• 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. nccovdut option : Can it have more than 1 option?

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 65
  • Views 14186
  • 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

nccovdut option : Can it have more than 1 option?

Pooja
Pooja over 16 years ago

Hi,

      I use ncverilog and the DUT for which am working on currently has a seperate Tx top and a seperate Rx top,

and it  does not have a common top level or rather the design team wants to keep the Tx and Rx seperate.Now I

want code coverage for Tx as well as Rx,is it possible to have 2 arguments to the nccovdut switch? Meaning

can we have +nccovdut+xyz_tx_top+xyz_rx_top in the makefile? Please let me know your thoughts as to how can  i

get code coverage of Rx and Tx wherein I have them as seperate modules and also don have the luxury to put

them together in a top level design file?

  • Cancel
Parents
  • Mickey
    Mickey over 16 years ago

    Hi Pooja,

    I would recommend leaving your current covdut option as is (+nccovdut+tx_mod +nccovdut+rx_mod).  When you pass the wildcarp key (*) to the report_html command the report will include the coverage for all modules hierarchically below and including the tx_mod and rx_mod module.  Although you could pass the test as the covdut, that could lead to confusing results when reporting the results because the user would have to remember that the cov database includes stats from the test.

     

    Be aware that since there is no specification on whether the report should be a module or instance report, the default will be a module report.  This means that the coverage numbers for all instantiations of a given module will be combined to provide the total coverage for that module.  So your report currently does include coverage data from both the tx and rx instance trees.  However the report is being done on a module basis, so common modules found under both of those trees are combined to provide the total coverage results for any module.

     

    Perhaps your intent is to capture the coverage results on an instance basis.  In an instance report the tool will report the specific coverage for each instance as well as the cumulative overage stats for all instantiations found hierarchically below a given instance.  To output an instance html report add -instance to the output command as will as *...  The "*" is a wild card to specify all modules at the top level and the "..." means to also include all instantiaions below those top instances.  So your command for an html instance report will be : 

    iccr> report_html -instance *... > myreport.out

     

    By the way if you would like more information on any command within iccr you can simply type in help along with the command name within iccr.  For example the help for the report_html command details the defaults for the command as well as other options that can be included.  The help for that command can be brought up as follows:

      iccr> help report_html

    Please let me know if that helps.

    Best regards,

    Mickey

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Mickey
    Mickey over 16 years ago

    Hi Pooja,

    I would recommend leaving your current covdut option as is (+nccovdut+tx_mod +nccovdut+rx_mod).  When you pass the wildcarp key (*) to the report_html command the report will include the coverage for all modules hierarchically below and including the tx_mod and rx_mod module.  Although you could pass the test as the covdut, that could lead to confusing results when reporting the results because the user would have to remember that the cov database includes stats from the test.

     

    Be aware that since there is no specification on whether the report should be a module or instance report, the default will be a module report.  This means that the coverage numbers for all instantiations of a given module will be combined to provide the total coverage for that module.  So your report currently does include coverage data from both the tx and rx instance trees.  However the report is being done on a module basis, so common modules found under both of those trees are combined to provide the total coverage results for any module.

     

    Perhaps your intent is to capture the coverage results on an instance basis.  In an instance report the tool will report the specific coverage for each instance as well as the cumulative overage stats for all instantiations found hierarchically below a given instance.  To output an instance html report add -instance to the output command as will as *...  The "*" is a wild card to specify all modules at the top level and the "..." means to also include all instantiaions below those top instances.  So your command for an html instance report will be : 

    iccr> report_html -instance *... > myreport.out

     

    By the way if you would like more information on any command within iccr you can simply type in help along with the command name within iccr.  For example the help for the report_html command details the defaults for the command as well as other options that can be included.  The help for that command can be brought up as follows:

      iccr> help report_html

    Please let me know if that helps.

    Best regards,

    Mickey

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

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