Coverage Technology

User Guide
M-2017.03-SP1, June 2017
Copyright Notice and Proprietary Information
© 2017 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to Synopsys,
Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use,
reproduction, modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
Third-Party Software Notices
VCS®/VCSi™ and VCS® MX/VCS® MXi™ includes or is bundled with software licensed to Synopsys under free or
open-source licenses. For additional information regarding Synopsys's use of free and open-source software, refer to
the third_party_notices.txt file included within the <install_path>/doc directory of the installed VCS/VCS MX software.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.

Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com

ii
Contents

1. Introduction to VCS Coverage Technology

Planning Coverage 7

2. Introduction to Verification Planner

Importance of Verification Planning . . . . . . . . . . . . . . . . . . . . 2-2
Introduction to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verification Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Creating a Verification Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Creating a Verification Plan . . . . . . . . . . . . . . . . . . . . . . . 2-7
Elements of a Verification Plan. . . . . . . . . . . . . . . . . . . . . 2-8
Viewing the Verification Results. . . . . . . . . . . . . . . . . . . . . . . 2-10
Tracking Project Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10

Managing Coverage Verification 13

3. Generating Coverage Metrics for Your Design

Generating Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Analyzing Design Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Contents
iii
 Compiling Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Options for Generating Coverage Metrics . . . . . . . . . . . . 3-4
Running the Simulation and Monitoring Coverage . . . . . . . . 3-5
Unified Coverage Database. . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Generating Coverage Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Using Unified Report Generator (URG) to Generate Coverage
Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Using DVE Coverage to Generate Coverage Reports. . . . . . 3-8
Using Unified Coverage API to Generate Coverage Reports 3-9
Viewing Coverage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Viewing Coverage for Protected Modules . . . . . . . . . . . . . . . 3-12
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

4. Setting Up Coverage Metrics

Overview of Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Line Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Line Coverage for Verilog. . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Line Coverage for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Condition Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Limitations With Verilog Conditional Coverage . . . . . . . . 4-16
Limitation With VHDL Conditional Coverage . . . . . . . . . . 4-17
Specifying Stable Names for Conditions in a Design . . . . . . . 4-18
Naming a Condition in a Module . . . . . . . . . . . . . . . . . . . 4-19
Advantages of Assigning Stable Names for Conditions . . 4-19

Contents
iv
 Generating El File for Condition Coverage. . . . . . . . . . . . 4-20
Specifying Tags in the Source . . . . . . . . . . . . . . . . . . . . . 4-21
Specifying Multiple Conditions in a Statement . . . . . . . . . 4-21
Specifying Multiple Statements in a Line . . . . . . . . . . . . . 4-23
Viewing Names in the Generated Reports . . . . . . . . . . . . 4-23
Limitations With Stable Names for Conditions . . . . . . . . . 4-25
FSM Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
FSM Coverage for Verilog . . . . . . . . . . . . . . . . . . . . . . . . 4-27
FSM Coverage for VHDL . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Branch Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
Branch Value Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
SystemVerilog Support for Code Coverage . . . . . . . . . . . . . . 4-44
Coverage Options and Sub-Options . . . . . . . . . . . . . . . . . . . 4-47
Mandatory Options for Generating Coverage Metrics . . . 4-47
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48
Using with Clause in Covergroups. . . . . . . . . . . . . . . . . . . . . 4-49
Coverpoint Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
Limitations With Using the with Clause . . . . . . . . . . . . . . 4-54
Writing and Configuring Test Run Metrics . . . . . . . . . . . . . . . . . . 4-55
Writing Test Run Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-56
Generating Lightweight Test Records . . . . . . . . . . . . . . . 4-56
Reporting Test Run Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61
Configuring the Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64
Test Record of a Merged Database . . . . . . . . . . . . . . . . . . . . 4-66
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-67

Contents
v
5. Merging Coverage Metrics
Serial Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Parallel Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Specifying the Number of Tests in Merging . . . . . . . . . . . . . . 5-6
Specifying Hosts to Execute Jobs . . . . . . . . . . . . . . . . . . . . . 5-7
Using a GRID Computing Engine . . . . . . . . . . . . . . . . . . . . . 5-7
Using an LSF Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Merging Covergroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Default Merging for Covergroups. . . . . . . . . . . . . . . . . . . . . . 5-9
Flexible Merging for Covergroups . . . . . . . . . . . . . . . . . . . . . 5-10
Merge Equivalence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Rules for Flexible Merging of Databases . . . . . . . . . . . . . 5-12
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Union Merging for Covergroups. . . . . . . . . . . . . . . . . . . . . . . 5-17
Rules for Union Merging of Databases . . . . . . . . . . . . . . 5-19
Reference Merging for Covergroups and Assertions. . . . . . . 5-31
Example - Covergroup Metrics. . . . . . . . . . . . . . . . . . . . . 5-32
Example - Assertion Metric . . . . . . . . . . . . . . . . . . . . . . . 5-36
Resetting the Scores of all Coverable Objects to Zero . . . . . 5-39
Toggle Coverage Reference Merging . . . . . . . . . . . . . . . . . . . . . 5-40
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
Region Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45
VDB Directory Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
Mapping Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48
Mapping Assertion Coverage . . . . . . . . . . . . . . . . . . . . . . . . 5-52

Contents
vi
 Mapping Sub-Hierarchy Coverage in VHDL . . . . . . . . . . . . . 5-53
Mapping Coverage Information From Multiple Sources. . . . . 5-54
Understanding Instance-Based Mapping. . . . . . . . . . . . . . . . 5-55
Examples of Instance-Based Mapping. . . . . . . . . . . . . . . 5-57
Mapping Assertion Coverage Using a Mapping Configuration File 5-
58
Map-Merging Assertion Coverage . . . . . . . . . . . . . . . . . . . . . 5-60
Mapping Relocated Source File. . . . . . . . . . . . . . . . . . . . . . . 5-62
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-63

6. Grading Tests for Coverage

Test Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Cost-Based Test Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Parallel Test Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Using Grading in a High-Coverage Environment . . . . . . . . . . . . 6-12
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Recommendation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Generating Graded Test List Files . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Modifying Overall Grading Scores. . . . . . . . . . . . . . . . . . . . . . . . 6-15

7. Other Coverage Post-Processing Techniques

Managing the Covergroup Coverage Database . . . . . . . . . . . . . 7-1
Editing the Covergroup Coverage Database . . . . . . . . . . . . . 7-2

Contents
vii
 Resetting and Deleting a Covergroup in Coverage Database 7-3
Resetting Hit Counts of Bins . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Deleting a Covergroup from Coverage Database . . . . . . . . . 7-5
Resetting and Deleting Assertion Coverage . . . . . . . . . . . . . . . . 7-6
Resetting Assertion Coverage . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Deleting Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Resetting the Scores of all Coverable Objects . . . . . . . . . . . 7-8

Analyzing Coverage Verification 11

8. Viewing and Analyzing Coverage Reports in Verification Planner

9. Viewing and Analyzing Coverage Reports Using DVE

Starting DVE in Coverage Mode . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
Opening a Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
Loading Multiple Coverage Tests Incrementally . . . . . . . . . . 9-9
Loading and Saving Sessions . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Saving a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Loading a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
DVE Coverage Source/Database File Relocation . . . . . . . . . 9-13
Using the Coverage GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
The Navigation Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
The Coverage Summary Map Window . . . . . . . . . . . . . . . . . 9-19
Review Flow for Unmappable Exclusion . . . . . . . . . . . . . . . . 9-20
The Coverage Detail Window . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Navigating in the Source Pane . . . . . . . . . . . . . . . . . . . . . . . 9-22

Contents
viii
 Creating User-Defined Groups. . . . . . . . . . . . . . . . . . . . . 9-22
Display Single Cover Group in Detail Pane . . . . . . . . . . . . . . 9-24
Viewing Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Viewing Line Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Viewing Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Viewing Nets and Registers . . . . . . . . . . . . . . . . . . . . . . . 9-27
Viewing Multi-Dimensional Arrays . . . . . . . . . . . . . . . . . . 9-29
Displaying Condition Coverage . . . . . . . . . . . . . . . . . . . . . . . 9-30
Viewing Condition IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31
DVE Coverage with Condition Coverage Observability . . 9-32
Displaying Finite State Machine (FSM) Coverage . . . . . . . . . 9-33
Displaying Transition Details . . . . . . . . . . . . . . . . . . . . . . 9-34
Displaying Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
Displaying Branch Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
The Branch Coverage Detail Window . . . . . . . . . . . . . . . 9-37
Viewing Implied Branches . . . . . . . . . . . . . . . . . . . . . . . . 9-39
Displaying Assertion Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
SVA Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
OVA Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
The Covers Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-43
Displaying Testbench Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 9-48
Compute Coverage Score by Ratio . . . . . . . . . . . . . . . . . . . . 9-51
Filtering Instances with No Coverable Objects . . . . . . . . . . . . . . 9-53
Working With HVP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-57
Working With Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . 9-58
Running Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-58

Contents
ix
 Filtering the Hierarchy Display . . . . . . . . . . . . . . . . . . . . . . . . 9-59
Generating URG Report From DVE Coverage GUI . . . . . . . . . . 9-60

10. Viewing and Analyzing Coverage Reports Using Unified Report

Generator
Supported Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Invoking URG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Merging Coverage Results of Several Runs of the Same
Executable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5
Merging Coverage Database Across Versions of VCS . . 10-6
Format to Display Coverage Results. . . . . . . . . . . . . . . . . . . . . . 10-7
What is Covered in Each Coverage Metric . . . . . . . . . . . . . . . . . 10-9
The Line Coverage Report . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Annotating Macro Instantiations in Line Coverage . . . . . . 10-13
The Toggle Coverage Report. . . . . . . . . . . . . . . . . . . . . . . . . 10-23
Support for Interface Signals on Port Boundary . . . . . . . . . . 10-24
Excluding Interface Signals From Design . . . . . . . . . . . . 10-28
Interface Expansion Limitations . . . . . . . . . . . . . . . . . . . . 10-29
The Condition Coverage Report . . . . . . . . . . . . . . . . . . . . . . 10-32
Condition Coverage Report Splitting for Large Number of
Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
The FSM Coverage Report . . . . . . . . . . . . . . . . . . . . . . . . . . 10-37
The Branch Coverage Report . . . . . . . . . . . . . . . . . . . . . . . . 10-38
The Assertion Coverage Report . . . . . . . . . . . . . . . . . . . . . . 10-43
Summary Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-43
Detail Report for Assertions . . . . . . . . . . . . . . . . . . . . . . . 10-45
Detail Report for Cover Sequence . . . . . . . . . . . . . . . . . . 10-49

Contents
x
 Detail Report for Cover Properties . . . . . . . . . . . . . . . . . . 10-49
The Covergroup Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-51
Viewing Results for Coverage Group Variants . . . . . . . . . 10-53
Understanding Covergroup Page Splitting . . . . . . . . . . . . 10-55
Correlation Report: Determining Which Tests Covered Which Objects
10-64
Viewing Tests for Covered Objects. . . . . . . . . . . . . . . . . . 10-66
Tests Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-75
Unsupported Arguments . . . . . . . . . . . . . . . . . . . . . . . . . 10-76
Difference Reports for Functional Coverage . . . . . . . . . . . . . . . . 10-76
Viewing the Difference Between Tests in Dashboard and Test Pages
10-78
What is Shown as Covered? . . . . . . . . . . . . . . . . . . . . . . . . . 10-79
Report for Default Mode (-diff or -diff object) . . . . . . . . . . 10-79
Report for Count Mode (-diff count) . . . . . . . . . . . . . . . . . 10-80
Unsupported Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-81
Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-81
Reporting Only Uncovered Objects (-show brief) . . . . . . . . . . . . 10-82
Brief Report for Line Coverage. . . . . . . . . . . . . . . . . . . . . 10-82
Brief Report for Condition Coverage . . . . . . . . . . . . . . . . 10-84
Brief Report for FSM Coverage . . . . . . . . . . . . . . . . . . . . 10-84
URG Support for Uncovered Only (–show brief) Feature on Selected
Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-85
Report Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-88
Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-88
Module List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-88
Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-89
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-90

Contents
xi
 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-90
HVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-91
Assertions Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-91
Module and Instance Header Sections . . . . . . . . . . . . . . 10-91
Summary Only URG Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-92
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-92
Coverage Report Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-94
Overview of URG Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-95
Common Report Elements . . . . . . . . . . . . . . . . . . . . . . . . 10-96
The Dashboard File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-98
The Hierarchy File (Design Hierarchy) . . . . . . . . . . . . . . . 10-100
The Modlist File (Design Module List) . . . . . . . . . . . . . . . 10-105
The modN File (Module Definition). . . . . . . . . . . . . . . . . . 10-108
The Groups File (Testbench Group List) . . . . . . . . . . . . . 10-111
The grpN File (Group Definition) . . . . . . . . . . . . . . . . . . . 10-114
The Tests File (Test Records). . . . . . . . . . . . . . . . . . . . . . 10-117
The Assertions File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-120
The HVP File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-124
Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-129
Performance Improvement for HTML URG Reports . . . . . . . . . . 10-130
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-130
-legacy batch_hier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-131
Design Hierarchy Page . . . . . . . . . . . . . . . . . . . . . . . . . . 10-132
HVP and HVP Problem Hierarchy Pages. . . . . . . . . . . . . 10-133
LP Hierarchy Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-134
-legacy batch_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-135
-legacy batch_test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-138
-attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-139

Contents
xii
11. Analyzing Coverage Trend Charts
Generating Trend Charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Customizing Trend Charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Modifying the Timestamp of Trend Charts . . . . . . . . . . . . . . . 11-10
Suppressing the Generation of session.xml . . . . . . . . . . . . . 11-10
Analyzing Trend Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Organization of Trend Charts. . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Top-Level Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
Navigating Through Trend Charts . . . . . . . . . . . . . . . . . . 11-15
Metric-Wide Breakdown Linkage . . . . . . . . . . . . . . . . . . . 11-16
Hierarchical Linkage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Links to Previous Sessions . . . . . . . . . . . . . . . . . . . . . . . 11-24

Closing Coverage Verification 1

12. Exclusion Management

Managing Exclusions in DVE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Using the DVE Exclusion Menu . . . . . . . . . . . . . . . . . . . . . . 12-4
Context Sensitive Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Saving Exclusions On a Module and Instance Basis. . . . . . . 12-7
Exclusion Modes in DVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Using Exclusion Files With DVE . . . . . . . . . . . . . . . . . . . . . . 12-12
You can create exclusions in DVE and save them in an exclusion
file. DVE saves exclusion files with a.el extension. The
following sections discuss the format used in the exclusion
files to exclude various coverage metrics. . . . . . . . . . 12-12
Checking the Version of an Exclusion File . . . . . . . . . . . . 12-12

Contents
xiii
 Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Exclusion State Markers in DVE . . . . . . . . . . . . . . . . . . . . . . 12-16
Understanding Review Markers in DVE GUI . . . . . . . . . . . . . 12-18
Adding Exclusion Annotations in DVE . . . . . . . . . . . . . . . . . . 12-20
Interactively Marking Items for Exclusion in the Detail Views 12-24
Filtering Coverage Objects Based on Exclusion Status . . 12-26
Excluding Multiple Objects in a Single Line . . . . . . . . . . . . . . 12-26
Excluding Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27
Exclusion Propagation in Hierarchies. . . . . . . . . . . . . . . . 12-28
Excluding Half Toggle Transitions . . . . . . . . . . . . . . . . . . 12-29
Excluding Covergroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31
Exclusion Propagation in Covergroups . . . . . . . . . . . . . . 12-33
Excluding Auto-Cross Bins . . . . . . . . . . . . . . . . . . . . . . . . . . 12-35
Excluding Toggle Coverage MDA . . . . . . . . . . . . . . . . . . . . . 12-35
Exclusion File Syntax for MDA Exclusion. . . . . . . . . . . . . 12-36
Excluding Cross-of-a-Cross . . . . . . . . . . . . . . . . . . . . . . . . . . 12-37
Using Exclusion File to Exclude Cross-of-a-Cross. . . . . . 12-37
Enhanced Syntax of Covergroup Exclusion . . . . . . . . . . . 12-40
Saving and Loading Saved Exclusions . . . . . . . . . . . . . . . . . 12-41
Loading Exclusions From an Exclusion File. . . . . . . . . . . 12-43
Loading Excluded Covered Items in Strict Mode . . . . . . . 12-45
Recalculating Coverage Scores. . . . . . . . . . . . . . . . . . . . . . . 12-46
Using Adaptive Exclusion in DVE . . . . . . . . . . . . . . . . . . . . . 12-46
Adaptive Exclusion Review Flow . . . . . . . . . . . . . . . . . . . 12-47
Enabling and Disabling Adaptive Exclusion Review Mode 12-49
Reviewing Exclusions in the Navigation Pane . . . . . . . . . 12-51
Reviewing Exclusions in the Detail Pane . . . . . . . . . . . . . 12-56
Unmappable Exclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 12-60

Contents
xiv
 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-66
Viewing Excluded Coverage Objects in URG . . . . . . . . . . . . . . . 12-67
Generating URG Reports Using Exclusion Files . . . . . . . . . . 12-68
Viewing Excluded Covergroups in URG . . . . . . . . . . . . . . . . 12-70
Synchronizing Checks Using Checksum . . . . . . . . . . . . . . . . 12-71
Line Exclusion Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-72
Toggle Exclusion Format . . . . . . . . . . . . . . . . . . . . . . . . . 12-73
FSM Exclusion Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-74
Condition Exclusion Format . . . . . . . . . . . . . . . . . . . . . . . 12-75
Branch Exclusion Format . . . . . . . . . . . . . . . . . . . . . . . . . 12-76
Assertion Exclusion Format . . . . . . . . . . . . . . . . . . . . . . . 12-77
Covergroup Exclusion Format . . . . . . . . . . . . . . . . . . . . . 12-78
Viewing Annotated Exclusions in URG . . . . . . . . . . . . . . . . . 12-82
Exclusion Annotation Syntax . . . . . . . . . . . . . . . . . . . . . . 12-82
Indicating Exclusion Status in URG . . . . . . . . . . . . . . . . . . . 12-84
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-84
Dumping Full Exclusion Files in Commented Format . . . . . . 12-88
Dumping Full Exclusion Files . . . . . . . . . . . . . . . . . . . . . . 12-89
Controlling the Hierarchy Dumped in Full Exclusion Files 12-89
Using Dumped Full Exclusion Files . . . . . . . . . . . . . . . . . 12-90
Full Exclusion Files for Coverage Metrics . . . . . . . . . . . . . . . 12-90
Full Exclusion Files for Line Coverage . . . . . . . . . . . . . . . 12-92
Full Exclusion Files for Toggle Coverage . . . . . . . . . . . . . 12-94
Full Exclusion Files for Condition Coverage. . . . . . . . . . . 12-98
Full Exclusion Files for Branch Coverage . . . . . . . . . . . . 12-102
Full Exclusion Files for FSM Coverage . . . . . . . . . . . . . . 12-104
Full Exclusion Files for Group Coverage . . . . . . . . . . . . . 12-109
Full Exclusion Files for Assertion Coverage. . . . . . . . . . . 12-114

Contents
xv
 Managing Exclusions in UCAPI. . . . . . . . . . . . . . . . . . . . . . . . . . 12-117
Excluding Coverage Objects Using Hierarchy Exclusion Files 12-117
Excluding Coverage Objects Using Object Handles . . . . . . . 12-118
Default Versus Strict Exclusion in UCAPI . . . . . . . . . . . . . . . 12-119
Using Report-Time Exclusion . . . . . . . . . . . . . . . . . . . . . . . . 12-120
Saving Exclusions in UCAPI . . . . . . . . . . . . . . . . . . . . . . . . . 12-121
Computing Checksum for Coverage Metrics . . . . . . . . . . . . . 12-121
Calculating Checksum for Condition Coverage . . . . . . . . 12-122
Calculating Checksum for Line Coverage . . . . . . . . . . . . 12-124
Calculating Checksum for Toggle Coverage . . . . . . . . . . 12-125
Calculating Checksum for FSM Coverage . . . . . . . . . . . . 12-126
Calculating Checksum for Branch Coverage . . . . . . . . . . 12-128
Calculating Checksum for Assertion Metric . . . . . . . . . . . 12-130
Calculating Checksum for Covergroup Metric . . . . . . . . . 12-131
Remapping Exclusions From the Block Level to the System Level 12-
132
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-132
-map and -elfile Options . . . . . . . . . . . . . . . . . . . . . . . . . . 12-134
-mapfile and -elfile Options. . . . . . . . . . . . . . . . . . . . . . . . 12-135

13. Constant Analysis

Filtering Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Constant Analysis With the -cm_seqnoconst Option . . . . . . . 13-8
Analyzing Assignments in Sequential Code. . . . . . . . . . . 13-9
Analyzing Signal Bits With Multiple Drivers . . . . . . . . . . . 13-11
Analyzing Continuous Assignments With Delays. . . . . . . 13-12
How Constant Analysis is Used for Coverage . . . . . . . . . 13-12
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20

Contents
xvi
 Limitations With -cm_noconst and -cm_seqnoconst Options 13-
20
Limitation With the -cm_seqnoconst Option. . . . . . . . . . . 13-24
Other -cm_seqnoconst Limitations. . . . . . . . . . . . . . . . . . 13-25
Propagating Constants Through Instance Arrays . . . . . . . . . 13-26
Rules of Port Connections in Instance Arrays . . . . . . . . . 13-26
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-28
Treating Other Signals as Permanently at 1 or 0 Value . . . . . 13-29
Specifying Instance-Specific Constant Signals in Constant
Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-31
Specifying Module-Specific Constant Signals in Constant
Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-31
Syntax of the -cm_constfile Input File . . . . . . . . . . . . . . . 13-34
Dumping Annotations for Automatically Excluded Coverage Targets 13-
41
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-43
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-46
Multiple 1-Value Constants. . . . . . . . . . . . . . . . . . . . . . . . 13-46
Bit-Select Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-48
Bit Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-48
Bit Padding For Constant File Entries . . . . . . . . . . . . . . . 13-49

14. Unified Coverage API

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Database Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
UCAPI Setup and Compilation Requirements . . . . . . . . . . . . A-6
Enabling Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . A-8

Contents
xvii
 Dynamic UCAPI Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8
Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
UCAPI Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Common Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10
Coverable Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13
Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13
Integer and Scalar Values . . . . . . . . . . . . . . . . . . . . . . . . A-14
Interval Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
Vector Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
Value Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16
Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16
Cross . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18
Stable Names for Coverable Objects. . . . . . . . . . . . . . . . . . . A-19
Naming the Next Statement in a Module . . . . . . . . . . . . . A-20
Using Stable Names for Coverable Objects . . . . . . . . . . . A-20
Specifying Tags in the Source . . . . . . . . . . . . . . . . . . . . . A-21
Multiple Conditions in a Statement . . . . . . . . . . . . . . . . . . A-22
Multiple Statements on a Line . . . . . . . . . . . . . . . . . . . . . A-23
Names in the Generated Reports. . . . . . . . . . . . . . . . . . . A-24
El File for Condition Coverage . . . . . . . . . . . . . . . . . . . . . A-25
Design Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-25
Design and Test Name . . . . . . . . . . . . . . . . . . . . . . . . . . . A-26
Tests and Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-26
Source Definition and Source Instance . . . . . . . . . . . . . . A-27
Test-Qualified Source Regions. . . . . . . . . . . . . . . . . . . . . A-37
Other Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39
Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39
Predefined Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . A-40

Contents
xviii
 Line Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-41
Condition Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-44
Branch Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-49
Finite State Machine Coverage . . . . . . . . . . . . . . . . . . . . . . . A-55
Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-60
Assertion Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-64
Testbench Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-73
Setting Hit Count on Bins . . . . . . . . . . . . . . . . . . . . . . . . . A-79
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-79
Set covdbStatusCovered . . . . . . . . . . . . . . . . . . . . . . . . . A-79
Compressed and Uncompressed Bins. . . . . . . . . . . . . . . A-80
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-81
Loading a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-83
Available Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-84
Loading Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-85
Coverage Correlation: Determining Which Test Covered an Object
A-87

Contents
xix
Contents
xx
1
Introduction to VCS Coverage Technology 1
Coverage is a measurement of completeness in the verification of a
design and an important metric of a design’s readiness for tape-out.
A comprehensive coverage model combines different coverage
technologies and metrics to ensure all valid design scenarios are
exercised and validated.

A typical verification cycle normally encompasses of four phases:

planning with verification intent, managing test runs, analyzing
results, and converging techniques for achieving coverage goal. All
these stages are pretty much iterative process communicating with
each other. Comprehensive and integrated solutions would lead to
faster and effective coverage closure.

Introduction to VCS Coverage Technology

1-1
Figure 1-1 Typical Verification Cycle

The pivotal step of coverage verification is the creation of a

comprehensive coverage model taking all aspects of a design into
consideration. A well modeled coverage model combines different
coverage technologies and metrics to ensure all valid design
scenarios are exercised and validated.

The VCS Coverage flow, as shown in Figure 1-1 is a conjunction of

various coverage metrics and techniques that you can use to design
an broad spectered coverage model. The following sections
introduce these metrics and techniques in detail along with the
methods in which they can be used effectively. The subsequent
chapters of the user guide provides further details.

Introduction to VCS Coverage Technology

1-2
Figure 1-2 Detailed Verification Flow

Planning Coverage

An essential first step of a coverage flow is to create a verification

plan. A verification plan specifies what and how to verify in a
verification cycle. The verification plan can be created and
maintained in different formats and tools, such as Excel, Word, text
or using the Verdi Planner IDE. The plan specifies coverage and
other targets with goals hierarchically - lower-level features have
goals that may be different from goals measured at higher levels of
abstraction. The quality of the verification plan has direct impact on

Introduction to VCS Coverage Technology

1-3
 how well a design is verified and the confidence level for tape-out. As
coverage and other collected data becomes available, it can be
compared with these goals to decide whether the verification target
is met. For more information on creating a verification plan, see the
segment “Planning Coverage” .

Managing Coverage Verification

This segment discusses how you can manage coverage in terms of

generating the coverage database and reports, and perform various
post-processing techniques that help improve analysis of the
coverage results, in the following chapters:

Generating Coverage Database

The prerequisite for coverage analysis is that you generate the
Coverage database containing coverage data and coverage metrics
for your design. For more information on how a Coverage database
can be generated, see Chapter “Generating Coverage Metrics for
Your Design”

Generating and Viewing Coverage Reports

This section and the next (Analyzing Coverage Verification ) section
discus how you can generate and analyze coverage reports
respectively.

The generation of Coverage reports and the analysis of the results is

an iterative process that aims at Coverage closure. VCS provides
various techniques that can be used to organize and analyze
coverage data better. This results in the Coverage report being
affected after these techniques are employed. Therefore, the usage
of analysis techniques and the generation of coverage reports
thereafter, might be a repetitive process.

Introduction to VCS Coverage Technology

1-4
After the coverage database is generated, you need to generate the
coverage reports. You can generate and view the coverage reports
using any of the following applications:

• “Viewing and Analyzing Coverage Reports in Verification Planner”

• “Viewing and Analyzing Coverage Reports Using DVE”
• “Viewing and Analyzing Coverage Reports Using Unified Report
Generator”

Analyzing Coverage Verification

After simulations have been run and coverage databases have been
created, the information from those coverage databases are
combined together to discover which targets are or are not covered.
VCS Coverage provides various analysis techniques, such as
parallel merging, exclusion (waivers), test ranking, test correlation
and random driven verification which can be used for easier analysis
and faster coverage closure.

All these techniques are discussed in detail in the following chapters:

• “Setting Up Coverage Metrics”

• “Merging Coverage Metrics”
• “Mapping Coverage Metrics”
• “Grading Tests for Coverage”
• “Other Coverage Post-Processing Techniques”

Introduction to VCS Coverage Technology

1-5
 Tracking Coverage
VCS Coverage provides a feature that lets you analyze and track
coverage trends to understand how the coverage model needs to be
updated/improvised to achieve the desired coverage goals. For
more information, see Chapter “Analyzing Coverage Trend Charts” .

Closing Coverage Verification

Once the coverage data is analyzed, it is likely that there would be

unexercised regions of a design. These unexercised regions are
coverage holes and represent areas that have not been validated.
Some of these coverage holes represent unreachable areas of code
and can be automatically excluded by VCS Coverage.

Other legitimate coverage holes require different techniques, such

as tuning constraints and creating directed tests, to fill the holes.
These techniques can be used to achieve the goal defined in the
verification plan. When the coverage model and other criteria meets
the targeted goal, the design under test can be considered signed-
off. For more details, see Chapters “Exclusion Management” and
“Constant Analysis” .

Introduction to VCS Coverage Technology

1-6
 Planning Coverage1
This segment introduces Verification Planner and provides a brief
overview on how you can use it to plan coverage in VCS, in the
following chapter:

• “Introduction to Verification Planner”

2
Introduction to Verification Planner 1
An important step of a verification project is to create a complete
verification plan and specify coverage targets. The quality of a
verification plan has a direct impact on how well a design is verified
and determines the criteria for tape-out. The following sections
discuss the importance of verification planning and how Verification
Planner aids in creating robust verification plans:

• “Importance of Verification Planning”

• “Introduction to Verification Planner”
• “Creating a Verification Plan”
• “Viewing the Verification Results”
• “Tracking Project Progress”

Introduction to Verification Planner

2-1
 Importance of Verification Planning

Technological advances have paved the way for increasingly

complex chip designs. With the increase in chip complexity, the task
of verifying these designs for correctness becomes even more
complex and time consuming. A well defined and robust verification
plan is crucial in ensuring that the design is completely analyzed and
that its verification goals and milestones are clearly defined and
tested during the verification cycle.

A well defined verification plan has the following properties:

• The design intent that needs to be verified, in other words, the

features or goals that must be verified for design accuracy.
Therefore, a verification plan identifies design requirements as
verifiable goals with a specification of how these goals will be
tested, and the metrics that will indicate the achievement of that
goal. A good verification plan is based on the intent of the design,
not its implementation.
• The milestones of each verification goal and the sign-off criteria
that clearly identifies the closure of that goal.
• Verification goals and their associated milestones tend to change
and mature during the lifetime of a project. Therefore, a verification
plan must be a living document that reflects these changes as the
project progresses towards completion.
• A verification plan must be executable, where executable means
that the plan can be annotated with live verification data from the
design verification environment. This ensures that the plan’s goals
are being compared against actual results with minimal effort. This
helps the team easily measure project progress in terms of
achieved verification goals.

Introduction to Verification Planner

2-2
Introduction to Verification Planner

Using Verification Planner, you can create and maintain a live and
executable verification plan that can be updated according to the
changing implementation of your design.

The purpose of executable verification planning is to provide a

structured way to track the desired verification of each feature of the
design. Verification Planner is a component of VCS, that helps you
enumerate verification goals and back-annotate the plan with
coverage and other verification data to keep track of the progress
made and highlight areas needing additional attention. The following
figure shows two of the supported flows - the HVP language plan
(red arrows) and the Excel-based plan (green arrows).

Introduction to Verification Planner

2-3
Table 2-1 Verification Plan Flow Using HVP Plan or Excel-Based Plan

The basic steps for creating and using a verification plan are as
follows:

• Create a plan by defining a set of features. Connect the features

in a hierarchy, grouping related features together at each level
until the top-level features are grouped into the plan itself.
Describe each feature in detail, and list the coverpoints, assert
properties, tests, and code coverage associated with verifying that
feature.
• Run tests to accumulate coverage and other verification metrics.

Introduction to Verification Planner

2-4
• Annotate the verification data back onto the verification plan.
You can create a plan directly in a text file or create it interactively
using DVE. The DVE interface allows you to load a compiled design
and drag and drop coverage targets into the plan hierarchy as you
create it, easing the process of collecting coverage targets for your
plan. For more information, see section
“Creating a Verification Plan” .

Once the plan is created, you can use DVE, URG, or spreadsheet
annotator to view the results. The reports shows the verification plan
hierarchy with the back-annotated scores of the associated
measures, linked directly to the detailed coverage reports. For more
information, see section
“Viewing the Verification Results” .

Consider the following plan:

plan myPlan;
feature Feature_1;
measure Line, Toggle module;
source = "module: logic_block_tb@**";
source = "module: top@**";
endmeasure
endfeature
feature Feature_11;
measure Line, Cond, Toggle, Branch mod_2;
source = "module: logical_block_dut@*";
endmeasure
endfeature
feature Feature_2;
measure Line, Cond, FSM, Toggle, Branch, Assert,
test, AssertResult Inst_1;
source = "instance : test_top.top1.**.**@test*";
endmeasure
endfeature
feature Feature_3;
measure Line, FSM, Toggle, Branch Measure_1;

Introduction to Verification Planner

2-5
 source = "tree: test_top.top1.tb1";
endmeasure
endfeature
endplan

After simulating the design source file, to view the report, you must
back-annotate the coverage results.For example, in URG, you can
use the following command to back-annotate the results:

% urg -dir simv.vdb -plan myPlan.hvp

URG generates a report with the plan details, as shown in the
following figure. Each of the feature names are links that show the
details for each feature.

Figure 2-1 Sample URG Report

Introduction to Verification Planner

2-6
Creating a Verification Plan

At a very high-level, a verification plan is a hierarchical structure

composed of features. Each leaf-level feature contains references to
coverage/verification targets in a design and a testbench. Features
in the hierarchy may contain references to coverage/verification
data, or may be used only to group child features logically and in a
way that can be easily tracked. In some cases, it is possible that a
plan references only test pass/fail results or higher level features that
contain only sub-features.

Creating a Verification Plan

Verification Planner supports several formats that you can choose to
create a verification plan. You should choose the format and thereby
the plan creation tool that best suits your team’s requirements. The
supported plan creation tools include:

• The interactive plan editor in DVE Coverage. This tool allows you
to graphically browse and edit your verification plan.
For more information on this, see chapter HVP Interactive Editor
in the Verification Planner User Guide.

• As a text file in the HVP format using a regular text editor. This
helps you write your verification plan in a simple language.
For more information on this, see section Reporting HVP
Annotated Results in XML Format in the Verification Planner User
Guide.

• As a spreadsheet written in the XML spreadsheet 2003 format.

For more information on this, see chapter Verification Planner
Spreadsheet Annotator in the Verification Planner User Guide.

Introduction to Verification Planner

2-7
 • As a Word document written in the XML spreadsheet 2003 format.
For more information on this, see section Verification Planner MS
Doc Annotation in the VCS MX/VCS MXi LCA Features Guide.

Elements of a Verification Plan

A typical verification plan can contain many elements, but the most
important are sources and features.

• Sources are references to verification metric score that are

measured and collected from your verification environment.
Examples of sources are functional and code coverage objects
such as covergroups, modules, instances, or the pass/fail results
of designated tests.
• Features are groups of sources and/or other features. You can
define them to correlate to the design features that you intend to
implement.
The features in a verification plan are arranged hierarchically.
Verification Planner traverses the feature sub-trees to aggregate the
feature information. First, the low-level feature information is
annotated to a plan, and then the annotated scores are propagated
up the feature hierarchy. The method of aggregation is defined in the
metric declaration for each metric being measured. For example,
Verification Planner sums up all pass and fail test results and
averages coverage scores.

Figure 2-2 shows the various elements of a verification plan and how
they are connected.

Introduction to Verification Planner

2-8
Figure 2-2 Elements of a Verification Plan

In addition to features and sources, a verification plan can also

contain attributes and goals. Attributes are data values that are
attached to features. Goals define the intended range of scores that
are expected for each metric. Another element to note is the
measure object. Measures are a linkage between a feature and a
source.

For more information on goals and measures, see the Verification

Planner User Guide.

Introduction to Verification Planner

2-9
 Viewing the Verification Results

You can view the verification Planner results using one of the
following formats:

• Interactively within the DVE editor (See chapter “Viewing and

Analyzing Coverage Reports Using DVE” ).
• URG HTML document (See chapter “Viewing and Analyzing
Coverage Reports Using Unified Report Generator” )
• Annotated spreadsheet (See chapter Verification Planner
Spreadsheet Annotator in the Verification Planner User Guide)
• Annotated Word document (See section Verification Planner MS
Doc Annotation in the VCS MX/VCS MXi LCA Features Guide.)
• XML dataset (see section Reporting HVP Annotated Results in
XML Format in the Verification Planner User Guide.)

Tracking Project Progress

Verification Planner provides the capability to track the progress of a

project through the status of the goals created in the verification plan.
Verification Planner reports scores that are failing to meet their goals
in red and scores that meet or exceed their goals in green.

The tool also allows you to incrementally adjust goals as the project
timeline moves along. For example, if you expect your coverage to
be at 50% in the second month of a project, 70% in the fourth month,
90% by the sixth month, and then 98% by the eight month then you
can override your plan goals at those times to reflect your
expectations. In doing so, you can check whether your plan is on
track by viewing the reports. If all of the score cells are green, then

Introduction to Verification Planner

2-10
you are on schedule. If any cells are red then you are falling behind
your expectations. The location of the red score cells indicate which
aspects of your plan that need more effort to meet your goals.

Introduction to Verification Planner

2-11
Introduction to Verification Planner
2-12
 Managing Coverage
Verification1
This segment discusses how you can manage coverage in terms of
generating the coverage database and reports, and perform various
post-processing techniques that help improve analysis of the
coverage results, in the following chapters:

• “Generating Coverage Metrics for Your Design”

• “Setting Up Coverage Metrics”
• “Merging Coverage Metrics”
• “Mapping Coverage Metrics”
• “Grading Tests for Coverage”
• “Other Coverage Post-Processing Techniques”
• “Analyzing Coverage Trend Charts”
3
Generating Coverage Metrics for Your
Design 1
This chapter describes how you can generate coverage metrics,
save it to a database, generate coverage reports and view these
reports in VCS, in the following sections:

• “Generating Coverage Metrics”

• “Generating Coverage Reports”
• “Viewing Coverage Reports”
• “Examples”

Generating Coverage Metrics for Your Design

3-1
Generating Coverage Metrics

To obtain coverage metrics for your design, you need to compile your
design and run simulation, as discussed in the following steps:

1. Analyze your design (MX or three-step flow)

2. Compile your design
3. Run simulation
For more information about VCS and VCS MX flow, see the VCS
User Guide and VCS MX User Guide.

Analyzing Design Files

Analysis is the first step in simulating your design. In this phase, you
analyze your VHDL, Verilog, SystemVerilog, and OpenVera files
using vhdlan or vlogan. The following are a few example
command lines to analyze your design files:

Analyzing your VHDL files:

% vhdlan [vhdlan_options] source.vhd

Analyzing your Verilog files:

% vlogan [vlogan_options] source.v

Analyzing your SystemVerilog files:

% vlogan -sverilog [vlogan_options] source.sv

For the complete usage model, see Chapter “Using SystemVerilog”
in the VCS MX User Guide.

Generating Coverage Metrics for Your Design

3-2
Compiling Design Files

You can specify the types of coverage for which you want VCS to
compile your design.To compile the design for coverage, execute the
following command:

% vcs [cover_options] [compile_options] source.v

You must add the coverage compile-time options to your regular
VCS compile command. For example, -cm line+tgl is given to
compile for line and toggle coverage. For the complete list of
coverage compile-time options, see section Compile Options for
Coverage Metrics in the Coverage Technology Reference Manual.

In the process of compilation, VCS creates a directory called

simv.vdb, that contains code, assertion, and functional coverage
data.

The -cm_dir <directory_path_name> option enables you to

specify an alternative name or location for saving the default
simv.vdb directory. If not specified, VCS automatically generates
the coverage database with the name simv.vdb or
<exe_name>.vdb where, exe_name is the argument to -o option
if included during compilation.

Note:
If you compile the design with the -cm_dir option and then move
simv.vdb to a new location, you must use -cm_dir at runtime
to point to the new location of simv.vdb.

The -cm_name <filename> option as a compile-time or runtime

option enables you to specify an alternative test name instead of the
default name. The default test name istest.

Generating Coverage Metrics for Your Design

3-3
 Options for Generating Coverage Metrics
To generate coverage metrics, use the following commands during
compile-time and runtime:

-cm <cov_metrics_name>
The arguments to the -cm option are as follows:

line
Specifies line coverage

cond
Specifies condition coverage

tgl
Specifies toggle coverage

fsm
Specifies FSM coverage

branch
Specifies branch coverage

assert
Specifies assertion coverage

You can include more than one argument using a plus (+) as a
delimiter between arguments.

For example,

% vcs source.v -cm line+tgl+branch

Generating Coverage Metrics for Your Design

3-4
The coverage for covergroup and cover property is automatically
enabled in VCS. Therefore, you do not need to specify any
commands to collect this information.

Running the Simulation and Monitoring Coverage

To monitor coverage during simulation, execute the following

command:

% simv [cover_options] [run_options]

Where,

• [cover_options] are coverage related compilation options.

For more information on compilation options, see section “Options
for Generating Coverage Metrics” .
• [run_options] are runtime options. For more information on
compilation options, see section Simulation Options for Coverage
Metrics in the Coverage Technology Reference Manual.

Generating Coverage Metrics for Your Design

3-5
 Unified Coverage Database

The Unified Coverage Database helps in simplifying data

management with a single database while at the same time
providing merge time and grade time performance. The Unified
Coverage database, as the name indicates, contains coverage data
for code coverage, functional coverage, assertion coverage and
various aspects of coverage, such as hit counts, weights,
annotations, etc.

The Unified database supports the following:

• Coverage data of all the metrics (Line, Toggle, Branch, Condition,

FSM, Assertion, and Functional coverage) is accumulated in a
single directory, simv.vdb.
• All the metrics are supported with the same post-processing tools.
URG for batch merging, grading, and reporting, DVE Coverage
GUI for interactive analysis, and UCAPI for custom developed
applications.

Generating Coverage Metrics for Your Design

3-6
Generating Coverage Reports

After the coverage database is generated, you can generate the

coverage reports using any of the following utilities:

• “Using Unified Report Generator (URG) to Generate Coverage

Reports”
• “Using DVE Coverage to Generate Coverage Reports”
• “Using Unified Coverage API to Generate Coverage Reports”

Using Unified Report Generator (URG) to Generate

Coverage Reports

URG generates combined reports for all types of coverage

information. You can view these reports organized by the design
hierarchy, module lists, or coverage groups. You can also view the
overall summary of the entire design/testbench on the dashboard.
The reports consist of a set of HTML or text files.

The HTML version of the reports take the form of multiple interlinked
HTML files. For example, a hierarchy.html file shows the
design's hierarchy and contains links to individual pages for each
module and its instances.

For more information on URG reports, see chapter “Viewing and

Analyzing Coverage Reports Using Unified Report Generator”

Generating Coverage Metrics for Your Design

3-7
 Recommended Browsers

It is recommended that you use one of the following browsers to view

the URG HTML reports:

• Internet Explorer 10 or later versions

• Firefox 16 or later versions
• Chrome 22 or later versions

Using DVE Coverage to Generate Coverage Reports

Discovery Visualization Environment (DVE) is a comprehensive

visualization environment, which integrates with the design
hierarchy display.You use DVE to view the summary of the coverage
results or details of various types of coverage metrics. DVE coverage
also provides more advanced feature enabling interactive
operations, such as excluding parts of a design.DVE also supports
verification plan editing and annotation.

You can use DVE to view the following coverage information:

• Code coverage information — DVE can display the following

types of code coverage information:
- Line coverage — The lines or statements were executed
during simulation.
- FSM coverage — VCS can identify blocks of code that make
up Finite State Machines (FSMs). FSM coverage reports on the
states, transitions, and sequences of states during simulation.
- Toggle coverage — The signals in the design toggle from 0 to
1 and 1 to 0 during simulation.

Generating Coverage Metrics for Your Design

3-8
 - Condition coverage — Conditions are expressions and sub-
expressions that control the execution of code or the
assignment of values to signals. Condition coverage tests
whether both true and false states of these conditions were
covered during simulation.
- Branch coverage — Analyzes how if and case statements
and the ternary operator (?:) establish branches of execution
in your Verilog design. It shows you vectors of signal or
expression values that enable or prevent simulation events.
• Testbench coverage — Coverage of SystemVerilog and
OpenVera testbench coverage groups.
• Assertion coverage — Coverage of OpenVera and
SystemVerilog cover directives.

Using Unified Coverage API to Generate Coverage

Reports

Unified Coverage Application Programming Interface (UCAPI) is a

set of APIs that you can use to extract specific data from your
coverage database. This is needed when you want to generate
custom reports to analyze your coverage data. For more information
about UCAPI, see the appendix “Unified Coverage API” .

Generating Coverage Metrics for Your Design

3-9
Viewing Coverage Reports

Viewing Coverage Reports in Verification Planner

You can view coverage reports in Verification Planner in the following

formats. See the sections provides as references for more
information.

• Interactively within the DVE editor (See chapter “Viewing and

Analyzing Coverage Reports Using DVE” ).
• URG HTML document (See chapter “Viewing and Analyzing
Coverage Reports Using Unified Report Generator” )
• Annotated spreadsheet (See chapter Verification Planner
Spreadsheet Annotator in the Verification Planner User Guide)
• Annotated Word document (See section Verification Planner MS
Doc Annotation in the VCS MX/VCS MXi LCA Features Guide.)
• XML dataset (see section Reporting HVP Annotated Results in
XML Format in the Verification Planner User Guide.)

Viewing Coverage Reports in URG

To view coverage reports using URG, invoke URG by specifying one
or more coverage database directories.

With the default coverage options, the coverage database directory

is saved in the *.vdb directory that contains code coverage,
covergroup coverage, and assertion coverage data.

Use the following command lines to invoke URG:

% urg -dir dir1 [dir2 ....] [urg_options]

% urg -dir simv.vdb -format both

Generating Coverage Metrics for Your Design

3-10
Where,

• dir1 and dir2 are the coverage database directories.

• If you specify more than one coverage database directory in the
URG command-line, URG merges the coverage database
directories, and writes a merged coverage database into the
current or specified directory. [urg_options] are URG
command-line options. For more information about URG options,
see the chapter URG Options in the Coverage Technology
Reference Manual.
By default, the specified URG commands write both HTML and text
report files in the urgReport directory that is created in the current
directory.The dashboard.html page is the homepage that
provides the overall coverage information of the design or the
testbench. For more information on URG, see chapter “Viewing and
Analyzing Coverage Reports Using Unified Report Generator” .

Viewing Coverage Reports in DVE Coverage

To view coverage reports in DVE invoke the DVE Coverage GUI by
entering the dve command with the coverage command-line option
(-cov) and then load the coverage database. You can also specify
the directory name in the command-line while invoking the DVE
Coverage GUI.

% dve -cov

OR

% dve -dir *.vdb

Generating Coverage Metrics for Your Design

3-11
 For more information about the DVE Coverage, see chapter Viewing
and Analyzing Coverage Reports Using DVE.

Viewing Coverage for Protected Modules

VCS does not report coverage scores for protected modules for any
coverage metric. If a module contains protected code, VCS
Coverage does not monitor the module or its self-instance and the
full hierarchy below it|.

Examples

The following examples show compilation and runtime options to

generate one or more metrics and invoking URG and Coverage GUI.
You can view the coverage report in batch mode using URG or in
GUI mode using DVE Coverage:

Example 3-1 Line Coverage Only

% vcs -cm line source.v
% simv -cm line
% urg -dir simv.vdb //to generate URG report
% dve -dir simv.vdb //to view coverage report in DVE
Coverage GUI
In this example,

1. VCS compiles for line coverage.

2. During simulation, VCS looks for line coverage.
Example 3-2 Line, Condition and FSM Coverage
% vcs -cm line+cond+fsm source.v
% simv -cm line+cond+fsm
% urg -dir simv.vdb

Generating Coverage Metrics for Your Design

3-12
 % dve -dir simv.vdb
In this example,

1. VCS compiles for Line, Condition, and FSM coverage.

2. During simulation, VCS looks for Line, Condition, and FSM
coverage.
Example 3-3 Line, Condition, FSM, Toggle, and Branch Coverage
% vcs -cm line+cond+fsm+tgl+branch -lca source.v
% simv -cm line+cond+fsm+tgl+branch
% urg -dir simv.vdb
% dve -dir simv.vdb
In this example,

1. VCS compiles for Line, Condition, FSM, Toggle, and Branch

coverage.
2. During simulation, VCS keeps track of Line, Condition, FSM,
Toggle, and Branch coverage.
Example 3-4 Line, Condition, and Assertion Coverage
% vcs -cm line+cond+assert source.v
% simv -cm line+cond+assert
% urg -dir simv.vdb / dve -dir simv.vdb
In this example,

1. VCS compiles for Line, Condition, and Assertion coverage.

2. During simulation, VCS keeps track of Line, Condition, and
Assertion coverage.
Example 3-5 Compiling for FSM, Toggle, and Branch Coverage while
Simulating only Branch Coverage
% vcs -cm fsm+tgl+branch source.v
% simv -cm branch
% urg -dir simv.vdb / dve -dir simv.vdb

Generating Coverage Metrics for Your Design

3-13
 In this example,

1. VCS compiles for FSM, Toggle, and Branch coverage.

2. You can choose to simulate VCS to track only few metricsthan
what you have specified during the compilation stage, such as
Branch coverage.
However, choosing fewer metrics for coverage compilation and
choosing more during simulation does not work.
Example 3-6 Specifying More Metrics at Compile-time and Runtime but
Generating Reports for Fewer Metrics
% vcs -cm line+fsm+branch+cond source.v
% simv -cm line+fsm+branch+cond
% urg -dir simv.vdb -metric line+fsm
% dve -dir simv.vdb
In this example,

1. VCS compiles for and simulates Line, FSM, Branch, and

Condition coverage.
2. While generating reports, you can choose to generate reports for
fewer metrics than what you have specified during compilation
and simulation and use URG to generate only Line and FSM
coverage.

Generating Coverage Metrics for Your Design

3-14
4
Setting Up Coverage Metrics 1
This chapter describes how you can set up coverage metrics using
various methods, as discussed in the following sections:

• “Overview of Coverage Metrics”

• “Code Coverage”
• “Functional Coverage”
• “Writing and Configuring Test Run Metrics”

Overview of Coverage Metrics

VCS monitors and evaluates coverage metrics of Verilog, VHDL, and

mixed HDL designs during simulation to determine which portions of
the design have been exercised. The results of the analysis are
reported in a number of ways that allow you to see the shortcomings

Setting Up Coverage Metrics

4-1
 in your testbench and improve tests as needed to obtain the
complete coverage. Functional coverage is the determination of how
much functionality of the design has been exercised by the
verification environment.

VCS writes both code and functional coverage databases during

simulation. Using VCS, you can generate the following types of
coverage databases:

• “Code Coverage”
You can obtain the following types of code coverage information:

- The control-flow coverage that tracks which lines and branches

have taken the flow of execution through the Verilog or VHDL
code. Control-flow metrics that includes line coverage and
branch coverage.
- The value coverage that monitors what values the signals and
expressions take on during simulation. Value-coverage metrics
include toggle coverage and FSM coverage, that track the
values (or value-transitions) of signals and variables.
• “Functional Coverage”
Functional coverage provides information about the testbench
variable and signal values and their state transitions. You can
enable cross-coverage between variables and signals. Cross
coverage allows you to check the combinations of values between
two or more signals.

The VCS implementation of SystemVerilog supports the

covergroup construct, which you specify as the user. These
constructs allow the system to monitor values and transitions for
variables and signals. They also enable cross-coverage between
variables and signals.

Setting Up Coverage Metrics

4-2
Code Coverage

This section discusses the following types of code coverage metrics.

• “Line Coverage”
• “Toggle Coverage”
• “Condition Coverage”
• “FSM Coverage”
• “Branch Coverage”
• “SystemVerilog Support for Code Coverage”

Line Coverage

Line coverage (or statement coverage) shows which lines of code

are exercised — and which ones are not — by the testbench during
a simulation run. VCS generates metrics for total coverage of lines,
blocks, and branches that tell you how much of your code is actually
executed by the tests. Line coverage is applied to signal and variable
assignments in HDL code and gives an indication of the number of
times each assignment statement was executed when the design
was simulated. A zero execution count pin-points a line of code that
has not been exercised and could be the source of a potential design
error.

Line coverage also produces annotated lists that identify the

statements that are not exercised. You can use this information to
develop the test suite further.

Setting Up Coverage Metrics

4-3
 Reporting the number of times a line of code is executed is not
default. To enable this, add the -cm_count elaboration option in the
command line.

In line coverage, VCS keeps track of the following in the source

code:

• Individual procedural statements

• Procedural statement blocks
• Procedural statement block type
• Missing (implied) conditional statements
Note:
• Statement blocks consist of a set of individual procedural
statements executed sequentially and always executed together
in the same time step.
• Line coverage does not keep track of continuous assignment
statements, by default. However, you can enable it using the
-cm_line contassign option. For more information see
“Enabling Line Coverage for Continuous Assignments”.

Line Coverage for Verilog

VCS tracks the following types of Verilog procedural statements:

• Statements that cause a simulation event, such as a procedural

assignment statement or a system task.
• Statements that control which other statements are executed,
such as the while or if statements.

Setting Up Coverage Metrics

4-4
 The following code example illustrates what is covered in Verilog:

Example 4-1 Monitored Statements in Line Coverage

module top;
reg clk;
reg [8:0] data;
wire [8:0] results;

initial
begin
$display("Assigning initial values");
clk=0; data=256;
#100 $finish;
end

always
#3 clk=~clk;

dev dev1 (results,clk,data);

endmodule

module dev (out,clock,in);

output [8:0] out;
input clock;
input [8:0] in;
reg [8:0] out;
reg en;

task splitter;
input [8:0] tin;
output [8:0] tout;
begin
tout = tin/2;
end
endtask

always @ (posedge clock)

begin
if (in % 2 !== 0)
$display("error cond, input not even");

Setting Up Coverage Metrics

4-5
 else
out = in;
if (in % 2 == 0)
en =
1;
while (en)
forever
case (out % 2)
!0 : #0 $finish;
0 : #5 splitter(out,out);
endcase
end
endmodule

In Example 4-1, the statements tracked by VCS for line coverage are
shown in boldface.

VCS line coverage also includes information about the always and
initial blocks and other types such as forever, case, if-else, so
on of blocks of code. In line coverage, a block is a nesting level in the
code. It is more of a level of control of the execution of the procedural
code. Typically, you will have to change the indentation of your
source code for a nesting level. Example 4-2 illustrates the code
blocks in the source code in Example 4-1. It is interrupted in a
number of places to explain the blocks.

Example 4-2 Code Blocks in Line Coverage

1 module top;
2 reg clk;
3 reg [8:0] data;
4 wire [8:0] results;
5
6 initial
7 begin
8 $display("Assigning initial values");
9 clk=0; data=256;
10 #100 $finish;
11 end

Setting Up Coverage Metrics

4-6
The initial block is a distinct block of code in this top-level
module. Inside the initial block is a procedural delay on the $finish
system task. This delay and system task constitutes a separate block
of code, so that if simulation ends before time 100, the other
statements in the initial block can be covered, just not the
$finish system task.

Note that the assignment statements to regs clk and data are on
the same line. This illustrates the difference between line and
statement coverages. In this case, line 9 is covered only if both the
statements clk=0; and data=256; are covered.

In terms of the statement coverage, the procedural delay is

considered as a separate wait statement in addition to the
$finish system task on that line. Here, #100 and $finish are
different statements present in one line. So the initial block in
Example 4-2 contains five statements in three lines.
always
#3 clk=~clk;

dev dev1 (results,clk,data);

endmodule

The always block that contains an assignment statement with a

procedural delay is one block instead of two.

module dev (out,clock,in);

output [8:0] out;
input clock;
input [8:0] in;
reg [8:0] out;
reg en;
task splitter;
input [8:0] tin;
output [8:0] tout;

Setting Up Coverage Metrics

4-7
 begin
tout = tin/2;
end
endtask

The procedural statements in a task definition (in this case, one

statement) are a separate block.
always @ (posedge clock)
begin
if (in % 2 !== 0)
$display("error cond, input not even");
else
out = in;
if (in % 2 == 0)
en =
1;
while (en)
forever
case (out % 2)
!0 : #0 $finish;
0 : #5 splitter(out,out);
endcase

end
endmodule

A block for this always block contains three statements: if-else,

if, and while statements.

The $display system task is controlled by the if construct of the

if-else statement and is in a separate block.

The procedural assignment to reg out is a separate block because

it is controlled by the else construct.

The procedural assignment to reg, en is a separate block because it

is controlled by the second if construct. This is one statement on
two lines.

Setting Up Coverage Metrics

4-8
The forever statement is in a separate block because it is
controlled by the while statement.

The case statement is in a separate block because it is controlled by

the forever statement.

The case item statements are separate blocks and the procedural
delays on these case item statements are considered separate wait
statements. There can also be blocks for missing constructs. If you
use an if statement instead of an if-else statement, VCS
considers the else construct to be missing. If you use a case
statement and do not enter a default case, VCS considers the default
case to be missing.

Enabling Line Coverage for Continuous Assignments

By default, line coverage does not include Verilog continuous
assignments. You can enable line coverage for continuous
assignments with the -cm_line contassign compile-time option
and keyword argument. For example:

% vcs -f design_files -cm line -cm_line contassign

When you include this compile-time option and keyword argument,
URG shows the continuous assignment statement, including any
delay specification, as a block of code.

If a continuous assignment assigns a constant value to the signal or

variable on the left hand side of the continuous assignment operator,
VCS does not compile or monitor it for line coverage.

For example,

module dev;
wire w1,w2,w3;
reg r1,r2;

Setting Up Coverage Metrics

4-9
 .
.
.
assign #5 w1=1;
assign #3 w2=r1;
assign #10 w3=r1 && r2;
endmodule

VCS compiles and monitors the continuous assignments to w2 and

w3 for line coverage, but not to w1.

Line Coverage for VHDL

In line coverage, VCS tracks the following in the VHDL source code:

• Individual statements
• Statement blocks
• Statement block type
Note:
- Statement blocks consist of a set of individual statements
executed sequentially and always executed together in the
same time step.
- Concurrent signal assignments and component instantiations
are not reported in the coverage reports because they are
always executed.
- Coverage information is not reported for execution lines in entity
or configuration declaration statements.

Setting Up Coverage Metrics

4-10
 - VCS monitors line coverage inside for-generates blocks,
but individual instances of the generate loop are not monitored
separately. Therefore, a line is reported as covered if it is
covered in any iteration of the loop, and a line is reported not
covered only if it is not covered in any iteration of the loop.

Toggle Coverage

Toggle coverage monitors value changes on signal bits in the design.

When toggle coverage reaches 100%, it means that every bit of
every monitored signal has changed its value from 0 to 1 and from 1
to 0. VCS generates metrics for the total coverage of nets and
registers that tell you how much activity is occurring on all the
elements; thus giving you a clear indication of how much testing is
actually being performed at the gate level.

Missing transitions of values provide definitive conclusions about

inactive elements and portions of the design that are not exercised.
The statistics produced for each module can be examined to quickly
determine areas of low coverage. This helps you to write tests to
address the missing activity.

Note:
By default, toggle coverage does not display or report 0 → 1 and
1 → 0 transitions where the signal returns to its original value
during the same time step that is, a glitch during which zero
simulation time passes.

Setting Up Coverage Metrics

4-11
Example 4-3 Example For Toggle Coverage
module test;
reg r1;
reg [7:0] r2;
wire w1;

dut dut1 (w1,r1);

initial
begin
r1=0;
r2=8’b00000000;
#100 $finish;
end

always
#10 r1=~r1;

always
#25 r2=r2+1;

endmodule

module dut (out,in);

output out;
input in;
reg dutr1;

always @ in
dutr1=in;

assign out=dutr1;
endmodule

In Example 4-3, the top-level module, test, instantiates module

dut. The top-level module, test, contains two registers, r1 and r2,
and one net, w1. The module instance dut1 of module dut contains
one register dutr1 and two nets, ports in and out.

Setting Up Coverage Metrics

4-12
In the top-level module, test, reg r1 will have ten 0 → 1 or 1 → 0
transitions and vectr reg r2 will increment three times.

In module instance dut1, all the signals will have ten 0 → 1 or 1 →

0 transitions.

Condition Coverage

Condition coverage monitors whether certain expressions and sub-

expressions in your code evaluate to true or false. By default, the
expressions and sub-expressions are as follows:

• The conditional expression used with the conditional operator ?:

in a continuous or procedural assignment statement. For
example, note the following continuous assignment statement for
Verilog:
assign w1 = r1 ^~ r2 ? r2 : r3;

The conditional expression is r1 ^~ r2 and the truth or falsity

of this expression are conditions for condition coverage.

• The conditional expression used in conditional concurrent signal

assignment or selected concurrent signal assignment, as shown
in either of the following VHDL examples:
c <= '0' when (a='0' and b= '0') else
'1' when (a='1' and b= '1'); -- conditional concurrent
-- signal assignment

OR

with (a and b or d) select

c <= '0' when '0',
'1' when '1',
'X' when others;

Setting Up Coverage Metrics

4-13
 In this example, the conditional expressions are (a='0' and b=
'0') and (a='1' and b= '1') conditional concurrent signal
assignment, and (a and b or d) for selected concurrent signal
assignment.

• Sub-expressions are other conditional operands to the logical

AND(&&), logical OR (||), or ternary operators. Consider the
following Verilog assignment statement:
r8 = (r1 == r2) && r3 ? r4 : r6;

Here, the conditional expression is (r1 == r2) && r3 and the

sub-expressions are (r1 == r2) and r3. The conditions for
condition coverage are the truth or falsity of the conditional
expression and these two sub-expressions.

In the case of VHDL, expression ((a and b) or d) consists

of two sub-expressions: the (a and b) expression and the d
expression. The conditions for condition coverage are the truth or
falsity of the whole expression and these two sub-expressions.

• Sub-expressions that are the operands to the logical AND && or

logical OR || operators in the conditional expression in an if
statement. For example, in the following Verilog if statement:
if ((r1 ^ (!r2)) && (r3 == r4))
begin
.
.
.
end

The sub-expressions that are the operands of the logical and

operator && are (r1 ^ (!r2)) and (r3 == r4))and the
conditions for condition coverage are the truth or falsity of these
VHDL sub-expressions.

Setting Up Coverage Metrics

4-14
 if ( A = '0') and ( B = '0') then
...
end if;
(A = '0') and (B = '0') are the subexpressions

• Sub-expressions that are the operands to the logical AND (&&)

or logical OR (||) operators in an expression in a continuous or
procedural assignment statement. For example, in the following
Verilog continuous assignment statement:
assign w2 = r5 || r6;

Sub-expressions r5 and r6 are operands of the logical OR (||)

operator and their truth or falsity are conditions in condition
coverage.

For example, in the following Verilog procedural assignment

statement:

r6 = (r6 !== r7) || r8;

Sub-expressions (r6 !== r7) and r8 are operands of the

logical OR (||) operator and their truth or falsity are conditions
in condition coverage.

• Sub-expressions (mba < mbb) and (mbb <=mbc) are operands

of the logical AND operator and their truth or falsity are conditions
in condition coverage.
• Sub-expressions (b /= c) and d are operands of the logical OR
and their truth or falsity are conditions in condition coverage.

Setting Up Coverage Metrics

4-15
 Limitations With Verilog Conditional Coverage
In some cases, conditional expressions with the right operators do
not result in conditions for condition coverage. The following are
cases with conditional expressions, where VCS does not monitor for
condition coverage:

• In terminal connection lists in task-enabling statements:

#1 t1(r11 && r12,r12,r3);

• In instance connection lists:

dev d1(r11 && r12);

• In PLI routine calls:

$pli((r11 && r12);

• In for loops:
for (i=0;i<10;i=i+1)
if(r1 && r2)
r3=r1;
else
r3=r2;

In this example, VCS by default does not monitor the conditional

expression (r1 && r2)for condition coverage, but it is possible
to monitor conditional expressions in for loops.

For more information, see the topic Enabling Condition Coverage

in For Loops in the Coverage Technology Reference Manual.

• In user-defined tasks and functions:

Setting Up Coverage Metrics

4-16
 task mytask;
input in;
output out;
begin
if (r1 && r2)
out=in;
else
out=~in;
end
endtask

By default, VCS does not monitor conditional expressions in user-

defined tasks and functions.

For more information, see the topic Enabling Condition Coverage in

Tasks and Functions in the Coverage Technology Reference
Manual.

Limitation With VHDL Conditional Coverage

In the following instances, VCS does not monitor condition coverage
and URG does not report condition coverage. However, no warning
or error message is displayed:

• Conditions in sequential templates.

For example,

if(clk'event and clk='1') then

.
.
.

• Conditions with a vector of variable size, though the size is known

through further evaluation. For example:

Setting Up Coverage Metrics

4-17
 variable N : integer;
DATA (N to N+3) <= DATA2 (7-N downto 4-N) AND DATA3(7-N
downto 4-N);

• Conditions within a generate block.

• Conditions within a subprogram body.
• Conditions within an entity declaration region. For example, a
subprogram defined in an entity.
• Conditions within a package body. For example, a subprogram
defined in a package body.
• Conditions within a block construct.

Specifying Stable Names for Conditions in a Design

Code coverage automatically finds conditions in a design and

monitors whether they are covered in simulation runs. These objects
are identified in an ad hoc manner, depending on the type of object.
For example, signals in toggle coverage and machines in finite-state
machine (FSM) coverage can be identified by signal names.
Statements, branches, and conditions are identified by line numbers.
Conditions are identified by a sequence number within a given
module (for example, 1st, 2nd, and 3rd).

The following are the two categories of conditions:

• Conditions with stable names — An object name is stable, if it is

not sensitive to unrelated changes. For example, the name of a
signal for toggle or FSM coverage is stable. The condition name
can be changed by changing the signal name itself.

Setting Up Coverage Metrics

4-18
• Conditions with unstable names — Object names that are
sensitive to unrelated changes in the design are unstable. For
example, any condition whose name depends on a source line
number has an unstable name, since even adding a comment can
change the name.
This feature allows you to specify stable names for conditions,
whose names are unstable, by default.

Naming a Condition in a Module

You can use the coverage name <condition name> pragma to
name a condition in a module. For example:

//coverage name a1
if (a || (b && c))

In the example, the condition name a1 is assigned to the statement

if (a || (b && c)). Any conditions found in the statement can
be addressed starting with a1, rather than with a sequence number
in the module or source line number. The pragma should be inserted
immediately before the condition.

Advantages of Assigning Stable Names for Conditions

Assigning stable names for conditions is useful for excluding
continuous conditions and FSvectors specified in exclusion files (el
files) for condition coverage, see section “Generating El File for
Condition Coverage” for more information on el files.

Setting Up Coverage Metrics

4-19
 You can exclude conditions and vectors using the condids given in
el file, which is generated by DVE. However, the names of conditions
and vectors in that file are sequence numbers generated by an
incrementing counter. For example, condition 1, condition 2, and so
on.

An issue in this approach is that if a new condition is added, then all

the sequence numbers for conditions below the addition are
invalidated. Where you once had conditions with IDs 5, 6, 7, the IDs
are now 6, 7, and 8. Any file that contains a condition to ‘exclude
condition 6’ is now excluding the incorrect one.

If you assign a stable name to a condition, then that name will be

shown in any coverage reports (and available through UCAPI).

Assigning stable names for conditions is accomplished by providing

tags in the source and generating an el file using DVE for condition
coverage metric. This metric will contain the stable names and
excluded vectors in the generated file.

Generating El File for Condition Coverage

If you use DVE to generate the el file, the dumped file contains the
stable name for tagged conditions instead of the Integer IDs.

While applying the el file to your design, if the module or instance

checksum has changed, then only the conditions with given stable
names are considered for exclusion. The remaining non-stable IDs
are ignored in URG and are under review in DVE.

The auto_stablefile.el file is generated when you specify the

-cond ids option in the urg command line. In this el file, all the
condition exclusions are commented. You can uncomment any
condition exclusion as required.

Setting Up Coverage Metrics

4-20
Specifying Tags in the Source
This section explains how tags are specified in the source and how
condition names are derived from these tags.

Condition and Sub-condition

Consider the following example:

//coverage name a1
if (a || (b && c)) {
…
}

The top-level condition is a || (b && c). It is broken down by code

coverage into two terms. Its name is a1:

a || (b && c)Condition a1
1 --2---

There is also a sub-condition with two terms, named a1.1:

b && c Condition a1.1

1 2

Specifying Multiple Conditions in a Statement

A statement might contain more than one independent condition.

For example:

//coverage name mycond

x <= (a || (b && c)) ? ( (d && (e || f)) ? 1’b1 : 1’b0 ) : 1’b1;

Setting Up Coverage Metrics

4-21
 There are two conditions, (a || (b && c)) and
(d && (e || f)) in the example. Both the conditions are part of
the same statement, but there is only one name pragma.

VCS assigns names based on the name. The first condition is

named as mycond:

a || (b && c) Condition mycond

1 --2---
b && c Condition mycond.1
1 2
The second condition is named as mycond.2:

d && (e || f) Condition mycond.2

1 --2---
e || f Condition mycond.3
1 2
If there were additional conditions, then they would be named as
mycond.<serial number of condition on the line>. For
example, mycond.2, mycond.3, and so on.

Note:
This additional naming is valid only for one statement.

Setting Up Coverage Metrics

4-22
Specifying Multiple Statements in a Line
If a single source line contains multiple statements, then only the first
statement is named by a preceding pragma. For example:

//coverage name a2
x <= (a || b) ? 1’b0 : 1’b1; y = (c && d) ? 1’b0 : 1’b1;
a || b Condition a2
1 2
There is no name for the second condition c && d, since it occurs
in another statement that has no pragma preceding it. If you want to
assign a name to c && d, then you must place the statement on a
separate line:

//coverage name a2
x <= (a || b) ? 1’b0 : 1’b1;
//coverage name a3
y = (c && d) ? 1’b0 : 1’b1;
a || b Condition a2
1 2
c && d Condition a3
1 2

Viewing Names in the Generated Reports

In the URG reports, condition ID numbers are shown if the -cond
ids option is specified. These appear inlined with the condition
coverage reports. For example, in URG, you can view the following:

LINE 12
CONDITION_ID 1
STATEMENT if ((a || (b && c)))
1 --2---
EXPRESSION -1- -2-
0 0 | Not Covered
0 1 | Not Covered
1 0 | Not Covered

Setting Up Coverage Metrics

4-23
 If the condition was named with a pragma in the source, then the
name will appear instead:

LINE 12
CONDITION_ID a1
STATEMENT if ((a || (b && c)))
1 --2---
EXPRESSION -1- -2-
0 0 | Not Covered
0 1 | Not Covered
1 0 | Not Covered

Sub-conditions will be named as described above. For example, the

subcondition b && c is labeled as a1.1:

LINE 12
CONDITION_ID a1.1
STATEMENT if ((a || (b && c)))
1 2
EXPRESSION -1- -2-
1 1 | Not Covered
0 1 | Not Covered
1 0 | Not Covered
You can use the covdb_get_annotation(condObj, "id") to
get the stable name from the condition ID handle.

Setting Up Coverage Metrics

4-24
Limitations With Stable Names for Conditions
The following are the limitations of this functionality:

• The support for stable names is not available for VHDL conditions.
It is available only for Verilog conditions.
• There should be no other lines (even blank lines) between the
condition statement line and the pragma line.
• The stable name for condition cannot have a period (.) character
in it; it is reserved for condition coverage naming scheme for sub-
conditions.

FSM Coverage

In hardware, a Finite State Machine (FSM) is a sequential logic that

outputs a current state and a combinational logic that outputs the
next state. When VCS compiles your design for FSM coverage, it
identifies a group of statements in the source code to be an FSM and
tracks the states and transitions that occur in the FSM during
simulation.

The sequential logic is driven by the next state signal and clock, and
reset signals. The combinational logic is driven by the current state
and the inputs to the FSM.

Setting Up Coverage Metrics

4-25
Figure 4-1 Finite State Machine

reset
sequential logic current state
clock
determines the
current state

next state

combinational logic
determines the
next state
inputs

In higher level Verilog or VHDL, a group of statements can be a

higher level of abstraction of an FSM. VCS treats a group of
statements as an FSM if the group contains a procedural assignment
statement to assign the current state of the FSM. The values
assigned in the group of statements must be clearly identifiable as
constants and there must be a dependency between the current
state and the next state. The following group of Verilog statements is
an FSM:

input in;
reg [3:0] current,next;

initial
current=4’b0001;

always @ in
begin
case (1’b1)
current [0] : next=4’b0010;
current [1] : next=4’b0100;
current [2] : next=4’b1000;
current [3] : next=4’b0001;

Setting Up Coverage Metrics

4-26
endcase
#2 current=next;
end

FSM Coverage for Verilog

In Verilog, a group of statements can be used to describe a higher
level of abstraction of an FSM. VCS treats a group of statements as
an FSM if it meets the following criteria:

• The group of statements must contain a procedural assignment

statement to a vector variable to assign the current state of the
FSM.
The group can also contain one of the following (though this is not
required):

- A procedural assignment to assign the next state to another

variable.
- A concurrent assignment statement to assign the next state to
a net.
• In the group, a dependency exists between the current value
assigned and the next value assigned.
When you write such a group of statements, it is important to know if
the statements made the assignments to all possible states of the
FSM and all possible transitions between states.

VCS does not automatically extract an FSM when:

• The group of statements exists in a user-defined task (in VHDL,

a function or procedure), including a SystemVerilog global task (it
will extract if the group is in a user-defined function, including a
SystemVerilog global function).

Setting Up Coverage Metrics

4-27
 • There are less than three possible states.
Example 4-4 is a Verilog module definition that contains statements
that function as an FSM:

Example 4-4 Verilog Module Definition Containing an FSM

module dev (clk,in,state);
input clk,in;
output [1:0] state;

reg [1:0] state,next;

parameter idle = 2’b00,
first = 2’b01,
second = 2’b10,
third = 2’b11;

initial
begin
state=idle;
next=idle;
end

always @ in
begin
next = state; // by default hold
case (state)
idle : if (in) next = first;
first : if (in) next = second;
second : if (in) next = third;
third : if (in) next = idle;
endcase
end

always @ (posedge clk)

state=next;

endmodule

Setting Up Coverage Metrics

4-28
The FSM has four states: idle, first, second, and third. It is possible
for a testbench to apply stimulus such that line coverage indicates
that VCS executed all the executable lines, but FSM coverage
indicates that there never was a transition from the third to the idle
state.

The values that the statements in the group assign to a signal are the
states of the FSM, and must be of an identifiable set of parameters,
numeric constants, or text macros (where the macro text that VCS
substitutes for the macro name is a numeric constant). The states
can also be enumerated types in SystemVerilog.

Limitation
The current state variable and the variables used to store the next
state value must not have unpacked dimensions.

FSM Coverage for VHDL

VCS automatically extracts FSMs from VHDL code in the following
scenarios:

• The state values are stored in enumerated, std_logic_vector,

bit_vector, or integer data types.
• The state values of the FSM are either an enumerated type, VHDL
constant, or literal constant. No expressions or function calls on
the right side of assignment statements assigning the next state
of the FSM.
• The code determines the next state of the FSM using a case
statement. VCS does not extract the FSM if there is an if
statement for determining the next state.

Setting Up Coverage Metrics

4-29
 • The code for the FSM is entirely within a procedure or process or
using one combinational process to determine the next state of
the FSM and a sequential process to set the next state on the
clock edge.
VCS cannot automatically extract the following types of FSMs:

• One-hot or hot-bit FSMs.

• FSMs using conditional assignment statements.
Example 4-5 illustrates a VHDL architecture that models an FSM:

Example 4-5 VHDL Architecture Modeling an FSM

architecture exfsmarch of exfsm is
type my_fsm_states is (idle, first, second, third);

signal curr_state : my_fsm_states := idle;

signal next_state : my_fsm_states := idle;

begin

my_fsm : process(insig)
begin
next_state <= curr_state;
case curr_state is
when idle => if (insig = '1') then next_state <= first;
end if;
when first => if (insig = '1') then next_state <= second;
end if;
when second => if (insig = '0') then next_state <= third;
end if;
when third => if (insig = '1') then next_state <= idle;
end if;
end case;
end process;

advance_fsm : process
begin
wait until clk'event and clk = '1';

Setting Up Coverage Metrics

4-30
 curr_state <= next_state;
end process;

end exfsmarch;

Limitation
FSMs are not supported inside loop generate blocks.

Branch Coverage

Branch coverage monitors the execution of conditional statements

such as if/else statements, case statements, and the ternary
operator "?:" in a design. By default, Branch coverage analyzes
which alternative of these conditional statements is covered during
simulation. It can also monitor and report the values computed by a
ternary expression.

Note:
VHDL branch coverage is an LCA feature. For more information
about the LCA feature, see the section Using VHDL Branch
Coverage in the VCS MX LCA Features Guide.

Consider the code in Example 4-6:

Example 4-6 Branch Coverage Code Example

case (r1)
1’b1 : if (r2 && r3)
r4 = (r5 && r6) ? 1’b0 : 1’b1;
1’b0 : if (r7 && r8)
r9 = (r10 && r11) ? 1’b0 : 1’b1;
default : $display("no op");
endcase

Setting Up Coverage Metrics

4-31
 In this block of code, there are procedural assignment statements
where the value assigned is controlled by the ternary operator (?:).
These statements in turn are controlled by if statements and the if
statements are controlled by a case statement.

In this block of code, the possible vectors of signal or expression

values that result in simulation events or prevent simulation events
are as follows:

r1 (r2 && r3) (r5 && r6) (r7 && r8) (r10 && r11)

1 1 1 - -
1 1 0 - -
1 0 - - -
0 - - 1 1
0 - - 1 0
0 - - 0 -
default - - - -

For example, in the first vector, r1 is 1’b1 and the expression

(r2 && r3) is true, therefore, the value of r4 depends on the value
of (r5 && r6). The values of (r7 && r8) and (r10 && r11)do
not matter.

Consider an another example where r1 is 1’b1, but the expression

(r2 && r3) is false, and the values of the other expressions are not
applicable, therefore the scenario is not simulated.

Branch coverage displays these vectors and indicates whether

these vectors ever occurred during simulation, in other words,
whether they were covered.

By default, VCS does not monitor branch coverage for if and case
statements and ternary operator(?:) if they are in user-defined tasks
or functions or in code that executes as a result of a for loop. You
can, however, enable branch coverage in this code.

Setting Up Coverage Metrics

4-32
For more information, see, Section "For Loops and User-defined
Tasks and Functions" in the Coverage Technology Reference
Manual.

Branch Coverage With Unknown and High Impedance Values

If the conditional expression in an if statement evaluates to X or Z,
branch coverage treats this as a false value and reports that 0 value
for the expression is covered.

If the case expression in a case statement evaluates to X or Z, VCS

executes the default case item. When this occurs, branch coverage
reports that the vector for the default case item is covered. If there is
no default case item, branch coverage reports a vector for the
missing default case item and reports it as covered.

When the conditional expression for a ternary operator evaluates to

X or Z, the vector for the expression is not covered.

Branch Value Coverage

Branch coverage analyzes how if/else and case statements and
the use of the ternary operator (?:) are exercised during simulation
of a design. Previously, branch coverage would only report for
ternary expressions which branches were used when the expression
was evaluated. Now, branch coverage can also report on whether
the value seen when a particular ternary branch was used was zero
or non-zero. For example, consider the following expression:

res <= a ? b : c;

With the new -cm_branch values switch, branch coverage now

reports the coverage for this expression as shown below:

Setting Up Coverage Metrics

4-33
 res <= a ? b : c;
-1- a
-2- b
-3- c
Branches:
-1- -2- -3-
0 - 0 Covered
0 - other Not Covered
1 0 - Not Covered
1 other - Covered

If a is true at the time of execution, then the true alternative is

covered and if a is false, then the false alternative is covered. With
the -cm_branch values switch, VCS also reports whether a zero or
non-zero value is seen for b when the true alternative is covered, and
whether a zero or non-zero value is seen for c when the false
alternative was covered.

If ternary expressions are more than one bit, branch coverage tracks
them in the same way as it tracks the ternary expressions having one
bit. For example, consider the following expression:

reg [7:0] avec, bvec, cvec;

res <= avec ? bvec : cvec;

With the new -cm_branch values switch, branch coverage reports

the coverage for this expression as shown below:

res <= avec ? bvec : cvec;

-1- avec
-2- bvec
-3- cvec
Branches:
-1- -2- -3-
0 - 0 Covered
0 - other Not Covered
1 0 - Not Covered
1 other - Covered

Setting Up Coverage Metrics

4-34
This section consists of the following subsections:

• “Nested/Complex Branch Types”

• “Expression Results”
• “Constant Results”
• “Unknown Values”
• “User Interfaces”

Nested/Complex Branch Types

For nested expressions, branch coverage tracks the leaf values of
ternary expressions. For example, branch coverage monitors the
values of d, e, g, and h in the following ternary expression:

reg a, b, c, f;
reg [3:0] d, e, g, h;
assign a = b ? ( c ? d : e ) : ( f ? g : h );

VCS branch value coverage reports the expression as follows:

assign a = b ? ( c ? d : e ) : ( f ? g : h );

-1- b
-2- c
-3- d
-4- e
-5- f
-6- g
-7- h
Branches:

Setting Up Coverage Metrics

4-35
 -1- -2- -3- -4- -5- -6- -7- Status
1 1 0 - - - - Not Covered
1 1 other - - - - Not Covered
1 0 - 0 - - - Not Covered
1 0 - other - - - Not Covered
0 - - - 1 0 - Not Covered
0 - - - 1 other - Not Covered
0 - - - 0 - 0 Not Covered
0 - - - 0 - other Not Covered

Expression Results
Branch value coverage monitors the value of all leaf alternative
expressions in ternaries. This includes both simple expressions, as
in the examples above, and complex expressions. For example,
branch coverage tracks the values of sx and
((4’d2 << ss) + ({2’b0,le[1:0]} << fs)) in the following
expression:

assign fps = (a|b) ? sx : ((4’d2 << ss) + ({2’b0,le[1:0]} << fs));

-1- (a|b)
-2- sx
-3- ((4’d2 << ss) + ({2’b0,le[1:0]} << fs))
Branches:
-1- -2- -3-
0 - 0 Covered
0 - other Not Covered
1 0 - Covered
1 other - Not Covered

Setting Up Coverage Metrics

4-36
Constant Results
If a ternary expression has a constant value, branch value coverage
does not track its value. For example, branch value coverage does
not track the value of 2’b00 in the following expression:

nxt <= (cur == IDLE) ? ival

: (cur == BUSY) ? 2'b00
: dval;

Instead, the constant result is omitted from the list in the report, as
shown in the following example:

nxt <= (cur == IDLE) ? ival

: (cur == BUSY) ? 2'b00
: dval;

-1- (cur == IDLE)

-2- ival
-3- (cur == BUSY)
-4- dval
Branches:
-1- -2- -3- -4-
0 - 0 0 Not Covered
0 - 0 other Covered
0 - 1 - Not Covered
0 - 1 - Not Covered
1 0 - - Covered
1 other - - Not Covered

Branch coverage does not monitor literal constants and enumerated

values. However, values that happen to be constant because they
involve signals that are tied to constants, or are expressions that
happen to evaluate to a constant value, are tracked for zero and non-
zero values. For example, branch coverage tracks all leaf values in
the following expression even though one leaf value is always
constant:

Setting Up Coverage Metrics

4-37
 assign tied0 = 1'b0;
…
assign res = a ? tied0 : c;

res <= a ? tied0 : c;

-1- a
-2- tied0
-3- c
Branches:
-1- -2- -3-
0 - 0 Covered
0 - other Not Covered
1 0 - Not Covered
1 other - Covered

If all results are constant, branch coverage omits all leaf values and
only reports ternary conditions. For example, consider the following
expression:

wire t2 = oe_s ? (kp_hold ? 8'b1 : 8'b0) : (kp_hold ? 8'b0

: 8'bz);

Branch coverage omits all values as shown below:

wire t2 = oe_s ? (kp_hold ? 8'b1 : 8'b0) : (kp_hold ? 8'b0

: 8'bz);

-1- oe_s
-2- kp_hold
-3- kp_hold
Branches:
-1- -2- -3- Status
1 1 - Not Covered
1 0 - Not Covered
0 - 1 Not Covered
0 - 0 Not Covered

Setting Up Coverage Metrics

4-38
Unknown Values
If a ternary expression evaluates to an unknown value (X), zero and
non-zero values both remain uncovered. For example, branch
coverage does not cover any value in the following expression:

Branch Coverage for Instance : top.d1

…
assign bvec = 2'bxx;
assign cvec = 2'bxx;
res <= avec ? bvec : cvec;

-1- avec
-2- bvec
-3- cvec
Branches:
-1- -2- -3-
0 - 0 Not Covered
0 - other Not Covered
1 0 - Not Covered
1 other - Not Covered

Here, avec contains the value ‘x’ for the duration of the simulation to
get the 0% coverage reported. Note that avec remains x for the entire
simulation.

Setting Up Coverage Metrics

4-39
 User Interfaces
You can view the branch coverage report using the following utilities:

• “Command Line”
• “URG”
Note: The option to track branch values is determined at compile time
and no extra switches are required at simulation or report time.
Command Line

To enable branch value coverage, use the -cm_branch values sub-

switch along with the branch coverage switch, –cm branch, in the
vcs command. Its syntax is as follows:

vcs –cm branch –cm_branch values …

URG

Unified Report Generator (URG) generates combined reports for all

types of coverage information. The reports consist of a set of HTML
or text files. To invoke URG, use the following URG command:

% urg -dir <coverage_database.vdb> format both

URG creates the following coverage report in the HTML format:

Setting Up Coverage Metrics

4-40
URG creates the following coverage report in the text format:

Setting Up Coverage Metrics

4-41
 Limitations
The branch value coverage feature has the following limitations:

• Zero and non-zero values are covered; x and z values are not
covered. For example:
assign out = ((din & {512 {1'bx}})? din :((~din) &
dout_temp) |(din & {512 {1'bx}})));
assign y = x & 3'bx; // this is not extracted in
// conditional coverage

• Branch coverage for code inside functions and expressions that

are function calls cannot be extracted.
• VCS does not report if it is a condition of if/while/case, for
example:
if (a ? b : c)
case(a ? b : c)
while(a ? b : c)
assign a = a || (a ? b : c)

• Branch values are not monitored for leaf nodes that have
unpacked dimensions.
module test
reg a;
reg z[6:0];
reg b[6:0];
reg c[6:0];
initial begin
z = a? b : c;
//Coverage should not create z = a? (b? b :b) : (c? c: c);
//and hence, the branch values are not monitored for the
//leaf nodes b and c.
end
endmodule

Setting Up Coverage Metrics

4-42
• Branch values are not monitored for the nodes with streaming
operators [>> and <<].
• Branch value coverage ignores ternary expressions inside
generate statements. For example:

genvar i;
generate for (i=0; i<4;i++ )
begin: inst
always @(posedge clk)
e[i] <= ((c[i] && d[i]) ? ((c[i]!=1'b0)?
c[i]: ~c[i]) : d[i]);
end
endgenerate

Branch coverage shows the following warning in the URG report:

e[i] <= ((c[i] && d[i]) ? ((c[i]!=1'b0)? c[i]: ~c[i]) :

d[i]);
Warning: the following expressions cannot be annotated
-1- ((c[1] && d[1])) ? ...;
-2- ((c[1] != 1'b0)) ? ...;

Setting Up Coverage Metrics

4-43
 SystemVerilog Support for Code Coverage

Code coverage metrics is supported for SystemVerilog language

constructs. However, VCS does not support all the constructs in
SystemVerilog, essentially the non-dynamic constructs. The
following table illustrates the support matrix.

Name of the Coverage Metrics Unsupported Description

Construct Coverage
always[comb, ff, latch] All metrics NA NA

initial @ All NA NA

case/casez/casex with line+tgl+cond+ fsm NA

arrays branch

case/casez/casex with line+tgl+cond+ fsm NA

part selects branch

case/casez/casex with line+tgl+cond+ fsm NA

struct/union members branch
as case variables with
don’t cares and const
expressions.
unique/priority tgl+fsm line+cond+branch NA

fork / Join Valid only for line NA NA

Loops

generate line+tgl NA NA

break / continue line+tgl+cond+ NA NA

branch

return / disable All metrics NA NA

Setting Up Coverage Metrics

4-44
Name of the Coverage Metrics Unsupported Description
Construct Coverage
INTERFACES

Interfaces instantiated All metrics NA interface

in modules modports, being
passed as a port to
any module is
not reported.
Blocks All metrics NA NA
**specify block

Tasks and functions line+cond+fsm+tgl Branch coverage Arguments in task

is reported with - and functions
cm_cond not reported in tgl
coverage.

modports Not supported All metrics NA

Parameterized All metrics NA NA

interfaces

COVERAGE

Datatypes

Enum line+fsm+branch enum methods in NA

conditional
expression
doesn’t extract a
condition.
event line not monitored in NA
tgl
byte, shortint, int, line not monitored in NA
longint, time, shortreal tgl
bit, logic, tgl NA NA

Setting Up Coverage Metrics

4-45
 Name of the Coverage Metrics Unsupported Description
Construct Coverage
packed, unpacked All NA NA

struct / union [ tagged ] line+tgl+cond+ part select on NA

branch struct variable
doesn’t generate
fsm

Nested struct and union line+tgl+cond+ NA NA

branch

Array of structs and line+tgl+cond+ NA NA

unions (MDAs as branch
members)

Arrays If it is used inside

an expression,
conditional and
Dynamic arrays line+cond+branch tgl
branch coverage
are reported.
Associative array line+cond+branch tgl

Queues line+cond+branch tgl

Parameterized Type Works for toggle NA NA

coverage on
signals of
"parameterized
type"

Setting Up Coverage Metrics

4-46
Name of the Coverage Metrics Unsupported Description
Construct Coverage
Blocks

clocking Not Supported Not supported NA

Program Block Not Supported Not supported NA

packages Not Supported Not supported NA

Classes Not Supported Not supported NA

Coverage Options and Sub-Options

VCS Coverage provides options and sub-options that help you

customize the generation of coverage data for your design.

Mandatory Options for Generating Coverage Metrics

To generate coverage metrics, use the following commands during
compile-time and runtime:

-cm <cov_metrics_name>
The arguments to the -cm option are as follows:

line
Specifies line coverage

cond
Specifies condition coverage

tgl
Specifies toggle coverage

Setting Up Coverage Metrics

4-47
 fsm
Specifies FSM coverage

branch
Specifies branch coverage

assert
Specifies assertion coverage

You can include more than one argument using a plus (+) as a
delimiter between arguments.

For example,

% vcs source.v -cm line+tgl+branch

Functional Coverage

VCS provides a capability to gather functional coverage metrics

during simulation runs. If your design has assertions or covergroups
defined, VCS collects the coverage data and generates the
coverage database (simv.vdb). After simv.vdb is generated, you can:

• Use Unified Report Generator (URG) to generate text or HTML

reports
• Use DVE Coverage GUI (Cov GUI) to view your assertion or
covergroup reports
• Use custom coverage API to view the reports

Setting Up Coverage Metrics

4-48
Using with Clause in Covergroups

As defined in the SystemVerilog LRM, VCS supports with clause in

covergroups. The syntax of coverpoint and cross bins to support
with clause is described in the following sections. The with clause
helps you define coverpoints clearly, which otherwise requires
elaborate writing in the cover group specification.

You can use the with clause to precisely specify the functional
coverage space for your SystemVerilog based verification
environment. This feature is applicable only for regular coverpoint
bins (transition bins are not supported).

Coverpoint Syntax
The syntax for specifying ranges for coverpoint bins to include the
with clause is as follows:

bins_or_options ::=

[ 'wildcard' ] bins_keyword bin_identifier [ '[' [

expression ] ']' ] = '{' open_range_list '}' [
'with' '(' with_expression ')' ] [ 'iff' '('
expression ')' ]

| [ 'wildcard' ] bins_keyword bin_identifier [

'[' [ expression ] ']' ] = cover_point_identifier
'with' '(' with_expression ')' [ 'iff' '('
expression ')' ]

Where,

bins_keyword :: = bins | ignore_bins | illegal_bins

Setting Up Coverage Metrics

4-49
 with_expression ::= expression

The with clause further tightens the range of values specified

through open_range_list and subsumed by a coverpoint bin.
Essentially, each value in the open_range_list must satisfy the
condition represented by the with_expression in order to be
considered a part of the bin. The with_expression can be an
arbitrary expression (including function calls) with the coverpoint
identifier used as one of the operands in the expression. Instead of
the coverpoint identifier, the keyword item must be used.

Additionally, the coverpoint name can be used to substitute the

whole range of values taken by the coverpoint variable. The
evaluation of the bin ranges and the with_expression is done at
the time of cover group instantiation. All variables, barring the
coverpoint name and the item keyword are contained in the
with_expression. They are treated as runtime constants and are
evaluated at the time of cover group instantiation; the treatment is
similar to the one used for guard expressions.

Examples

bit [7:0] x;
a: coverpoint x
{
bins mod3[] = {[0:255]} with (item % 3);
}
The bin definition in this example selects all values from 0 to 255 that
are not divisible by 3.

As the range list in the example includes all values of the coverpoint
variable, it can be substituted with the name of the coverpoint, as
follows:

bins mod3[] = a with (item % 3);

Setting Up Coverage Metrics

4-50
An example for function calls used in the with expression, is as
follows:

bins mod3[] = {[0:255]} with (myFunc(item));

If none of the values in the open_range_list satisfy the

with_expression, the bin is deemed to be excluded from the
coverpoint and is dropped. This is similar to specifying an invalid (or
a null) open_range_list. VCS generates a runtime warning to
indicate that such a bin is dropped and extends this warning to the
bins that are determined to have a null solution set satisfying the
with_expression:

Warning-[FCPSBU] Invalid values in bin

For unconstrained array bins, VCS assigns a threshold of 50000 on

the number of distinct values that can be specified in
open_range_list, and issues a runtime error when this threshold
is reached. This logic will be extended for bins under
with_expression; when the number of values of
open_range_list satisfying with_expression exceeds the set
threshold, the following error is issued and the bin is dropped:

Error-[FCABEL] Array bin limit exceeded

Setting Up Coverage Metrics

4-51
 Additions to Syntax

select_expression ::=
...
| select_expression 'with' '(' with_expression ')'
| cross_identifier

with_expression ::= expression

The with clause for the cross further restricts the set of coverpoint
bin combinations (or ‘tuples’) that are specified by the select
expression, select_expression. The subsumed combinations
must satisfy with_expression. Instead of select_expression
(that is, expression with binsof), you can also specify the cross
identifier itself (that is, the name of the cross), to indicate that the
with clause needs to be applied to all the bin combinations for the
cross. As discussed in section “Coverpoint Syntax”,
with_expression can be an arbitrary expression (including
function calls), and involves the coverpoints that compose the cross.
The expression should have at least one coverpoint (specified by the
name of the coverpoint) as an operand.

Examples
logic [0:7] a, b;

covergroup cg(bit [0:7] mask);

a1:coverpoint a
{
bins foo[] = {[0:127]};
bins bar = {[128:255]};
}
b1:coverpoint b
{
bins two[] = {[0:255]} with (item % 2);
bins three[] = {[0:255]} with (item % 3);
}

Setting Up Coverage Metrics

4-52
 X: cross a1,b1
{
bins cherry = (binsof(b1) intersect {[0:50]} &&
binsof(a1.foo) intersect {[0:50]}) with (a1==b1);
bins plum = (binsof(b1.two) with (b1 > 12)) ||
(binsof(a1.foo) with (a1 & b1));
bins apple = X with (a1+b1 < 100);
}
endgroup

The cross bin cherry demonstrates using the with clause on a

complex select_expression. First, the bin tuples consisting of a
bin from b containing a value between 0 and 50 are selected; then,
the && operator selects from these bin tuples the ones with a bin from
a.foo containing a value between 0 and 50. The with clause then
selects from these bins, the bin tuples containing at least one value
tuple where a==b.

The cross bin plum demonstrates a select_expression

composed of with expressions. The first with expression selects
the bin tuples containing bins in the b.two bin array whose values
are greater than 12. The || operator then adds the bin tuples
selected by the second with expression (those containing a bin
from a.foo and for which the bitwise AND of the a value, b value,
for some values a and b in the bins of the bin tuple).

Finally, bin apple illustrates a bin specification written without bins

of or the intersect constructs. Similar to the coverpoint bins, the
name of the cross can be used to represent the whole cross space.
This bin subsumes all bin combinations where the sum of the values
of the two constituent coverpoints is below 100.

Setting Up Coverage Metrics

4-53
 Limitations With Using the with Clause
The with clause functions with the following limitations:

• Does not support the solver for constraints involving function calls.
• The –covg_dump_range option that is meant for displaying the
values subsumed by bins in coverage reports, is not supported
for regular bins involving large bin ranges and having with
expressions on them.
• A runtime error is issued for bins that uses with clause and has
32767 matching items.

Error-[FCWCBREL] State value ranges limit

exceeded /slowfs/vgpv3/nda/with_clause/
range_error.v, 19 top, "cov1"

The number of state value ranges evaluated by the

'with' clause on bin 'b1' of coverpoint 'c1' in
covergroup 'cov1' exceeds the limit '32767'.

Covergroup instance: 'cg1'

Design hierarchy: 'top'

For example,

integer i1;

..........
c1: coverpoint i1 {
bins b1 = {[$:$]} with( item%2 == 1);

}
...........

Setting Up Coverage Metrics

4-54
Writing and Configuring Test Run Metrics

Test run metrics are non-coverage measurements and records from

a simulation run. For example, test run metrics include elapsed CPU
and clock time, number of simulation cycles, and the maximum
amount of memory used. The collective set of these metrics for a
given test run is called its test record.

The following sections discuss how you can write and configure test
run metrics:

• Automatically writing test run metrics when coverage is enabled.

See section “Writing Test Run Metrics”.
• Generating lightweight test records. See section “Generating
Lightweight Test Records”
• Reporting test run metrics using the -show tests option or any
-grade option. See section “Reporting Test Run Metrics”.
• Configuring reports to control how test run metrics are displayed
in the URG tests.txt or tests.html report. See section “Configuring
the Reports”.
• Writing the test record of a merged database. See section “Test
Record of a Merged Database”.

Setting Up Coverage Metrics

4-55
 Writing Test Run Metrics

Certain test run metrics are written automatically during a simulation

run when any type of coverage is enabled.

This metric data is stored in the same verification database (vdb)

directory in which the runtime coverage data is stored. In addition, it
is possible to retain the test run metrics for the original test runs when
merging the VDB data of the original test runs.

This feature is enabled by default; you can disable it during

simulation using the -cm_stats option with the none argument:

% simv -cm_stats none …

Generating Lightweight Test Records

VCS Coverage also provides the option to save test run metrics for
a simulation run to a lightweight VDB directory, even when coverage
is not enabled. This VDB directory will contain only the test run
metrics without any coverage information.

You can create this lightweight VDB by providing the all argument
with the –cm_stats option as follows. This forces the creation of a
lightweight VDB directory even when coverage is not enabled or
suppressed:

% simv –cm_stats all

A test record created without coverage data is called a lightweight
test record.

A VDB produced by a simulation run when coverage is not enabled

contains only the structure required for storage of the test record and
the test record file itself.

Setting Up Coverage Metrics

4-56
You can specify the name of the directory in which the lightweight
test record should be stored using the –cm_dir option as follows:

% simv –cm_stats all –cm_dir mysimv.vdb

The name of the test can be specified on the simv command line by
using the –cm_test option in conjunction with the -cm_name
option. Use the–cm_name option to designate a unique test name
under the directory (created using the –cm_dir option), in the VDB to
store the test records. Use the –cm_test option to assign the test
an unambiguous name as shown in the following example:

% simv –cm_stats all –cm_test /rand/usbp/test7 –cm_name test7

The -cm_name option provides the location where the test data
needs to be stored. If two simulations are run with the same
-cm_name value, the data of the latest simulation is overwritten over
the first. If you do not provide –cm_name option, then test is used as
a default. You can then use the –cm_test option to assign a name to
your test.

Note:
While covergroups enable themselves by default, they can be
disabled with the command line options. You can use the
-cm_stats all option in these cases to force the generation
of a test record.

For example, the following command creates no coverage data,

however, it creates a lightweight test record VDB directory:

% simv –covg_disable_cg –cm_stats all

Setting Up Coverage Metrics

4-57
 Lightweight test records are generated when you use the
–cm_stats all option in the simv command line, even if coverage
information is suppressed.

The following figures show the basic rules to generate lightweight

test record and to merge the lightweight test record. You can
generate test record-only data into full or standalone VDBs and both
types can be merged with each other.

In the following example, test1 is run without coverage, but with the
–cm_stats all option, so a test record is generated into a VDB.
test2 is also run with coverage and its results are stored in the
same VDB directory. Thus, both lightweight test records and regular
test records coexist in the same VDB directory:

In the following example, the design is compiled without coverage.

Both test1 and test2 are run with –cm_stats all, each
generating a lightweight test record.

Setting Up Coverage Metrics

4-58
In the following example, two VDBs containing lightweight test
records are merged to create a new VDB. Both test records are
preserved in the new, merged VDB, similar to regular simv runs with
coverage.

In the following example, a regular VDB is merged with a VDB

containing only lightweight test records. The resulting merged VDB
contains both lightweight and regular test records.

Setting Up Coverage Metrics

4-59
 If there are tests with the same name in two different source VDBs,
the conflict is resolved using the same name conflict merging rules
that apply to merging non-lightweight tests.

UCAPI covdbAvailableTests Relation

Whether a test record or VDB is lightweight or not, all tests appear in
the covdbAvailableTests relation. They also appear in the
output of the urg –show availabletests option.

For example, if the following tests have been created:

lightweight.vdb/lightweighttest1
mixed.vdb/lightweighttest2
mixed.vdb/regulartest3
cov.vdb/regulartest4

Every test in every VDB is displayed in the output of the –show

availabletests option as follows:

% urg –dir lightweight.vdb mixed.vdb cov.vdb –show

availabletests
Available tests names:
lightweight/lightweighttest1
mixed/lightweighttest2
mixed/regulartest3

Setting Up Coverage Metrics

4-60
 cov/regulartest4

Reporting Test Run Metrics

Using the URG -show tests option, or any -grade option

automatically displays the test run metrics for each simulation run.
With either of these options, all the test record information is listed in
the tests.html/tests.txt page below the primary list of tests. Each test
record contains Simulation time, CPU time, start time, finish time,
user name, and so on. In the HTML version, the name of a test in the
primary list is linked to its full test record.

For example, when -show tests is included, a sample URG

report is as shown in Figure 4-2. VCS generates test numbers T1,
T2, and so on for the test names.

Figure 4-2 Test Information

When you click T2, the detailed report is displayed, as shown in

Figure 4-3.

Setting Up Coverage Metrics

4-61
Figure 4-3 Detailed Test Report of test2

Table 4-1 lists the test run metrics automatically recorded by VCS.

Table 4-1 Test Run Metrics

Test Run Metrics Explanation Example
Simulation time Simulation time with unit 47885000 ms
CPUtime CPU time usage in seconds 0.5 s
Started Time simulation began Aug 07 10:25:11 AM PDT 15
Finished Time simulation ended Aug 07 10:25:12 AM PDT 15
Peak memory Maximum memory use 101880 kb
Host Name of machine that ran
simulation
User User id that ran simulation
Command line Simulation command line simv -cm line -cm_name
test2
Directory Directory path

Setting Up Coverage Metrics

4-62
Reporting Lightweight Test Records
The rules for reporting lightweight VDBs are shown in the following
figures (the rules apply to both URG and Verdi/DVE). You can report/
load VDBs containing only lightweight test records or mixed
lightweight and regular VDBs together using the following
commands:

urg -dir lightweight.vdb -show tests

or

urg -dir mixed.vdb -dir cov.vdb -grade [grade_type] ...

Setting Up Coverage Metrics

4-63
 Configuring the Reports

Some test run metrics can be displayed in the primary list of tests
next to the coverage scores and test names. This can be used for a
quick reference or for sorting the tests using one of these metrics.
Test run metrics are only displayed in the primary list of tests when
the grade option is used. Specify the type of test grading to perform
as the sub-argument to the -grade option (for example, -grade
index), or use -grade list to create a primary test table without
grading the tests.

For example,

% urg -dir simv.vdb -grade index list \

columns cputime+clocktime …
This generates a primary list of tests with their CPU times and clock
times. The sub-arguments passed to columns must be separated
by the “+” symbol, and include seed, seed48, simtime, cputime,
and clocktime.

Cost-based grading shows the cost type selected for grading and the
running total of that metric, by default. For example, if -grade cost
simtime is used, row #N in Table 4-1 shows the simulation time for
test #N along with the simulation time total of the tests 1 through N.
You can modify the default behavior and add more columns using
the columns argument.

Setting Up Coverage Metrics

4-64
 Example 1

A sample output of the following urg command with -grade list

only lists the tests, as shown in Figure 4-4. No test metrics are shown
as the -grade columns option was not included.

% urg -dir simv.vdb -grade list

Figure 4-4 Tests List

Setting Up Coverage Metrics

4-65
 Test Record of a Merged Database

While merging the VDBs, the test record information is generated

and is available in the URG report.

For example, execute the following command line to gather the test
record information of a merged database:

% urg -dir simv1.vdb -dir simv2.vdb -dbname merged.vdb

-format both

This command gathers the test record from each run in the
test.xml file in the merged database because of the inclusion of
the -dbname option.

Note:
To dump test records while merging vdbs, it is not required to pass
the -show tests option.

The -show tests option only controls the display of the test
records/test correlation data in the URG reports. You can generate
the URG report with the test record of the merged database using the
following command:

% urg -dir merged.vdb -show tests

Setting Up Coverage Metrics

4-66
Limitations

The following are the limitations with this feature:

• Passing the -cm_stats option to the vcs command line with the
-R option is not supported.
• Random seed information is only available when there is
covergroup data for the test.

Setting Up Coverage Metrics

4-67
Setting Up Coverage Metrics
4-68
5
Merging Coverage Metrics 1
Merging is used to analyze the coverage status of your design and
testbench across all simulation runs.

Merging creates a single database of merged data that contains all

the coverage information from your simulation runs.

You can create a merged coverage database by passing the

-dbname option to the URG command line. For example,

% urg -dir simv.vdb -dbname merged_dir/merged_test -format

text

This command creates merged_dir.vdb, which contains a single

test object named merged_test. This test contains the merged
coverage results from all test runs found in the simv.vdb directory.

The following command creates merged_dir3.vdb with the

default test name test.

Merging Coverage Metrics

5-1
 % urg -dir simv.vdb -dbname merged_dir3 -format text

If you specify the -show tests option to URG when merging, the
resulting merged database notes, for each covered object, which
tests covered it, up to a maximum number of tests per object. You
can also specify the maximum number of tests to be stored for each
object using the -db_max_tests option, as follows:

% urg -dir simv.vdb -dbname merged_dir3 -show tests

-db_max_tests 20

This creates merged_dir3.vdb with a maximum of 20 tests stored

for each covered object. This test correlation data can be shown in
generated reports using the -show tests option. It also plays a
role in test grading of the merged VDB. For details on test grading,
see Chapter, “Grading Tests for Coverage” .

URG provides two methods of merging - Serial and Parallel Merging.

You can either choose serial or parallel merging based on the size
and number of the databases, as described in the following sections:

• “Serial Merging”
• “Parallel Merging”
You can also use the following algorithms to influence how coverage
data from different tests is combined when merging:

• Default merge
• Flexible merge
• Union merge
• Reference merge

Merging Coverage Metrics

5-2
 Any of these algorithms can be used with either serial or parallel
merging. The following sections describe each algorithm. The choice
of algorithm generally affects only covergroup data, however,
reference merging has an impact on assertions data as well.

• “Default Merging for Covergroups”

• “Flexible Merging for Covergroups”
• “Union Merging for Covergroups”
• “Reference Merging for Covergroups and Assertions”

Serial Merging

The default mechanism URG employs to merge test results is serial

merging.As the name implies, this technique merges coverage data
of numerous tests one after the other, serially.

For example, consider that you have run four tests and therefore
have four sets of test results. When you employ serial merging on
these tests, it starts merging the test results of the with the first two
tests. It then merges this merged results with the results from the
third test, then merges the new merged results with the results from
the fourth test to generate the final merged test result.

Serial merging is suitable in cases with limited amount of coverage

data or fewer number of test results that need to be merged. In cases
with a huge amount of coverage data or higher number of test
results, serial merging might not be a preferable solution as it might
take a considerable amount of time to complete the task.

Merging Coverage Metrics

5-3
Parallel Merging

Coverage data can be merged in parallel to significantly speed up

processing. With URG’s parallel merge feature, URG divides the
tests to be merged into separate groups. As those groups finish, they
are also divided into parallel jobs, until the final merge is done.

Coverage offers the parallel merging technique that is suitable in

scenarios where there is a huge amount of coverage data that needs
to be merged. You can merge coverage data using parallel merging
by specifying the -parallel option on the urg command line.

When you use parallel merging, the urg_parallel.elog file is

created. This file records warnings and errors that occur during one
of the sub-processes. If you specify the -verbose option, the
following type of message is generated: . Status: 13 Mergings, 1
remain (12 Done, 0 Running, 1 on queue, 0 waiting)

Merging the Final One

The error messages of sub-jobs are saved in
urg_parallel.elog.
Distributed Merging SUCCESSFUL!!!
Note:
In this technology, this underlying mechanism is associating
coverage data with each other, not creating new or different
coverage data.

As an example, consider that twelve coverage databases need to be

merged. Parallel merging is ideal in this situation as there are large
number of databases that needs to be merged.

Merging Coverage Metrics

5-4
 Figure 5-1 shows how these twelve coverage databases are merged
using the parallel merging technique. In the first pass, URG merges
test0, test1, test2, and test3 into one group; test4, test5,
test6, and test7 into a second group; and test8, test9,
test10, and test11 into a third group.

Figure 5-1 Parallel Merging of Twelve Tests

test0

test1

job1
test2

test3

test4

test5

job2 job4
test6

test7

test8

test9

job3
test10

test11

In parallel merging, a job refers to the process of creating each

group. In this scenario, URG runs three jobs to create three groups

Merging Coverage Metrics

5-5
 in the first pass. It then combines these three groups in a fourth job
into a single result.

Notice that there is a hierarchy of levels to the jobs. The first three
jobs are on the first level, the fourth job is on the second level.

You can control the number of tests that URG merges into a group,
and the number of lower level groups that go into a higher level
merging. If you specify a smaller the number of tests to be
considered per merging, it results in a higher number of jobs (and
thereby levels) created to complete parallel merging.

Specifying the Number of Tests in Merging

You can specify the number of tests that should be considered for
merging, and the number of lower-level mergings in a higher-level
merging, using the -parallel_split integer option, as
follows:

urg -dir base.vdb simv1.vdb simv2.vdb -parallel

-parallel_split 5

If you specify a lower number of tests per merge, the number of jobs,
and the associated levels increases. Therefore, for twelve tests,
specifying a value of 3 creates six jobs on three levels and specifying
a value of 6 creates three jobs on two levels.

You can perform parallel merging using one of the following

methods:

• “Specifying Hosts to Execute Jobs”

• “Using a GRID Computing Engine”

Merging Coverage Metrics

5-6
• “Using an LSF Engine”

Specifying Hosts to Execute Jobs

You can choose the machines on your network that you want to run
parallel merging jobs on. To do so, list the machine names on
separate lines in a text file and provide the file name as an argument
to the -parallel option.

The following is an example of a file named machine_file with the

machine names listed:

RHEL32_machine1
RHEL32_machine2
RHEL32_machine3
RHEL32_machine4

You can pass machine_file as an argument to the -parallel

option as follows:

% urg -dir test0.vdb test1.vdb test2.vdb test3.vdb test4.vdb\

test5.vdb test6.vdb test7.vdb test8.vdb test9.vdb \
test10.vdb test11.vdb -parallel machine_file

Using a GRID Computing Engine

You can run your parallel merging operation on a GRID computing

engine and pass optional arguments to that engine using the -grid
command-line option. You pass the optional arguments for the
engine in quotation marks that follow the option, as shown in the
following example.

Following the -grid option, you can pass the secondary options
-sub and -del to run and clear the GRID engine respectively.

Merging Coverage Metrics

5-7
 % urg -dir test0.vdb test1.vdb test2.vdb test3.vdb \
test4.vdb test5.vdb test6.vdb test7.vdb test8.vdb \
test9.vdb test10.vdb test11.vdb -parallel -grid \
"-l arch=1x24-amd64 -P bnormal" -sub qsub -del qdel

In this example, URG starts the GRID engine with the qsub
command. URG appends -l arch=1x24-amd64 -P bnormal to the
qsub command line. After parallel merging, URG passes the qdel
command to the engine to clear the engine.

Using an LSF Engine

You can also run your parallel merging operation on an LSF engine
using the -lsf command-line option. Similar to the -grid option,
you pass the optional arguments to the engine in quotation marks
that follow the option.

With the -lsf option, you must enter the secondary options, -sub
and -del, to enter the commands to create and control jobs in the
engine. The following is an example of using the -lsf option:

% urg -dir test0.vdb test1.vdb test2.vdb test3.vdb \

test4.vdb test5.vdb test6.vdb test7.vdb test8.vdb \
test9.vdb test10.vdb test11.vdb -parallel -lsf \
"-q queuename -R res_req" -sub bsub -del bkill ...

Merging Coverage Metrics

5-8
Merging Covergroups

While the overall algorithm for merging covergroup coverage is the

same as for code coverage, there are some differences and more
choices available for covergroup merging. These differences largely
arise from the fact that each simulation run may have a different set
of covergroups in it, and that those groups may have different
shapes/numbers and types of bins due to parameterization. This
section discusses the special merging features that apply only to
covergroups.

Default Merging for Covergroups

While merging covergroups in the default flow, if two tests contain

different versions of the same covergroup, the two versions are
treated as two separate covergroups and two copies of that group
are shown in the reports. Consider the following versions of the
covergroup, cg () present in two different tests,

Table 5-1 Covergroups in Two Tests

Test1 Test2
covergroup cg(); covergroup cg();
cp: coverpoint a cp: coverpoint a
{ {
bins b1 = {[3'b000:3'b011]}; bins b1 = {[3'b000:3'b011]};
bins b2 = {[3'b100:3'b111]}; bins b2 = {[3'b100:3'b101]};
} bins b3 = {[3'b110:3'b111]};
}
endgroup
endgroup

To merge the covergroups in the default mode, use the following

command:

% urg -dir simv1.vdb simv2.vdb -format both

Merging Coverage Metrics

5-9
 The merged result is displayed as shown in Figure 5-2.

Figure 5-2 Default Merged Report

Flexible Merging for Covergroups

This merging technique is available only for covergroup coverage.

Flexible merging enables you to get a more accurate coverage
report when the coverage model is still evolving and you are running
tests repeatedly with minor changes in the coverage model between
the test runs. URG facilitates flexible merging using a new merge
database option. It follows a set of rules to merge databases
depending on the functional coverage model.

To enable flexible merging, use the -group flex_merge_drop

option on the URG command line, as follows:

% urg -dir simv1.vdb -dir simv2.vdb -group flex_merge_drop

URG assumes the first specified coverage database as a reference
for flexible merging.

Merging Coverage Metrics

5-10
Example

Consider two databases, first.vdb and second.vdb. Using the

-group flex_merge_drop option and flexible merging database
rules, URG generates a merged report. For example:

% urg -dir first.vdb -dir second.vdb -group flex_merge_drop

In this example, URG considers the first.vdb coverage database

directory as a reference to generate the flexible merged report.

Merge Equivalence
To merge two coverpoints or crosspoints, you should merge them
equivalent to each other. The following section lists the requirements
for merge equivalence.

Merge Equivalence Requirements for Autobin Coverpoints

The coverpoint P1 is said to be merge equivalent to a
coverpoint P2 only if the name, auto_bin_max and the width of
the coverpoints are the same, where P1 and P2 are autobin
coverpoints.

Merge Equivalence Requirements for User-Defined Coverpoints

The coverpoint P1 is said to be merge equivalent to a
coverpoint P2 only if the coverpoint names and width are the
same.

Merging Coverage Metrics

5-11
 Merge Equivalence Requirements for Crosspoints
The crosspoint C1 is said to be merge equivalent to a
crosspoint C2, if the crosspoints have the same number of
coverpoints and their corresponding coverpoints are merge
equivalent.

Rules for Flexible Merging of Databases

The following sections list the rules that govern the merging of
databases with flexible merge dropping semantics. By dropping
semantics, you can take advantage of the information available from
a newer database to eliminate the redundant information from the
older databases.

Rules for Merging Coverpoints

The coverpoints P(T1) in first test run T1 and P(T2) in the
second test run T2 are merged according to the following rules:

• If the coverpoints are merge equivalent: The merged coverpoints

will contain a union of all the coverpoint bins in P(T1) and P(T2),
but URG will drop the coverpoint bins that are defined only in the
earlier coverage model.
• If the coverpoints are not merge equivalent: The merged
coverpoint will contain all the coverpoint bins in the most recent
test run and the older test run data is not considered and dropped.

Merging Coverage Metrics

5-12
 Rules for Merging Crosspoints
The crosspoint C(T1) in test T1 and C(T2) in test T2 are
merged according to the following rules:

• If the crosspoints are merge equivalent: The merged crosspoints

will contain a union of all the crosspoint bins in C(T1) and C(T2),
but URG will drop the crosspoint bins that are defined only in the
earlier coverage model.
• If the crosspoints are not merge equivalent. The merged
crosspoint will contain all the crosspoint bins in the most recent
test run and the older test run data is not considered and dropped.

Example
The example discusses two tests with minor changes in the
functional and assertion coverage models. The changes are marked
in boldface.

Example 5-1 Test01

cp1: coverpoint firstsig;
option.auto_bin_max = 64;
cp2: coverpoint secondsig {
bins first = {[0:63]};
bins mid = {[71:82]};
}
cp3: coverpoint thirdsig;
bit[7:0]signal;
cp4:coverpoint signal;
cc1: cross cp1, cp2;
cc2: cross cp2, cp3 {
bins mybin = binsof(cp2) intersect [0:255];
}
cc3: cross cp2, cp3 {
bins my_st = binsof(cp2) intersect [0:255];
}

Merging Coverage Metrics

5-13
Example 5-2 Test02
cp1: coverpoint firstsig;
option.auto_bin_max = 32;
cp2: coverpoint secondsig {
bins first = {[0:63]};
bins second = {[65:128]};
}
cp3: coverpoint thirdsig;
bit[15:0]signal;
cp4:coverpoint signal;
cc1: cross cp1, cp2;
cc2: cross cp2, cp3 {
bins mybin = binsof(cp2) intersect [0:255];
bins yourbin = binsof(cp2) intersect [256:511];
}
cc3: cross cp2, cp3 {
bins my_st = binsof(cp2) intersect [0:8191];
}
cc4: cross cp1, cp2, cp3
The two coverage model examples can be used to analyze the
flexible merged database. In this example test 02 is the latest test
that is run, and is the reference coverage database. URG considers
the first database specified as the reference coverage database
directory.

urg -dir test02.vdb -dir test01.vdb -group flex_merge_drop

Coverpoint Analysis

• cp1, the auto_bin_max is changed to 32,therefore they are

not merge equivalent and only cp1 data from test 02 is included
in the generated report.

Merging Coverage Metrics

5-14
• The coverpoint cp2 is merge equivalent and the data from
both the tests are merged. The new bin second, added in test02
is included in the generated report, but the bin mid from the
previous test test01 is dropped from the generated report
since it is removed from latest test test02 coverage model.
• The coverpoint cp3 is unchanged. The data from both the
tests are merged to be included in the generated report.
• cp4, the signal width is changed, therefore they are not merge
equivalent and only test02 data is included in the generated
report.
Crosspoint Analysis

• cc1, the component pair of coverpoint cp1 is not merge

equivalent, therefore only data from the test02 is included in
the generated report.
• cc2, a new bin yourbin is added, but the component pair of
coverpoint cp2 and cp3 are merge equivalent and therefore
the data from both the tests are merged to be included in the
generated report.
• cc3, the component coverpoint cp2 intersect range is
changed. They are not merge equivalent and user defined my_st
will be considered only from test02, but the auto-crosses in
test01 will be merged with the auto-crosses in test02.
• The crosspoint cc4 is a new introduction in test02 and is
included in the generated report.

Merging Coverage Metrics

5-15
Table 5-2 Flexible Merge Database
Coverage Model for Coverage Model for Flexible Merge Database Profile for
test01 test02 test01 and test02 (test02 is the
recent database and test01 is the
old database.)
cp1: coverpoint firstsig; cp1: coverpoint firstsig; //auto_bin_max differs and is not
option.auto_bin_max = option.auto_bin_max = 32; merge equivalent.
64;
cp1: coverpoint firstsig;
auto_bin_max = 32;
// (From test02)
cp2: coverpoint cp2: coverpoint // (cp2 is merged across test01 and
secondsig{ secondsig{ test02)
bins first = {[0:63]}; bins first = {[0:63]}; cp2: coverpoint secondsig {
bins mid = {[71:82]};} bins second = bins first = {[0:63]};
{[65:128]};} bins second = {[65:128]};}
cp3: coverpoint thirdsig; cp3: coverpoint thirdsig; //cp3 is merged across test01 and
test02
cp3: coverpoint thirdsig;
bit[7:0]signal; bit[15:0]signal; //width of signal has changed and not
cp4: coverpoint signal; cp4: coverpoint signal; merge equivalent
cp4: coverpoint signal;
// (From test02)
cc1: cross cp1, cp2; cc1: cross cp1, cp2; // cc1 is not merged equivalent
because cp1 is not merge equivalent
cc1: cross cp1, cp2;
// (From test02)
cc2: cross cp2, cp3 { cc2: cross cp2, cp3 { // cc2 is merged across test01 and
bins mybin = binsof(cp2) bins mybin = binsof(cp2) test02)
intersect [0:255]; } intersect [0:255]; cc2: cross cp2, cp3 {
bins yourbin=binsof(cp2) bins mybin = binsof(cp2)
intersect [256:511];} intersect [0:255];
bins yourbin = binsof(cp2) intersect
[256:511];}
cc3: cross cp2, cp3 { cc3: cross cp2, cp3 { cc3: cross cp2, cp3 {
bins my_st = binsof(cp2) bins my_st = binsof(cp2) bins my_st = binsof(cp2)
intersect [0:255];} intersect [0:8191];} intersect [0:8191];}
The autocrosses in test01 will be
merged with the autocrosses of test
02.

Merging Coverage Metrics

5-16
 Coverage Model for Coverage Model for Flexible Merge Database Profile for
test01 test02 test01 and test02 (test02 is the
recent database and test01 is the
old database.)
- cc4: cross cp1, cp2, cp3; cc4: cross cp1, cp2, cp3;
// (From test02)

Union Merging for Covergroups

This merging technique is available only for covergroup coverage.

Union merging enables you to retain both previous and new versions
of coverpoints and crosses in the final merged result and in the
reports. It enables you to gather and merge covergroup data from
ongoing simulation runs even as the coverage model is changing,
without losing any data from any version of the model.

The key value is that the coverage gathered for all versions of all
parts of a covergroup is retained, and the data for parts that does not
change is merged across all the test runs. In contrast, reference
merge splits covergroups that have any differences between them,
along with their data. Flexible merge is similar to union merge, but
flexible merge discards data from the changed parts of a covergroup,
whereas union merge saves the data for each changed part so that
data can be retrieved later if the covergroup definition changes .

Figure 5-3 illustrates the union merging flow. As simulations run with
different models, all variations are combined to produce a superset
coverage model and to merge the merge-able data down to the
coverpoint bin level. When it is required to generate a snapshot, a
specific reference model is chosen and the superset coverage data
is extracted based only on the coverage objects in the union-merged
database that match those in that reference model.

Merging Coverage Metrics

5-17
Figure 5-3 Union Merging for Various Coverage Model Variants

Note:
Code coverage is not supported with union merging.

You can perform union merging in URG using the union merge
report-time option. To enable union merging, use the union option
along with -flex_merge on the urg command line, as follows:

% urg -dir new.vdb -dir old.vdb -flex_merge union -dbname

merge

Merging Coverage Metrics

5-18
 Rules for Union Merging of Databases
Flexible merging preserves coverage data from coverpoints and
crosses that exist in the latest version of each covergroup. In
contrast, union merging preserves all coverpoints and cross
coverage data seen in each covergroup across all simulation runs
even as they change.

Table 5-3 outlines the rules of union merging. Union merging is

performed regardless of the order and there is no reference version.
Therefore, for a given coverpoint or cross P, the following rules
apply:

Table 5-3 Union Merging Rules for Changed Coverpoints or Crosses

Version A Version B Union Merge Result
P P does not exist Contains coverpoint P

P New merge-equivalent version Data from identical bins in version A and B are
of P merged.
Bins unique in either A or B are preserved with
their coverage data.
Bins with the same name but different in A and
B are preserved as multiple copies, each with
their own unmerged data.
P New version of P that is not Two coverpoints named P appear in the final
merge-equivalent merged result, one containing A's data and one
containing B's data

Union merging is performed on a covergroup-by-covergroup basis

and happens without splitting a covergroup. For example, all of the
following changes are compatible with union merge:

• New or deleted coverpoints or crosses

• Merge equivalent changes to coverpoints and crosses

Merging Coverage Metrics

5-19
 • Changes to coverpoints or crosses that make them not merge-
equivalent
• Changes to a sampling event
• Changes to the argument list of the covergroup
Therefore, the resulting merged covergroup is not a legal
SystemVerilog code (for example, union merge result might have
multiple versions of a single bin, or of a single coverpoint with the
same name). However, the coverage analysis tools and report
generators can still report such groups.

Scoring
Scores are computed normally during union merging. In the default
mode, the scores of each coverpoint and cross are averaged
together to compute the score of the group. In group ratio mode, all
numerators (covered count) of coverpoints and crosses are added
and divided by the sum of all denominators (coverable). For more
information about computing scores by ratio, see section Compute
Coverage Score by Ratio in the Coverage Technology Reference
User Guide.

A union merged covergroup may contain multiple copies of the same

coverpoint or cross. Scoring treats each of these copies as a
separate coverpoint, as if it had a unique name. Therefore, when a
coverpoint is duplicated, both of its scores (or both of its sets of
numerators/denominators) are used to compute the covergroup's
score.

Merging Coverage Metrics

5-20
Merging
The merging rules described in the section “Rules for Union Merging
of Databases” explain what happens in union merge mode. This
section discusses how other merging modes handle databases
created in union merge mode.

The following are the other merging modes besides union merging:

• Reference merge: This technique merges covergroups with the

same name and shape, but splits covergroups into two copies if
the shape (checksum) has changed.
• Flexible merging: This technique also uses a reference database
and only discards data from changed covergroups at a coverpoint
and a cross level.
The databases input to reference or flexible merging can be created
either by reference, or flexible, or union merging. The result of a
reference merge of two databases splits covergroups with different
shapes; the result of a flexible merge of two databases eliminates
data from non-merge-equivalent covergroup elements.

Examples
This section illustrates the various examples that are union merged.
Consider two code versions, Version A and Version B of a
covergroup G that are union merged. Note that these examples do
not define any functionality.

Merging Coverage Metrics

5-21
 Non-Merge-Equivalent Coverpoints

In Table 5-4, all the variations in coverpoints are not merge-

equivalent, so in each case the coverpoint or cross that has changed
is duplicated:

Table 5-4 Non-Merge-Equivalent Coverpoints

Version A Version B Union merge result Data is extracted
from
reg [3:0] P, Q; reg [3:0] Q; covergroup G;
covergroup G; covergroup G; coverpoint P; A only
coverpoint P; coverpoint Q; A and B
coverpoint Q; coverpoint Q; endgroup
endgroup endgroup

reg [3:0] P, Q; reg [7:0] Q;

reg [3:0] P;
covergroup G; covergroup G; covergroup G;
coverpoint P; coverpoint P; coverpoint P; A only
coverpoint Q; coverpoint Q; coverpoint Q; (4 bits) A only
coverpoint Q; (8 bits) B only
endgroup endgroup endgroup

covergroup G; covergroup G; covergroup G;

coverpoint R; coverpoint R; A only
option. option.
auto_bin_max=64; auto_bin_max=64;
coverpoint R; coverpoint R; B only
option. option.
auto_bin_max=32; auto_bin_max=32;
endgroup endgroup endgroup

Changes in the Sampling Event

Changes in the sampling event for a covergroup have no effect on

the merged shape (same as the latest). Therefore, a covergroup with
no changes to its coverpoints or crosses whose sampling event has
changed will not have duplicated coverpoints or crosses.

Merging Coverage Metrics

5-22
 Merge-Equivalent Coverpoints

When coverpoints are merge-equivalent, the bins from the different

versions are union merged together to create the final result instead
of duplicating the coverpoint or cross.

Note:
If a new bin is added and another bin deleted, all bins are still
displayed in the merged result. If a bin itself changes, the hit counts
of the bin are added up in the merged result.

Table 5-5 Merge-Equivalent Coverpoints

Version A Version B Union Merge Result Data Used
reg [3:0] P, Q; reg [3:0] Q;
covergroup G; covergroup G; covergroup G;
coverpoint P; coverpoint P; coverpoint P; A and B
coverpoint Q { coverpoint Q { coverpoint Q {
bins x={[0]}; bins x={[0]}; bins x={[0]}; A and B
bins y={[1]}; bins y={[1]}; A only
bins z={[2]}; bins z={[2]}; B only
}; }; };
endgroup endgroup endgroup

reg [3:0] P, Q; reg [3:0] P, Q; reg [3:0] P, Q;

covergroup G; covergroup G; covergroup G;
coverpoint P; coverpoint P; coverpoint P; A and B
coverpoint Q { coverpoint Q { coverpoint Q {
bins x={[0]}; bins x={[0]}; bins x={[0]}; A and B
bins y={[1]}; bins y={[1,2]}; A and B
bins y={[2]}; };
}; }; endgroup
endgroup endgroup

Merging Coverage Metrics

5-23
 Cumulative Changes Over Time

Table 5-6 shows an example of how repeated changes to a simple

covergroup can result in a complex union merged group. Each row
after the first merge starts with the union merged result from the row
above it. Even though the covergroup has two coverpoints and one
cross, by the end of the variations there are four coverpoints and four
crosses being maintained.

Table 5-6 Cumulative Changes Over Time

Version A Version B Union Merge Result Data Used
reg [3:0] P, Q; reg [7:0] P, Q;
covergroup G; covergroup G; covergroup G;
coverpoint P; coverpoint P; coverpoint P; (4 bits) A only
coverpoint Q; coverpoint Q; coverpoint P; (8 bits) B only
cross P, Q; cross P, Q; coverpoint Q; (4 bits) A only
endgroup endgroup coverpoint Q; (8 bits) B only
cross P, Q; (4 bits) A only
cross P, Q; (8 bits) B only
endgroup
(union merged result) reg [7:0] P;
covergroup G; reg [3:0] Q; covergroup G;
coverpoint P; (4 bits) covergroup G; coverpoint P; (4 bits) A only
coverpoint P; (8 bits) coverpoint P; coverpoint P; (8 bits) A (8 bits) and B
coverpoint Q; (4 bits) coverpoint Q; coverpoint Q; (4 bits) A (4 bits) and B
coverpoint Q; (8 bits) coverpoint Q; (8 bits) A only
cross P, Q; (4 bits) cross P, Q; (4 bits) A only
cross P, Q; (8 bits) cross P, Q; (8 bits) A only
endgroup cross P, Q; cross P, Q; (8x4 bits) B only
endgroup endgroup

(union merged result) reg [3:0] P;

reg [7:0] Q;
covergroup G; covergroup G; covergroup G;
coverpoint P; (4 bits) coverpoint P; coverpoint P; (4 bits) A (4 bits) and B
coverpoint P; (8 bits) coverpoint P; (8 bits) A only
coverpoint Q; (4 bits) coverpoint Q; (4 bits) A only
coverpoint Q; (8 bits) coverpoint Q; coverpoint Q; (8 bits) A (8 bits) and B
cross P, Q; (4 bits) cross P, Q; (4 bits) A only
cross P, Q; (8 bits) cross P, Q; (8 bits) A only
cross P, Q; (8x4 bits) cross P, Q; (8x4 bits) A only
cross P, Q; cross P, Q; (4x8 bits) B only
endgroup endgroup endgroup

Merging Coverage Metrics

5-24
 Depending on how much the coverage model changes, the result
consists of large, complex groups, points, and crosses containing
many incompatible elements.

Added Coverpoint

Consider that the covergroup cg3 has one coverpoint in version A

and an additional coverpoint in version B (italicized indicates a
covered object and boldface indicates an uncovered object).

The merged result is the coverage from version A and version B that
are merged; the union of coverpoints in both covergroups is retained.

Table 5-7 Added Coverpoint

Version A Version B
covergroup cg3; covergroup cg3;
coverpoint data2; coverpoint data2;
coverpoint data3;
endcovergroup
endcovergroup

The following is the merged result for Version A and Version B:

Command Default Result Union Merged Result

urg -dir A.vdb B.vdb covergroup cg3;
coverpoint data2;
endcovergroup
covergroup cg3;
coverpoint data2;
coverpoint data3;
endcovergroup covergroup cg3;
coverpoint data2;
coverpoint data3;
urg -dir A.vdb B.vdb covergroup cg3;
endcovergroup
group flex_merge_drop coverpoint data2;
endcovergroup

urg -dir B.vdb A.vdb covergroup cg3;

group flex_merge_drop coverpoint data2;
coverpoint data3;
endcovergroup

Merging Coverage Metrics

5-25
 Non-Intersecting Coverpoints

Consider that covergroup cg3 has coverpoint data2 in version A

and coverpoint data3 in version B. In the merged result, cg3 will
have both data3 and data2. Only the coverpoint in the reference
VDB (first one passed) is retained.

Table 5-8 Non-Intersecting Coverpoints

Version A Version B
covergroup cg3; covergroup cg3;
coverpoint data2; coverpoint data3;
endcovergroup
endcovergroup

The following is the merged result for Version A and Version B:

Command Default Result Union Merged Result

urg -dir A.vdb B.vdb covergroup cg3;
coverpoint data2;
endcovergroup
covergroup cg3;
coverpoint data3;
endcovergroup
covergroup cg3;
coverpoint data2;
urg -dir A.vdb B.vdb covergroup cg3;
coverpoint data3;
group flex_merge_drop coverpoint data2;
endcovergroup
endcovergroup
urg -dir B.vdb A.vdb covergroup cg3;
group flex_merge_drop coverpoint data3;
endcovergroup

Merging Coverage Metrics

5-26
 Overlapping Set of Coverpoints

Consider that version A has coverpoint data1 that is not in Version

B, and Version B has coverpoint data3 that is not in Version A. The
union merged covergroup result contains data1, data2, and
data3 in the final merged result.

Table 5-9 Overlapping Set of Coverpoints

Version A Version B
covergroup cg3; covergroup cg3;
coverpoint data1;
coverpoint data2;
coverpoint data2;
coverpoint data3;
endcovergroup
endcovergroup

The following is the merged result of Version A and Version B:

Command Default Result Union Merged Result

urg -dir A.vdb B.vdb covergroup cg3;
coverpoint data2;
coverpoint data3;
endcovergroup
covergroup cg3;
coverpoint data1;
coverpoint data2;
endcovergroup

covergroup cg3;
urg -dir A.vdb B.vdb covergroup cg3;
coverpoint data1;
group flex_merge_drop coverpoint data1;
coverpoint data2;
coverpoint data2;
coverpoint data3;
endcovergroup
endcovergroup

urg -dir B.vdb A.vdb covergroup cg3;

group flex_merge_drop coverpoint data2;
coverpoint data3;
endcovergroup

Merging Coverage Metrics

5-27
 Difference in auto_bin_max

Consider that the versions of coverpoint cp1 in versions A and B are

not merge equivalent, because they have different auto_bin_max
option values in each version.

Table 5-10 Difference in auto_bin_max

Version A Version B
covergroup cg3; covergroup cg3;
cp1: coverpoint firstsig; cp1: coverpoint firstsig;
option.auto_bin_max = 64;
option.auto_bin_max = 32;
endcovergroup
endcovergroup

The following is the union merged result with two copies of cp1:

Union Merged Result With Two Copies of cp1

covergroup cg3;
cp1: coverpoint firstsig;
option.auto_bin_max = 32;
cp1: coverpoint firstsig;
option.auto_bin_max = 64;
endcovergroup

Merging Coverage Metrics

5-28
 Overlapping Copy of Coverpoints

Consider the result of the preceding example and perform reference

or union merge with another database.

Table 5-11 Overlapping Copy of Coverpoint

Version A Version B
covergroup cg3; covergroup cg3;
cp1: coverpoint firstsig; cp1: coverpoint firstsig;
option.auto_bin_max = 32;
option.auto_bin_max = 32;
cp1: coverpoint firstsig;
endcovergroup option.auto_bin_max = 64;
endcovergroup

With this data, you observe that for reference merge, the data for the
second copy of cp1 (with max 64) is discarded, as follows:

Reference merge result with A as reference Notes

model
covergroup cg3; For reference merge, the data from
cp1: coverpoint firstsig; versions A and B of the 32-bin cp1 will be
merged. The 64-bin cp1 and all of its data
option.auto_bin_max = 32;
is discarded.
endcovergroup

Union merged result with Version A as the reference model remains

same as the following results:

Reference or union merge result with B as Notes

reference model
covergroup cg3; For reference or union merge, the data
cp1: coverpoint firstsig; from versions A and B of the 32-bin cp1
will be merged. The 64-bin cp1 and its
option.auto_bin_max = 32;
data from version B is retained.
cp1: coverpoint firstsig;
option.auto_bin_max = 64;
endcovergroup

Merging Coverage Metrics

5-29
 Superset of Previous Covergroup

Consider versions A and B, where version B is a superset of A.

Table 5-12 Superset of Previous Covergroup

Version A Version B
covergroup cg3; covergroup cg3;
coverpoint data1; coverpoint data1;
coverpoint data2;
coverpoint data2;
coverpoint data3;
endcovergroup
endcovergroup

The following is the reference merged result of A and B, with A as

reference model:

Reference merge result of A and B, with A as Notes

reference model
covergroup cg3; For reference merge, the data from
coverpoint data1; version B for data1 and data2 is merged;
the data from data3 from B is discarded.
coverpoint data2;
endcovergroup

Union merge result of A and B, with A as reference model remains

the same as the following results.The following is the reference or
union merge result of A and B, with B as a reference model:

Reference or Union merge result of A and B, Notes

with B as reference model
covergroup cg3; For reference or union merge, the data
coverpoint data1; from version A for data1 and data2 is
merged; the data from data3 from B is
coverpoint data2;
retained.
coverpoint data3;
endcovergroup

Merging Coverage Metrics

5-30
Reference Merging for Covergroups and Assertions

Reference merging helps you can eliminate the covergroups and

assertions/cover properties that are not present in the latest
database (referred as reference/base/latest database). This merging
technique is available only for coverage for covergroups and
assertions. (Code coverage does not allow merging multiple
versions of the design.)

Flexible merging of covergroups using the -group

flex_merge_drop option enables you to obtain a merged
coverage report when the coverage model is still evolving, and when
you are running tests repeatedly with minor changes in the coverage
model between test runs. Along with the report of the latest
database, the covergroups that are not present in the latest
coverage model are also reported.

To eliminate the reporting of covergroups that are present only in the

reference database, use the -flex_merge reference option on
the urg command line, as follows:

% urg -dir latest.vdb -dir old.vdb -flex_merge reference

Note:
The -flex_merge drop option can be used as an equivalent
to -group flex_merge_drop. The drop option to
-flex_merge enables drop mode of flexible merging for
covergroups. For more information about -group
flex_merge_drop, see Section “Flexible Merging for
Covergroups”

Merging Coverage Metrics

5-31
 Example - Covergroup Metrics
Consider the latest and the older version of the design source code
file, test.v shown in the following table:

Table 5-13 Design Source Code

test.v (older version) test.v (latest version)
module top; module top;
bit cp1, cp2, cp3; bit cp1, cp2, cp3;

covergroup cg2; covergroup cg2;

coverpoint cp1; coverpoint cp1;
coverpoint cp3; coverpoint cp2;//ADDED
coverpoint cp4; coverpoint cp3;
option.per_instance = 1; coverpoint cp4;
End group option.per_instance = 1;
endgroup
covergroup cg1;
coverpoint cp1; covergroup cg1; //DELETED
coverpoint cp2; coverpoint cp1;
coverpoint cp3; coverpoint cp2;
option.per_instance = 1; coverpoint cp3;
endgroup option.per_instance = 1;
endgroup
cg2 inst2 = new(); cg2 inst2 = new();
cg1 inst1 = new(); cg1 inst1 = new();//DELETED
bot b();
bot b(); endmodule
endmodule
module bot();
module bot(); bit cp1, cp2, cp3;
bit cp1, cp2, cp3;
covergroup cg;//DELETED
covergroup cg; coverpoint cp1;
coverpoint cp1; coverpoint cp2;
coverpoint cp2; coverpoint cp3;
coverpoint cp3; option.per_instance = 1;
option.per_instance = 1; endgroup
endgroup
covergroup cg3;
cg inst = new(); coverpoint cp1;
coverpoint cp2;
endmodule coverpoint cp3;
option.per_instance = 1;
endgroup

cg3 inst3 = new();

endmodule

Merging Coverage Metrics

5-32
Note:
The lines of code that the stricken through indicate that these
lines are eliminated in the design source code after merging.

To enable the drop mode of flexible merging, use one of the following
commands:

% urg -dir latest.vdb -dir old.vdb -flex_merge drop

OR

% urg -dir latest.vdb -dir old.vdb -group flex_merge_drop

The shapes of covergroup instances are reported as follows:

top.inst2:
coverpoint cp1; (Scores of cp1 from both databases are merged)
coverpoint cp2; (Scores of cp2 from latest.vdb are retained)
coverpoint cp3; (Scores of cp3 from both databases are merged)
coverpoint cp4; (Scores of cp4 are skipped, no longer reported)

top.inst1:
coverpoint cp1; (Scores of cp1 from old database are retained)
coverpoint cp2; (Scores of cp2 from old database are retained)
coverpoint cp3; (Scores of cp3 from old database are retained)

top.b.inst:
coverpoint cp1; (Scores of cp1 from old database are retained)
coverpoint cp2; (Scores of cp2 from old database are retained)
coverpoint cp3; (Scores of cp3 from old database are retained)

top.b.inst3:
coverpoint cp1; (Scores of cp1 from latest database are retained)
coverpoint cp2; (Scores of cp2 from latest database are retained)
coverpoint cp3; (Scores of cp3 from latest database are retained)

Along with the report of the recent shape of top.inst2, the shapes
of the covergroup instances top.inst1 and top.b.inst that are
not present in the latest coverage model are also reported.

Merging Coverage Metrics

5-33
 To eliminate the reporting of redundant covergroups, use the
following command:

% urg -dir latest.vdb -dir old.vdb -flex_merge reference

The shape of top.inst2 only is reported and the remaining
instances are eliminated, as shown in the following report:

top.inst2:
coverpoint cp1; (Scores of cp1 from both databases are merged)
coverpoint cp2; (Scores of cp2 from both databases are merged)
coverpoint cp3; (Scores of cp3 from latest.vdb are retained)
coverpoint cp4; (Scores of cp4 are skipped and no longer reported)

top.inst1: //DELETED since they are not present in the latest coverage
model

top.b.inst: //DELETED since they are not present in the latest coverage
model

top.b.inst3:
coverpoint cp1; (Scores of cp1 from old database are retained)
coverpoint cp2; (Scores of cp2 from old database are retained)
coverpoint cp3; (Scores of cp3 from old database are retained)

If there are multiple tests present in the base database, URG selects
one of those tests as the base test and it would be considered as the
reference test. URG does not specify which test would be
considered as the base test. Therefore, it is always recommended to
pass a base database containing only the test that contains the
entire and the latest coverage model.

Consider that the latest coverage model has covergroups CG1, CG2,
CG3, but different seeds lead to instantiation of different covergroups
in each test, as follows:

latest.vdb/test1: CG1, CG2

latest.vdb/test2: CG2
latest.vdb/test3: CG1, CG3
latest.vdb/test4: CG1, CG2, CG3 // contains the whole
coverage model
old.vdb/test: CG1, CG3, CG4, CG5

Merging Coverage Metrics

5-34
In this case, urg -dir latest.vdb -dir old.vdb
-flex_merge reference selects one of the tests in latest.vdb
as the base test and the remaining tests are considered as old tests.
Depending on which test is selected as the base test, the results of
-flex_merge reference change as follows:

• If the base test is latest.vdb/test1, the result is:

CG1 // Cumulative of reset.vdb/test1,test3,test4, old.vdb/test
CG2 // Cumulative of reset.vdb/test1,test2,test4

• If the base test is latest.vdb/test2, the result is:

CG2 // Cumulative of reset.vdb/test2,test1,test4

• If the base test is latest.vdb/test3, the result is:

CG1 // Cumulative of reset.vdb/test3,test1,test4, old.vdb/test
CG3 // Cumulative of reset.vdb/test3,test4, old.vdb/test

• If the base test is latest.vdb/test4, the result is:

CG1 // Cumulative of reset.vdb/test4,test1,test3, old.vdb/test
CG2 // Cumulative of reset.vdb/test4,test1,test2
CG3 // Cumulative of reset.vdb/test3,test4, old.vdb/test

In these results, test4 yields the expected results with respect to

the latest coverage model. Therefore, it is recommended to pass a
database containing only test4 (a test that contains the entire
coverage model) as the base database to obtain correct results.

Merging Coverage Metrics

5-35
 Example - Assertion Metric
Consider the older and the latest version of the design source code
file, test.v.

Table 5-14 Design Source Code

test.v (older version) test.v (latest version)
module top; module top;
bot1 b1(); bot1 b1();
bot1 b2(); bot1 b2(); //DELETED
endmodule endmodule

module bot1; module bot1;

reg r=1; reg r=1;
reg x, y, clk; reg x, y, clk;

cp1: cover property (@(posedge clk) x cp1: cover property (@(posedge

##1 y); clk) x ##1 y); //DELETED
ap1: assert property (@(posedge clk) x ); ap1: assert property (@(posedge
clk) x );
initial begin
clk = 0; initial begin
forever #5 clk = ~clk; clk = 0;
end forever #5 clk = ~clk;
end
initial begin
A: assert(r==1); initial begin
C: cover(r); A: assert(r==1); //DELETED
x = 1; C: cover(r);
#5 y = 1; D: cover(r); //ADDED
#10 y = 0; x = 1;
#100 $finish; #5 y = 1;
end #10 y = 0;
endmodule #100 $finish;
end
endmodule

Consider that latest.vdb (latest database containing the latest

test) is generated from the latest test.v file, and old.vdb file
(older database containing old tests) is generated from the previous
version of test.v. When you merge old.vdb with latest.vdb,

Merging Coverage Metrics

5-36
 with latest.vdb as the reference database, without passing the
-flex_merge switch, all the assertions (including deleted
assertions) are retained in the merged report as shown Figure 5-4.

Command Line:

% urg -dir latest.vdb -dir old.vdb

Figure 5-4 Detailed Report for Assertions and Cover Properties

In this report, the deleted assertions are also retained.

With the -flex_merge reference option, assertions from the old

databases are eliminated as they are not present in the latest test of
the reference database. For the matched assertions, the counts are
accrued.

Merging Coverage Metrics

5-37
 Command Line:

% urg -dir latest.vdb -dir old.vdb -flex_merge reference

Figure 5-5 Detailed Report for Assertions and Cover Properties

Note:
If conflicting flex merge options are passed, for example,
-flex_merge reference+drop or -flex_merge
reference -group flex_merge_drop, then reference
takes priority over the drop merge and the reports are generated
accordingly.

Merging Coverage Metrics

5-38
Resetting the Scores of all Coverable Objects to Zero

You can reset the scores of all coverable objects to zero. The scores
of code, assert, and covergroup coverage can be reset to zero. As
the reset database contains the latest covergroup shape, it can be
used as a reference database to generate a report from a union-
merged database. For more information about reference database
and union merged databases, see Section “Reference Merging for
Covergroups and Assertions” and “Union Merging for Covergroups” .

Consider a scenario in which you are required to gather coverage

data for eight weeks and create merged VDBs for various time-
window options. Therefore, at any given time you can see the
accumulated coverage data of the past 2 days or 4 days or 1 week
or 4 weeks, and so on. If you want to see old coverage data (for
example, merged data of the last two weeks, excluding the latest)
through a newer coverage shape (the coverage shape derived from
the latest coverage data), and you need to merge the existing set of
databases against the new coverage shape. You can achieve this
using the reset database. In the reset database, the coverage data
is reset to zero and the latest coverage shape is retained.

To reset all the coverage metrics to zero, use the

-reset_coverage option along with -dbname reset.vdb on
the urg command line.

For example,

% urg -dir simv1.vdb -dir simv2.vdb …. -reset_coverage\

-dbname reset.vdb

This command enables you to dump the merged coverage database

reset.vdb which contains the scores of all coverable objects that
are reset to zero. So, when you generate the reports out of

Merging Coverage Metrics

5-39
 reset.vdb, the scores of each coverable object are reported as
zero. However, this command does not generate urgReports and
therefore, -report <path to urg reports> is ignored by URG.

Note:
It is mandatory to pass -dbname reset.vdb along with
-reset_coverage.

The -show tests option is not honored if passed along with

-reset_coverage. Therefore, the dumped database does not
contain any test correlation data (as no objects are covered in the
reset database, URG will not have any test to attach). However, URG
does not issue any warning for this scenario.

Toggle Coverage Reference Merging

In general, coverage data collected for a module in a simulation run

can only be merged with a compile-time VDB directory that was
compiled with the same version of the module that was used in the
simulation run. When merging, if the coverage data for a module or
instance produced by simulation does not match what is found in the
compiled VDB, the data from that simulation run is discarded.

This section describes a feature that allows coverage data for toggle
coverage to be merged on a signal-by-signal basis instead of
module-by-module (or instance-by-instance) basis under a switch.

This section consists of the following subsections:

• “Use Model”
• “Limitation”

Merging Coverage Metrics

5-40
Use Model

When toggle coverage reference merging is enabled, coverage data

for signals that exist in the input design but do not exist in the base
design, or which have different bounds or types in the base and input
design, are discarded and a mismatch report can be generated.

The base design is the first design and the input design is the other
design to be merged with the base design. If there are multiple input
designs, each design is merged one at a time with the base design.

To enable reference toggle coverage merging, use the

-flex_merge tgl switch with the urg command. Its syntax is as
follows:

% urg -dir <base.vdb> <input.vdb> -flex_merge tgl

where,
• <base.vdb> and <input.vdb> are the base database and input
database respectively. Note that both directories must be either
a compile-time VDB or a merged VDB produced with URG's
-dbname option. VDBs that are produced using the -cm_dir option
on the simv command line cannot be merged in this mode.
• -flex_merge tgl enables reference merging for toggle coverage
metric.
The rules for toggle reference merging are as follows:

1. Only signals that exist in the base design are retained. Signals
that exist only in the input design are discarded.
2. Coverage data of the signals that exist in both databases with
same bounds and size are merged from both designs.

Merging Coverage Metrics

5-41
 3. For a signal that exists in both databases but has different bounds,
only the data from the base design for that signal is retained.
4. For a signal that exists in both databases but has a different type,
only the data from the base design for that signal is retained.
For example, consider the following scenarios in which signals in a
module for base.vdb and input.vdb have changed:

Table 5-15 Example: Changes in base.vdb and input.vdb

Base Design, Input Design, Changes With
base.vdb input.vdb Respect to input.vdb
reg a, b; reg a; Signal b is deleted.

reg a, b; reg a, b, c; Signal c is added

reg a, b; reg b, a; Signal declaration order

changed

reg a, [3:0]v; reg a, [5:2]v; Bounds of signal v are

changed

reg a; wire a; Signal type of a is changed

reg a; //local input a; //port signal Signal type of a is changed

Only the data from the base design is shown in the Default Flow
columns of Table 5-16 to Table 5-23, as any design change causes
the data from the input design to be discarded for all signals in the
module.

Now, In the first row of the table above, signal b exists only in the
base design. In the default flow, coverage for a is taken only from
base.vdb because all of the input design data for this module is
discarded. In the reference merging flow, coverage data for a and b
is merged from both, that is, base.vdb and input.vdb (see
Table 5-16).

Merging Coverage Metrics

5-42
Table 5-16 Default and Reference Merging Flows for Signals a and b
Base Design, Input Design, Default Flow Reference
base.vdb input.vdb Merging Flow

1−>0 0−>1 1−>0 0−>1 1−>0 0−>1 1−>0 0−>1

a No Yes a Yes Yes a No Yes a Yes Yes

b No No b No No b No No

In Table 5-15, signal c exists only in the input design, therefore, it is

not merged in the base database as it does not exist in the base
design as shown in Table 5-17.

Table 5-17 Default and Reference Merging Flows for all Signals
Base Design, Input Design, Default Flow Reference
base.vdb input.vdb Merging Flow

1−>0 0−>1 1−>0 0−>1 1−>0 0−>1 1−>0 0−>1

a No Yes a Yes Yes a No Yes a Yes Yes

b No No b No Yes b No No b No Yes

c Yes No

Merging Coverage Metrics

5-43
 If the signals are identical but the order in which they are declared in
the source are different, it does not effect merging in the reference
merge flow.

Table 5-18 Identical Signal With Different Sequence of Declaration

Base Design, Input Design, Default Flow Reference
base.vdb input.vdb Merging Flow

1−>0 0−>1 1−>0 0−>1 1−>0 0−>1 1−>0 0−>1

a No Yes b No Yes a No Yes a Yes Yes

b No No a Yes No b No No b No Yes

If bounds change for the signal v from [3:0] to [5:2], the input data
for v is discarded and the data for a is merged from both designs
(see Table 5-19).

Table 5-19 Bounds Change for Signal v

Base Design, Input Design, Default Flow Reference
base.vdb input.vdb Merging Flow

1−>0 0−>1 1−>0 0−>1 1−>0 0−>1 1−>0 0−>1

a No Yes a Yes Yes a No Yes a Yes Yes

v[3] No Yes v[5] Yes Yes v[3] No Yes v[3] No Yes

v[2] Yes Yes v[4] Yes Yes v[2] Yes Yes v[2] Yes Yes

v[1] No No v[3] Yes Yes v[1] No No v[1] No No

v[0] Yes No v[2] Yes Yes v[0] Yes No v[0] Yes No

Merging Coverage Metrics

5-44
 If the kind of signal changes, that is from reg to wire, the toggle data
is not merged from the input design (see Table 5-20).

Table 5-20 Signal Changes From reg to wire

Base Design, Input Design, Default Flow Reference
base.vdb input.vdb Merging Flow

reg a; wire a; reg a; reg a;

1−>0 0−>1 1−>0 0−>1 1−>0 0−>1 1−>0 0−>1

a No Yes a Yes No a No Yes a No Yes

This section consists of the following subsections:

• “Region Changes”
• “VDB Directory Types”

Region Changes
As with the default flow, coverage for a module or an instance that
exists only in the input design is not retained when merging. For
example, consider Table 5-21 in which the module name, mymod, is
same in both base.vdb and input.vdb. However, their instances are
different, that is m1 in base.vdb and m2 in input.vdb. In this case,
only data for m1 is retained and data for m2 is discarded.

Table 5-21 Same Module Name With Different Instances Names

Base Design, Input Design, Reference Merging
base.vdb input.vdb Flow
module mymod; module mymod; Only data for m1 is
… … retained and data for m2
endmodule endmodule is discarded

module top; module top;

mymod m1; mymod m2;

Merging Coverage Metrics

5-45
 If the module name changes, no cross-design merging happens in
the reference merging flow. For example, see Table 5-22:

Table 5-22 No Cross-Design Merging

Base Design, Input Design, Reference Merging
base.vdb input.vdb Flow
module mymod1; module mymod2; Only data for m1 and
… … mymod1 of the base
endmodule endmodule design is retained and
data for m1 and mymod2
of the input design is
module top; module top;
mymod1 m1; mymod2 m1; discarded.

For the input design, toggle coverage merging happens only for
those iterations that exist in the generate statement of the base
design. For example, see Table 5-23:

Table 5-23 The generate Statement

Base Design, Input Design, Reference Merging
base.vdb input.vdb Flow
genvar j; genvar j; Only data for iterations 0
generate generate and 1 is retained in the
for(j=0;j<2; j=j+1) for(j=0;j<5; j=j+1) base design and it is
begin begin merged from both base
… … and input designs.
end end However, data from
iterations 2, 3, and 4 is
discarded as those
iterations do not exist in
the base design.

Merging Coverage Metrics

5-46
 VDB Directory Types
There are three types of VDB directories: Compile-time, simulation-
only, and merged. For details on these directories, see Table 5-24:

Table 5-24 VDB Directory Types

VDB Directory Description Example
Type
Compile-time VDB It is created by the vcs command % vcs -sverilog -cm tgl -cm_dir
and it contains shape and design comp.vdb dut.v …
information.
where,
-cm_dir is used to specify an
alternative name or a location for
saving the default simv.vdb directory.
comp.vdb is the compile time vdb.

Simulation-only VDB It is created by a simv executable % simv -cm tgl -cm_dir simv.vdb
that uses the -cm_dir flag to direct
runtime results to a new directory, where,
or to one that was previously -cm tgl adds runtime data to simv.vdb
created by another simv run.
Simulation-only vdbs contain only
runtime coverage data, and no
shape or design information.

Merged VDB A merged vdb is one created with % urg -dir comp.vdb simv1.vdb
the URG -dbname flag. When URG simv2.vdb … -dbname merged.vdb -
creates a merged vdb, it includes noreport
shape, design and runtime where,
coverage information in it. -dbname is used to create merged
coverage database.

To use reference merging with coverage data, VDBs should contain

design and shape information as well as runtime coverage data. This
information is required to match the signals in different versions of
each module by name, size, and to check size and bounds.
Therefore, toggle coverage merging is supported on compile-time
VDBs or merged VDBs.

Merging Coverage Metrics

5-47
 Limitation

Toggle coverage merging does not support simulation-only VDBs.

Mapping Coverage Metrics

Code coverage data is collected on a module and instance basis. If

the design hierarchy changes, the list of modules or instances
changes, and you can no longer directly merge code coverage data.

In such cases, you can merge coverage data from non-identical

designs using mapping. You can compile a design (or part of a
design) with different contexts and merge coverage data. However,
this can be done only for subtrees of the design that are identical
across all versions of the design that you are merging. Mapping is
useful when some coverage data is collected at the block-level and
other data for that block is collected in system-level simulation, or
when the verification process involves swapping out different top-
level test-benches that each instantiate the design.

You can instantiate a sub-hierarchy (a module instance in your

design and all the module instances hierarchically under this
instance) in two different designs and view the combined coverage
for the sub-hierarchy from the simulation of both designs.

Use the -map option to map sub-hierarchy coverage from one

design to another. Full hierarchy should be generated in the
hierachy.html file. This option is available in code coverage and
assertion coverage but not supported in group coverage.

The -map option syntax is as follows:

Merging Coverage Metrics

5-48
urg -dir <base_design>.vdb -dir <input_design>.vdb -map
<module name>
Where:

<base_design>
The first directory mentioned is the base design and will report
the design coverage directory after the merge.

<input_design>
The second directory provided to the URG command line is the
input design. The input design coverage is merged into the base
design.

The cumulative coverage will be available in the base design

coverage directory.

<module name>

Defines the top-level module name (identifier) of the sub-

hierarchy. Do not use the hierarchical name of the top-level
module instance in the sub-hierarchy.
Note:
When you map coverage from one design to another, the source
file names must be identical. For example, consider the following
figure:

Merging Coverage Metrics

5-49
Figure 5-6 Mapping Coverage
design 1

base design

sub1 sub2 sub3 sub4

design 2
mapped
coverage
mapped design

sub1 sub2 sub5

As shown in Figure 5-6, two designs instantiate a common sub-

hierarchy, labeled sub1. The code for the sub-hierarchy, in both
designs, is in the source file named sub1.v. The module name
(identifier) of the top-level module in the subhierarchy is sub1. This
illustration shows mapping coverage information for that
ksubhierarchy from the simulation of design 2 to the coverage
information for that subhierarchy from the simulation of design 1.
There can be multiple instances of the sub-hierarchy in the design
from which coverage information is mapped (mapped design).
However, there can only be one instance of the sub-hierarchy in the
design to which the coverage information is mapped (base design).

The following procedure explains how you can map coverage

information:

Merging Coverage Metrics

5-50
1. Compile the base design for coverage and then simulate that
design while monitoring for coverage. For example:
% cd /net/design1
% vcs -cm line sub1.v sub2.v sub3.v sub4.v main.v test.v
% simv -cm line

2. Compile the mapped design for coverage and then simulate that
design while monitoring for coverage. For example:
% cd /net/design2
% vcs -cm line sub1.v sub5.v main.v test.v
% simv -cm line

3. Run URG specifying the name of the top-level module in the sub-
hierarchy. Also, specify the coverage directory for the base
design, and then specify the mapped design. For example:
% urg -dir /net/design1/simv.vdb /net/design2/simv.vdb \
-map sub1

The files generated using this command, only contain sections for
the module instances in the sub-hierarchy. These module instances
are identified by their hierarchical names in the first (or base) design.
The coverage information in these sections is the coverage
information from both designs.

You can also include the -hier compile-time option to specify a

larger sub-hierarchy that includes the sub-hierarchy for which you
want mapped coverage. The resulting report files contain sections
for the module instances in this larger hierarchy, but the sections for
the instances in the smaller sub-hierarchy (sub-hierarchy with
mapped coverage) also contain coverage information from the other
design.

Merging Coverage Metrics

5-51
 Note:
You cannot use the -map and -grade URG options together as
it is not supported.

Mapping Assertion Coverage

You can use the -map option in the URG command line to map
assertion coverage from two designs. This section discussed
different scenarios that help you understand how assertions are
handled. The basic syntax of the -map option is as follows:
Syntax

% urg -dir <base_design>.vdb -dir <input_design>.vdb \

-map <module name>

Example
% urg -dir coverage_chip.vdb -dir coverage_block.vdb \
-map block

Scenario-1: Assertions Present in a Separate Bind Module

If assertions are present in a separate bind module for the input
design, then the -map use model is slightly different when compared
to the input design for which assertion is present within the module
itself. For example:

bind block block_sva bind_My_block1(....); (assertion

mentioned in block_sva module for the input design block,
bind_My_block1 is bind instance here).

Syntax

% urg -dir <base_design.vdb> -dir <input_design.vdb> \

-map <bind module name>

Merging Coverage Metrics

5-52
Examples

% urg -dir coverage_chip.vdb -dir coverage_block.vdb \

-map block_sva
urg -dir coverage_chip.vdb -dir coverage_block.vdb
-map block_sva -map block (This is required if you are
interested in mapping line, toggle, code coverage for same block).

Known Issue

URG generates the following warning during report generation for

this case; however, mapping is correctly done.

Warning[UCAPI-MAP-INSMISMATCH] Instance mismatch

in mapping

Mapping Sub-Hierarchy Coverage in VHDL

You can also map a VHDL sub-hierarchy’s coverage from one

design to the other using the -map URG command-line option.

The procedure is as follows:

1. Compile for coverage and simulate the base design while

monitoring for coverage.
2. Compile for coverage and simulate the mapped design while
monitoring for coverage.
3. Run URG specifying the sub-hierarchy with the -map option and
the coverage directory for both designs as arguments to the -dir
option.
4. Specify the name of the entity at the top of the sub-hierarchy that
is to be used in both designs. You can specify this in two ways:

Merging Coverage Metrics

5-53
 - Specify the entity name as follows:
-map entity_name

- Specify the library name and entity name as follows:

-map library_name.entity_name

An example command line for URG is as follows:

urg -dir /net/design2/simv.vdb -map sub1

By default, the report contains data only for sections for the entity
instances in the sub-hierarchy. These entity instances are identified
by their hierarchical names in the first or base design. The coverage
information in these sections is the coverage information from both
designs.

Mapping Coverage Information From Multiple Sources

You can map coverage from different databases or intermediate

coverage data files generated from different platforms using multiple
-map options in the URG command line. In other words, the
intermediate information in the coverage directories is platform-
independent. However, you specify multiple -map options, you must
ensure to specify the respective -dir options when using URG. For
example:

% urg -dir chip.vdb t1.vdb t2.vdb -map t1 -map t2

The first directory specified with -cm_dir must have both t1 and t2
instantiated.

Merging Coverage Metrics

5-54
 Understanding Instance-Based Mapping

Instance-based mapping allows you to specify an instance in your

base design for which you want to merge coverage data of two
different designs.

Assume that you have the same module instantiated in different

locations in two different designs. (For example, one of the designs
could be a system-level design, and the other, an RTL design.)

Consider the following figure:

A B

My_Ip B C
Common My_Ip1 My_Ip2

My_Ip1 My_Ip2
Base Input

Here, you are able to map instances B.My_Ip1 and B.My_Ip2 to

instance A.B.My_Ip1.

The mapping configuration file for this example will contain the
following information:

MODULE: My_Ip
INSTANCE:
SRC: B.My_Ip1, B.My_Ip2
DST: A.B.My_Ip1

The mapping configuration file contains the following elements:

Merging Coverage Metrics

5-55
 • MODULE: Specifies the name of the common module.
• INSTANCE: Provides source and destination information for
MODULE.
• SRC: Represents the list of one or more module instances in the
input design.
You can specify multiple instances in a comma-separated list after
the SRC keyword. If an instance does not appear in the specified
input design, VCS ignores that instance.

• DST: Represents a list of one or more module instances in the

base design to which the source module instances are to be
mapped.
Note:
Both SRC and DST can contain either a full hierarchical path or
the * wild-card.

You can use the -mapfile option for instance-based mapping in

URG; the syntax is as follows:

% urg -dir base.vdb -dir input.vdb -mapfile file_name

Where, file_name is the mapping configuration file.

The following guidelines apply to instance-based mapping:

• If the instance name from the input design matches the pattern
given in the -mapfile file_name file, but if it does not
correspond to the module for which the pattern is provided, it is
ignored.
• Rules applied for mapping are applied in all directories given by
the -dir option.

Merging Coverage Metrics

5-56
• You cannot use -mapfile and -map options together in URG.

Examples of Instance-Based Mapping

The following examples illustrate how you can use the mapping
configuration file to perform various instance-based mapping
operations.

Example 1

If you want to merge all instances of a specified module in the input

design, use the * wild-card following SRC:

MODULE: My_Ip
INSTANCE:
SRC: *
DST: A.B.My_Ip1

This syntax merges all the instances (B.My_Ip1, B.My_Ip2) of

the input design into A.B.My_Ip1.

Example 2

If you want to merge one instance of the input design into all the
instances of the base design, use the * wild-card after DST:

MODULE: My_Ip
INSTANCE:
SRC: B.My_Ip1
DST: *

This syntax merges the data from B.My_Ip1 into both A.B.My_Ip1
and A.C.My_Ip2.

Merging Coverage Metrics

5-57
 Mapping Assertion Coverage Using a Mapping
Configuration File

Similar to instance-based mapping, you can also map assertion

coverage using the mapping configuration file. After specifying the
required information in the mapping configuration file, you can pass
it as an argument with the -mapfile option. The basic syntax of the
-mapfile option is as follows:

Syntax

% urg -dir <base_design>.vdb -dir <input_design>.vdb \

-mapfile <file_name>

Where, file_name is the mapping configuration file.

Example

% urg -dir coverage_chip.vdb -dir coverage_block.vdb \

-mapfile block

Scenario-1: Assertions Present in a Separate Bind Module

If assertions are present in a separate bind module for the input
design, then the -mapfile use model is different when compared
to the input design for which assertion is present within the module
itself. For example:

bind block block_sva bind_My_block1(....);

(Assertion mentioned in block_sva module for the input design
block, bind_My_block1 is bind instance here).

Syntax

% urg -dir <base_design.vdb> -dir <input_design.vdb> \

Merging Coverage Metrics

5-58
-mapfile <block>

Example using the -mapfile option:

MODULE: block
INSTANCE:
SRC: B.My_block1.bind_My_block_1,
B.My_block2.bind_My_block2
DST: A.B.My_block.bind_My_block_base
MODULE: block (This is required if you are interested in mapping
line, toggle, code coverage for same block).

INSTANCE:
SRC: B.My_block1, B.My_block2
DST: A.B.My_block
Note:
URG issues the following warning during report generation for
this case; however, mapping is correctly done.

Warning[UCAPI-MAP-INSMISMATCH] Instance mismatch in mapping

Scenario-2: Swapping the Module Name with Bind Module

Name
URG will not issue any warning or error messages if you swap the
module name with the bind module name using the -mapfile
option. In both cases, you will be able to see correct mapping.

Example using the -mapfile option:

MODULE: block_sva
INSTANCE:
SRC: B.My_block1.bind_My_block_1,
B.My_block2.bind_My_block2
DST: A.B.My_block.bind_My_block_base

Merging Coverage Metrics

5-59
 Map-Merging Assertion Coverage

Map-merging is a technique that accumulates the assertions of the

module/instance being mapped from both the input and base VDBs.
Map-merging accumulates even those assertions that are present in
the input VDBs but are not present in the base VDB.

You can specify the -map_merge_union option in conjunction with

-mapfile or -map option to map-merge assertion coverage. The
merging semantics using the -map_merge_union option is the
same as the default merge, that is, it accumulates all the assertions
of the module/instance being mapped from all the VDBs. Without this
option, the assertions that are present in the input VDBs, but
assertions not present in the base VDB, are ignored. Suppose a
module has N assertions in VDB1 and some new assertions N+M in
VDB2. If you merge these VDBs normally, no warning messages are
issued and all the assertions (N+M) are displayed in the report.

If you use the -map option and merge the VDBs keeping VDB1 as
the base, a warning message is issued stating that the secondary
VDB(VDB2) has assertions that are not present in the base VDB and
those assertions will be discarded. If you want to keep such
assertions in the merged VDB, then use the -map_merge_union
option in conjunction with -map or -mapfile option. The report
generated using the -map_merge_union option is independent of
the order of VDBs specified on the command line.

The following example discusses a scenario where the

-map_merge_union option is used with either the -mapfile or
-map option for merging assertion coverage:

Consider the following assertions in the design source code files,

test1 and test2:

Merging Coverage Metrics

5-60
Syntax of test1.v

always @(posedge clock) begin

if( !reset )
Q <= 1'b0;
else
Q <= (J & ~Q) | (~K & Q);
IA1: assert ( (J == Q) && (J == ~K) );
IA2: assert #0 ( (J == Q) && (J == ~K) );
CA1: assert property (p1);
CA2: assert property (p2);
end
....
Syntax of test2.v

always @(posedge clock) begin

if( !reset )
Q <= 1'b0;
else
Q <= (J & ~Q) | (~K & Q);

IA1: assert ( (J == Q) && (J == ~K) );

IA2: assert #0 ( (J == Q) && (J == ~K) );
IA3: assert final ( (J == Q) );
CA1: assert property (p1);
CA2: assert property (p2);
end
...

simv1.vdb is generated from test1.v and simv2.vdb from test2.v.

When you map the two databases using only the -mapfile option,
the following warning is issued.

% vcs -cm asset test1.v -cm_dir simv1.vdb -R

% vcs -cm asset test2.v -cm_dir simv2.vdb -R

% urg -dir simv1.vdb simv2.vdb -format both -mapfile map.file

Merging Coverage Metrics

5-61
 In this case, simv1 is the base VDB and therefore, assertion IA3 is
discarded from the assertions report.

Similarly, when simv2.vdb is the base VDB, as shown in the

following command, IA3 is not discarded as IA3 is present in the
base VDB:

% urg -dir simv2.vdb simv1.vdb -format both -mapfile

map.file

When you use the -mapfile or -map option along with the
-map_merge_union option, no warning is issued, as shown in the
following command:

% urg -dir simv1.vdb simv2.vdb -format both -mapfile map.file

-map_merge_union

As the results of the -map_merge_union option is independent of

order of the VDBs specified in the command line, the report shows
IA3 along with all other assertions present.

Mapping Relocated Source File

URG determines the location of a source directory or source file

using the information built into the coverage database.

However, if you change the location of a source file, you can map the
path to the relocated file using the -pathmap option.

By default, the source directory, which is provided at compile time, is

assumed to be constant. Using this feature, you can change the
location of the source file after compile time.

Merging Coverage Metrics

5-62
Syntax for relocating the source file
urg -pathmap <file>
where,

<file> — contains one or more mapping rules in the format of

<from> : <to>.

<from> — is an exact match of the path prefix of the original

source directory.

<to> — refers to the path of the relocated directory.

For example:

% urg -dir simv.vdb -pathmap pmap

The file pmap contains the following rule:

/home/work/src : local/files/source

Thus, for the source file /home/work/src/test1.v, URG will try

local/files/source/test1.v first and then /home/work/
src/test1.v.

Limitation

Mapping a coverage database generated from partition compilation/

precompiled IP flow with a coverage database generated from non-
partition compile/non-PIP flow is not supported.

Merging Coverage Metrics

5-63
Merging Coverage Metrics
5-64
6
Grading Tests for Coverage 1
VCS supports various tests grading techniques that enable you to
eliminate redundant tests from a test suite. These techniques are
discussed in detail in the following sections:

• “Test Grading”
• “Cost-Based Test Grading”
• “Parallel Test Grading”
• “Using Grading in a High-Coverage Environment”
• “Generating Graded Test List Files”
• “Modifying Overall Grading Scores”

Grading Tests for Coverage

6-1
Test Grading

Most test suites contain a large number of tests, and this number
keeps increasing with the evolution of the DUT. As the test suite is
developed, it often results in the creation of redundant tests that
check overlapping functionality.

VCS Coverage provides test grading as a post-processing technique

that enables you to compare the effectiveness of a set of tests
against each other.

You can use the -grade option to URG to specify and run test
grading on a test suite and generate test grading reports.

Your test suite achieves a certain level of coverage when all tests are
run. Grading results in an ordered list of tests in "best first" order that
achieves the same coverage as the full suite of tests, such that only
the required tests are selected, and tests that are not required for
coverage are excluded.

To grade a set of tests, invoke URG with the -grade option. There
are many options to control how grading is executed and reported,
but the basic decisions you have to make are as follows:

• What criteria should be used to order the tests?

• What scores do you want to be reported?
By default, URG grades all coverage data present in the VDB
directories passed to it, and it tries to minimize the total number of
tests selected. You can grade via only some metrics and use other
selection criteria, as explained in Chapter, "URG Options" in the
Coverage Technology Reference Manual.

Grading Tests for Coverage

6-2
 Usage

By default, test grading generates a full-grading report that includes

the cumulative (TOTAL), stand-alone (TEST), and incremental
(INCR) scores of each metric of each test. Use the -grade option
to generate the grading report (see Figure 6-1). The TOTAL column
lists the cumulative coverage score after each test is merged with all
previous tests in the graded list. TEST is the individual coverage
score of each test. INCR is the improvement of coverage score for
each test contributing to the cumulative value.

If the original test VDBs are available when grading is done, and test
standalone scores ("TEST" in the reports) are being reported, URG
loads those individual tests' data to compute those scores. This is
enabled by default and can be interesting as a reference, but can
add a significant amount of time to the grading process. To omit
reporting the test standalone scores, add scores total+incr as
an argument to the -grade option.

Figure 6-1 Example of a Full-Grading Report

To specify the total number of tests for grading, use the following
command:

Grading Tests for Coverage

6-3
 % urg –grade index indexlimit N
where,

N can be any positive integer. Its default value for N is 20. In theory,
you can use N equal to the total number of tests you are grading for
the highest quality report, but in designs with millions of objects this
is generally not practical.

You can also merge the tests yourself and then grade from the
merged VDB, as long as you create the merged VDB with the -show
tests option passed to URG. Similar to the indexlimit option
discussed above, a merged VDB does not record every test that
covers every object by default. You can control the maximum
number of tests tracked per object with the -db_max_tests option
when merging.

If you use a -db_max_tests value of N, then indexlimit values

higher than N do not have any additional improvement on the
grading results from the resulting merged VDB, as the covering-test
information is not recorded in the merged VDB.

Grading Tests for Coverage

6-4
Cost-Based Test Grading

Test grading in URG is effective at finding the smallest number of

tests to reach the coverage goal. The test grading algorithm is
enhanced to automatically report different costs of each test and to
allow test grading to consider specific cost metrics when putting tests
in best-first order. The types of costs that may be used for grading
are simulation cycles, clock time, or CPU time.

Grading is an iterative process, where one test is selected in each

iteration. For each iteration, URG computes the incremental benefit
of each test that has not yet been chosen. It then picks the test with
the highest incremental benefit.

For regular grading, the benefit is merely how much the test will
improve the overall coverage score when merged with the already-
chosen tests. This results in a list of tests in best-first order that uses
the fewest number of tests to reach the coverage goal.

In cost-based grading, the benefit is computed by dividing the test's

incremental score improvement by the test's cost. This means that in
cost-based grading, a test with a lower incremental score
improvement may be chosen before a test with a higher incremental
score improvement.

Consider the cost-based grading report as shown in Figure 6-2. In

regular grading, TST4 would have been chosen first, as it has the
highest standalone score (incremental improvement over 0%).
However, as its simulation time is high (its cost), it is instead selected
last.

Grading Tests for Coverage

6-5
Figure 6-2 Cost-Based Test Grading Report
SCORE LINE
TOTAL TEST INCR TOTAL TEST INCR Sim Time Total Time NAME
45.83 45.83 45.83 45.83 45.83 45.83 310 310 TST3/TST3
61.46 31.25 15.62 61.46 31.25 15.62 240 550 TST2/TST2
69.79 20.83 8.33 69.79 20.83 8.33 210 760 TST1/TST1
100.00 51.04 30.21 100.00 51.04 30.21 980 1740 TST4/TST4

This happens because when choosing the first test, these benefits
are computed for each test:

TST3/TST3 45.83 / 310 = 0.1478

TST2/TST2 31.25 / 240 = 0.1302
TST1/TST1 20.83 / 210 = 0.0992
TST4/TST4 51.04 / 980 = 0.0521

As TST3 has the highest benefit, it is chosen as the first test in the
list.

The new cost suboption to -grade is used to specify which

measurement to use for cost-based grading. The syntax is:

% urg -dir -simv.vdb -grade cost \

[simtime|cputime|clocktime]…

When cost is used, the chosen cost type is displayed by default

along with the cumulative cost of the test. For example, the sample
output of the following command is displayed as shown in
Figure 6-3.

% urg -dir simv.vdb -grade cost cputime

Grading Tests for Coverage

6-6
Figure 6-3 Cost-Based Grading Based on CPU Time

If one or more tests in the provided database directories do not have

any costs stored (for example, if the URG report was generated by
an earlier version of VCS), such tests are assigned a default cost of
the average cost of the tests that do have cost information. A warning
message is displayed in this scenario. Tests that do not have costs
are displayed with their “computed cost” in the report. These tests'
costs are highlighted to indicate that they are assigned and not
measured.

For example, if test2 has no measured SimTime or CPU time, its

average costs would be displayed in the report as shown in
Figure 6-4.

Grading Tests for Coverage

6-7
Figure 6-4 Cost-based Grading With Assumed Cost

When you are not performing cost-based grading and you view the
test metrics, any missing metrics are shown as “--”.

For example, a quick grading report might show test2 or test5 as

shown in Figure 6-5, if it were missing SimTime and CPU time.

Figure 6-5 URG Report With Missing Metrics

If no test in the database directories has a cost, an error message is

displayed and cost-based grading is not done.

Grading Tests for Coverage

6-8
 You can generate a grading report with different columns using the
columns argument to the -grade option. For example, the sample
output of the following command is displayed as shown in
Figure 6-6.

% urg -dir simv.vdb -grade cost cputime \

columns simtime+cputime

Figure 6-6 Cost-Based Grading With Measurement Columns

Note:
When you specify columns along with -grade cost, URG will
not automatically include the specified cost metric. For example,%
urg -grade cost cputime columns seed shows only the
seed value and not the cputime in the report.

If no columns are specified, only the default cost-based grading

columns are displayed. For example, with CPU time cost-based
grading, only CPU and total CPU time are shown as in Figure 6-7.

Grading Tests for Coverage

6-9
Figure 6-7 Cost-Based Grading Report When no Columns are Specified

Note:
For index grading (not cost-based) with assertion or covergroup
coverage, SimTime, Seed and 48Seed are automatically
displayed in the URG report.This behavior is retained for
backward compatibility as shown in Figure 6-8.

Figure 6-8 Index-Based Grading Report With Seed and 48Seed

Grading Tests for Coverage

6-10
 Limitations

The following are the limitations with this feature:

• The precision sub-option to the -grade option is not

supported for cost items.
• Random seed information is only available when there is
covergroup data for a test. The random seed value is saved in the
testbench/covergroup coverage data files and it is currently not
available in the test records.

Parallel Test Grading

VCS Coverage enables you to perform test grading in parallel on

your compute farm/grid by passing the –parallel option along with
certain –grade options, on the URG command line.

For example:

urg –dir simv.vdb –parallel –grade index

urg –dir my*.vdb –parallel –grade cost cputime

Note:
You can perform either default (best-first) or cost-based grading
using this option.

When these options are given, merging is done in parallel and the
grading step is done in one serial step at the end.

Grading Tests for Coverage

6-11
Using Grading in a High-Coverage Environment

As discussed above, test grading enables you to limit the number of

tests that should be tracked for each coverable object. When an
object is covered by many tests, grading ignores the tests beyond a
certain number. If a high-coverage test appears late in the list of tests
to be graded, its contribution would not be counted for the objects
that already have the maximum number of tests associated with
them. Therefore, it is recommended to ensure that any known high-
coverage tests are presented first in the lists of tests to be graded.

This section consists of the following subsections:

• “Use Model”
• “Recommendation”

Use Model

Consider a scenario in which URG picks 10 tests for grading with

indexlimit as 10, and a high-coverage test,
simv/mergefinal/test is the last one examined. Even though
the high-coverage test appears last, there are only 10 tests, so the
high-coverage test gets credit for all its covered objects, and
correctly reports 82.5% as coverage contribution:

Grading Tests for Coverage

6-12
Consider the case where URG picks 100 tests for grading with
indexlimit of 10 and the high-coverage test is the last one
examined. Now, the high-coverage test gets credit for only 63.32%
of objects in the design; the other objects, which are covered, have
their tests list filled up by other tests during the grading process:

However, if URG picks 100 tests for grading with indexlimit of 10

and the high-coverage test appears first in the index construction, its
coverage score would be 82.5%, as it was placed on the list of each
object that it covers:

Recommendation

Following is the recommendation for using grading in a high-

coverage environment:

• If there are known high-coverage tests that require grading,

ensure that they are considered first for grading using the -grade
reqtests option.

Grading Tests for Coverage

6-13
Generating Graded Test List Files

To generate graded test files, use the testfile argument with the
-grade option in URG.This command generates the
gradedtests.txt text file, which contains a simple list of graded
tests and is easy to parse. These tests are different from the score
values generated in the URG tests.html or tests.txt report

To generate the gradedtests.txt test file, specify the testfile

argument with the –grade option, as follows:

% urg –grade testfile…

When you use quick, greedy, or index grading, URG generates the
urgReport/gradedtests.txt file.The gradedtests.txt file
begins with the following comment, followed by the list of test names:

# Tests that contribute to coverage in graded order

simv/test1
simv/test2
You can also perform index grading, which generates the
urgReport/uniquetests.txt file. The uniquetests.txt file
lists the tests that cover at least one object which is not covered by
any other test:

# Tests that cover objects not covered by any other test,

in graded order.
simv/test2

Grading Tests for Coverage

6-14
Modifying Overall Grading Scores

Graded scores are calculated based on the weights of coverage

metrics. By default, each metric is weighted the same which results
in a certain graded score.

You can modify the overall graded score by modifying the weights of
each metric using the -scorefile option. The -scorefile option
enables you to specify a separate score file that allows you to assign
a different weight to each metric.

To instruct URG to use the score file, use the following syntax:

% urg -grade [grading options] -scorefile file_name

Note:
You can use either the -scorefile or -metric option, but not
both.

You can define a score file in the following format:

metric1 weight1
metric2 weight2
…
metricN weightN

In this file, each metric can only be specified once. The metric names
are the same as those used for the -metric option on the command
line (for example, line, cond, assert). Each weight must be a
non-negative integer.

Grading Tests for Coverage

6-15
 When the -scorefile option is given along with the -grade
option, grading is performedonly for the metrics specified in the
-scorefile file. You cannot specifythe-metric option with
the-scorefile option, since the score file spells out which metrics
are tobeused.

The following is a sample score file. It indicates that line coverage is

weighted normally, but that each group coverable object should be
weighted twice:

line 1
group 2

In this case, the overall score and the score for each test will be
computed as follows:

score = (linescore + (groupscore * 2)) / 3

The score file weights only affect the computation of the overall score
and the overall score for each test; it does not affect the score
reported for any individual metric. For example, the group score will
be reported the same regardless of the weight specified in the score
file.

Grading Tests for Coverage

6-16
7
Other Coverage Post-Processing
Techniques 1
This chapter discusses other coverage post-processing techniques,
in the following sections:

• “Managing the Covergroup Coverage Database”

• “Resetting and Deleting Assertion Coverage”

Managing the Covergroup Coverage Database

As the functional coverage model evolves, and changes, you may

want to make changes to your existing VDB coverage directory. In
normal scenarios, you might probably not need these tools.
However, there are some cases where you may want to reset the
coverage counts of a set of covergroups or even remove a

Other Coverage Post-Processing Techniques

7-1
 covergroup entirely from a VDB directory. VCS coverage has some
tools that allow you to modify the data in a coverage VDB directory
manually. The following sections describe how these tools work:

• “Editing the Covergroup Coverage Database”

• “Resetting and Deleting a Covergroup in Coverage Database”
• “Resetting Hit Counts of Bins”
• “Deleting a Covergroup from Coverage Database”

Editing the Covergroup Coverage Database

You can open the covergroup coverage database for editing using
the URG -group db_edit_file command option. An example of
the URG command with the -group db_edit_file option is as
follows:

% urg -dir first.vdb -format text -report hier_rep \

-group db_edit_file <filename> -dbname save/edited

where, filename is a user-written file that contains funccov and

assert statements in the following format:

begin funccov (reset|delete) (module|tree)

(module-name|instance-name)
covergroup-name [optional coverpoints or crosses]
end

The module parameter can be a module, interface, or program.

The tree parameter can be a module instance, interface instance,

or program instance. Pathnames in trees must use periods (“.”) as
instance delimiters.

Other Coverage Post-Processing Techniques

7-2
A funccov statement is used to reset or delete covergroup
coverage data. An assert statement is used to reset or delete
assertion coverage data.

Note:
VCS does not support editing the code coverage data.

Resetting and Deleting a Covergroup in Coverage

Database

The coverage model from the covergroup coverage databases can

be deleted or reset (their coverage set to zero) in accordance with
the changing functional coverage model. To delete or reset the
covergroup in the database, execute the following steps:

1. Create a file that contains a list of commands.

2. Pass the name of your command file as an argument to the
-group db_edit_file flag.
The syntax for covergroup reset and delete commands is as
follows:

% urg -dir first.vdb -format text -report hier_rep

-group db_edit_file -dbname save/edited

begin (funccov|assert) (reset|delete) (module|tree)

(module_name|instance_name) covergroup_name|assert_name
{optional coverpoint crosspoints} end

Where,

funccov|assert:
Identifies the metric type. Use the keyword funccov to edit a
covergroup and assert to edit an assertion.

Other Coverage Post-Processing Techniques

7-3
 reset|delete:
Identifies the operation that you want to perform.Use reset to
reset the hit counts to zero and delete to delete the specified
covergroup or assertion.

module|tree:
Identifies the scope of the operation. Use module if the operation
applies on all instances of the module and tree if the operation
applies only on a specific instance.

covergroup_name:
Identifies the name of the covergroup that is the target of the
operation.

optional coverpoint crosspoints:

Specifies a list of coverpoint/crosspoints whose hit counts should
be reset to zero using the reset operation for funccov.

Resetting Hit Counts of Bins

The reset command enables you to reset the hit counts of all bins
in a covergroup to zero.The following examples illustrate the usage
of the reset command:

• To reset the covergroup gc under the module instance top.i1,

use the following command:
begin funccov reset tree top.i1 gc end

• To reset the covergroup gc under all instances of the module

definition my_mod, use the following command:
begin funccov reset module my_mod gc end

Other Coverage Post-Processing Techniques

7-4
• To reset the coverpoint/crosspoint ra under the covergroup gc
with all instances of module definition my_mod, use the following
command:
begin funccov reset module my_mod gc ra end

• To reset the coverpoint/crosspoint ra under the covergroup gc

with all instances of top.i1, use the following command:
begin funccov reset tree top.i1 gc ra end

Deleting a Covergroup from Coverage Database

To delete a covergroup from the coverage database, use the

delete command, as illustrated in the following examples:

• To delete the covergroup gc under all instances of the module

definition my_mod, use the following command:
begin funccov delete module my_mod gc end
• To delete the covergroup gc under all instances of top.i1, use
the following command.
begin funccov delete tree top.i1 gc end

Other Coverage Post-Processing Techniques

7-5
Resetting and Deleting Assertion Coverage

As the design changes, assertions evolve and change. In the older

coverage databases, you are required to reset their hit counts to 0 or
they should be deleted.

The syntax for resetting and deleting assertion coverage is as

follows:

begin assert (reset|delete) (module|tree)

(module_name|instance_name) {optional assertions} end

This section consists of the following subsections:

• “Resetting Assertion Coverage”

• “Deleting Assertions”
• “Resetting the Scores of all Coverable Objects”

Resetting Assertion Coverage

To reset assertion coverage, use the assert reset command as

illustrated in the following examples:

• To reset the hit count of the assertion mid_first from the

instance top.i1, use the following command:
begin assert reset tree top.i1 mid_first end

• To reset the hit counts of all assertions under the instance top.i1,
use the following command.
begin assert reset tree top.i1 end

Other Coverage Post-Processing Techniques

7-6
Deleting Assertions

To delete assertion coverage form the coverage database, use the

assert delete command, as illustrated in the following examples:

• To delete the assertion mid_first from the instance top.i1,

use the following command:
begin assert delete tree top.i1 mid_first end

• To delete all assertions under the instance top.i1, use the

following command:
begin assert delete tree top.i1 end

• To delete the assertion mid_first from all instances of the

module mid, use the following command:
begin assert delete module mid mid_first end

• To delete all assertions from all instances of the module mid, use
the following command:
begin assert delete module mid end

Other Coverage Post-Processing Techniques

7-7
 Resetting the Scores of all Coverable Objects

You can reset the scores of all coverable objects such that all hit
counts are zero and every object is marked uncovered. Such a reset
database retains the shape information for the design, and can be
used as a base design for merging, but with all coverage information
removed. For more information on reference database and union-
merged databases, see Section “Reference Merging for
Covergroups and Assertions” and “Union Merging for Covergroups” .

Consider a scenario in which you are required to gather coverage

data for eight weeks and create merged VDBs for various time-
window options. Therefore, at any given time you can see the
accumulated coverage data of the past two days or four days or one
week or four weeks, and so on. Using the reset database, you can
see old coverage data (for example, merged data of the last two
weeks, excluding the latest) through a newer coverage shape (the
coverage shape derived from the latest coverage data), and merge
the existing set of databases against the new coverage shape. In the
reset database, the coverage data is reset to zero and the latest
coverage shape is retained.

To reset all the coverage metrics to zero, use the

-reset_coverage option along with -dbname reset.vdb on
the urg command line.

For example,

% urg -dir simv1.vdb -dir simv2.vdb …. -reset_coverage\

-dbname reset.vdb

This command enables you to dump the merged coverage database

reset.vdb, which contains the scores of all coverable objects that
are reset to zero. So, when you generate the reports out of

Other Coverage Post-Processing Techniques

7-8
reset.vdb, the scores of each coverable object are reported as
zero. However, this command does not generate urgReports and
therefore, -report <path to urg reports> is ignored by URG.

Note:
It is mandatory to pass -dbname <reset.vdb> along with
-reset_coverage.

The -show tests option is not honored if passed along with

-reset_coverage. Therefore, the dumped database does not
contain any test correlation data (as no objects are covered in the
reset database, URG will not have any test to attach). However, URG
does not issue any warning for this scenario.

Other Coverage Post-Processing Techniques

7-9
Other Coverage Post-Processing Techniques
7-10
 Analyzing Coverage
Verification1
This segment discusses how coverage reports are analyzed in
various applications, in the following chapters:

• “Viewing and Analyzing Coverage Reports in Verification Planner”

• “Viewing and Analyzing Coverage Reports Using DVE”
• “Viewing and Analyzing Coverage Reports Using Unified Report
Generator”
• “Analyzing Coverage Trend Charts”
8
Viewing and Analyzing Coverage Reports in
Verification Planner 1
This chapter describes how you can view coverage reports using
Verification Planner (Spreadsheet Annotator).

For information on creating and back-annotating verification plan,

see chapter “Viewing and Analyzing Coverage Reports in
Verification Planner” .

You can view the back-annotated coverage reports in the Verification

Planner Spreadsheet Annotator. The annotated spreadsheets are
similar to the original plans except for the cells that are annotated
with metrics and color-coded according to goal values.

After annotation, an annotated cell is highlighted in green if the

corresponding goal value of the cell is met, otherwise the cell is
highlighted in red. If no goal is specified, coverage and test scores
are annotated with color-coding, as shown in Figure 8-2.

Viewing and Analyzing Coverage Reports in Verification Planner

8-1
 Figure 8-1 shows an example of an original spreadsheet versus an
annotated spreadsheet.

Figure 8-1 Original Spreadsheet vs. Annotated Spreadsheet

Original
Spreadsheet

Annotated
Spreadsheet

After you apply the hvp annotate command, the corresponding

annotated cells are highlighted in green when goals are met, and in
red otherwise, provided that the goals of metrics are specified. If you
do not specify goals, the annotated cells will not be highlighted.

However, for a ratio or percent type metric or test metric, even if no

goal is given, the cell is highlighted in one of six colors from red (low)
to green (high) depending on the metric’s percentage value, as
shown in Figure 8-2.

Figure 8-2 Color Legend for Coverage Metrics

Note:
For the test metric, the cell color is based on the (pass count)/
(total test count) percentage.

Viewing and Analyzing Coverage Reports in Verification Planner

8-2
 In an annotated spreadsheet, a cell for a measure source or feature
might have a pop-up window that show details of its scores and
matched region. The information in the pop-up window is useful in
determining the exact matching region strings and scores, if the
source string contains wild-cards or if there are multiple sources in
the cell.

For example, Figure 8-3 shows the pop-up window for the source
string /cfg1/CPU1/L1CACHE/* and seven matched testcases,
with an annotated score of total=7 pass=6 fail=1. The pop-up
window illustrates details about how this score was aggregated.

Figure 8-3 Pop-up Window for a Source String and With Matches

If the number of matched regions is too high, you can set a filter, for
example, to see only the testcases with pass or warn. In this case,
you can use -ss_show_sources test pass+warn at the
command line. For more information about using the
-ss_show_sources switch, see section, Using the Spreadsheet
Annotator Commands in the Verification Planner User Guide.

If you use the –report urg-report-path switch, you will see

hyperlinks at source and feature cells. Clicking one of those
hyperlinks opens the URG report in your web browser and you can

Viewing and Analyzing Coverage Reports in Verification Planner

8-3
 see details in the URG/HVP report. For more information on URG,
see chapter “Viewing and Analyzing Coverage Reports Using
Unified Report Generator” .

For more information about Spreadsheet Annotator, see chapter

Verification Planner Spreadsheet Annotator in the Verification
Planner User Guide.

Viewing and Analyzing Coverage Reports in Verification Planner

8-4
9
Viewing and Analyzing Coverage Reports
Using DVE 1
This chapter describes how you can generate and view coverage
reports using DVE, in the following sections:

• “Opening a Database”
• “Loading Multiple Coverage Tests Incrementally”
• “Loading and Saving Sessions”
• “DVE Coverage Source/Database File Relocation”
• “The Navigation Pane”
• “The Coverage Summary Map Window”
• “Review Flow for Unmappable Exclusion”
• “The Coverage Detail Window”

Viewing and Analyzing Coverage Reports Using DVE

9-1
 • “Navigating in the Source Pane”
• “Display Single Cover Group in Detail Pane”
• “Viewing Line Coverage”
• “Viewing Toggle Coverage”
• “Displaying Condition Coverage”
• “Displaying Finite State Machine (FSM) Coverage”
• “Displaying Branch Coverage”
• “SVA Naming Convention”
• “OVA Naming Convention”
• “The Covers Tab”
• “Compute Coverage Score by Ratio”
• “Running Scripts”
• “Filtering the Hierarchy Display”

Viewing and Analyzing Coverage Reports Using DVE

9-2
Starting DVE in Coverage Mode

To start DVE in the coverage mode, enter the dve command with the
coverage command-line options as follows:

-cov
Opens the DVE Coverage GUI.

-dir <dir>
Opens the coverage database in the given directory.

Other Options
You can also append the following options as required: -f <file>
Opens the coverage directories listed in the given file.

-tests <file>
Opens coverage tests listed in the given file.

-show availabletests
Lists the available tests for the given design.

-assert minimal
Reports only modules and instances which have assertion in
assertion coverage. Code coverage database can not be loaded
with this option.

Viewing and Analyzing Coverage Reports Using DVE

9-3
 Opening a Database

In DVE, you can open a VDB directory produced by VCS. VDB

directories may contain any combination of code coverage,
assertions/cover property coverage data, and covergroup
coverage data.

To open a coverage database, execute the following steps:

1. Click File > Open/Add Database.

The Open/Add Coverage Database dialog box appears.

Viewing and Analyzing Coverage Reports Using DVE

9-4
Figure 9-1 Open/Add Coverage Database Dialog

2. Click the Browse button below the Design hierarchy/testbench

location field to locate and specify the design hierarchy/testbench
location.
3. Click the Metrics drop-down list to select the metrics you want to
include.

Viewing and Analyzing Coverage Reports Using DVE

9-5
 4. Click the More Options tab and select the desired coverage
reporting options.

You can click the Tips>> button to read the description of each of
these options.
5. (Optional) Click any of the following buttons above the test
directories list box to add and remove the directory:

- Adds a test directory.

- Adds the test files.

Viewing and Analyzing Coverage Reports Using DVE

9-6
 - Deletes a selected item from the list.
6. Select tests to manage one or more test files from the Available
tests list box.

- Displays a dialog box for selecting a filter file.

- Toggles enabling and disabling of a filter file.

- Selects all tests in the list. If you select more than one test
file, the results of the tests are merged.

- Clears all files in the list.

If you select more than one test file, the results of the tests are
merged. Note that you can also check and clear tests in the list.

7. Accept the default name or enter a new name for the test results.
8. Click OK.
The DVE Coverage window is populated with coverage
information, as shown in Figure 9-2.

Viewing and Analyzing Coverage Reports Using DVE

9-7
Figure 9-2 DVE Coverage Window

Main Coverage Table Window

Navigation pane
Console Window

Viewing and Analyzing Coverage Reports Using DVE

9-8
Loading Multiple Coverage Tests Incrementally

You can interactively load many coverage tests and merge them
interactively in the DVE Coverage GUI. With the incremental loading
feature, you can re-open the Open/Add Coverage Database dialog
box and select the third test, load it, and merge it together with the
previously merged tests. Thus, you can save time needed to close,
re-open, and merge the database.

To load multiple tests. execute the following steps:

1. Select File > Open/Add database.

The Open/Add Coverage Database dialog box appears.

Viewing and Analyzing Coverage Reports Using DVE

9-9
Figure 9-3 Open/Add Coverage Database Dialog

1 2

2. Click the left icon from the Test directories field (indicated as 1
in the figure) to add a test path.
3. Repeat Step 2 to add multiple test, if required.
4. Click the icon indicated as 2 in Figure 9-3, if you have a file with
test paths.
You can either perform step 2 or 3, or both to add the test
directories.
5. Specify the test path in the Tests to Open field.

Viewing and Analyzing Coverage Reports Using DVE

9-10
 The tests are listed under the Test Name area.
6. Select or clear the check boxes against the test you want to open
for the given design.
7. (Optional) Type the strings to filter the test in the Test filter field.
8. Click OK to open the databases.
Note:
• This feature is supported only for XML-based coverage database.
• While loading the test incrementally, you can not change the
design hierarchy and metrics.

Loading and Saving Sessions

This section describes how to save a session and load a previously

saved session.

Saving a Session
You can save all session data or arrangement of windows, views and
panes for later reuse.

To save a session, execute the following steps:

1. Select File > Save Session

The Save Session dialog box appears.

2. Select one of the following:

- Save all session data including window layout, the current view
and its contents, and coverage databases.

Viewing and Analyzing Coverage Reports Using DVE

9-11
 - Save the arrangement of windows, views, and panes.
3. Enter a file name.
4. Click Save.
The session is saved as a Tcl file for future use.

Loading a Session
To load a previously saved session, execute the following steps:

1. Select File > Load Session.

The Load Session dialog box appears.

2. Browse to a previously saved DVE session file (.tcl), and then

select the file.
When you select a session file, the right pane displays information
on the session file.
3. Click Load.
The session is loaded.

Viewing and Analyzing Coverage Reports Using DVE

9-12
DVE Coverage Source/Database File Relocation

If you change the location of a coverage file, and then attempt to load
that file with DVE, DVE displays a dialog asking you to provide the
new location of the file.

After you provide DVE with the new location of the file, DVE
subsequently uses both the built-in location and the new location
information you have provided.

DVE compares the two locations to make a more intelligent attempt

at locating the file.

For example, assume that the location of a file foo.v (as specified
in the coverage database) is as follows:

/A/B/C/foo.v

Consider that you moved the file to this location, which you provided
to DVE:

/X/Y/C/foo.v

Thereafter, DVE compares these two locations and working from

right to left, determines that the following location is the new root
directory for design files is as follows:

/X/Y

Assume now that DVE performs a search for the following file, based
on database information:

/A/B/E/bar.v

Viewing and Analyzing Coverage Reports Using DVE

9-13
 Instead of looking in /A/B, DVE searches in /X/Y, the correct
location of this file:

/X/Y/E/bar.v

If DVE cannot find the file using the default location, then DVE
displays a dialog asking for the correct location of the file.

Note:
DVE can only remember one root location directory at a time. DVE
replaces any earlier root location directory with whichever new
location you specify.

Viewing and Analyzing Coverage Reports Using DVE

9-14
Using the Coverage GUI

This section describes how to use the DVE Coverage GUI.

The Navigation Pane

Figure 9-4 Navigation Pane

drop-down shows
current coverage
database Filter drop-down

The Navigation pane is to navigate to the required database. It

consists of the following items:

• Design Hierarchy - contains the module instances in the

hierarchy. Click the plus (+) next to the top-level to see the names
of the module instances in the top-level module. They are listed
by instance name with their corresponding module name in
parentheses.

Viewing and Analyzing Coverage Reports Using DVE

9-15
 • Function Groups - contains the testbench coverage groups in
your testbench database and the OpenVera (OVA) and
SystemVerilog (SVA) assertions and cover sequences and
properties.
• Module Lists - lists all the module definitions in the design
• Text drop-down - shows the list of the coverage databases that
you have loaded recently. If you want to load another database,
you must close the database using the Close Database option in
File menu.
• Filter drop-down - maintains a history of previously applied filters.
You can see the history and select a filter to apply.
Figure 9-5 Coverage Summary Table Window

The Main Coverage Table window shows you the summary of each
type of coverage. For example, Figure 9-6 shows the details for lines
covered.

Viewing and Analyzing Coverage Reports Using DVE

9-16
 To view the coverage details, select a cell and click View > Show
Ratio.

The coverage detail appears as follows;

Figure 9-6 Line Coverage

Total lines covered Percentage of lines

covered.

Total lines uncovered

The Coverage Table window contains the following fields and

options:

Show
Provides the following options:

Functional Groups
Displays results by user-defined groups including total score and
scores for cover directive and covergroup coverage.

Instances
Displays results by module instances and their total coverage
score and individual scores for line, condition, FSM, and toggle
coverage. There is a row for each module instances (click the plus
(+) to the left of the top-level module to see the instances under
it). A plus down the design hierarchy indicates new instances to
be revealed.

Viewing and Analyzing Coverage Reports Using DVE

9-17
 Modules
Contains module names instead of instance names. There is a
row for each module definition. The coverage information
displayed for each module definition is a union of the information
that would be displayed for each instance of the module.

Test
Provides the name of the merged test that you specified in the
Open Coverage Database dialog box, see Figure 9-1.

Hierarchical Coverage
Specifies whether to display hierarchical or local coverage
numbers in the table. If it is checked, for each instance, functional
group, or module, the numbers are aggregated for all objects
hierarchically under the selected item. When you clear this check
box, the coverage numbers are for the particular item and do not
include the objects under them. When the Show field is set to
Modules, there is no hierarchical display possibility and this check
box disappears.

Detail Window
Displays coverage for each coverage type available. By default,
the Detail window shows the coverage for the metric
corresponding to the clicked column for the object in the clicked
row. Click a cell to view the Detail window.

Viewing and Analyzing Coverage Reports Using DVE

9-18
 The Coverage Summary Map Window

Use the Map window for a quick view of the overall coverage results.
The map window tabs displays results in customizable color-coded
ranges to help identify coverage areas of interest and overall
progress. Figure 9-7 shows a coverage map and the default color
key and range.

Figure 9-7 Coverage Summary Map Window

You can change the root of the map by dragging and dropping a
functional group, instance, or module from any other window.

Viewing and Analyzing Coverage Reports Using DVE

9-19
 Drill down into the view by selecting a rectangle. Double-clicking the
selected rectangle changes the view to display its children.

Review Flow for Unmappable Exclusion

The unmappable exclusion review is appended to the end of the

review list. If there is any unmappable exclusion that belongs to
current instance/module and current metric, the Unmappable
Exclusion dialog box appears. The dialog box displays only those
exclusions, which are beyond current instance/module and metric
under review, as shown in Figure 9-8.

Figure 9-8 Unmappable Exclusion Dialog Box

Viewing and Analyzing Coverage Reports Using DVE

9-20
 The Coverage Detail Window

The Coverage Detail Window displays the following fields:

• The source file with annotations indicating covered and uncovered

lines or objects.
• The Coverage Detail tabs where you select the coverage type to
view.
Figure 9-9 Coverage Detail Tab
Default coverage state Covered
Uncovered

Ports,
variables, and
signals

Viewing and Analyzing Coverage Reports Using DVE

9-21
 Navigating in the Source Pane

Use the navigation bands in the Source pane to seethe coverage

results for the source code. The bands are color-coded to display the
coverage range. To navigate to an area of interest, click on a band
to display the color-coded source line.

Note:
When viewing annotated data, DVE requires the original source
files to be unaltered since the compilation.

Figure 9-10 Source Pane

Click a band to
display
corresponding
code.

Creating User-Defined Groups

You can create and modify user-defined groups to organize and
navigate to your functional coverage elements, such as covergroups
and assert/cover statements.

To create a user-defined covergroup, execute the following steps:

Viewing and Analyzing Coverage Reports Using DVE

9-22
 1. Click Edit > Create/Edit User Defined Groups.
The x dialog box appears.

Covergroups and assertions in your project are listed in the left

pane.
Figure 9-11 User Defined Group

2. Click the Create new group icon , then accept the default
name or name your group.
3. Select cover groups and assertions from the Name list, search
using a search string, or click More to specify search options and
criteria.
4. Drag and drop the desired items into your created group.
5. Click OK.
Your group gets created and the dialog box closes. You can click
Apply to save the group. The dialog box remains open and you
can make more groups.

Viewing and Analyzing Coverage Reports Using DVE

9-23
 Display Single Cover Group in Detail Pane

The detailed pane displays only single cover group. So, when you
drag-drop or double-click a cover group variant, the detail pane
populates with only one cover group, as shown in Figure 9-12.

Figure 9-12 Single Cover Group in Detail Pane

Save the Drop-Down List Option in Detail Pane

The cross-table retains the selected menu when you return to same
cover group, as shown in Figure 9-13.

Viewing and Analyzing Coverage Reports Using DVE

9-24
Figure 9-13 Save the New Cross Selection in Detail Pane

Viewing Code Coverage

This section discusses how to view the various code coverage

metrics using DVE, in the following sections:

• “Viewing Line Coverage”

• “Viewing Toggle Coverage”
• “Displaying Condition Coverage”

Viewing and Analyzing Coverage Reports Using DVE

9-25
 Viewing Line Coverage

The Line Coverage Detail window displays the annotated source

code and coverage percentage for the total block and statement
coverage.

Figure 9-14 Line Coverage Detail Window

• The Annotated source window allows you to view the source files
annotations that shows you which code has and has not been
covered. The highlighted colors can be changed using the Colors
tab in the Preferences dialog box. The color banding adjacent to
the scroll bar aid in navigating the code. Figure 9-9 shows the
Source Window with annotations, and the default annotation
colors.
• The Detail Window for line coverage displays metrics for coverage
of blocks and statements. A block of code is a group of statements
that always will be executed together.

Viewing and Analyzing Coverage Reports Using DVE

9-26
 This display tells you how much of your code is actually executed
by the tests. The number of covered and uncovered lines give you
the information you need to write the tests to complete the
coverage.
• Use the Shown for drop-down to look at the coverage of other
instances or module variants corresponding to the current
instance or module.
• In the cross table, coverage status column is added and decorated
lines are removed as shown in Figure 9-15.
Figure 9-15 Display of Coverage Status Column

Viewing Toggle Coverage

You can view the summary of toggle coverage in the coverage

Summary Table. In the Summary Table, double-click on a row under
the Toggle column to view the coverage Details view.

Viewing Nets and Registers

The toggle coverage Details view displays the value transitions from
0 -> 1 and 1 -> 0 for each net and register.

Viewing and Analyzing Coverage Reports Using DVE

9-27
 You can also view the nets and registers highlighted with their
coverage range in the Source view. Use the Show drop-down list to
look at the coverage of other instances or module variants
corresponding to the current instance or module.

Figure 9-16 Toggle Coverage Detail view

Details table Bit List table

The toggle coverage Details view contains the following:

• Variable column - Identifies the nets and registers.

An up arrow indicates toggle from 0 to 1, and a down arrow
indicates toggle from 1 to 0. The arrow is colored green if the
toggle is covered, red if it is uncovered, and yellow when the signal
has both covered and uncovered bits.

• Type column - Displays the type, signal or a MDA.

Viewing and Analyzing Coverage Reports Using DVE

9-28
• Coverage column - Displays the total coverage of nets and
registers that tell you how much activity is occurring on all the
elements, thus giving you a clear indication of how much testing
is actually being performed at the gate. The Coverage column
indicates gray color when you exclude the signal.
• Display column - Indicates all the possible transitions for the
register with pairs of up-down arrows and displays two transitions
for each bits.
You can view the bit list of each signal in the Bit List table at the right-
side of the Details table. To see the bits, select a row in the Details
table. You can compress and uncompress the bits in the Bits List
table using either the CSM options Compress Bits and
Uncompress Bits or double-click on the bit.

Viewing Multi-Dimensional Arrays

Multi-dimensional arrays (MDAs) are displayed as toggle signals.
The top level toggle signal is named with all its indices's. Its value are
a contiguous string of values of all its leaf level words.

The top level MDA is expandable to its next level of indices similar to
a vector. Each of the MDA's layers are expandable until the bit level.
Similar to vector, the coverage information of each layer of the MDA
consists of coverage for 0->1 and 1->0 transitions.

The cumulative score of each layer in MDA is determined by

calculating the covered/total bits in that MDA layer.

You can exclude the top level MDA, any MDA layer in the middle, or
the word and bits.

Viewing and Analyzing Coverage Reports Using DVE

9-29
 The Type column in the coverage Details view indicates MDA. You
can view the MDA bits in two modes, compressed and
uncompressed, in the Bit List table.

To view compressed or uncompressed MDA bits, select the option

Compress MDA bits from Edit > Preferences > Detail View.

Displaying Condition Coverage

The Condition Detail Window helps you monitor whether both true
and false states of the conditional expressions and sub-expressions
in your code are covered.

• The Condition list expands to show coverage by possible vectors

or subconditions, percent coverage, and the line number of the
expression. By default, condition coverage only lists sensitized
vectors. For more information about sensitized vectors or how to
monitor coverage of all vectors, see the Coverage Technology
Reference Manual.
• The right pane displays the selected expression above with
possible conditions and their coverage status below.
• Use the Show drop-down to look at the coverage of other
instances or module variants corresponding to the current
instance or module.

Viewing and Analyzing Coverage Reports Using DVE

9-30
 Figure 9-17 shows the condition coverage results for a simple
expression.

Figure 9-17 Condition Detail Window

Expression coverage
totals and line numbers Selected conditional expression

Viewing Condition IDs

To view the condition IDs, select View > Show Condition IDs. The
condition IDs are displayed in the Detail window as follows:

Viewing and Analyzing Coverage Reports Using DVE

9-31
Figure 9-18 Viewing Condition IDs

Condition IDs are displayed

DVE Coverage with Condition Coverage Observability

The observability feature is used to find out the situations where a
certain part of the combinational circuit is controlling (and hence
observable) the primary output of the combinational circuit. Certain
vector combination of a subexpression is marked as covered only if
that combination is controlling the primary output in the context of the
whole expression.

You can enable the observability based condition coverage using the
-cm cond -cm_cond obs compile option.

In the DVE Coverage GUI, you can view the observability expression
in the Expression Displayer pane. The observability expression and
its values are displayed in the format: [Expression]=[Value].

Viewing and Analyzing Coverage Reports Using DVE

9-32
Displaying Finite State Machine (FSM) Coverage

The default FSM coverage tab has two views:

• The left pane displays state, transition, and sequence coverage

for each FSM with a percentage bar annotated with the total
number of covered and uncovered and the percentage of each.
• The right pane displays transition or sequence results for all
possibilities in table or list format.

Viewing and Analyzing Coverage Reports Using DVE

9-33
Figure 9-19 Default FSM Detail Display

Displaying Transition Details

The Transition Mode for the selected FSM displays all the possible
transitions and whether the current state of the FSM made any of
these transitions. You can display the results in table or list format.
Figure 9-20 shows the table view with states and transitions
displayed with covered transitions in green and uncovered
transitions in red. Transitions that are not possible are white with a
dash.

Figure 9-20 FSM Transition Detail Table

Viewing and Analyzing Coverage Reports Using DVE

9-34
 To view the transition details in list format with coverage ranges,
select Shown in List. Figure 9-21 shows transitions with covered
transitions displayed in green and uncovered in red. Not-possible
transitions are not listed in the table.

Figure 9-21 FSM Transition List

Displaying Sequences
The Sequences view shows states and sequences and their
possible coverage numbers that an FSM can follow to reach from
one state to another state. Holding the cursor on a cell displays a
tool-tip showing the sequences and their coverage.

Viewing and Analyzing Coverage Reports Using DVE

9-35
Figure 9-22 FSM Sequence Table

To view the state details in list format, select Shown in List.

Figure 9-23 shows sequences with covered sequences displayed in
green and uncovered in red.

Note:
You must turn on the sequences at compile-time to view them in
DVE by using -cm_fsmopt sequence switch.

Figure 9-23 FSM Sequence List

Viewing and Analyzing Coverage Reports Using DVE

9-36
Displaying Branch Coverage

This section describes branch coverage. You can view the branch
coverage information in the following windows:

• Summary Table - The branch coverage information is displayed

in the Branch column.
• Treemap - The Branch tab is displayed in the Treemap view
inline with other tabs.
• Application Preferences - The metric Branch is displayed in the
Coverage Settings - Coverage Weights view.
• Detail View - The Branch tab is displayed inline with other tabs.
Unlike other metrics, you can view the source code line numbers
to see the branch coverage information.

The Branch Coverage Detail Window

The Branch Coverage Detail window displays annotated source
code and coverage percentage for branch coverage.

Viewing and Analyzing Coverage Reports Using DVE

9-37
Figure 9-24 Branch Coverage Detail Window

It consists of the following panes and options:

• Source pane - allows you to view the source file annotations that
shows you which code has been covered and which has not. The
source code lines are color-annotated according to their coverage
values. You can see only the line of branches as color-annotated
and not the line of terms.
You can also see the missing Else/Default statements annotated
in the Source pane.

• The Detail List View - allows you to view the items and branches
on the left side and the branch path list on the right side. When
you select the items, the Value column will be empty. When you
select the branch, the value column gets populated with the
branch’s value.
• Show drop-down - allows you to look at the coverage of other
instances or module variants corresponding to the current
instance or module.

Viewing and Analyzing Coverage Reports Using DVE

9-38
 Note:
When there are more than 50 branches for an item, DVE changes
the report from complete table format to just the related expression
paths for a branch.

Viewing Implied Branches

The DVE Coverage GUI shows implied branches in the source
window (when you use dve -cov) only when you view branch
coverage or are analyzing the branch metric. The implied branches
of case and if statements are indicated by MISSING_ELSE and
MISSING_DEFAULT tags. You can exclude any branches tagged in
this fashion.

Displaying Assertion Coverage

DVE can display limited information about SystemVerilog Assertion

(SVA) and OpenVera Assertion (OVA) coverage.

SVA assert and cover statements and OVA assert and cover
directives appear in the Navigation pane and in the Details
Window Covers tab.

There is no coverage information in the database for assume

statements.

• To monitor SystemVerilog assert statements, include the -cm

assert compile-time and runtime option and the keyword
argument.

Viewing and Analyzing Coverage Reports Using DVE

9-39
Figure 9-25 SVA assert and cover statements in the Navigation Pane

The statements appear in the Function Groups folder in the

Navigation pane. In this example, the assert and cover
statements are in top-level module test with the block identifiers
assert1 to assert4 and cover1 to cover4.

DVE uses the following symbol to indicate an assert or cover

statement or directive:

Note:
DVE uses the same symbol for SystemVerilog and OpenVera
assert or cover statements and directives.

Viewing and Analyzing Coverage Reports Using DVE

9-40
 SVA Naming Convention

DVE lists these statements by their hierarchical name, for example:

top. dev1.specdev1.cover1

Hierarchical name of the module Block identifier of the statement

instance that contains the
assert or cover statement

If you bind an SVA module to a design module, the hierarchical name

includes the instance name of the SVA module, for example:

top.dev1.specdev1.checker1.assert1

Hierarchical name of the Instance name Block identifier

module instance to which of the SVA
the SVA module is bound, module
unit is bound

The Detail Window Covers tab puts the block identifier in a

separate column from the rest of the hierarchical name.

OVA Naming Convention

DVE lists these directives by their hierarchical name, for example:

top.dev1.specdev1.ova_unit_instance_name.directive_name

Hierarchical name of the Instance name for the Name of the directive
module instance to which OpenVera assertion
the OpenVera assertion unit
unit is bound

Viewing and Analyzing Coverage Reports Using DVE

9-41
 If you do not specify an instance name in the bind module
construct that binds the unit to the module, VCS generates an
instance name for the unit and placesit in the hierarchical name,
For example:

top.dev1.specdev1.assert1_inst00000000.directive_name

Hierarchical name of the Generated instance name Name of the directive

module instance to which for the OpenVera assertion
the OpenVera assertion unit
unit is bound

The generated instance name begins with the name of the

OpenVera assertion unit, followed by _inst and then an eight digit
number that is unique to the instance.

The Detail Window Covers tab places the name of the directive in
a separate column from the rest of the hierarchical name.

Viewing and Analyzing Coverage Reports Using DVE

9-42
 The Covers Tab

This section describes the fields and columns in the Covers Tab.

Figure 9-26 SystemVerilog assert and cover statements in the Covers

Tab

Figure 9-27 OpenVera assert and cover Directives in the Covers Tab

The Instance column lists the module instance that contains the
assert and cover statement or directive. If you bindan SVA
module, this name also include the instance name for the SVA
module. Each entry in this column also begins with the symbol for
one of these statements.

Viewing and Analyzing Coverage Reports Using DVE

9-43
 The Cover Name column lists the block identifier for assert or
cover.

The Attempts column lists the number of times VCS searches to see
if the assert statement or directive succeeded or the cover
statement or directive matched.

The Real Successes column lists the number of times assert

succeeded and the number of the cover matched. A real success
is when the entire expression succeeds or matches without the
vacuous successes.

The Real Successes column is color-coded with a 0 considered

uncovered and a non-0 considered covered. By default, covered is
displayed in green and uncovered is red. You can change the colors
in the Preferences dialog box.

The Failures column shows the number of times assert does not
succeed. cover does not have failures, so the entry for cover
statements in this column will always be 0.

The Incompletes column lists the number of times VCS started

keeping track of the statement or directive, but simulation ended
before the statement could succeed or match.

Display Excluded Covergroup in Map View

The enhanced DVE coverage usability sets a preference to display
the excluded covergroup items in map view as well, which is shown
in Figure 9-28.

Viewing and Analyzing Coverage Reports Using DVE

9-44
Figure 9-28 Setting Preference to Display Excluded Bins of Covergroup in
Coverage Map

Add/Edit and Delete Exclusion Annotation for Hierarchy Tree

This section describes the exclusion annotation for excluded tree for
instances in DVE Coverage. The Tree Exclusion menu is moved to
second level and it consists of Exclude, Unexclude, Add/Edit
Annotation and Delete Annotation options to allow the you to add/
edit and delete exclusion annotation for hierarchy tree exclusion, as
shown in Figure 9-29.

Viewing and Analyzing Coverage Reports Using DVE

9-45
Figure 9-29 Add/Edit Annotation and Delete Annotation in Exclude Tree

Viewing and Analyzing Coverage Reports Using DVE

9-46
 Applying Existing Exclusion to URG Report Generated from
DVE
In the URG window, the Exclusion of Current Session check box
is enabled, by default. Hence, the existing exclusions is applied to
URG report generated from DVE.

Figure 9-30 URG Window

Viewing and Analyzing Coverage Reports Using DVE

9-47
Displaying Testbench Coverage

DVE displays testbench coverage information as specified in

SystemVerilog covergroup constructs in SystemVerilog program
blocks and the OVA covergroup construct in the OpenVera code.

The SVA and OVA constructs specify the clocking event that defines
the coverage data reported during simulation and specifies the
coverage points monitored.

When you open a database, DVE displays the SVA covergroups and
OVA covergroup in the Functional Groups folder in the Navigation
pane.

The Covergroup tab lists covergroup items with coverage score,

goal, weight, and a coverage map view. The Covergroup Items
pane is shown in Figure 9-31. Double-click a covergroup to view the
covergroup source code in the Source Window. Expanding the
covergroup displays coverpoints, crosses, bins, and instances.

Viewing and Analyzing Coverage Reports Using DVE

9-48
 In the Covergroup detailed window, you can view the covergroup
definition and instances using the Show drop-down. You can also
use the CSM to locate instance for covergroup definition, and
definition for covergroup instance.

Figure 9-31 Covergroup Item Pane

Viewing and Analyzing Coverage Reports Using DVE

9-49
 Figure 9-32 shows the map view results for covergroup
unit_uart_interface::cov_rx_transaction. The
cumulative score for the cross below the mouse pointer in the map
view is 20.83, as displayed in the tool-tip.

Figure 9-32 Covergroup Tab

To drill down for details of the cross or cover point results, you can
double-click on a rectangle in the map view or drag and drop, or
select a cross in the left pane.

Figure 9-33 Results for Crosses

Viewing and Analyzing Coverage Reports Using DVE

9-50
 To view results in table format, select Table. Figure 9-34 shows the
tabular results for a cross listing bins and their coverage. Click the
Size column header to sort and bring the holes to the top.

Figure 9-34 Coverpoint Table View

Compute Coverage Score by Ratio

The Compute Group By Ratio option helps you to compute the

coverage score by ratio. On the View menu, choose Compute
Group By Ratio, as shown in Figure 9-35.

Figure 9-35 Compute Group By Ratio

Execute the following steps to invoke DVE with the-group ratio

option:

Viewing and Analyzing Coverage Reports Using DVE

9-51
 % dve –covdir <coverage database> -group ratio
% dve –covf <coverage database> -group ratio
The cover group scores and overall group scores are calculated as
a ratio between the numbers of covered bins and the total number of
coverable bins.

Without the -group ratio option, the score for a cover group is
calculated as the average of the percentages of individual cover
point scores.

The following figures show the difference between the score

calculation with and without the -group ratio option.

Score of cov1 50% is the average score of cp1, cp2, and cp3, as
shown in Figure 9-36.

Figure 9-36 Without group ratio option

Score of cov1 45.45% is the ratio between the numbers of covered

bins and the total number of coverable bins, as shown in Figure 9-
37.

Viewing and Analyzing Coverage Reports Using DVE

9-52
Figure 9-37 With Group Ratio Option

Filtering Instances with No Coverable Objects

Some instances or modules in your design can have no coverage

data. If your designs are large, and contain multiple such instances,
it would be difficult to find instances or modules with actual coverage
data you are interested in.

Viewing and Analyzing Coverage Reports Using DVE

9-53
Figure 9-38 Dummy Instances and Modules in the Hierarchy Pane

Viewing and Analyzing Coverage Reports Using DVE

9-54
Figure 9-39 Dummy Instances in the Coverage Table Window

Figure 9-40 Dummy Modules in Coverage Table Window

Viewing and Analyzing Coverage Reports Using DVE

9-55
 By default, DVE Coverage GUI displays only the part of design
hierarchy where the coverage data exists, and hides the instances/
modules with no coverable objects (instances/modules that have a
hierarchical coverable count of zero). This helps you to view only
instances/modules with actual coverage data, thereby saving your
debug time. This feature hides the dummy instances/modules in
Hierarchy Pane and Coverage Table that are shown in Figure 9-38,
Figure 9-39, and Figure 9-40.

To view full design hierarchy, including instances/modules with no

coverable objects; use the -show fullhier option or the DVE
Coverage Application Preferences dialog box.

To disable this feature using the Application Preferences dialog

box:

1. Select Edit > Preferences.

The Application Preferences dialog box appears.

2. In the Summary Table category, select the Show full hierarchy,

including instances that have a hierarchical coverable count
of zero check box.

Viewing and Analyzing Coverage Reports Using DVE

9-56
Figure 9-41 Viewing Full Design Hierarchy

3. Click OK.
DVE makes this mode as default until you again enable this feature
by clearing the Show full hierarchy, including instances that
have a hierarchical coverable count of zero check box.

Note:
Command-line option takes precedence over preference setting.

Working With HVP Files

You can use the DVE Coverage GUI to create HVP files. An HVP
(Hierarchical Verification Plan) is a comprehensive model that allows
you to hierarchically describe a verification plan. You can then
annotate that plan with live verification data using the Unified Report
Generator (URG) tool.

For more information about HVP files, see the LCA category in the
VCS Online Documentation.

Viewing and Analyzing Coverage Reports Using DVE

9-57
Working With Coverage Results

Running Scripts

You can perform any DVE operation with Tcl commands, including
using Tcl scripts to modify the display of your coverage data. For
example, you can omit the display of statement, instance, or module
coverage.

To select and source a TCL script

1. Select File > Execute TCL Script.

The Execute TCL Script dialog box appears.

2. Browse to the script, select it, then click Execute.

The Tcl script is executed.

Viewing and Analyzing Coverage Reports Using DVE

9-58
Filtering the Hierarchy Display

To filter the display in the Navigation pane, execute the following

steps:

1. Select Edit > Filters > Add.

The Filter dialog box appears.

2. Enter a string or expression to filter.

3. Select any of the filtering options as follows:
- Match case
- Match whole word only
- Use regular expression
4. Click OK or Apply to filter according to the criteria you specified.
The Navigation pane displays the modified results.
Filters are applied cumulatively. A filter added to an already filtered
result further filters the result display. If you want to apply the filter
to the unfiltered results, first apply a * filter to display the unfiltered
results.

Viewing and Analyzing Coverage Reports Using DVE

9-59
Generating URG Report From DVE Coverage GUI

You can generate a URG report from the DVE coverage GUI. URG
Window is the interface you use to generate the URG report. You
need to set the configuration options in the URG Window and run
URG to generate the report.

To generate a URG report

1. Load the coverage database in DVE.

2. Click Generate URG Report from the File menu.

Viewing and Analyzing Coverage Reports Using DVE

9-60
 The URG Window dialog box opens.

3. (Optional) Enter your command in the Append Options text box.

4. Click the Show/hide URG option tabs button “>>”.
The option tabs, General and HVP are displayed below the
Append Options text box.
5. Select the following options under the General tab. The options
that you select in the configuration tabs appear in the URG
Command Line text area.

Viewing and Analyzing Coverage Reports Using DVE

9-61
 - Database of Current Session — Specifies database of the
current session.
- Report Directory (-report) — Generates report in the default
directory (urgReport). Click the Set URG report directory
button to select the directory where you want to save the
generated report.
- Report Format (-format) — Specifies the report format,
HTML, text, or both, in which you want to view the report.
- Uncovered Only (-show brief) — Specifies only the
uncovered items.
- Exclusion of Current Design — Specifies the exclusion
performed in the current session. You can select this check box
if you want to include the current exclusion.
- Strict Exclusion (-excl_strict) — Specifies exclusion in
strict mode.
6. Click the HVP tab and select the check box HVP Plan of Current
Session to include the HVP plan of the current session.
7. Click Run to execute the URG report.
The URG report is generated. If there is an error in the report
generation, errors are displayed in the command line output text
area.
8. Click the Browse Report button to view the generated URG
report.
The report is displayed in a standard browser.

Viewing and Analyzing Coverage Reports Using DVE

9-62
9. Click the Customized button to display additional configuration
options and tabs (Grade and Advanced). The available
customized configuration options are as follows:

Viewing and Analyzing Coverage Reports Using DVE

9-63
 • General tab
- Design Directory(-dir) — Specifies the base design/test
directory. You can browse and select the desired base design/
test directory.
- Test Directories (-dir) — Identifies the test directories for
source data. Click the Edit button to display the Choose test
directories dialog box. You can add or delete the directories, or
move the selected directories up/down.
- Test Directory List File (s)(-f) — Specifies multiple
directories for source data in a file.
- Test List File (s)(-tests) — Specifies a file containing names
of tests to report from specified directories.
- Metrics — Specifies the metrics for Line, FSM, Condition,
Toggle, Branch, and Assertion.
- You can select your own exclusion file in the customized mode.
• HVP tab
- Top Plan File (-plan) — Reports the Hierarchical Verification
Plan (HVP) given in the specified file.
- Filter/Override (s)(-mod) — Reads filtered/overridden HVP
data from the specified file. The -plan options must also be
given.
- User-data List File (s)(-userdatafile) — Specifies a file
containing HVP data file names for annotation. The -plan
option must also be given.
- Userdata File (s)(-userdata) — Reads HVP data from the
given file for annotation. The -plan option must also be given.

Viewing and Analyzing Coverage Reports Using DVE

9-64
 - Show full HVP tree (-show hvpfullhier) — Lets you see
the full hierarchy tree, including the plans and features which
are filtered out.
- Show problem HVP tree (-show hvpprob) — Lets you see
the failed plan that was set for one or more metrics.
• Grade tab
- Grade Algorithm (-grade) — Specifies which algorithm to
use: quick, greedy, or score.
- Goal(-grade goal) — Stops grading when the cumulative
score reaches the specified goal. It has no effect on the score
algorithm.
- Timelimit (-grade timelimit) — Specifies the time limit for
the report generator to run before exiting. Only those tests that
are graded before the time limit is hit are included in the graded
list.
- Maxtest (-grade maxtests) — Specifies the maximum
number of tests to include in the report.
- Minincr (-grade minincr) — The score improvement for
each metric that the test contributed to the cumulative value
when it was merged.
- Reqtests (-grade requests) — Specifies reading a list of
test names from file_name for inclusion in the grading report.
(used only for greedy algorithm).
- Listonly (-grade listonly) — Generates only a grading
report.

Viewing and Analyzing Coverage Reports Using DVE

9-65
 • Advanced tab — Lists various URG commands with description
specified against each command.

To run URG and view the customized report, repeat Steps 7 and 8.

Viewing and Analyzing Coverage Reports Using DVE

9-66
10
Viewing and Analyzing Coverage Reports
Using Unified Report Generator 1
This chapter describes how you can generate and view coverage
reports using URG, in the following sections:

• “Supported Metrics”
• “Invoking URG”
• “Format to Display Coverage Results”
• “What is Covered in Each Coverage Metric”
• “Difference Reports for Functional Coverage”
• “Reporting Only Uncovered Objects (-show brief)”
• “Summary Only URG Reports”
• “Coverage Report Files”

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-1
 • “Performance Improvement for HTML URG Reports”

Supported Metrics

URG generates reports that include the following metrics:

• Code coverage
- “The Line Coverage Report”
- “The Toggle Coverage Report”
- “The Condition Coverage Report”
- “The FSM Coverage Report”
- “The Branch Coverage Report”
• “The Assertion Coverage Report”
• “The Covergroup Report”
The following reports are generated as .html or .txt files:

• “The Dashboard File”

• “The Hierarchy File (Design Hierarchy)”
• “The Modlist File (Design Module List)”
• “The Groups File (Testbench Group List)”
• “The modN File (Module Definition)”
• “The grpN File (Group Definition)”
• “The Tests File (Test Records)”

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-2
 • “The Assertions File”
• “The HVP File”

Invoking URG

The usage model to invoke URG is as follows:

1. Compile the test file.

% vcs [compile_options]

2. Simulate the test file.

% simv [runtime_options]

3. Run URG command

% urg -dir coverage_directory.vdb urg_options

You must specify the directories containing coverage data files.

Coverage directory contains code coverage, covergroup or
assertion/property coverage data.

Data files are grouped into tests based on the names of the tests.
Therefore, if you have the following data files, URG considers all of
them as data for 'test1'.

./simv.vdb/snps/coverage/db/testdata/test1

To report any particular metric related information, use the -metric

option with the specific metric (“+” separated arguments for more
than one metric). The possible metric arguments are as follows:

-metric [+]line+cond+fsm+tgl+assert+group

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-3
 An initial plus sign is not required, but is allowed.

By default, the coverage collection for covergroup and cover

property is turned on in VCS. Hence, there is no need to specify any
commands to collect the coverage for covergroup and cover
property. However, when you run a design to report other metric such
as line, toggle, assert, and so on, VCS reports the covergroup and
cover property metric as well, by default.

For example, if simv.vdb contains coverage for line, covergroup,

and cover property, but if you are interested to get only the report for
line metric, then you can achieve it by using the following
command:

% urg -dir simv.vdb -metric line

If no -metric argument is specified, then URG reports all type of
coverage in the indicated coverage directories.

URG generates the reports and places them in a directory

urgReport, by default. Each time URG is run, the report directory
is overwritten by the new report files. You can use -report mydir
option to save the generated reports in mydir.

For example:

% urg -dir simv.vdb -metric line+fsm -report mydir

Since urg is a UNIX command, the arguments may include shell

variables, absolute, or relative paths, such as:

% urg -dir $MYDIR/foo.vdb

% urg -dir $MYDIR
% urg -dir ~username/covd ~username/covd/simv1.vdb

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-4
Note:
When the design and test databases are different, you need to
pass design database as the first argument in URG.

Merging Coverage Results of Several Runs of the Same

Executable
To merge the coverage result of several runs of the same
executable, simulate the executable with different stimuli +number,
or $value$plusarg option, and give a unique name to the test
using the -cm_name option:

% simv -cm line +number=2 -cm_name test_2

% simv -cm line +number=1 -cm_name test_1
% simv -cm line +number=0 -cm_name test_0
The results can be merged and displayed using URG as follows:

% urg -dir simv.vdb

Now open the URG reports, select tests.html and the following
text is displayed in the report:

Data from the following tests was used to generate this report
simv/test_0
simv/test_1
simv/test_2

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-5
 Merging Coverage Database Across Versions of VCS
A database created with a given major version of VCS can be read
with any of the coverage tools from the same major version. For
example, a database created with VCS 2012.09 (for any patch
number) can be read by URG or DVE Coverage GUI from VCS
2012.09 (again, any patch number) or UCAPI-based application
linked against a VCS 2012.09 UCAPI library. This is called as Patch-
to-Patch compatibility.

Databases created with one major version are not guaranteed to be

compatible with tools from a different major versions. For example, a
database written from VCS 2012.09 is not guaranteed to be readable
by tools from VCS 2011.12. Thus Release-to-Release compatibility
is not guaranteed.

For more details about how versioning is done, see the section
“Version Check” in the Coverage Technology Reference Manual,
which discusses the major / minor version numbers maintained in
the database's XML files. Note that DVE Coverage GUI and URG
uses the UCAPI, thus the requirements are the same.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-6
Format to Display Coverage Results

URG introduces two basic types of format to display coverage

results:

• Statistics table
• Table of coverable objects
Statistics tables are summaries of types of coverage elements. Each
line in a statistics table reports the coverage for a class or category
of object. Figure 10-1 shows an example of a statistics table for line
coverage:

Figure 10-1 Example of a Statistics Table

Statistics tables are color-coded using the same color legend as for
coverage tables shown in Figure 10-45.

The table of coverable objects shows the coverage results for

individual coverable objects. Coverable objects do not have
percentages; they are either covered or uncovered. Coverable
object tables show covered (and observed) objects in green and

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-7
 uncovered or partially covered objects in other colors as per the
coverage percentage. Figure 10-11 in the Condition Coverage
Section shows a coverage data table for condition coverage.

For all types of coverage, the data section begins with a statistics
table showing the basic categories (for example, lines, statements,
and blocks, or logical and non-logical conditions). This is followed by
a table of coverable objects.

Note that several metrics have options that change exactly what is
covered and how to display it. For example, use the condition
coverage option -cm_cond allops to control which vectors and
conditions are monitored. For more information, see the Coverage
Technology Reference Manual in the VCS VCS MX SolvNet online
support site at:

https://solvnet.synopsys.com/

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-8
What is Covered in Each Coverage Metric

URG, by default, shows detailed coverage reports for all the modules
and instances for any given metric. URG shows the entire summary
table for a metric it reports. Figure 10-2 is an example for toggle
coverage report.

Figure 10-2 Example of a Toggle Coverage Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-9
 The Line Coverage Report

The line coverage report starts with a table listing individual statistics
of each always block, initial block, VHDL process, and continuous
assignment. For example,

Figure 10-3 Example of a Line Coverage Section Report

Note that each line in the table is identified by its type (always, initial,
continuous assignment, and so on) and its starting line number.
These entries do not represent the scores for individual lines or
statements, but for the whole always block, initial block, VHDL
process, or continuous assignment. You can then see which part(s)
of the module require the most attention.

If the source code of your design is available, the second section in

the report displays the annotated source code. The first column
shows the line number in the source file. If a line contains a
coverable statement, the second column shows the number that are
covered and the total coverable statements that begin on that line.
For example, on line 231 in Figure 10-4, there is one coverable
statement and it is covered (1/1). On line 238, there is one coverable
statement and it is not covered (0/1). On line 244, there are two
coverable statements and the two statements are covered (2/2).

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-10
 Each coverable statement appears in boldface – black if covered,
red if uncovered.

Figure 10-4 Example of an Annotated Source Code File

Note:
When statements are spread across multiple lines, the covered/
coverable numbers and the coloring will only be shown on the first

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-11
 line (as shown on line 226 in the example above).

If the source code of your design is not available (for example,

source code files have been moved to a new location, the files are
not read-accessible, or the files are not visible on the machine/
network on which you are running URG), then URG generates a
simplified report in place of the annotated source, as shown in
Figure 10-5.

Figure 10-5 Example of a Simplified Report

Note that URG only lists lines with statements on them in the
simplified report.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-12
Annotating Macro Instantiations in Line Coverage
URG annotates the coverable objects present in macro
instantiations. This enables you to get the exact information about
the line coverage of the objects present inside a macro instantiation.

Use Model
Consider the following design source code file source.v and the
macro file gt_macros.sv:

source.v

`include "gt_macros.sv"
2 module bot;
3 logic [2:0] sigA;
4 logic [2:0] sigB;
5 logic [2:0] a;
6 logic [2:0] b;
7 logic [2:0] a1,b1,c1,d1;
8 logic [2:0] d;
9 bit clk ;
10
11 `ALWAYS (sigA[2:0],sigB[2:0],clk)
12
13 initial begin
14 clk = 0;
15 #1 clk = 1;
16 #1
17 $finish;
18 end
19 endmodule

gt_macros.sv

1 `define DELAY #1
2
3 `define ALWAYS(q,i,clock) \

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-13
 4 always @(posedge clock) \
5 begin \
6 if(i) \
7 q = (i && i);\
8 else\
9 q = (i || i);\
10 #1; \
11 q <= `DELAY i; \
12 end

Use the following command to compile and run this example:

% vcs -sverilog -cm line source.v -R

You can see the precise line coverage information of the expanded
macro instantiation. The report shows the lines that are covered and
the lines that are not covered in the macro instantiation.

URG Report

To generate the line coverage report, execute the following

command:

% urg -dir simv.vdb -format text

The following is the line coverage report for the preceding example:

---------------------------------------------------------------------
Line Coverage for Module : bot

Line No. Total Covered Percent

TOTAL 11 8 72.73
ALWAYS 11 6 3 50.00
INITIAL 14 5 5 100.00

10
11 3/6 ==> `ALWAYS (sigA[2:0],sigB[2:0],clk)
ALWAYS (sigA[2:0],sigB[2:0],clk):
11.1 always @(posedge clk)
11.2 begin
11.3 1/1 if(sigB[2:0])

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-14
11.4 0/1 ==> sigA[2:0] = (sigB[2:0] && sigB[2:0]);
11.5 else
11.6 1/1 sigA[2:0] = (sigB[2:0] || sigB[2:0]);
11.7 1/2 ==> #1;
11.8 0/1 ==> sigA[2:0] <= #1 sigB[2:0];
11.9 end
12
13 initial begin
14 1/1 clk = 0;
15 2/2 #1 clk = 1;
16 1/1 #1
17 1/1 $finish;

---------------------------------------------------------------------

In the annotated coverage report, the line number shown for each
statement of a macro expansion is given as N.M, where N is the line
number where the macro is instantiated in the source, and M is the
line number of the coverable object relative to the macro definition.
So for a macro on line 11 that spans across 9 lines (as in the example
above) the first object is numbered 11.1, the second 11.2, and so on.

After the expanded macro text, the regular source code text of the
file continues on the next line.

The following is the line coverage report in the HTML format:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-15
 Collapse icon

You can distinguish the macro text from the other statements in the
HTML report as it is displayed with a light gray background.

If any lines of the macro definition file are not covered or if it is

partially covered, these lines appear in red font.

By default, the macro text is expanded in the URG HTML report. You
can click the expand/collapse icon to show or hide the macro text.
The following report hides the macro text:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-16
In addition to the displayed macro text, the URG HTML report also
links the macro name to the macro definition source file. When you
click the macro name, the corresponding macro definition file opens
in a separate page as shown in the following figure:

Annotating Nested Macros

If a macro definition contains nested macros, all the nested macros
are expanded in the annotated report. Any macro that is expanded
within another macro is not considered as a separate macro during
annotation. The offsets of the nested macro are shown with
reference to the top level macro.

For example,

`define STMTLIST wait (clk==1'b0); \

wait (clk==1'b1);

`define MY_ALWAYS1(stmtlist) always \

begin \
wait ((clk===1'b1) && (`MYDATA===8'bz)) \
begin \
->dbevt; \
end \
stmtlist \

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-17
 end

module m;
…
`ALWAYS1(`STMTLIST)

endmodule

The macro annotation for the stmtlist macro is as shown in the

following report:

94 1/6 ==> `MY_ALWAYS1(`STMTLIST)

MY_ALWAYS1(`STMTLIST):
94.1 always
94.2 begin
94.3 1/1 wait ((clk===1'b1) && (data===8'bz))
94.4 begin
94.5 0/1 ==> ->dbevt;
94.6 end
94.7 0/2 ==> wait (clk==1'b0);
94.8 0/2 ==> wait (clk==1'b1);
94.9 end

Annotating Multiple Macros

If a line statement contains more than one macro, URG shows the
macro text in sequence as shown in the following report. URG does
not conjunct all the macro text and the full name (macro name with
parameters) of the macro instantiation is displayed.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-18
Support for Test Correlation in Macros
You can see the test correlation information in the expanded macro
annotation. Run the urg command with the -show tests option to
enable the test correlation feature for macro instantiations. For more
information about test correlation, see Section “Correlation Report:
Determining Which Tests Covered Which Objects”.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-19
 Excluding Macros
You can use exclusion files to exclude macro instantiations from
annotations. Note that, though the macro is completely excluded, its
text can be expanded as shown in the following report:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-20
If a macro is partially excluded, the coverage data is displayed for
each macro statement as shown in the following report:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-21
 Limitation
URG supports executable statement level macro annotation in line
coverage. However, URG does not support expression level macro
annotation.

Consider the following example,

`define MYDATA data

`define VALUE 1'b0
……
always
begin
wait((clk===1'b1) && (`MYDATA===8'bz))
begin
->dbevt;
end
wait(clk==`VALUE);
end

In this example, VALUE is an expression level macro and the URG

report for this macro annotation does not show the content of the
VALUE macro as shown in the following report:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-22
 The Toggle Coverage Report

URG covers any toggle, be it 1->0 or 0->1. The toggle coverage

report starts with a table containing the number of signals, the bits in
each, and the summary coverage statistics for each type of signal. It
then shows a table for each type of signal, listing each signal and
indicating whether it was fully covered or not. The following figure is
an example toggle summary table.

Figure 10-6 Example of a Toggle Coverage Summary Report

The following figure shows a toggle coverage detailed report. In the

detailed table, URG lists signals and ports that are not fully covered.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-23
Figure 10-7 Example of a Toggle Coverage Detailed Report

Support for Interface Signals on Port Boundary

VCS supports toggle coverage on port interface signals. VCS

includes interface signals as part of the toggle coverage score for a
given module or instance. You can use the toggle coverage compile-
time option –cm_tgl fullintf to get toggle coverage reports for
all signals of an interface located within the port boundary of a
module or instance.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-24
 Use the -cm_tgl fullintf compile-time option to get toggle
coverage on interface signals. Using this option enables full interface
flattening at port boundaries. Therefore, this option reports all
interface signals used in a module port list as port signals of the
corresponding module or instance.

Consider the code shown in Example 10-1.

Example 10-1 Toggle Coverage

interface intf(input bit clk);
logic dvld;
logic ack;
endinterface

module mod(intf intf1, input clk);

always @(posedge clk)
$display("\n Hello World ");
endmodule

module tb();
logic clock;
intf intf_0(clock);
mod mod_0(intf_0, clock);
initial begin
clock = 0;
forever #3 clock = ~clock;
end

initial
#15 $finish;
endmodule

A coverage report generated with –cm_tgl portsonly looked like

Figure 10-8.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-25
Figure 10-8 Coverage Report Generated With -cm_tgl portsonly
Module Instance : tb
SCORE TOGGLE
-- --

Module Instance : tb.intf_0

Port Details
Toggle Toggle 1->0 Toggle 0->1 Direction
clk Yes Yes Yes INPUT

Toggle Coverage for Instance : tb.intf_0

Total Covered Percent
Totals 1 1 100.00
Total Bits 2 2 100.00
Total Bits 0->1 1 1 100.00
Total Bits 1->0 1 1 100.00

Module Instance : tb.mod_0

Port Details
Toggle Toggle 1->0 Toggle 0->1 Direction
clk Yes Yes Yes INPUT

Toggle Coverage for Instance : tb.mod_0

Total Covered Percent
Totals 1 1 100.00
Total Bits 2 2 100.00
Total Bits 0->1 1 1 100.00
Total Bits 1->0 1 1 100.00

In Figure 10-8, for instance tb.mod_o, only port signal clk is

reported. Interface signal intf1 is not reported.

A coverage report generated with -cm_tgl fullintf looks like

Figure 10-9. Here, interface intf1 declared at port list is expanded
and shares coverage data from its source interface instantiation.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-26
Figure 10-9 Coverage Report Generated With -cm_tgl fullintf
Module Instance : tb.intf_0
Port Details
Toggle Toggle 1->0 Toggle 0->1 Direction
clk Yes Yes Yes INPUT
dvld No No No INOUT
ack No No No INOUT

Toggle Coverage for Instance : tb.intf_0

Total Covered Percent

Totals 3 1 33.33
Total Bits 6 2 33.33
Total Bits 0->1 3 1 33.33
Total Bits 1->0 3 1 33.33

Module Instance : tb.mod_0

Port Details
Toggle Toggle 1->0 Toggle 0->1 Direction
clk Yes Yes Yes INPUT
intf1.clk No No No INPUT
intf1.dvld No No No INOUT
intf1.ack No No No INOUT

Toggle Coverage for Instance : tb.mod_0

Total Covered Percent
Totals 3 1 33.33
Total Bits 6 2 33.33
Total Bits 0->1 3 1 33.33
Total Bits 1->0 3 1 33.33

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-27
 Excluding Interface Signals From Design
Following is the syntax to exclude interface signals from a given
design:

-node <instance pattern> <signal pattern>

Consider the code shown in Example 10-2.

Example 10-2 Excluding interface signals

interface intf(input bit clk);
logic dvld;
logic ack;
endinterface
module mod(intf intf1, intf intf2, input clk);
always @(posedge clk)
$display("\n Hello World ");
endmodule

module tb();
logic clock;
intf intf_0(clock);

mod mod_1(intf_0,clock);
mod mod_2(intf_0,clock);
initial begin
clock = 0;
forever #3 clock = ~clock;
end
initial
#15 $finish;
Endmodule

You can use the following command to exclude signal ack from all
instances of module mod:

-node tb.mod_* intf*.ack

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-28
Note:
This solution also applies to structure, which has nesting similar
to interface signals.

Interface Expansion Limitations

The following limitations apply for interface expansion at the port
boundary using the –cm_tgl fullintf option:

• Enums are not supported within interfaces. You can infer real
values of enum changes from FSM coverage, which shows
transitions between two enum states. For example:
interface intf(input bit clk);
typedef enum reg[1:0] {pink,red,yellow} color;
color d;
clocking master_cb @(posedge clk);
inout d;
endclocking
modport master (import master_cb.d);
endinterface

module tb();
logic clock;
intf intf_0(clock);
endmodule

• Port interfaces which have an instance array in the path between

the ref and actual handle are not supported. Consider the following
example:
interface wbone;
logic cyc_o;
modport dut_slave( output cyc_o);
endinterface

module dut(wbone.dut_slave sifc_0);

reg m_select;

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-29
 endmodule

module dut_shell(wbone sifc[1] );

dut dut1(sifc[0].dut_slave);
endmodule

module top;
wbone wbone_sifc[1]();
dut_shell mydut(wbone_sifc);
endmodule

In the above example, coverage for instance top.mydut and

top.mydut.dut1 is not reported because top.mydut has an
instance array in its port list, and top.mydut.dut1 has an
instance array in the path between its ref instantiation and actual
instantiation.

• Nested interfaces are not supported.

Interfaces instantiated within other interfaces are not reported at
the port boundary of a given module. Coverage reports only
interface self signals (that is, port signals + local signals) at any
ref port. It does not report nested interface signals at the port
boundary. For example, consider the following code:

interface intf(input bit clk);

endinterface

interface nst_intf(input bit nst_clk, intf s1);

ntf s2(nst_clk);
endinterface
module mod(nst_intf intf1,input clk);
endmodule

module Top();
logic clock;
intf intf_0(clock);
nst_intf nst_intf_1(clock,intf_0);
mod mod_0(nst_intf_1,clock);

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-30
 endmodule

Thus, in the above example, for interface nst_intf, interface

s1 is part of the port list of interface nst_intf, but interface s2
is the physical instantiation inside the interface nst_intf. So,
for instance top.mod_0 of module mod, the following list of
signals is reported.

Top.mod_0.clk
Top.mod_0.intf1.nst_clk
Top.mod_0.intf1.s1.clk

s2 is a physical instantiation of an interface. In any case s2 is

reported as a separate instance:

Top.nst_intf_1.s2

In general, all nested interface data reported for a given interface

at a module port boundary can be too much data, given that
nesting of interfaces can be deep. Nested interfaces are always
reported as separate instances anyway.

Therefore, for precise and clear reporting, it is better to report only

one level of interface data for a given interface in a module.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-31
 The Condition Coverage Report

By default, condition coverage reports shows the conditions True or

False for all the logical operators and its sensitized vectors for the
expression and its sub-expressions, as shown in the following report:

Figure 10-10 Example of a Condition Coverage Report

Figure 10-11 shows a sample condition coverage report with nested

conditions.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-32
Figure 10-11 Example of a Condition Coverage Report with Nested
Conditions

When there are nested conditions, URG reports them hierarchically.

For example, using the expression (kp_hold && (y_tot || x_not), the
two terms for the operator && is (kp_hold) and (y_tot || x_not).

The subexpression (y_tot || x_not) is then broken down into its terms,
y_tot and x_not. These are reported separately in the second
section.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-33
 Condition Coverage Report Splitting for Large Number
of Conditions
A module may contain an extremely large number of conditions and
at times the report page may be too large for a browser to handle.

Using URG, you can separate the condition report itself into its own
page. But it can happen that the condition section by itself is still too
large. In such cases with large expressions, the URG report will be
split in a list format. You can control the splitting threshold using the
URG option -split N. If page size of the line coverage annotation
exceeds N, it is moved into a new page, and links are created for
navigation.

Note:
Starting with VCS K-2015.09 release, the -split N and -split
metric options are not supported. However, these options can
be used with the -legacy option on the urg command line.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-34
Figure 10-12 List format for coverage text report with large expressions

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-35
Figure 10-13 HTML report to cover large expressions

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-36
 The FSM Coverage Report

The FSM coverage report begins with a summary table for states,
transitions, and sequences for all FSMs in the module/instance/
entity. Subsequently, it shows individual state, transition, and
sequence tables for each FSM.

Figure 10-14 Example of an FSM Coverage Summary Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-37
 The Branch Coverage Report

URG branch coverage reports display the source code text with
annotations showing both covered and uncovered branches.
Consider the following lines from a design source code file:

Example 10-3 Lines from Design Source Code

/*** the write ***/
always @ (posedge clk)
if ((write > 0) & !full)
begin
dfifo[head] <= #`DELAY data_in;
#`DELAY head = head + 1;
e_count = e_count + 1;
end
else if (write & (full != 0))
$display ($stime," tried to write a full fifo");
/*** the read ***/
Figure 10-15 shows its branch coverage report.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-38
Figure 10-15 URG Branch Coverage Report

In Figure 10-15, the URG branch coverage report first shows the
source code, which contains the branch alternatives for a given
branch, with each branch control highlighted and indexed with a
number. Subsequently, the source code is followed by a table
showing the different combinations and the coverage status of the
control branches.

One difference between URG and DVE Coverage GUI reports is that
URG displays an arrow (==>) for each branch.

Note that the index number for control branch -1- is colored in green
because it is fully covered. The arrow (==>) is at the same
indentation as the corresponding index. The index of control branch
-2- is in red because it is not fully covered, that is, the else
statement branch is not covered.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-39
 For ternary operators, the URG report is similar to the report
displayed in Figure 4.17:

Figure 10-16 Coverage Example of a Ternary Operator

If there are multiple branches, each branch has its individual index
and an arrow (==>) beneath each index. For example:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-40
Figure 10-17 Example of Multiple Branches

Branch coverage for case statements follows the same reporting

mechanism as described in the previous examples, Figure 10-18 is
an example of case statement.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-41
Figure 10-18 Case Statements Example

The summary table for branch coverage is organized by top-level

branch statements (these correspond directly to the tables in the
detailed reports). The summary table shows the line number on

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-42
 which the branch statement starts, the number of branch alternatives
the branch contains, and the number of branches covered. For
example:

Number of
Line Number Branches Covered Percentage

1 3 0 0.00
15 3 2 66.67
316 2 1 50.00

The Assertion Coverage Report

URG reports the details of an assertion. It tells you how many times
the assertion has succeeded and failed.

Summary Tables
The URG asserts.html page includes five summary tables, as shown
in Figure 10-20. Every first column of these summary tables provides
a hyperlink to navigate from summary table to detail table (see
Figure 10-21).

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-43
Figure 10-19 Summary Tables in asserts.html Page

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-44
Detail Report for Assertions
The Detail Report for Assertions includes the following tables, as
shown in Figure 10-21.

• Assertions Uncovered
• Assertions Success
• Assertions Failure
• Assertions Incomplete
• Assertions Without Attempts
• Assertions Excluded
Note:
The “Assertions Without Attempts” table will not be included in
“Detail Report for Assertions”, if there are no incomplete
assertions.

Information related to excluded assertions are displayed in a

separate row in “Summary for Assertions” table, as shown in
Figure 10-20.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-45
Figure 10-20 Viewing excluded assertions

The list of all excluded assertions will be displayed in “Assertions

Excluded” table, as shown in Figure 10-21, in “Detail Report for
Assertions”.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-46
Figure 10-21 Tables in “Detail Report for Assertions”

The first column lists the names of the block identifier for assert or
cover statements.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-47
 The ATTEMPTS column lists the number of times VCS began to see
if the assert statement or directive succeeded or the cover
statement or directive matched.

The REAL SUCCESSES column lists the number of times the assert
statement succeeded. A real success is when the entire expression
succeeds or matches without the vacuous successes. This column
is color-coded. A cell with 0 value shows there are no real success
and is colored in red and the success values are shown in green.

The MATCHES column (displayed in the Cover Properties detail

report) lists the total number of times the cover statement matched.
The MATCHES column is color-coded according to its content. A cell
with a 0 value is considered not covered and is displayed in red,
while a cell with a non-zero value is considered covered and is
displayed in green.

The FAILURES column lists the number of times the assert

statement does not succeed. Because cover statements do not
have failures, the entry for cover statements in this column is not
shown.

The INCOMPLETES column lists the number of times VCS started

keeping track of the statement or directive, but simulation ended
before the statement could succeed or match.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-48
 Detail Report for Cover Sequence
The “Detail Report for Cover Sequence” section now includes the
following tables, as shown in Figure 10-22.

• Cover Sequences Uncovered

• Cover Sequences All Matches
• Cover Sequences First Matches
• Cover Sequences Excluded
Figure 10-22 Tables in “Detail Report for Cover Sequence”

Detail Report for Cover Properties

The Detail Report for Cover Properties includes the following tables:

• Cover Properties Uncovered

• Cover Properties Matches
• Cover Properties Excluded

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-49
Figure 10-23 Detail Report for Cover Properties

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-50
 The Covergroup Report

Each covergroup report lists all points and crosses and their
coverage scores at the top.

Figure 10-24 Example of a Covergroup Report

In Figure 10-25, the VCS coverage feature hole analysis

compresses 4 bins into a single row for the UNCOVERED BINS
table. The following is an example of cross details:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-51
Figure 10-25 Example of a Detailed Cross Table

There is also a section for each point and cross showing the
individual coverage percentage, information about the point or cross,
and so on.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-52
Viewing Results for Coverage Group Variants
A shape designation in a coverage group name indicates coverage
results for variants of a coverage group. Because parameter values
can affect the number or size of bins to be monitored, coverage
group instances can have different shapes.

In the following Vera example, the program has two instances of W

(w1 and w2). Variants of the coverage group, cov0, were instantiated
with different parameters in w1 and w2.

#define UPPER 4'h7

#define LOWER 4'h0

class W {
rand bit [3:0] addr;
rand bit [3:0] resp;

coverage_group cov0(bit [3:0] lower, bit [3:0] upper)

{
sample_event = @(posedge CLOCK);
sample resp;
sample addr;
cross cc1 (resp, addr) {
state cross_low_range( addr >= lower && addr
<= upper );
}
cumulative = 1;
}

task new(bit [3:0] lower, bit [3:0] upper) {

cov0 = new(lower,upper);
}
task display(integer id = -1) {
printf("%d -> \t%h \t%s \n", id, addr, resp);
}
}

program prog {

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-53
 W w1, w2;
w1 = new(LOWER, UPPER);
w2 = new(LOWER+8, UPPER+8);
@(posedge CLOCK);

void = w1.randomize() with {addr == 4'h6;};

w1.display(1);

void = w2.randomize() with {addr == 4'h6;};

w2.display(2);

@(posedge CLOCK);

The coverage results for w1 and w2 are found in W::cov0_SHAPE_0

and W::cov0_SHAPE_1, respectively.

Crosses for Group : W::cov0_SHAPE_0

Automatically Generated Bins for resp
name count at least
auto[3:3] 1 1

Samples for Group : W::cov0_SHAPE_1

Automatically Generated Bins for resp
name count at least
auto[6:6] 1 1

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-54
Understanding Covergroup Page Splitting
In some situations, the detailed covergroup report can become quite
large, which can cause difficulties when you load and view the report.
You can split such large reports into meaningful smaller pages using
the option -split N.

The -split N option controls the size of all files before being split.
The argument is an integer specifying the maximum size in
kilobytes (KB) for any generated file. This number is used as a
guideline, not an absolute limit. The default value is 200KB.

Note:
The page-splitting functionality applies only to HTML reports, not
text reports.

Starting with VCS K-2015.09 release, the -split N and -split

metric options are not supported with URG. However, these
options can be used with the -legacy urg option.

Note:
You can split covergroup using three methods: Instance splitting, Bin
table splitting, and Variable/Cross splitting.

Instance splitting
URG splitting behavior for covergroup instances resembles code
coverage splitting for module instances. When URG generates a
report for any group instance, URG checks the size of the current
page and creates a new page if the report exceeds the value you
defined with -split N.

URG never splits a group report.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-55
 Page name: original_page_name + "_i" + instance_id

For example, grp1_i1.html, grp1_i2.html, grp2_i1.html, ...

Bin table splitting

The bin table splitting has two modes, single page mode and multiple
page mode.

single page mode

This mode can be used for bin tables that are big enough to have
their own pages, but not big enough for further splitting. If a bin table
has more than "split_bin", but less than "bin_part" rows, it will be
moved into an individual bin table page. In this situation, the
covergroup page displays a note alerting you to the multiple-page
splitting that URG has performed. The covergroup page also
contains links to the various pages.

Page name: original_page_name + "_bin" + bin_id

For example, grp1_bin1.html, grp1_bin2.html,

grp2_1_bin1.html, ...

In the bin table page, there are:

• Ordinary page head and foot.

• The bin table.
• Links "Go back" pointing to exactly where the table used to be in
the covergroup page.
In the following figures, Figure 10-26 shows the original report and
Figure 10-27 shows how the report is split.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-56
Figure 10-26 Single page mode

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-57
Figure 10-27 Single Page Split Report

multiple pages mode

If a bin table has more than "split_bin" and "bin_part" rows, it will be
split into several pages, each has at most "bin_part" rows. This mode
is used for bin tables that are so huge that further splitting is a must.

Notice that in this mode sort works only in the current bin table sub-
page.

Page name: original_page_name + "_bin" + bin_id + "_" + page_id

For example, grp1_bin1_1.html, grp1_bin1_2.html,

grp2_1_bin1_1.html, ...

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-58
In the covergroup page, the original bin table is substituted by the
following elements:

• A note "This cross/variable has %d bins so the list has been split
into multiple HTML pages. Click on the page number below to see
each subset of bins."
• A summary table (page link / expected / uncovered / covered /
percent).
In the following figures, Figure 10-28 shows the original report and
Figure 10-29 shows how the report is split.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-59
Figure 10-28 Multiple page

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-60
Figure 10-29 Multiple Page Split Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-61
 Variable or Cross Page Splitting
In variable/cross splitting method, instead of reporting each variable/
cross after the summary table on the same page, they are split into
sub-pages linked by the summary table. The splitting is controlled by
the URG option -split N.

If the covergroup page name is "grp4.html", the sub-page names are

"grp4_1.html", "grp4_2.html" ….

Covergroup instance splitting works together with variable/cross

splitting.

If the covergroup page name is "grp4.html", the split instance page

names are "grp4_i1.html", "grp4_i2.html"...., then sub-page names
become "grp4_i1_1.html", "grp4_i1_2.html" ….

For example in the following Figure 10-30, RD/WD/RDXWD has

been split into multiple sub-pages.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-62
Figure 10-30 Variable/Cross Splitting

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-63
 Correlation Report: Determining Which Tests Covered
Which Objects

When you have multiple test files (intermediate results files) from
multiple simulations, URG merges the coverage results so that if
something is covered in one, but not all the test files, URG reports it
as covered. URG indicates this information in the modinfo.txt/
mod*.html pages as to which test covered each metric.

You can use the URG -show tests option to see the list of tests
that cover objects for all coverage metrics. You can see the test
information for a specific metric using the sub-options for line,
condition, toggle, FSM, assert or group.

For example,

Including only the -show tests option as shown in the following

urg command line shows the test information for all metrics:

% urg -dir … -show tests

Including line+cond+tgl with -show tests as shown in the

following command shows the test information for line, condition and
toggle metrics:

% urg -dir … -show tests line+cond+tgl

Including fsm with -show tests as shown in the following

command line shows the test information for FSM metrics:

% urg -dir … -show tests fsm

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-64
By default, when using the -show tests option, a maximum of
three tests are shown for each coverable object. You can change
that limit by using the -show maxtests N option, where N is the
maximum number of tests you want to show for each covered object.
For example,

% urg -dir … -show maxtests 5

When the -dbname option is added to -show tests, a merged

database is created with up to maxtests test names for each object
saved from the individual databases. For example, if databases
simv1.vdb and simv2.vdb are merged into mergeddb.vdb, the
merged database will include all the individual tests in simv1.vdb
and simv2.vdb and will store which of those tests covered each
object, up to maxtests per object.

% urg -dir simv1.vdb/ -dir simv2.vdb -dbname ./mergeddb \

-show tests -format both -show tests
If the URG report is generated with mergeddb.vdb and with the
-show tests option, the report shows the original simv/test1
and simv/test2 information as shown in Figure 10-31.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-65
Figure 10-31 Test Information in the Merged Database

Viewing Tests for Covered Objects

This section describes the URG reports for line, condition, branch,
toggle, FSM, assertions and functional covergroups with tests
information.

In the coverage detail report, to see the test name in the URG HTML
report, hover the cursor over the test number.

Line Metric
URG displays the tests covering line objects. The tests covering the
line coverage object are listed after the line.

For example, line 185 of the design source code is covered by test
numbers T1, T2 and T3 as shown in Figure 10-32. When you hover
the cursor over T3, its corresponding test name simv/test3 is
displayed as shown in Figure 10-32.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-66
Figure 10-32 Line Coverage Report Showing Test Information

If more than one object is shown in the same line, a "|" is displayed
to separate the test list for each object. For example, both the objects
in line 194 are covered by T1, T2 and T3 as shown in Figure 10-32.

Condition Metric
URG reports the tests that cover the conditions in a design source
code.

For example, URG reports the status for the combination of truth or
falsity of the conditions kp_hold, y_tot, and x_not and displays the
test numbers T1, T2, and T3, that cover these combinations as
shown in Figure 10-33.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-67
Figure 10-33 Condition Coverage Report Showing Test Information

Branch Metric
URG reports the coverage status for the possible expression values
of control branch 1 and the test numbers that cover these
possibilities. In Figure 10-34, for the expression shown, true case is
covered by T1,T2 and T3 and false case is covered by T1, T2 and
T3.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-68
Figure 10-34 Branch Coverage Report Showing Test Information

If an existing design source file is not available for annotation

because of renaming or moving the database, the test information
for branch coverage metric is shown only with the line ID or block ID
as shown in Figure 10-35.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-69
Figure 10-35 Branch Coverage Report Showing Test Information

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-70
 Toggle Metric
In the following example, tests covering the transitions 1->0 and
0->1 for the various signals are shown in Figure 10-36.

Figure 10-36 Toggle Coverage Report Showing Test Information

If a part of the bit vector is covered (for example, if only addr[5:0]

is covered out of the signal addr[7:0]), URG shows the tests for
covered bits. Figure 10-37 shows that tests T1, cover addr[5:0],
whereas hold[7:6] is uncovered.

Figure 10-37 Toggle Coverage Report Showing Test Information

Figure 10-38 is a snapshot of URG report, which shows the tests

information for toggle coverage of a multidimensional array (MDA).

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-71
Figure 10-38 Toggle Coverage Report Showing Test Information for MDA

FSM Metric
URG reports the tests that cover FSM transitions, states and
sequences. The first section of the report lists the states, status of
coverage and the test numbers. The subsequent section lists the
transitions, status of coverage followed by the test numbers that
cover these transitions. FSM sequences are listed in the third table
with its corresponding status and tests.

A sample FSM coverage report is as shown in Figure 10-39.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-72
Figure 10-39 FSM Coverage Report Showing Test Information

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-73
 Functional Coverage Metric
When reporting which tests covered which object for group
coverage, the tables showing the covered bins have additional
columns. The “TEST” column gives the ID number assigned to each
test, and the COUNT column shows the hit count for that bin. If the
maximum number of tests being reported per object is N, then N
additional TEST/COUNT columns is shown as follows:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-74
Assertion Metric
For assertion, additional tables are added after original assertion
tables. Every assertion with non-zero attempt has its own detailed
table, with the name as header. First row of a detailed table is the
total count, followed by rows of contributing tests. Test numbers (of
format T1, T2, ...) are also used here.

For example, an assertion table is shown similar to the following:

Tests Page
The list of tests in the tests page (tests.html/txt) has the
columns: TEST NO, TEST NAME, USER TEST NAME, STATUS,
STARTED, FINISHED and SIMULATION TIME showing all the test
numbers used in the coverage reports (T1, T2, and so on) and their
corresponding test information. For example, a tests page may
contain data as shown in Figure 10-40.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-75
Figure 10-40 Tests Page

Unsupported Arguments
The -diff command line argument of the urg command is not
compatible with test correlation mode. If -diff is entered along with
-show tests or -show maxtests, an error is reported and URG
exits.

Difference Reports for Functional Coverage

Coverage driven verification is an iterative process of running some

tests, analyzing coverage results, adding new tests, and repeating
the cycle until the required level of coverage is achieved. During this
iterative process, it sometimes helps to understand the differential
value that a new test adds to an existing coverage result. That is, it
is helpful to compare the coverage results of a new test run with an
existing base or a reference test run. This is referred to as Difference
Report (Diff report) in URG.

Given two tests test1 and test2, a diff report shows the difference in
the objects covered by the two tests. The difference is the set of
objects covered by one test minus the set of objects covered by the
other test.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-76
To create a diff report, use the -diff flag as follows:

urg –dir mydir1.vdb mydir2.vdb –tests myfile –diff

The filename specified with the -tests flag (myfile in the example
above) must contain the names of the two tests. If more or fewer than
two tests are specified, or if the -tests flag is not given at all, URG
reports an error and exits.

The order in which the two tests are specified matters. The first test
specified is called the diff test. The second test is called the base
test. The diff operation is diff test – base test.

The default for -diff is to report a number of objects. However, a

count option can be specified with the -diff flag to change the
operation from object-based to count-based. The two forms are:

% urg –dir mydir.vdb –tests myfile –diff [object]

% urg –dir mydir.vdb –tests myfile –diff count

A sample myfile is shown as the following:

simv/test
simv/test_gen_1

If the -diff count flag is used, then the differences between the
hit counts are shown for functional and assertion metrics that have
counting data in tests. The hit count in the base test is subtracted
from the hit count in the diff test for each object. If the result is greater
than 0, the result is shown as the hit count in the diff report. If the
result is greater than or equal to the hit count goal (1 by default), then
the object is shown as covered.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-77
 Only the assert and covergroup metrics are supported with the
-diff flag. If data from other metrics is present, URG prints a
warning message, and the other metrics data are ignored. No
scores, objects, or other values from other metrics appear in a report
generated with -diff.

Additionally all types of exclusion are supported with the –diff

option including the –hier file and the loading of exclude files.

Viewing the Difference Between Tests in Dashboard and

Test Pages

Details about the diff being processed are shown at the top of the
dashboard and test pages. For example, assume that the –tests
file contains the following:

simv/test2
simv/test1

Then, the dashboard page displays the following:

Date: date-and-time
User: username
Version: VCS-version
Command line: urg -diff -dir simv.vdb -tests mytests

This report was generated with the -diff flag. The tests
used were:

base test: simv/test1

diff test: simv/test2

The only objects not shown as covered in this report are

those that are covered in simv/test2 that are not covered
in simv/test1.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-78
In a diff report, there is no list of tests in the tests.html/txt file, since
the only two tests are the base test and the diff test, and they are
already specified explicitly.

What is Shown as Covered?

Report for Default Mode (-diff or -diff object)

In a report generated with the –diff or –diff object flag, the
only things shown as covered are those objects that were covered in
the diff test but not covered in the base test. The overall scores, the
summary tables, and the detailed reports all show only what was
covered in the diff test but not covered in the base test.

The following table shows how a given object is shown in the diff
report for different combinations of coverage status in the base and
diff tests:

Diff Test Base Test In Diff Report

Covered Covered Not covered

Not Covered covered Not covered

covered Not Covered Covered

Not covered Not covered Not covered

Note that in the default mode, the hit counts do not matter. For
metrics that support hit counts in the report, the hit count of the diff
test is shown for any objects that are covered in the diff test but not
covered in the base test. For all other objects a hit count of 0 is
shown.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-79
 Report for Count Mode (-diff count)
In –diff count mode, hit counts are computed as follows for each
coverable object:

diff = diff test count – base test count

if (diff >= 0)
displayed count = diff
else displayed count = 0

if (diff >= hit count goal for this object)

displayed result = covered
else displayed result = not covered

The following table shows some examples for a given object:

Hit Count Goal Diff Test Base Test In Diff Report

1 7 10 Not covered. count 0

1 10 7 Covered, count 3

4 10 7 Not covered, count 3

1 10 10 Not covered, count 0

1 10 10 Not covered, count 0

1 0 10 Not covered, count 0

1 1 0 Covered, count 1

For metrics for which counting is not enabled, the same reporting
rules are used as for default mode (that is, –diff object), even
when –diff count was given.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-80
Unsupported Flags

The following flags are not compatible with the –diff flag. If any of
these flags are given with the –diff flag, an error is reported and
URG exits.

• -grade
• -annotate
• -trend
• -show maxtests N
• -show availabletests
• -dbname (You cannot save a merged diff db)
• -map

Exclusions

All types of exclusion are supported with the –diff flag, including
the –hier file and the loading of exclude files.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-81
Reporting Only Uncovered Objects (-show brief)

This section describes how URG allows you to create reports only for
uncovered objects (instead of creating reports for all coverable
objects).

URG supports a command-line option that causes only uncovered

objects to be shown in the report:

% urg –show brief

You can use this option in combination with text mode to generate a
brief text report:

% urg –show brief –format text

Brief Report for Line Coverage

For line coverage reports (which provides annotated source code
that shows coverable objects and which objects are not covered),
URG shows only the lines that contain uncovered statements
(“uncovered lines”), with two lines of context before and after each
uncovered line.

Showing some context is important because the coverage database

does not know the extent of a statement—a statement could cross
over several lines, in which case the statement would be truncated.
URG provides two lines of context above and below a statement:

if (some condition)
if (some other condition)
a <= (b ? c :
( d ? e :
( f ? g :

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-82
 ( h ? i :
( j ? k : l )))));

If the statement is uncovered, URG shows only this information:

if (some condition)
if (some other condition)
a <= (b ? c :
( d ? e :
( f ? g :

If several uncovered lines are grouped together, they are all grouped
together in the report. For example:

if (some condition)
begin
if (some other condition)
begin
a <= b;
if (yet another condition)
begin
x <= y;
end
end
end

The report for the above example would show the following text,
rather than reporting the information in two separate sections:

if (some other condition)

begin
a <= b;
if (yet another condition)
begin
x <= y;
end
end

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-83
 Brief Report for Condition Coverage
The condition that is fully covered is omitted in the brief report that
has no (uncovered) subconditions.

The brief report shows both the condition and its subcondition—if
one of the subcondition is uncovered even though the condition itself
is fully covered.

Brief Report for FSM Coverage

URG omits from the report any FSMs that are fully covered (all states
and transitions). However, these FSMs are shown in the FSM
summary table—with only the FSM name and its score.

If an FSM is fully covered except for its sequences, URG omits the
FSM even if the sequence score is less than 100.

If an FSM is not fully covered, URG lists all of the FSM’s states, and
only its uncovered transitions and sequences.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-84
URG Support for Uncovered Only (–show brief) Feature
on Selected Metrics

The -show brief option enables you to see only the uncovered
metrics. To see only the uncovered metrics, execute the following
command:

% urg –dir simv.vdb –show brief [-metric line+tgl+…]

In the above command, metric is an optional argument. It specifies
the metrics that should be reported in uncovered only mode, and
uses the same format as the urg –metric option (such as
line+cond+group). If you do not specify metrics, URG defaults to
the original uncovered only mode.

If you specify metrics, URG enables uncovered mode only on the

selected metrics. Other metrics, together with the module list and
hierarchy, remain in their default mode. For example, if you use the
-show brief assert+fsm option, the module list looks like the
default mode, as shown in Figure 10-41.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-85
Figure 10-41 Show Brief Assert Output

As a comparison, in the original -show brief mode, fully covered

and empty modules are not displayed (see Figure 10-42).

Figure 10-42 Fully Covered and Empty Modules Not Displayed

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-86
 Similar to the module list, if you turn on selected metrics for -show
brief, the hierarchy looks the same as the default mode (see
Figure 10-43).

Figure 10-43 Selected Metrics Turned On

The jb1 shown in Figure 10-43 is not displayed in the original

-show brief mode.

In the detailed report, the detailed module and instance coverage

report are reported only for metrics selected by -show brief
[metrics...].

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-87
 Report Changes

This section describes how each report section changes when you
use the -show brief option.

Dashboard
The dashboard report does not change. The total coverage
summary for the design is shown with the summary for each top-
level instance.

Module List
Only modules with an overall coverage score less than 100% are
shown. Modules with no coverable objects in them (for any reported
metric) are not listed.

For example, assume the module list report looks similar to the
following:

In brief mode, the module list report would only show the following
modules:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-88
Hierarchy
The hierarchy report omits any instances that do not have coverable
objects in their subtree or whose entire subtree has a score of 100%
(for all reported metrics). URG does not produce a comment or other
indication that such an instance has been omitted.

In other words, the only parts of the hierarchy that will be deleted
from the report are those entire subtrees that have coverage scores
of 100%, or that have no coverable objects in them at all.

Consider the following report:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-89
 In brief mode, the report shows only the following modules:

Groups
The groups report omits any groups that have a 100% score.

Tests
The tests report does not change.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-90
HVP
The HVP format omits any features whose subtrees are either 100%
covered or which have no coverable measures in them. Like the
hierarchy, only entire subtrees are omitted (if any).

Assertions Report
URG lists in any of the tables only assertions that are not covered or
that failed. Only covers and assertions that are not covered are
listed.

The total number of assertions is still reported the same way in

asserts.html.

Module and Instance Header Sections

In brief mode, URG generates module, instance, and group
reports only for those modules and instances that have coverage
scores less than 100%.

Module Header
URG lists the same header for modules, including all self-
instances—even those self-instances that have 100% coverage.
However, the self-instances with 100% coverage do not link to any
report because their reports are not generated. URG shows all self-
instances because you can see how URG computed the scores for
the module.

If a module is hidden from the module list page, but its instances are
reported, the module header still appears at the top of the module
page because the module header contains useful information for the
whole page.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-91
 Instance Header
URG shows the same instance header, including a list of all
subtrees.

Summary Only URG Reports

The generation of detailed URG reports for very large coverage

models can require a large memory footprint and be time consuming
to load and display in your browser. To reduce this overhead, you
can view a URG summary report. Since this feature does not
generate the detailed report, it improves the performance of URG.

Use Model

URG provides the following command-line option for generating the

summary of reports:

% urg –show summary <n>

where, n is optional value to specify how many levels of hierarchy of
reports should be generated.

Regardless of the value of n, or by default, URG generates the

following report pages:

• Dashboard
• Modlist (code or assertion coverage)
• Asserts (assertion coverage)
• Groups (group coverage)
• Tests

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-92
URG disables the following while generating the summary only
reports:

• modinfo.txt, modN.html, and so on for code or assertion

coverage.
• grpinfo.txt, grpN.html, and so on for group coverage.
• Links to the detailed report pages in HTML reports.
If the value of n is:

• Greater than zero and less than the maximum level of hierarchy,
then URG generates the hierarchy until the specified level.
• Greater than the maximum level of hierarchy, then URG generates
the entire hierarchy.
• Zero, then URG does not generate any hierarchy.
• Less than zero, then URG generates an error to mention that no
hierarchy is generated.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-93
Coverage Report Files

URG supports two basic formats to display coverage results: text

and HTML. The text report is a set of plain text files that is suitable
for searching and casual examination, while the HTML report is
intended for interactive browsing and analysis. The HTML reporting
display provides easy navigation, sorting and formatting features
and enables you to:

• Easily view the hierarchy in the design and browse to the instance
that is of interest, as the Design Hierarchy page shows the
complete tree structure of the design. For any instance, you can
expand or collapse its sub-instances. The Expand All and
Collapse All buttons on the left corner of the page enable you to
expand or collapse the hierarchy tree.
• Sort tables by clicking on column headings.
• Use new tabs and panes to switch between report sections.
• View coverage details while still viewing the definition or the
instance summary data, as the corresponding coverage scores
are displayed in the right pane.
• Provide readily viewable reports that include a concise summary
and that are easily navigable.
Recommended Browsers

It is recommended that you use one of the following browsers to view

the URG HTML reports:

• Internet Explorer 10 or later versions

• Firefox 16 or later versions

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-94
• Chrome 22 or later versions
Note:
To revert to the previous format of URG reports, use the -legacy
option on the urg command line.

Overview of URG Reports

URG generates a number of files that you can use to access the
report files in either HTML or text format. The HTML files contain a
common navigation menu and also follow a color-code that helps
visually assess the coverage metrics.

URG generates the following top-level report pages:

• dashboard
• hierarchy
• modlist
• groups
• tests
• assertions
• hvp.<plan_name>

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-95
 Common Report Elements
Most URG reports are displayed in a tabular format. The HTML
version includes color-coded cells. The cells are left empty when
coverage data for the coverage type represented by the cell is not
collected.

For example,

In this example, the first cell shows the name of a region, and the
second cell shows the overall score of all metrics. (By default, this is
the simple average of all the metric percentages. You can control the
way the score is computed using the -scorefile option.)

In this example, URG displays line, condition, toggle, branch, and

assertion coverage metrics. Condition coverage was turned on, so
its cell is displayed. However, no conditions were found in this
region, so the cell is empty.

By default, URG shows the coverage metric in terms of percentage

value. You can use the -show ratios option to show the total
number of covered objects and the total number of coverable objects
for each metric. When this option is included on the urg command
line, the Show/Hide Ratios button is enabled in the top-right corner
of the URG reports in HTML mode.

To enable quick page navigation, each definition/instance is shown

as a separate page in the new URG HTML reports. A key feature of
the new HTML format is the use of panes within the coverage
reports. For example, the Module Definition page and the Group
Definition page are split into four panes, as shown in Figure 10-44:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-96
Figure 10-44 URG Report Panes

The common navigation menu is shown in the top pane of each

HTML page. This menu is a simple list of the top-level pages that
allow you to go directly to any of the main page, including
dashboard, hierarchy, modlist, groups, asserts, and tests,
pages.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-97
 In the left pane, the module's summary data is displayed showing its
total coverage and the coverage for each of its self-instances. It also
displays the design source file location.

In the right pane, detailed coverage information is displayed. You can

click the metric in the Metric Navigator tab or scroll down to see the
detailed coverage data.

You can resize the left pane and right pane as needed using the
resize cursor. You can also show/hide the panes with a click, as
shown in Figure 10-44. The color-code legend is displayed in the
bottom pane. By default, the color-code legend (bottom pane) is
hidden.

The Dashboard File

The dashboard file (dashboard.html or dashboard.txt)
describes the top-level view of all the coverage data, including
coverage data scores for the database as a whole. Figure 10-45 is
an example of the new dashboard HTML report.

In the URG reports, the Dashboard page contains the Total Module
Definition Coverage Summary section and the Total Groups
Coverage Summary section. The Scores for Verification Plan
section is displayed at the top of the Dashboard page if a verification
plan is passed on the command line.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-98
Figure 10-45 Example of a Dashboard HTML Report

Figure 10-46 displays the corresponding dashboard text report.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-99
Figure 10-46 Example of a Dashboard Text Report

The Hierarchy File (Design Hierarchy)

The hierarchy file (hierarchy.html or hierarchy.txt)
contains a hierarchical display of the instances of modules,
interfaces, and components in the design.

The coverage data for each instance in the hierarchy.html file

shows the coverage information for that instance and for all
instances in its sub-tree merged together. Thus, at any level of the
hierarchy report you will see the complete coverage from that
instance down to the leaf instances.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-100
 For any instance, you can expand or collapse its sub-instances. The
Expand All and Collapse All buttons on the left corner of the page
enable you to expand or collapse the complete hierarchy tree. By
default, the first level of the instance hierarchy is expanded, as
shown in Figure 10-47.

For easy viewing of coverage data, each row of the coverage table
can be selected. The selected row is highlighted in blue.

Figure 10-47 Example of a Design Hierarchy HTML Report

The columns of the coverage tables are resizable.To resize the

columns, rest the cursor on the right side of the column boundary
you want to move until it changes into a resize cursor. Then drag the
boundary until the column is of the width you want.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-101
 Coverage tables are sortable by clicking any column heading:
NAME, SCORE, LINE, COND, TOGGLE, and ASSERT, in this
example.

The module and instances of the module are hyperlinked to their

corresponding module instance sections in the Module Definition
page as shown in Figure 10-48 and Figure 10-49.

Figure 10-48 Module Definition Page - Module

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-102
Figure 10-49 Module Definition Page - Instance

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-103
 Figure 10-50 displays the corresponding partial Design Hierarchy
text report.

Figure 10-50 Example of a Design Hierarchy Text Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-104
 The Modlist File (Design Module List)
The modlist file (modlist.html or modlist.txt) lists all the
modules, entities/architectures, and interfaces in the design. The
module (or entity, or interface) in the HTML file is hyperlinked to its
respective modN.html page. The coverage data shows the
accumulated coverage information for all instances of the module (or
entity/architecture, or interface).

Each metric in the coverage data cell is hyperlinked to its respective

coverage metric section in the Module Definition page
(modN.html). Figure 10-51 is an example of a Module List HTML
report.

Figure 10-51 Example of a Design Module List HTML Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-105
 If there is no assertion or code coverage information, URG does not
generate the hierarchy or the modlist files.

Figure 10-52 displays the corresponding modlist text report.

Example of a Design Module List Text Report

Figure 10-52 Example of a Design Module List Text Report

If the number of modules in a design is huge, the module list page

gets split into several pages (see Figure 10-53).

Figure 10-53 Module Definition Page Split Into Several Pages

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-106
 Module With Parameters
In the module list reports, when a module has more than one
instance with different parameters that affect the number or shape of
coverage targets in the instance, URG displays the parameter values
in the module list, as shown in Figure 10-54:

Figure 10-54 Example of a Module List with Parameters

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-107
 The modN File (Module Definition)
Each modN.html file contains the coverage information of a
module, entity/architecture, or interface.

In the module definition report, the left pane shows the coverage
information for the module, a link to its source file and the list of
module self-instances (with their coverage scores). The module self-
instances are hyperlinked to the respective module instance
coverage information. Click the module-self instance, to see the
coverage scores in the left-bottom pane.

The right pane shows the respective detailed coverage information.

Click the metric in the Metric Navigator tab to see its detailed
coverage data. This metric navigator is displayed by default.
However, the navigator can be shown or hidden as needed.

The left-bottom pane shows the coverage scores of the instance and
its sub-instances. By default, the sub-instance hierarchy tree is in the
collapsed state. This pane only lists the sub-instances that are
directly under the current instance and therefore only two levels of
the hierarchy are displayed. If the current instance does not have
any sub-instance, the second level of the hierarchy tree shows “no
children”, as shown in Figure 10-56:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-108
Figure 10-55 Example of a Module Definition HTML Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-109
 Modinfo Text Report

Figure 10-57 displays a partial section of the modinfo text report that
includes the coverage information about both module definition and
module instances.

Figure 10-56 Instance Hierarchy With No Children

Figure 10-57 Example of a Modinfo Text Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-110
 The Groups File (Testbench Group List)
The groups file (groups.html or groups.txt) shows the total
group’s coverage summary and lists the hierarchy tree of all the
Group Definitions and the related Group Instances. The link from
each group is hyperlinked to a grpN.html file.

Similar to the Design Hierarchy page, the hierarchy can be

highlighted and resized.

Figure 10-59 displays the corresponding groups text report.

Figure 10-58 Example of a Testbench Group List HTML Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-111
Figure 10-59 Example of a Testbench Group List Text Report

Figure 10-60 shows Groups file with multiple groups coverage

summary. If your design contains multiple groups that cannot be
displayed in a single page, URG splits the display of the groups
score into different groups page. Click the Groups page to view the
scores.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-112
Figure 10-60 Example of a Groups Page With Multiple Groups

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-113
 The grpN File (Group Definition)
The grpN.html page has a structure similar to that of the
modN.html page. Each coverage group report contains a statistics
table for both variables and crosses and shows the overall coverage
for each variable and cross.

In the Group Definition page, the left pane shows the coverage
summary information for the current group definition, variables and
crosses. It also lists the group source file location and all the group
instances that are related to the current group definition. Click the
instance to see the group instance information in the left-bottom of
the same pane.

The right pane shows the detailed coverage information for the
variables, crosses, and bins. Click the variable, cross, or bin in the
quick navigator tab to navigate from one variable/cross to another
variable/cross.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-114
Figure 10-61 Example of a Group Definition HTML Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-115
 Grpinfo Text Report

Figure 10-62 displays a partial group info text report. The design
source file location is displayed as well.

Figure 10-62 The Grpinfo Text Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-116
The Tests File (Test Records)
The test records page (tests.html or tests.txt) have one of
several different formats depending on the applied grading option (if
any) and whether the -show tests argument is provided on the
command line. The default format of a tests.html file is shown in
Figure 10-63.

The URG tests page shows the total coverage summary, the list of
tests, and the test run metrics of each test. For more information
about test run metrics, see Section “Correlation Report: Determining
Which Tests Covered Which Objects”.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-117
Figure 10-63 Example of a Test Records HTML Report

Figure 10-64 displays the corresponding Test Records text report

with the Total Hierarchical Coverage Summary section.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-118
Figure 10-64 Example of a Tests Record Text Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-119
 The Assertions File
The asserts report file (asserts.html or asserts.txt) shows all
the assertions by category and severity. The left pane of the
Assertions page is categorized into the following sections:

• Assertions by Category
• Assertions by Severity
• Summary for Assertions
• Summary for Cover Properties
Detailed information about assertions, such as uncovered
assertions, successful and failed assertions, and the detailed report
for cover properties are shown in the right pane. The top navigator
allows you to navigate to these Assertion sections. Hovering the
mouse over the assertion or cover property shows the source file as
a tooltip. Click the assertion or the cover property to open the
respective source file.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-120
Figure 10-65 Example of an Assertions HTML Report

Note: If there are many assertions, the assertion page gets split and
shows next page and previous page tabs to navigate pages
(see Figure 10-66).

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-121
Figure 10-66 Example of an Assertions Page Split Into Multiple Pages

Figure 10-67 displays the corresponding Assertions text report of

Figure 10-65.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-122
Figure 10-67 Example of an Assertions Text Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-123
 The HVP File
HVP (Hierarchical Verification Plan) is a comprehensive model that
allows you to hierarchically describe a verification plan. You can then
annotate the plan with live verification data using the URG tool. The
HVP hierarchy report shows the hierarchical structure of the HVP
design. The hvp page shows the cumulative coverage data for each
of the sub-plan and the sub-features along with other verification
planning attributes.

Figure 10-68 Example of an HVP Hierarchy HTML Report

Besides showing the coverage scores, the HVP hierarchy page also
shows all the attribute values along with the plans and features. By
default, all the attributes are displayed in the hierarchy page, and the
attribute names are displayed as column names. If you do not want
to see all the attributes in the HVP hierarchy page, you can list the
attributes of interest in a configure file. When generating the URG
report, you can append -attribute <attribute configure

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-124
 file>, (an additional URG option) with the -plan <hvp plan
file> option. All the attributes listed in the configure file are shown
in the HVP hierarchy page.

For example,

% urg -dir <path of the VDB file> -plan <path of the HVP
file> -attribute <path of the attribute configure file>

Note:
The -attribute option must be used with the -plan option.

Figure 10-69 displays the corresponding partial HVP Hierarchy text

report. The verification planning attributes are displayed in the text
reports in this release.

Figure 10-69 Example of an HVP Hierarchy Text Report

The HVP Plan

The top pane contains the Plan Navigator tab along with the
common navigation menu. The Plan Navigator lists the full hierarchy
path of the current plan. The HVP Plan page shows the coverage
summary scores for the plan, sub-features/sub-plans, and the

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-125
 attribute/annotation information. If you enable the -show stats
option, the statistics information is shown in this pane as well. You
can click the sub-feature/sub-plan to navigate to its respective
feature/plan page.

Figure 10-70 Example of an HVP Plan HTML Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-126
The HVP Feature
The top pane contains the Plan Navigator tab along with the common
navigation menu. Plan Navigator lists the full hierarchical path of the
current feature.

Below the Plan Navigator tab, you can find the Feature Detail
Navigator tab. This Feature Detail Navigator enables you to quickly
navigate to Sub-features, Measure Totals, Measures and Attributes/
Annotation values sections. The detailed pane shows the detailed
coverage information, such as measures and attribute/annotation
values of the feature.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-127
Figure 10-71 Example of an HVP Feature Report

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-128
Note:
In the HVP plan/feature text reports, if every attribute has a default
value, the Attribute/Annotation values section is not displayed.

Backward Compatibility

To generate the HTML reports in the legacy page format, you can
use the -legacy option. For example,

% urg -dir <coverage_directory.vdb> <urg_options> -legacy

The -split N and -split metric options are not supported as

URG options. However, these options can be used with the
-legacy option.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-129
Performance Improvement for HTML URG Reports

The interactive features of URG reports, such as tree table, dynamic

pane, and expand/collapse, rely on client-side JavaScript. On some
very large designs or plans, the interactive performance of the
browser can be slow. Therefore, the -legacy and -attribute
options are provided to generate a simpler static rendering of the
coverage reports that loads faster. The new options described in this
section have no effect on text-format reports.

Use Model

To enhance the page loading performance of the URG report, the

following new sub-options are added to the existing -legacy and
-attribute options:

• -legacy
- “-legacy batch_hier”
- “-legacy batch_list”
- “-legacy batch_test”

Note:To enable multiple sub-options together, separate each

sub-option with a '+':
-legacy batch_hier+batch_list+batch_test
• “-attribute”
- -attribute <file>

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-130
-legacy batch_hier
The -legacy batch_hier option generates a page with flat tables
with indentation and no interactive features to improve the page
loading performance. This option does not support the sorting
feature, however, it still supports the existing page splitting feature
such that very large hierarchies are split into multiple separate HTML
files. To view the details on how the option impacts each page, see
the following subsections:

• “Design Hierarchy Page”

• “HVP and HVP Problem Hierarchy Pages”
• “LP Hierarchy Page”
Note:
The -legacy batch_hier option does not affect
non-hierarchical report pages such as the Design Module List,
Testbench Group List, and Tests pages.

The syntax for using the -legacy batch_hier option with the urg
command is as follows:

% urg -dir simv.vdb -legacy batch_hier <urg_options>

Where,

• simv.vdb is the coverage database.

• urg_options are other URG command-line options. For more

information about URG options, see Chapter, “URG Options” in
the Coverage Technology Reference Manual.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-131
 Design Hierarchy Page
The Design Hierarchy page displays tree-structured tables and
supports page splitting by default to improve browsing performance.
With the -legacy batch_hier option, the page displays flat tables
with indentation and provides the page splitting feature. Sorting is
disabled when the report is generated with -legacy batch_hier.
The figure below shows the Design Hierarchy page using the
-legacy batch_hier option:

Figure 10-72 The Design Hierarchy Page Using the -legacy batch_hier
Option

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-132
 HVP and HVP Problem Hierarchy Pages
Hierarchical Verification Plan (HVP) and HVP Problem hierarchy
pages now support page splitting by default to improve browsing
performance. With the -legacy batch_hier option, the page
displays flat tables with indentation and disables all interactive
features, such as expand/collapse all, tree-structured table, dynamic
pane, and sorting. The figure below shows the HVP Hierarchy page
using the -legacy batch_hier option:

Figure 10-73 The HVP Hierarchy Page Using the -legacy batch_hier Option

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-133
 LP Hierarchy Page
The Low Power (LP) hierarchy page now supports page splitting by
default. With the -legacy batch_hier option, the page displays flat
tables with indentation and the page does not support the instance
grouping feature. The option also disables all interactive features,
such as expand/collapse all, tree table, dynamic pane, and sorting.

The figure below shows the LP Hierarchy page using the

-legacy batch_hier option:

Figure 10-74 The LP Hierarchy Page Using the -legacy batch_hier Option

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-134
-legacy batch_list
The -legacy batch_list option generates a page without the page
splitting feature, and retains support for sorting. To view the details
on how the option impacts each page, see the following subsection:

• “Design Module List Page”

• “Testbench Group List Page”
Note:
The -legacy batch_list option does not affect other pages such
as Design Hierarchy page, HVP/HVP Problem Hierarchy page,
and LP Hierarchy page.

URG does not support searching or sorting records among multiple

pages. However, if you want to search or sort all the records, you
may use the -legacy batch_list option to disable the page splitting
feature first, and then perform the sorting by clicking the column
header.

Design Module List Page

The Module List page disables the page splitting feature using the
-legacy batch_list option to show all records in the same page.
Also, it provides searching and sorting features page wise.

Note:
The -legacy batch_list option does not support appending
parameters in a module in the Design Module List page.
Therefore, the value of parameters does not appear next to the
module in the Design Module List page.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-135
 The figure below shows the Design Module List page using the
-legacy batch_list option:

Figure 10-75 The Design Module List Page Using the - legacy batch_list
Option

Testbench Group List Page

The Testbench Group List page disables the page splitting feature
using the -legacy batch_list option to show all records in the same
page. Searching and sorting features are supported.

Note:
The -legacy batch_list option does not support appending
parameters in a module in the Testbench Group List page.
Therefore, the value of parameters does not appear next to the
module in the Testbench Group List page.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-136
 The figure below shows the Testbench Group List page using the
-legacy batch_list option:

Figure 10-76 The Testbench Group List Page Using the - legacy batch_list
Option

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-137
 -legacy batch_test
The -legacy batch_test option generates a page without the page
splitting feature. To view the details on how the option impacts each
page, see the following subsection:

• “Tests Page”
Note:
The -legacy batch_test option does not affect other pages such
as Design Hierarchy page, HVP/HVP Problem hierarchy page,
LP Hierarchy page, Design Module List page, and Testbench
Group List page.

Tests Page
The Tests page supports the page splitting feature by default and it
also provides a page navigator to navigate among pages. With the
-legacy batch_test option, URG disables the page splitting feature
in the page to show all records in the same page. However, it
provides the search capability on the page.

The figure below shows the Tests page using the

-legacy batch_test option:

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-138
Figure 10-77 The Tests Page Using the -legacy batch_test Option

-attribute
URG does not show any attribute in the HVP Hierarchy page by
default. For example, the following command displays the HVP
Hierarchy page without any attribute (see Figure 10-78):

urg -dir simv.vdb/ -plan bigplan.hvp

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-139
Figure 10-78 The HVP Hierarchy Page Without Attributes

To view all attributes in the HVP Hierarchy page, use the -attribute
option with the -plan <hvp file> option. For example, the following
command displays the HVP Hierarchy page with all attributes (see
Figure 10-79):

urg -dir simv.vdb/ -plan <hvp file> -attribute

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-140
Figure 10-79 The HVP Hierarchy Page With All Attributes

To view specific attributes in the HVP Hierarchy page, use the

-attribute <file> option. For example, the following command
displays the HVP hierarchy page with specific attributes (see
Figure 10-80):

urg -dir simv.vdb/ -plan <hvp file> -attribute <file>

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-141
Figure 10-80 The HVP Hierarchy Page With Specific Attributes

The -attribute option and the -attribute <file> option do not

affect other pages such as Design Hierarchy page, HVP Problem
Hierarchy page, LP Hierarchy page, Design Module List page,
Testbench Group List page, and Tests page.

Viewing and Analyzing Coverage Reports Using Unified Report Generator

10-142
11
Analyzing Coverage Trend Charts 1
Knowing the current verification metric scores and status - coverage,
passing vs failing tests, number of open bugs - is a key part of closing
verification. Just as important as these values are on any given day
are their rates of change. Is coverage high but no longer increasing?
Are there more bugs open this week than last?

You can analyze these verification trends using URG reports. URG
uses raw data from the coverage database and verification planner
metrics data to plot trend charts. These trend charts allow you to
graphically analyze the data from a number of previous URG reports.

Each URG report contains coverage data and metrics data that
constitutes a snapshot of the verification metrics for a single session,
at the point in time when that report was generated. You can use
URG to generate a set of trend charts to track the progress of your
projects using the -trend option with the URG command, as
follows:.

Analyzing Coverage Trend Charts

11-1
 %urg -trend [trend_options]

This command generates the trend charts and displays it under the
trend tab in the URG report, as shown in Figure 11-1.

Figure 11-1 URG Dashboard With the trend Page

The following sections discuss how you can generate, customize,

and navigate through the URG trend charts:

• “Generating Trend Charts”

• “Customizing Trend Charts”
• “Analyzing Trend Charts”
• “Analyzing Trend Charts”

Analyzing Coverage Trend Charts

11-2
Generating Trend Charts

Trend charts are most useful if you periodically sample the same set
of data over a period of time. It is recommended that you execute a
URG run on a standard set of coverage and test result data after
each complete regression. For example, you could run a nightly or
weekly cron job that first runs your regressions and then runs URG
with the -trend option.

URG generates trend charts by scanning previously saved URG

reports to extract metrics data for trend plotting. Use the root
keyword to specify the root directory where all the snapshots of URG
reports are stored. For example:

%urg -trend root urg_report_root_path

URG will look in the specified directory for a series of report

directories. They can have any names, as long as they contain the
report results. It does not matter if the reports were generated in
HTML or text mode. Once URG locates the reports, it will extract all
the metrics to create a set of trend charts.

The following are the various options that you can provide to the
-trend argument:

-report someUniqueName
Ensures that each snapshot of the URG report has a unique name.
If you do not assign unique names, the URG results will be
overwritten and you will not be able to generate a meaningful trend
report. One way to generate a unique name is to base the name
on the current date/time.

Analyzing Coverage Trend Charts

11-3
 -trend root path
As already discussed, the -trend root option the historical
URG reports that need to be used for trend charting. With the
root option, URG recursively explores the path that you provide
to locate all the URG reports. If used with the -report option
provided with unique report names, you need not change the URG
command line arguments when new reports are added.

-trend root path rootdepth N

Scans the given root path and sub-directory recursively to find the
URG reports. If you do not specify rootdepth, the default depth
considered for N is 1.

-trend rootfile txtfile

Specifies the enumeration (in a text file) of multiple root paths for
scanning.

-trend src report1 [report2 ... ]

Specifies the enumeration (with the src keyword) of all the URG
reports. You can use this option instead of, or as well as, the
-trend root option. It is often useful when you need to locate
directories stored in different locations.

-trend srcfile txtfile

Specifies the enumeration (in a text file) of all the URG report
paths.

Analyzing Coverage Trend Charts

11-4
Customizing Trend Charts

URG provides various options using which you can customize trend
charts to suit your requirements. For example, you can select the
maximum level of data details or chart details (depth) that URG
should consider while creating the trend charts.

It is recommended that you choose the same level of depth to

create all URG reports during the project duration. The -trend
option provides the following arguments that you can use to
customize trend charts:

-trend depth number

Sets the depth of the DUT instance/HVP feature hierarchy for

which URG should generate trend charts. The default depth is 1,
that is, only the top-level chart is generated. You can specify a
higher value for number to generate trend charts with higher
granularity. Note that if you specify a higher value for number, it
results in larger URG report sizes and longer run-times. The report
sizes and run-times grow exponentially with respect to the depth
specified. The following is a sample command that specifies the
depth of the trend chart:

%urg -dir wishbone.vdb -plan wishbone.hvp -trend root

path depth 3

It is important that you use the same depth while creating all
your URG reports so that you can create trend series.

In the following example, the trend chart is generated for two levels
of hierarchy:

% urg -trend root REPORTS -report \

Analyzing Coverage Trend Charts

11-5
 REPORTS/urgReport.default -dir simv.vdb -trend depth 3

% urg -trend root REPORTS -report \

REPORTS/urgReport.zero -dir simv.vdb -trend depth 3

% urg -trend root REPORTS -report \

REPORTS/urgReport.one -dir simv.vdb -trend depth 3

When you do not specify the depth value, as shown in the following
commands, URG displays the trend data for the entire design. As
the depth is not specified, the default value of 1 is considered.
Therefore, the coverage report for only the top-level module is
generated. In other words, the following commands will not allow
drill-down:

% urg -trend root REPORTS -report \

REPORTS/urgReport.default-dir simv.vdb

% urg -trend root REPORTS -report \

REPORTS/urgReport.zero -dir simv.vdb

% urg -trend root REPORTS -report \

REPORTS/urgReport.one -dir simv.vdb

Irrespective of the depth value specified in the URG command,

all URG commands use the value of depth specified in the
preceding command. For example, consider the following three
commands.

As there is no depth specified in the first command, the default

value of 1 is considered. The second and third commands
consider the depth as 1 in accordance with the first command.
% urg -trend root REPORTS -report \
REPORTS/urgReport.default -dir simv.vdb

% urg -trend root REPORTS -report \

REPORTS/urgReport.zero -dir simv.vdb -trend depth 2

Analyzing Coverage Trend Charts

11-6
 % urg -trend root REPORTS -report \
REPORTS/urgReport.one -dir simv.vdb -trend depth 3

-trend linestyle
Displays the lines in the trend chart in different styles (solid line,
dashed line, and so on).This feature is useful when you need to
print these charts with a black-and-white printer. Figure 11-2
shows a trend chart without different line styles. Figure 11-3
shows a trend chart generated using the linestyle option. The
line styles are automatically selected by an internal line style
palette.

%urg -dir wishbone.vdb -plan myplan.hvp -trend root path

linestyle

Figure 11-2 Trend Chart Without the linestyle Option

Analyzing Coverage Trend Charts

11-7
Figure 11-3 Trend Chart with the linestyle Option

-trend offbasicavg
Displays only the Plan Average lines without displaying the Basic
Average lines on the chart.

The Basic Average consists of the raw built-in coverage metrics

(Line, Cond, FSM, Toggle, and Branch) and the two functional
coverage metrics (Assert and Group). The Plan Average consists
of the seven built-in coverage metrics score captured by a
verification plan.

This option helps avoid cluttering in trend charts. The following is

a sample command using the -offbasicavg option:

Analyzing Coverage Trend Charts

11-8
 %urg -dir wishbone.vdb -plan myplan.hvp -trend root path
offbasicavg

Figure 11-4 Top-level Trend Chart Using the offbasicavg Option

Analyzing Coverage Trend Charts

11-9
 Modifying the Timestamp of Trend Charts

You can modify the timestamp of the current URG report using the
URG_FAKE_TIME environment variable. Set this variable before
using the urg command. Ensure that you specify the timestamp in
mm-dd-yyyy hh:mm:ss format. For example, you can set the
timestamp variable as follows:

setenv URG_FAKE_TIME "11-16-2007 10:20:30"

Suppressing the Generation of session.xml

In some scenarios, you might want to suppress the generation of

session.xml so as to prevent the current URG report from
affecting future trend analysis. To do this, set the
URG_NO_SESSION_XML environment variable as follows:

% setenv URG_NO_SESSION_XML

Analyzing Coverage Trend Charts

11-10
Analyzing Trend Charts

When you generate a trend chart using the -trend option, URG
generates a trend chart that you can access using the trend tab in
the URG report.

The following sections discuss how trend charts are organized and
how you can use them to analyze coverage scores:

• “Organization of Trend Charts”

• “Metric-Wide Breakdown Linkage”
• “Hierarchical Linkage”
• “Links to Previous Sessions”

Organization of Trend Charts

Trend charts consists of many charts organized in two types of

hierarchies: metric-wide and design-wide. The metric-wide hierarchy
shows metrics and their sub-metrics in a hierarchy. The design-wide
hierarchy is the DUT hierarchy for Basic Average, or the verification
plan feature hierarchy for all other verification plan metrics. Both the
hierarchies start with the top-level chart. All other charts are listed
under the top-level chart and can be accessed from the top-level
chart by clicking on line graphs or legend labels to drill down on the
metric-wide or design-wide hierarchy.

Figure 11-5 shows a diagram that illustrates the URG trend chart
organization:

Analyzing Coverage Trend Charts

11-11
Figure 11-5 Trend Chart Hierarchy
Default
Default pages
pages
Click legend
Top chart flavor
flavor wide
sub-metric
breakdown
breakdown
breakdown chart

Generated when
Generated when
DUT hierarchy Click legend flavor -dir
-dirisisgiven
given
Click flavor wide
sub-metric
2nd level chart breakdown
BasicAverage breakdownchart
breakdown
Curve

DUT
DUT Click legend
Click curve DUT hierarchy flavor
flavor wide
instance
instance
3rd level chart sub-metric
breakdown
breakdown
breakdown chart

Generated when
HVP
HVP hierarchy
hierarchy Click legend
Generated
-plan is is
given
when
HVP
Click PlanAverage 2nd hierarchy flavor -hvp given
2nd levelchart
level chart
2nd level chart
flavor
flavor
breakdown
Or userdef metric breakdown
Curve breakdown

DUT
Click curve HVPDUT
hierarchy’ Click legend flavor
flavor wide
instance
instance
3rd level chart sub-metric
breakdown
breakdown
breakdown chart

Top-Level Chart
URG always displays a top-level chart when you select the trend
tab as shown in Figure 11-2.

As illustrated in Figure 11-6, the top-level trend chart contains four

metric legends:

- Basic Average legend for raw coverage - The Basic Average

score is displayed by default.

Analyzing Coverage Trend Charts

11-12
 - Plan Average legend for verification plan coverage score - To
see the top-level verification Plan Average score, use the
-plan option. When you use the -plan option, the chart also
displays the Failures and other user-defined metrics, such as
bug count.
- Failures legend for test failure count - The Failures metric is
same as the verification plan built-in metric test.fail.The
Failures legend is linked to other enumerated scores in the test
metric, such as total test count, test.pass, test.warn, and
so on.
- Bugs legend for user-defined metric bug count - The Bugs
metric is a user-defined integer metric for bug count.
You need not include both the Basic Average and verification Plan
Average scores on the same chart every time.However, this
information is useful when you need to perform basic sanity checks
to ensure that your verification plan correlates accurately with the
raw coverage metrics. You can turn-off the display of the Basic
Average coverage information in the chart by specifying the -trend
offbasicavg option.

Analyzing Coverage Trend Charts

11-13
Figure 11-6 Top-Level Chart with Linkage Description

The y-axis on the left-hand side represents the percentage of

coverage, and the y-axis on the right-hand side represents integer
count of Bugs and Failures. The legend labels above each y-axis
indicate the metric that the axis represents.The metrics that have the
same type of values (for instance, test.fail and the bugs metric
integer values) share the same axis. If the score values of metrics
vary over a wide range, the line graph might not reflect the trend well,
because the metric with a lower range will be compressed due to the
need for a higher range of y-axis.

Analyzing Coverage Trend Charts

11-14
Navigating Through Trend Charts
URG provides the capability to navigate from one trend chart to
another trend chart or to a URG report. A web browser is required to
view trend charts. URG uses hyperlinks to link one graphical user
interface, such as an element in trend charts to some section of
information in URG reports.

URG trend charts provide the following three types of hyperlinks:

1. Legend label hyperlinks above the y-axes link to metric-wise

detailed charts.
2. Line hyperlinks on a trend chart link to instance-wise or feature-
wise hierarchical sub-level charts.
3. Session date hyperlinks of the x-axis link to older URG reports
used to generate the data points on a trend charts.
The following sections describe in more details the behavior of these
various links.

In addition to hyperlinks, URG trend charts show graphical user

interface elements, such as tooltips where appropriate. Hover the
cursor over an element on a trend chart, without clicking it, and a
small box appears with supplementary information regarding the
element. The tooltips allow supplementary information to be
annotated to the chart without cluttering it since only one tooltip can
be displayed at a time. URG provides the following tooltips usage:

• The tooltips for line graphs display the metric name and score of
the point for each curve. In addition, if the curve is click-able, the
tooltip shows the next chart that you can see by clicking the label.
For example:
78.1% - Basic raw coverage score curve

Analyzing Coverage Trend Charts

11-15
 90.5% - Click to see feature-wise subhierarchy breakdown
for Plan Average Score

• The tooltips for the legends above y-axis show the next chart that
you can see by clicking the label. For example:
Click to see metric-wise basic coverage breakdown chart

• The tooltips for the x-axis date labels show the exact date and
time in mm/dd/yyyy hh:mm:ss format and the name of the URG
report for each session.
Note that each x-axis date label displays the date of each session in
mm/dd/yyyy format without a time. If the number of sessions
increases, URG shows only the “-” character instead of the date for
each session.

Metric-Wide Breakdown Linkage

To view the complete breakdown chart of a metric, click on a metric
legend label above either of the y-axes. In Figure 11-6, the legend
labels at the top of the y-axis are metric-wide breakdown chart links
(Group, Assert, Cond, and Line). The Basic Average and Plan
Average breakdown charts show the components that comprise the
average score.

Analyzing Coverage Trend Charts

11-16
Figure 11-7 Plan Average Score Breakdown Page

Dip on line
curve

Click the green arrow beside Plan Average, to see the Plan Average
score breakdown page as shown in Figure 11-7. The Plan Average
chart displays the coverage metrics lines of the Plan Average score.

You can study the metric detail line to analyze the trends of coverage
scores for a metric over a period of time. You can also analyze the
factors that affect the coverage scores of these metrics, For
instance, in Figure 11-7, there is a dip on the Line coverage score in
the 11/12/2007 session. This dip could be caused due the
introduction of new code. If you inspect the Line detail chart, you see
that total number of coverable objects increased on 11/12/2007. This
increase in coverable objects caused the drop in the Line coverage

Analyzing Coverage Trend Charts

11-17
 score. The metric detail line chart allows you to compare the set goal
against the real score. According to the chart, the Line score started
meeting the goal on 11/16/2007.

Figure 11-8 and Figure 11-9 show the details (total coverable points
line and goal line (if they exist)) for Line and Group metrics
respectively.

Figure 11-8 Line Metric Detail for Plan Average Breakdown

In Figure 11-8, the three lines represent the Line Coverage score,
the Goal of the line metric, and total number of Coverable Points,
respectively.

Analyzing Coverage Trend Charts

11-18
Figure 11-9 Group Metric Detail for Plan Average Breakdown

In Figure 11-9, there is no line for the total number of coverable

objects because the Group coverage metric is not a ratio type, but
rather is a percentage type. If you have not specified a goal for the
metric, URG does not create the Goal line.

If there are other enumeration types of user-defined metrics in the

verification plan, their legend label hyper-links operate the same way
as described in this section.

Figure 11-10 shows the Failure Breakdown Chart. This chart

displays the values for test.warn, test.fail, test.pass and
test in different colored lines corresponding to the legend.

Analyzing Coverage Trend Charts

11-19
Figure 11-10 Failure Breakdown Chart

The line charts for instances, such as test.unknown and

test.assert might not be visible on a trend chart. This is because
they have zero values throughout the time span of the trend analysis
and are therefore are not of importance.

If a verification plan has several user-defined metrics, all of the

metric lines are plotted on the top-level chart. Each hyperlink of the
user-define metric line links to feature-wide sub-level chart. Also, if
any of the user-defined metrics is an enumeration type, the hyperlink
on legend label links to the enumeration breakdown chart the same
way as the hyperlink does for test.fail label.

Analyzing Coverage Trend Charts

11-20
Each breakdown chart such as the Basic Average, the Plan Average,
or the Failures, is a leaf node chart. Therefore, there is no more
linkage either on legend labels or curves to additional charts except
for the session time-stamp labels on the x-axis.

Hierarchical Linkage
Click the individual lines on a top-level chart, to view sub-hierarchy
charts. Consider the Figure 11-6, the green arrows 5, 6, 7, and 8 are
sub-hierarchy chart hyperlinks. Each line displays the trend of a
metric and is color-coded to match the metric legend it represents.
Figure 11-6 displays the following values:

- Basic Average - line chart of raw coverage DUT instance

hierarchy. It is click-able if you specify the -dir covdb option
to generate the URG reports and the depth value is at least 2
or higher.
- Plan Average - line chart of verification plan feature sub-
hierarchy. It is click-able if the depth value is at least 2 or higher.
- Other metric line graphs of verification plan feature sub-
hierarchies. It is click-able if the depth value is at least 2 or
higher.
For example,

Analyzing Coverage Trend Charts

11-21
Figure 11-11 Plan Average Feature Hierarchy Chart

Click the Basic Average legend (the green arrow 1 in Figure 11-6),
which links to the chart of raw coverage score, as shown in
Figure 11-11. The top.wb_dma_test_top.dut instance contains
five sub-instances. You can drill-down to the next level by clicking
any individual curve to view the sub-instance chart. Further, the
legend labels are also click-able,which enables you to view the flavor
breakdown charts of this average coverage score.

The hierarchy levels of charts are determined by the value of depth

you specify with the -trend depth option. As you increase the
depth value, there is an exponential increase in the URG runtime
and the usage of the disk space. Therefore, it is recommended that
you use a depth value of four or less.

Analyzing Coverage Trend Charts

11-22
Figure 11-12 Verification Plan Hierarchy Chart for Plan Average Score

Click the Plan Average legend (the green arrow 2 in Figure 11-6),
which links to the chart of coverage score lines for each sub-feature
as shown in Figure 11-12. Each line is click-able if you specify the
-trend depth <number> argument with a value of 2 or higher
and the verification plan sub-hierarchies are available. The legend
labels mentioned above the y-axis are also click-able for flavor
breakdown charts.

Other verification plan metric line charts on the top chart are also
click-able if their sub-features exist and the -trend depth
<number> argument is has higher value.

Analyzing Coverage Trend Charts

11-23
 Links to Previous Sessions
The session date labels on the x-axis of a trend chart are click-able.
You can use these links to view the URG report dashboard pages for
the previous sessions. If the number of sessions are high to display
, the date labels for some sessions might be replaced with the “|”
character to avoid the text overlay. The tooltip of the “|” label shows
the timestamps, and is click-able.

If the current URG report is located under the same trend root
directory as other URG session reports, the URL to the other session
is a relative path, such as ../../urgReport_session_N/
dashboard.html. Therefore, this hyperlink works even if you
move the entire trend root directory to another path or access the
URG report from a Windows disk mount.

Alternatively, the URL hyperlink is based on the absolute UNIX path

and therefore cannot be resolved if moved.

Analyzing Coverage Trend Charts

11-24
Closing Coverage Verification1
Coverage data is collected over multiple tests and simulations.
Analyzing the accumulated coverage results uncovers parts of a
design that have not been exercised and validated. These
uncovered parts are called coverage holes. Some coverage holes
can be excluded, such as debug code, because part of the design
functionality will not be used in valid scenarios. Other legitimate
verification holes require different techniques, such as tuning
constraints and creating direct tests, to fill the holes.

When a verification plan and a coverage model with different

coverage metrics reach a 100% goal, the design under test is ready
to be signed-off.

This segment discusses the techniques used in closing coverage

gaps, in the following chapters:
• “Exclusion Management”
• “Constant Analysis”
12
Exclusion Management 1
Coverage data is collected over multiple tests and simulations.
Analyzing the accumulated coverage results uncovers parts of a
design that have not been exercised and validated. These
uncovered parts are called coverage holes. Some coverage holes
can be excluded, such as debug code, because part of the design
functionality will not be used in valid scenarios. Other legitimate
verification holes require different techniques, such as tuning
constraints and creating direct tests, to fill the holes.

When a verification plan and a coverage model with different

coverage metrics reach a 100% goal, the design under test is ready
to be signed-off.

Any complex design will probably have code or combinations that

can never happen. For example, certain combinations of values may
never occur together. When you are trying to verify the design, you
will want to exclude these impossible coverage targets, so you can

Exclusion Management
12-1
 focus testing the parts of the design that can happen. This section
explains some ways to remove impossible or unexercised parts of
the design from coverage monitoring.

There are two complementary types of exclusion. One is the

exclusion of general areas that are not of interest - don't care
exclusion. When you exclude a module, instance, covergroup,
coverpoint, or cross you are saying that you do not want the scores
from those regions be taken into account when computing your
coverage score. From the point of view of your verification plan, it
does not matter if they are covered or not.

The other type of exclusion is done when you are asserting that a
given coverable object - for example, a signal bit, a cross bin, a line
of code - cannot be covered, and therefore should not be counted
when computing your coverage score. When you exclude at the
object level, you are saying not to count that object because it cannot
be covered. In fact, it is not legal to exclude an object if it is covered,
and if it becomes covered an error will be flagged.

You can exclude items interactively using DVE, and your exclusions
can be saved to files that can be reloaded into a later DVE session,
into the Unified Report Generator (URG), or into the Unified
Coverage API (UCAPI), in the following sections:

• “Managing Exclusions in DVE”

• “Viewing Excluded Coverage Objects in URG”
• “Managing Exclusions in UCAPI”
• “Remapping Exclusions From the Block Level to the System
Level”

Exclusion Management
12-2
Managing Exclusions in DVE

You can use DVE to exclude coverage objects interactively or by

using an exclusion file, annotate the exclusions, save them reload
them in later sessions.

The following sections discuss how you can create and manage
exclusions in DVE

• “Using the DVE Exclusion Menu”

• “Saving Exclusions On a Module and Instance Basis”
• “Exclusion Modes in DVE”
• “Using Exclusion Files With DVE”
• “Exclusion State Markers in DVE”
• “Understanding Review Markers in DVE GUI”
• “Interactively Marking Items for Exclusion in the Detail Views”
• “Excluding Multiple Objects in a Single Line”
• “Excluding Hierarchies”
• “Excluding Covergroups”
• “Excluding Auto-Cross Bins”
• “Excluding Toggle Coverage MDA”
• “Excluding Cross-of-a-Cross”
• “Saving and Loading Saved Exclusions”
• “Recalculating Coverage Scores”

Exclusion Management
12-3
 • “Using Adaptive Exclusion in DVE”

Using the DVE Exclusion Menu

The Edit > Exclusion menu commands are as follows:

Figure 12-1 Exclude Menu Options

• Recalculate - Reruns the coverage calculations and displays the

results to include results of pending exclusion/inclusion items.
• Clear Marks - Reverts all pending exclusion/inclusion items to
their original state.
• Exclude - Marks the selected item for exclusion.
• Unexclude - Marks the selected excluded item for reinclusion.
• Edit Exclude Annotation: Modifies an annotation to the excluded
coverable objects, such as mentioning the reason behind the
exclusion to an exclusion file.
• Delete Exclude Annotation: Deletes the exclude annotation.
• Save Exclusion: Saves the exclusion.

Exclusion Management
12-4
 • Exclude Tree: Marks the hierarchy for exclusion or re-inclusion.
• Unexclude Tree: Unexcludes (re-includes) the tree.
• Add/Edit Annotation Tree: Adds an annotation tree.
• Delete Annotation Tree: Deletes the annotation tree.
• Save Exclusion Tree: Saves the exclusion tree.

Context Sensitive Menu

Right-click in the Summary window to display the context-sensitive
menu (CSM) and Exclude or Include items:

Figure 12-2 Context Sensitive Exclude Menu Options

Exclusion Management
12-5
 Exclusion Toolbar
The exclusion toolbar has the following six buttons:

Exclude

Unexclude

Recalculate

Clear Exclusion

Load Exclusion

Save Exclusion

Excluding Coverage Object Using the Edit Menu

You can mark the items by first selecting them and then excluding or
including them either through the CSM or the main menus. You can
select and mark multiple items simultaneously.

In DVE detailed pane, you can select multiple items in List pane
using the Ctrl key for all coverage metric. In case of the line metric,
the multiple select option is possible only in the Source pane. The
same procedure can be followed for all metrics.

The following is an example of how you can exclude an item:

1. Start DVE in coverage mode.

2. Load the coverage database.

Exclusion Management
12-6
3. Open the condition metric coverage detailed pane.
4. Click on any expression or sub-expression in the expression list
pane.
5. Press the Ctrl key and clickon the desired expressions or sub-
expressions to select them.
6. Right-click and selectthe Exclude option in the menu to exclude
all the selected items.
7. Re-calculate.
Note:
For an excluded item, only the Include menus options are enabled.
When all of the selected item is included, only the Exclude menus
are enabled. If there is a mix of included and excluded items, both
menus are enabled.

Saving Exclusions On a Module and Instance Basis

Exclusions can be saved on instance and module basis using the

following Save Exclusion options:

• Use the Save Exclusion option to save exclusions for selected

module/instance in the navigation pane.

Exclusion Management
12-7
Figure 12-3 Save Exclusion in Navigation Pane

• Use the Save Exclusion and Save Exclusion Tree sub-options

to save the exclusion tree as shown in Figure 12-4.

Exclusion Management
12-8
Figure 12-4 Save Exclusion Option in Exclusion Menu

• The Save propagated exclusions from module/cover group

variant check box is selected while saving exclusion on instances/
instance tree. If this check box is selected, it saves the excluded
objects propagated from the module along with the excluded
objects from instance while saving instance/instance tree. If this
check-box is not selected, it saves only the excluded objects from
instances.
• Use the Save Exclusions in the Exclude tree menu option is to
save exclusions for a hierarchy tree, as shown in Figure 12-5.

Exclusion Management
12-9
Figure 12-5 Save Exclusion Option in Exclude Tree Menu

Exclusion Management
12-10
Exclusion Modes in DVE

A coverage object can be excluded in any one of the following two

modes:

Default mode - In the Default mode, you can exclude anything,

whether it is covered or not. Anything specified in the exclude file (a
file containing excluded objezmodules, module instances, or any
other coverable object will be excluded completely.

Strict mode - In the Strict mode, you can exclude only uncovered
objects. To enable the Strict mode, you can use the DVE command
line option -excl_strict. For example:

% dve -dir simv.vdb -excl_strict

You can also choose the option Do not allow Covered Objects to
be excluded in the DVE Application Preferences window accessed
from the Edit > Preferences menu > Exclusion category. Using the
preferences menu option will require that you reload the database to
enable Strict mode.

In the Strict mode, containers, such as vector signals in toggle

coverage, conditions, control statement in branch coverage, and
FSMs, may be excluded, but only the uncovered objects within those
containers will actually be excluded. The covered objects will be
marked as Attempted, meaning that an attempt was made to exclude
them, but they were already covered.

After you have excluded objects in DVE, you can save those
exclusions to a file (also called elfile). For more information on
creating and managing exclusion files, see section “Using Exclusion
Files With DVE” .

Exclusion Management
12-11
 The mode you are in (Default or Strict) when you create an exclusion
file is saved with the rest of that file's contents. If you load an
exclusion file in a different mode than the mode in which it was
created, a warning message will be printed, but the mode in which
you are currently in will be in effect.

For example, if DVE is in Strict mode and you load an exclude file
created in Default mode, you will see a warning, and only the
uncovered objects specified in the exclude file will actually be
excluded, since DVE is in Strict mode. In addition, a file
attempts.log will be created listing all the covered objects that
were in the exclude file but which could not be excluded.

Using Exclusion Files With DVE

You can create exclusions in DVE and save them in an exclusion file.
DVE saves exclusion files with a.el extension. The following
sections discuss the format used in the exclusion files to exclude
various coverage metrics.

Checking the Version of an Exclusion File

You can checks various the various changes made to a design by
comparing it against the earlier version, with the help of the version/
checksum in the exclusion file. Use the following steps to check for
design changes:

1. Compile the design.

2. Simulate the design.
3. Load the coverage database to DVE.
4. Mark exclusions, and save them to an exclusion file.

Exclusion Management
12-12
5. Edit the design source.
6. Recompile the edited design.
Note:
This step is important to generate the new checksum.

7. Simulate the edited design.

8. Reload exclusions.
An exclusion file is not discarded when one or more checksums
mismatch (exclusion on objects where a checksum match is seen
are applied normally, while those having their checksums
mismatched are treated adaptively). Checksums are computed for
modules as well. The checksum of a module considers the source
code of the module and ignores all white space, including new lines
and comments. Therefore, any addition or deletion of text to the
module (barring white space and comments) impacts the module
checksum. Essentially, version checks for excluded modules or
instances follows a two-level approach.

For code or assertion coverage metrics, the module checksum is

matched. This is followed by comparing the variant checksum (if
applicable). A mismatch in any of the two checksum checks results
in version failure for that excluded scope. Similarly, for covergroups,
matching is done for covergroup definition and covergroup variant
checksums in that order (covergroup definition and variant
checksums are analogous to module and metric-variant checksums,
respectively).

To enable module or metric-variant level granularity in version

checks, checksums are dumped along with exclusions. Specifically,
the keyword CHECKSUM: is introduced, replacing the existing
// MOD_CHKSUM: and // CHECKSUM: keywords, where in each

Exclusion Management
12-13
 MODULE:/INSTANCE:/covergroup specification is accompanied
with a checksum line that is prefixed with the CHECKSUM: keyword.
The format is as follows,

CHECKSUM: <mod_or_cgdef_checksum> <variant_checksum>

where, <mod_or_cgdef_checksum> can be either the module

checksum that is described in the previous paragraph for MODULE:
and INSTANCE: exclusions or the covergroup definition checksum
for covergroup exclusions.

For scope exclusions (complete exclusion of a module, instance, or

a covergroup definition), only the module or covergroup definition
checksum is dumped and matched. This means, even if any of the
metric variant checksums of that module or covergroup change (or
new variants are added), exclusion is applied on the scope if the
module or covergroup checksum matches.

Example 12-1 and Example 12-2 show the format and contents of
the generated exclusion file.

Example 12-1 Metric (or Partial Scope) Exclusions

CHECKSUM: “<mod_chksum> <metric_variant_checksum>”
MODULE: <module_name>
<metric_objects>

CHECKSUM: “<mod_chksum> <metric_variant_checksum>

INSTANCE: <instance_name>
<metric_objects>

CHECKSUM: “<cg_def_chksum> <cg_variant_checksum>

covergroup <cg_variant_or_instance_name>
<covergroup_objects>

CHECKSUM: “<cg_def_chksum> <cg_variant_checksum>

covergroup <cg_variant_or_instance_name>
// covergroup variant or instance exclusion

Exclusion Management
12-14
Example 12-2 Scope Exclusions
CHECKSUM: “<mod_chksum>” // Notice that there isn’t any
variant checksum here – only <mod_chksum> is matched
MODULE: <module_name>

CHECKSUM: “<mod_chksum>” // Notice that there isn’t any

variant checksum here – only <mod_chksum> is matched
MODULE: <instance_name>

CHECKSUM: “<cg_def_chksum>” // Notice that there isn’t any

covergroup variant checksum here – only <cg_def_chksum> is
matched
covergroup <cg_def_name>

The metric variant checksum is not available for assertion coverage.

For design qualified assertion variants and instances, only the
corresponding module checksums are dumped, and matched, while
loading an exclusion file. For test qualified assertion objects, there is
no checksum check (exclusion is applied unconditionally).

The absence of a checksum for a scope in the exclusion file is

interpreted as a mismatch. Unless the file is loaded in the backward-
compatible mode (see section “Backward Compatibility” ),
exclusions are not applied for that scope. To enablethe loading of
exclusions for such modules (which means to disable exclusion file
version checks) you can use the URG or DVE switch
-excl_bypass_checks.

Exclusion Management
12-15
 Backward Compatibility
Exclusion files generated with the previous release of VCS can be
used with the current release, thus ensuring backward compatibility.
Shape change detection may be less precise, but if the exclusion file
is reviewed first in the previous release, on the same DUT, it can be
imported into the new version of VCS and shape mismatches can be
suppressed.

Note:
Exclusion files that are manually edited to add new scopes and
exclusions without VCS-generated shape checksums cannot be
checked for source changes by VCS. These exclusions are
loaded without any version check.

Exclusion State Markers in DVE

You can view the exclusion markers in the Detail and Source
windows.

• Pending items marked to be excluded are indicated by a minus

sign in a green circle. Pending items marked to be included are
indicated as a plus sign in a green circle, as follows:

• Excluded items are indicated with an x in a red circle, as follows:

• Items that are partially marked or excluded are indicated with the
Partial Exclusion symbol, as follows:

Exclusion Management
12-16
 • Items for which exclusion was attempted are indicated as follows:

ToolTips on these symbols indicate the statement or metric that is

marked.

List view panes (Summary and Detail) have an additional column

showing the exclusion markers.

For additional clarity, excluded items have their coverage bars

grayed out and values removed. These bars are still displayed as
they still impart useful information, as shown in the following figure.

Figure 12-6 Excluded Items Grayed Out

Exclusion Management
12-17
 Understanding Review Markers in DVE GUI

After you invoke DVE and load an exclude file with the Bypass
checks option deselected, markers are used to facilitate the review
of the exclusion changes. DVE denotes exclusions with different
markers based on their status in the review process.

Table 12-1 lists the marker icons for mappable exclusions and
explains what they mean.

Table 12-1 Review Markers for Mappable Exclusions in DVE GUI

Icon of Markers Review Status
Children or sub-children contain an unreviewed exclusion and signa-
ture mismatching.

Container contains unreviewed exclusions and signature mismatch-

ing for child objects.

Children or sub-children contain an unreviewed exclusion and signa-

ture matching.

Container contains unreviewed exclusions and signature matching for

child objects.

Unreviewed and signature matching.

Unreviewed exclusion and signature mismatching.

Exclusion Management
12-18
 Icon of Markers Review Status
Unmappable objects or scope.

Review accepted.

Container contains accepted exclusion for child objects.

Reviewed and rejected.

Accepted and recalculated.

Table 12-2 lists the marker icons for unmappable exclusions and
explains what they mean.

Table 12-2 Review Markers for Unmappable Exclusions in DVE GUI

Icon of Markers Review Status
The unmappable exclusion is in unreviewed status.

The unmappable exclusion is reviewed.

Unmappable scope or module.

The unmappable exclusion is reviewed and recalculated.

Exclusion Management
12-19
 Adding Exclusion Annotations in DVE

You can add an annotation to the excluded coverable objects, such

as mentioning the reason behind the exclusion inthe exclusion file.
Upon loading this file, the annotation are displayed in the URG
reports and the DVE coverage GUI. Consider the following exclusion
file as an example:

MODULE : top
ANNOTATION: "Unreachable signal"
Toggle a
In this example, the annotation Unreachable signal is added to
signal a of module top, which you want to exclude. You can add,
edit, and delete exclusion annotation of an excluded object or scope
in DVE.

Note:
You cannot add an annotation to a scope, container, or object that
is not excluded fully or partially, even if you have added it in the
exclusion file or edit it in the GUI before recalculation. Annotation
will only be set for a fully excluded object, scope, or container after
recalculation.

To add and delete exclusion annotation, use the following

steps:

1. Start DVE in coverage mode.

2. Load the coverage database.
3. Select the object or scope in the Hierarchy pane, Detail view, or
Summary view.
4. Right-click on the object, select Exclude to mark for exclusion.

Exclusion Management
12-20
 5. Right-click on the excluded object, scope, or container and select
Edit Exclude Annotation.
Figure 12-7 Edit Exclude Annotation Menu Item

The Add Exclude Annotation dialog box appears that contains

the following fields.

Exclusion Management
12-21
Figure 12-8 Add Exclude Annotation Dialog Box

In the Add Exclude Annotation dialog box:

- Exclude annotation — Identifies a text area where you can
type your exclusion annotation.
- Available annotations — Lists all the annotations that you
have already created.
- Save as a favorite annotation — Saves the added annotation
as your favorite, if selected. Favorite annotations are saved in
user preferences, as shown in the following figure:

Exclusion Management
12-22
Figure 12-9 :Favorite Annotations as Preferences

If you save any annotation as your favorite, you can reuse these
annotation the next time you start DVE. Other recently used
annotations are not saved.

- Add — Adds the annotation to the Exclude annotation column

from the list of available annotations.
- Recently used annotations — Contains two options,
Recently used annotations and Favorite annotations. The
selected option will be effective next time when you open the
Add Exclusion Annotation dialog box.
6. Enter the exclusion comment under the Exclude annotation text
area. You can add an annotation of upto 16K characters.
7. Select the Save as a favorite annotation (as required) check
box and click OK.
The exclusion annotation is saved and is displayed in the ToolTip,
when you point your mouse over the object, container, or scope,
in the Summary view.

Exclusion Management
12-23
 The following icon indicates that the item is annotated.

8. If you want to delete the annotation, select the object in the

Hierarchy pane, right-click and select Delete Exclude
Annotation. The exclusion annotation will be deleted.
Note:
- You can select multiple objects and add the same annotation.
- The annotation on module is not propagated to its instances.
- You cannot add annotations to unexcluded objects.

Interactively Marking Items for Exclusion in the Detail

Views

Within the source windows, items can be marked for exclusion in the
following ways:

• Edit Menu- Select the item to be excluded and use the CSM, Edit
menu as shown in Figure 12-1.
• Margin - Click in the left hand column of the margin to toggle the
Exclude mark. Depending upon the contents of the line being
marked the system will mark all related items. All exclude-able
items are initially marked with an empty green circle. Lines that
do not show this icon cannot be excluded.
Lines containing multiple exclude-able items are marked with a
special icon when the items on the line are at different exclusion
states. This line is referred to as being partially excluded. Exclude-
able items are marked with the icon.

Exclusion Management
12-24
Figure 12-10 Detail View Showing Markers in Source and List Windows

Within the list views, you can toggle the exclusion markers by
clicking them. The markers toggle as follows:

• Excluded -> Include Pending

• Included -> Exclude Pending
• Include Pending -> Excluded
• Exclude Pending -> Included

Exclusion Management
12-25
 Filtering Coverage Objects Based on Exclusion Status
Use the exclusion browser in the toolbar to filter coverage items
based on their exclusion status.

Excluding Multiple Objects in a Single Line

You can exclude multiple objects in a single line of source code. This
feature is supported in all metrics.

To exclude/include an object in a line, use the following steps:

1. Select the line of code in the Source view.

Right-click the green exclusion marker beside a particular line
number and select the exclude/include option.The object is
excluded/included.

Exclusion Management
12-26
Figure 12-11 Source View

Excluding Hierarchies

Some views display object hierarchies as trees. When you mark a

tree branch for exclusion, all child objects within that branch will also
be marked for exclusion. This is true whether or not the child items
are visible in the navigation pane at the time the parent object was
marked.

Marking an object in one view will automatically mark the same

object in all other views.

Exclusion Management
12-27
 For hierarchical exclude-able items in toggle, condition, branch,
FSM, or assertion coverage, you can mark a branch of the hierarchy
simply by selecting the root of the branch. In such a case, all items
in the branch are marked, not just the root. This makes the exclusion
explicit.

Note:
Excluding an instance only excludes that specific instance itself,
not other instances within it. You can use the Exclude Tree/
Unexclude Tree options in the CSM to mark the hierarchy for
exclusion or re-inclusion.

Different object types have different exclusion rules associated with

them. For example, if a module is excluded, all its instances are also
excluded.

Note:
If a module itself is excluded, coverable objects at the instance
level can not be later included through DVE. However, if the
module definition is not totally excluded, coverable objects at the
instance level, which were excluded in the module can later be
included in DVE.

Exclusion Propagation in Hierarchies

Exclusion at the instance level is not propagated to the module. Even
if all the instances of one particular module are excluded, that
module is not marked as excluded and coverage for that module is
reported.

Exclusion Management
12-28
Excluding Half Toggle Transitions
Toggle coverage for a bit is combination of two sequences 0 -> 1 and
1 -> 0, which gets counted in the final score of the toggle coverage.
The total count of toggle coverable objects for a signal is the number
of bits in that signal times two, where two is number of sequences
per bit.

You can exclude either sequences of a given bit in a signal. For

example, you can exclude only the 0 to 1 transition for a bit.

Consider the following example, where p[0] goes from 0 to 1 and p[1]
goes from 1 to 0:

initial begin
reg [1:0] p;

p = 2'b10;
#1 p = 2'b01;
end
You can exclude the 1 to 0 transition for p[0] and the 0 to 1 transition
for p[1], since neither can occur in this code.

For this example, the toggle coverage exclude file will be as follows:

=== elfile ===

Module: top
Toggle 0to1 p[1]

To exclude the toggle transition, use the following steps

1. Select the transition and right-click in the Summary window to

display the CSM.
2. Select Exclude or Unexclude to display the transition sub-menu.

Exclusion Management
12-29
 3. Select any of the following sub-menu options as desired:
Figure 12-12 Excluding Toggle Transition

- All - Marks Exclude/Unexclude for the selected item (signal

or vector).
- 0=>1 - Marks Exclude/Unexclude for all 0=>1 transitions in
the selected item.
- 1=>0 - Marks Exclude/Unexclude for all 1=>0 transitions in
the selected item.

Exclusion Management
12-30
Excluding Covergroups

You can exclude covergroups, cover items, or the constituent bins

using the DVE Coverage GUI.

To exclude covergroups in DVE, use the following steps:

1. Start DVE in coverage mode.

2. Load the Coverage Database.
The DVE coverage windows are populated with the coverage
data.
3. Select the covergroup in the Navigation pane.
The covergroup items (coverpoints and bins) are displayed in the
Summary pane, as shown in the following figure:

Exclusion Management
12-31
Figure 12-13 Covergroup Items in the Summary Pane

4. Modify the covergroup data usingthe following steps:

- Select the coverpoints/crosses under the covergroup in the
Summary window and exclude/include them using the CSM.
- View the source file with annotations indicating covered and
uncovered lines or objects in the Annotated Source window.
- View the excluded coverpoints/crosses in Table or Map view
in the Detail window.
- Save the exclusion data in an exclusion file.
- Load/Reload saved exclude file(s).
For more information on saving/loading exclusion data, see
section “Saving and Loading Saved Exclusions” .

Exclusion Management
12-32
 Note:
In Strict mode, you cannot exclude a cover point/cross once the
score is 100%. When the score is greater than 0 and less than
100, its uncovered children are excluded and covered children
are marked as attempted.

Exclusion Propagation in Covergroups

Coverpoint and coverpoint bins exclusion are propagated to the
crosses automatically. If you exclude coverpoint or coverpoint bins,
cross or cross bins containing the coverpoints are excluded as well.

Variants of Covergroups
Variants are different shapes of the covergroup definition due to
module instances or parameterized covergroup instances.

Exclusion Management
12-33
Figure 12-14 Variants of Covergroup coin_fsm::Cvr

In this figure, the covergroup definition coin_fsm::Cvr defined in

module coin_fsm has five different variants created for each
instance of the module.

Exclusion Management
12-34
Excluding Auto-Cross Bins

You can exclude the auto cross bins either directly in the Detail
window or using the Edit Exclusion sub-menu.

To exclude auto-cross bins, use the following steps:

1. Select auto cross bins in the Summary window.

2. Right-click and select Expand.
The compressed bins are visible.
3. Select Exclude/Unexclude icons to exclude/include the sub-
bins.

Excluding Toggle Coverage MDA

DVE Coverage supports the Verilog MDA exclusion. You can

exclude the entire MDA range items or individual bits of an MDA
range items, in the Detail window.

By default, the VCS coverage engine does not monitor MDAs as a

part of toggle coverage. You can use the -cm tgl and -cm_tgl
mda options, to enable monitoring of MDAs, as follows:.

% vcs –cm tgl –cm_tgl mda

To exclude bits of an MDA range item, use the following steps:

1. Select an MDA range item in the Summary window to view its

range items in the Detail window.
2. Right-click and select Expand MDA to show the compressed
MDA bits, as shown in Figure 12-15.

Exclusion Management
12-35
 The compressed MDA bits are visible.

3. Select Exclude/Unexclude icons to exclude/include the MDA

bits.
Figure 12-15 MDA Exclusion

Note:
If there are multiple dimensions (for example, A[1:3][4:7]),
DVE expands them, dimension by dimension and from left to right.

Exclusion File Syntax for MDA Exclusion

You can use an exclusion file to exclude MDA completely or to
specify a list of ranges to be excluded. The following examples
discusses the syntax that you can use to exclude MDAs.

• Elfile 1 excludes the MDA as a whole, as follows:

MODULE: test
Toggle mda1

Exclusion Management
12-36
 • Elfile 2 excludes a specific range of the MDA, as follows:
MODULE: test
Toggle mda1[1:16][7:4]

Excluding Cross-of-a-Cross

You can exclude a cross-of-a-cross either by selecting it from DVE

or by specifying the cross-of-a-cross or its bins in an exclusion file.

Using Exclusion File to Exclude Cross-of-a-Cross

To exclude a cross-of-a-cross, specify the name of the cross-of-a-
cross with keyword coveritem under the covergroup in which it is
defined. The following is the syntax:

covergroup <scope_name>::<covergroup_name>
coveritem <cross-of-a-cross_name>

To exclude bins of a cross-of-a-cross, first specify the cross-of-a-

cross and then specify its bins. The following is the syntax:

covergroup <scope_name>::<covergroup_name>
coveritem <cross-of-a-cross_name>
{bins_defn}

Consider the covergroup shown in Example 12-3:

Example 12-3 Excluding Cross-of-a-Cross #1

covergroup cov1 @(posedge clk);
cp1: coverpoint a;
cp2: coverpoint c;
cp3: coverpoint b;
cr1: cross cp1, cp2;
cr2: cross cr1, cp3;
endgroup

Exclusion Management
12-37
 Based on Example 12-4, you can use the following elfile to exclude
cross-of-a-cross cr2 as a whole:

covergroup top::cov1
coveritem cr2

To exclude a specific bin of cross-of-a-cross cr2, you can use the

following elfile. The bin is the cross of auto[1] of coverpoint a,
auto[0] of coverpoint c and auto[0] of coverpoint b.

covergroup top::cov1
coveritem cr2
bins {{{auto[1]}, {auto[0]}}, {auto[0]}}

Now, consider the covergroup shown in Example 12-4:

Example 12-4 Excluding Cross-of-a-Cross #2

covergroup cov1 @(posedge clk);
cp1: coverpoint a;
cp2: coverpoint c
{
bins B1= {0};
bins B2= {1};
}
cp3: coverpoint b
{
bins b1 = {[0:7]};
bins b2 = {[8:15]};
}
cp4: coverpoint d;
crbd : cross cp3, cp4;
cr1: cross cp1, cp2;
cr2: cross crbd, cp1;
cr3: cross cr2, cp2;
endgroup

Exclusion Management
12-38
Based on Example 12-4, you can use the following elfile to exclude
the bin of cross-of-a-cross cr2, which is cross of user-defined bin b1
of coverpoint b, auto cross bin range of auto[0] – auto[15]
of coverpoint d, and auto-bin auto[0] of coverpoint a.

covergroup top::cov1
coveritem cr2
bins { {{b1}, {auto[1]-auto[15]}}, {auto[0]}}

Also based on Example 12-4, you can exclude a bin of cross-of-a-

cross cr3. Note that cr3 is made up of a cross-of-a-cross (cr2) and
coverpoint cp2.

coveritem cr3
bins {{ {{b1}, {auto[1]-auto[15]}}, {auto[0]}}, {B1}}

The exclusion status of a coverpoint, coverpoint bin, cross, cross bin,

cross-of-a-cross, and cross-of-a-cross bin is propagated to the
container cross-of-a-cross.

In Example 12-4, if the bin b1 of coverpoint b is excluded, the

status is automatically propagated to the bins of cr2 which contain
b1 (for example, {{{b1}, {auto[1]-auto[15]}},
{auto[0]}}). Similarly, the bin bins {{{{b1}, {auto[1]-
auto[15]}}, {auto[0]}}, {B1}} of cr3 are also excluded.

Exclusion Management
12-39
 Enhanced Syntax of Covergroup Exclusion
For manually written exclusion files, you must specify a cross-of-a-
cross and its bins using the following syntax. In this syntax
description, the line highlighted in bold shows the enhancement
made to the syntax. The line highlighted in gray is replaced by the
line highlighted in bold from this version forwards.

covergroup_spec ::= cg_excl_list

| cg_inst_excl_list
| cg_excl_spec
cg_excl_spec ::= covergroup [ex_identifier]
{coveritem_exclusion}
cg_excl_list ::= covergroup ex_identifier_list
ex_identifier_list ::= ex_mod_identifier [,
ex_mod_identifier]
cg_inst_excl_list ::= covergroup ex_inst_ identifier_list
ex_inst_ identifier_list::= ex_inst_ identifier [,
ex_inst_identifier]
ex_mod_identifier:: hierarchy::covergroup_name_identifier
ex_inst_identifier::
hierarchy.covergroup_inst_name_identifier
coveritem_exclusion ::= coveritem_excl_list
| coveritem_excl_spec
coveritem_excl_list ::= coveritem ex_identifier_list
cp_excl_spec :: = coveritem ex_identifier
{bin_exclusion}
bin_exclusion ::= bin bin_list
bin_list :: = bin_spec [, bin_spec]
bin_spec:: = cp_bin_spec
| auto_cross_bin_spec
cp_bin_spec:: = ex_identifier
| auto_cp_bin_spec
auto_cp_bin_spec:: = auto[bin_range]
| auto[bin_range]-auto[bin_range]
bin_range:: = ex_identifier
| ex_identifier:ex_identifier
auto_cross_bin_spec:: = {cross_bin_dim_list}
cross_bin_dim_list:: = cross_bin_dim [, cross_bin_dim]
cross_bin_dim_list:: = cross_bin_dim | auto_cross_bin_spec

Exclusion Management
12-40
[, cross_bin_dim | auto_cross_bin_spec ]
cross_bin_dim ::= {} | {cp_bin_list}
cp_bin_list ::= cp_bin_spec [, cp_bin_spec]
ex_identifier ::= simple_identifier | escaped_identifier

Saving and Loading Saved Exclusions

There are two ways to save exclusions:

• Using the File > Save Exclusions menu.

• Using the Edit > Preferences > Exclusion, then selecting the
option Save exclusion data when saving sessions.
To save an exclusion state using the Save Exclusions menu, use the
following steps:

1. Select File > Save Exclusions.

The Save Exclusion File dialog box appears.

2. Enter a name for the exclusion file.

Exclusion Management
12-41
Figure 12-16 Save Exclusion Dialog Box

3. Select the New Format radio button, if not already selected.

If you select the Old format radio button, a warning message
appears.
4. Click OK.
The exclusion state is saved.

Exclusion Management
12-42
 Loading Exclusions From an Exclusion File
To load exclusions from an exclusion file, use the following steps:

1. From the File menu, select Load Exclusions > From File....The
Load Exclusion dialog box appears as follows:
Figure 12-17 Load Exclusion Dialog Box

2. Select an exclude file from the directory.

3. (Optional) Select the Clear current exclusions before loading
check box to clear all the exclusions.
4. Select the Bypass checks check box to bypass the checksum
checks.
5. Click Open.
The exclusion file is loaded bypassing the checksum validation.

Exclusion Management
12-43
 To load multiple exclusion file from a file list, use the following steps:

1. From the File menu , select Load Exclusions > From File List.
The Load Exclusion File List dialog box appears, as follows:
Figure 12-18 Load Exclusion File List Dialog Box

2. Select the file list in which you have stored multiple exclusion files
and click Open.The exclusion files are loaded.

Exclusion Management
12-44
Loading Excluded Covered Items in Strict Mode
In the Strict mode, covered items cannot be excluded. When you
load an exclude file containing covered items in the Strict mode, the
following warning is issued. You can either choose to continue
loading the exclusion file by clicking on Select continue, or you can
abort the loading of the exclude file by clicking the Abort option and
exit DVE.

You can also choose to view the details of the covered objects by
clicking on the Detail option.

Exclusion Management
12-45
 Recalculating Coverage Scores

Once items are marked for exclusion, you need to recalculate the

coverage scores. To do so, select from the toolbar or use the

command Edit > Exclusion > Recalculate.

The Recalculate command will be disabled until an item is marked

for exclusion. After recalculation, it is once again disabled.

Recalculation will not be required again if you add/edit or delete an

annotation on an existing excluded item. To save time, it is
recommended that you mark multiple items for exclusion before
recalculating coverage scores, rather than recalculating after
marking each item.

Using Adaptive Exclusion in DVE

Adaptive exclusion is a DVE process you can use to review and

reuse an exclusion. To facilitate this, the adaptive exclusion use
model refers to an original version of an exclusion file EA from design
version A and the use of EA with subsequent version B of the same
design. The reuse of exclusion files is important in the coverage flow
because it improves productivity.

The adaptive exclusion review flow works with all metrics, including
line, toggle, FSM, branch, assertion, condition, and covergroup.

• Exclusion reviews can take place at a low granularity in the

navigation pane.
• Exclusions reviews of high granularity use signatures and take
place in the detail panes.

Exclusion Management
12-46
This section discusses the following subsections:

• “Adaptive Exclusion Review Flow”

• “Reviewing Exclusions in the Navigation Pane”
• “Reviewing Exclusions in the Detail Pane”
• “Unmappable Exclusions”
• “Limitations”

Adaptive Exclusion Review Flow

In order to reuse the exclusion file on the modified part of the design,
DVE coverage allows you to review the existing exclusions, decide
which exclusions you can reuse, and which cannot be reused with
the newer version of the design.

The review flow consists of compiling and simulating design version

A, and creating an exclusion file EA. When you modify the design to
create design version B, he goal of adaptive exclusion is to make it
easy for you to reuse exclude file EA on design version B. To review
an exclusion file with checksum mismatches, use the following
steps:

1. Load the coverage database generated with design B in

interactive mode.
2. Load the file EA.

2.1) If you select bypass_check to load the exclusion file, all

exclusions with mismatched signatures are directly applied
without the checksum comparison.

Exclusion Management
12-47
 2.2) If you do not select bypass_check, you can continue to Step
3.

3. If there is any checksum mismatch, DVE opens up all exclusions

in the modified design scopes.
4. Select a scope or module that contains exclusions that are not
reviewed and go to the Detail Pane for further review.
5. Review the exclusions using the procedure explained in section
“Reviewing Exclusions in the Detail Pane” .
6. If there are any unmappable exclusions, you can review them in
the Unmappable dialog box.
6.1 In the Unmappable dialog box, you can mark the exclusion
as reviewed.

7. Repeat steps 4 to 6 for every metric until all objects in the instance
or module are reviewed completely.
8. Recalculate to apply all reviewed results.
9. Save as a new exclusion file elfile (optional).
Note:
Once a reviewed exclusion is recalculated, it cannot be changed
back to the unreviewed state. To retrieve unreviewed exclusions,
click Clear Reviews button or use the menu command Edit
> Review > Clear Reviews, and then reload the exclusion file.

Exclusion Management
12-48
Enabling and Disabling Adaptive Exclusion Review
Mode
The following sections describe how you configure the adaptive
exclusion review mode:

• “Disabling Adaptive Exclusion Review Mode”

• “Enabling Adaptive Exclusion Review Mode”

Disabling Adaptive Exclusion Review Mode

The adaptive exclusion review mode is enabled by default. Use the
-excl_resolve off option or the DVE Application Preferences
dialog box to disable the adaptive exclusion review mode. To disable
the adaptive exclusion review mode using the DVE Application
Preferences dialog box, use the following steps:

1. Select Edit > Preferences.

The Application Preferences dialog box appears.

2. In the Exclusion category, clear the Interactive review mode.

This only takes effect after re-loading the exclusion file.
3. Click OK.
This will disable the adaptive exclusion review mode.

DVE makes this mode as the default mode until you enable adaptive
exclusion review mode again.

Exclusion Management
12-49
 Enabling Adaptive Exclusion Review Mode
You can enable the adaptive exclusion review mode by using the
-excl_resolve on option or by selecting the Interactive review
mode. This only takes effect after re-loading the exclusion file in the
Exclusion category of the DVE Application Preferences dialog
box, as shown in Figure 12-19:

Figure 12-19 Enabling Adaptive Exclusion Review Mode

Exclusion Management
12-50
 Reviewing Exclusions in the Navigation Pane
Exclusion reviews at a high level of granularity (for example, module
or instance) are performed in the Navigation pane. Figure 12-20
shows the Navigation pane with review markers.

Figure 12-20 Navigation Pane with Review Markers

The marker (shown in Table 12-1) is used to indicate that a given

instance or module contains exclusions that you have not yet
reviewed. DVE counts and displays the total number of unreviewed
exclusions at <Design Hierarchy>, <Function Groups>, and
<Module List> headings in the Hierarchy pane, as shown in

Exclusion Management
12-51
 Figure 12-20, so you know if there are any unreviewed exclusions
remaining. If an exclusion is reviewed, then the total number should
decrease by 1. Once the total number becomes 0, it turns green.

Exclusions with unmappable module names are grouped together,

sorted by their module names and shown in the <Module List>
with the icon.

The Navigation pane has a context-sensitive menu (right-click the

review marker), as shown in Figure 12-21:

Figure 12-21 Context-Sensitive Menu in the Navigation Pane

In Figure 12-21, note the following menu selections:

• Review detail — Starts the review with the selected regions

(instances or modules) in detail panes. This is enabled only when
at least one unreviewed region is selected.

Exclusion Management
12-52
 • Review unmappable exclusions — Displays all unmappable
exclusions of the selected scope or module in the Unmappable
dialog box for further review. This is dimmed if not applicable.
• Accept All — Provides two options, All and Signatures
matching, to accept all exclusions or only those with matching
signatures, respectively (see Figure 12-22).
Figure 12-22 Options in Accept All Menu

• All in this metric — If you right-click a list item or source window

in the Detail pane, in this context, the Accept All menu displays
the All in this metric option. You can choose this option to accept
or reject all unreviewed items in the current metric.
Figure 12-23 shows the All in this metric option on the Detail
pane, which shows coverage items of each metric.

Exclusion Management
12-53
Figure 12-23 All in this Metric Option in the Accept All Menu

• Reject All — Provides two options, All and Signatures

mismatch, to reject all exclusions or only those with signatures
that do not match, respectively (see Figure 12-24).

Exclusion Management
12-54
Figure 12-24 Options in Reject All Menu

The ToolTip in the Navigation pane displays the following types of

exclusions for each metric:

• Automatically resolved exclusions

• Unresolved and accepted exclusions
• Unresolved and unaccepted exclusions
• Automatically unresolved exclusions
• Unresolved and reviewed exclusions
For example:

Mappable : a/b/c
Fsm: d
Condition: e
…
Unmappable: f/g

where,

• a is the amount of exclusions that are automatically resolved.

• b is the amount of unresolved exclusions that are accepted by
users.

Exclusion Management
12-55
 • c is the amount of unresolved exclusions that are rejected by
users.
• d and e are total mappable numbers in each metric.
• f is the amount of exclusions that are not automatically resolved
or mapped.
• g is the amount of unresolved exclusions that are reviewed by
users.
Note:‘a’ + ‘f’ = Total exclusions tool attempted to automatically
resolve.
‘g’ <= ‘b’ + ‘c’

Reviewing Exclusions in the Detail Pane

This section explains how you can use the Detail pane in DVE to
perform high-granularity exclusion reviews. This section consists of
the following subsections:

• “Icons in the Review Toolbar”

• “Metric, Scope and Cover group Menus in Review Toolbar”
• “Any and Conflict Menus in Review Toolbar”

Exclusion Management
12-56
 Icons in the Review Toolbar
You select an instance or module to populate the Detail pane by
clicking the Review detail icon in the context-sensitive menu
described in section “Reviewing Exclusions in the Navigation Pane”
. You can then click the icons in the Review toolbar (see Figure 12-
25) to walk through exclusions and review them one by one.

Figure 12-25 Review Toolbar

The following are brief descriptions of the icons:

• Accept — Marks the current exclusion under review as accepted.

DVE then automatically moves forward to the next unreviewed
exclusion.
• Reject — Marks the current exclusion under review as rejected.
DVE then automatically moves forward to the next unreviewed
exclusion.
• Go to previous — Moves to the previous unreviewed exclusion.
• Go to next — Moves to the next unreviewed exclusion.
• Clear Review — Reverts (undo) your previous reviews. This is
useful if you want to start the review again. Clicking this icon
displays the message box shown in Figure 12-26.

Exclusion Management
12-57
Figure 12-26 Confirmation Window for Clear Review Option

Click Yes to clear all the review marks (accept or reject mark along
with any condition open for review).

Note:
After clearing all reviews, you need to reload the exclusion to
continue the review process.

Metric, Scope and Cover group Menus in Review Toolbar

To support the exclusion review flow for all metrics, the Metric,
Scope and Cover group menus are added to the Review toolbar as
shown in Figure 12-27.

Figure 12-27 Metric, Scope and Cover group Menus in Review Toolbar

If you select Metric, then the Go to next button takes you to the next
metric of the current instance or module that contains unreviewed
exclusions. If there is no next metric to review, then the Go to Next
button is disabled.

If you select Scope, then the Go to next button takes you to the next
instance or module. It goes through instances first, then modules. If
there is no next scope or instance available to review, then the Go to

Exclusion Management
12-58
 next button is disabled. When a new instance or module is
populated in the Detail pane, the Summary report is printed in the
console and the Detail pane switches to the first available metric for
review.

If you select Cover group, then the Go to next button takes you to
the next or previous cover group, which contains unresolved
exclusions.

• In code coverage, the sequence of Go to next metric is: Line ->

Toggle -> Condition -> FSM -> Branch -> Assert.
• In functional coverage, if you select Scope as the criterion, then
two buttons are disabled, but Metric is allowed. The sequence is:
Cover-Group -> Assertion.
When you decide to accept or reject an exclusion, you need to
compare the signature from the database to the signature from the
exclusion file to see if they match.

Any and Conflict Menus in Review Toolbar

A combo-box with Any and Conflict menus is available in the
Review toolbar, as shown in Figure 12-28.

Figure 12-28 Any and Conflict Menus in Review Toolbar

If you select Any, then the Go to next button goes through any
unresolved exclusion. If you select Conflict, then the Go to next
button goes through an unresolved exclusion with mismatching
signature only.

Exclusion Management
12-59
 Unmappable Exclusions
In some scenarios, there might be a module, instance, or expression
that has changed a lot. In such cases, the excluded objects in the
exclusion file cannot be mapped to the changed design. To display
unmappable exclusions, you can use the Unmappable exclusions
dialog box.

To invoke the Unmappable exclusions dialog box:

• From the Edit > Review menu, select Show unmappable

exclusions. The Unmappable Exclusions List dialog box
appears, displaying all unmappable exclusions.
(or)

• Select a scope or module and select Review unmappable

exclusion from the context sensitive menu. The dialog box
displays unmappable exclusions of the selected scope or module.
Figure 12-29 shows the Unmappable Exclusion List dialog box
displaying a few unmapped exclusions.

Exclusion Management
12-60
Figure 12-29 Unmappable Exclusion List Dialog Box

The two modes of unmappable exclusion are:

• Not reviewed

• Reviewed

After recalculation, it is displayed as .

The dialog box is synchronized with the current detail window and
only displays one metric at a time. When the metric in the detail
window changes, this dialog box is updated with the new metric.

The five buttons in the Unmappable Exclusion List dialog box are:

• Reset — Marks all selected exclusions as not reviewed.

• Review — Marks all selected exclusions as reviewed.

Exclusion Management
12-61
 • Review All — Marks all exclusions in the dialog box as reviewed.
• Close — Closes the dialog box.
• Tips — Provides review tips.Examples
The following are some examples of unmappable exclusions:

• “Insertion of Another Block”

• “Insertion of Code in the Same Block”
• “Deletion of Irrelevant Code”

Insertion of Another Block

In Figure 12-30, there are two versions of the design. In version 1,
the condition v || x is excluded and is reused in version 2. But in
version 2, a new always block is added which contains the condition
a && b.

Exclusion Management
12-62
Figure 12-30 Insertion of Another Block in Design 2
Design Design
version 1 version 2

module m;
…
always@y
module m; begin
… if (a && b)
always@x begin
begin …
if (v || x) end
begin end
... always@x
end if (v || x)
end begin
endmodule
…
end
end
endmodule

DVE allows the exclusion file generated using version 1 to hold the
checksum for the condition (v || x) computed from @x and
(v||x). For version 2, the checksum of the condition (v||x) is
also computed from @x and (v||x). When an exclusion file sis
loaded into DVE, the checksum of the excluded condition will be
matched against the checksum present in the database. As both the
checksums are same, the condition is excluded automatically.

Exclusion Management
12-63
 Insertion of Code in the Same Block
This is similar to the first example, “Insertion of Another Block” , but
the new code is inserted inside the same always block as shown in
Figure 12-31.

Figure 12-31 Insertion of Code in Same Block in Design Version 2

Design Design
version 1 version 2

module m;
…
module m; always@x
… begin
always@x if (a && b)
begin begin
if (v || x) …
begin end
... if (v || x)
end begin
end …
endmodule end
end
endmodule

Here, the exclusion is applied automatically and no review is flagged.

The checksum for condition (v||x) is same in both the versions.

Exclusion Management
12-64
 Deletion of Irrelevant Code
Two conditions are present inside an always block. Condition 2 has
been excluded in design version 1. In design version 2, condition 1
has been removed. By using checksum based approach, as there is
no change in the checksum for the target condition (v||x) between
both the versions, the object is excluded automatically.

Figure 12-32 Deletion of Irrelevant Code in Design Version 2

Design Design
version 1 version 2

module m; module m;
… …
always@x always@x
begin begin
if (a && b) if (v || x)
begin begin
… ...
end end
if (v || x) end
begin endmodule
…
end
end
endmodule

As long as the checksum of a coverage target remains the same

across the design versions, exclusion is applied without flagging the
review. The computed checksum is dumped into the coverage shape
file and read later to compare with the corresponding checksum
present in the exclusion file.

Exclusion Management
12-65
 Limitations
The following are the limitations with adaptive exclusion:

Adaptive Exclusion for VHDL Designs

Adaptive exclusion is not supported for line and condition metrics for
the VHDL designs.

Adaptive Exclusion Basic Block Limitations

The following limitations apply to basic blocks in the adaptive
exclusion flow:

Incomplete consideration of source

As only the first line is considered in signatures, any changes to
subsequent lines of the basic block go undetected. In this case, you
can see false signature matches.

Over consideration of source

When multiple basic blocks exist on the same line, all of them contain
the same signature. Even in this case, you can see false signature
matches.

For example:

module m;
……
begin
A=0; #5 B=0; //written in a single line
end
endmodule

Exclusion Management
12-66
 A=0 and #5 belong to the same block, whereas B=0 belongs to a
different block, but their signature will be the same ("A=0; #5
B=0;"). For example, consider the blocks to be b1 and b2. If you
change A=0 to A=1, the signature of both the blocks change. But the
checksum of b2 will not change. So, if an exclusion on b2 is applied
byan exclusion file, it will be excluded automatically even if the
signature is different.

The exclusion applied on B2 by the exclusion file excludes it even if

the signature is different.

Viewing Excluded Coverage Objects in URG

You can view coverage objects that have been excluded using DVE
using URG reports. The following sections discusses how URG
displays exclusions:

• “Generating URG Reports Using Exclusion Files”

• “Viewing Excluded Covergroups in URG”
• “Synchronizing Checks Using Checksum”
• “Viewing Annotated Exclusions in URG”
• “Indicating Exclusion Status in URG”
• “Dumping Full Exclusion Files in Commented Format”
• “Full Exclusion Files for Coverage Metrics”

Exclusion Management
12-67
 Generating URG Reports Using Exclusion Files

You can use exclusion files with URG to remove excluded items from
the URG-generated reports. To do this, pass the exclusion file
(created using DVE or manually) to URG using the command-line
option -elfile, as follows:

% urg –dir … –elfile filename.el

Excluded items from the exclusion file are marked Excluded in the
generated URG reports, and are not taken into account for
computing coverage scores.The figure Figure shows a normal URG
report with the total coverage summary. This report displays the total
coverage numbers for the line, condition, toggle, FSM and branch
coverage.

Exclusion Management
12-68
Figure 12-33 Example of a Report without Exclusion

When you specify the exclusion file using the -elfile option, URG
generates the report as shown in Figure 12-34. The total coverage
numbers have increased since some of the uncovered coverage
metric items specified in the exclude file are omitted from the
coverage calculation, resulting in higher coverage numbers:

% urg –dir simv.vdb –elfile filename.el

Exclusion Management
12-69
Figure 12-34 Example of a Report generated with an exclude file

Viewing Excluded Covergroups in URG

You can exclude covergroups in URG in the following ways:

• You can specify a covergroup within the design hierarchy or a

fully-qualified covergroup name as seen in URG report in the
exclusion file. The URG report includes the complete design
hierarchy name also as a part of the covergroup name.
• You can specify the bins level exclusion by its name.
• For a compact and easy specification especially for automatic
bins, URG report prints an identifier (which is a number in an
increasing order) for each of the bins in a cover point and a cross.
This numbering scheme is generated for all bins in each of the
coverpoint.

Exclusion Management
12-70
 You can specify bins level exclusion bylisting these identifiers.

• You can specify automatic cross bins in terms of their identifiers

or in terms of the bin identifiers of the constituent cover items of
that particular cross.

Synchronizing Checks Using Checksum

When exclusions are saved into an exclusion file, DVE generates a

checksum for these exclusions and dumps it into the file. This
checksum is obtained from the metric variant checksum information
and the names of the modules (or covergroups for testbench metric).
The purpose of the checksum is to synchronize the checks.

It is recommended that you create and edit exclusion files using

DVE. However, if you do create your own file outside of DVE, without
the checksum, the synchronization checks are not run.

For code coverage metrics, one line per excluded module is dumped
into the exclusion file and this line consists of the checksums of all
the metrics of excluded objects. This line starts with the prefix \\
MOD_CHKSUM,as shown in the following example:

\\ MOD_CHKSUM: 3 mod v11 L1411939641 v11 T1074138296 v11

C2409237268 v10 B301527767

For covergroup metric, the checksum information starts with the

prefix // Checksum and consists of the names of the excluded
covergroups and its instances, as shown in the following example:

// Checksum: 300200840 3953929699 cg4_i | 3562878031

3865826166 cg3_i | 1282958077 2393771040 cg2_i

Exclusion Management
12-71
 Line Exclusion Format
The line exclusion format contains information on the checksum,
excluded block_ids, and the module or instance scope for which
the exclusion is carried out. This is illustrated in the following
example:

Exclusion Format
CHECKSUM: "3656021512 2564524589"
INSTANCE: test
Block 1 "802523853" "case (state)"
Block 3 "1605227561" "next_state = 3'b1;"
Block 7 "2054220958" "next_state = 3'b1;"

Verilog File
20 always @(data,state) begin
21 case(state)
22
23 3'b000:begin
24 if(data)
25 next_state=3'b001;
26 else
27 next_state=3'b000;
28 end
29 3'b001:begin
30 if(!data)
31 next_state=3'b010;
32 else
33 next_state=3'b001;
34 end

URG Report
6 always @(data,state) begin
7 excluded case(state)
8
9 3'b000:begin
101/1 ==>if(data)
11 excludednext_state=3'b001;

Exclusion Management
12-72
12 else
13 1/1 ==> next_state=3'b000;
14 end
15 3'b001:begin
16 1/1 ==> if(!data)
17 1/1 ==> next_state=3'b010;
18 else
19 excludednext_state=3'b001;
20 end

Toggle Exclusion Format

The toggle exclusion format identifies the instance, module, and
toggle ID, as illustrated in the following example:

Verilog File
1 module top;
2 reg [26:10] top_var1;
3 reg [26:10] top_var2;
4 reg top_var3;
5 reg top_var4;
6 reg top_var5;
7
8 wire [26:10]top_net1, top_net2;
9 wire top_net3, top_net4, top_net5;
… …
endmodule

Exclusion Format
INSTANCE: top
Toggle top_net1
Toggle 0to1 top_net2[26:10]
Toggle 1to0 top_net3

Exclusion Management
12-73
 URG Report
Net Details
Toggle Toggle 1->0 Toggle 0->1 Direction

top_net1[26:10] Excluded Excluded Excluded

top_net2[14:10] No No Excluded
top_net2[20:15] Yes Yes Excluded
top_net2[23:21] No Yes Excluded
top_net2[25:24] No No Excluded
top_net2[26] No Yes Excluded
top_net3 No Excluded Yes

FSM Exclusion Format

The FSM exclusion format identifies the instance, module, and the
FSM.Italso identifies transition exclusion and an optional state, as
illustrated in the following example:

Verilog File
reg [1:0] state,next;
parameter idle = 2'b00,
first = 2'b01,
second = 2'b10,
third = 2'b11;
... ...
always @ in
begin
next = state; // by default hold
case (state)
idle : if (in) next = first;
first : if (in) next = second;
second : if (in) next = third;
third : if (in) next = idle;
endcase
end

always @ (posedge clk)

state=next;

Exclusion Management
12-74
Exclusion Format
INSTANCE: top1
MODULE: dev
FSM state
State first
State second
State third
Transition idle->first
Transition first->second
Transition second->third
Transition third->idle

URG Report
State, Transition and Sequence Details for FSM :: state
states Covered
idle Covered
first Attempted
second Attempted
third Excluded

transitions Covered
idle->first Attempted
first->second Attempted
second->third Excluded
third->idle Excluded
...

Condition Exclusion Format

The excluded condition format identifies the instance, module,
condition, and condition vectors, as illustrated in the following
example:

Verilog file
56 input clk,in;
57 output [1:0] state;
58 wire e;
59 assign e = clk ? 1'b0:1'b1;

Exclusion Management
12-75
 60 reg [1:0] state,next;

Exclusion Format
INSTANCE: top3.D3
Condition 1 (1)
Condition 1 (2)

URG Report
LINE 59
EXPRESSION (clk ? 1'b0 : 1'b1)
-1-
-1- Status
0 Excluded
1 Excluded

Branch Exclusion Format

The excluded branch format identifies the instance, module, and the
vector ID representing the excluded branches, as illustrated in the
following example:

Verilog file
24 always@(posedge clk)
25 begin
26 // nested if's
27 if ( e && f)
28 begin
29 $display("s3");
30 if ( g && h)
31 $display("s4");
32 end
33 end

Exclusion Format
MODULE: test
Branch 2 (0)
Branch 2 (1)

Exclusion Management
12-76
URG Report
27 if ( e && f)
-1-
28 begin
29 $display("s3");
30 if ( g && h)
-2-
31 $display("s4");
==>
MISSING_ELSE
==>
32 end
MISSING_ELSE
==>

Branches
-1- -2- Status
1 1 Excluded
1 0 Excluded
0 - Covered

Assertion Exclusion Format

The excluded assertion format identifies the instance, module, and
the assertion name that is excluded, as illustrated in the following
example:

INSTANCE: tb.dut
MODULE: top.test
Assert a_one_yellow

Exclusion Management
12-77
 Covergroup Exclusion Format
The following is a snapshot of covergroup code and various elfile
examples that can be used with it:

module M;
…
bit [3:0] x;
integer y;
integer z;

covergroup cov1;
cp1: coverpoint x;
cp2: coverpoint y {
bins b1 = {100};
bins b2 = {200};
bins b3 = {300};
bins b4 = {400};
bins b5 = {500};
}
cp3: coverpoint z {

bins zb1[] = {[10:18]};

bins zb2 = {4543};
}

cc1: cross cp1, cp2, cp3 {

bins cb1 = binsof(cp2.b2);
}
cc2: cross cp1, cp2, cp3;
endgroup

covergroup cov2;
coverpoint cp1 {
…
}
coverpoint cp2 {
…
}
coverpoint cp3 {
…

Exclusion Management
12-78
 }
cc1: cross cp3, cp2;
cc2: cross cp2, cp1;
endgroup

cov1 cov1_inst1 = new;

cov2 cov2_inst1 = new;
…
endmodule

module top;
M i1();
M i2();
…
endmodule

Example elfile1
covergroup top.i1::cov1
covergroup top.i2.cov2_inst1

This elfile specifies that covergroup cov1 in design hierarchy

top.i1 and instance cov2_inst1 of covergroup cov2 in design
hierarchy top.i2 should be excluded. The hierarchy of an instance
is the same as that of its definition. In covergroup definitions,'::'
serves as the resolution operator, while it is '.' in instances. For
instance, covergroup cov2 in this example is represented as
top.i1::cov2, while its instance cov2_inst1 is specified as
top.i1.cov2_inst1.

Example elfile2
covergroup top.i1::cov1
coveritem cp2
bins b1, b2 //Multiple bins grouped in a comma
separated list
coveritem cc2

Exclusion Management
12-79
 covergroup top.i1::cov2
coveritem cp1, cp2 //Multiple coverpoints/crosses
grouped in a comma-separated list

covergroup top.i1::cov2, top.i1::cov3 //Multiple cover group

definitions grouped in a
comma-separated list
coveritem cp2
Multiple covergroup instances having common exclusion items can
grouped in a single comma-separated list, as illustrated in this elfile
example.

Example elfile3
covergroup top.i1::cov1
coveritem cp1
bins auto[8], auto[10], auto[11], auto[12], auto[13]
coveritem cp2
bins b3, b5
coveritem cp3
bins zb2
coveritem cc1
bins cb1
coveritem cc2
bins {{auto[1], auto[4]}, {b2}, {zb1[13], zb1[14],
zb2}}

covergroup top.i2.cov2_inst1
coveritem cc1, cc2

In this example, the five auto bins auto[8], auto[10], auto[11],

auto[12], auto[13] can be specified in a compressed form:
auto[8], auto[10-13] or auto[8], auto[10]-auto[13].
This representation is particularly useful in specifying coverage
holes, which are reported in the compressed format by URG.

Exclusion Management
12-80
The auto cross bins specification {{auto[1], auto[4]}, {b2},
{zb1[13], zb1[14], zb2}} subsumes six auto bins of the cross
cc2, corresponding to the following six combinations of coverpoint
bins:

cp1 cp2 cp3

auto[1] b2 zb1[13]
auto[1] b2 zb1[14]
auto[1] b2 zb2
auto[4] b2 zb1[13]
auto[4] b2 zb1[14]
auto[4] b2 zb2

Example elfile4
covergroup top.i1::cov1
coveritem cp2
coveritem cc1
bins {{auto[1], auto[ 8]}, {}, {zb1[18]}} // {} -
Consider all bins of cp2 in cross exclusion
coveritem cc2

bins {{},{},{}} //Equivalent to excluding all bins

of the cross cc2

Example elfile5
Consider the uncovered bins printed for the cross cc1 in the URG
report as follows:

cp1 cp2 cp3 COUNT AT LEAST NUMBER

* [b5 , b4 , b3] * -- -- 1056

The compressed representation of uncovered bins can be excluded

as follows:

covergroup top.i1::cov1
coveritem cc1
bins {{},{b3,b4,b5},{}}

Exclusion Management
12-81
 Thus, URG automatically excludes these uncovered bins while
generating the URG report.

Viewing Annotated Exclusions in URG

You can view the exclusion annotation in URG, in the last column of
each coverable object, in the table for Condition, FSM, Toggle, and
Branch. For Line coverage, you can see the annotation in the line
below the excluded line in the Line Coverage Report.

The following is an example of exclusion annotation in a Branch

coverage report:

Note:
The existing annotation is overwritten when loading multiple
exclusion files if there are annotations in each file for a scope/
object. When the same coverage object is marked as excluded
but with different annotations, DVE/URG will keep all the
annotations, regardless of whether the annotation comes from the
same exclusion file or different exclusion file.

Exclusion Annotation Syntax

The annotation for a coverable object is added in front of it in the
exclusion file. The keywords - ANNOTATION,
ANNOTATION_BEGIN, and ANNOTATIION_END are used to
describe annotations.

Exclusion Management
12-82
The ANNOTATION keyword is used for adding an annotation to a
single scope/object.The ANNOTATION_BEGIN/ANNOTATION_END
keywords are used for adding annotations for scopes or containers.

Example 1
MODULE: top

ANNOTATION: "it is unreachable."

Signal a
signal b

In this example only signal a is excluded and annotated.

Example 2
INSTANCE: TOP.CPU.ALU

ANNOTATION_BEGIN: "unreachable"
Condition 1 (1)
Condition 1 (2)
Condition 1.1 (1)
Condition 1.1 (2)

ANNOTATION_END

Exclusion Management
12-83
 Indicating Exclusion Status in URG

URG indicates partially or fully excluded modules or instances with

exclusion symbols in hierarchy, modlist and modinfo html/txt
based pages in the URG report directory generated.

In the HTML reports, partially excluded scopes (modules or

instances) are indicated with and fully excluded scopes are
marked with .

In the text reports, partially excluded scopes are annotated with (x)
and fully excluded scopes are annotated with(X).

Examples
Example-1: Module and Instance Partially Excluded HTML
Report

Exclusion Management
12-84
Figure 12-35 Modlist.html

Figure 12-36 Hierarchy.html

Exclusion Management
12-85
Figure 12-37 modinfo.html

Figure 12-38 Text Report

Exclusion Management
12-86
 Example-2: Instance Completely Excluded

Figure 12-39 HTML Report

Figure 12-40 Text Report

Exclusion Management
12-87
 Dumping Full Exclusion Files in Commented Format

You can dump metric specific exclusion files at the instance and
module level using the -dump full_exclusions URG option.
Each metric specific exclusion file includes the exclusion entries for
all the corresponding coverable objects for each instance and
module of the design.

When the file is generated, the exclusion entry for each coverable
object of an exclusion file is commented out. You can edit the
exclusion file to uncomment the exclusion entries of the objects that
you want to exclude from the coverage report. The edited file can be
used either in the URG or the DVE exclusion flow.

This feature allows you to manage exclusions without using the DVE
interactive flow. The -dump full_exclusions option is used to
create exclusion files. The files are edited either manually or by user-
defined scripts or tools, and then loaded into URG or DVE or Verdi
to generate the final coverage report.

The following sections describe how you can dump and use full
exclusion files.

• “Dumping Full Exclusion Files”

• “Controlling the Hierarchy Dumped in Full Exclusion Files”
• “Using Dumped Full Exclusion Files”

Exclusion Management
12-88
Dumping Full Exclusion Files
The supported metrics for dumping full exclusion files are line,
toggle, condition, branch, FSM, group (functional) and assert. To
dump the exclusion files for specific metrics, execute the following
command:

% urg -dump full_exclusions [metric1[+metric2..]] \

<other URG options>

For each metric, fullexclude.<metric> and

fullexclude_module.<metric> files are dumped.

If you do not specify any metric to the -dump full_exclusions

option, URG dumps the exclusion files for all the metrics that are
present in the design directory.

% urg -dump full_exclusions <other URG options>

Note:
For the VHDL portion of the design, the metric checksum for line
and condition coverage is not dumped, as adaptive exclusion is
not supported for VHDL.

Controlling the Hierarchy Dumped in Full Exclusion

Files
By default, all the excludable-objects of all instances and modules of
a design are dumped in the corresponding
fullexclude.<metric> and
fullexclude_module.<metric> file. To dump only the required
part of the design in the exclude files, use the -hier<hierFile>
URG option. The hierarchy enabled by the <hierFile> is dumped
into the corresponding full exclusion file. The syntax is as follows:

Exclusion Management
12-89
 % urg -hier <hierFileName> -dump full_exclusions \
<other URG options>

Using Dumped Full Exclusion Files

To use the exclusion files in the exclusion flow of DVE or URG,
execute the following command:

% urg -elfile fullexclude.line

Note:
With the -dump full_exclusions option, any previously
existing fullexclude.<metric> files are overwritten. To
prevent unnecessary loss of information, copy or rename the
existing fullexclude.<metric> file and then use the new file.

Full Exclusion Files for Coverage Metrics

The following sections discuss the full exclusion files for each metric.

• “Full Exclusion Files for Line Coverage”

• “Full Exclusion Files for Toggle Coverage”
• “Full Exclusion Files for Condition Coverage”
• “Full Exclusion Files for Branch Coverage”
• “Full Exclusion Files for FSM Coverage”
• “Full Exclusion Files for Group Coverage”
• “Full Exclusion Files for Assertion Coverage”
Example 12-5 is the design used to describe line, toggle, condition,
and branch metrics.

Exclusion Management
12-90
Example 12-5 Design Used to Describe Line, Toggle, Condition, and Branch
Metrics
1
2 module top;
3 reg[3:1] x, y, z;
4
5 test t1();
6 test t2();
7
8 initial begin
9 if(x & y)
10 $display("x & y");
11 else if(y || z)
12 $display("y || z");
13 else
14 $display("Else block");
15 end
16 endmodule
17
18 module test;
19 reg a,b;
20 reg a1,b1,c1;
21 reg z;
22 wire w;
23 reg [1:0] m,n;
24 reg [3:0] p [3:0];
25 reg [3:0] q [3:0];
26
27 assign w = (a ? 1'b1 : 1'b0);
28
29 initial begin
30 $monitor($time,a,b);
31 #1;
32 a = 1'b0;
33 b = 1'b1;
34 if (a && b)
35 $display("a && b");
36 else if (m|n)
38 $display(" m|n ");
39 else
40 $display(" Else block ");

Exclusion Management
12-91
 41
42 z = a1 ^ b1 | c1;
43 end
44 endmodule

Full Exclusion Files for Line Coverage

You can use the -dump full_exclusions [line] URG option

to dump fullexclude.line and fullexclude_module.line
exclusion files.

fullexclude.line File
The fullexclude.line file includes all the excludable objects for
line coverage. To exclude any basic block from the line coverage
report, uncomment the corresponding exclusion entry in the
fullexclude.line file.

Example 12-6 illustrates the fullexclude.line file.

Example 12-6 fullexclude.line File

//========================================================================
// This file contains the Excludable objects for Line coverage
// Generated By User: xxxxxx
// Format Version: 2
// Date: Tue Jun 18 03:16:08 2013
// ExclMode: default
// Version: I-2014.03-Beta0
// Usage:
// (i) For each instance, the following is dumped:
// <Module-checksum> <Metric-checksum>
// <ANNOTATION containing Module-name>
// <Instance/Module-name>
// <ANNOTATION containing source-info for Basic block 1>
// <Exclusion-info for Basic block 1>
// <ANNOTATION containing source-info for Basic block 2>
// <Exclusion-info for Basic block 2>
// ...
// ...
// <ANNOTATION containing source-info for Basic block n>
// <Exclusion-info for Basic block n>
// (ii) Each basic block's exclusion-info is of the form:
// Block <block-id> "<block-checksum>" "<block-signature>"
// For e.g.,

Exclusion Management
12-92
// if basic block's exclusion-info is:
// // Block 3 "3426792653" "$display(" a && b");
// then,
// block-id: 3
// block-checksum: "3426792653"
// block-signature: "$display(" a && b");
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option
// '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick
// reference.
// It can be edited by users to add their own annotations. Users
// can as well delete the line containing the annotation.
//
// (NOTE:
// This file will be overwritten if '-dump full_exclusions' is
// enabled again.)
//========================================================================

// CHECKSUM: "2611468360 283053632"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t1
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:30"
// Block 1 "3569065293" "$monitor($time, a, b);"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:31"
// Block 2 "1571914351" ";"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:35"
// Block 3 "3426792653" "$display(\" a && b\");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Block 4 "175478951" "if ((m | n))"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:37"
// Block 5 "2169278599" "$display(\" m|n \");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:39"
// Block 6 "3172254695" "$display(\" Else block \");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:41"
// Block 7 "3242563609" "z = ((a1 ^ b1) | c1);"

// CHECKSUM: "2611468360 283053632"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t2
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:30"
// Block 1 "3569065293" "$monitor($time, a, b);"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:31"
// Block 2 "1571914351" ";"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:35"
// Block 3 "3426792653" "$display(\" a && b\");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Block 4 "175478951" "if ((m | n))"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:37"
// Block 5 "2169278599" "$display(\" m|n \");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:39"
// Block 6 "3172254695" "$display(\" Else block \");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:41"

Exclusion Management
12-93
 // Block 7 "3242563609" "z = ((a1 ^ b1) | c1);"

// CHECKSUM: "4211721852 3052365625"

//
// ANNOTATION: "ModuleName: top"
// INSTANCE: top
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:9"
// Block 1 "2350782579" "if ((x & y))"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:10"
// Block 2 "626554033" "$display(\"x & y\");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:11"
// Block 3 "3997206727" "if ((y || z))"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:12"
// Block 4 "4037394950" "$display(\"y || z\");"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:14"
// Block 5 "2273786389" "$display(\"Else block\");"

fullexclude_module.line
In a fullexclude_module.line file, the header and the format
of dumping remains same as that of the fullexclude.line file,
but it contains exclusion entries of all the excludable objects for line
coverage at module level. You can edit this file to exclude the objects
for line coverage at module level (for all instances of the module).

Full Exclusion Files for Toggle Coverage

You can use the -dump full_exclusions [tgl] URG option
to dump fullexclude.tgl and fullexclude_module.tgl
exclusion files.

fullexclude.tgl File
The fullexclude.tgl file includes the excludable objects for
toggle coverage. To exclude any signal, uncomment the
corresponding exclusion entry in the fullexclude.tgl file. You
can also edit the file to exclude bit-selects or part-selects at 0->1 or
1->0 transition levels as per the exclusion syntax.

Exclusion Management
12-94
 Example 12-7 illustrates the fullexclude.tgl file.

Example 12-7 fullexclude.tgl File

//========================================================================
// This file contains the Excludable objects for Toggle coverage.
// Generated By User: xxxxxx
// Format Version: 2
// Date: Tue Jun 18 03:16:08 2013
// ExclMode: default
// Version: I-2014.03-Beta0
// Usage:
// (i) For each instance, the following is dumped:
// <Module-checksum> <Metric-checksum>
// <ANNOTATION containing Module-name>
// <Instance/Module-name>
// <ANNOTATION containing source-info for Signal 1>
// <Exclusion-info for signal 1>
// <ANNOTATION containing source-info for Signal 2>
// < Exclusion-info for signal 2>
// ...
// <ANNOTATION containing source-info for Signal n>
// < Exclusion-info for signal n>
// (ii) Each signal's exclusion-info is of the form:
// Toggle [<transition>] <signal> "<signal-signature>"
// where, <signal> can be full signal, part-select, bit-select.
// For eg.,
// if a signal's exclusion-info is:
// //Toggle 1to0 a1 [1:0] "reg a1[3:0]"
// then,
// transition: 1to0
// signal: a1 [1:0] ( to denote part-select a1[1:0] )
// signal-signature: "reg a1[3:0]"
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option
// '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick
// reference.
// It can be edited by users to add their own annotations. Users
// can as well delete the line containing the annotation.
// (NOTE:
// (A) This file will be overwritten if '-dump full_exclusions' is
// enabled again.)
//
// (B) This file contains the exclusions only for full signals.
// Further exclusions can be made as shown below:
// (a) Part and bit-selects of vectors and MDAs can be excluded.
// For e.g.,
// (i) If the declaration of a vector is "reg a1[3:0]",
// then, a part-select of the vector can be excluded as:
// "Toggle a1 [1:0] "reg a1[3:0]" "
// and a bit-select of bit #1 of the vector can be excluded as:
// "Toggle a1 [1] "reg a1[3:0]" "
//
// (ii) If the declaration of an MDA is "reg [3:0]a2[3:0]",
// then, a part-select, [0][3:0] of the MDA can be excluded as:
// "Toggle a2 [0][3:0] "reg [3:0]a2[3:0]" "

Exclusion Management
12-95
 // and a bit-select of bit [0][1] of the MDA can be excluded as:
// "Toggle a2 [0][1] "reg [3:0]a2[3:0]" "
//
// (b) Half toggles may also be excluded, by specifying the toggle
// after the keyword 'Toggle'.
// For e.g.,
// "Toggle 0to1 a1 [1:0] "reg a1[3:0]" "
// OR
// "Toggle 1to0 a1 [1:0] "reg a1[3:0]" ")
//========================================================================

// CHECKSUM: "2611468360 2090381708"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t1
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:18"
// Toggle a "reg a"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:18"
// Toggle b "reg b"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:19"
// Toggle a1 "reg a1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:19"
// Toggle b1 "reg b1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:19"
// Toggle c1 "reg c1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:20"
// Toggle z "reg z"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:21"
// Toggle w "net w"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:22"
// Toggle m "reg m[1:0]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:22"
// Toggle n "reg n[1:0]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:23"
// Toggle p "reg [3:0]p[3:0]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:24"
// Toggle q "reg [3:0]q[3:0]"

// CHECKSUM: "2611468360 2090381708"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t2
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:18"
// Toggle a "reg a"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:18"
// Toggle b "reg b"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:19"
// Toggle a1 "reg a1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:19"
// Toggle b1 "reg b1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:19"
// Toggle c1 "reg c1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:20"
// Toggle z "reg z"

Exclusion Management
12-96
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:21"
// Toggle w "net w"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:22"
// Toggle m "reg m[1:0]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:22"
// Toggle n "reg n[1:0]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:23"
// Toggle p "reg [3:0]p[3:0]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:24"
// Toggle q "reg [3:0]q[3:0]"

// CHECKSUM: "4211721852 1456370658"

//
// ANNOTATION: "ModuleName: top"
// INSTANCE: top
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:2"
// Toggle x "reg x[3:1]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:2"
// Toggle y "reg y[3:1]"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:2"
// Toggle z "reg z[3:1]"

fullexclude_module.tgl
In a fullexclude_module.tgl file, the header and the format of
dumping remains same as that of the fullexclude.tgl file, but it
contains exclusion entries of all the excludable objects for toggle
coverage at module level. You can edit this file to exclude the objects
for toggle coverage at the module level (for all instances of the
module).

Exclusion Management
12-97
 Full Exclusion Files for Condition Coverage
You can use the -dump full_exclusions [cond] URG option
to dump fullexclude.cond and fullexclude_module.cond
exclusion files.

fullexclude.cond File
The fullexclude.cond file includes all the excludable objects for
condition coverage. To exclude specific conditions or condition
vectors from the condition coverage report, uncomment the
corresponding exclusion entry in the fullexclude.cond file.

Example 12-8 illustrates the fullexclude.cond file.

Example 12-8 fullexclude.cond File

fullexclude.cond:
//========================================================================
// This file contains the Excludable objects for Condition coverage.
// Generated By User: xxxxxx
// Format Version: 2
// Date: Tue Jun 18 03:16:08 2013
// ExclMode: default
// Version: I-2014.03-Beta0
// Usage:
// (i) For each instance, the following is dumped:
// <Module-checksum> <Metric-checksum>
// <ANNOTATION containing Module-name>
// <Instance/Module-name>
// <ANNOTATION containing source-info for Condition 1>
// <Exclusion-info for Condition 1>
// < Exclusion-info for Condition 1 vector 1>
// ...
// < Exclusion-info for Condition 1 vector k1>
// <ANNOTATION containing source-info for Condition 2>
// < Exclusion-info for Condition 2>
// < Exclusion-info for Condition 2 vector1>
// ...
// ...
// <ANNOTATION containing source-info for Condition n>
// < Exclusion-info for Condition n>
// < Exclusion-info for Condition n vector 1>
// ...
// < Exclusion-info for Condition n vector kn>
// (ii) Each Condition's exclusion-info is of the form:
// Condition <condition-id> "<condition-checksum>" "<condition-
// signature>" [(<vector-signature>)]

Exclusion Management
12-98
// where, Condition Signature: "(<condition>) <condition-width>
// <bit-id>"
// (Here, <bit-id> is '-1' when it represents the full condition.)
// and,
// Vector Signature: <vector-id> "<vector>"
// For e.g.,
// if a condition's exclusion-info is:
// // Condition 3 "4094674079" "(m | n) 2 1" (2 "01")
// then,
// condition-id: 3
// condition-checksum: "4094674079"
// condition-signature: "(m | n) 2 1"
// condition: (m | n)
// condition-width: 2 (as both m, n are 2 bit vectors)
// bit-id: 1 (as the exclusion is for bit 1 of condition m|n)
// vector-signature: (2 "01")
// vector-id: 2
// vector: "01"
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option
// '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick
// reference.
// It can be edited by users to add their own annotations. Users
// can as well delete the line containing the annotation.
// (NOTE:
// This file will be overwritten if '-dump full_exclusions' is
// enabled again.)
//========================================================================

// CHECKSUM: "2611468360 3556602004"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t1
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:34"
// Condition 1 "52726451" "(a && b) 1 -1"
// Condition 1 "52726451" "(a && b) 1 -1" (1 "01")
// Condition 1 "52726451" "(a && b) 1 -1" (2 "10")
// Condition 1 "52726451" "(a && b) 1 -1" (3 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Condition 2 "4094674079" "(m | n) 2 -1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Condition 4 "4094674079" "(m | n) 2 0"
// Condition 4 "4094674079" "(m | n) 2 0" (1 "00")
// Condition 4 "4094674079" "(m | n) 2 0" (2 "01")
// Condition 4 "4094674079" "(m | n) 2 0" (3 "10")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Condition 3 "4094674079" "(m | n) 2 1"
// Condition 3 "4094674079" "(m | n) 2 1" (1 "00")
// Condition 3 "4094674079" "(m | n) 2 1" (2 "01")
// Condition 3 "4094674079" "(m | n) 2 1" (3 "10")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:41"
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1"
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1" (1 "00")
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1" (2 "01")
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1" (3 "10")

Exclusion Management
12-99
 // ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:41"
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1"
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (1 "00")
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (2 "01")
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (3 "10")
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (4 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:27"
// Condition 7 "2290113809" "(a ? 1'b1 : 1'b0) 1 -1"
// Condition 7 "2290113809" "(a ? 1'b1 : 1'b0) 1 -1" (1 "0")
// Condition 7 "2290113809" "(a ? 1'b1 : 1'b0) 1 -1" (2 "1")

// CHECKSUM: "2611468360 3556602004"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t2
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:34"
// Condition 1 "52726451" "(a && b) 1 -1"
// Condition 1 "52726451" "(a && b) 1 -1" (1 "01")
// Condition 1 "52726451" "(a && b) 1 -1" (2 "10")
// Condition 1 "52726451" "(a && b) 1 -1" (3 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Condition 2 "4094674079" "(m | n) 2 -1"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Condition 4 "4094674079" "(m | n) 2 0"
// Condition 4 "4094674079" "(m | n) 2 0" (1 "00")
// Condition 4 "4094674079" "(m | n) 2 0" (2 "01")
// Condition 4 "4094674079" "(m | n) 2 0" (3 "10")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:36"
// Condition 3 "4094674079" "(m | n) 2 1"
// Condition 3 "4094674079" "(m | n) 2 1" (1 "00")
// Condition 3 "4094674079" "(m | n) 2 1" (2 "01")
// Condition 3 "4094674079" "(m | n) 2 1" (3 "10")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:41"
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1"
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1" (1 "00")
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1" (2 "01")
// Condition 5 "342519691" "((a1 ^ b1) | c1) 1 -1" (3 "10")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:41"
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1"
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (1 "00")
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (2 "01")
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (3 "10")
// Condition 6 "1274958896" "(a1 ^ b1) 1 -1" (4 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:27"
// Condition 7 "2290113809" "(a ? 1'b1 : 1'b0) 1 -1"
// Condition 7 "2290113809" "(a ? 1'b1 : 1'b0) 1 -1" (1 "0")
// Condition 7 "2290113809" "(a ? 1'b1 : 1'b0) 1 -1" (2 "1")

// CHECKSUM: "4211721852 387279596"

//
// ANNOTATION: "ModuleName: top"
// INSTANCE: top
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:9"
// Condition 1 "149338110" "(x & y) 3 -1"

Exclusion Management
12-100
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:9"
// Condition 4 "149338110" "(x & y) 3 0"
// Condition 4 "149338110" "(x & y) 3 0" (1 "01")
// Condition 4 "149338110" "(x & y) 3 0" (2 "10")
// Condition 4 "149338110" "(x & y) 3 0" (3 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:9"
// Condition 3 "149338110" "(x & y) 3 1"
// Condition 3 "149338110" "(x & y) 3 1" (1 "01")
// Condition 3 "149338110" "(x & y) 3 1" (2 "10")
// Condition 3 "149338110" "(x & y) 3 1" (3 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:9"
// Condition 2 "149338110" "(x & y) 3 2"
// Condition 2 "149338110" "(x & y) 3 2" (1 "01")
// Condition 2 "149338110" "(x & y) 3 2" (2 "10")
// Condition 2 "149338110" "(x & y) 3 2" (3 "11")
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:11"
// Condition 5 "492599446" "(y || z) 1 -1"
// Condition 5 "492599446" "(y || z) 1 -1" (1 "00")
// Condition 5 "492599446" "(y || z) 1 -1" (2 "01")
// Condition 5 "492599446" "(y || z) 1 -1" (3 "10")

fullexclude_module.cond File
In a fullexclude_module.cond file, the header and the format
of dumping remains same as that of the fullexclude.cond file,
but it contains exclusion entries of all the excludable objects for
condition coverage at module level. You can edit this file to exclude
the objects for condition coverage at the module level (for all
instances of the module).

Exclusion Management
12-101
 Full Exclusion Files for Branch Coverage
You can use the -dump full_exclusions[branch] URG to
dump fullexclude.branch and
fullexclude_module.branch exclusion files.

fullexclude.branch File
The fullexclude.branch file includes all the excludable objects
for the branch coverage. To exclude any specific branch or branch
vectors from the branch coverage report, uncomment the
corresponding exclusion entries in the fullexclude.branch file.

Example 12-9 illustrates the fullexclude.branch file.

Example 12-9 fullexclude.branch File

//========================================================================
// This file contains the Excludable objects for Branch coverage.
// Generated By User: xxxxxx
// Format Version: 2
// Date: Tue Jun 18 03:16:08 2013
// ExclMode: default
// Version: I-2014.03-Beta0
// Usage:
// (i) For each instance, the following is dumped:
// <Module-checksum> <Metric-checksum>
// <ANNOTATION containing Module-name>
// <Instance/Module-name>
// <ANNOTATION containing source-info for Branch 0>
// <Exclusion-info for Branch 0>
// <Exclusion-info for Branch 0 vector 1>
// ...
// <Exclusion-info for Branch 0 vector k1>
// <ANNOTATION containing source-info for Branch 1>
// <Exclusion-info for Branch 1>
// <Exclusion-info for Branch 1 vector 1>
// ...
// ...
// <ANNOTATION containing source-info for Branch n>
// <Exclusion-info for Branch n>
// <Exclusion-info for Branch n vector 1>
// ...
// <Exclusion-info for Branch n vector kn>
// (ii) Each branch's exclusion-info is of the form:
// Branch <branch-id> "<branch-checksum>" "<branch-signature>"
// [(<vector-id>) "<vector-signature>"]
// For e.g.,

Exclusion Management
12-102
// if a branch's exclusion-info is:
// // Branch 1 "1966633406" "(a && b)" (1) "(a && b) 0,1"
// then,
// branch-id: 1
// branch-checksum: "1966633406"
// branch-signature: "(a && b)"
// vector-id: (1)
// vector-signature: "(a && b) 0,1"
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option
// '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick
// reference.
// It can be edited by users to add their own annotations. Users
// can as well delete the line containing the annotation.
//
// (NOTE:
// This file will be overwritten if '-dump full_exclusions' is
// enabled again.)
//========================================================================

// CHECKSUM: "2611468360 2484196152"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t1
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:27"
// Branch 0 "2538409013" "a"
// Branch 0 "2538409013" "a" (0) "a 1"
// Branch 0 "2538409013" "a" (1) "a 0"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:34"
// Branch 1 "1966633406" "(a && b)"
// Branch 1 "1966633406" "(a && b)" (0) "(a && b) 1,-"
// Branch 1 "1966633406" "(a && b)" (1) "(a && b) 0,1"
// Branch 1 "1966633406" "(a && b)" (2) "(a && b) 0,0"

// CHECKSUM: "2611468360 2484196152"

//
// ANNOTATION: "ModuleName: test"
// INSTANCE: top.t2
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:27"
// Branch 0 "2538409013" "a"
// Branch 0 "2538409013" "a" (0) "a 1"
// Branch 0 "2538409013" "a" (1) "a 0"
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:34"
// Branch 1 "1966633406" "(a && b)"
// Branch 1 "1966633406" "(a && b)" (0) "(a && b) 1,-"
// Branch 1 "1966633406" "(a && b)" (1) "(a && b) 0,1"
// Branch 1 "1966633406" "(a && b)" (2) "(a && b) 0,0"

// CHECKSUM: "4211721852 931724091"

//
// ANNOTATION: "ModuleName: top"
// INSTANCE: top
//

Exclusion Management
12-103
 // ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/test.v, LineNumber:9"
// Branch 0 "14865438" "(x & y)"
// Branch 0 "14865438" "(x & y)" (0) "(x & y) 1,-"
// Branch 0 "14865438" "(x & y)" (1) "(x & y) 0,1"
// Branch 0 "14865438" "(x & y)" (2) "(x & y) 0,0"

fullexclude_module.branch File
In a fullexclude_module.branch file, the header and the
format of dumping remains same as that of the
fullexclude.branch file, but it contains exclusion entries of all
the excludable objects for branch coverage at module level. You can
edit this file to exclude the objects for branch coverage at the module
level (for all the instances of the module).

Full Exclusion Files for FSM Coverage

You can use the -dump full_exclusions [fsm] URG option,
to dump fullexclude.fsm and fullexclude_module.fsm
exclusion files.

fullexclude.fsm File
The fullexclude.fsm file includes all the excludable objects of
FSM coverage – states and transitions. To exclude any specific
state, transition of a FSM or the whole FSM from the FSM coverage
report, uncomment the corresponding exclusion entries in the
fullexclude.fsm file.

Example 12-10 is the design used to describe the FSM metric.

Example 12-10 Design Used to Describe the FSM Metric

1 module top;
2 reg x, y, z;
3
4 fsm1 fsmOne();
5 fsm2 fsmTwo();

Exclusion Management
12-104
6 endmodule
7
8 module fsm1();
9 reg clk;
10 reg [9:0] current;
11 reg [9:0] next;
12 integer j;
13
14 initial begin
15 current=10'b0000000001;
16 clk = 0;
17 #20 $finish();
18 end
19
20 always #1 clk = ~clk;
21
22 always @(posedge clk)begin
23 case (1'b1)
24 current [0] : next=2;
25 current [1] : next=4;
26 current [2] : next=8;
27 current [8] : next=2;
28 endcase
29 current=next;
30 end
31 endmodule
32
33 module fsm2 ();
34 wire clk,in;
35 reg [1:0] state,next;
36
37 parameter idle = 2'b00, first = 2'b01,
38 second = 2'b10, third = 2'b11;
39
40 initial begin
41 state=idle;
42 next=idle;
43 end
44
45 always @ in
46 begin

Exclusion Management
12-105
 47 next = state; // by default hold
48 case (state)
49 idle : if (in) next = first;
50 first : if (in) next = second;
51 second : if (in) next = third;
52 third : if (in) next = idle;
53 endcase
54 end
55
56 always @ (posedge clk)
57 state=next;
58
59 endmodule

Example 12-11 illustrates the fullexclude.fsm file.

Example 12-11 fullexclude.fsm File

//========================================================================
// This file contains the Excludable objects for Fsm coverage.
// Generated By User: xxxxxx
// Format Version: 2
// Date: Tue Jun 18 03:16:08 2013
// ExclMode: default
// Version: I-2014.03-Beta0
// Usage:
// (i) For each instance, the following is dumped:
// <Module-checksum> <Metric-checksum>
// <ANNOTATION containing Module-name>
// <Instance/Module-name>
// <ANNOTATION containing source-info for Fsm 1>
// <Exclusion-info for Fsm 1>
// <Exclusion-info for Fsm 1>
// <Exclusion-info for State 1>
// <Exclusion-info for State 2>
// ...
// <Exclusion-info for State V_1>
// <Exclusion-info for Transition 1>
// <Exclusion-info for Transition 2>
// ...
// <Exclusion-info for Transition E_1>
// <ANNOTATION containing source-info for Fsm 2>
// <Exclusion-info for Fsm 2>
// ...
// ...
// <ANNOTATION containing source-info for Fsm n>
// <Exclusion-info for Fsm n>
// ...
// <Exclusion-info for State V_n>
// ...
// <Exclusion-info for Transition E_k>

Exclusion Management
12-106
// (ii) The exclusion-info for fsm is of the form:
// Fsm <fsm-name> "<fsm-checksum>"
// The exclusion-info for state is of the form:
// State <state-name> "<state-signature>"
// The exclusion-info for transition is of the form:
// Transition <transition-name> "<transition-signature>"
// For e.g.,
// if an fsm's exclusion-info is:
// // Fsm current "4059198254"
// // State 'h1 "1"
// // State 'h2 "2"
// // Transition 'h1->'h2 "1->2"
// then,
// fsm-name: current
// fsm-checksum: "4059198254"
// state-name: 'h1
// state-signature: "1"
// transition-name: 'h1->'h2
// transition-signature: "1->2"
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option
// '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick
// reference.
// It can be edited by users to add their own annotations. Users
// can as well delete the line containing the annotation.
// (NOTE:
// This file will be overwritten if '-dump full_exclusions' is
// enabled again.)
//========================================================================

// CHECKSUM: "955169489 4059198254"

//
// ANNOTATION: "ModuleName: fsm1"
// INSTANCE: top.fsmOne
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/testFsm.v, LineNumber:30"
// Fsm current "4059198254"
// State 'h1 "1"
// State 'h2 "2"
// State 'h4 "4"
// State 'h8 "8"
// State 'h100 "256"
// Transition 'h1->'h2 "1->2"
// Transition 'h2->'h4 "2->4"
// Transition 'h4->'h8 "4->8"
// Transition 'h100->'h2 "256->2"

// CHECKSUM: "3628627142 1133352179"

//
// ANNOTATION: "ModuleName: fsm2"
// INSTANCE: top.fsmTwo
//
// ANNOTATION: "FileName: /remote/xxxx/yyyy/zzzz/testFsm.v, LineNumber:58"
// Fsm state "1133352179"
// Fsm state "1133352179"
// State idle "0"

Exclusion Management
12-107
 // State first "1"
// State second "2"
// State third "3"
// Transition idle->first "0->1"
// Transition first->second "1->2"
// Transition second->third "2->3"
// Transition third->idle "3->0"
The exclusions that are possible using a fullexclude.fsm file
are,

• “State Exclusion”
• “Transition Exclusion”
• “FSM Exclusion”

State Exclusion
In Example 12-11, to exclude the state first of the FSM state of
the instance top.fsmTwo, uncomment the following lines:

// Fsm state "1133352179"

// State first "1"

Transition Exclusion
In Example 12-11, to exclude the transition first->second of the
FSM state of the instance top.fsmTwo, uncomment the following
lines:

// Fsm state "1133352179"

// Transition first->second "1->2"

FSM Exclusion
In Example 12-11, to exclude the whole FSM of the FSM state of
the instance top.fsmTwo, uncomment the following line:

// Fsm state "1133352179"

Exclusion Management
12-108
 fullexclude_module.fsm File
In a fullexclude_module.fsm file, the header and the format of
dumping remains same as that of the fullexclude.fsm file, but it
contains exclusion entries of all the excludable objects for FSM
coverage at the module level. You can edit this file to exclude objects
for FSM coverage at the module level (for all instances of the
module).

Full Exclusion Files for Group Coverage

You can use the -dump full_exclusions group URG option to
dump fullexclude.tb_inst and fullexclude.tb_def
exclusion files.

Example 12-12 is the design source code for which group coverage
is monitored.

Example 12-12 Design Used to Describe the Group Metric

test.v

module mod;
int v,u,r,a,b;
reg x, y, z;
covergroup cg(int a, int b);
option.auto_bin_max=b;
coverpoint v;
coverpoint u{
bins sabin_u = {6,7,8} iff(a>0);
}
coverpoint r{
bins sabin_r = {1,2,3};
}
cross u,v{
bins b = binsof(u) iff(a);
bins b1 = binsof(v) iff(!a);
}
option.per_instance = 1;

Exclusion Management
12-109
 endgroup

covergroup cov(int a);

coverpoint a{

bins b = {2,3};
}

option.per_instance = 1;
endgroup
cg cg1;
cg cg2;
cov cov1;
cov cov2;
initial begin
a=2;b=3;
cg1 = new(1, 64);
cg2 = new(0, 32);
v = 2;
cg1.sample();
u = 6;
cg1.sample();
cov1 = new(4);
cov1.sample();
cov2 = new(5);
cov2.sample();
end

endmodule

fullexclude.tb_inst file
The fullexclude.tb_inst file includes all the exclusion entries
for all the instances of all the covergroups along with their
coverpoints, crosses and bins. These exclusion entries will be in
their commented form. To exclude any specific entry from the
functional coverage report, uncomment the corresponding exclusion
entries in the fullexclude.tb_inst file.

Example 12-13 illustrates the fullexclude.tb_inst file.

Exclusion Management
12-110
Example 12-13 fullexclude.tb_inst File
//==================================================
// // This file contains the Excludable objects for group coverage
// Generated By User: xyz
// Format Version: 2
// Date: Thu May 29 23:53:54 2014
// ExclMode: default
// Version: J-2014.12-Beta0
// Usage:
// (i) For each Definition, the following is dumped:
// <Definition-checksum> <Shape-checksum>
// <ANNOTATION containing Covergroup's file name and line number>
// <Definition name of covergroup>
// <Coverpoint/Cross List>
// <Name of coverpoint/cross>
// <bins keyword Bins Name List>
// For e.g.,
// CHECKSUM: "1529104392 4145108059"
// ANNOTATION: "test.v, LineNumber:6"
// covergroup mod::cg::SHAPE{b=64,Guard_ON(u.sabin_u)}
// coveritem "v","cg_cross"
// coveritem v
// bins sabin_v
// coveritem cg_cross
// bins b_cross1, b1_cross2
// (ii) For each instance, the following is dumped:
// <Definition-checksum> <Shape-checksum>
// <Covergroup Instance name List>
// <Definition-checksum> <Shape-checksum>
// <ANNOTATION containing Covergroup Instance's file name and line number>
// <Instance name of covergroup>
// <Coverpoint/Cross List>
// <Name of coverpoint/cross>
// <bins keyword Bins Name List>
// For e.g.,
// CHECKSUM: "1529104392 2053810295"
// covergroup mod.cg2, mod.cg1
// CHECKSUM: "1529104392 2053810295"
// ANNOTATION: "test.v, LineNumber:25"
// covergroup mod.cg1
// coveritem "v","cg_cross"
// coveritem v
// bins sabin_v
// coveritem cg_cross
// bins b_cross1, b_cross2
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick reference.
// It can be edited by users to add their own annotations. Users can as well
// delete the line containing the annotation.
// (NOTE:
// This file will be overwritten if '-dump full_exclusions' is enabled again.)
//==================================================
// CHECKSUM: "1529104392 114556960"
// ANNOTATION: "/remote/xxxxx/xxxx/dump_full_exclusion/Group/test.v, 4"
// covergroup mod.cg1
// CHECKSUM: "1529104392 114556960"
// ANNOTATION: "test.v, 32"
// covergroup mod.cg1
// coveritem "v", "u", "r", "cg_cc"
// coveritem "v"
// bins auto[-2147483648:-2080374785]-auto[2080374784:2147483647]
// coveritem "u"

Exclusion Management
12-111
 // bins "sabin_u"
// coveritem "r"
// bins "sabin_r"
// coveritem "cg_cc"
// bins "b", "b1"
// CHECKSUM: "1529104392 1386083047"
// ANNOTATION: "/remote/xxxxx/xxxx/dump_full_exclusion/Group/test.v, 4"
// covergroup mod.cg2
// CHECKSUM: "1529104392 1386083047"
// ANNOTATION: "test.v, 33"
// covergroup mod.cg2
// coveritem "v", "u", "r", "cg_cc"
// coveritem "v"
// bins auto[-2147483648:-2013265921]-auto[2013265920:2147483647]
// coveritem "u"
// bins "sabin_u"
// coveritem "r"
// bins "sabin_r"
// coveritem "cg_cc"
// bins "b", "b1"
// CHECKSUM: "1712407508 2539924183"
// ANNOTATION: "/remote/xxxxx/xxxx/dump_full_exclusion/Group/test.v, 20"
// covergroup mod.cov2, mod.cov1
// CHECKSUM: "1712407508 2539924183"
// ANNOTATION: "test.v, 40"
// covergroup mod.cov2
// coveritem "a"
// coveritem "a"
// bins "b"
// CHECKSUM: "1712407508 2539924183"
// ANNOTATION: "test.v, 38"
// covergroup mod.cov1
// coveritem "a"
// coveritem "a"
// bins "b"

fullexclude.tb_def file
In a fullexclude.tb_def file, the header and the format of
dumping remains same as that of the fullexclude.tb_inst file,
but it contains exclusion entries of all the excludable objects for all
the shapes/definitions of covergroups along with their coverpoints as
shown in Example 12-14.

Example 12-14 fullexclude.tb_def file Without the Header

//================================================
// CHECKSUM: "1529104392 114556960"
// ANNOTATION: "/remote/xxxx/xxx/dump_full_exclusion/Group/test.v, 4"
// covergroup mod::cg::SHAPE{b=64}
// coveritem "v", "u", "r", "cg_cc"
// coveritem "v"
// bins auto[-2147483648:-2080374785]-auto[2080374784:2147483647]
// coveritem "u"
// bins "sabin_u"
// coveritem "r"
// bins "sabin_r"

Exclusion Management
12-112
 // coveritem "cg_cc"
// bins "b", "b1"
// CHECKSUM: "1529104392 1386083047"
// ANNOTATION: "/remote/xxxx/xxx/dump_full_exclusion/Group/test.v, 4"
// covergroup mod::cg::SHAPE{b=32}
// coveritem "v", "u", "r", "cg_cc"
// coveritem "v"
// bins auto[-2147483648:-2013265921]-auto[2013265920:2147483647]
// coveritem "u"
// bins "sabin_u"
// coveritem "r"
// bins "sabin_r"
// coveritem "cg_cc"
// bins "b", "b1"
// CHECKSUM: "1712407508 2539924183"
// ANNOTATION: "/remote/xxxx/xxx/dump_full_exclusion/Group/test.v, 20"
// covergroup mod::cov
// coveritem "a"
// coveritem "a"
// bins "b"

For low power covergroups, the fullexclude_lp.tb_def file is

dumped containing the objects of all LP instrumented covergroups
as shown in Example 12-15.

Example 12-15 fullexclude_lp.tb_def File

//==================================================
//ANNOTATION: "/remote/vgxyz/xxxxxx/Project/covg_disable_cg/
test_exlude_LP_COV/test.upf, 25"
// CHECKSUM: "1761881426 1471011507"
// covergroup testbench/top/Iff_switch.switch_state.inst
// coveritem "states", "transitions"
// coveritem "states"
// bins FF_OFF, FF_ON, INVALID
// coveritem "transitions"
// bins FF_OFF => FF_ON, FF_ON => FF_OFF, FF_OFF =>
//INVALID_illegal, FF_ON => INVALID_illegal, INVALID => FF_OFF_illegal,
//INVALID => FF_ON_illegal

Exclusion Management
12-113
 Full Exclusion Files for Assertion Coverage
You can use the -dump full_exclusions assert URG option
to dump fullexclude.assert and
fullexclude_module.assert exclusion files.

Example 12-16 is the design source code for which assertion

coverage is monitored.

Example 12-16 Design Used to Describe the Assertion Coverage Metric

assert_test.v

module bot;
int x,y,z,w;
reg clk;

function bit f (int a, int b);

a1: assert #0 (a == b);
endfunction

always_comb begin : b1
f(x,y);
end

always_comb begin : b2
f(z,w);
end

initial begin
base_rule1: assert property (@clk x) $display("%m, passing");
else $display("%m, failed");
end
endmodule

module top;
bot b1();
bot b2();
endmodule

Exclusion Management
12-114
 fullexclude.assert File

The fullexclude.assert file includes the instance level

excludable objects for assertion coverage. To exclude any
excludable assertion objects of all the module instances,
uncomment the corresponding exclusion entry in the
fullexclude.assert file.

Example 12-17 illustrates the fullexclude.assert file.

Example 12-17 fullexclude.assert File

//==================================================
// This file contains the Excludable objects for assertion coverage
// Generated By User: xyz
// Format Version: 2
// Date: Tue Jun 24 07:24:48 2014
// ExclMode: default
// Version: J-2014.12-Beta0
// Usage:
// (i) For instance level assertions, the following is dumped :
// <Module-checksum>
// <ANNOTATION: Module name>
// <INSTANCE: Name of module instance>
// <ANNOTATION: File name and line number>
// <Assert assertion name "assertion type">
// For e.g.,
// CHECKSUM: "4150909837"
// ANNOTATION: "ModuleName: bot"
// INSTANCE: top.b1
// ANNOTATION: "assert_test.v, LineNumber:6"
// Assert base_rule1 "assertion"
// (ii) For module level, the following is dumped:
// <Module-checksum>
// <MODULE: Name of module>
// <ANNOTATION: File name and line number>
// <Assert assertion name "assertion type"
// For e.g.,
// CHECKSUM: "4150909837"
// MODULE: bot
// ANNOTATION: "assert_test.v, LineNumber:6"
// Assert f.a1 "assertion"
// (iii) Copy this file to a new file, uncomment necessary exclusions in
// the new file, and pass the new file as an argument to the option '-elfile'.
// (iv) The ANNOTATION containing source-info is for user's quick reference.
// It can be edited by users to add their own annotations. Users can as well
// delete the line containing the annotation.
// (NOTE:
// This file will be overwritten if '-dump full_exclusions' is enabled again.)
//==================================================
// CHECKSUM: "4150909837"
// INSTANCE: top.b1
// ANNOTATION: "FileName: assert_test.v, LineNumber: 18"
// Assert base_rule1 "assertion"
// ANNOTATION: "FileName: assert_test.v, LineNumber: 6"
// Assert f.a1 "assertion"

Exclusion Management
12-115
 // CHECKSUM: "4150909837"
// INSTANCE: top.b2
// ANNOTATION: "FileName: assert_test.v, LineNumber: 18"
// Assert base_rule1 "assertion"
// ANNOTATION: "FileName: assert_test.v, LineNumber: 6"
// Assert f.a1 "assertion"

fullexclude_module.assert

In a fullexclude_module.assert file, the header and the

format of dumping remains the same as that of the
fullexclude.assert file, but it contains exclusion entries of all
the excludable objects for assertion coverage at module level as
shown in Example 12-18. You can edit this file to exclude the objects
for assertion coverage at module level (for all instances of the
module).

Example 12-18 fullexclude_module.assert file Without the Header

//==================================================
// CHECKSUM: "4150909837"
// MODULE: bot
// ANNOTATION: "FileName: assert_test.v, LineNumber: 18"
// Assert base_rule1 "assertion"
// ANNOTATION: "FileName: assert_test.v, LineNumber: 6"
// Assert f.a1 "assertion"

Exclusion Management
12-116
Managing Exclusions in UCAPI

UCAPI allows you to mark coverage objects as excluded, which

means they are ignored when computing the covdbCoverable and
covdbCovered properties of handles - they are excluded from the
computation of the coverage score. The following sections describe
how objects and regions can be excluded in UCAPI.

• “Excluding Coverage Objects Using Hierarchy Exclusion Files”

• “Excluding Coverage Objects Using Object Handles”
• “Default Versus Strict Exclusion in UCAPI”
• “Using Report-Time Exclusion”
• “Saving Exclusions in UCAPI”
• “Computing Checksum for Coverage Metrics”

Excluding Coverage Objects Using Hierarchy Exclusion

Files

UCAPI supports hierarchy exclusion files, which allow you to specify

source regions, design hierarchies, and some individual objects for
exclusion or explicit inclusion for coverage. For example, a hierarchy
exclusion file with the following content would exclude the sub-
hierarchy of the design rooted at the path top.d1:

-tree top.d1
See the VCS Coverage Metrics User Guide for the complete
description of the hierarchy exclusion file syntax.

Exclusion Management
12-117
 Hierarchy exclusion files are loaded using the covdb_loadmerge
function with an already-loaded design handle, as follows:

covdb_loadmerge(covdbHierFile, designHdl, filename);

Excluding Coverage Objects Using Object Handles

Applications may set the covdbExcludedAtReportTime flag

using the covdb_set function, as follows:

status = covdb_get(obj, region, test, covdbCovStatus);

status = status |= covdbStatusExcludedAtReportTime;
covdb_set(obj, region, test, covdbCovStatus, status);
When an object is marked excluded, it no longer contributes its
covdbCoverable (or covdbCovered) count to the count of any
containing object or region. For example, if you exclude a statement
in a basic block, it lowers the covdbCoverable count of the basic
block by 1.

Exclusion bits set using the covdb_set function are not saved to
the main UCAPI database or to test files – they are saved to a
separate exclusion file. Exclusion files are saved using the
covdb_save_exclude_file function, as follows:

covdb_save_exclude_file (testHdl, “myexcludes.el”, “w”);

Either a design handle or a test handle must be passed as the first

argument to the covdb_save_exclude_file command. If the first
argument is a test handle, then all exclusions of non-test-qualified
objects are saved to the file, along with any exclusions of objects in
test-qualified regions that appear in that test. If the first argument is
a design handle, then only exclusions of non-test-qualified objects
are saved.

Exclusion Management
12-118
Exclusion files can be saved with mode w to write a new file,
overwriting the existing or with mode a to append the exclusion data
into an existing file.

You can load a previously-saved exclusion file using

covdb_load_exclude_file, as follows:

covdb_load_exclude_file(testHdl, “projectexcl.el”);

The covdb_unload_exclusion function removes all

covdbExcludedAtReportTime bits from all coverable objects in
the design. The syntax is as follows:

covdb_unload_exclusion(designHdl);

Default Versus Strict Exclusion in UCAPI

UCAPI has two exclusion modes - Default and Strict, similar to DVE.
In Default mode,youcan exclude object regardless of whether it is
covered or not.

In strict mode, excluding a covered object is illegal. If you mark a

container for exclusion, only the uncovered objects in that container
will be excluded. If a region, such as a module, is excluded, only the
uncovered objects throughout that region will be excluded.

The exclusion mode can be selected using the covdb_configure

function. To change the mode from default to strict, use the following
command:

covdb_configure(designHdl, covdbExcludeMode, "strict");

Exclusion Management
12-119
 In strict mode, UCAPI keeps track of the covered objects that were
in regions or containers that were excluded - theseobjects are called
attempted exclude objects. The list of such objects can be saved to
a file using the covdb_save_attempted_file function, as
follows:

covdb_save_attempted_file(mytestHdl, "attempts.txt", "w");

Exclusion files can be saved with mode w to write a new file,

overwriting the existing or with mode a to append the exclusion data
into an existing file.

Using Report-Time Exclusion

The coverage report-time exclusion provides granularity of exclusion

file version check from file level to module or metric-variant level.

The following additional information is available in the format of the

exclusion file created by the UCAPI function
covdb_save_exclude_file:

• Module or instance-wise positioning of a design and its metric-

variant checksums in the generated file
• CHECKSUMinformation

Exclusion Management
12-120
Saving Exclusions in UCAPI

When exclusion are saved into an exclusion file, the checksum

information of an excluded scope, variant, or instance and the
corresponding exclusions are dumped together. This is true when
saving is called in append mode as well, even when the file to which
exclusions are appended is an exclusion file generated through a
previous release. In this case, the file takes a hybrid format. Version
checks of such mixed-formatted exclusion files also follow a hybrid
approach. First, all previous release style checksums are read and if
there is a mismatch, all exclusions that are saved through the
previous release (which means, all scopes that do not come with
CHECKSUM: …) are not loaded. If the checksums match, then all of
these exclusions are loaded. For the rest, which are generated with
the current release (which means, scopes that come with
CHECKSUM:...), checksums are matched scope by scope and
exclusions are applied wherever checksums match.

Computing Checksum for Coverage Metrics

The basic process of using the checksum for exclusion purpose is

mostly the same for different coverage metrics.

For line, condition, branch and FSM metrics, when an exclusion file
is loaded into DVE, the checksum is compared with the checksum of
coverage objects in the database.

In case of single match, the object is excluded directly. For multiple

matches, exclusions with matching signatures are flagged for
review. If there is no match, the exclusion is flagged as unmappable.

Exclusion Management
12-121
 Calculating Checksum for Condition Coverage
The checksum used for a top-level condition is that condition itself.
But if the condition is nested inside other code, the enclosing
conditions are also taken into consideration which calculating the
checksum.

Signature in Elfile for Condition Metric

Consider the following code, which contains two conditional
expressions:

108: if (stall || (x_not && y_tot))

109: n_state = five;
110: else if (qtr && !dim && !nck)

Both of these expressions contain excluded vectors. Also, the

exclusion on line 108 is annotated with this exclusion for testing.

The exclusion file contains the following information:

CHECKSUM: "1551008188 1009698005"

INSTANCE: test_jukebox.st0.coin1
Condition 5 "3829769986" "(stall || (x_not && y_tot)) 1 -1"
ANNOTATION: "Condition Excluded"
Condition 7 "703447148" "(((!qtr)) && ((!dim)) && ((!nck)))
1 -1"
Note:
The signature that mentions Condition 7 is from line 110 and
the signature that mentions Condition 5 is from line 108. Both
exclusions are in the instance test_jukebox.st0.coin1.

If you change an excluded expression in the design, review is

triggered. For example, if you change stall to kp_hold in the
expression on line 108 would change as follows:

Exclusion Management
12-122
108: if (kp_hold || (x_not && y_tot))

You then recompile, re-simulate, and load the new coverage

database into DVE along with the exclusion file. As the checksum is
different for test_jukebox.st0.coin1, a review of the
signatures for this instance is required.

The review information appears when you mouse-over an

expression, and it also appears in the console window. The
information in the console window contains:

• The line number of the exclusion in the current design, and

whether the two signatures match or not.
• The signature of the exclusion in the current design (if the two
signatures match, it is not shown).
• The signature of the exclusion from the exclude file.
• The annotation for the exclusion from the exclude file, if any.
The console displays the following expressions:

Current exclusion under review is at Line 108, signatures

mismatch:
Review state:(((!qtr)) && ((!dim)) && ((!nck))): Not reviewed
Signatures match
Signature from the elfile : (((!qtr)) && ((!dim)) &&
((!nck))) 1
Exclusion annotation from the elfile:Condition Excluded

The expression for the second exclusion is not changed, as its

review is triggered by the change of the checksum of that instance.

Exclusion Management
12-123
 An exclusion review of line 110 may seem unnecessary in this
example, but consider that the checksum change occurred because
the signals gtr, dim, or nck were given different assignments in the
code. In this case, a review is important.

Calculating Checksum for Line Coverage

In line coverage The text of the first line of a block is used as its
signature. All the statements in a particular block and the control
structures enclosing that block becomes a part of the checksum
calculation for this block.

Signature in Elfile for Line Metric

VCS Coverage does not check line coverage. Instead, it checks
basic block coverage. A basic block is a collection of statements that
always execute together. For example:

if (kp_hold && (y_tot || x_not))

begin
go = 1; //statement (1)
n_state = idle; //statement (2)
end
In this example, statements (1) and (2) make up a single basic
block. When any statement in a basic block executes, all other
statements are executed as well (by definition). Line coverage only
monitors which basic blocks are covered during simulation.

The signature for an excluded statement for line coverage is the text
of the starting line of the block in the source code.

Multiple basic blocks can appear on a single line of text. In this case,
the signature of an excluded statement still includes the entire
source text of the line.

Exclusion Management
12-124
The checksum is as follows:

CHECKSUM: "1068666273 3477974917"

INSTANCE: test_jukebox.st0.coin1
ANNOTATION: "Line is excluded for testing"
Block 16 "1216171131" "go = 1;"

Calculating Checksum for Toggle Coverage

Toggle exclusions are mapped to objects in the design by signal
names. If no signal exists with the same name in the given region,
the exclusion goes into the unmappable list. If a signal with the same
name does exist, the shape recorded in the exclude file is compared
to the shape of the signal in the design, using the type, size and
bounds of the signal. If the shape is the same, the exclusion is
applied; otherwise, the exclusion is flagged for review.

Signature in Elfile for Toggle Metric

The signature for excluding a signal for toggle coverage is as follows:

<type> <signal_name>[msb:lsb] for vector

<type> <signal_name> for scalar

Example 1

Input in[3:0];
CHECKSUM: "297701905 1142099701"
INSTANCE: memsys_test_top.dut.Umem
ANNOTATION: " Signal Excluded "
Toggle adxStrb "net adxStrb"

The toggle direction is not included in the signature.

Exclusion Management
12-125
 Example 2

input reset,output reg [6:0]led_state,

CHECKSUM: "1416628156 2241958015"

INSTANCE: traffic_tb.u1.u0
Toggle reset "net reset"
Toggle 0to1 reset "net reset"
Toggle 1to0 reset "net reset"
Toggle 0to1 led_state "reg led_state[6:0]"
Toggle 1to0 led_state "reg led_state[6:0]"
ANNOTATION: "vector signal"
Toggle led_state "reg led_state[6:0]"

If there is no signal with the name reset or led_state in the

design, the exclusion goes into unmappable list.

Calculating Checksum for FSM Coverage

All the statements (such as state-name and state-values) in a
particular FSM and the enclosing control structures become a part of
the checksum computation.

Signature in Elfile for FSM Metric

FSM coverage contains the following three types of exclusions:

• Whole FSM
• State
• Transition
The signature for an FSM state exclusion is as follows:

• Name of the FSM current state signal

• Checksum

Exclusion Management
12-126
The signature for an FSM transition exclusion is as follows:

• Name of the FSM current state signal

• Values and names of both states
The following is an example of state and transition exclusion:

CHECKSUM: "3952978018 3449621262"

INSTANCE: dev_tb.d0
ANNOTATION: "Fsm state_new excluded"
Fsm state_new "2485623001"
State idle "1"
State first "2"
State second "4"
Transition idle->first "1->2"
Transition first->idle "2->1"
Transition first->second "2->4"
Transition third->idle "8->1"

FSM exclusions are mapped using the current state signal name and
the names of the states involved. If an exclusion exists for a state
signal that no longer exists, or a state whose name no longer exists,
the exclusion is categorized as unmappable. For example, for
transition third->idle, it should be 8->1, where 8 is the value of
third and 1 is idle.

Exclusion Management
12-127
 Calculating Checksum for Branch Coverage
For branch coverage, all the controlling expressions inside a branch
and enclosing scopes (event expression of always block), if any,
becomes a part of checksum computation.

Signature in Elfile for Branch Metric

The signature information for a whole branch block is as follows:

<the top condition expression>

The signature information associated with a branch is as follows:

<the top condition expression> <branch vector>

Consider the following example:

if(a1==1'b1)
begin
out = a1 && a2;
end
else
begin
if(reset==1)
begin
q=4'b0000;
end
else
q=q+1;
end

Checksum:

CHECKSUM: "3103542204 3423368445"

INSTANCE: traffic_tb.u1.u1
Branch 0 "24436355" "(reset == 1'b1)"

Exclusion Management
12-128
ANNOTATION: "branch excluded for testing"
Branch 0 "24436355" "(reset == 1'b1)" (0) "(reset == 1'b1) 1"

Branch block signature: reset == 1'b1

The signatures for these branches are as follows:

Branch 1:
"24436355" "(reset == 1'b1)" (0) "(reset == 1'b1) 1"

Branch 2:
"24436355" "(reset == 1'b1)" (1) "(reset == 1'b1) 0"

For case switching, <as the separators for case> is used,

as shown in the following example:

case(state)
S0: if(count<4'b1001)
begin
state<=S0;
count<=count+4'b0001;
end

Signature:

signature "(reset == 1'b1)" (1) "(reset == 1'b1) 0,S0

,1,-,-,-,-,-,-"
Note:
With this signature scheme, all changes to the top expressions
are detected and lead to signature mismatches. The disadvantage
is that changes in the structure or inner expressions of the branch
are not detected.

Exclusion Management
12-129
 Calculating Checksum for Assertion Metric
The signature for an assertion exclusion is the name and type
(assertion, cover property, cover sequence) of the assertion.

Signature in Elfile for Assertion Metric

For unnamed assertions, VCS Coverage assigns names using a

counter. If one unnamed assertion is deleted, then it effectively
changes the names of all following unnamed assertions. For
example, if an assertion unnamed$$_3 is excluded in design
version A, then the signature is unnamed$$_3. As it is difficult to
know whether or not to accept the exclusion, it is recommended that
you name the assertions.

Note:
Changes in assertion content are not detected, because they are
not part of the signature.

For example,

A1 : assert property(@(posedge clk) a);

The checksum generated for excluding the assertion in the

exclusion file is as shown in the following example:

CHECKSUM: "3172832887"
INSTANCE: dut
Assert A1 "assertion"

Exclusion Management
12-130
Calculating Checksum for Covergroup Metric
Covergroup bins also contain unique names that are used for
coverage exclusion. The signature of a covergroup bin is its name.
User-defined bins have user-defined names. Automatically created
bins have names generated according to the LRM rules.

Signature in Elfile for Covergroup Metric

Exclusion of entire covergroups and crosses is done by name only

for covergroups and crosses with user-defined labels (ignoring the
lists of bins, and so on).

For example:

covergroup cg;
cover_point_y : coverpoint y;
endgroup

The checksum generated for excluding the covergroup in the

exclusion file is as shown in the following example:

CHECKSUM: "2971092695 231123789"

covergroup main::cg

Exclusion Management
12-131
Remapping Exclusions From the Block Level to the
System Level

When large designs are verified, often lower-level blocks or units are
first verified independently and then integrated into a larger chip or
system-level verification. As a block/unit level design is verified, it is
often needed to waive or exclude objects from the coverage model.
Usually those objects should also be excluded at the system level.
This section describes how to import block-level exclusions to the
system level. The technique used is based on the same feature —
mapping — that enables block-level coverage to be imported into
system-level coverage analysis. You can map both coverage and
exclusions at the same time if required.

Use Model

Consider the following figure that shows reusing of exclusions from

block level to the system level:

Exclusion Management
12-132
In the figure, the block-level instance md1 of the mod1 module is
mapped with the system-level instances, namely md1a and md1b of
the mod1 module. Therefore, exclusions associated with the block-
level instance md1 can be reused at the system-level instances md1a
and md1b.

There are two ways to remap exclusions from the block level to the
system level:

• Map exclusions block to system every time the system-level

coverage is analyzed. In this mode, the exclusions are remapped
on every URG run. Use this when the block-level exclusion work
is ongoing during a period of system-level analysis
• Map exclusions block to system once (or a few times) into system-
level and then create a new system-level elfile. Use this once the
block level has stabilized and all work is done at the system level.
This section consists of the following subsections:

• “-map and -elfile Options”

• “-mapfile and -elfile Options”

Exclusion Management
12-133
 -map and -elfile Options
When using the -map option, a module is identified by name and all
of its instance exclusions are mapped to all of its instance at the
system level. For mapping, use the -map option with the urg
command. The rules for mapping exclusions using the -map option
are as follows:

Excluded at the Excluded at the SoC

Block Level Level After Mapping
Object in a module Object in a module (Affects all
instances)

Object in a module Object in all instances of a

instance module

To map exclusions for a module from the block level to the system
level, use the -elfile option along with the following -map option:

urg -dir <base_design>.vdb -dir <input_design>.vdb -map

<module1> [-map <module2>...] -elfile <elfilename>

The following example shows how to map exclusions given in the

elfile.el file for the mod1 module from input.vdb to base.vdb
using the following urg command:
urg -dir base.vdb -dir input.vdb -map mod1 -elfile elfile.el

A sample of the elfile.el file is as follows:

CHECKSUM:1002196755 756496780"
INSTANCE:mod1.md1
Toggle a "reg a”

Exclusion Management
12-134
-mapfile and -elfile Options
To map instance exclusions at the block level with those at the
system level using a mapping configuration file, use the -mapfile
option with the urg command. An example of the mapping
configuration file is as follows:

MODULE: mod1
INSTANCE:
SRC: mod1.md1
DST: top1.mod1.md1a
SRC: mod1.md1
DST: top1.mod1.md1b

With the -mapfile option, you can specify about the instances that
receive exclusions from instances at the block level. Therefore, you
can map exclusions from the block level instead of merging
exclusions instance-by-instance.

The rules for mapping exclusions using the -mapfile option is as

follows:

Excluded at the Excluded at the SoC

Block Level Level After Mapping
Object in a module Excluded only in the
destination module. (If
excluded in all instances,
excluded in module)

Object in a module Excluded only in the

instance destination instances

To map exclusions from a mapping configuration file, use the -

elfile option along with the following -mapfile option:

urg -dir <base_design>.vdb -dir <input_design>.vdb -mapfile

<mapfile1> [-mapfile <mapfile2>...] -elfile <elfilename>

Exclusion Management
12-135
 The following example shows how to map exclusions given in the
elfile.el file for the map1 file from input.vdb to base.vdb using
the following urg command:
urg -dir base.vdb -dir input.vdb -mapfile map1 -elfile
elfile.el

Exclusion Management
12-136
13
Constant Analysis 1
This chapter discusses how you can find coverage targets that are
unreachable and helps reduce the coverage denominator. This
allows you to focus on the reachable coverage targets. This chapters
has the following sections:

• “Filtering Constants”
• “Dumping Annotations for Automatically Excluded Coverage
Targets”

Filtering Constants

Many designs have a number of HDLs and IP’s derived from different
sources, which are used to build a SoC. However, often many parts
of the design may not be used in the real chip because of the
unreachable targets. Constant analysis finds coverage targets that

Constant Analysis
13-1
 cannot be reached by any test and helps reduce the coverage
denominator and allows you to focus on the reachable coverage
targets.

For example, coverage statistics can sometimes be distorted if you

use certain nets as flags to deliberately stop the execution of certain
lines or conditions. Using this technique to prevent the execution of
these lines in certain circumstances can give you the simulation
results you want, but also lowers your line, condition, and toggle
coverage percentages.

To prevent this lowering of coverage percentages, use

-cm_noconst or -cm_seqnoconst compile-time option. Use
these options to instruct VCS MX to perform the following:

1. Recognize when a net is permanently at a constant 1 or 0 value.

2. Recognize when a signal or part of a signal cannot reach certain
values (-cm_seqnoconst)
3. Determine the lines, conditions and toggles that cannot be
covered as a result of constant analysis.
4. Suppress monitoring of these lines, conditions and toggles during
simulation so that the coverage score is not distorted by
unreachable targets.
Note:
Constant filtering is supported for line, condition and toggle in
Verilog. In VHDL design, constant filtering is supported in line and
condition but not toggle. In mixed design, the constants are not
propagated across language boundaries.

Constant Analysis
13-2
 The -cm_constfile option is used to inform VCS MX to treat
specified signals, nets, and variables, as permanently at 1 or 0
constant values. You can specify the list of signals in the text file
passed as an argument to the -cm_constfile option.

In Example 13-1 there are conditions that will never be met, lines that
will never execute, and nets that will never toggle between true and
false.

Example 13-1 Lines and Conditions That Can Never be Covered

1 module test;
2 reg A,B,C,D,E; net F is at 0 throughout the simulation
3 wire F;
4
5 assign F = 1’b0;
6
7 always @(A or B)
8 begin
9 C = (A && B && D);
10 E = (C || F); so F will never be true
11 if (!D)
12 C = 0;
13 else
14 C = (A || B);
15 if (!F)
16 E = 0;
17 else
18 E = 1; and this line will never execute
19 end
20
21 endmodule

In this example, if -cm_noconst is specified at compile time VCS

MX does not monitor when net F toggles or is true as a sub-
expression of the logical or operator || in line 10. It also does not
monitor for the execution of line 18 because line 18 will never be
executed since F is always 0 at line 15.

Constant Analysis
13-3
 There are a number of ways that a net can be permanently at 1 or 0,
but the analysis performed by the -cm_noconst option can only
recognize this in the following cases:

• When a 0 or 1 value is assigned to the net in a continuous

assignment statement. For example:
assign sig1 = 1’b0;

• When a 0 or 1 value is assigned to the net in the net declaration.

For example:
wire sig1 = 1’b0;

• When it is a supply0 or supply1 net.

• When VCS MX can determine through analysis of the code that
a signal will always have a 1 or 0 value. For example:
assign sig1 = 1’b0;
assign sig2 = sig3 && sig1;

However, the analysis performed by the -cm_seqnoconst option

can:

• Analyze assignments in sequential code

• Analyze signal bits with multiple drivers
• Analyze continuous assignments with delays
There are a number of ways you can assign the values 0 or 1 in a
continuous assignment statement. Here are a few examples:

assign G = 1;
assign H = 0;
assign I = 3’b0;
assign J = 1’b1;

Constant Analysis
13-4
No matter how you assign these 0 or 1 values, when you use the
-cm_noconst option, VCS MX will not monitor the pertinent
conditions or lines.

Constant filtering does not just pertain to scalar nets. If a continuous

assignment assigns a 1 or 0 value to a vector net, and you use the
-cm_noconst option, VCS MX does not monitor for the condition or
line coverage that cannot be covered because these vector nets
have a 1 or 0 value.

If a vector net is continuously assigned a 0 or 1 value, the least

significant bit is assigned either 1 or 0. All the other bits are assigned
0 and remain at 0 permanently. This means that a bit-select or part-
select of a vector net can be permanently at a value and the
-cm_noconst option can instruct VCS MX not to monitor for certain
conditions or line execution based on the permanent values of the
bit-select or part-select. For example:

wire [7:0] w1;

.
.
.
assign w1 = 1;

always @ sig1 VCS does not monitor for when w1[0] is 0

begin
if (w1[0] && sig1)
VCS does not monitor for when w1[1] is 1
.
.
.
sig2 = (w1[1] && sig1)

Constant Analysis
13-5
 If there is more than one continuous assignment statement of the 1
or 0 value to a net, VCS MX does not omit monitoring for conditions
or lines specified or controlled by the value of that net. This is true
even when the multiple continuous assignments are assigned to
different bits of a vector net. For example:

assign w1 = 1; multiple assignments to the same net

assign w1 = 0;
assign w2[1] = 0; assignments to different bits
assign w2[0] = 1;

always @ r1
VCS monitors for when w1 is both 1 and 0
begin
r2 = (w1 && r1);
r3 = (w2[0] && r1);
end
VCS monitors for when w2[0] is both 1 and 0

VCS MX detects unreachable conditions by analyzing procedural

blocks, evaluating the conditions controlling those blocks, and
determining which blocks are actually unreachable. Consider the
code shown in Example 13-2.

Example 13-2 Unreachable Verilog Block #1

22 case (my_case_var)
23 2'b10 : a = b & c
24 2'b11 : a = b | c
25 default : a = b ^ c;
26 endcase

The constant configuration file contains the following line:

Top.M1.my_case_var 2'b10

In Example 13-2, the conditions at lines 24 and 25 are unreachable

for instance top.M1 regardless of the values of b and c.

Constant Analysis
13-6
 Next, consider the code shown in Example 13-3.

Example 13-3 Unreachable Verilog Block #2

27 if (x || y)
28 begin
29 $display(" in IF");
30 end
31 else begin
40 if ( a || b ) begin
41 $display(" In nested IF”);
42 end
43 end

The constant configuration file contains the following line:

Top.M1.x 1’b1

In Example 13-3, the condition at line 40 is unreachable because x

|| y evaluates to constant 1 regardless of the value of y.

VCS MX detects these type of unreachable conditions under any

level of nesting of control statements, including

• case block within an if block

• if block present within a case block and so on.
VCS MX does this analysis for all selection statements, including
case, casex, casez, if-else, priority-if, unique-if,
priority-case, unique-case, except when comparisons with X
or Z values are involved. For more information, see “Module-Specific
Constant Limitations” .

All conditions found to be unreachable because of block-level

unreachability are marked unreachable in coverage report.

Constant Analysis
13-7
 VCS MX also supports marking a condition in ternary condition as
unreachable if that condition is never evaluated, as ternary condition
evaluates to be constant. For example, consider the following code:

assign r= a? b&&c : d ||e ;

Here, if a is a constant and has value 0, all vectors of condition b&&c

are marked unreachable in URG.

Constant Analysis With the -cm_seqnoconst Option

As discussed in the earlier sections, the -cm_noconst compile-time

option is used to automatically find unreachable coverage targets
using constant propagation analysis and remove them from
coverage monitoring. VCS MX excludes those signals and related
coverage objects that are found to be unreachable from the
coverage reports, as those signals are either tied to a constant value
in a continuous assignment, or designated as having constant
values by the user. This reduces the coverage denominator and
allows you to focus on the reachable coverage targets.

The -cm_seqnoconst compile-time option can be used instead to

enable the following additional features in constant analysis for
coverage in a design:

• “Analyzing Assignments in Sequential Code”

• “Analyzing Signal Bits With Multiple Drivers”
• “Analyzing Continuous Assignments With Delays”

Constant Analysis
13-8
 Analyzing Assignments in Sequential Code
Consider a simple flip-flop as shown in Figure 13-1. The data input
is known to be “always 0” - say, due to a continuous assignment to a
wire. And while the output is initially X, the output can never be 1.

Figure 13-1 Sequential assignment

This “never 1” information can be propagated through a chain of flip-

flops, as shown in Figure 13-2.

Figure 13-2 Sequential Assignment Through a Chain of Flip-flops

The following example shows the same structure as it could be

written in Verilog:

module dff_sync(data, clk, reset, q);

Constant Analysis
13-9
 input data, clk, reset;
output q;
reg q;

always@(posedge clk or reset)

if (reset == 1'b0)
q <= 1'b0;
else
q <= data;

endmodule

module top;
wire d1, /* always 0 */
d2, /* never 1 */
d3, /* never 1 */
d4; /* never 1 */
reg clk;
dff_sync ff1(d1, clk, d2);
dff_sync ff2(d2, clk, d3);
dff_sync ff3(d3, clk, d4);

assign d1 = 1'b0; /* d1 is always 0 */

endmodule

With the -cm_seqnoconst compile-time option, VCS MX does

additional analysis to determine that d2, d3, and d4 are “never 1”.
VCS MX then uses this information to eliminate the coverage targets
that depend on these signals' values reaching zero from coverage
monitoring.

For example, VCS MX can conclude that d4 is “never 1”, it will

exclude the “then” branch of the following “if” statement from
coverage monitoring:

if (d4)
… // this line will be marked unreachable
else
…

Constant Analysis
13-10
The same analysis is performed for vector signals. In the following
example, even though you do not have any information about the
value of data, you can see that q[3:0] will never be 1, because
both of its assignments are from constant 0.

module dff_sync(data, clk, q);

input [7:0] data, clk, reset;
output[7:0] q;
reg[7:0] q;

always@(posedge clk or reset)

if (reset == 1’b0)
q <= 8’b00000000;
else
q <= { data[3:0], 4’b0000 };

endmodule

Analyzing Signal Bits With Multiple Drivers

When using the -cm_noconst option, if a single bit of a signal was
driven by more than one source, the signal bit was not analyzed as
a constant, even if all sources assigned the same constant value. For
example, having two continuous assignments of the same value to a
signal will not be considered as a constant under the -cm_noconst
option.

Under the -cm_seqnoconst compile time option, such constants

can be analyzed. For example, VCS MX can conclude that signal a
is “never 0” from the following code:

assign b = 1'b1;

always@(posedge clk)
begin
a <= b; // a should be 'never 0'
end

Constant Analysis
13-11
 initial
begin
a <= 1;
end
The same analysis is performed for vector signals. In the following
example, qout[15:2] is “never 1”.

assign d = 0; /* d is always 0 */
assign e = 0; /* e is always 0 */

dff_sync ff1(d, clk, reset, qout[9:2]);

//qout[15:2] is "never 1"

dff_sync ff2(e, clk, reset, qout[15:8]);

Analyzing Continuous Assignments With Delays

When the -cm_seqnoconst option is given, VCS MX analyzes
continuous assignments for constant values even if they have
delays. In the following example, VCS MX concludes that signal c is
“never 1” under the -cm_seqnoconst compile-time option.

assign #5 c = 1'b0;

How Constant Analysis is Used for Coverage

The goal of performing constant analysis is to remove unreachable
coverage targets from the computation of the score and the reports,
so that you can focus on the hittable targets that need testing.

As described above, there are two types of constants detected by

VCS MX - "always" constants and "never" constants. For example,
you may know that a signal is "always 0" or you may only know that
it is "never 1". Depending on the coverage type and how the signal
is used in the code, you may or may not be able to eliminate a given

Constant Analysis
13-12
coverage target. This section discusses, for each metric, any
differences between always and never constants and how they are
used to identify unreachable coverage targets.

Toggle Coverage
In toggle coverage, “never 0” and “always 1” are the same. Because
toggle only cares about value changes from 0 ->1, a given toggle bit
becomes unreachable for any constant status.

For example,

wire a, b, c, d;
assign a = 1'b0;
assign b = 1'b1;
assign #5 c = 1'b0;
assign #5 d = 1'b1;

In the above example, signals a and b are "always" constants, and

signals c and d are "never" constants. For toggle coverage, these
signals are all reported in the same manner because toggling from
X-> 0 (or 1) does not count as a covered toggle:

Signal Details
Toggle Toggle 1->0 Toggle 0->1
a Unreachable Unreachable Unreachable
b Unreachable Unreachable Unreachable
c Unreachable Unreachable Unreachable
d Unreachable Unreachable Unreachable

The only exception to ignoring all "never" constants for toggle

coverage is when a signal is a 2-state value type. For example, the
SystemVerilog bit type has a default initial value of 0. In the
following example, the signal a will toggle from 0 -> 1 at time 5,
because its default initial value is 1'b0:

Constant Analysis
13-13
 bit a;
assign #5 a = 1'b1;
Although signal a appears to be of “never 0” value, it is not because
of its being of type bit.

Line Coverage
In Verilog, any expression with an X value in it evaluates to X, and
any conditional test of an X value is treated as false.

For example, consider the following “if” statements when the value
of myx is X:

if (myx)
$display("myx");
else
$display("else myx");// will execute if 'myx' is 1'bx

if (!myx)
$display("!myx");
else
$display("else !myx");// will execute if 'myx' is 1'bx

In both the “if” statements the “else” branch will execute when myx is
1'bx, even though the values myx and !myx are tested, which
appears to be opposite values. This is because myx and !myx both
evaluate to the unknown X value, which is treated as false.

The following table shows what can be concluded for the reachability
of the “if-then-else” branches for a simple “if” statement on a variable
“s”. For the “always” cases, either the true or the false branch will be
unreachable. For the “never 0” case, nothing can be concluded
because “never 0” is same as “X or 1”. Since X will be treated as

Constant Analysis
13-14
 false, either branch could be reached. And for “never 1”, it can be
concluded that the “then” case is unreachable, because “never 1”
means “X or 0”, both of which are treated as false.

Value of s
if (s)
Always 0 Always 1 Never 0 (X or 1) Never 1 (X or 0)
a = 1'b0;
else unreachable reachable reachable unreachable
a = 1'b1; reachable unreachable reachable reachable

Consider a scenario in which “s” is “never 0” (X or 1); !s will either

be X (in which case the else clause will be hit) or !s will be 0, which
means the “else” clause will be hit. So the “then” clause is
unreachable. But if s is “never 1”, !s will either be 1 or X, so either
clause can be hit.

Value of s
if (!s)
Always 0 Always 1 Never 0 (X or 1) Never 1 (X or 0)
a = 1'b0;
else reachable unreachable unreachable reachable
a = 1'b1; unreachable reachable reachable reachable

Line coverage also monitors continuous assignments. If the right-

hand side of the assignment ever changes to 0 or 1 (even if its initial
value is X), the assignment is counted as covered. So for a
continuous assignment the reachability for never constants is
different than for always constants, as shown in the following table.

Value of s
Always 0 Always 1 Never 0 (X or 1) Never 1 (X or 0)
assign x = s; unreachable unreachable reachable reachable

Constant Analysis
13-15
 Case Statements

Consider the case statement in the following example, supposing

that the variable a is "always 01":

case (a)
2’b00: ..bold lines are unreachable if ‘a’ is always 01
2’b01: ...
2’b10: ...
2’b11: ...
2'b0x: ...
2'b1x: ...
2'bx0: ...
2'bx1: ...
2'bxx: ...
endcase
But when a is known to be either 2'b01 or X, the case statement is
as follows:

case (a)
2'b00: ... red lines are unreachable if 'a' is 01-or-X
2'b01: ...
2'b10: ...
2'b11: ...
2'b0x: ...
2'b1x: ...
2'bx0: ...
2'bx1: ...
2'bxx: ...
endcase
Also, consider the casex statement. The casex statement treats
any X or Z value as don't-care when comparing. The X or Z values
can appear either in the argument to casex or in any of the case
values.

For example,

casex (a)

Constant Analysis
13-16
 2'b1x: …
…
endcase
It appears that the first case can only happen if a's first bit is 1. But it
will also match if a's value is 2'bxx, because the X's in a will be
treated as don't-cares. So when VCS MX is comparing a const-or-X
value for the casex statements, it is assumed that any bit can be X,
and therefore any case value can be matched. Because Verilog
evaluates casex statements in the first-match order, the first case is
always reachable.

Condition Coverage
In some cases of condition coverage, VCS MX considers an X value
to be equivalent to false but in other cases it will not. If the operator
of the conditional expression is a “relational” operator, an X value is
treated as false.

The following table lists the supported Verilog operator:

== equality
!= inequality
=== case equality
!== case inequality
> greater that
>= greater that or equal to
< less than
<= less than or equal to

In the following example, even if VCS MX knows that bus is "00 or

X", it cannot mark either the true or the false value of b[1:0] ==
b[1:0] as unreachable because if bus is 2'bXX, any equality
comparison will be false although it is being compared to itself.

Constant Analysis
13-17
 if (b[1:0] == b[1:0]) … //will be executed when b == 2'b00

else … // will be executed if b == 2'bXX

If b is all Xs at time 0 and then becomes 2'b00 later, both clauses
will be marked covered, and the following non-intuitive result is
displayed:

LINE 27
EXPRESSION (b[1:0] == b[1:0])
---------1--------
-1- Status
0 Covered
1 Covered
But for non-relational operators, VCS MX treats X as its own
separate value.

For example,

if (a || b)
...
else
...

VCS MX might monitor the combinations of a and b shown in the

following table. In this case, “never 0” or “never 1” are identical to
“always 1” or “always 0” as shown:

Value of s
Always 0 Always 1 Never 0 (X or 1) Never 1 (X or 0)
a=1, b=0
reachable unreachable unreachable reachable
a=0, b=1 unreachable reachable reachable unreachable
a=0, b=0 reachable unreachable unreachable reachable
unreachable reachable reachable unreachable
a=1, b=1

Constant Analysis
13-18
Conditions inside the ternaries are not affected by the “never”
uncertainty. So in the following example, VCS MX can mark the "q &
z" condition as unreachable, as it knows bus b can never be 2'b00:

assign #5 b = 2'b11;
req = (b[1:0] == 0) ? (q & z) : (q | z);

Constant Analysis
13-19
 Limitations

This section describes the limitations with -cm_noconst and

-cm_seqnoconst options.

Limitations With -cm_noconst and -cm_seqnoconst

Options
The following are the limitations with -cm_noconst and
-cm_seqnoconst options:

• VCS MX does not perform constant analysis within any kind of

task or functions.
• Constant X or Z values are not considered for constant analysis.
Any comparison which involves X or Z values is not determined
as constant. For example, for the following code:
wire [2:0] w;
assign w = 2'b0x;
initial
begin
case (w)
2'b00 : $display("00");
2'b0x : $display("0x");
default : $display("default");
endcase
end

The value of w actually matches with case-item 2’b0x. However,

VCS MX is unable to determine this kind of constant because an
X value comparison is involved.

Again, for the following example:

wire [2:0] w;

Constant Analysis
13-20
 assign w = 2'b01;
initial
begin
casex (w)
2'b00 : $display("00");
2'b0x : $display("0x");
default : $display("default");
endcase
end

Here, case item 2’b0x is always reachable, whereas default

and 2’b00 are unreachable.

• VCS does not detect constant signal values when cross module
references (XMRs) are involved.
For example,

module m;
assign top.p = 1'b0;
endmodule

module top;
wire p;
endmodule

In the above example, VCS will not find that top.p is constant 0
with either -cm_noconst or -cm_seqnoconst option.
Therefore, the generated constfile.txt file does not include
an entry for the top.p signal.

For example,

module m;
wire q;
assign q = top.d;
endmodule

module top;

Constant Analysis
13-21
 wire d;
assign d = 1'b0;
m m1();
endmodule

In the above example, VCS only detects the constant 0 value of

the d signal. VCS does not detect the constant 0 value of the
top.m1.q signal.

• The -cm_noconst and -cm_seqnoconst features do not

analyze constants as they are assigned to struct members.
Consider the code snippet below in which struct members,
s1.i1[3:0] and s1.i2, are driven by signals, r1[31:0] and
p1 respectively. These signals are assigned constants, namely,
1'b1 and 32'h76BCA401 respectively. Both the signals,
r1[31:0] and p1 are marked as unreachable. However, the
limitation of the -cm_noconst and -cm_noconst features is
that both the struct members, s1.i1[3:0] and s1.i2 and
input ports, i1[1:0] and i2 are not marked as unreachable. For
this, see the code snippet below:
module top( input wire clock, input wire MRE);
wire [31:0] r1;
reg p1;

assign p1 = 1'b1;

typedef struct {
reg [3:0] i1;
bit i2;
}str;

str s1;

assign s1.i1 = r1[1:0];

assign s1.i2 = p1;

dummy d1 [1:0] (r1);

try TR1 [1:0](clock, s1.i1, s1.i2);

Constant Analysis
13-22
endmodule

module try(input wire clock, input wire [1:0] i1, input

wire i2);
endmodule

module dummy (output wire [31:0] r1);

assign r1 = 32'h76BCA401;
reg clk;
endmodule

Toggle Coverage for Module : top

Port Details
Toggle Toggle 1->0 Toggle 0->1 Direction
clock Yes Yes Yes INPUT
MRE Unreachable Unreachable Unreachable INPUT

Signal Details
Toggle Toggle 1->0 Toggle 0->1
r1[31:0] Unreachable Unreachable Unreachable
p1 Unreachable Unreachable Unreachable
s1.i2 No No Yes
s1.i1[3:0] No No No

Toggle Coverage for Module : try

Port Details
Toggle Toggle 1->0 Toggle 0->1 Direction
clock Yes Yes Yes INPUT
i1[1:0] No No No INPUT
i2 No No No INPUT

Constant Analysis
13-23
 Limitation With the -cm_seqnoconst Option
With the -cm_seqnoconst option, VCS MX does not find every
unreachable coverage target in the design. For example, consider
that there are only two assignments to the signal b in the following
design:

if (qout) /* qout is known "never 1" */

b <= 1'b1; /* this line will be marked unreachable */
else
b <= 1'b0;
Assuming that the signal qout is “never 1” for coverage purpose,
VCS MX will exclude the ‘then’ clause. However, VCS MX will not be
able to conclude that signal b is “never 1” (or “always 0”) and
therefore, any coverage targets dependent on the value of signal b
will continue to be monitored for coverage.

Similarly, when a flip-flop is resettable to 0, knowing that the input is

“always 1” does not help. In such a scenario, the output can be 0
when reset, 1 when passed through, or X before it is first invoked
during simulation as shown in the following example:

assign data = 1'b1;

always@(posedge clk or reset)

if (reset == 1'b0)
q <= 1'b0;// 'q' will not be treated as constant
else // because 'd' is 1 but there is
q <= data;// an assignment from 0, too

However, the output of a resettable flip-flop with an “always 0” input

can still be treated as “never 1” because both assignments to the
signal q are 0:

assign data = 1'b0;

Constant Analysis
13-24
 always@(posedge clk or reset)
if (reset == 1'b0)
q <= 1'b0; // 'q' will be treated as constant
else // because 'd' is 0 and
q <= data; // the reset is also value 0

Other -cm_seqnoconst Limitations

Other limitations for the -cm_seqnoconst compile-time option are
as follows:

• The -cm_seqnoconst compile-time option cannot be used to

analyze or propagate constants through VHDL designs.
• Constant values other than 1 and 0 are not analyzed.
• The constant values resulting from different signal strengths are
not detected. For example, a strong assignment of 0 -> X will not
over-ride a weak assignment of 1 -> X. In such cases, VCS MX
will not detect that X is a constant.
• Constants are not analyzed inside tasks or functions. The return
values from the functions and the output arguments in the tasks
are treated as unknown values.
• Constant propagation improvement does not effect branch, FSM,
and path coverage.
• Constant propagation improvement does not effect covergroup
and assertion analysis.

Constant Analysis
13-25
 Propagating Constants Through Instance Arrays

While identifying constants, VCS MX considers the propagation of

constants through the port connections between instances.

Instance arrays behave like any other normal instance from a

constant filtering perspective. Constants are identified from single
instances and passed through port connects of single instances.
Instance arrays include some special features regarding port
connections which are duly regarded during constant propagation
with the enhanced constant filtering mechanism. For more
information, see IEEE std 1364-2005, Verilog Language Reference
Manual, section 7.1.6.

Rules of Port Connections in Instance Arrays

The following cases explain the rules of port connections in instance
arrays.

Case 1

For each port or terminal where the bit length of the instance array
port expression is the same as the bit length of the single-instance
port, the instance array port expression is connected to each single-
instance port.

Example

modName inst_arr[1:0] (.abc(def));

Here, if the widths of abc and def are equal, then it is interpreted as:

modName inst_arr[0] (.abc(def));

modName inst_arr[1] (.abc(def));

Constant Analysis
13-26
and,

modName inst_arr[4:5] (.abc(def[1:4]));

If the widths of abc and def are equal (both have width 4), then it is
interpreted as:

modName inst_arr[5] (.abc(def[1:4]));

modName inst_arr[4] (.abc(def[1:4]));

Case 2

If bit lengths are different, then each instance gets a part-select of the
port expression as specified in the range, starting with the right-hand
index.

Example

modName inst_arr[1:2] (.abc(def[6:1]));

If the width of abc is 3, that is width of the high connection = (width

of instance array) X (width of low connection), then it is interpreted
as:

modName inst_arr[2] (.abc(def[3:1]));

modName inst_arr[1] (.abc(def[6:4]));

Case 3

Too many or too few bits to connect to all the instances is reported
as a syntax error during Verilog parsing.

Constant Analysis
13-27
 Examples
Example 13-4 shows identification of a constant in instance array/up
and downward constant propagation through an instance array. In
Example 13-4:

• top_b is a constant, as the value of bot_o is propagated upward

through the instance array.
• ia_con is identified as a constant in both of the single-instances
of the instance array ia_inst[1:0].
• bot_i is a constant as the value of top_a is propagated
downward through the instance array.
Example 13-4 Constant Propagation Instance Array Up and Down
module top;
wire top_tmp;
wire top_a;
wire top_b;

assign top_a = 1'b1;

instArrMod ia_inst[1:0] (top_a, top_b);
endmodule

module instArrMod(input ia_i, output ia_o);

wire ia_tmp;
wire ia_con;

assign ia_con = 1'b0; bot bot_inst(ia_i, ia_o);

endmodule

module bot(input bot_i, output bot_o); wire bot_tmp;

assign bot_o = 1'b1;

endmodule

Constant Analysis
13-28
 Example 13-5 shows passing constants to and from an instance
array according to the port connection rule for instance array. In
Example 13-5:

• top_b will have bits 0 and 1 constant for single instance

ia_inst[0] and bits 4 and 5 constant for ia_inst[1].
• ia_i is a constant only in the single-instance ia_inst[1].
Example 13-5 Constant Propagation by Port Connection Rule
module top;
wire top_tmp;
wire [7:0]top_a;
wire [7:0]top_b;
assign top_a = 8'b1111XXXX;
instArrMod ia_inst[1:0] (top_a, top_b);
endmodule

module instArrMod(input [3:0]ia_i, output [3:0]ia_o); wire

ia_tmp;
assign ia_o = 4'bXX11;
endmodule

Treating Other Signals as Permanently at 1 or 0 Value

You can also tell VCS MX to treat specified signals, nets, and
variables, as permanently at 1 or 0 constant values by specifying the
list of signals in a text file passed as an argument to the
-cm_constfile option. VCS MX will not monitor the specified
signals, nets, or variables for toggle coverage (Verilog only), or
vectors for conditions that cannot be covered and lines that would
not be executed considering the information in <constfile>.
However, <constfile> does not really affect the values of signals,
nets, or variables during simulation.

Constant Analysis
13-29
 When compiled with the -cm_constfile option, VCS MX treats
the following as constants:

• Signals specified in <constfile>

• Constants extracted from a continuous assignment
• supply0 or supply1
For example:

Example 13-6 Using the -cm_constfile Option

module top();
wire [1:0] a;
wire [7:0] b;
wire [4:0] c;
reg d;
assign b = {a, d, 5’b11x01};
endmodule

In the <constfile>, you have:

top.a 2’b10
then VCS MX Coverage considers the value of "b" as
8’b10x11x01 for constant filtering.

Note:The value of the constant "a" defined, in the <constfile> is

considered to evaluate the wire "b".
These constants remain local to the instance and do not propagate
across the hierarchy through ports.

However, you can use the -cm_noconst or the -cm_seqnoconst

compile-time option to propagate the local constants across the
hierarchy.

Constant Analysis
13-30
Specifying Instance-Specific Constant Signals in
Constant Configuration File
VCS MX allows you to specify instance-specific constant signals
within a constant configuration file (-cm_constfile option).
Following are the syntaxes:

Syntax 1

constfile_statement ::= <Full-Signal-Name> <constant-

expression>
where, <Full-Signal-Name> := <Hierarchical-name of
the instance>.<Signal-Name>

For example, to make signal “x ” a constant 0 for instance Top.M1

of module Mid, specify the following in the <constfile>:

Top.M1.x 1'b0

Syntax 2

constfile_statement ::= instance {<Hierarchical-Instance-

Name>} {Signal-Name} {<constant-expression>}
For example, to make signal “x ” a constant 0 for instance Top.M1
of module Mid, specify the following in the <constfile>:

instance {Top.M1} {x} {1'b0}

Specifying Module-Specific Constant Signals in

Constant Configuration File
VCS MX allows you to specify module-specific constant signals
within a constant configuration file (-cm_constfile option).
Following are the syntaxes:

Constant Analysis
13-31
 Syntax 1

constfile_statement ::= <Full-Signal-Name> <constant-

expression>
where, <Full-Signal-Name> := <Module-Name>.<Signal-
Name>

and <Module-Name> := [<library-Name>.]Name-

Identifier

For example, to make signal “x” a constant 0 for module M and if the
module is inside library LIB, specify the following in the
<constfile>:

\LIB.M .x 1'b0

Syntax 2

constfile_statement ::= module {<Module-Name>} {Signal-

Name} {<constant-expression>}
where, <Module-Name> := [<library-Name>.]Name-
Identifier

For example, to make signal “x” a constant 0 for module M and if the
module is inside library LIB, specify the following in <constfile>:

module {\LIB.M } {x} {1'b0}

For register constants, use -cm_constfile to specify them

explicitly. You must also use the -cm_noconst option for the
constant analysis to happen.

Constant Analysis
13-32
For a particular signal, if both module-specific and instance-specific
constant signals are specified in the constant configuration file, the
instance-specific constant value is given preference for the particular
instance.

For example, if the content of a constant configuration file is:

\LIB.M .x 1’b0
Top.M1.x 1’b1

Here, M1 is an instance of module M instantiated in another module

Top, and x is a signal in module M. Even though you explicitly assign
value 1’b1 to signal x for instance M1, because the module-specific
constant is specified first in the constant configuration file, it is given
preference, and signal x gets a constant value of 1’b0.

However, if the content of a constant configuration file is:

Top.M1.x 1’b1
\LIB.M .x 1’b0

Then signal x gets value 1’b1 for instance M1, because the
instance-specific constant is specified first in the constant
configuration file.

Module-Specific Constant Limitations

Note the following limitations when working with module-specific
constants:

• VHDL is not supported.

• No analysis is done to determine if registers are constant in a
design. For example, if you have a register declared as:
reg [1:0] my_case_var;

Constant Analysis
13-33
 And you initialize it at the beginning of an initial block as follows:

initial
begin
my_case_var = 2'b10;

And the always block where my_case_var is driven is:

always @(posedge clk)

begin
if (a)
my_case_var = 2'b10;
else
my_case_var = 2'b11;
end

And the constant configuration file contains:

Top.M1.a 1’b1

Then, the register my_case_var always gets constant value

2’b10. But you cannot determine such constants for registers.

• Control flow constructs such as while or for are not supported for
control flow-based reachability for condition coverage.

Syntax of the -cm_constfile Input File

You can specify a constant value to a signal, net, or variable in the
following two ways:

• Specify a constant value

• Write an expression - VCS MX evaluates the expression, and
assigns the obtained value to the specified constant.

Constant Analysis
13-34
Using the <constfile>, you can:

• Include single-line or multi-line comments.

• Specify a list of signals, nets, or variables and their values.
The syntax to write a <constfile>, is as follows:

• Single line comments should start with "//". You can also
comment a block, by enclosing it within "/*" and "*/".
• Specify a list of signals, nets, or variables, and their corresponding
constant values.
For example:

top.t1.a 1
top.b 4’b1010 //test is the module name and for all the
instances of module test “b” is tied to 4’b1010

Note:
Instance specific constants are given preference over module
specific constants if they both refer to the same variable and have
different constant values.

For example, consider that b1, b2, b3 are three instances of

module “bot” and they are instantiated in top; and in the constfile
you have three entries for a variable ‘x1’ of module “bot” as follows:

top.b1.x1 1’b0

bot.x1 1’b1

top.b2.x1 1’b0

For above, both the instances b1, b2 will get value 1’b0 and for
instances b3, variable x1 will get value 1’b1.

Constant Analysis
13-35
 For example:

Using wire c, shown in Example 13-6, the following assignment in

the <constfile>:

top.c 1’sb1

is equivalent to top.c 5’b11111.

• You can specify the value of a signal, net, or variable in the

following formats:
- Decimal
- Binary
- Octal
- Hexadecimal
• Use the "U" character to concatenate two or more part selects of
the same signal, as follows:
top.c[0:3] 4’b1111
top.c[5:7] 3’b101
The above declaration, can also be written as:

top.c 4’b101U1111

If the representation is in binary format, "U" acts as a single bit. For

Octal and Hexadecimal formats, "U" acts as 3 bits and 4 bits,
respectively.

For example:

top.d 9’o3U4
top.e 12’h5U8A

Constant Analysis
13-36
VCS MX expands above declarations as:

top.d 9’b011UUU0100
top.e 12’b0101UUUU10001010
Instead of a constant value, you can also specify an expression as
follows:

top.t1.f {4’b1010, 4’b0101} | 8’h5A

VCS MX evaluates the above expression and assigns the resultant

to the signal, top.t1.f.

Note:
If the specified expression contains "U", VCS MX replaces "U" with
"x" as in Verilog during evaluation, and the evaluation follows
Verilog semantics.

Constant Analysis
13-37
 The following table lists the supported operators:

Table 13-1 Supported Operators

Operator Operator Operation Number of
Type Symbol Performed Operands
Arithmetic * multiply Two
/ divide Two
+ add Two
- subtract Two
% modulus Two
** power (exponent) Two
Logical ! logical negation One
&&| logical and Two
| logical or Two
Relational > greater than Two
< less than Two
>= greater than or
equalTwo
<= less than or equalTwo
Equality == equality Two
!= inequality Two
=== case equality Two
!== case inequality Two
In constfile case
equality and normal
equality behave the
same way
Bitwise ~ bitwise negation One
& bitwise and Two
| bitwise or Two
^ bitwise xor Two
^~ or ~^ bitwise xnor Two
Reduction & reduction and One
~& reduction nand One
| reduction or One
~| reduction nor One

Constant Analysis
13-38
Table 13-1 Supported Operators (Continued)
^ reduction xor One
^~ or ~^ reduction xnor One
Shift >> Right shift Two
<< Left shift Two
>>> Arithmetic Right Shift Two
<<< Arithmetic Left Shift Two
Concatenation { } Concatenation Any number
Replication {{}} Replication Any number
Conditional ?: Conditional Three
Parentheses () Change Precedence --

The <constfile> syntax is:

constfile_statement_declarations ::=
constfile_statement_declarations constfile_statement
|
;
constfile_statement ::= full_signal_name
constant_expression
| module '{'module_name'}' '{'signal_identifier'}'
'{'constant_expression'}'
| instance '{'full_instance_name'}'
'{'signal_identifier'}' '{'constant_expression'}'
full_signal_name ::= full_instance_name.signal_identifier
| module_name.signal_identifier
full_instance_name ::= hierarchical_path_of_instance
constant_expression::=
[ sign ] decimal_number
| [ sign ] octal_number
| [ sign ] binary_number
| [ sign ] hex_number
| expression_with_operator
expression_with_operator ::=
'(' constant_expression ')
| constant_expression BIN_OP constant_expression
| '{' list_of_constant_expression '}'
| '{' constant_expression '{' constant_expression '}' '}'

Constant Analysis
13-39
 | UNI_OP constant_expression

| constant_expression '?' constant_expression ':'

constant_expression
list_of_constant_expression ::=
constant_expression
| list_of_constant_expression , constant_expression
BIN_OP ::= * | / | + | - | % | ** | && | || | < | > | <= | >= |
== | != | === | !== | | | & | ^ | ~^ | ^~ | << |
>> | <<< | >>>
UNI_OP ::= ! | ~ | & | ~& | | | ~| | ^ | ~^ | ^~
decimal_number ::=
unsigned_number | [ size ] decimal_base unsigned_number
binary_number ::= [ size ] binary_base binary_value
octal_number ::= [ size ] octabl_base octal_value
hex_number ::= [ size ] hex_base hex_value
sign ::= +|-
size ::= non_zero_unsigned_number
non_zero_unsigned_number* ::=
non_zero_decimal_digit {_|decimal_digit}
unsigned_number* ::= decimal_digit {_|decimal_digit}
binary_value* ::= binary_digit {_|binary_digit}
octal_value* ::= octal_digit {_|octal_digit}
hex_value* ::= hex_digit {_|hex_digit}
decimal_base* ::= '[s|S]d | '[s|S]D
binary_base* ::= '[s|S]b | '[s|S]B
octal_base* ::= '[s|S]o | '[s|S]O
hex_base* ::= '[s|S]h | '[s|S]H
non_zero_decimal_digit ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
decimal_digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
binary_digit ::= U | 0 | 1
octal_digit ::= U | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
hex_digit ::= U | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
| a | b | c | d | e | f | A | B | C | D | E | F

Note:
Embedded spaces are illegal.

See the Coverage Technology Command Reference Guide to see

how this option affects the contents of condition coverage reports.

Constant Analysis
13-40
Dumping Annotations for Automatically Excluded
Coverage Targets

The -diag noconst compile-time option is used to dump the

constant analysis information enabled by the -cm_noconst,
-cm_seqnoconst or -cm_constfile options into a file called
constfile.txt. The reason for each signal being determined by
VCS MX as a constant is reported in the constfile.txt file.

For example, if VCS MX determines that the following $display

statement is unreachable:

if (a && b)
$display("this can't happen");

If you enable -diag noconst, VCS MX will, in the output file, say
if it was “a” that was determined to be constant 0, or “b”, or both.

For example, if the myconsts.txt file is provided as an input file to

the -cm_constfile option and contains the following line:

top.d1'b0

Then, for the following code, the constant analysis is done as shown
in the comments and in the given order:

Constant Analysis
13-41
 1 module dff_sync(data, clk, reset, q);
2 input data, clk, reset;
3 output q;
4 reg q;
5 always@(posedge clk or reset)
6 if (reset == 1'b0)
7 q <= 1'b0; /* 2. q is only 0 or X */
8 else
9 q <= data; /* 2. q is only 0 (data) or X */
10 endmodule d is const So d is
11 0 from always
12 module top; constfile 0
13 wire d, qout;
14 reg clk, rst;
15 dff_sync d1(d, clk, rst, qout); /* 1. data is always 0 */
/* 3. qout is only 0 or X */
16
17 wire t;
18 assign t = d | qout; /* 4. t can only be 0 or X */
19 endmodule

The following five signals are identified as constant in this example:

• top.d is identified in -cm_constfile as always constant 0

• top.d1.data is the LowConn for top.d and therefore, its value
is always 0
• top.d1.q is assigned in two places, but both by the value 0. The
first is the reset assignment from literal 1'b0 and the other is from
top.d1.data. As it is sequentially assigned, it is flagged as “0
or X”
• top.qout is the HighConn for top.d1.q and therefore, its value
is “0 or X”.

Constant Analysis
13-42
 For more information about what the “0 or X” value means, see
the “Constant Analysis With the -cm_seqnoconst Option” section.

• top.t is assigned “d | qout”, so its value is also “0 or X”, as

both of its inputs are known constants

Use Model

The annotations are dumped to the constfile.txt file using the

-diag noconst compile-time option in the vcs command line:

% vcs <const_propagation_analysis_option> -diag noconst \

<other_compile_time_options>

Note:
You must enable constant analysis using the appropriate constant
propagation analysis option, such as -cm_noconst,
-cm_constfile, or -cm_seqnoconst in the command line.
The following is the constant analysis information dumped into
constfile.txt for the example mentioned in the previous
section.

constants:
- module: top
expression: d
declaration: file.v:13
value: always 0
locations:
- location: myconsts.txt:1

- instance: top.d1
expression: data
declaration: file.v:2
value: always 0
locations:
- location: file.v:15

Constant Analysis
13-43
 inputs:
- input: d

- instance: top.d1
expression: q
declaration: file.v:4
value: 0 or X
locations:
- location: file.v:7
- location: file.v:9
inputs:
- input: data

- module: top
expression: qout
declaration: file.v:13
value: 0 or X
locations:
- location: file.v:15
inputs:
- input: q

- module: top
expression: t
declaration: file.v:17
value: 0 or X
locations:
- location: file.v:18
inputs:
- input: d
- input: qout

This is a YAML (Yet Another Markup Language)-format file that can

be easily read with a program or a script, but also can be read as
(almost) plain text. The file always starts with the constants:
keyword. Each entry after that, lists a scope (module or instance)
and an expression (a signal, or bit-select, or part-select), and always
includes exactly one value and at least one location.

Constant Analysis
13-44
If the scope is a module, it means VCS MX has found that the
expression is constant based on the module itself, independent of
the parameter values or the values passed to only some
instantiations but not others.

If the scope is an instance, it means VCS MX has found that the

expression is constant in that instance, but it might not be constant
in all the instances of the module.

The value field is always one of “0 always”, “1 always”, “1 or X”, or “0

or X”. The “always” constants mean that the expression holds the
given constant value from time 0 throughout the entire simulation.
For example, top.d is always 0 as it is specified as constant 0 in the
-cm_constfile input.

The “0 or X” or “1 or X” constants mean that while the value of the

expression is not fixed, it is known that it cannot reach the excluded
value. In this example, top.d1.q is “0 or X” because it can never be
1 as all the assignments to it have the constant 1'b0 as input. But it
is not “always 0” because it will have an X value until the first clock
positive edge or reset.

Each entry includes either zero or more locations and inputs. A

location identifies a line in the source code where a constant value is
assigned to the expression. There might be one location, as shown
in top.d at line 17 where it is continuously assigned 1'b0. There
might be multiple assignment locations, as shown in top.d1.q,
which is assigned 1'b0 at both line 7 and line 9 because the data is
0.

Note:
• There can be more than one location involved. For the signal
top.d1.q, there are two assignments that are considered.

Constant Analysis
13-45
 • There can be more than one input for a signal. For the signal
top.t, “d” and “qout” are inputs.
• Only signals and signal expressions are listed as inputs; there will
be no inputs listed if the only source s for the expression are literal
constants.

Examples

This section describes some examples and the corresponding

annotation file that is produced for each example.

Multiple 1-Value Constants

Because of the way VCS MX infers constant values, each “1” value
is tracked separately. For example, if you have the following code
snippet in the source code:

13 wire [3:0] vec;

14 …
15 assign vec = 4'b1100;

The “1” bits of vec are listed separately. The contiguous 0 part of
vec is listed as a 2-bit part-select:

- module: top
expression: vec[3]
declaration: file.v:13
value: always 1
locations:
- location: file.v:15

- module: top
expression: vec[2]
declaration: file.v:13
value: always 1

Constant Analysis
13-46
 locations:
- location: file.v:15

- module: top
expression: vec[1:0]
declaration: file.v:13
value: always 0
locations:
- location: file.v:15

The diagnostic output groups part-selects together to minimize the

number of expressions. For example,

13 wire [3:0] data;

14 …
15 assign data = 4'b1001;

The output consists of two expressions - one for data[3] and one for
all of data[2:0], each of which will have "always 1" as its constant
value:

- module: top
expression: data[3]
declaration: file.v:13
value: always 1
locations:
- location: file.v:15

- module: top
expression: data[2:0]
declaration: file.v:13
value: always 1
locations:
- location: file.v:15

Constant Analysis
13-47
 Note:
Because of this grouping no explicit 0 values are shown, as
data[2:0] having the value 001 implies that data[2] and
data[1] are both 0.

Bit-Select Inputs
The constants can be derived from bits of constant expressions. For
example, assume that r[0] and r[1] are both known to be “always
1”. Now consider this assignment to one bit of a vector “c”:

assign c[0] = ~(r[0] | r[1]);

Then, the report is as follows:

- instance: L2Inst
expression: c[0]
declaration: Source/seqNoConst/concatWidth.v:49
value: 0 always
locations:
- location: Source/seqNoConst/concatWidth.v:51
inputs
- input: r[0]
- input: r[1]

Note that both r[0] and r[1] are listed in the inputs.

Bit Padding
Consider the following assignment:

reg [25:0] myfile;

reg b5, b4, b3, b2, b1, b0;
…
myfile = { b5, b4, b3, b2, b1, b0 };

Constant Analysis
13-48
The myfile[25:6] expression is flagged as constant 0 because
the six-bit concat expression is padded out to the left with zeroes (the
lowest six bits of myfile are not constant). So the report is as
follows:

- instance: top
expression: foo[25:6]
declaration: file.v:1
value: 0 or X
locations:
- location: file.v:12
Note that there are no inputs listed, as only constant (padding) 0s
feed this constant expression.

Bit Padding For Constant File Entries

Consider the following code snippet:

module simple;
wire [5:0]w;
endmodule
When simple.w 5'b00101 is input using the myconst1.txt file
with the -cm_constfile option, zero padding occurs for bit w[5]
and is reported as:

- instance: simple
expression: w[1:0]
declaration: test_const_padding.v:3
value: 1 always
locations:
- location: myconst1.txt:1

- instance: simple
expression: w[4:2]
declaration: test_const_padding.v:3
value: 1 always

Constant Analysis
13-49
 locations:
- location: myconst1.txt:1

- instance: simple
expression: w[5]
declaration: test_const_padding.v:3
value: 0 always
locations:
- location: myconst1.txt:1

When simple.w 6'b000101 is input using the myconst2.txt

file, the signal bits [5:2] are combined together and reported as
always 1:

- instance: simple
expression: w[1:0]
declaration: test_const_padding.v:3
value: 1 always
locations:
- location: myconst2.txt:1

- instance: simple
expression: w[5:2]
declaration: test_const_padding.v:3
value: 1 always
locations:
- location: myconst2.txt:1

Constant Analysis
13-50
A
Unified Coverage API 1
The Unified Coverage Application Programming Interface, or
UCAPI, provides a single, consistent, and extensible interface to
access coverage data generated by Synopsys tools. With this API,
you can create custom reports and tools for displaying and analyzing
coverage data.This chapter contains the following sections:

• “Overview”
• “Data Model”
• “Predefined Coverage Metrics”
• “Loading a Design”

Unified Coverage API

A-1
Overview

The UCAPI library provides a set of C functions that can be called to

get handles to objects in the coverage database. Handles have
properties that may be retrieved, such as name, coverage status,
and source location information. Handles are connected with 1-to-1
and 1-to-many relations that allow you to traverse all of the data in
the database.

UCAPI coverage data is represented using a small set of simple

building blocks that can be used to model any type of coverage data.
The objects in the database are the same regardless of the design
language (for example, Verilog or VHDL), functional coverage
language, or coverage metric type. Different coverage metrics
arrange the objects in different ways, but the same basic building
blocks are used through UCAPI. This means you can write
applications that can understand any type of coverage data without
having to follow a set of rules for each different metric.

UCAPI does not provide a complete representation of the design –

only what is necessary to present coverage information in proper
context. For example, there is no representation of the control
structure of code – only the aspects of the design that are monitored
by each different metric. Data about the design that is independent
of any specific coverage metric is called unqualified data.

Inside each region in the design, the coverage data for a given metric
is made of UCAPI building blocks. These represent the objects that
were monitored for coverage in that region. Since each metric has its
own separate collection of such objects, this is called metric-qualified
data.

Unified Coverage API

A-2
Whether or not an object is covered depends on which test or
collection of tests you have loaded. For example, a cross bin may
have been covered in one simulation run, but not in another. Data
that depends on a particular test or set of tests is called test-qualified
data.

UCAPI uses a series of diagrams to represent object relationships.

The following is a summary of the relation types.

Unified Coverage API

A-3
 The section consists of the following subsections:

• “Database Contents”
• “Persistence”
• “UCAPI Setup and Compilation Requirements”
• “Dynamic UCAPI Library”

Database Contents

A UCAPI database is loaded from one or more directories. The fgirst

directory loaded must always contain the unqualified design
information - this is typically the data directory created when the
design was compiled. Subsequent directories can be full directories
(containing unqualified data) or test-only directories (containing only
information produced by one or more test runs).

Persistence

UCAPI handles are either volatile or persistent. A persistent handle

is guaranteed to remain valid until the application explicitly releases
it. Volatile handles are guaranteed to be valid only until the next
UCAPI operation is performed.

Some UCAPI functions automatically create persistent handles. But

for performance reasons, most UCAPI functions return volatile
handles. This results in significantly faster performance since new
handles are not allocated for each call - the previous handle is
reused “in place”. Applications can get a persistent handle for any
volatile handle on demand.

Unified Coverage API

A-4
The following rules explain in which conditions handles are
persistent or remain valid:

1. Handles returned by covdb_iterate and covdb_qualified

iterate are persistent and must be freed using
covdb_release_handle or memory leaks will occur.
2. A handle returned by covdb_scan on an iterator is guaranteed
to be valid only until the next call of covdb_scan,
covdb_iterate, or covdb_qualified_iterate.
3. Handles returned by covdb_load, covdb_merge, and
covdb_loadmerge are persistent and should be freed using
covdb_unload when the application is done with them.
4. Handles returned by covdb_get_handle and
covdb_get_qualified_handle are not persistent and may
be invalidated by the next call to either covdb_get_handle or
covdb_get_qualified handle.
5. All test-qualified handles become invalid when the test is
unloaded even if they have been made persistent by the
application.
6. All handles associated with a design become invalid when the
design in unloaded even if they have been made persistent by the
application.
7. Handles passed to an error callback function are persistent and
remain valid until released by the application using
covdb_release_handle.

Unified Coverage API

A-5
 UCAPI Setup and Compilation Requirements

UCAPI is supported on RedHat, Solaris, and SuSE. Depending upon

the OS, different compilation options will need to be passed to the
compiler. It is recommend that you use a setup script similar to the
following:

#!/bin/csh

#
# Common env var setup script for UCAPI examples
#

if (-f /etc/SuSE-release) then

#SuSE
set OTHER_FLAGS = -m32
set ARCH = suse9
else if (-f /etc/redhat-release) then
# REDHAT
set ARCH = linux
set OTHER_FLAGS = -m32
else
# Solaris
set OTHER_FLAGS = "-lsocket -lnsl"
set ARCH = sparcOS5
endif

# Make sure VCS_HOME is set to a directory

if (! -d $VCS_HOME) then
echo Error: VCS_HOME does not point to a valid directory
endif

# Make sure the current ARCH subdirectory exists

if (! -d $VCS_HOME/$ARCH) then
echo Error: this is an $ARCH machine but there is no VCS
installation for $ARCH at $VCS_HOME
endif

# Setup the LD_LIBRARY_PATH

if(! $?LD_LIBRARY_PATH) then

Unified Coverage API

A-6
 setenv LD_LIBRARY_PATH ${VCS_HOME}/${ARCH}/lib
else
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${VCS_HOME}/
${ARCH}/lib
endif

# A Summary
echo UCAPI Setup Complete
echo " VCS_HOME : " $VCS_HOME
echo " ARCH : " $ARCH
echo " LD_LIBRARY_PATH : " $LD_LIBRARY_PATH

As shown in the script, Redhat and SuSE require the -m32 option to
be passed to the C compiler, while Solaris requires the -lsocket
and -lnsl libraries to be included. The script also verifies that
VCS_HOME and the OS specific install of VCS is present on the
system before attempting to compile. This is required as the UCAPI
library is precompiled for different OS's and included within the VCS
install.

After the setup is complete, the c compiler, cc, is called with the
following arguments:

cc -g -I${VCS_HOME}/include -o ucapi_example ucapi_example.c

\
$VCS_HOME/$ARCH/lib/libucapi.a -ldl -lm $OTHER_FLAGS |& tee
compile.out
Note that $VCS_HOME/include will include necessary UCAPI
include files and $VCS_HOME/$ARCH/lib includes the precompiled
UCAPI library file. Any operating system specific flags will be
supplied by the setup script.

Unified Coverage API

A-7
 Enabling Error Reporting
By default, UCAPI will not print error messages to stdout.
However, this option can be enabled using the covdb_configure
call:

covdb_configure(covdbDisplayErrors, "true");
// setting to "false" disables / default
It is recommended that the above line of code be added to the
beginning of your UCAPI program.

Dynamic UCAPI Library

You can link UCAPI library dynamically, instead of linking it statically

with each version of VCS, and select different versions of UCAPI
depending on the version of VCS that created the coverage
database. Thus, you need not recompile your application and you
can maintain one executable.

Usage Model
To link the UCAPI library dynamically, use the following commands:

% setenv VCS_HOME <vcs_release_build>

% set path = ($VCS_HOME/bin $path)
% cc -I${VCS_HOME}/include \
-L`$VCS_HOME/bin/vcs -location`/ lib -lucapi <CC_FLAGS> \
<LD_FLAGS> -o <EXE> <C_FILES>

Unified Coverage API

A-8
Data Model

This section describes the UCAPI objects used to model the

contents of a coverage database.

The basic concept of UCAPI is that any coverage metric's objects

can be represented using a small set of building blocks. By defining
relations between these objects and setting properties (such as
name, relative weight, covered/not-covered) on them, the full set of
coverage data can be represented, while keeping the interface
simple, and the same for all metrics.

UCAPI Object

This section describes properties and relations that apply to all

UCAPI handles.

The covdbType property can be read from any UCAPI object

handle and it gives the UCAPI type of the object.

Any UCAPI object may have string or integer annotations on it, which
can be retrieved by using the covdb_get_annotation,
covdb_get_integer_annotation, and
covdb_get_qualified_annotation functions described in the
“Reading Annotations” section of the Coverage Technology
Reference Manual.

The supported annotations are described in the relevant sections of

this document.

Unified Coverage API

A-9
 Common Properties

This section describes properties that are supported on many UCAPI

handle types.

These properties can be read without a test handle:

• covdbLineNo – the line in the source file where the object’s text
begins.
• covdbName – the name of the object
• covdbFullName – the full name (including hierarchical name, if
applicable)
• covdbFileName – the source file in which this object is defined
The following properties may only be read from metric-qualified
objects, but does not require a test handle:

• covdbWeight – the relative weight of this coverable object.

• covdbCoverable – this property represents the number of
objects that are coverable. For a simple coverable object such as
a toggle sequence, the covdbCoverable value will be one. This
value may be greater than one for non-coverable objects, such
as covdbContainers, covdbSourceDefinitions, etc. It
may also be greater than one for a coverable object handle that
represents multiple distinct coverable objects.
• covdbCovGoal – the coverage percentage to be reached for this
coverable object. By default, this is 100.0.
• covdbCovCountGoal – the number of times an object must be
hit to count it as covered. By default, this is 1.

Unified Coverage API

A-10
• covdbAutomatic – non-zero if the object contains only
automatically-created sub-objects (for containers, crosses, and
sequences)
The following properties require a test handle to specify for which
test the data is being queried:

• covdbCovered – if the value of the covdbCovered property is

equal to the value of the covdbCoverable property, the handle's
contents are fully covered.
• covdbCovCount – the number of times the object has been
covered.
Note that covdbCovCount property can only be read if the
coverage tool that monitored the data had counting enabled.

The covdbCovStatus property may be read from metric-qualified

objects with or without a test handle. If it is read without a test handle,
then the covdbStatusCovered flag will never be set, since only a
test can mark an object covered.

The value of covdbCovStatus can be any combination of the

following:

• covdbStatusCovered – covered
• covdbStatusUnreachable – can never be covered, as when
a formal tool has proven it is impossible to cover
• covdbStatusIllegal – should be considered an error if the
object was covered
• covdbStatusExcludedAtCompileTime – the object was
marked excluded at compile time

Unified Coverage API

A-11
 • covdbStatusExcludedAtReportTime – the object was
marked excluded at report time
• covdbStatusExcluded – the object was marked excluded
either at report time or compile time – can be checked by
applications when it doesn't matter when the object was marked
excluded
Coverable objects with covdbStatusExcluded set (or
covdbStatusExcludedAtReportTime or
covdbStatusExcludedAtCompileTime) are ignored when
computing coverage scores – the covdbCoverable property will
not include them in its count, for example. However, they may still be
useful information. For example, some coverage tools will collect
expression coverage information for debugging or verification
analysis purposes that is not counted against a project’s coverage
goals. When coverable objects inside a container (or cross, or
sequence) are marked covdbStatusExcluded, they will be
excluded from the covdbCovered and covdbCoverable values
for that container (or cross or sequence).

The covdbValue property returns an integer value.

The covdbValueName property is used for covergroup bins and

FSM state values greater than 64-bit. It returns a string value.

Note that, while all of these properties may be retrieved from any
coverable object handle, all objects may not have useful information.
For example, a container object may have no associated file name
or line number, but that information may be retrieved from the objects
it contains. Whether or not this information is present for a given
object depends on the metric and the coverage tool that created that
object.

Unified Coverage API

A-12
Coverable Objects

Coverable objects are entities in the database that can be covered

or not covered. This small set of object types is sufficient to model
any type of coverage. All coverable objects are metric-qualified. That
means that each coverable object is associated with exactly one
metric.

Coverable objects are assigned names that are unique within the
region or container in which they are defined. Named objects, such
as signal bits, may contain a list of lower-level objects - for example,
a signal bit "x[1]" can have toggle objects representing the toggle
from 0 to 1 and the toggle from 1 to 0. In this example, the names of
those objects in UCAPI are "0 > 1" and "1 > 0".

Variant names are assigned by UCAPI using the name of the module
plus a parenthesized list of its parameter/generic values. For
example, if a module M has two variants for a given metric, its variant
names might be "M(p = 1)" and another variant "M(p = 2)". The
name of the unqualified module is "M". See the section titled “Source
Definition and Source Instance” for more information on variants.

In the diagrams for coverable objects in this section, only the special
properties and relations for each type are shown below.

Block
A block represents an atomic coverable object. The covdbType
property for a block object is covdbBlock. Block objects have no
additional relations on them. Depending on the metric, they may
have covdbFileName, covdbLineNo, and covdbName
properties.

Unified Coverage API

A-13
 Integer and Scalar Values
The value of an object of type covdbIntegerValue or
covdbScalarValue is read using the covdbValue property. For
integers, the value is the integer; for covdbScalarValues, the
value is one of the enumerated types covdbScalar0,
covdbScalar1, or covdbScalarX (see section 6.5).

For example:

covdbTypesT objty = covdb_get(objHdl, regHdl, NULL,

covdbType);
if (covdbIntegerValue == objty) {
int val = covdb_get(objHdl, regHdl, NULL, covdbValue);
} else if (covdbScalarValue == objty) {
covdbScalarValueT val =
covdb_get(objHdl, regHdl, NULL, covdbValue);
}

Unified Coverage API

A-14
Interval Values
A handle of type covdbIntervalValue contains two
covdbIntegerValue handles - one is the "from" value and the
other is the "to" value of the interval. For example, the interval [0, 10]
would be represented as shown follows:

covdbIntegerValue
covdbFromValue covdbValue: 0
covdbIntervalValue

covdbToValue covdbIntegerValue
covdbValue: 10

Vector Values
An object of type covdbVectorValue supports the
covdbValueName string property, which indicates the represented
value or range as a string.

Unified Coverage API

A-15
 Value Set
A covdbValueSet handle is used to model a value corresponding
to a coverable object.

A covdbValueSet handle is itself a coverable object. It is either

covered or not covered. From a covdbValueSet type handle,
applications can read the covdbValueName string property.

Sequence
An object of type covdbSequence contains an ordered collection of
other coverable objects and represents the sequential coverage of
each member object. For example, a sequence of value sets might
represent a signal taking on the specified sequence of values.

Note that a covdbSequence object itself is either covered or not

covered. The coverage statuses of its contents do not contribute to
its coverage status, because the sequence itself is an atomic
coverable object.

A coverable object in a covdbSequence's objects list has an

optional repeat count. This indicates that the object is repeated the
specified number of times in the sequence. The repeat count may be
a single integer or it may be a set of values, indicating the repetition
may be any of the specified numbers.

For example, if a testbench coverage transition bin is defined as:

Unified Coverage API

A-16
 coverpoint a
bin t1 : 1 -> 3 * (2..3)
This indicates that the value of a should transition from '1' to '3', then
from '3' to '3' again 1 or 2 additional times. In UCAPI, this is
represented using the covdbRepeat relation, as follows:

”t1”

covdbSequence
covdbObjects

covdbIntegerValue
covdbValue: 1

covdbIntegerValue
covdbValue: 3

covdbIntervalValue
covdbRepeat

covdbInterval
covdbObjects
optional
covdbRepeat
relation goes from covdbIntegerValue
sequence member
covdbFromValue covdbValue: 2
to repeat count
covdbIntegerValue
covdbToValue covdbValue: 3

When a value set is used as a repeat, it will have a value for

covdbRepeatType that is one of:

• covdbGoto
• covdbConsecutive

Unified Coverage API

A-17
 • covdbNonsecutive
When the value set is not a repeat value, the value of
covdbRepeatType will be -1.

Cross
An object of type covdbCross has the same structure as a
sequence, but the objects in the covdbObjects iterator are in no
particular order. A covdbCross object represents the simultaneous
coverage of its member objects.

Like a covdbSequence object, a covdbCross object is either

covered or not covered. The coverage statuses of its
covdbObjects do not contribute to its coverage status, because
the sequence itself is the coverage event.

Unified Coverage API

A-18
Stable Names for Coverable Objects

Code coverage automatically finds coverable objects in a design,

and monitors whether they are covered in simulation runs. These
objects are identified in an ad hoc way, depending on the type of
object. For example, signals in toggle coverage and machines in
finite-state machine coverage can be identified by signal names.
Statements, branches, and conditions are identified by line numbers.
Conditions are identified by a sequence number within a given
module (for example, 1st, 2nd, and 3rd). A path is named by the
sequence of basic blocks through which it flows.

Following are the two categories of coverable objects:

Coverable objects with stable names — An object name is stable, if

it is not sensitive to unrelated changes. For example, the name of a
signal for toggle or FSM coverage is stable. The name of the
coverable object can be changed by changing the signal name itself.

Coverable objects with unstable names — Object names that are

sensitive to unrelated changes in the design are unstable. For
example, any coverable object whose name depends on a source
line number has an unstable name, since even adding a comment
can change the name.

The stable names for coverable objects feature allows you to specify
stable names for coverable objects, whose names are unstable by
default.

Unified Coverage API

A-19
 Important:The support for stable names for coverable objects is
not currently available for VHDL.

Naming the Next Statement in a Module

A new pragma is introduced to allow you to name the next statement
in a module. For example:

//coverage name a1
if (a || (b && c))

In the example, the name a1 is assigned to the statement

if (a || (b && c)). Any conditions found in the statement can
be addressed starting with a1, rather than with a sequence number
in the module or source line number. Pragma should be just inserted
immediately before the condition.

You can attach a tag to a statement, but that statement may contain
multiple conditions. Each condition may also contain subconditions,
and each condition or subcondition will have a list of vectors.

Using Stable Names for Coverable Objects

Assigning stable names for coverable objects is useful for excluding
continuous conditions and vectors specified in el files for condition
coverage.

This is accomplished by providing tags in the source and generating

an el file using DVE for condition coverage metric. This metric will
contain the stable names and excluded vectors in the generated file.

Unified Coverage API

A-20
Specifying Tags in the Source
This section explains how tags are specified in the source, and how
coverable object names are derived from those tags.

Condition and Subcondition

Consider the following example:

//coverage name a1
if (a || (b && c)) {
…
}
The top-level condition is a || (b && c). It is broken down by code
coverage into two terms. Its name is a1:

a || (b && c)Condition a1
1 --2---

There is also a subcondition with two terms, named a1.1:

b && c Condition a1.1

1 2

Unified Coverage API

A-21
 Multiple Conditions in a Statement
Statements may contain more than one independent condition. For
example:

//coverage name mycond

x <= (a || (b && c)) ? ( (d && (e || f)) ? 1’b1 : 1’b0 ) : 1’b1;
There are two conditions, (a || (b && c)) and
(d && (e || f)) in the example. Both the conditions are part of
the same statement, but there is only one name pragma.

VCS will assign names based on the name. The first condition is
named as mycond:

a || (b && c) Condition mycond

1 --2---
b && c Condition mycond.1
1 2
The second condition is named as mycond.2:

d && (e || f) Condition mycond.2

1 --2---
e || f condition mycond.3
1 2
If there were additional conditions, then they would be named as
mycond.<serial number of condition on the line>. For
example, mycond.2, mycond.3, and so on.

Note:This additional naming only holds for one statement.

Unified Coverage API

A-22
Multiple Statements on a Line
If a single source line contains multiple statements, then only the first
statement will be named by a preceding pragma. For example:

//coverage name a2
x <= (a || b) ? 1’b0 : 1’b1; y = (c && d) ? 1’b0 : 1’b1;
a || b Condition a2
1 2
There is no name for the second condition c && d, since it occurs
in another statement that has no pragma preceding it. If you want to
assign a name to c && d, then you should put the statement on a
separate line:

//coverage name a2
x <= (a || b) ? 1’b0 : 1’b1;
//coverage name a3
y = (c && d) ? 1’b0 : 1’b1;
a || b Condition a2
1 2
c && d Condition a3
1 2

Unified Coverage API

A-23
 Names in the Generated Reports
Currently in the URG reports, condition ID numbers are shown if the
-cond ids option is specified. These appear inlined with the
condition coverage reports. For example, in URG, you can view the
following:

LINE 12
CONDITION_ID 1
STATEMENT if ((a || (b && c)))
1 --2---
EXPRESSION -1- -2-
0 0 | Not Covered
0 1 | Not Covered
1 0 | Not Covered
If the condition was named with a pragma in the source, then the
name will appear instead:

LINE 12
CONDITION_ID a1
STATEMENT if ((a || (b && c)))
1 --2---
EXPRESSION -1- -2-
0 0 | Not Covered
0 1 | Not Covered
1 0 | Not Covered
Subconditions will be named as described above. For example, the
subcondition b && c is labeled as a1.1:

LINE 12
CONDITION_ID a1.1
STATEMENT if ((a || (b && c)))
1 2
EXPRESSION -1- -2-
1 1 | Not Covered
0 1 | Not Covered
1 0 | Not Covered

Unified Coverage API

A-24
El File for Condition Coverage
If you use DVE to generate the el file, then the dumped file contains
the stable name for tagged conditions instead of the Integer IDs.
Expression IDs for subexpression in a new database may differ with
respect to the old database.

While applying the el file, if the module or instance checksum has

changed, then only the conditions with given stable names are
considered for exclusion. The remaining non-stable IDs are ignored.

Design Objects

Design objects are used to give context for coverable objects.

Design object handle types include covdbDesign, covdbTest,
covdbMetric, covdbTestName, covdbSourceDefinition,
and covdbSourceInstance. They do not have coverage state
themselves. They can be considered to be the framework on which
the coverable objects are distributed. The covdbName property can
be read from any design object handle.

Unified Coverage API

A-25
 Design and Test Name
A covdbDesign handle indicates a specific design in the coverage
database. A design contains a list of test names for which coverage
data exists.

The covdbTestName handles you get from

covdbAvailableTests are not the same as covdbTest handles
– applications cannot use them to get coverage data. But
applications can use their covdbName properties to load real
covdbTest handles.

Tests and Metrics

A covdbTest handle is a test whose data has been loaded into the
UCAPI interface. A test is the result of a single execution of a tool, or
the merged results of two or more executions.

Test handles are used to get test-qualified handles and data as

described in the introduction to this section. Handles to covdbTest
objects are accessed using the covdb_load, covdb_merge, and
covdb_loadmerge functions.

Metric handles have the covdbType covdbMetric. The only

property that can be read from a covdbMetric handle is its name,
using covdbName.

Unified Coverage API

A-26
The 1-to-many relation covdbMetrics may be iterated from a
covdbTest handle to get the list of metrics that have coverage data
in that test.

After tests are loaded, applications can iterate over the list of loaded
tests from a design handle using the covdbLoadedTests relation:

Source Definition and Source Instance

A covdbSourceDefinition handle represents a non-instantiated
design region, such as a Verilog module or a testbench coverage
group. A covdbSourceInstance represents a specific instance of
a covdbSourceDefinition.

Source regions represent the declarative regions from the design or

testbench - modules, entity-architectures, covergroups, packages -
and instances of those regions. Region handles can be unqualified,
metric-qualified, or test-qualified.

Unqualified regions are the skeleton of the design. You cannot see
any coverable objects in them because the list and shape of
coverable objects depend on a particular metric.

Metric-qualified region handles contain the coverable objects for

one specific metric. For example, a condition-qualified handle to a
module M will contain the coverable objects for conditions and
vectors found and monitored in M.

Unified Coverage API

A-27
 Test-qualified region handles are used for regions that only exist
within a specific test. For example, covergroup handles are always
test-qualified, since covergroups are used on a per-test basis - they
do not necessarily exist in every test.

The following properties may be read from any source definition or

instance:

• covdbFileName – the source file name of this definition or

instance.
• covdbLineNo – the line number where this definition or instance
is defined in its source file.
• covdbIsVerilog – non-zero if the definition or instance was
defined in Verilog.
• covdbIsVhdl – non-zero if the definition or instance was defined
in VHDL.
Source definitions may represent modules, entity-architectures, or
testbench coverage groups. Source instances may be instances of
any of these objects.

source instance
or definition

str: covdbFileName
int: covdbLineNo
int: covdbIsVerilog
int: covdbIsVhdl

Source definitions have a 1-to-many relation covdbInstances to

get an iterator of all instances of that definition. Similarly, source
instances have a 1-to-1 relation covdbDefinition to get the

Unified Coverage API

A-28
corresponding definition of an instance. Source instances also have
a covdbInstances relation from them; each instance in this list is
a child instance in the design hierarchy. The covdbParent relation
is the instance’s parent in the design hierarchy.

Properties such as covdbCovered and covdbCoverable may be

read directly from metric-qualified source region handles
(covdbCovered requires that a test handle be given) to compute
the coverage score for that metric. Any property that can be read
from an unqualified source definition or instance (such as
covdbFileName) can also be read from a metric-qualified source
definition or instance handle.

The covdbDefinitions and covdbInstances 1-to-many

relations may be used from a design handle to iterate over all
definitions or over the top-level instances in the design, respectively.
When these are qualified with a metric, the list of metric-qualified
definitions and top-level instances for that specified metric are
obtained.

The figures below examine different subsets of the relations between

different design region handles. First, is the structure of the
unqualified design. Without using any metric handles, an application
can walk through the base design – all definitions and all instances
of those definitions. Note that the covdbInstances relation from a
source definition gives its list of self-instances, whereas the
covdbInstances relation from a source instance gives its instance
children in the design hierarchy.

Unified Coverage API

A-29
 To get coverage information about a given metric in a given region,
an application must get a metric-qualified handle for that region. For
example, to get the list of FSMs in a module M, applications first get
the FSM metric-qualified handle to M.

There may be more than one FSM-qualified handle for M in a design,

due to parameter/generic values. In other words, the module M may
have been split by the FSM metric. Therefore, there is not
necessarily only a single FSM-qualified handle for M, and
applications use the metric-qualified 1-to-many relation
covdbDefinitions to walk through those handles, as shown in
the following figure:

Unified Coverage API

A-30
Similarly, unqualified covdbSourceInstance handles have
metric-qualified versions. However, since each instance is unique in
the design – it does not potentially represent multiple versions, like
covdbSourceDefinitions – there is always only one metric-
qualified source instance for each unqualified source instance
handle for a given metric. The metric-qualified source instance
handle is accessed using the metric-qualified 1-to-1 relation
covdbIdentity, and the unqualified instance handle is accessed
from the metric-qualified instance handle using covdbIdentity
with no qualifier:

Unified Coverage API

A-31
 unqualified

covdbSourceInstance

covdbInstances
covdbParent
covdbIdentity metricHdl,
covdbIdentity

covdbInstances
covdbParent

covdbSourceInstance

metric-qualified

There may be metric-qualified source instances or definitions with no

corresponding unqualified handle. For example, some instances
exist only for the assertions metric (bound-in OVA units, for
example). An application traversing only over the unqualified design
will not see these source regions. To distinguish them from metric-
qualified handles of unqualified source regions, these regions are
called metric-only regions.

If a metric-only region is attached to the unqualified design, it will be

visible only when iterating over the covdbInstances children of
the appropriate metric-qualified instance parent.

Unified Coverage API

A-32
For example, the following figure shows the unqualified and metric
qualified design hierarchies for an example design. The source
instances D and E are only visible in the metric-qualified design and
may not be directly accessed from any unqualified source handle.

If a metric-only region is separate from the design (such as a

testbench coverage covergroup declared outside of any module),
applications must use the metric-qualified 1-to-many relations
covdbDefinitions or covdbInstances from a test or design
handle – this will give access to the complete list of definitions or the
list of metric-qualified top-level instances. For example, in the
following figure, L, M, and N are Vera covergroups, accessed from a
test handle.

Unified Coverage API

A-33
 The following figure shows the complete set of relations used to
traverse the design.

unqualified design

covdbInstances
covdbDesign

covdbInstances

covdbSourceInstance
covdbDefinitions

covdbInstances
covdbSourceDefinition

covdbParent
covdbDefinition

covdbIdentity

metricHdl,

covdbIdentity
metricHdl,
covdbDefinitions

covdbIdentity
covdbDefinition
covdbSourceDefinition
covdbDefinitions
metricHdl,

covdbInstances

covdbSourceInstance
covdbParent

covdbInstances
metric-qualified design

Unified Coverage API

A-34
There is no metric-qualified covdbObjects list off of source
definitions or instances. All coverable objects are accessed from the
metric-qualified source definitions and instances. For example, to
get to the coverable objects list for a source definition:

Similarly, to get to the metric-qualified objects from a

covdbSourceInstance handle:

Unified Coverage API

A-35
 The covdbDeepCoverable and covdbDeepCovered properties
apply only to metric-qualified SourceInstance handles, and return
the coverable (covered) counts for the source instance and its entire
design subtree.

Unified Coverage API

A-36
 Test-Qualified Source Regions
Some metrics create test-qualified source regions that only exist
within a given test. For example, testbench coverage groups do not
exist in the unqualified design or even in the metric-qualified design
- they only exist in the test-qualified data.

The standard way to access test-qualified objects is from a test

handle using the metric handle as a qualifier. Assertions have a
special case where you can also access them from the DUT
hierarchy.

Like unqualified source definitions, test-qualified source definitions

may have multiple versions, due to variations between the instances
of the groups. These versions are accessed with the test-qualified
covdbDefinitions relation. As for HDL source definitions,
coverable objects are only accessed from the versions of definitions,
not from the master definition.

The following figure shows how test-qualified definitions are

accessed. Access is either from a testbench-qualified module
definition to the list of its test-qualified definitions or from a test
handle giving the list of all test-qualified definitions in a design.

Test-qualified instances may occur inside any HDL module instance,

or entirely outside the design hierarchy. They may occur inside an
HDL module instance even if they are not defined within the
corresponding HDL module1.

Test-qualified instances that are inside HDL module instances are

accessed by the test-qualified covdbObjects relation from the
metric-qualified HDL module instance handle.
1. Such as an SVTB covergroup defined in one module but instanced by another module - UCAPI supports
a covergroup defined in $root and instanced in the design, for example.

Unified Coverage API

A-37
 Test-qualified instances that are not within the HDL design hierarchy
are accessed from a covdbTest handle, using the metric-qualified
covdbInstances relation. The following figure shows how test-
qualified instances are accessed in UCAPI:

Covergroup definitions and instances have the same

covdbInstances/covdbParent relationship as HDL definitions
and instances.

Note: The only connection between covergroups and the design

hierarchy is the covdbParent relation from a group to
covdbSourceInstance.

Unified Coverage API

A-38
Other Objects

Container
Objects of type covdbContainer are abstractions that represent a
collection of coverable objects that logically belong together.
Containers may have two different lists in them:

• covdbObjects – a list of coverable objects or more

covdbContainers. The covered/coverable numbers for the
container is the sum of the covered/coverable numbers for all of
the contained objects.
• covdbComponents – a list of objects making up the structure of
the container. For example, a container representing a cross
declaration will have the list of coverpoints being crossed in its
covdbComponents list.
Containers whose objects are covdbCrosses or
covdbSequences may also have a covdbComponents list. If a
container has a covdbComponents list, it means that:

• Each cross or sequence in the container’s covdbObjects list

has the same number of objects in it.
• The container will have the same number of items in its
covdbComponents list as are in each item in its covdbObjects
list.
• Each item in each cross or sequence will correspond to the same
numbered item in the covdbComponents list.
The objects in the covdbComponents list do not contribute to the
coverage values for the container – they are provided only for
reference.

Unified Coverage API

A-39
 Containers are themselves not coverable objects – they contain
coverable objects in their covdbObjects lists. This is distinct from
Sequences and Crosses, each of which represent a single coverable
object.

In general, objects in containers are in source declaration order. This

is tool-dependent and metric-dependent.

Predefined Coverage Metrics

This section describes how UCAPI models each of the predefined

coverage metrics. Note that while the various metrics described
below use terms such as “basic block”, “condition” and “signal,”
these are not UCAPI object types, they are just describing what the
UCAPI types are being used to model. All object types are defined in
“Data Model” – there are no special object types for any metric.

Unified Coverage API

A-40
Line Coverage

Line or Statement coverage tracks which statements in the design

code were executed during simulation.

Statement coverage is organized in two levels, with always blocks/

processes at the top level. The type of an always block or process is
covdbContainer.

Within each always block/process container, statements are

organized into basic blocks, which are straight-line sections of code.
Basic blocks are also covdbContainer objects.

Within the basic block containers, each statement is modeled as a

covdbBlock object.

The organization of data for statement coverage is shown in the

following figure.
always block/process
source
instance or covdbContainer
definition covdbObjects

basic block

covdbContainer

statement
covdbObjects
covdbBlock

Unified Coverage API

A-41
 For example, consider the following code:

1 always@(posedge clk)
2 begin
3 if (x)
4 begin
5 a <= b;
6 c <= d;
7 end
8 else
9 begin
10 a <= d;
11 c <= b;
12 end
13 z <= w;
14 end
This is represented in UCAPI as follows:

Unified Coverage API

A-42
Unified Coverage API
A-43
 There is no representation of source lines as objects in UCAPI.
There may be multiple statements on a source line, or a statement
may extend across several lines. Source line information is available
using the covdbLineNo property on the covdbContainer and
covdbBlock handles.

Condition Coverage

Condition coverage tracks which values occurred in logical or bitwise

expressions in the design. A condition is that logical or bitwise
expression, and a vector is distinct set of values taken on by the
terms in the expression. Conditions are modeled as
covdbContainer objects, and vectors are modeled as
covdbCross objects containing value sets.

Conditions are organized into tables, such as logical conditions, non-

logical conditions, and event conditions. The covdbName of the
table container gives the type of conditions in that table.

table
source
instance or covdbContainer
definition covdbObjects
covdbObjects

condition
covdbObjects
covdbContainer

vector
covdbObjects
covdbCross value set

Unified Coverage API

A-44
The exact vectors in a given database depend on the compile-time
options used with VCS. For example, using the -cm_cond full flag
results in full truth tables (vectors) for every condition.

Note that there is no representation of which conditions are nested

textually within other conditions (such as the condition for an “if”
statement that is nested inside a “case” statement). However,
conditions can have sub-conditions within the same expression, and
in this case, the sub-condition will be in the list of objects for the
parent condition.

For example, if the following code is compiled in default condition

coverage in VCS:

if (a && (b || c))

The parent condition consists of two terms in a “&&” expression, “a”

and “(b || c)”. The sub-condition is the expression “b || c”,
which has two terms in a “||” expression, “b” and “c”. In this case,
UCAPI would represent the condition coverage objects as shown in
the following diagram (these conditions would be in the “logical”
conditions table, which is not shown in the diagram).

Unified Coverage API

A-45
 “a && (b || c)”
top-level condition
covdbContainer covdbCoverable = 6

“0 1”

covdbCross vectors for condition

covdbObjects

“a && (b || c)”

“1 0”

covdbCross

“1 1”

covdbCross

“b || c”
subcondition “b || c”
covdbContainer covdbCoverable = 3

“0 0”

covdbCross
covdbObjects

vectors for condition

“b || c”
“0 1”

covdbCross

“1 0”

covdbCross

Some conditions are expanded into multiple conditions. A bitwise

expression such as:

x = y & z;

Unified Coverage API

A-46
If x, y and z are 4-bit vectors, this represents four different
conditions:

y(0) & z(0)

y(1) & z(1)
y(2) & z(2)
y(3) & z(3)
This is represented in UCAPI as additional conditions inside the
main condition, as shown in the following figure. Note that these
“non-logical” conditions themselves do not have any vectors of their
own – only the single-bit conditions have vectors.

Note that “BIT 0 of y(2:5) & z(2:5)” is the expression for

“y(2) & z(2)”, but UCAPI does not provide the original indices.

Unified Coverage API

A-47
 As described in “Value Set” , values are not always integers. In
condition coverage, “don’t care” values may be present in vectors,
and will have the value type covdbScalarValue and a
covdbValue of covdbValueX.

top-level branch statement

branch-qualified
covdbContainer
instance or
int: covdbWidth
variant covdbObjects

covdbComponents
width is number
of branch terms
covdbObjects
branch term

covdbBlock
branch vector

covdbCross

term value

value set or
covdbBlock

Unified Coverage API

A-48
Branch Coverage

Branch coverage monitors the execution of conditional statements in

your design. Conditional statements include if/else statements,
case statements, and the ternary operator “?:”

Branch coverage differs from condition coverage in that branch

coverage does not track all the ways in which a Boolean condition
can be true or false – it only tracks whether it is true or false. Branch
coverage also tracks all conditions, rather than the subset of
complex conditions that condition coverage monitors. Branch
coverage also tracks case statements, which condition coverage
ignores.

The coverable objects for branch coverage are all crosses of value
sets. For example, consider a branch that is covered when the
following expression is true:

(r1 == 1’b1) && (r2 && r3) && (r5 && r6)
That branch would be modeled as a cross of these three terms, each
of which is a covdbIntegerValue value set:

cross for
covdbCross (r1 == 1’b1) && (r2 && r3) && (r5 && r6)

covdbValue = 1
covdbIntegerValue covdbName = “1’b1 ”

covdbValue = 1
covdbIntegerValue
covdbName = “1 ”

covdbValue = 1
covdbIntegerValue covdbName = “1 ”

Unified Coverage API

A-49
 Branch coverage is organized into disjoint sections of each
always/initial block or process by the top-level branch statements.
For example, the following code has two top-level branch
statements:

1 initial
2 begin
3 case (r1) First top-level statement
4 1'b1 : if (r2 && r3)
5 r4 = 1'b1;
6 1'b0 : if (r7 && r8)
7 r9 = r10 ? 1'b0 : 1'b1;
8 1'bx : $display("x");
9 default : $display("no op");
10 endcase
11
12 r9 = (r10 && r11) ? 1'b0 : 1'b1; Second top-level
statement
13 end

Unified Coverage API

A-50
Since the branches in each top-level statement do not interact,
UCAPI collects their branches into separate containers underneath
the source region handle. The model for objects inside a branch
coverage region is as follows:

For the sample code shown above, the UCAPI model is:

Unified Coverage API

A-51
 .

Unified Coverage API

A-52
 Note that in Verilog, case alternatives do not have to be constant
values. For example, the following is legal:

case(1)
vec[0]: …
vec[1]: …
vec[2]: …
endcase

In this example, the case alternatives are not constant values, and
therefore cannot be modeled as value sets. In this case,
covdbBlock handles are used for the case alternatives. Note that
the argument to the case conditional (“1”) is when possible modeled
as a value set:

branch-qualified
instance or variant
covdbComponents

covdbIntegerValue covdbName = “1”

covdbObjects

covdbValue = 1

covdbContainer
covdbObjects

covdbCross cross for 1 == vec[0]

covdbBlock covdbName = “vec[0]”

covdbCross cross for 1 == vec[1]

covdbBlock covdbName = “vec[1]”

covdbCross cross for 1 == vec[2]

covdbBlock covdbName = “vec[2]”

Unified Coverage API

A-53
 Ternary operators are also monitored by branch coverage. In UCAPI,
a ternary conditional is treated the same as an “if/else” condition.
For example:

9 if (z)
10 x <= a ? b : c;
11 else
12 x <= 1’b0;

Turns into this in UCAPI:

branch-qualified
covdbComponents

instance or variant

covdbBlock “z”
covdbObjects

covdbBlock “a”

covdbContainer
covdbObjects

cross for z && a

covdbCross covdbLineNo = 10

covdbIntegerValue
covdbValue = 1
covdbName = “1”
covdbIntegerValue covdbValue = 1
covdbName = “1”

covdbCross cross for z && !a

covdbLineNo = 10
covdbValue = 1
covdbIntegerValue
covdbName = “1”
covdbIntegerValue covdbValue = 0
covdbName = “0”
cross for !z
covdbCross covdbLineNo = 12

covdbIntegerValue
covdbValue = 0
covdbName = “0”
covdbScalarValue covdbValue = covdbValueX
covdbName = “-”

Unified Coverage API

A-54
Finite State Machine Coverage

Finite State Machine (FSM) coverage models three distinct types of

coverable objects.

Whether the FSM:

- entered each possible state (state coverage)
- state followed each possible state transition (transition
coverage)
- went through all possible sequences of states from the initial
state(s) (sequence coverage)
In UCAPI, state coverage is modeled with value sets, and transition
and sequence coverage are modeled with covdbSequence objects
containing value sets. The covdbCoverable property of the FSM
container is the total number of states, transitions, and sequences for
that FSM.

The covdbFileName and covdbLineNo properties may be read

from the FSM handles (of type covdbContainer), state value sets,
and transition covdbSequence handles. No other FSM objects
have source information.

State and sequence objects are all considered to be used for

information only and do not count for covdbCoverable and
covdbCovered numbers for FSM coverage. Each coverable object
for states and sequences will have covdbExcluded set in its
covdbCovStatus property.

Unified Coverage API

A-55
 FSM
source
instance or covdbContainer
definition covdbObjects

state states
covdbObjects

covdbObjects
value set covdbContainer
covdbObjects

transition transitions
covdbObjects
covdbSequence covdbContainer

sequence sequences
covdbObjects
covdbSequence covdbContainer

For example, consider an FSM encoded as:

always @(posedge clk) begin

case (state)
`IDLE: if (go) next = `READ else next = `IDLE;
`READ: if (go) next = `DLY else next = `IDLE;
`DLY: if (!go) next = `IDLE;
else if (ws) next = `READ;
else next = `DONE;
`DONE: next = `IDLE;
endcase
end
The FSM has four states and seven possible transitions:

States:
IDLE
READ
DLY
DONE

Unified Coverage API

A-56
 Transitions:
IDLE->READ
READ->IDLE
READ->DLY
DLY->IDLE
DLY->READ
DLY->DONE
DONE->IDLE
The states in UCAPI look like:

states
covdbCoverable = 4
covdbContainer

covdbName “IDLE”
covdbIntegerValue covdbIntValue 0
covdbObjects

covdbName “READ”
covdbIntegerValue covdbIntValue 1

covdbName “DLY”
covdbIntegerValue covdbIntValue 2

covdbName “DONE”
covdbIntegerValue covdbIntValue 3

The transitions are represented as covdbSequences, as shown in

the following illustration:

Unified Coverage API

A-57
 transitions

covdbContainer covdbCoverable = 7 (not all are shown here)

covdbName
covdbSequence “IDLE -> READ”

covdbName “IDLE”
covdbIntegerValue covdbIntValue 0

covdbName “READ”
covdbIntegerValue covdbIntValue 1

covdbName
covdbSequence “READ -> IDLE”

covdbName “READ”
covdbIntegerValue covdbIntValue 1

covdbName “IDLE”
covdbIntegerValue covdbIntValue 0

other five
transitions …

The FSM’s sequences are covdbSequence objects, but with

potentially more than two objects. For example, the sequence READ
-> DLY > IDLE looks like this:

Unified Coverage API

A-58
sequences

covdbContainer

covdbName
covdbSequence “READ -> DLY -> IDLE”

covdbName “READ”
covdbIntegerValue covdbIntValue 1

covdbName “DLY”
covdbIntegerValue covdbIntValue 2

covdbName “IDLE”
covdbIntegerValue covdbIntValue 0

other sequenc es …

Unified Coverage API

A-59
 Toggle Coverage

Toggle coverage in UCAPI is organized into tables, each of which

contain signals, which are modeled as covdbContainers.

The tables are groupings of signals by category, such as “signal” and

“port”. The covdbName property of the table container is the
category of all signals in that table (e.g, “ports”).

Each signal’s container has a list of sub-containers in it, representing

bits of that signal. Each sub-container has two covdbSequences in
it, one representing the transition from 0 to 1, and one representing
the transition from 1 to 0.

Signals and MDA dimension container objects for toggle coverage

have the annotations “lsb” and “msb” set on them. These return a
string given the least-significant bit and most-significant bit indices,
respectively, as strings.

The covdbCoverable of a given signal for toggle coverage is twice

the number of distinct bits for that signal – that is, the
covdbCoverable is the number of covdbSequences under the
container for the signal. The covdbWidth property is the total
number of bits.

Unified Coverage API

A-60
 signal table
source
instance or covdbContainer contains signals
definition covdbObjects

covdbObjects

signal covdbContainer contains bit- & part-selects

bit toggle 0->1 or 1->0 value 0 or 1

covdbObjects

covdbContainer covdbSequence value set

dimension dimension has either containers

for next innermost dimension or
words
covdbContainer
word

covdbBlock

For example, consider a module “M” with these signals:

reg x[3:0];
input y;
wire y;

Unified Coverage API

A-61
 Now assume the toggle coverage data is as shown in the following
table:

Table A-1
Signals 0->1 1->0
x[3] Y N
x[2:1] Y Y
x[0] N Y
y Y N

The toggle coverage structure would look like the following diagram.
(In this figure, only some of the covdbSequence and value set
children are shown.)

Now consider a case with a multiple-dimension array signal:

reg [2:0] mda[3:0][1:0];

The data looks like the following (only the handles containing
mda[1][0][2] are shown):

Unified Coverage API

A-62
Unified Coverage API
A-63
 Assertion Coverage

Assertion coverage includes coverage information about assertions,

cover properties and sequences. The covdbName of the assertion
coverage metric handle is Assert.

Assertion coverage objects may be accessed from the modules and

instances in which they are defined, or from a loaded test handle
directly using covdb_qualified_iterate with the assertion
coverage metric handle as the qualifier (see “Test-Qualified Source
Regions” ).

The assertion metric is used by UCAPI to represent assertions,

cover properties and cover sequences. To determine which type of
assertion object corresponds to a given handle, use this function:

// Enum for the type of assertion

typedef enum {

ASSERTION_TYPE_UNKNOWN = -1,

ASSERTION_TYPE = 0,

COVER_PROPERTY = 1,

COVER_SEQUENCE = 2

} AssertionType;

/**

* function to get the type of assert (unknown, cover property or cover

* sequence)

* @return AssertionType @see AssertionType

*/

AssertionType covdb_get_assert_type(covdbHandle assertHdl);

Unified Coverage API

A-64
There are three types of assertion coverage objects: assertions,
cover properties, and cover sequences. The handles for these
different assertion coverage objects are organized into
covdbContainers in each source definition and instance.

Assertions are modeled in UCAPI as covdbContainers. The

covdbBlock objects in these containers represent the different type
of information collected. For example, there is a covdbBlock
representing success, a covdbBlock for failures, and another for
attempts. The covdbName of each covdbBlock indicates what it
represents.

All but one of the covdbBlock objects will have the

covdbStatusExcluded flag set, indicating they should be ignored
for coverage. For example, for assertions there will be a block for
attempts. The number of attempts is not used to compute the
coverage score, so this block is marked excluded. The assertion is
covered if its non-excluded covdbBlock object is covered.

The covdbCovCount may be read from each of these

covdbBlock objects to get the number of times each type of thing
occurred. Non-excluded covdbBlocks are covered if their
covdbCovCount is greater than or equal to the assertion’s
covdbCovCountGoal.

SystemVerilog assertions and cover directives will always be in the

assert-qualified module definitions and instances in the
covdbObjects list. OpenVera Assertions are contained in test-
qualified source regions, as discussed in “Test-Qualified Source
Regions” .

Unified Coverage API

A-65
 The covdbFileName and covdbLineNo properties may be read
from handles of type covdbContainer for assertion coverage.
There is no source information for covdbBlock handles in assertion
coverage.

The following diagram shows the model for assertion coverage:

Unified Coverage API

A-66
For example, consider the following assertion:

clock posedge clk {

event fevent : data[0] *[1..] data[2] #1 data[3];
}
assert fassert : check(fevent);
The following diagram shows the UCAPI structure for this assertion
with basic coverage. Note that there are five covdbBlocks under
the assertion, but that only the realsuccesses block counts for
coverage, since the other blocks are all marked excluded. These
other blocks (e.g., attempts, incompletes) are in the database,
but are never considered for coverage.

In this example that only the paths where the first range (#[1..])
had value 1 or 2 was the assertion covered. It was covered one time
for the value 1 and three times for the value 2. You can see this as
the covdbCovCount of the individual covdbCross bin handles.

Unified Coverage API

A-67
Unified Coverage API
A-68
Now consider another example, a cover property with multiple time
intervals in it:

property p;
int var_l;
@clk
a ##[2:4] b or
(a, var_l=ex) ##1 c[*1:$] ##1 !a && (ex==var_l)[*1:8]
##1 a;
endproperty

Since this property has a top-level or, it will have two containers for
paths under the assertion container. Also, since the second term has
two time intervals in it, the crosses contains two values each.

Unified Coverage API

A-69
Unified Coverage API
A-70
You can read the category and severity failures for a given assertion
handle using the covdb_get_annotation function:

char *category = covdb_get_annotation(assertionHdl,

“FCOV_ASSERT_CATEGORY”); char *severity =
covdb_get_annotation(assertionHdl,
“FCOV_ASSERT_SEVERITY”);
For cover properties, there are four blocks under the property,
namely, "attempts", "failures", "allsuccesses" and "incompletes".
Additionally, if vacuous passes are monitored at runtime using the
switch -assert vacuous, a fifth block, named
"vacuoussuccesses" will be added to the container (as shown in the
blue rectangle in the figure) as follows:

Unified Coverage API

A-71
Unified Coverage API
A-72
Testbench Coverage

Testbench coverage monitors covergroup coverage during

simulation. The covdbName of the testbench coverage metric
handle is testbench.

Testbench coverage monitors the bins specified in the covergroups

in the testbench and DUT. These bins are one of three different
types: states (value sets), transitions (modeled as covdbSequence
objects), and crosses (covdbCross objects). For testbench
coverage, the containers of these coverable objects are called bin
tables.

The covdbFileName and covdbLineNo properties may be read

from group, group instance, point and cross declaration handles for
testbench coverage. No other handle types for testbench coverage
have source information. The covdbWidth property may be read
from coverpoint and cross container handles. Lower-level handles in
the testbench metric do not support the covdbWidth property.

When testbench covergroups are defined within HDL modules, you

can instruct UCAPI to create a covdbParent pointer from each
covergroup handle back to its design hierarchy parent module. To do
so, enable the covdbShowGroupsInDesign configuration before
loading any tests:

covdb_qualified_configure(designHdl,
covdbShowGroupsInDesign, "1");

If the covdbShowGroupsInDesign configuration is set before

loading tests, every covergroup shows two variants: original shape
and cumulative shape. A cumulative shape is a union of the
covergroup variants with same checksum. This shape shows
cumulative coverage at the module level.

Unified Coverage API

A-73
 For example: The table below shows a design, shapes created at RT,
and cumulative shape created with covdbShowGroupsInDesign:

Table A-2 Variants When covdbShowGroupsInDesign is Set

Design Shapes Created at Cumulative Shape Created With
RT covdbShowGroupsInDesign
module top;
covergroup CG1; top::CG1 top::CG1
bot b1(); top.b1::CG2
bot b2(); top.b2::CG2 bot::CG2
endmodule
top::CG1 is a copy of the original
module bot; shape top::CG1
covergroup CG2;
endmodule bot::CG2's score is computed as
union of top.b1::CG and top.b2::CG

The naming convention of an original shape is as follows:

<Hierarchical_scope_name>::<class_name>::<CG_name[SHAPE{…}
]>

The naming convention of the cumulative shape is as follows:

<scope_name>::<class_name>::<CG_name[SHAPE{…}]>

In case of a package and top module, the first part of both the formats
is same as there is no difference between its scope name and
hierarchical scope name. However for other cases, its scope name
and hierarchical scope name are different.

In the above example, both covergroups are defined in the package

and top module, therefore, the name of cumulative and original
shape appears to be same.

To look for the difference between the names of the shapes, you
need to look at their variants. For example, see the variants name of
cg_fsm in the code snippet below:

Unified Coverage API

A-74
Group name s::test_class::cg0, full name s::test_class::cg0
Var s::test_class::cg0, full name s::test_class::cg0

Parent is s

Var s::test_class::cg0, full name s::test_class::cg0

Parent is s

Group name fsm::cg_fsm, full name fsm::cg_fsm

Var top.dut::cg_fsm, full name top.dut::cg_fsm

Parent is top.dut

Var fsm::cg_fsm, full name fsm::cg_fsm

Parent is fsm

Group name top::cg_addr, full name top::cg_addr

Var top::cg_addr, full name top::cg_addr

Parent is top

Var top::cg_addr, full name top::cg_add

To distinguish the cumulative shapes from the original shapes,

check the type of their parent. If the type of the parent is
covdbSourceInstance then the covergroup variant is an original
shape. If the type of the parent is covdbSourceDefinition then the
covergroup variant is a cumulative shape. For example, see the
code snippet below:

covdbHandle grpSrcDefs = covdb_qualified_iterate(_testHandle, tbMetricHan-

dle, covdbDefinitions);
while (covdbHandle grpSrc = covdb_scan(grpSrcDefs)) {
covdbHandle grpDefs = covdb_qualified_iterate(grpSrc, _testHandle,
covdbDefinitions);
while (covdbHandle grp = covdb_scan(grpDefs)) {
grp = covdb_make_persistent_handle(grp);
covdbHandle parentHandle = covdb_get_handle(grp, covdbParent);
if (NULL == parentHandle) {
// test-qualified covergroup
……
} else {
// design-qualified covergroup
int type = covdb_get(parentHandle, NULL, NULL, covdbType);

Unified Coverage API

A-75
 if (covdbSourceInstance == type) {
//it is an original covergroup variant at module instance
//level
….
} else {
//type is covdbSourceDefinition
//cumulative shape to be reported at module level
…
}
}

The following figures show the structure of testbench coverage

within a test-qualified group or instance definition.

Figure A-1 shows how a user-defined coverpoint is modeled.

Figure A-1 User-Defined Coverpoint Bins

Unified Coverage API

A-76
 Figure A-2 shows a coverpoint with automatically generated bins.

Figure A-2 Automatic Coverpoint Bins

Unified Coverage API

A-77
 Figure A-3 shows a cross, where the two coverpoints crossed are
the ones from the previous example:

Figure A-3 Automatic Cross Bins

Unified Coverage API

A-78
Setting Hit Count on Bins
You can set hit count on user bins, compressed and uncompressed
auto bins for coverpoint and cross.

Usage
covdb_set(binHandle, coverGroupHandle, testHandle,
covdbCovCount, hitCount)
covdb_get(binHandle, coverGroupHandle, testHandle,
covdbCovCount)
Hit count can be set on bin handles at definition or instance level.

It's allowed at definition level only when per_instance is off. Because,

definition level hit count should be equal to the sum of hit counts of
the bin in all instances. If it's set at definition level, you can't distribute
it among instances. So, you get an error when you try to set the hit
count on definition level bin handles keeping per_instance ON.

You can set hit count on instance level bin handles. The increase or
decrease in hit count is populated to the corresponding bin at the
definition level.

Set covdbStatusCovered
To mark a bin as covered, increment the hit count of that bin to the
coverpoint's least value.

Usage
covdb_set(binHandle, coverGroupHandle, testHandle,
covdbCovStatus,covdbStatusCovered)
covdb_get(binHandle, coverGroupHandle, testHandle,
covdbCovStatus)

Unified Coverage API

A-79
 Compressed and Uncompressed Bins
Each bin handle has the COVERPOINT_BIN annotation set to a one-
character string containing only the character for 0, or a one-
character string containing only the character for 1. If it is set to 1, it
means the bin is a regular bin. If it is set to 0, it means the bin is a
compressed bin. Compressed bins have a covdbCoverable value
greater than 1 (the value is the number of bins that were
compressed).

The covdbObjects property gives an iterator over individual

coverpoint bins of compressed coverpoint bin handle. In case of
compressed cross bins, there are two kinds of iterators:

• Iterating over individual uncompressed auto-cross bins. The

covdbObjects property returns this iterator.
• Iterating over constituent coverpoint bins. The
covdbComponents property returns this iterator.
For example, the auto[1]-auto[3] bin is a compressed bin made up
of three uncompressed bins, one each for the values 1, 2, and 3.
The compressed bin is a covdbBlock, and its covdbObjects list is the
list of bins that make it up (see the figure below).

Unified Coverage API

A-80
Limitations
Currently, only automatically-generated cross bins are represented
as covdbCross objects. User-defined cross bins are represented
as covdbBlock objects. All transitions are currently represented as
covdbBlock objects.

The covdbComponents list is currently only available for

automatically generated crosses, not for user-defined crosses.

Unified Coverage API

A-81
 The covdb_get_str API may not provide the names of auto cross
bins correctly. For accessing the name of the auto bin, see
“Accessing the Name of Auto Cross Bin” .

Accessing the Name of Auto Cross Bin

The name of an auto bin of a cross can be constructed from its
individual components through iterating over the
covdbComponents relation where each component is either a
coverpoint or another cross (if the cross is a cross-of-cross). The full
name of the cross bin can be constructed by appending the names
of its components with the chosen delimiters. This approach of
obtaining the name can best be used to itemize the representation of
auto cross bin. The auto bins of a cross can be represented as a
matrix, with each row representing a bin combination and each
column forming a component of the bin.

You can use following code snippet to access the name of an auto
cross bin.

char* getAutoCrossBinName(covdbHandle bin, char *delimiter)

{
string bin_name_str;
char *bin_name;
int isFirst = 1;

covdbHandle comp, compI = covdb_iterate(bin,

covdbComponents);
while((comp = covdb_scan(compI))
{
if(!isFirst)
bin_name_str.append(delimiter); // Delimiter
between components
isFirst = 0;
bin_name_str.append(covdb_get_str(comp,
covdbName)); // Append the component name
}

Unified Coverage API

A-82
 bin_name = strdup(bin_name_str.c_ str());
return bin_name;
}

Loading a Design

Note that when using VCS, designs are loaded with the
covdb_load() function. The following function, loadDesign,
accepts a string argument representing the path to the design and
then loads the design.

covdbHandle loadDesign(char *design)

{
covdbHandle designHandle = covdb_load(covdbDesign, NULL,
design);
if(!designHandle)
printf("Error: could not load design %s\n", design);
else
printf("Info: loaded design %s\n", design);
return designHandle;
}
// example of calling the function:
covdbHandle designHandle = loadDesign("simv"); //
Note:
A handle returned by covdb_load is persistent until unloaded
by covdb_unload.

Unified Coverage API

A-83
 Available Tests

Loading a design does not load the test(s) associated with a design.
Given a valid design handle, the available tests can be accessed.

Calling covdb_iterate() with covdbAvailableTests returns

an iterator to a list of the testnames associated with the design.
These tests are not automatically loaded; they must be loaded with
one of the API functions. The following C function shows the
available tests associated with a design handle.

void showAvailableTests(covdbHandle designHandle)

{
covdbHandle availableTestName availableTestNameIterator;
availableTestNameIterator = covdb_iterate(designHandle,
covdbAvailableTests);
printf("Design: %s has the following tests:\n",
covdb_get_str(designHandle, covdbName));
while(availableTestName =
covdb_scan(availableTestNameIterator))
printf("\ttest: %s\n", covdb_get_str(availableTestName,
covdbName));
covdb_release_handle(availableTestNameIterator);
}

Unified Coverage API

A-84
Loading Tests

Tests are not automatically loaded with a design. Once a design

handle has been obtained, the handle is used to access the list of
test names and then load one or more of the tests. A single test is
loaded with covdb_load while two or more tests can be loaded with
successive calls to covdb_loadmerge.

Loading a single test requires that a valid design handle and test
name string be available:

/* load a single test from a design */

covdbHandle testHandle;
testHandle = covdb_load(covdbTest, designHandle, testName);
if(!testHandle) {
printf("UCAPI Error: could not load test %s\n", testName);
exit(1);
}
Loading and merging two or more tests first requires the loading of a
single test with covdb_load followed by multiple calls to
covdb_loadmerge to load and merge the additional tests' data.
The following example shows a function used to load all the available
tests related to a design. It is assumed that all of the test data is
contained in one location with the design data.

covdbHandle loadTests(covdbHandle designHandle)

{
covdbHandle availableTestName; availableTestNameIterator;
covdbHandle mergedTest;

// get an iterator to the list of availableTests

availableTestNameIterator = covdb_iterate(designHandle,
covdbAvailableTests);

// Using the iterator get the first available test

availableTestName =
covdb_scan(availableTestNameIterator);

Unified Coverage API

A-85
 // load the first test
mergedTest = covdb_load(covdbTest, designHandle, ,
availableTestName);
if(mergedTest)
printf("Successfully loaded test %0s\n",
covdb_get_str(availableTestName, covdbName);
else
{
printf("Unable to load test\n");
return NULL;
}

// using loadmerge load and merge the remaining tests

while((availableTestName =
covdb_scan(availableTestNameIterator)))
{
mergedTest = covdb_loadmerge(covdbTest, mergedTest,
availableTestName);
if(!mergedTest)
printf("Could not load test %s\n",
covdb_get_str(availableTestName, covdbName));
else
printf("Successfully loaded and merged test %s\n",
covdb_get_str(availableTestName,
covdbName);
}
covdb_release_handle(availableTestNameIterator);
return mergedTest;
}
The UCAPI method covdb_release_handle() function is called
to release the iterator availableTestNameIterator. This is
done because a handle returned from a covdb_iterate() call is
persistent. Releasing the handle frees the associated memory and
prevents a memory leak.

Unified Coverage API

A-86
Coverage Correlation: Determining Which Test Covered
an Object
This section describes how to use UCAPI to find which test covered
a given coverable object. When you merge two or more tests in
UCAPI, the information about which test covered which object is
retained. You can recover it by using the covdbTests relation from
a coverable object handle.

Note:
This feature is limited to testbench and assertion coverage metrics
only.

For example:

design = covdb_load(covdbDesign, NULL, “mysimv”);

test = covdb_load(covdbTest, design, “mysimv/test1”);
test = covdb_loadmerge(covdbTest, test, “mysimv/test2”);
…
tstsIter = covdb_qualified_object_iterate(binHdl, groupHdl,
testHdl,covdbTests);
while((testCt = covdb_scan(tstsIter))) {
printf("Bin %s was covered by", covdb_get_str(binhdl,
covdbName));
printf(" test %s %d times\n", covdb_get_str(testCt,
covdbName), covdb_get(testCt, grpHdl, testHdl,
covdbValue));covdb_release_handle(tstsIter);

Unified Coverage API

A-87
 The handle returned by covdb_scan for testsIter is a
covdbIntegerValue handle. Its covdbName is the name of the
test that was loaded/loadmerged. Its covdbValue is the hit count for
binHdl for that test. For example, if a bin “b1” had the following hits
in these different tests:

test hits
mysimv/test15
mysimv/test20
mysimv/test32
mysimv/test40
Then the above code would print the following for b1:

Bin b1 was covered by test mysimv/test1 5 times

Bin b1 was covered by test mysimv/test3 2 times

The tests that did not cover the bin are not given in the iterator. All
the metrics and modes do not track the hit counts. Some will only
record that a given object was covered or not covered in a given test.
In this case, each test in the list will have a count value of 1 or it will
not be in the list.

Metrics or modes that do not support this relation will return a NULL
iterator handle when covdb_qualified_iterate is called.
However, no error will be flagged. Once a merged test handle is
saved using covdb_save, the information about which of the tests
that were loaded or loadmerged covered which object, is discarded
by default. That is, if you then reload the saved test, no data about
the individual tests that were merged to create it will have been
retained. You can change this behavior by using
covdb_configure to set covdbKeepTestInfo to true before you
load the initial design as follows:

covdb_configure(design, covdbKeepTestInfo,
“true”);

Unified Coverage API

A-88
You can use the coverage API covdbMaxTestsPerCoverable to
set a maximum number of tests for each coverable object. The
default value of this API is "3". You can also set
covdbMaxTestCoverable to override the default value. If set to
non-zero, the value that you set for this API becomes the maximum
number of tests preserved for each object when multiple tests are
loadmerged. For more information about this API, see Chapter,
"Unified Coverage API Functions" in the Coverage Technology
Reference Manual.

Unified Coverage API

A-89
Unified Coverage API
A-90
Index

Symbols in line coverage 9

Chart Linkage 11
-cm_line contassign 9
checksum 13
-cm_noconst 2
–cm branch 40
&&
in condition coverage 15 -cm_branch values 33, 34
-cm_line contassign 9
-cm_noconst 2
A -cm_seqnoconst 10, 11, 12
adaptive exclusion 62 –cm_tgl fullintf 24
annotated source code 26, 37 –cm_tgl portsonly 25
assertion argument to the -cm option 4, 48 Code coverage, metrics reported 2
assertion coverage compiling for coverage 3
specifying 4, 48 cond argument to the -cm option 4, 47
condition coverage
defined 13
B specifying 4, 47
blocks Condition Coverage Detail Window 30
code blocks in line coverage 6
conditional expression
in line coverage 4, 10 in condition coverage 13
branch argument to the -cm option 4, 48 conditional operator
Branch Coverage 37 in condition coverage 13
branch coverage 31, 33 conditional statements 31
specifying 4, 48 constant 37, 38
continuous assignment statements
in condition coverage 15
C cost-based grading 11
case statement
coverage

1
 report-time exclusion 120 -flex_merge reference 31
Coverage Detail Window 21 forever statement
Coverage Map Window 19 in line coverage 9
coverage report, FSM 37 fsm argument to the -cm option 4, 48
Coverage Table Window 16 FSM coverage 37
coverage, toggle report 23 criteria for an FSM 27
coverage, viewing results 15 specifying 4, 48
coveritem 37 FSM transition mode 34
CPUtime 61 fullexclude_lp.tb_def 113
Customizing URG Charts 5 fullexclude_module.assert 114, 116
fullexclude.assert 114, 115
fullexclude.branch 102
D fullexclude.cond 98
-dbname 65 fullexclude.fsm 104
-diag noconst 43 fullexclude.line 92
drop 31 fullexclude.tb_def 109, 112
-dump full_exclusions 88 fullexclude.tb_inst 109, 112
-dump full_exclusions assert 114 fullexclude.tgl 94
-dump full_exclusions group 109
DVE 20
detail pane 56
G
starting 9, 3 generate 43
Generating Trend Charts 3
-grade cost 6
E gradedtests.txt 14
environment variable groups
URG_FAKE_TIME 10 creating coverage 22
environment variables
URG_NO_SESSION_XML 10
-excl_resolve on 49 H
exclusion files 88 Hierarchical Linkage 21
exclusion, commands 4

I
F if statement
filter coverage display 59 in line coverage 4, 8
-flex_merge 18 if-else statement
-flex_merge drop 33 in line coverage 8
invokingDVE 9, 3

2
L P
line argument to the -cm option 4, 47 pages, report generated 2
line coverage –parallel –grade 11
defined 3 port connection in Instance Arrays 26
difference from statement coverage 7 procedural assignment statement
line coverage, displaying 26 in condition coverage 13
load coverage session 11 procedural assignment statements
Loading and Saving Sessions 11 in condition coverage 15
propagation of constants 26

M
macro instantiations R
Coverage 13 recalculate the coverage 46
map window, coverage 19 report pages 2
-map_merge_union 60 reported code coverage metrics 2
mapping coverage for subhierarchies also reports
used in another design 54 generating 10
Metric-wide Breakdown Linkage 16 -reset_coverage 39, 8
module reuse of exclusion file 46
displaying coverage results by 18 review markers 51
monitoring for coverage 5 Running a Quick Start Example 4
multiple macros
annotation 18
S
N save exclusion state 41
sequences view
Navigating Trend Reports 11 FSM 35
navigation pane 51 -show brief 85
nested expressions 35 -show tests
nested macros line, tgl, fsm 64
annotation 17 Signature of exclusion 123
net and register coverage results 27 Simtime 61
simulating while monitoring for coverage 5
O source code
displaying 26, 37
objects tables 7
-srcmap 63
Older Session URG Links 24
start coverage mode 3
Organization of Trend Charts 11
starting DVE 9, 3
statement coverage

3
 difference from line coverage 7 U
statistics table, formatting 7
UCAPI 120
streaming operators 43
uniquetests.txt 14
SVA coverage 39
unknown value 39
unmappable exclusions 60
T unpacked dimensions 42
task definition URG 40
in line coverage 8 annotating exclusion 82
TCL scripts 58 urg –metric 85
ternary expression 31, 37 URG_FAKE_TIME environment variable 10
ternary operator 31 URG_NO_SESSION_XML environment
variable 10
test correlation
macros 19 user-defined coverage groups 22
test run metrics 62
testfile 14 V
tgl argument to the -cm option 4, 47
Viewing Coverage Results 15
The 7
toggle coverage 23
specifying 4, 47 W
Top Level Chart 12 wait statement
-trend option 2 procedural delay is interpreted as 7
while statement
in line coverage 4, 8