Event Semantics of System Verilog

26 Mar 2022

4 mins

Event semantics are various regions in which the simulation time slot is broken into. The simulation time slot does not move to the next time slot until all the activities of the current timeslot are completed. Do note that in event semantic for Verilog we used the term time-step but in System Verilog, we will use the term timeslot. This is because in recent standards the time-step terminology has been dropped from the standard.

In this article we will see the event semantics in System Verilog and why there was a need to make changes in the event semantics from Verilog. It is recommended to have knowledge of event semantics in Verilog before proceeding with this article.

Need for a new Event Semantics Region

In Verilog, we have seen that the timeslot is divided into 4 regions, namely Active, Inactive, NBA and Postpone region. Code written to schedule at correct regions can help avoid race around conditions that may be introduced due to the simulators. But there is one more race condition that was not considered in the initial Verilog standard.

The test bench and design need to interact with each other at various points in time. The clock is also generated in the test bench which acts as input for the design. But the design and test-bench code would be scheduled in any of these 4 regions only. This would not prevent any race around condition which may happen between the test-bench and code.

For example, Let’s suppose there is a situation where 2 blocking assignments one from testbench and one from design are scheduled to be executed in the active region. We know that there is no guarantee of order of execution of the 2 statements. Thus, there can be a race condition and output may vary depending upon which statement is executed first.

Event Semantics in System Verilog

In System Verilog, the timeslot is divided into 9 regions. These extra regions are added so that the design and test-bench code can execute in different regions ultimately avoiding race conditions between test-bench and design code.

From the above image, it can be observed that Active, In-active, NBA and Postpone regions are the same as that of the Verilog. Let’s investigate each region in detail

Prepone region

This is the first region which is executed when the simulation moves to the next timeslot. This indicated the state of the signal in the beginning of a time slot. This region is also used to sample the states of the signal that will be used in assertion.

Active Region Set

Similar to the Verilog semantic these region set consists of 3 regions. These regions behave exactly same as that of Verilog.

• Active Region
• Inactive Region
• NBA region

Observed Region

This region is used to evaluate the assertion expression from the values sampled in preponed region.

Re-active region set

This region set was introduced to be used by the test bench. This means that any of the test bench code would execute in the re-active regions. This set also consists of 3 regions and execution is similar to that of the active region sets.

• Re-Active Region
• Re-Inactive Region
• Re-NBA region

Postpone region

This is the last region of the event semantics. In this various system function like $strobe, $monitor gets executed. This region is also used to sample values for functional coverage if the strobe method is used for sampling.

Program block

From the above discussion, some of us can be confused as how the test-bench code will run in the re-active region set. In System Verilog, program block was introduced which is similar to that of modules. The only difference is that the code written inside program block are scheduled in re-active region sets.

Thus program blocks were introduced to be used with test-bench and should not be used with the design code.

Nowadays due to the advancement of the SV and the simulators lot of other construct have bee introduced to prevent race condition between design and test-bench. Thus program blocks are not widely used in industry nowadays.

Module vs Program