Hardware Reference
In-Depth Information
Checker Procedures
Straightforward inlining cannot work for checker procedures: it is illegal to have
nested procedures in SystemVerilog. One should regard checker procedures as if
they were instantiated outside the procedural code. Therefore, always procedures in
checkers are sort of screens “protecting” their contents from the procedural code at
the place of the checker instantiation.
Example 14.27.
Consider the following checker
check
instantiated in module
m
.
checker
check(a,
event
clk);
always_ff
@clk
a1:
assert property
(@clk a);
endchecker
: check
module
m(
input logic
clock, b, en);
// ...
always
@(
posedge
clock)
begin
if
(en)
begin
// ...
check mycheck(b,
negedge
clock);
end
end
endmodule
:m
This checker instantiation is conceptually equivalent to the following code:
module
m(
input logic
clock, b, en);
// ...
always
@(
posedge
clock)
begin
if
(en)
begin
// ...
end
end
always_ff
@(
negedge
clock)
a1:
assert property
(@(
negedge
clock) b);
endmodule
:m
The
always_ff
procedure in the checker screens assertion
a1
from the direct
effect of the
always
procedure in the module: assertion
a1
is controlled by
negedge
clock
and does not depend on the value of
en
. This behavior is different
from the behavior of static assertion
a1
in checker
check1
from Example
14.26
.
t
Example 14.28.
Assertion
a1
in the following checker is instantiated in the scope
of an
initial
procedure.
checker
check(a,
event
clk = $inferred_clock);
initial
a1:
assert property
(@clk
s_eventually
a);
endchecker
: check
module
m(
input logic
clock, b, en);
// ...
always
@(
posedge
clock)
begin
if
(en)
begin
// ...
Search WWH ::
Custom Search