I'm sure this is a frequently asked question (FAQ)
When we turn on SVA in our simulations, some of our long-running concurrent assertions are triggering failures at the end of the simulation. It appears the assertion triggered, but the simulaiton $finish before the assertion had a chance to complete (either vacuously-succeed, or normal succeed.)
When the assetoin-report is issued, these 'dangling' assertions are classified as failures.
Is there a way to change the report, or change the assertion-behavior so dangling-assertions are not reported as failures?
IUS uses "strong" semantics when evaluating SVA sequences. If the enabling conditionof a sequential assertion has been satisfied, but it is incomplete at the end ofsimulation, IUS reports it as a failure. To see these failures in the assertionsummary, you must use the "-final" option to the Tcl "assertion" command: assertion -summary -finalYou can use the following Tcl variable to turn off the use of these strongsemantics for both SVA and PSL assertions:set assert_report_incompletes 0
In reply to Mickey:
It seems like I should have read the manual more carefully!
that was exactly what I was looking for!
In reply to cubicle82:
SVA failures can be a bit confusing like this, especially if you're used to PSL.
In SVA, all assertions are defined as "strong" meaning that they must finish before the end of simulation, else they fail at the end of simulation. In PSL you have a choice of the default "weak" assertion which won't automatically fail at the end, or you can use the "!" operator to force an assertion to be strong.
Another thing you may see (at least, I've nearly tripped over it a couple of times) is that classic thing of looking a the bottom of the screen and reading the first error that you see on the screen. If you see an SVA assertion has failed at the end of the sim, and you think it is a bit weird, then your first reaction needs to be to scroll up through the log to look for some other thing that has terminated the sim.
For example in an OVM testbench, did some class-based check terminate with a dut_error()? If so, you'll see that message much further up the log compared to any final (and spurious) SVA failures...
All good fun, I suppose ;-)
Thanks it is very useful information. But I wonder if there is a way to selectively say which assertions need to be strongly evaluated and which assertions to be weakly evaluated?
In reply to araju:
In the 2012 version of the SVA LRM, the IEEE changed the default behavior of assertions to weak. The Incisive 13.2 release matches that change. By default, all SVA assertions start as weak. The SVA language added a keyword, "strong" to identify sequences that have to finish before the simulation ends.
assert property ( @(posedge clk) $rose(request) |-> strong ( ##
So if you can switch to 13.2, you can get the individual control that you are asking for.