Hardware Reference
In-Depth Information
4.4
Concurrent Assertions
Concurrent assertions have the same format as the immediate simple and deferred
ones, however, their action blocks are not limited to subroutine calls as in the case
of deferred assertions. The action blocks may contain any statements and their body
may have a more complex structure:
concurrent_assertion_body ::=
[clocking_event] [
disable iff
(
reset
)
] property
Here, the square brackets are not part of the syntax, they show that the corresponding
constructs are optional.
Example 4.4.
The following concurrent assertion
a1:
assert property
(@(
posedge
clk)
disable iff
(rst) a |->
nexttime
[2] b);
is controlled by clocking event
posedge
clk
and has a disabling condition
rst
.
The assertion property is
a |->
nexttime
[2] b
.
t
Like immediate assertions of any kind, concurrent assertions can be used inside
modules, interfaces, programs and checkers. They can be placed:
in
always
procedures
in
initial
procedures
standalone (also called static)—outside any procedure
For an assertion placed in either of the two procedures, it gets evaluated only
when the control point reaches the assertion statement. Commonly, an assertion is
placed in an
initial
procedure with the intention of evaluating the assertion only
once. For example, assertion
a1
checks that
ready
is low at the first tick of the
clock:
initial
a2:
assert property
(@(
posedge
clk) !ready);
In other cases, the assertion is monitored continuously: at each tick of its clock.
For example, assertion
a3
checks that
ok
is high at every tick of the clock:
a3:
assert property
(@(
posedge
clk) ok);
Or, an assertion monitored continuously can be placed in an
always
proce-
dure as:
always
@(
posedge
clk)
begin
d1 <= i1 | i2 ;
a4:
assert property
(d1 |=> i3 | i4);
dout <= f_ecap(d1);
end
Procedural assertions embedded in always procedures are discussed in detail in
Chap.
14
. Their use in checkers is discussed in detail in Chap.
9
and in Chap.
24
.
Search WWH ::
Custom Search