Assert Property vs Cover Property

Hi All,

Could someone please explain me when I should use ‘assert property’ and when ‘cover property’?

Is this just a matter whether the simulator will count hits and misses for each of the property? Will usage of ‘cover property’ slow down the simulation?

Thank you!

In reply to dmitryl:

Hi Dmitryl,

assert: if you want scenario to be hold true then you write an assertion.
cover : Whether scenario ever happened in your simulation or not.

In reply to cool_cake20:

If so, why not always to use both of them? ‘assert’ will check a failure of the rule/property, ‘cover’ will check whether the rule/property was ever fulfilled…

For example:

 sequence s;
    @(posedge clk) a ##1 b;
  endsequence

  property p;
    a |-> s;
  endproperty

  assert property (p);
  cover property (p);

In reply to dmitryl:

What’s usage of the ‘expect property(…)’?

The difference is that covering a property ignores the failures, and asserting a property ignores the passes. Actually, you have a choice with an assert, You may want to know that it passed at least once, and never fails.

An assertion that fails usually invalidates the entire test and all associated coverage you have collected for that test.

In reply to dmitryl:

What’s usage of the ‘expect property(…)’?
see 1800’2012 16.17 Expect statement

In reply to dave_59:

Thanks Dave! Clear, simple and understood (without referring to 1800’20xx xx.xx :-))!

In reply to dmitryl:

Dave,

  How "assert" will let us know that it is passed at least once.

In reply to cool_cake20:

It will be in your coverage report generated by your tool.

In reply to dave_59:

In reply to cool_cake20:
It will be in your coverage report generated by your tool.

Hi Dave,

Is there a way I can get the coverage info about the assertion during the simulation? I have written a cover property and during the simulation, I want to check if its covered (i.e. passed at least once). I can get such coverage info if I use covergroup but I wanted it with cover property.

Thanks,
Vinayak

In reply to VB:
That is going to be tool specific. You can do that in Questa with the “assertion count” command.

In reply to dave_59:

Thanks for the reply.

While I was browsing more on the question I asked, I came across system calls like $coverage_get using API, but I couldn’t figure out a way to implement them. Alternatively, I was also wondering if there is a way, I can set some variable or create an event the moment the defined property gets covered during runtime. I could then monitor any change in that variable to infer coverage.

While covergroup coverage can be tracked using .get_coverage, I feel it pretty lame that SV doesn’t have such a feature for cover property unless I’m missing something.

In reply to VB:
I provide an explanation in the use of APIs in my SVA Handbook.
The following is a copy of those pages.
http://systemverilog.us/sva_api.pdf
It should help

Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us

  • SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
  • A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
  • Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
  • Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8
  • Component Design by Example ", 2001 ISBN 0-9705394-0-1
  • VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
  • VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115

In reply to VB:

Just to be sure - covergroup can be correlated to “cover property” - and language does provide statistics for both. The case of “assert” is slightly more involved and interesting. Compare that to a procedural scoreboard. Now, language does NOT give a way to get coverage stats for procedural code (To some extent there is a coverage API, but have not used that a lot).

There are many interesting cases with assert properties - much like branch coverage/path coverage etc. For inst:

a |=> b |=> c;
a |=> ##[1:5] b; // Did I get b after 1,2,3,4,5 clocks? Each could be a cover item
or, intersect, within, and → operators create even more complex cases.

You may also be interested in “totally vacuous” reporting (tool dependent) https://vmmcentral.org/vmartialarts/2010/03/improved-productivity-with-vcs-assertion-indicators/index.html

Regards
Srini
www.verifworks.com

In reply to Srini @ CVCblr.com:

In reply to VB:
Just to be sure - covergroup can be correlated to “cover property” - and language does provide statistics for both. The case of “assert” is slightly more involved and interesting. Compare that to a procedural scoreboard. Now, language does NOT give a way to get coverage stats for procedural code (To some extent there is a coverage API, but have not used that a lot).
There are many interesting cases with assert properties - much like branch coverage/path coverage etc. For inst:
a |=> b |=> c;
a |=> ##[1:5] b; // Did I get b after 1,2,3,4,5 clocks? Each could be a cover item
or, intersect, within, and → operators create even more complex cases.
You may also be interested in “totally vacuous” reporting (tool dependent) https://vmmcentral.org/vmartialarts/2010/03/improved-productivity-with-vcs-assertion-indicators/index.html
Regards
Srini
www.verifworks.com

I’m not sure if I’m missing something, but isn’t the “totally vacuous” scenario already addressed by cover property, which is like a flag whether the assertion has passed atleast once?

Thanks,
Vinayak

In reply to dmitryl:

In reply to cool_cake20:
If so, why not always to use both of them? ‘assert’ will check a failure of the rule/property, ‘cover’ will check whether the rule/property was ever fulfilled…
For example:

 sequence s;
@(posedge clk) a ##1 b;
endsequence
property p;
a |-> s;
endproperty
assert property (p);
cover property (p);

When using both assert and cover on the same property, the coverage reports for the two simulators I use (Incisive and VCS) report 2 uncovered items for the same property. I find this annoying because I think I have twice as many uncovered items as I really have. For example, the report summary will say I have 10 uncovered assertions, but after I look at the details I realize I really only have 5 uncovered assertions. For this reason, I have stopped automatically adding a cover for each assert. I haven’t read anything in this good thread to convince me to do otherwise.

Perhaps other simulators or other tools (formal) use cover for different purposes.

In reply to gsulliva:

Yes, all the good tools by default report coverage for each assert property. You can use cover property when you want to collect coverage based on temporal behavior of a signal. Meaning you are not checking protocol but a certain behavior. Collecting coverage on a temporal sequence using cover property is easier than writing SV Function Coverage.

In reply to VB:

In reply to dave_59:
Thanks for the reply.
While I was browsing more on the question I asked, I came across system calls like $coverage_get using API, but I couldn’t figure out a way to implement them. Alternatively, I was also wondering if there is a way, I can set some variable or create an event the moment the defined property gets covered during runtime. I could then monitor any change in that variable to infer coverage.
While covergroup coverage can be tracked using .get_coverage, I feel it pretty lame that SV doesn’t have such a feature for cover property unless I’m missing something.

Hi VB,
I am also looking for a technique to get the same results with cover properties as we get using get_coverage() with covergroups during runtime. Could you find a way to this with cover properties?

In reply to dave_59:

Hi Dave,

I have written assertions asserted using assert property, I am looking into functional coverage now, will these assertions be included in the coverage ? or I need to make use of cover property ?

In reply to Surendra_Kumar:

https://verificationacademy.com/forums/systemverilog/assert-property-vs-cover-property#reply-49263