By David Solórzano. ASIC verification engineer at Rydev
david.solorzano@rydevinc.com
Let’s face it, VCS and Verdi are awesome tools but, precisely because of all their power and extensive features, sometimes the path to unleash all of their under-the-hood capabilities it’s not straightforward. Here are a few tricks that I found out come in handy in generating specific coverage reports.
Coverage
All Synopsys tools provide switches to limit the scope of the coverage collection/analysis. For instance, in VCS, one can easily limit the coverage collection in a particular scope by using the -cm_hier <filename>. This option limits the scope of the compilation for coverage for line, condition, FSG and toggle using the provided configuration file
On can also constrain both Verdi and URG to limit the coverage scopes generated in a report by using the -hier <filename>, which limits the scope of the report generated
Configuration/scope file
Synopsys provides the following statements to include or exclude a scope from coverage in VCS. All options can be used with either a (-) or a (+) to include or exclude from the scope. If no (+) is provided the global scope will be used, otherwise it will limit the scope to all (+) options.
Statements
[-/+]tree instance_name [level_number]: exclude/include an instance and the instances under it, the level can define. By default 0 is used (all levels below it).
[-/+]module module_name | entity_name: exclude/include a module type and entity name can be provided.
[-/+]file file_name: exclude/include a file from coverage.
[-/+]filelist file_name: exclude/include the files in the provided filelist.
[-/+]library library_name: exclude/include a library.
[-/+]moduletree module_name [level_number]: exclude/include a module type and instances below it. The level can be provided, 0 is used by default.
[-/+]node: exclude/include a signal from coverage
Examples:
+tree fc_top.this_design_dut
Only generates coverage for the DUT named this_design_dut within the fc_top fullchip hierarchy
-moduletree this_design_xbar
Excludes the switch_xbar module from coverage
-tree fc_top.this_design_dut.inst_myr_cclk_pll
Excludes a particular IP from coverage. Here, the inst_myt_cckl_pll IP module
Wild cards
These statements also support wild cards, numerical ranges, and alternative lists. Supported wildcards are *, ? and +. Here are some examples provided by Synopsys:
Numerical ranges: -node DUT{1..50}.inst{1..50}.a*
Alternative list: -node DUT1.inst1.b2.d7.{ab|mn|z}*
Limitations:
– Wildcards are not supported for file and library statements
– Excluding and excluding bit-selected signals with numerical range is not supported for node exclusion.
Begin end blocks
The configuration file also supports begin end blocks to specify which types of coverage are compiled for each scope. Supported options are:
line, cond, fsm, tgl and branch.
Solvenet states that assert is supported but, in my case, I haven’t been able to get it to work it when creating URG reports.
Examples:
begin line+tgl+cond -module bdev end
begin cond+line -library gate end
begin tgl -tree TOP.D1.L* end
I hope these examples from my particular experience are useful for you.
References
https://spdocs.synopsys.com/dow_retrieve/qsc-t/vg/VCS/T-2022.06-SP2/vcs_olh/index.htm#page/Coverage_Technology_Reference_Manual/command_ref.2.53.htm#wwconnect_header
https://spdocs.synopsys.com/dow_retrieve/qsc-t/vg/VCS/T-2022.06-SP2/vcs_olh/index.htm#page/Coverage_Technology_Reference_Manual/command_ref.2.54.htm#wwconnect_header