Assertion System Functions and Tasks - SVA: The Power of Assertions in SystemVerilog - page 150

7.3 Tasks for Controlling Assertions and Runtime Violations

During the course of development, assertions often fail because the code is
incomplete or is in the process of getting fixed. Such failures are impediments
to development, particularly when the developer is well aware of the causes of
the failures. This section describes the system control tasks to control assertion
executions, assertion action block executions, expect statement execution and
run time violations for unique , unique0 and priority . Using these tasks, the
developer can selectively turn off assertion or other monitoring checks until the
code is brought to a state where the tests can actually be exercised.
Section 7.3.1 describes tasks for controlling assertion evaluation attempts.
Section 7.3.2 describes tasks for controlling action blocks. Section 7.3.3 describes a
more generalized task $assertcontrol to control both assertion execution as well
as action block execution.

7.3.1 Tasks for Controlling Evaluation Attempts

It is often necessary to stop the evaluation and reporting of unwanted assertion
failures during special initialization, power down, or reset operation phases of the
design under verification. If there is some Boolean expression that characterizes
such a phase, then the expression can be used in a disable iff clause in
subsequent assertions to disable assertion failures during those phases. For other
situations when a testbench initializes the design, the assertions can be disabled
explicitly by using assertion control tasks :
￿ $asserton
￿ $assertoff
￿ $assertkill
By default all assertions are enabled from time 0. To stop the start of any attempts
from time t , it is sufficient to call $assertoff before the Observed region of the
simulator at time t . This, however, does not stop any evaluation attempt that has been
started earlier. To restart the evaluation, at some later time t 0 ,thetask $asserton is
called.
Therefore, to avoid executing all assertions during the initialization phase,
$assertoff should be called from the testbench at time 0, followed by $asserton
when exiting the initialization phase. This is illustrated in the following example.

Example 7.34.
module m;
bit clk;
default clocking ck @( posedge clk); endclocking
a: assert property ( ... );
initial begin
$assertoff();