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, 135 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 - How to do verification coverage?
     Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Private MessagesPrivate Messages   Log inLog in 

    How to do verification 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
    Newsletter
    Original Contribution


    Joined: Dec 08, 2003
    Posts: 1107

    PostPosted: Wed Dec 17, 2003 5:52 pm    Post subject: How to do verification coverage? Reply with quote

    (Originally from Issue 4.19, Item 10.0)

    From: Oki

    I want to know how to calculate verification coverage, who can help me?
    Back to top
    View user's profile
    Newsletter
    Original Contribution


    Joined: Dec 08, 2003
    Posts: 1107

    PostPosted: Mon Jan 05, 2004 10:39 pm    Post subject: Reply with quote

    From: Jeff Cartwright

    I think of verification coverage as a two step process. First, you
    want to have some measure of functional coverage, and second you want
    to have a measure of code coverage. Functional coverage is usually
    measured via monitors. A monitor is part of your test bench, and it
    records events as they occur. If you use a language like e or vera,
    you will have to write the monitor. In your test plan, you should
    identify the functional aspects of the design to measure. You should
    write tests to exercise these functions, and develop monitors to catch
    the events as they occur. Today, many simulators have options to
    automatically measure RTL coverage.

    In both cases, coverage is measured as a percent of the items hit by
    all of the tests divided by the total number of items (e.g., RTL lines
    hit/total lines of RTL).

    At Obsidian we have a tool which generates assembly code sequences to
    test processors. To test a processor, the verification engineer first
    writes a test plan, identifying the functional areas to cover. Next,
    the verification engineer writes the test bench. Using Obsidian's
    RAVEN tool, the engineer develops a series of test templates to
    exercise the functional aspects of the design. RAVEN generates tests
    from the templates, and the tests are run on an RTL simulator. The
    simulator provides RTL coverage information. An add on tool to RAVEN
    measures functional coverage by scanning the generated tests. An
    iterative process is used to develop more functional tests, or to
    target RTL that has not been exercised.

    Jeff Cartwright, VP Business Development
    Obsidian Software
    Back to top
    View user's profile
    Anders
    Industry Expert
    Industry Expert


    Joined: Jan 12, 2004
    Posts: 35
    Location: Ottawa, Canada

    PostPosted: Mon Jan 12, 2004 9:54 am    Post subject: How to do verification coverage? Reply with quote

    Another important aspect of verification coverage is structural coverage. Structural coverage refers to design independent hardware behaviour such as a FIFO full or empty signal, interrupt signals or arbiter request and grant signals. One way to measure structural coverage is to use assertions. They of course have the additional benefit of helping verify and debug the design as well.
    Start by writing a number of RTL assertions such as:
    - FIFO write and FIFO full are mutually exclusive
    - FIFO empty and FIFO read are mutually exclusive
    - Only one arbiter GNT may be asserted at the same time
    If these conditions occur during any simulation the assertion will highlight the error but if the assertion is never violated you don't know why. Is it because the design is correct or because that particular case was never simulated?
    There are several ways of implementing structural coverage using assertions. You can use the cover keyword in PSL or SystemVerilog and write your own list of conditions that should be exercised during simulation or you can use a library based approach such as 0-In's CheckerWare which collect statistics on the status of all assertions.
    By examining the result of the assertion monitors after the simulation you will find valuable information such as a FIFO was never full or that only one request to an arbiter was tested and you can then modify your tests to cover these holes.

    Regards,

    Anders Nordstrom
    Cadence Design Systems
    Back to top
    View user's profile
    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.18 Seconds