diff options
author | bnewbold <bnewbold@robocracy.org> | 2014-05-01 17:03:24 -0400 |
---|---|---|
committer | bnewbold <bnewbold@robocracy.org> | 2014-05-01 17:03:24 -0400 |
commit | 494848cbf05f87897ed79067cf0eace7ff566d4b (patch) | |
tree | 00eb8395e4453d5b1f3372baf0a360397cf03a0f /tmp/review_nonblocking_verilog_kill | |
parent | 5a58c148008b028cdcef3e5d12b31d873d483caa (diff) | |
download | knowledge-494848cbf05f87897ed79067cf0eace7ff566d4b.tar.gz knowledge-494848cbf05f87897ed79067cf0eace7ff566d4b.zip |
back up misc crap from ent before wipe
Diffstat (limited to 'tmp/review_nonblocking_verilog_kill')
-rw-r--r-- | tmp/review_nonblocking_verilog_kill | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/tmp/review_nonblocking_verilog_kill b/tmp/review_nonblocking_verilog_kill new file mode 100644 index 0000000..296f8c5 --- /dev/null +++ b/tmp/review_nonblocking_verilog_kill @@ -0,0 +1,67 @@ +to: team@leaflabs.com +subj: paper review: "Nonblocking Assignments in Verilog Synthesis..." + +TL;DR: this is something like a "goto considered harmful" w/r/t using confusing +blocking assignment in (non-sythesizable?) Verilog. + +# Context + +This paper was written in 2000 and seems to target Verilog programmers who +write non-synthesizable simulation code. Despite the word "Synthesis" in the +title. After reading, the implication that this paper might have any new +insights for an engineer whose failure might "kill" stikes fear in my gut. + +Apparently this won a "Best Paper" award at a conference back when it was +published. + +On page 15 there is a note about about synthesis performance: "The latter would +be inefficient from a simulation time perspective"; perhaps this was the +historical temptation of these bad practices? + +# Judgement + +There's really nothing new here (for jess/aj/bryan at least): for sequential +logic use nonblocking assignment in always@ blocks, and for combinatoral logic +use 'assign' statements outside of a block, unless you have something really +tight and complicated going on, in which case use an always block with a +carefully selected sensitivity list and all blocking assignments inside. + +# Nuggets + +From page 20: "Nonblocking assignments are updated after all $display +commands". I did not know this! The example given is pretty good; $strobe is +recommended as the alternative: + + module display_cmds; + reg a; + initial $monitor("\$monitor: a = %b", a); + initial begin + $strobe ("\$strobe : a = %b", a); + a = 0; + a <= 1; + $display ("\$display: a = %b", a); + #1 $finish; + end + endmodule + +gives: + + $display: a = 0 + $monitor: a = 1 + $strobe : a = 1 + +# Appendix: Verilog Coding Guidelines + +Verbatim from paper: + +1: When modeling sequential logic, use nonblocking assignments. +2: When modeling latches, use nonblocking assignments. +3: When modeling combinational logic with an always block, use blocking +. +4: When modeling both sequential and combinational logic within the same always +nonblocking assignments. +5: Do not mix blocking and nonblocking assignments in the same always block. +6: Do not make assignments to the same variable from more than one always block. +7: Use $strobe to display values that have been assigned using nonblocking +. +8: Do not make assignments using #0 delays. |