Why do we use Blocking statement in Combinatorial Circuits designed using Always Block in Verilog/Systemverilog ? Why not Nonblocking?

Question

Everywhere it is mentioned this as a guideline, but after lot of thought i want to know what harm will it cause if we use Nonblocking statement inside Always Block for Combinatorial also. I won't be mixing the two together. But what i feel is when we use Nonblocking for Combinatorial statements in Always Block it represents the hardware more accurately. Does it not...?

For Example, if we take the following circuit:

In this diagram when the inputs a,b,c are supplied the outputs x1 and x will not be available instantly. There will be gate delays. first x1 will be available and then x will be available. If we use blocking statements both are available instantly. If we use nonblocking, it resembles the hardware more accurately.

For Example, if we take the following code based on the above diagram

module block_nonblock(output logic x,x1,y,y1,input logic a,b,c);

always@* begin : BLOCKING
    x1 = a & b;
    x  = x1 & c; 
end

always@* begin : NONBLOCKING
    y1 <= a & b;
    y  <= y1 & c; 
end

endmodule

This synthesizes as:

Both are synthesized as And gates, and give same simulation results but when we check for the changes in output in delta time, i feel the Non blocking matches the hardware more accurately as compared to the Blocking.

Also i went through : IEEE P1364.1 / D1.6 Draft Standard for Verilog® Register Transfer Level Synthesis, which specifies the use of non blocking for Sequential modeling but doesn't specify specifically using blocking for Combinational modeling using Always Block. It says don't mix the two(Blocking and Nonblocking) in Combinational statements.

So, shouldn't we use nonblocking for combinational statements in always blocks which are dealing with pure combi logic (non sequential/ no clocks involved)

Answer 1

The harm is in simulation; in performance, and in race conditions.

Your NONBLOCKING code executes twice for every change in a or b. Non-blocking assignment updates are scheduled into a later queue of events, and this causes a much bigger rippling effect where blocks get repeatedly executed.

When you simulate RTL code, you are doing so in the absence of physical delays and synthesis tools understand how the logic is going to be implemented. But simulation tools cannot do this and also need to work with non-synthesizable code. They have to execute the code exactly as written. And they also have to deal with massive amounts of concurrency executing code on a processor with a single or limited number of threads. So simulation introduces race condition in software that would not exist in real hardware. Non-blocking assignments are there to prevent those race conditions when writing sequential logic. But they can have the opposite affect if you use them in combinational logic, especially when used in the combinational logic involved in the generation of clocks.

Answer 2

You ask "So, shouldn't we use nonblocking for combinational statemnts in Sequential?" The answer is No.

If you use non-blocking assignments for combinational logic in clocked always blocks, you will get more flip-flops than you expect. Basically, non-blocking assignments in clocked always blocks will behave like flip-flops when you simulate and infer flip-flops when you synthesise.

So,

1 - use blocking assignments for gates and

2 - use non-blocking assignments for flip-flops.

Answer 3

Your very own description of the behaviour of the circuit suggest actually the use of blocking operations.

You say: (emphasys mine)

In this diagram when the inputs a,b,c are supplied the outputs x1 and x will not be available instantly. There will be gate delays. first x1 will be available and then x will be available. If we use blocking statements both are available instantly. If we use nonblocking, it resembles the hardware more accurately.

So you need x1 to be available before x. So your always block must use a blocking assignment, so...

always@* begin : BLOCKING
    x1 = a & b;
    x  = x1 & c; 
end

x1 first will have a known value, and then, and only then, x will have a value. If you use non blocking...

always@* begin : NON BLOCKING
    x1 <= a & b;
    x  <= x1 & c; 
end

You are telling the simulator that x1 and x will be evaluated at the same time.

Although for synthesis this may work, in simulation this won't, and you want to make sure your simulated circuit works as intended before going over the synthesis phase.

Answer 4

I have found a satisfactory answer and need input for it. I feel we should use Nonblocking statements for both combinational and sequential statements.

For sequential it is pretty clear y we should use.

I will describe the reason for Combi Blocks. For combinational segments we will use Nonblocking Statements because, when we use Blocking or NonBlocking statements, even though it gives us the same hardware or RTL in the end; it is the nonblocking statements which shows us the glitches in simulation. Theses glitches will be there in hardware as well (because of Gate Delays), so we can rectify them when we see them in Simulation so that they will cause less harm at a later stage of the design/development cycle.

In the circuit I originally mentioned in the question if we give the inputs together as (A = 1,B = 1,C = 0) and then change them together after say 10ns as (A=1,B=0,C=1) then we can see that there is a glitch. This glitch will be there in actual Hardware as well. But this is only shown in simulation by Nonblocking Statements Output (Y) and not by Blocking Statements Output (X). Once we see a glitch we van take additional measures to prevent this from happening, so that it doesnt happen in hardware.

Hence i feel it is safe to conclude that we must use Nonblocking statements for combi blocks.

Answer 5

We should not use non-blocking assignments in Combinational block, because if we use non-blocking it will infer the transport delays in the design due to this our results will never come what we expected, but if we use blocking , this blocking will able to suppress the transport delays in the design and we can safely said that there is no glitches in the waveform. So it is recommended that we should use blocking statements in combinational designs.