• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Systemverilog SVA reporting in IUS: how to suppress failures...

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 65
  • Views 18151
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Systemverilog SVA reporting in IUS: how to suppress failures caused by unfinished assertions?

cubicle82
cubicle82 over 16 years ago

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?

  • Cancel
  • Mickey
    Mickey over 16 years ago

    Hi Cubicle,

    IUS uses "strong" semantics when evaluating SVA sequences. If the enabling condition
    of a sequential assertion has been satisfied, but it is incomplete at the end of
    simulation, IUS reports it as a failure. To see these failures in the assertion
    summary, you must use the "-final" option to the Tcl "assertion" command:

    assertion -summary -final

    You can use the following Tcl variable to turn off the use of these strong
    semantics for both SVA and PSL assertions:

    set assert_report_incompletes 0

    Best regards,

    Mickey

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • cubicle82
    cubicle82 over 16 years ago

    It seems like I should have read the manual more carefully!

    Thank you,

    that was exactly what I was looking for!

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • StephenH
    StephenH over 16 years ago

    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 ;-)

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • araju
    araju over 11 years ago

     Hi Mickey,

     

    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?

     

    Thanks,

    Anand Raju

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • TAM1
    TAM1 over 11 years ago

    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 ( ##

  • grant ) );

     

    So if you can switch to 13.2, you can get the individual control that you are asking for.

  • Cancel
  • Vote Up 0 Vote Down
  • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information