Non-blocking assignment in always@(*) block

Hi,

I've always coded using blocking assignment in always@(*) to specify combo logic. However, I am going through a design where non-blocking assignment is always used in always@(*) blocks. Is there a reason to do this? Maybe to be more succinct in the code, and declare less intermediate signals?

Thanks :smile:

KQWD,

I would question the quality of that design you are going through...

See the following paper and search for Example 19.

http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

You really don't want to use non-block statements in what is supposed to be combinatorial logic.

Regards

Thanks for the reply - I see why the example you gave is wrong. I guess I have a new question - the signals in the always@(*) block are declared as reg, and wires are assigned , for example;

input wire input_value;

reg example1_new;
reg example1_current;
reg example2_new;
reg example2_current;
wire example3;

always@(posedge clk) begin
example1_current <= example1_new;
example2_current <= example2_new;
end

assign example3 = input_value;

always@(*) begin
example1_new <= 0;
example2_new <= 0;
if (example3) begin
example1_new <= 1;
example2_new <= 1;
end
end

So are example1_new and example2_new combinatorial logic? It seems like no, since they are reg, but I am still confused by assigning it in a always@(*) block. It's like we are registering values and doing the combinatorial logic at the same time, since the last non-blocking statement is used (example1_new will be 1 if input_value is 1).

Thanks again!

You should read my blog about the use of 'reg' terminology in Verilog: https://go.mentor.com/wire-vs-reg

reg in verilog always confuse to beginner, as reg implies to us as sequential element and wire implies for combinational element.

following points are needed to understand-
1. any output whether it is intermediate output or output must be declared as reg iff it is described inside always block
2. Always block can infer Combinational hardware, iff it is output completely defined within always, for example, incomplete if leads to a latch (which is sequential element and latches are level triggered)

3. Flipflop are always EDGE Triggered, thus signal attribute such as posedge or negedge leads to flipflop inference.

In the present example (in post #3), there's no effect of using non-blocking versus blocking assignments. Nevertheless you should follow the known coding rules (e.g. discussed in the Sunburst paper linked in post #2), because it might matter in other cases.