Electronic – Verilog Non-Blocking And IF-Statement

This is actually quite similar to a question I answered previously, but I will try to build up a canonical answer for this somewhat common issue.

In a zero-delay simulation like this, the test flip-flop has a setup time and a hold time of zero:

\$ T_{setup} = T_{hold} = 0 \$

What this means is that the instant the sensitive clock edge occurs, the output is updated, regardless of what happened immediately before or after that instant. This is not like real hardware which would usually have a non-zero \$ T_{setup} \$ and \$ T_{hold} \$.

I ran your testbench, and the results are pretty clear. The valid signal changes at the same time the clock signal does. You have delayed them by precisely the same amount. So at the very edge when the clock is high, the valid signal has also changed:

Both the input (div_valid), and the clock (gclk) go high at the same time: 220 ns. Therefore, the DFF latches this new data, and the output changes instantly since there is also 0 propagation delay. This simulation would look less confusing if we just chose a different delay value for the input to the design:

In this case, we update the input on the falling edge of the clock (620 ns). It is much more clear now that the next clock edge (640 ns) will be when the DFF updates its output.

Here is the testbench code so you can see exactly how it works in your own simulator. Please update the design name as it wasn't clear what yours was named.

module scratch_tb;

   reg gclk;
   reg resetn;
   reg div_valid;
   wire data;

   // instantiate design under test
   scratch scratch (gclk, resetn, div_valid, data);

   // generate stimulus
   initial begin
      gclk            = 1'b1;
      resetn          = 1'b0;
      div_valid       = 1'b0;

      #80 resetn      = 1'b1;

      // test 1: input switches on rising clock edge
      #160 div_valid   = 1'b1;
      #40 div_valid   = 1'b0;

      #160 div_valid  = 1'b0;

      // test 2: input switches on falling clock edge
      #180 div_valid  = 1'b1;
      #40 div_valid   = 1'b0;

      #2000 $finish;
   end

   always begin
      #20 gclk = ~ gclk;
   end

endmodule

Articles that say "nonblocking and blocking assignments do not have any effect on the synthesis, but only regards to the simulation" are incorrect. It is true there are certain cases where choosing either assignment operator has no affect on the synthesized hardware, but there are cases where it does make a difference.

One needs to realize that code you write executes in serial order within a begin/end block regardless of whether it represents a sequential or combinational circuit. Both simulation and synthesis tools need to implement the behavior you specify.

You can model both sequential and combinatorial circuits with just blocking assignments (in fact, non-blocking assignments were a later addition to the Verilog language). You can determine if the code represents a particular kind of circuit by looking at the order of assignments to the LHS variables with respect when the same variables are used in the RHS.

always @(posedge clk)begin
    ab  =  a & b & q0;  
    q0  =  ab; 
  end 

Because ab appears in a blocking assignment statement before appearing on the RHS, it is considered combinational (write before read). And the value of ab gets updated immediately before executing the next statement. And since q0 appears on the RHS before appearing on the LHS, it is considered sequential (read before write).

But if we add another always block that uses ab on the RHS, that usage is considered sequential.

always @(posedge clk) begin
        c = ab;  
      end 

Now ab represents sequential logic in that block because the other block executed on a clock edge, sampling the values of a and b. But now we have a simulation race condition because although the execution order within a begin/end block is serial, there is no defined ordering between different always blocks triggered by the same clock edge - you don't know if the second always block has the updated value of ab from the first always block.

The non-blocking assignment solves this race simulation race condition by delaying the LHS assignment until after everything else that was supposed to execute at the same time step. If we change the assignment to ab in the first always block to:

always @(posedge clk)begin
    ab  <=  a & b & q0; // NBA
    q0  =  ab; 
  end  

Now the second always block is guaranteed to have the "old" value of ab. But this also does affect the statement that follows it in the same block. It now assigned the "old" value of ab to q0. So now it does take two clock cycles to get the value through to q0.