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.

Complete Partial
Without SoC Code
Machine / CPU Time Code code Coverage
(Sec) Coverage Coverage (-cm_hier)
Compilation Time (Sec) 897 1207 969
Simulation Time (Sec) 619 1024 781
Total (Sec) 1516 2231 1750
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.

Figure 1 Control cover-groups of UVM RAL Model

 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 cant 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
system_top.system_core.blk_inst. In this case, instance-based mapping proved useful.
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

Sometimes functional coverage is reused from VIP or legacy project, instead of developing
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.

By using the above functions and commands in SystemVerilog and the Synopsys VCS tool, one can
reduce coverage closure effort as well as the resultant simulation time.
The authors are engineers at eInfochips.