Hardware Reference
In-Depth Information
1 module m( input logic go, done, clock, reset,
2 logic [31:0] din, dout);
3 default clocking @( posedge clock); endclocking
4 default disable iff reset;
5 ...
6 c_seqprotocol inst1(go, done, din, dout);
7 c_seqprotocol inst2(go, done, din, dout, negedge clock);
8 c_seqprotocol inst3(go, done, din, dout, edge clock);
9 endmodule :m
Fig. 9.5
Invocations of checker c_seqprotocol
However, explicit specification of the clock and reset is redundant because they
can be inferred from the instantiation context (Lines 3 and 4 ). In instantiations
inst2 and inst3 (Lines 7 - 8 ) the clocking event must be specified explicitly
because it is different from the default one.
This example clearly demonstrates the advantages of the checker-based imple-
mentation:
￿ Checkers are instantiated “in place”, similarly to property instantiations in
assertions. They can have untyped formal arguments. Therefore, there is no need
in passing redundant information about data type and size to them.
￿ Checkers can infer clock and reset from the instantiation context
￿ Checker instantiation syntax is uniform. All information is passed to a checker
through ports. There is no need to distinguish between ports and parameters.
￿ There is no special handling of the double edge clocks. All clocks are passed as
event expressions.
￿ Checker instantiation is concise, as a result of conventions described in the
previous bullets.
￿ There is no need for explicit sampling of expressions in assertion modeling code.
The checker does the required sampling automatically.
Checkers also have the following advantages as containers of the verification
code:
￿ Checkers may accept sequences and properties as their arguments.
￿ Checkers may be instantiated in procedural code (see Sect. 14.8 ).
9.2
Checker Declaration
The checker declaration has the following syntax:
checker checker_name ( checker_formal_arguments );
...
endchecker
Search WWH ::




Custom Search