Contact / Report an issue

SystemVerilog Scheduling Semantics

SystemVerilog event regions


This section gives an overview of the interactions and behavior of SystemVerilog elements, especially with respect to the scheduling and execution of events.

Updates to IEEE STD 1800-20051 divide the SystemVerilog time slot into 17 ordered regions, nine ordered regions for the execution of SystemVerilog statements and eight ordered regions for the execution of PLI code. The purpose of dividing a time slot into these ordered regions is to provide predictable interactions between the design and testbench code.

Use of Event scheduling


Every change in the state of a net or variable in the system description being simulated is considered an update event. When an update event is executed, all the processes that are sensitive to those events are considered for evaluation known as an evaluation event.

Examples of processes include, initial, always, always_comb, always_latch, and always_ff procedural blocks, continuous assignments, asynchronous tasks, and procedural assignment statements.

A single time slot is divided into multiple regions where events can be scheduled. This event scheduling supports obtaining clear and predictable interactions that provide for the ordering of particular types of execution.

This allows properties and checkers to sample data when the design under test is in a stable state. Property expressions can be safely evaluated, and testbenches can react to both properties and checkers with zero delay, all in a predictable manner.

This same mechanism also allows for non-zero delays in the design, clock propagation, and/or stimulus and response code to be mixed freely and consistently with cycle-accurate descriptions.

Note:
  1. The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the system description being simulated.
  2. A time slot includes all simulation activity that is processed in the event regions for each simulation time SystemVerilog event Regions The new SystemVerilog event regions are developed to support new SystemVerilog constructs and also to prevent race conditions being created between the RTL design and the new verification constructs.

events region
SystemVerilog Scheduling Semantics

These new regions guarantee predictability and consistency between design, testbenches, and assertions



Preponed region


The values of variables that are used in concurrent assertions are sampled in the Preponed region. (Evaluation is done at observed region). Preponed region is executed only once in each time slot, immediately after advancing simulation time.

Pre-active region


The Pre-active region is specifically for a PLI callback control point that allows for user code to read and write values and create events before events in the Active region are evaluated

Active region


The Active region holds current events being evaluated and can be processed in any order.

  • Execute all module blocking assignments.
  • Evaluate the Right-Hand-Side (RHS) of all nonblocking assignments and schedule updates into the NBA region.
  • Execute all module continuous assignments
  • Evaluate inputs and update outputs of Verilog primitives.
  • Execute the $display and $finish commands

Inactive region


The Inactive region holds the events to be evaluated after all the active events are processed. In this region #0 blocking assignments are scheduled.

Pre-NBA region


The Pre-NBA region is specifically for a PLI callback control point that allows for user code to read and write values and create events before the events in the NBA region are evaluated

Non-blocking Assignment Events region (NBA)


The principal function of this region is to execute the updates to the Left-Hand-Side (LHS) variables that were scheduled in the Active region for all currently executing nonblocking assignments.



Post-NBA region


The Post-NBA region is specifically for a PLI callback control point that allows for user code to read and write values and create events after the events in the NBA region are evaluated

Observed region


The principal function of this region is to evaluate the concurrent assertions using the values sampled in the Preponed region. A criterion behind this decision is that the property evaluations must only occur once in any clock triggering time slot. During the property evaluation, the pass/fail code shall be scheduled in the Reactive region of the current time slot.

Post-observed region


The Post-observed region is specifically for a PLI callback control point that allows for user code to read values after properties are evaluated (in Observed or earlier region).

Reactive region


The code specified in the program block, and pass/fail code from property expressions, are scheduled in the Reactive region. The principal function of this region is to evaluate and execute all current program activity in any order

  • Execute all program blocking assignments.
  • Execute the pass/fail code from concurrent assertions.
  • Evaluate the Right-Hand-Side (RHS) of all program nonblocking assignments and schedule
  • Execute all program continuous assignments
  • Execute the $exit and implicit $exit commands

Re-Inactive Events region


In this region #0 blocking assignments in a program process are scheduled.

Postponed Region


The principal function of this region is to execute the $strobe and $monitor commands that will show the final updated values for the current time slot. This region is also used to collect functional coverage for items that use strobe sampling.