Everywhere I have read has said, do not use the <= operator inside an always@(*) block, yet my professor did on his solutions for one of our homeworks, and he works in the industry too. What is their reasoning for saying this if it can be done?
-
1if you added some example code, you would get a better response. – Tony Cronin Mar 22 '14 at 23:50
-
This has effectively been answered here: http://stackoverflow.com/questions/22565475/verilog-blocking-assignment – Chiggs Mar 23 '14 at 11:07
3 Answers
The short answer is that you can always use either blocking or non-blocking assignments, in any situation, as long as you understand the implications for scheduling. If you understand the scheduling model, you can use NBAs (ie. <=
, which is not an 'operator' in this context) in combinatorial processes, which is what your prof has done. Note that using NBAs in combinatorial code might potentially reduce simulation speed.
The problem is that practically nobody actually understands "the implications for scheduling", so most people use guidelines instead. The guidelines you should read for using NBAs are in this paper. Ask if you don't understand it. It's too complicated to summarise, but the paper suggests not using NBAs in combinatorial code.
These are just guidelines, and lots of (knowledgeable) people don't like them. Bear in mind that guidelines only exist because the language is poorly designed and defined. Also bear in mind that people who write guidelines tend not to appreciate this, and like to think that there are good reasons for their guidelines.

- 9,619
- 6
- 46
- 78
In LRM, it says
"The implicit event_expression, @*, is a convenient shorthand that eliminates these problems by adding all nets and variables that are read by the statement."
In Verilog, when you are using <=
non-blocking assignments and want to refer flip-flops or latches, your always@(...)
sensitive list must contains edge-triggered clocking and reset signals.
To make the syntax more explicit and clear, you should use always_ff
or always_latch
with your clocking and reset signals, not just always @*
.

- 2,449
- 1
- 21
- 27
-
This doesn't answer the question, and the `always_` stuff is SystemVerilog, not Verilog. They're unnecessary in Verilog (and SystemVerilog) unless you're doing something that you probably shouldn't be doing. – EML Mar 24 '14 at 10:08
Usually the usage of = is for combinational logic and <= for sequential logic.however, there are certain exceptions. one example is clock modeling, as described in Verilog Blocking Assignment. however, specifically for your question i believe Gotcha 30 (Nonblocking assignments in combinational logic) in 101 gotchas can explain it ( http://books.google.com/books?id=_VGghBpoK6cC&printsec=frontcover&dq=Verilog+and+SystemVerilog+Gotchas&hl=en&sa=X&ei=F9cvU_WhJYzdoASLoYHwBw&ved=0CCwQ6AEwAA#v=onepage&q=Verilog%20and%20SystemVerilog%20Gotchas&f=false)

- 1
- 1

- 1
- 1
-
1I've got to say it - gotcha #30 (`always @(m,n) m <= m+n`) is nonsense. The real hardware oscillates, and the simulation oscillates, just as it should do. – EML Mar 24 '14 at 10:05