Thanks Michael,

Since I want to reiterate my kudos to Joao and the guys, I included Michael's below (read it again :-)!).

Now for the discussion. A1 has stimulated my thought on one important and crucial aspect in mind...

A1_BT)

- I would like to tweak A1 a bit to say:How can we discuss an (3rd party or user C/C++ code) coverage interface -without- actually having the ability in the SV language itself to define: "coverage_def", "state", "trans" etc... May be I am wrong (Joao, Ghassan correct me) but it seems the VeraLite donation does -not- include the "Functional Coverage" of Vera (from where I got the keywords above...). As it stands, I do not think any of the other subcomittees (BC/EC) are tasked to do this. So it seems pointless to define an access API without the objects being in the language to begin with (again if indeed what I say is correct) !!!! - I know a similar argument had been used -erroneously- for assertions. Fact is for assertions, SV 3.0 already has what we worked on (SV-AC) at the time to define -all- of the objects, and also the -mechanisms- to be in the SV language. For coverage this is not the case, so indeed this argument applies. I wish VeraLite included that but as I see it now it does not, and SV did not in 3.0 and is not slated to have these in 3.1.

To summarize, I think the Coverage API needs to be postponed to 3.2 (In fact I would prioritize VPI (design object access to what -is- in SV) first, and then Coverage API).

- So what do we do in the meantime for "coverage" ? I suggest we put even more effort on what -is- in SV i.e. assertions, and the assertions API. Coverage can be done on the design by virtue of defining "expressions" (a.k.a. events/txps....) coupled with local/global vars etc... a good job of functional coverage can be done without necessarily needing to add specific coverage objects at this time. I really think the latter is just "sugar coating", the real power is in the assertions themselves, so let'd do a good job of interfacing to 'em.

A*_BT) Give me morre time to think about the rest :-), although the rest are implementation/clarification issues that become moot in light of A1_BT.

-Bassam.

Michael Rohleder wrote:

Hi all,

this is just an attempt to inject some more discussion about the coverage donation. I am unsure whether I understood everything, so it might also be a good cross-check to identify mismatches between my believes and the reality. This is a good chance for Joao to clarify any wrong idea or silly statement I am making here due to some misunderstanding on my side.

In general I would like to thank Joao and his team for all his effort w.r.t. this work. I think this is an important topic we should cover within SystemVerilog soon. On the other side I am unsure whether the current donation is sufficient as a basis for further work in this direction. Most of the comments in this email are targeted for getting clarification on this.

Joao, you might want to help me [and hopefully others] to form their opinion until friday. Hope this starts a lively discussion ...

Best regards, Michael

A) General comments:

A1) This is probably a discussion where we should also include sv-bc/ec: This donation implicitely defines also some new SV keywords/commands ($cm_coverage, $cm_get_coverage, $cm_get_limit). Can we and how do we want to handle such additions?