In reply to shilpa v:
When u say checker …does it mean another class
A checker is a new SystemVerilog construct, and has nothing to do with classes.
- Checkers
17.1 Overview
Assertions provide building blocks to validate the behavior of the design. In many cases there is a need to
group several assertions together into bigger blocks having a well-defined functionality. These verification
blocks may also need to contain modeling code to compute values of auxiliary variables used in assertions or
covergroup instances to be integrated with cover statements. The checker construct in SystemVerilog was
specifically created to represent such verification blocks encapsulating assertions along with the modeling
code. The intended use of checkers is to serve as verification library units, or as building blocks for creating abstract auxiliary models used in formal verification.
The modeling mechanism in checkers is similar to the modeling mechanism in modules and interfaces,
though several limitations apply. For example, no nets can be declared and assigned in checkers. On the
other hand, checkers allow nondeterministic modeling, which does not exist in modules and interfaces. Each
variable declared in a checker may be either deterministic or random. Checker modeling is explained in
17.7. Random variables are useful to build abstract nondeterministic models for formal verification.
Reasoning about nondeterministic models is sometimes much easier than reasoning about deterministic RTL
models.
I explain the application of 1800’2012 checkers in my SystemVerilog Assertions Handbook, 3rd Edition VhdlCohen Publishing
Below is an untested dummy model of a checker bound to an SV interface.
module rtl (
input logic clk, reset, request, ack,
input logic[7:0] data_in,
output logic[7:0] data_out);
timeunit 1ns; timeprecision 100ps;
logic done; // done is to test_rtl
// ..
endmodule : rtl
checker handshake_chk (input logic clk, reset_n, request, ack, done);
timeunit 1ns; timeprecision 100ps;
//..
property p_req_ack (clk, a, b, c);
@ (posedge clk) $rose(a) |-> ##[1:2] b ##1 c;
endproperty : p_req_ack
ap_req_ack : assert property (p_req_ack(clk, request, ack, done)) else
$display ("%m 1 Request-acknowledge failure");
endchecker : handshake_chk
interface req2send_if (input bit clk, reset_n);
timeunit 1ns; timeprecision 100ps;
logic request, ack, done; // signals belonging to interface
logic [7:0] source_data, data_out; // signals belonging to interface
// Define a clocking for the properties and IO ports
clocking reqclk @(posedge clk);
input ack, data_out, done;
output request, source_data;
endclocking : reqclk
// Define port direction for a module that sends data
modport sendmode_if (output ack, data_out, done,
input request, source_data);
endinterface : req2send_if
module test3_tb;
timeunit 1ns; timeprecision 100ps;
logic clk, reset_n, request, ack; // signals local to testbench
logic[7:0] data_in, data_out;
req2send_if req2send_if1 (.*);
// perform 2 instantiations of test_rtl, using 2 styles
rtl rtl_1(clk, reset, request, ack, data_in, data_out);
rtl rtl_2(.*);
bind req2send_if // interface
handshake_chk // cheker containing the properties
handshake_chk_1(.*); // instance of handshake_chk that contains the properties.
endmodule : test3_tb
I fail to understand the relationship of UVM configuration and assertions, particualrly since config is about classes, and concurrent assertions cannot be in classes.
Ben Cohen systemverilog.us