VCS commands ease coverage efforts & speed
simulation
Dhaval RanaSnehal Patel, - May 07, 2015
This blog talks about challenges and solutions while reusing the required functional coverage of IP at the SoC level, coverage merging issues, exclusion/removal of groups from functional coverage report, and more.
1. Coverage Generation Control
a. Control for Code Coverage Sampling
SoC level verification may not demand complete code coverage when pre-verified IPs are used in the design. Disabling the monitoring of modules/instances, which are not targeted for code coverage, helps in making the process more efficient. There are two approaches we can take.
Approach-1: VCS Compile-time option”-cm_hier <filename>”
Approach-2: System Function: $coverage_control (control_constant, coverage_type,
scope_def, modules_or_instance)
If both the approaches are implemented simultaneously on the same module/instance, then higher precedence will be given to the compile time option (-cm_hier).
We used the compile time option “-cm_hier” in existing SoC verification project, where only Chip Top module toggle coverage was required to be tracked, as all other IPs were pre-verified. The initial approach was to dump complete code coverage of the SoC RTL and then exclude code coverage of all IPs during coverage report generation. Later, we adopted a better approach of using compile time option “–cm_hier” with only Chip Top module code coverage enabled. The time difference between both the approaches is shown in Table-1 for one test case.
Machine / CPU Time (Sec) Without Code Coverage Complete SoC code Coverage Partial Code Coverage (-cm_hier)
Compilation Time (Sec) 897 1207 969
Simulation Time (Sec) 619 1024 781
Table 1 Machine time analysis of single test case
b. Control for Code Coverage Dumping
“-cm_dir <directory path>” compile/ simulation time option (For VCS) can create centralized coverage database (*.vdb) for all test cases to minimize coverage database merging effort. “-cm_name <Test name>” will create separate profile in coverage database directory.
c. Control for UVM RAL model Functional Coverage
UVM RAL model allows creation of functional coverage (cover groups per registers), during RAL model creation using ralgen/ralf. Functional coverage may not require creating cover-groups for all simulations. In case of SoC RAL model, generation of a huge number of
registers’ coverage can impact simulation performance, as it may not be required to simulate with functional coverage enabled, every time.
Figure 1 shows one of the ways to enable /disable UVM RAL model cover-groups. RAL model registers are extended from “uvm_reg”, which can be overwritten by “cust_uvm_reg”, where “new” method is customized to disable functional coverage. From top environment, all registers or individual register cover-groups can be controlled.
2. Code Coverage Mapping/Merging Control
While working at System level (SoC) verification, Module level and System level code coverage may need to merge depending on project requirement. IP level code coverage can’t merge with SoC level directly due to change of design hierarchy.
a. Module based Mapping/Merging
“–map” switch of URG allows to merge code coverage database of same block, used in two RTLs (System and Unit level). Figure 2 shows map function use case for merging two instances of same module in two different designs. One of the designs is block/IP level and the other is system level design which uses the same block/IP.
Figure 2 Module based Merging
b. Instance based Mapping using Mapfile
As shown in Figure 3, we wanted to merge only “system_top.system_core.blk2_inst.blk_inst” with block level RTL coverage, but did not want to merge coverage for
Mapfile “map_block1” and urg command to merge is shown in Figure 3.
Figure 3 Instance based Merging
c. Manual Mapping
Manual methods can also be used for mapping/merging code coverage for block and system level RTL by making same hierarchy of both, which can be done by adding wrapper in block level testbench RTL, for example:
System Hierarchy: System_top.system_core.block_inst Block Hierarchy: block_top.block_inst
Block level hierarchy with wrapper: System_top.system_core.block_inst
“-parallel” option of URG (VCS) can help to merge coverage databases in parallel if
multi-core machine is used. This is one of the useful options, if large coverage databases are required to be merged in less time.
3. Functional Coverage Exclusion Control a. Edit coverage database (.vdb) in VCS
from scratch. There are cases, when all cover-groups are not valid and hence partial reuse is required, which in turn requires exclusion of the unused cover-groups. Here, we can either simply remove unused code after porting coverage, if it is accessible or exclude cover-groups without removing any code. This approach is mainly used while reusing VIP functional
coverage. Excluded cover-groups will always visible in coverage report (.html, .vdb), but marked as excluded.
The VCS (URG) allows reset/removal of the cover group of coverage database while generating coverage database report. Figure 4 will demonstrate usage of the same. File "cov_remove_file" will carry info about cover-groups which need to be removed /reset.
Figure 4 Control coverage database Exclusion
This feature also helps in editing coverage database for assertion coverage. To do so, “assert” shall be used with assertion name and the same name is used in cov_remove_file to
remove/reset the coverage information from the coverage database.
reduce coverage closure effort as well as the resultant simulation time.
