If I use $assertoff to globally disable SVA, does this mean the assert() is not run at all? Or only that the action/fail-blocks are skipped?
I’m asking, because inside the assert() expression, I call functions which perform critical actions, then return a status-code.
function bit do_important_stuff( input bit flag_1 );
// do critically important stuff
fork
spawn_process_server;
join_none
if ( successful )
return 1;
else
return 0;
endfunction : do_important_stuff
initial begin : main
// setup
...
// Trigger the loop, and check the result, too.
assert ( **do_important_stuff( 1'b1 )** == 1 ) else
$fatal( 1, " FATAL_ERROR, please debug!" );
// do more work, dependent on important_stuff running in background.
end
…
So if I install a $assertoff, will that prevent do_important_stuff() from ever executing?
The LRM is not very clear on this, although it seems that $assertoff was written with only concurrent assertions in mind. There are a number of open issues to clarify this, but it may take a few years for the IEEE to get to it.
In any case, if you write all of your testbench code in classes residing in packages, you can easily avoid this issue by giving an argument with $assertoff that specifies top level module. i.e. $assertoff(0,top);
Then, none of the assert statements within the package would be affected by $assertoff, regardless of the outcome of the LRM clarification.,
Dave
Dave
Thanks for the response.
I ran an experiment in (Cadence) IUS 6.2s004, based on code similar to my example. $assertoff disables the ‘action’ block (both the PASS and FAIL blocks.) But the assert() expression still evaluates properly.
initial begin : main
...
assert( my_function( x, y) )
$display("GOOD, passed!"); // $assertoff disables this action
else
$fatal( 1, "Cannot continue!" ); // $assertoff disables this action
end : main
As you can see, I only ran immediate-assertions: I didn’t try concurrent-assertions.