Enabling and Disabling Assertions

Many times, assertions need to be disabled based on the test or during the simulation. For example,   some assertions are not really valid before reset(not counting disable iff feature of assertion property) and you might want to switch off those assertions. Similarly, the case when there is mode transition you might want to switch off certain assertions till transition is complete and then re-enable.

There are different methods to enable and disable assertions. Below explanation summarizes it

1) Use of $assertoff and $asserton system Verilog tasks

$assertoff is used to switch off assertions. We can use this systemverilog task anywhere in the testbench like classes, modules etc including UVM tests, sequences, driver, initial block of a module.

Syntax:

$assertoff[("levels" [,"hierarchical path to instance of modules or assertions "];

Where

"levels" is an optional argument which specifies the hierarchy levels below the instance name(next optional argument)

"hierarchical path to an instance of modules or assertions"> is an optional argument indicating an instance of module or assertions to be turned off

Ex- let's say,  top is the name of the top level of the testbench in which design instance mydut is instantiated. Design instance has fsm_logic instance.

$assertoff(0,top);

Level 0 => All assertions in module top and below in the hierarchy to be turned off. This essentially switches off all the assertions inside the design as the module top is the top of the testbench including the ones inside mydut and fsm_logic

$assertoff(1,top.mydut);

Level 1 => only assertions in module instance mydut will be turned off while assertions in other instances will continue to fire.

$assertoff(2,top);

Level 2 => Assertions in instance top module and one level below top module(mydut is the only module instance inside top) will be turned off.
$assertoff with no arguments turns off all assertions in all modules.
You can switch of specific assertions inside the module if the assertion has name
Ex:
Dummy property will fail if it ever fires. It is coded to fire in the first rising clock.

Use $asserton similarly with the same syntax as $assertoff

Problem with this method of enabling or disabling
• It requires the hierarchical path to module or assertion and is very painful as we go up in integration.
• Nonreusable as the hierarchy might change anytime


2) Use of Verilog Attributes to create Assertion categories and switch on/off assertions based on vendor-specific nonstandard system tasks

Attributes were created in Verilog 2001 as a way to define and attach some characteristics for tool specific usage.

Ex: While inserting DFT Mux called VISA by specific visa tool, it inserts ports with tool attribute with tool specific number
Syntax:

(* [=] *)

Where [=] is the name assigned to attribute. This constant can be string or number or both.

Simulation Vendors like Synopsis VCS provide many nonstandard tasks which will enable us with the capability to disable or enable these tool-specific features. We can categorize assertions then use these nonstandard tasks to disable or enable assertions

Ex:

(* category = 6 *)
category_example:assert property(check_something);

I have used VCS tool for simulation and hence these examples are going to be specific to VCS while the same concept can be used elsewhere with the similar approach

VCS Specific Tasks:

   Stops all assertions associated with the specified category level (an unsigned integer from 0 to 2^24– 1):

$ova_category_stop([Category number]);

  Starts all assertions associated with the specified category:

$ova_category_start([Category number]):

Note that these tasks can be used anywhere including UVM sequences, test or driver etc

The category attribute, along with $ova_category_stop and $testplusargs arguments can be used enable or disable assertions.
lets rewrite the assertion in one of the design example above with added category:

(*category=1501*)
DUMMY_ASSERT : assert property (p_dummy) `uvm_info(""design_module"", "DUMMY", UVM_HIGH) else `uvm_error("design_module", $sformatf("p_dummy failed"))

Call below function before the simulation starts anywhere in _test_base or test

function void check4sva_argument();

    int sva_category;

    if($value$plusargs("sva_disable_category_number=%0d", sva_category))

    begin

        $ova_category_stop(sva_category);

        `uvm_info(get_type_name( ), $sformatf("Turning off SVA Category=%0d",sva_category), UVM_LOW)

    end

endfunction

Formalizing SVA Categories:

There are many DUTs which might want to take benefit of this feature and the same testbench might get integrated at SOC level for reuse purpose.  There is a quite a possibility of different testbenchs end up using the same category number for different assertions which might result in a clash and hence false pass. Therefore, Formalization of these categories is must.