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

￿ Process, which is previously suspended due to a wait statement or an event
control, resumes after its wait statement or event control is enabled.
￿ Process is retriggered due to a value change of a variable in its sensitivity list.
￿ Process is explicitly disabled using the disable statement.
Since the deferred assertions are glitch-free, they are the preferable way
to express unclocked Boolean assertions in RTL. However, when the code has
event controls, the behavior of deferred assertions becomes unintuitive, and it may
result in missed failure reporting.

Do not use deferred assertions when the code has delay controls. Use
immediate assertions instead.

Use final deferred assertions instead of observed ones except when the action
block is required to execute some action that is not allowed in the Postponed
region.

Final deferred assertions are more robust in that their reporting will not change
when a portion of a module-based design is replaced by more abstract model in a
program. For example, as illustrated by the replacement of module mod1 in Fig. 4.5
by a program prog in Fig. 4.6 .

4.3.2 Deferred Assertion Actions

The complex bookkeeping of deferred assertions explains the restriction imposed
on their actions that they may consist only of a single subroutine call. A subroutine
in SystemVerilog can be either a task or a function .
Example 4.3. The following observed deferred assertions are legal:

int err_cnt = 0;
task err( bit a, b, string s);
err_cnt++;
$error("%s failure: a = %b,b=%b",a,b);
endtask
da1: assert #0 (a == b)
else err("da1", a, b);
da2: assert #0 (a == b) $info("a and b have value %b", a);
da3: assert #0 (a == b) $info("a and b have value %b", a);
else $error("da3 failure:a=%b,b=%b",a,b);
da4: assert #0 (a == b);