SystemVerilog Simulation Semantics - SVA: The Power of Assertions in SystemVerilog - page 45

Example 3.2. In Example 3.1 , the nonblocking assignment

allow <= req;
causes an update event if the value of variable allow changes as a result of the
assignment. There are many language constructs whose execution is tied to the
occurrence of update events. The continuous assignment statement

assign tmp = allow && gnt1;
in Example 3.1 is executed when and only when either the update event on allow
or preGrant occurs. The always procedure
always @( posedge clk) allow <= req;
executes when and only when the event posedge clk occurs. t

The execution of a statement may not materialize immediately, but be scheduled
as an evaluation event in a queue corresponding to a region for execution, based
on the type of the statement and its context. By scheduling evaluation events in
various queues and by executing them later from the queues, the intended order
between statements is accomplished. The execution of an evaluation event can result
in further update events or evaluation events which are again scheduled. The creation
and execution of these events, together with their scheduling in queues is what keeps
the simulation engine running. As long as there are scheduling events left to process,
the engine keeps executing statements and progresses through time. The simulation
ends only when there are no more events left in the queues.

Example 3.3. When the evaluation event for the always procedure

always @( posedge clk) allow <= req;
is executed, an evaluation event for the nonblocking assignment allow <= req;
emerges and gets scheduled. When this evaluation event for the nonblocking
assignment is executed, an update event for variable allow is issued.

t

3.3 Bringing Order to Events

Now, we can see the important role of queues in the assembly of discordant events
into a predictable simulation execution model. First, we focus on the execution
of statements specified in the context of design code, rather than assertions, or
programs that represent testbench code. Events issued from the design code are
grouped in a region set called the Active region set. We elaborate upon the notion of
a region set, including the Active region set and other region sets, in Sect. 3.5 .For
now, we limit our discussion to the activities within the regions of the Active region
set and to the queues they contain.
The queues represented in Fig. 3.1 belong to the regions from the Active region
set. There are three principal regions and queues corresponding to them in this
region set: Active region, Inactive region and NBA region.