How are event-controlled events scheduled in Verilog?

Question

Consider the following snippet (please let me know if you need me to include more):

always @(posedge CLK)
begin
 if (RST == 1'b1)
  OUT <= 4'b0000;
 else
  OUT <= OUT + 1
end

The above, let's say, is part of some DUT. Now suppose in my testbench which instantiates this DUT that I update CLK (0 -> 1) and RST (1 -> 0) at the same time; more precisely, suppose that both are updated in different procedural blocks (so they are concurrent) in the same t=100 time slot's active region (both are blocking assignments). Is there any possibility of nondeterministic/simulator-dependent behavior?

I think the crux/answer to my question will depend on how Verilog treats event-controlled evaluation. I see two possibilities:

(1) RST gets updated to 0 before the CLK signal gets updated to 1. Then, when the CLK signal gets updated there is no problem because the always block above, which is sensitive to this edge on the CLK signal, generates an evaluation event in the same t=100 time slot's active region and, eventually, we get OUT <= OUT + 1 as desired.

(2) But what if CLK updated first? In this case, the always block above, which is sensitive to this edge on the CLK signal, generates an evaluation event in the same t=100 time slot's active region. Does this evaluation event occur (a) after or (b) before the RST update? (a) In this case, there is no problem since RST will already be updated and the same decision as in (1) above will be taken. (b) In this case we will take the wrong path.

Does Verilog have a defined behavior in this case, or is it up to the simulator (in which case code should not be written like this and, perhaps, the RST update should be done at some time slot before t=100)?

Answer 1

Yes, depending on how you drive the DUT inputs from the testbench, you could have simulation race conditions, leading to different behavior on different simulators.

This is why it is very important to use good coding habits in the design as well as the testbench.

Since your code uses a synchronous reset, you should drive it from the testbench as you drive your logic in the design, specifically:

• @(posegde CLK)
• Nonblocking assignments: <=

For example, assuming the testbench has the reg named RST_TB:

initial begin
    RST_TB <= 1;
    repeat (3) @(posedge CLK); // Adjust delay as needed
    RST_TB <= 0;
end

All synchronous inputs to the DUT should be driven in a similar fashion.

Answer 2

In real world, the hold time of a D flip flop is usually negative. Therefore, if you change the input at clock edge, the D flip flop will be written the input before clock edge. I think a simulator will also do this.