• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Functional Coverage in Transaction Class

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 64
  • Views 14738
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Functional Coverage in Transaction Class

archive
archive over 18 years ago

Hi all,

When do data-oriented functional coverage, can we put the covergroup in transaction class directly? And is there any short guideline how to do?

For example,
I have transaction define class like:
//-----------
class video_pkg_c;
      rand bit [7:0]  opcode_1;
      rand bit [7:0]  opcode_2;
      rand bit [15:0] data;
      //----
      // can I add covergroup here?
      //----
endclass

class video_pkg_driver;
      ... ...
      video_pkg_c video_pkg;
      video_pkg = new();
      rand_result = video_pkg.randomize();
      ... ...
endclass
//-----------

I use IUS583.

Best regards,
Davy


Originally posted in cdnusers.org by davyzhu
  • Cancel
  • archive
    archive over 18 years ago

    Hi all,

    When do data-oriented functional coverage, can we put the covergroup in transaction class directly? And is there any short guideline how to do?
    ==================

    I would highly recommend to avoid this. This is because, coverage is
    more or less a "static" view of your verification progress and not
    truly as dynamic as the transactions themselves are. I usually create
    a separate coverage element and hook it up. Agreed there is some
    repetition in work - especially for long transaction descriptors, but
    one can automate it, write some script or use SV struct etc. to ease
    the pain.

    VMM also recommends some thing similar, it prefers to associate
    coverage with the transactors. Another rule/guideline is "cover as
    close to DUT as possible".

    This is b'cos, even though a packet got generated at a high level
    generator, perhaps due to the fact that particular port was in
    blocking mode (a random configuration setting), the packets never went
    into the DUT. This may or may not be the desired thing. By having the
    transactor tell us "when to sample" we are sure that we are covering
    at the correct place. Imagine creating 10K transactions, you don't
    need 10K coverage objects as well - you simply need a "count" of what
    kind of packets (Type, length, CRC etc.) went in and how many of them.
    This is what I refer to as "pseudo-static" item in the verification
    environment.

    The hook up of coverage class to the transactor is an interesting
    topic. In VMM one can use callbacks or vmm_channel::tee(). In AVM one
    can use analysis ports to do this. Not sure of in uRM, some thing
    similar exists there? If we had AOP, then that would help here as
    well.

    HTH
    Ajeetha, CVC
    www.noveldv.com


    Originally posted in cdnusers.org by ajeetha
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Hi,

    Covergroups in transactions are usually not recommended. Classes in SV are often copied (cloned) when propagated through your testbench, e.g. when sending to the DUT and the scoreboard at the same time. This may result in counting each sampling event multiple times.

    The correct way is sampling the coverage using a monitor which is a singleton object. It will detect the sampling event from the signals and collect the coverage only on "real" transactions that actually made it to the DUT.

    Gabi


    Originally posted in cdnusers.org by Gabi
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information