Hardware Reference
In-Depth Information
14.8
Procedural Checker Instances
Checkers are generalizations of concurrent assertions that also serve as containers
for verification code that supports the assertions. As such, it is desirable to be able to
instantiate checkers wherever concurrent assertions can be written, including within
procedures. Supporting this capability comes with some challenges to define how
various checker constructs interact with the surrounding procedural context. The
instantiation rules formulated for static checker instances hold also for procedural
checker instances, but there are additional rules applicable to procedural instances,
as well as considerations for their effective use. These are the subjects of this section.
Static Assertions
Static assertions in a checker declaration (i.e., those checker assertions that are not
in the scope of any checker procedure) become procedural assertions as the result
of a procedural instantiation of the checker.
Example 14.26. Assertion a1 is static in checker check1 :
checker check1(a, event clk = $inferred_clock);
a1: assert property (@clk a);
endchecker : check1
The instantiation c1 of checker check1 in module m
module m( input logic clock, b, en, ...);
// ...
always @( posedge clock) begin
if (en) begin
// ...
check1 c1(b);
end
end
endmodule :m
is conceptually 3 equivalent to
module m( input logic clock, b, ...);
// ...
always @( posedge clock) begin
if (en) begin
// ...
a1: assert property (@( posedge clock) b);
end
end
endmodule :m
That is, the static assertion a1 in checker check1 behaves as a procedural assertion
in checker instantiation c1 in module m .
t
3 We use the term “conceptually” because of the hierarchical assertion naming in the checker, as
explained in Sect. 9.3.2 .
Search WWH ::




Custom Search