User guide

23-67
SystemVerilog Assertion Constructs
At simulation time 5 ns VCS is tracing test.a1. An attempt at the
assertion started at 5 ns. At this time VCS found req1 to be true and
is looking to see if req2 is true one to five clock ticks after 5 ns. Signal
req2 doesn’t have to be true on the next clock tick, so req2 not being
true is okay on the next clock tick; that’s what looking for “or any”
means, anything else than req2 being true.
5ns: tracing "test.a1" started at 3ns:
trace: req1 ##1 anylooking for: req2 or any
failed: req1 ##1 req2
The attempt at the assertion also started at 3 ns. At that time VCS
found req1 to be true at 3 ns and it is looking for req2 to be true some
time later. The assertion “failed” in that req2 was not true one clock
tick later. This is not a true failure of the assertion at 3 ns, it can still
succeed in two more clock ticks, but it didn’t succeed at 5 ns.
5ns: tracing "test.a1" started at 1ns:
trace: req1 ##1 any[* 2 ]looking for: req2 or any
failed: req1 ##1 any ##1 req2
The attempt at the assertion also started at 1 ns. [* is the repeat
operator.
##1 any[* 2 ] means that after one clock tick, anything
can happen, repeated twice. So the second line here says that req1
was true at 1 ns, anything happened after a clock tick after 1 ns (3
ns) and again after another clock tick (5 ns) and VCS is now looking
for req2 to be true or anything else could happen. The third line here
says the assertion “failed” two clock ticks (5 ns) after req1 was found
to be true at 1 ns.
The $assert_monitor_off and $assert_monitor_on system
tasks turn off and on the display from the $assert_monitor system
task, just like the $monitoroff and $monitoron system turn off
and on the display from the $monitor system task.