System Verilog event regions
http://www.sunburst-design.com/papers/CummingsSNUG2006Boston_SystemVerilog_Events.pdf
Let us first understand the #1step (time step) and time slot concepts in simulation -
what do they really mean?
#1step (time step): -
• This is the smallest unit of time for which the simulator will schedule an
event – there can be no activity in between #1step delays.
• The smallest possible increment when advancing from one time slot to the
next is represented by the global time precision.
• The step time unit is equal to the global time precision. "The global time
precision, also called the simulation time unit, is the minimum of all the time
precision in the design."
• To synchronize the scheduling of events across different modules with
different timescales and precisions, the simulator picks the smallest time
precision across the entire design and assigns that the value of 1 time unit
Ex: - Assuming the smallest precision across all the modules was 10ps, that becomes the
global value of 1 time unit. So, if there were a module with a timescale of 1ns/1ns and
there was a delay of #12.3, that would be rounded to 12ns and then scaled to an
integer of 1200. (1200x10ps= 12ns)
timescale of 1ns/200ps
t=0 t=1ns t=2ns
200ps 200ps 200ps 200ps 200ps 200ps 200ps 200ps 200ps 200ps
Time slot 1
Time slot 0
All scheduled events at a specific time define a time slot. Simulation proceeds by
executing and removing all events in the current simulation time slot before moving on
to the next nonempty time slot, in time order. This procedure guarantees that
the simulator never goes backwards in time.
System Verilog event regions.
Regions that are designed to implement correct RTL functionality:
Active regions:
• Active,
• Inactive
• NBA regions - but avoid Inactive region events).
Regions that are designed to implement correct verification execution:
Preponed, Reactive regions:
• Reactive,
• Re-Inactive,
• Re-NBA
• Postponed regions
Regions that are designed to implement concurrent assertion checking:
• Preponed,
• Observed
• Reactive regions.
Region that should be avoided:
• Inactive region. (# delays in RTL)
Notes:
• Of course, verification code can be executed in the regions devoted to RTL
functionality.
• Prior to the introduction of SystemVerilog, engineers working on Verilog-
2001 verification, implemented some clever methods to ensure race-free
operation between RTL designs and the testbenches.
• The new SystemVerilog regions just make it easier to implement a race-free
verification environment.
1. Preponed Events Region
• In this region, the concurrent assertions event values are sampled.
• Preponed region is executed only once in each time slot, immediately
after advancing simulation time (there is no feedback path to re-
execute the Preponed region).
• "The values of variables used in assertions are sampled in the
Preponed region of a time slot, and the assertions are evaluated
during the Observed region. ..."
2. The Active Region Set (Active - Inactive - NBA)
• The active region set is used to schedule blocking assignments and
nonblocking assignments included in module code.
• Any task or function called from a module is also scheduled into the
active region set.
• The purpose of the active region set is to schedule RTL and behavioral
code activity. Testbench code can also be written as module code and
indeed pre-existing Verilog testbench code was written as module
code, but SystemVerilog users are encouraged to place future
testbench code into program, so they are scheduled in the different
regions to avoid race conditions
a. Active Events Region
• 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.
b. Inactive Events Region
The region where #0 blocking assignments are scheduled.
Most designers that continue to use #0 assignments are trying to beat the
race condition that might exist in their code due to assignments made
to the same variable (The variable is read in one always block and
updated the same variable in another always block at the same time)
from more than one always blocks, which is a violation of basic RTL
Guideline
c. Nonblocking Assignment Events Region
In this region, LHS of all the non-blocking assignments are updated with the
RHS evaluated in active event region.
3. Observed region
• The observed region is designed to evaluate concurrent assertions using
the values sampled in the preponed region.
• Clocking blocks are triggered.
• This region just evaluates pass or fail conditions of concurrent assertions,
it doesn't execute the code written inside pass or fail block.
• A process associated with the pass and fail code is scheduled inside the
Reactive regions. This is because concurrent assertions are designed to
behave strictly as monitors, thus, they are not allowed to modify the
state of the design
4. The Reactive Region Set (Reactive - Re-Inactive -Re-NBA).
Why the program block has been introduced?
As it is explained above all the test bench related code is executed in reactive
regions if it is written inside the program block, this way we can isolate RTL and
the test bench code and avoid race conditions between RTL and test bench.
a. Reactive Events Region (Similar to the active region, but for the program
modules)
• 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 updates into the Re-NBA region.
• Execute all program continuous assignments
• Execute the $exit and implicit $exit commands.
The reactive region events are scheduled towards the end of the time slot to ensure
the following.
• The signals monitored/sampled by the test bench code are stable before it
samples. Since all the signals which are driven by DUT are evaluated in the
active regions, they can be monitored in the reactive regions by program block
without any race condition issue.
• It also ensures, the signals driven by the test bench to the DUT are stable
enough before it is read by the DUT
5. Postponed Region
• This is the last region to be executed in the given time slot
• This region is designed 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.
Let's consider a simple example to understand how the events are scheduled in the
different regions.
What is the best or when to apply stimulus in verilog and system verilog??.
• Verilog-2001 designs and testbenches
The Verilog testbench methodology typically assigned stimulus on the
inactive clock edge (The clock edge which is not used by the DUT), typically far
away from setup and hold times for the gate-level devices.
• System Verilog designs and testbenches
There are two ways to drive stimulus if the test bench is coded in system verilog.
a. Drive stimulus on inactive clock edge like verilog (This method is not highly
recommended over clocking block)
b. Use the clocking blocks supported by system Verilog to have configurable
skew values for input and output ports of the testbench.
clocking ram @(posedge clk);
14 input #1 dout;
15 output #1 din,addr,ce,we;
16 endclocking
In the above example, input and output skews are defined such that
inputs are sampled by test bench 1ns before the active clock edge and all
the outputs (stimulus) from test bench are driven 1 ns after the clock edge.
