1. The SystemVerilog Assertion (SVA) language offers a very powerful way to
describe design properties and temporal behaviors; however, they are innately
synchronous due to how they are defined by the SystemVerilog standard.
Unfortunately, this makes them especially hard to use for checking asynchronous
events and behaviors. Notwithstanding, armed with the proper techniques, SVA can
be used to effectively describe and check both synchronous and asynchronous
assertions.
1
2. First, let’s start our discussion by having a look at asynchronous behaviors and the
challenges that they present.
2
3. Asynchronous behaviors typically come in two forms: (1) asynchronous control
signals, and (2) asynchronous communication. Most designs have some kind of
asynchronous event like an asynchronous reset, enable, non-maskable interrupt, etc.
Even if these events are synchronized within to a clock, they may occur at any time,
preempting the current operation of the design, and should immediately trigger an
assertion to check that the design properly responds to the event.
The second form of asynchronous behavior is asynchronous communication. This is
seen with communication across clock domains or on interfaces that use some kind
of asynchronous handshaking. See the following paper for details on handling these
behaviors:
Doug Smith. “Asynchronous Behaviors Meet Their Match with SVA,”
DVCon Proceedings, San Jose, February 2010.
This paper is also available from www.doulos.com.
3
4. Let’s have a look at the first type of behavior—asynchronous control signals. To
understand the difficulties, we’ll start by having a look at a simple up-down counter.
The table here shows the proper behavior of this counter. The asynchronous control
is the reset that causes the design to immediately change to 0.
4
5. If we were to write assertions for this counter, they might look something like this.
These assertions are rather straightforward since checking always happens on the
rising edge of the clock. But what about the asynchronous reset? How do we
incorporate that into our assertions?
5
6. A common mistake would be to add Reset into our assertion precondition as shown
here. While this looks like it would work, we might actually encounter false failures
from this. As you can see, when reset occurs, the value of Q immediate resets to 0.
On the next clock cycle when the precondition is evaluated, the asserted Reset will
stop the precondition from spawning a thread and the check from occurring just as
we intended.
The problem lies with the cycle before Reset occurs. The cycle before, the
precondition is met, an assertion thread is spawned, and the checker waits to check
the condition on the next clock edge. Before the check is evaluated, the Reset signal
asserts, changing the actual value of Q from the expected and the assertion throws a
false failure.
6
7. What we really need is some way to not only stop the evaluation of an assertion
when Reset occurs, but also kill any threads waiting to check when the reset asserts.
The “disable iff” abort terminator allows us to do just that. As soon as the Reset
signal occurs, the level-sensitive abort terminator stops both the evaluation of the
assertion and kills any processing threads. As a general rule of thumb, all assertion
sensitive to an asynchronous signal should use a “disable iff” qualifying expression.
7
8. Disable iff handles terminating our assertions, but what about checking that the
RTL does the correct thing when the asynchronous reset occurs? To write such an
assertion, we might write something as shown here---when the Reset goes high, then
check that Q goes to 0.
At first glance, this looks like it would do what we expect, but unfortunately it does
not. In fact, the assertion never even evaluates!!
8
9. To understand why, we need to understand how the SystemVerilog simulation
scheduler evaluates assertions, which we will look at in the next section.
9
10. A Verilog or SystemVerilog simulator has different scheduling regions where events
are scheduled and subsequently evaluated. All event evaluations occur in the
scheduler’s Active region. Events are scheduled in the Inactive region by using a #0
delay, and the Non-Blocking Assignment (NBA) region by using a non-blocking
assign. Once all the events in the Active region are exhausted, the Inactive region
events are promoted to the Active region and evaluated. Likewise, once those events
are evaluated, the non-blocking events are promoted to the Active region and
evaluated. As simulation progresses, events are scheduled and evaluated until all
events for a particular time step are evaluated and simulation can move forward.
The traditional Verilog scheduling semantics have been extended from including an
Active, Inactive, and NBA regions to also include some special regions just for
assertions. The Preponed region has been added in SystemVerilog in order to
sample all of a concurrent assertion’s inputs, and the Observed region is used for
their evaluation. Events such as clock or asynchronous signals are generated using
blocking or non-blocking assignments from initial or always blocks, which means
that they occur in the Active or subsequent regions. Since concurrent assertion
inputs are sampled in the Preponed region before any clock or reset events are
generated, assertions ALWAYS sample their input values before the sampling event
occurs. This is why when we write synchronous assertions we always need to go 1
clock cycle into future and then look into the past with $past() in order to see what
happened on the last clock edge.
In addition to the Preponed and Observed regions, SystemVerilog also includes a
Reactive region where program blocks can schedule their events after the design has
finished evaluating in the Active/Inactive/NBA regions. The idea for this is to avoid
race conditions between the testbench and the design.
10
11. Now that we understand the scheduling semantics, let’s take a look at why the
asynchronous reset assertion failed. On the left-hand side, you can see what the
values of Reset and Q are in their respective regions. In the top assertion, when the
posedge of Reset occurs, the precondition evaluates whether Reset is true (non-
zero). As you can see, in the Preponed region, Reset == 0 so this assertion’s
precondition ALWAYS evaluates to false and the assertion never performs any
checking (this is hard to detect in simulation because it looks like the assertion is
always working and evaluating to true!)
In the bottom assertion, we set the precondition to always evaluate true (i.e., non-
zero) so that the assertion check occurs, but the value sampled for Q in the Preponed
region is 3, not 0. So this assertion always fails except for the case when Q was
already 0 before reset.
Where we need to check the value of Q is sometime after the design has updated Q
in the NBA region. To do so, we need to move the sampling of the assertion inputs
to either the Observed, Reactive, or later regions.
11
12. Let’s have a look at some simple methods we could use to delay the sampling of our
assertion inputs.
12
13. The most common way of handling asynchronous checking is to simply check the
signal synchronously. Either the clock or a fast clock usually suffices to give the
design enough time to update so when the assertion evaluates it samples the correct
input values. For most people this is adequate and it handles any timing delays in
the design, but it also leaves you wondering if the design really did immediately
react to the asynchronous control signal since the actual checking is delayed.
13
14. Alternatively, immediate assertions can be used to check the asynchronous behavior
immediately at the appropriate time. Immediate (or procedural) assertions are
placed inside of procedural blocks of code (initial, always) and sample their inputs
at the time they are evaluated, which is based on their context. By placing the
immediate assertions in the right context, the sampling of their inputs can be delayed
to check the asynchronous behavior.
There are several simple methods that can be used to delay the input sampling,
which will be discuss in the following slides.
14
15. The first method to delay input sampling is to use a program block. Program blocks
sample their inputs in the Observed region and schedule their events in the Reactive
region. By placing the assertion in a program block, the value of Q can be sampled
AFTER the non-blocking assignment is made to it by the RTL when Reset occurs.
Now, when Reset occurs, its results can be immediately observed and checked.
One drawback to using a program block is that not all simulators support nested
programs inside of modules, which means that hierarchical references would be
needed to access the RTL signals. To work around this, a program could be bound
(using bind) into the design unit.
15
16. Sequence events are another way to delay assertion input sampling. The
SystemVerilog standard states that sequence events set their end-point (i.e., when
they are matched) in the Observed region, and that a process resumes it execution
following the Observed region in which the end-point is detected (see IEEE
1800-2005, Section 10.10.1, p. 142).
A sequence event is created by defining a named sequence and then waiting on it as
shown above. The assertion is placed after the sequence event so that its inputs are
sampled after the Observed region. The latest versions of most simulators have
good support for sequence events.
16
17. The expect statement is another useful SystemVerilog construct for delaying input
sampling. The SystemVerilog standard states, “The statement following the expect
is scheduled to execute after processing the Observe region in which the property
completes its evaluation” (IEEE 1800-2005, Section 17.6, p. 299). The advantage of
using expect over just assert is that expect can evaluate temporal expressions and
properties; whereas, assert cannot. Unfortunately, not all simulators delay the
evaluation of expect so a program block can be used as seen before.
17
18. Since the RTL updates using non-blocking assignments, trying to delay sampling to
the NBA region could pose a possible race condition. However, if done correctly, an
immediate assertion can be also be delayed to right after the RTL has finished its
updating. This can be accomplished by using a combination of a non-blocking
event, such as the non-blocking trigger shown above, and the use of a #0 delay.
The non-blocking trigger above will delay the assertion evaluation until at least the
NBA region; however, System/Verilog does not guarantee the order that the always
blocks will evaluate and schedule their events. In order to further delay the assertion
evaluation until after the RTL schedules its update to Q, a #0 delay can be used to
delay the assertion further to the Inactive region as illustrated in this slide. Using
the #0 delay, the order that the non-blocking events no longer matters and the
assertion can be guaranteed to always sample its inputs and evaluate at the correct
moment in simulation time.
For older simulators that do not implement the non-blocking trigger construct, the
following could also be used:
always @(posedge Reset)
myReset <= Reset;"
always @(posedge myReset)
#0 assert( Q == 0 );"
18
19. Clocking blocks can also be used for delaying immediate assertion input sampling.
When an “input #0” is specified in a clocking block, the inputs are sampled in the
Observed region. Using the clocking block then means that the inputs are always
sampled after the design has finished updating.
Unfortunately, clocking blocks do not give the same results in all simulators the first
time Reset occurs. Since System/Verilog indeterminately executes processes, a race
condition may exist between when the assertion reads the clocking block variable
and when it gets updated, resulting in an X for Q the first time Reset occurs. To
solve this, it is usually adequate to wait on the clocking block.
19
20. Immediate assertions generally do not allow us to use the SVA temporal syntax that
we get with concurrent assertions. Concurrent assertions are limited by the standard
on when they can sample their inputs---inputs must be sampled in the Preponed
region. However, there are 2 workarounds that we can consider.
20
21. The first way to make a concurrent assertion work is to delay the sampling event. A
simple concurrent assignment with a #1 delay is adequate enough to delay the input
sampling long enough for the asynchronous assertion to evaluate correctly. Of
course, some might object that this is not much different than sampling with a clock
because there is a possibility of glitches between the asynchronous event and the
actual check. However, a #1 delay should be small enough to not worry too much
about this. While not exactly standard, some simulators support using #1step in an
assignment, which essentially delays the assertion evaluation to the Postponed
region and removes the possibility of missing any glitches. One major simulator
(Modelsim/Questasim) supports #step instead.
21
22. Another way to delay input sampling is by calling a task or function in a concurrent
assertion. The SystemVerilog standard states that subroutines called in a sequence
are to be evaluated in the Reactive region. By using a ref on a task argument, the
current value is sampled in the Reactive region. Unfortunately, not all simulators
treat functions the same as tasks so a workaround is to not pass the thing to be
sampled as a function argument but to simply sample it within its declarative scope
inside the function. Since the signal is not an argument, it is not an assertion input
and not sampled in the Preponed region but in the Reactive region---the region of its
evaluating context.
22
23. Delaying the input sampling for assertions works great for RTL simulation, but what
happens when timing delays are inserted in a gate-level simulation? Now of these
assertions would work because the RTL does not change on the same time step as
the asynchronous event.
Instead, our assertions need to wait for the asynchronous event and then watch for
the design to change before checking. We could use a multi-clocked sequence as
shown above to wait for the design to update.
However, what if Q was already 0 so @Q never evaluates because there was no
value change? It could be qualified using a conditional statement, but there still
exists 2 problems: (1) there is the same sampling issue of Q when @Q occurs since
the input is sampled in the Preponed region, and (2) how can it guaranteed that Q
changed because of Reset event that triggered it? What if Q did not change from
Reset but when the counter started counting again? Even if it is qualified with Reset
being high, Q might not change until a future Reset event and not the current one.
23
24. The best solution to this problem is probably a compromise using a multi-clocked
sequence with Reset and the Clock. The assertion will trigger asynchronously when
the Reset event occurs, but then Q is sampled using the Clock to ensure that it
eventually updates while under Reset given a window of time specified by some
timeout constant. This makes it easy to change the assertion to compensate for gate-
delays with the gate-level netlist, to ensure that Q changes within an acceptable
window of time, and that Q actually responses to the corresponding Reset event.
24
26. Here are some guidelines to follow when handing asynchronous behaviors with
SVA …
26
27. For more information on writing asynchronous assertions, please see the following
paper:
Doug Smith. “Asynchronous Behaviors Meet Their Match with SVA,”
DVCon Proceedings, February 2010.
This paper describes in detailed what is presented here, plus discusses how to handle
asynchronous communication using multi-clocked sequences. The full paper can be
downloaded from the Doulos website (www.doulos.com).
27
