Verification Guild
A Community of Verification Professionals

 Create an AccountHome | Calendar | Downloads | FAQ | Links | Site Admin | Your Account  

Login
Nickname

Password

Security Code: Security Code
Type Security Code
BACKWARD

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Modules
· Home
· Downloads
· FAQ
· Feedback
· Recommend Us
· Web Links
· Your Account

Advertising

Who's Online
There are currently, 82 guest(s) and 0 member(s) that are online.

You are Anonymous user. You can register for free by clicking here

  
Verification Guild: Forums

 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile  ProfileDigest    Log inLog in 

SV and coverage

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Verification Guild Forum Index -> Coverage
View previous topic :: View next topic  
Author Message
elavelle
Junior
Junior


Joined: Jun 15, 2004
Posts: 9

PostPosted: Wed Aug 25, 2004 12:01 pm    Post subject: SV and coverage Reply with quote

I'm looking for any docs, examples, or info on SV coverage, particularly compared to Specman's coverage - can anyone give me any pointers?

Thanks -

Evan
Back to top
View user's profile Send e-mail
srini
Senior
Senior


Joined: Jan 23, 2004
Posts: 436
Location: Bengaluru, India

PostPosted: Wed Aug 25, 2004 12:36 pm    Post subject: Re: SV and coverage Reply with quote

elavelle wrote:
I'm looking for any docs, examples, or info on SV coverage, particularly compared to Specman's coverage - can anyone give me any pointers?

Thanks -

Evan


Evan,
If you are asking about SV as a language and its capabilities for FCOV - best would be to look at LRM, I glanced through it and having used Specman for nearly 3 yeras, I find SV quite sufficient in terms of language. Now, when it comes to implementation - I guess you need to talk to the vendors on their plans/current capacity and you know which vendor I would favor (if not, please look at my signature Smile ).

On a similar note, property/sequence coveragae is some thing that is getting more attention - thanks to upcoming standards such as SVA, PSL etc. I believe one can do this in "E" as well, but I haven't seen many using that.

Regards,
Srinivasan
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems
Back to top
View user's profile Send e-mail Visit poster's website
elavelle
Junior
Junior


Joined: Jun 15, 2004
Posts: 9

PostPosted: Wed Aug 25, 2004 1:25 pm    Post subject: Reply with quote

Hi Srini -

I've gone through the 3.1 LRM, but it's pretty dry and it's not obvious what, if anything, you can do without resorting to the API. It's also not obvious (to me) how much of the coverage functionality must be supported by vendors.

Quote:
On a similar note, property/sequence coveragae is some thing that is getting more attention - thanks to upcoming standards such as SVA, PSL etc. I believe one can do this in "E" as well, but I haven't seen many using that.


This is actually a pretty fundamental part of Specman - I'd be surprised to see many people using it without sequence and property coverage.

Evan
[/quote]
Back to top
View user's profile Send e-mail
srini
Senior
Senior


Joined: Jan 23, 2004
Posts: 436
Location: Bengaluru, India

PostPosted: Wed Aug 25, 2004 1:45 pm    Post subject: Reply with quote

elavelle wrote:
Hi Srini -

I've gone through the 3.1 LRM, but it's pretty dry and it's not obvious what, if anything, you can do without resorting to the API. It's also not obvious (to me) how much of the coverage functionality must be supported by vendors.



Hi Evan,
I am not sure what exactly you are looking for. Also, let me admit that I haven't spent quality time in exploring all possible options within the coverage definition syntax (such as WEIGHT, ignore, illegal options in E) of SV. But bottomline - you need:

items, crosses, sampling events and a GOOD API, I see all of them in SV.

Quote:

This is actually a pretty fundamental part of Specman - I'd be surprised to see many people using it without sequence and property coverage.

Evan


Well probably I didn't make myself clear, sorry about it. I meant "assertion coverage", i.e. having an "assertion" on top of a sequence/property (defined using an assertion language, I know that "E" has TEs for example). Do people often write complex TEs (of-course they do simple TEs, I tried few "detach"s and got loads of messages on "too complex, trying to simplify" kind.. hence left that excercise there itself). What I am looking for is comprehensive assertions, and coverage on them (perhaps automatically derived by the tool with a switch) details such as:

1. How many attempts were made
2. How many succeeded

(These 2 are kind of available in Specman for normal coverage groups)

3. How many vacuosuly succeeded

I might even extend the above to:

4. Ranges specified in the properties - are the corner cases covered/satisfied (req ##[1:100] ack - did I cover 1, 50, 100 ?).


Actually there is much more to this, but can't list all of them here, sorry Sad

Thanks,
Srinivasan
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems
Back to top
View user's profile Send e-mail Visit poster's website
jonathan
Senior
Senior


Joined: Jul 20, 2004
Posts: 20

PostPosted: Tue Aug 31, 2004 6:04 am    Post subject: Reply with quote

hi Srini,

Quote:
I meant "assertion coverage", i.e. having an "assertion" on top of a sequence/property (defined using an assertion language, I know that "E" has TEs for example). Do people often write complex TEs (of-course they do simple TEs, I tried few "detach"s and got loads of messages on "too complex, trying to simplify" kind.. hence left that excercise there itself). What I am looking for is comprehensive assertions, and coverage on them (perhaps automatically derived by the tool with a switch) details such as:

1. How many attempts were made
2. How many succeeded
(These 2 are kind of available in Specman for normal coverage groups)
3. How many vacuosuly succeeded
I might even extend the above to:
4. Ranges specified in the properties - are the corner cases covered/satisfied (req ##[1:100] ack - did I cover 1, 50, 100 ?).


You can certainly do all these things in 'e'.

To get success count, simply emit an event on success of a TE. As you say, events are counted automatically by the coverage engine.

The other counts seem to me to be much less interesting, but it's still easy to get them. It's not clear to me what should count as an "attempt" but if, as I guess, we are interested in "did the sequence start" then it's easy - either the start of the assertion is an event, in which case it's counted automatically, or it's a more complex TE, in which case you can add an "exec" clause to that TE so that it emits a suitable event.

Vacuous success seems to me even less interesting, but nevertheless, given an assertion (in e syntax)

expect TE1 => TE2;

it's easy to count vacuous success by counting an event that's emitted by

event vacuous is fail(TE1);

Finally, your "wouldn't it be nice if" idea about property range coverage is also easily achieved using "exec" to calculate (count) the range: something like this (not tested, not guaranteed, some declarations missing!!!)

// get sampling event for the assertion, and count occurrences
event sample is ......;
on sample { n += 1 };
// create assertion
expect ( @req => {cycle exec {start=n;};
[5..10]; @ack exec {latency=n-start}; } ) @sample;
// cover property range
cover ack is {item latency;};

However, 'e' has one really important limitation in this respect: it has no idea of a variable local to a sequence! So it can be very difficult to keep track of sequences that may have multiple concurrent instances.

I have to admit a personal (note: strictly PERSONAL!) preference here, for the Specman style in which you must explicitly code for assertion coverage, rather than the VCS style in which you get truckloads of coverage information whether you want it or not. So I'm not sure that I like the idea of automatic coverage based on a tool switch.
Back to top
View user's profile
srini
Senior
Senior


Joined: Jan 23, 2004
Posts: 436
Location: Bengaluru, India

PostPosted: Wed Sep 01, 2004 4:25 am    Post subject: Reply with quote

Hi Jonathan,
I didn't mean to say these are not possible in one language or the other, I was just clarifying my earlier post on the difference bet'n the more popular functional coverage vs. property/assertion coverage. Also, I am not sure how many real life designs use these coverage metrics as of today - though tehnically it is possible to do (as you have shown with examples).

The idea of bringing in this assertion coverage was to really understand what Evan was looking for in terms of SV + coverage - some thing that I still don't have an answer for (:-
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems
Back to top
View user's profile Send e-mail Visit poster's website
elavelle
Junior
Junior


Joined: Jun 15, 2004
Posts: 9

PostPosted: Wed Sep 01, 2004 6:28 am    Post subject: Reply with quote

srini wrote:
The idea of bringing in this assertion coverage was to really understand what Evan was looking for in terms of SV + coverage - some thing that I still don't have an answer for (:-


Well, 'functional' coverage; I don't think it's normal practice to distinguish between different forms of functional coverage. As the SV 3.1a LRM puts it,

Quote:
Broadly speaking, there are two types of coverage metrics. Those that can be automatically extracted from the design code, such as code coverage, and those that are user-specified in order to tie the verification environment to the design intent or functionality. This latter form is referred to as Functional Coverage, and is the topic of this section.


To be frank, the reason I didn't reply to your last post was that it appeared to me that you were replying in your capacity as a Synopsys rep. 'e' has had very useful coverage functionality for a long time (7 or 8 years?), but a casual reader of your post might come to the conclusion that SV had just invented it. My apologies if I misunderstood your reply.

Actually, I've largely answered my own question, by downloading the new 3.1a LRM. This added a new coverage chapter; coverage was largely ignored in the 3.1 LRM. It would still be interesting to find out which vendors intend to support the 3.1a functionality and when, and whether they'll have portable databases, and tools for analysing the databases.

[Aside: even a very cursory reading of the new chapter shows errors - the code example at the bottom of p311 contains an error, for example].

Cheers

Evan
Back to top
View user's profile Send e-mail
srini
Senior
Senior


Joined: Jan 23, 2004
Posts: 436
Location: Bengaluru, India

PostPosted: Wed Sep 01, 2004 12:15 pm    Post subject: Reply with quote

Quote:

To be frank, the reason I didn't reply to your last post was that it appeared to me that you were replying in your capacity as a Synopsys rep. 'e' has had very useful coverage functionality for a long time (7 or 8 years?), but a casual reader of your post might come to the conclusion that SV had just invented it. My apologies if I misunderstood your reply.


Evan - Thanks for taking time out to reply. I thought that could be the reason for the silence, good that we broke the stalemate. Frankly, I am looking for "technical discussion" in this forum. If I am making a paper presentation/giving tutorial I will go all out to defend my employer's products, but why in a discussion forum that's meant to be technical? Also, I personally am interested in knowing the "need" of high end design/verification engineers (like yourself) so that I can help my employer to better position itself.

If some thing is lacking, yes it is, SNPS should know (and it does know) how to tackle it Smile

Quote:

Well, 'functional' coverage; I don't think it's normal practice to distinguish between different forms of functional coverage. As the SV 3.1a LRM puts it,



Perhaps you are right, but one could argue that even code coverage is some sort of functional coverage - one writes RTL to describe functionality, a coverage on the description is (indirectly) a form of fcov.

When I was a heavy "E" user, I used to argue that fcov is "code cov. on testbench code", plus temporal sense in it.

Quote:

Actually, I've largely answered my own question, by downloading the new 3.1a LRM. This added a new coverage chapter; coverage was largely ignored in the 3.1 LRM.


There we are - I was referring to 3.1a LRM and I still defend that SV - as a language does have the "necessary" features. I would highly encourage (or request) experienced people to come out and say what's lacking.

Quote:

It would still be interesting to find out which vendors intend to support the 3.1a functionality and when, and whether they'll have portable databases, and tools for analysing the databases.


Well SV LRM has some defined API for basic querying etc. You might want to take a look at that as well. Infact I started delving into it fairly recently only and is quite interesting Smile

On "portable databases" - Ground reality: we don't even have a Binary VCD format that can be portable across simulators Smile or (:- ??

Quote:

[Aside: even a very cursory reading of the new chapter shows errors - the code example at the bottom of p311 contains an error, for example].


Isn't that expected for 2 reasons:

1. It is fairly new
2. It is just too big not to have "bugs"

Anyway, I hope I am not mistaken either by SNPS nor by general community, let's stay technical in this forum.

Thanks,
Srini
_________________
Srinivasan Venkataramanan
Chief Technology Officer, CVC www.cvcblr.com
A Pragmatic Approach to VMM Adoption
SystemVerilog Assertions Handbook
Using PSL/SUGAR 2nd Edition.
Contributor: The functional verification of electronic systems
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Verification Guild Forum Index -> Coverage All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Verification Guild ? 2006 Janick Bergeron
Web site engine's code is Copyright © 2003 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free Software released under the GNU/GPL license.
Page Generation: 0.299 Seconds