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)?

• Dave Tweed: You should in general avoid coding like that, because in real hardware, it would represent a setup/hold/recovery time violation.
• EE18: That's well taken, and so I should note that this certainly isn't for any real application. This is just part of me trying to understand Verilog :) @DaveTweed

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.

• EE18: Understood (mostly), I think! Just to confirm, and as regards your very first sentence: are you saying that each of the cases 1,2a, and 2b I outlined in the OP are possible (in terms of comporting to the Verilog standard and/or to how most simulators are implemented)?
• toolic: @EE18: Unless you are designing your own Verilog simulation software, you should not focus too deeply on event scheduling details. Focus instead on good coding practices to design the digital logic you need to design.
• EE18: That is fair, but I would argue that since those good coding practices follow from simulator rules (which in turn follow from trying to model, as best we can, real hardware) that it can't hurt to know the latter :) at any rate, I would greatly appreciate if you can comment on that question. I have accepted either way.

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.