Verification Guild
A Community of Verification Professionals
Search


  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

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

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

     
    Verification Guild :: View topic - SV and coverage
     Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Private MessagesPrivate Messages   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: 442
    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: 442
    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: 442
    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: 442
    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

    Powered by phpBB © 2001, 2005 phpBB Group
    Verification Guild (c) 2006-2014 Janick Bergeron
    PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
    Page Generation: 0.23 Seconds