Assertion Statements - SVA: The Power of Assertions in SystemVerilog - page 60

1 assign a = ...;
2 assign b = ...;
3 always_comb a1: assert (a == b);

Fig. 4.4 Glitch in immediate assertion

4.2.2 Simulation Glitches

The code in Fig. 4.2 is not as straightforward as it looks; the way variables a and b
get their values greatly affects the behavior of assertion a1 . Let us modify this code
by explicitly specifying the assignments of a and b . The resulting code is shown in
Fig. 4.4 where we deleted the assertion action blocks for convenience.
In this case, the continuous assignments and assertion a1 are executed in three
separate processes: each continuous assignment is a separate process by itself and
assertion a1 executes in the scope of always_comb . We had to place assertion a1
there, as immediate assertions are allowed only in procedural code. Consider the
assertion behavior at time 50. SystemVerilog does not impose any predefined order
of process execution for parallel processes such as the ones in this example, so let
us assume the following order:

￿Line 1 is executed. a is assigned the value 1, b is still keeping its old value 0.
￿Line 3 is executed. Because a and b at this point have different values, assertion
a1 fails, and an error message is issued.
￿Line 2 is executed. b is assigned the value 1.
￿Line 3 is executed again. Now the assertion passes, and no message is issued.

As a result, the user will think that the assertion failed at time 50, though
essentially it passed, and its failure was just a simulation glitch. Had we assumed a
different simulation order (Lines 1 , 2 , and 3 ), no assertion failure would be reported.
This example clearly shows that, due to their vulnerability to 0-delay simulation
glitches, using immediate assertions may be problematic. So, when should immedi-
ate assertions be used? From their simulation semantics it follows that they should
be used in the following cases:

￿ Debugging simulation results by traversing the simulation flow and detecting
situations such as glitches. However, as we pointed out earlier, immediate
assertions may only discover glitches when they manifest in simulation, and not
the real glitches in the circuit.
￿ When delay controls are specified that make the code impervious to glitches.
￿In program testbenches which observe only the stable values of design variables
because programs execute in the Reactive region set.

In all other cases, we recommend to use deferred assertions.