The SystemVerilog Scheduling Model and Event Regions

SystemVerilog defines a precise scheduling model — the ordering of events within a single simulation time step. Understanding it explains why non-blocking assignments update when they do, why $strobe differs from $display, and why a well-written testbench never sees race conditions.

Regions within a time step

Each time step is divided into ordered regions. The key ones: the Active region (blocking assignments, RHS of non-blocking, $display), the NBA region (non-blocking assignments take effect), and the Postponed region ($strobe, $monitor — read-only, after everything settled). Because non-blocking updates land in NBA, a $display in Active sees the old value while a $strobe sees the new one.

module tb;
  logic clk = 0, q = 0;
  always #5 clk = ~clk;
  always @(posedge clk) q <= ~q;      // non-blocking: updates in NBA region
  initial begin
    @(posedge clk);
    $display("$display at edge : q = %b  (Active region: OLD value)", q);
    $strobe ("$strobe  at edge : q = %b  (Postponed: NEW value)", q);
    #10 $finish;
  end
endmodule

$display at edge : q = 0  (Active region: OLD value)
$strobe  at edge : q = 1  (Postponed: NEW value)
- /var/folders/l0/gs5hnkm56g54bmxg32r6nnwr0000gn/T/tmpvrrhpdbc/tb.sv:9: Verilog $finish

Run it: at the clock edge $display prints the value of q before the non-blocking update, while $strobe, which fires in the Postponed region after all NBA updates, prints the value after. This is exactly why testbench checks and monitors use $strobe/clocking blocks to sample stable end-of-step values.