In reply to Vickyvinayk:
Use the assertion control. You’ll need support logic to use those controls at the appropriate timings.
$assertcontrol ( control_type [ , [ assertion_type ] [ , [ directive_type ]
[ , [ levels ] [ , list_of_scopes_or_assertions ] ] ] ] ) ;
$assertoff stops the checking of all specified assertions until a subsequent $asserton. An assertion that is already executing, including execution of the pass or fail statement, is not affected. It is equivalent to:
$assertcontrol(4, 15, 7, levels [,list])
$asserton re-enables the execution of all specified assertions. It is equivalent to:
$assertcontrol(3, 15, 7, levels [,list])
// from my book
/* Assert control Rule: The $assertcontrol provides finer granularity in how and which types of assertions are controlled. The syntax is repeated below: */
$assertcontrol ( control_type [ , [ assertion_type ] [ , [ directive_type ] [ , [ levels ] [ , list_of_scopes_or_assertions ] ] ] ] ) ;
[1] The arguments for the $assertcontrol system task are described below:
— control_type: This argument controls the effect of the $assertcontrol system task. This argument shall be an integer expression. Section 4.2.4.1.1 describes the valid values of this argument.
— assertion_type: This argument selects the assertion types that are affected by the $assertcontrol system task. This argument shall be an integer expression. Section 4.2.4.1.2 describes the valid values for this argument. If assertion_type is not specified, then it defaults to all types of assertions and expect statements (i.e., Concurrent, Simple Immediate, Observed-Deferred Immediate, Final Deferred Immediate, and expect).
— directive_type: This argument selects the directive types (i.e., assert, cover, assume) that are affected by the $assertcontrol system task. This argument shall be an integer expression. Section 4.1.4.1.3 describes the valid values for this argument. If directive_type is not specified, then it defaults to all types of directives. — levels: This argument specifies the levels of hierarchy, consistent with the corresponding argument to the $dumpvars system task (see 1800-2012 section 21.7.1.2).
If this argument is not specified, it defaults to 0 (i.e., the specified module and in all module instances below the specified module).
Example: $dumpvars (1, top); // Because the first argument is a 1, // this invocation dumps all variables within the module top; // it does not dump variables in any of the modules instantiated by module top.
— list_of_scopes_or_assertions: This argument specifies which scopes of the model to control. These arguments can specify any scopes or individual assertions. For example,
module akill; // /ch4/4.2/akill.sv
bit clk, a,b; default clocking @(posedge clk); endclocking ap_kill: assert
property (a |=> b) $assertkill(0, akill.ap_test_kill);
ap_kill0: assert property(a |=> b) $assertcontrol(5, 15, 7, 0, akill.ap_kill0);
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
** SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
…
- SVA Package: Dynamic and range delays and repeats SVA: Package for dynamic and range delays and repeats | Verification Academy
- Free books: Component Design by Example FREE BOOK: Component Design by Example … A Step-by-Step Process Using VHDL with UART as Vehicle | Verification Academy
Real Chip Design and Verification Using Verilog and VHDL($3) https://rb.gy/cwy7nb
- Papers: