Unified Coverage Reporting

User Guide
Version X-2005.12 December 2005

Comments? E-mail your comments about this manual to vera_support@synopsys.com

Copyright Notice and Proprietary Information

Copyright 2005 Synopsys, Inc. All rights reserved. This software and documentation are owned by Synopsys, Inc., and furnished under a license agreement. The software and documentation may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.

Right to Copy Documentation

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page: This document is duplicated with the permission of Synopsys, Inc. for the exclusive use of __________________________________________ and its employees. This is copy number __________.

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 readers 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, the Synopsys logo, Arcadia, BiNMOS-CBA, CMOS-CBA, COSSAP, DESIGN (ARROWS), DesignPower, DesignWare, dont_use, EPIC, ExpressModel, in-Sync, LM-1000, LM-1200, Logic Modeling, Logic Modeling (logo), Memory Architect, ModelAccess, ModelTools, PathMill, PLdebug, RailMill, SmartLicense, SmartLogic, SmartModel, SmartModels, SNUG, SOLV-IT!, SourceModel Library, Stream Driven Simulator, Synopsys, Synopsys (logo), Synopsys VHDL Compiler, Synthetic Designs, Synthetic Libraries, TestBench Manager, and TimeMill are registered trademarks of Synopsys, Inc 3-D Debugging, AMPS, Behavioral Compiler, CBA Design System, CBA-Frame, characterize, Chip Architect, Compiled Designs, Core Network, Core Store, Cyclone, Data Path Express, DataPath Architect, DC Expert, DC Expert Plus, DC Professional, DelayMill, Design Advisor, Design Analyzer, Design Compiler, DesignSource, DesignTime, DesignWare Developer, Direct RTL, Direct Silicon Access, dont_touch, dont_touch_network, ECL Compiler, ECO Compiler, Embedded System Prototype, Floorplan Manager, Formality, FoundryModel, FPGA Compiler, FPGA Express, Frame Compiler, General Purpose PostProcessor, GPP, HDL Advisor, HDL Compiler, Integrator, Interactive Waveform Viewer, Library Compiler, LM-1400, LM-700, LM-family, Logic Model, ModelSource, ModelWare, Module Compiler, MS-3200, MS3400, Power Compiler, PowerArc, PowerGate, PowerMill, PrimeTime, RTL Analyzer, Shadow Debugger, Silicon Architects, SimuBus, SmartCircuit, SmartModel Windows, Source-Level Design, SourceModel, SWIFT, SWIFT Interface, Synopsys Graphical Environment, Test Compiler, Test Compiler Plus, Test Manager, TestSim, Timing Annotator, Trace-On-Demand, VCS, VCSi, VHDL System Simulator, VirSim, Visualyze, Vivace, VSS Expert, and VSS Professional are trademarks of Synopsys, Inc. Linux is a registered trademark of Linus Torvalds used by permission. All other product or company names may be trademarks of their respective owners. Unified Coverage Reporting User Guide, Version X-2005.06 2

Contents
1. Unified Coverage Reporting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Elements for all pages . . . . . . . . . . . . . . . . . . . . . . . Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "hierarchy" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "modlist" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "groups" File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "tests" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "modN" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "grpN" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assertions and Property Coverage Reports . . . . . . . . . . . . . . Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 1-5 1-5 1-7 1-8 1-10 1-11 1-12 1-13 1-15 1-17 1-18 1-18 1-20 1-20 1-22

FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Coverage Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grading and the -scorefile Option . . . . . . . . . . . . . . . . . . . . . . Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling the Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grading and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-22 1-24 1-25 1-26 1-26 1-27 1-28 1-28 1-29 1-29 1-30 1-31 1-32

1
Unified Coverage Reporting 1
The Unified Report Generator (URG) generates combined reports for all types of coverage information. The reports may be viewed through the design hierarchy, module lists, coverage groups, or through an overall summary "dashboard" for the entire design/testbench. 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" page shows the design's hierarchy and contains links to individual pages for each module and its instances. The HTML file that the URG writes can be read by any web browser that supports CSS (Cascading Style Sheets) level 1, which includes Internet Explorer (IE) 5.0 and later versions, any version of Opera, and the later versions of Netscape.

Unified Coverage Reporting 1-1

Note:For the Vera X-2005.12 release, only testbench and assertion coverage are supported. Assertion and Code coverage is not supported by Vera alone, but requires that you also use either ovasim or VCS. To invoke URG, enter the urg command and specify the directories containing coverage data files. Testbench and assertion coverage data are written to the *.vdb directory Code coverage data is written to a *.cm directory

For all three types of coverage, you invoke URG as follows:

% urg -dir simv.cm simv.vdb

Data files are grouped into tests based on the names of the files. So if you have:
./simv.vdb/snps/coverage/db/testdata/test1 ./simv.cm/coverage/verilog/test1.db ./simv.cm/coverage/vhdl/test1.db ./simv.vdb/fcov/test1.db

All of these files will be considered data for 'test1'. The reports generated by URG are placed in a directory (by default this is "urgReport" in the working directory). The reports consist of a set of HTML or text files. Each time URG is run, the report directory and all of its contents are removed and replaced by the new report files.

Unified Coveage Reporting 1-2

Features
URG includes reporting for the following metrics: Code coverage - line - condition - toggle - FSM Assertions Testbench

Note: You can only report on code or assertion coverage if you use VCS code or assertion coverage to collect data. Path, assigntgl, and branch coverage are not supported. No sub-options for these features are supported in this version. The following report pages are generated as .html or .txt files: dashboard hierarchy modlist groups modN.html or modinfo.txt grpN.html or grpinfo.txt

Unified Coverage Reporting 1-3

asserts assertcategories assertseverities assertcomplexities assertdensities tests

The following options are supported:

Table 1-1. URG Options Option -dir directory_name Description Specifies coverage data directories Comments

-metric Limit report to specified metric(s) line+cond+fsm+tgl+assert+tb -show text -cond exclude filename -cond ids -cond nocasedef -fsm disable_sequence -fsm disable_loop -line nocasedef -show tests -show maxtests N -grade goal timelimit -scorefile filename Generate text report (not HTML) Specify excluded conditions condition coverage Show condition ids in generated report only Exclude case default from condition reports Do not show fsm sequences Do not show fsm sequences containing loops Exclude case default from line coverage reports Show the tests that covered each line and condition Specify the maximum number of tests with "-show tests" Grade tests (see page 26) Allows user to specify different weight to each metric fsm coverage only

line coverage only line & condition coverage

Unified Coveage Reporting 1-4

Table 1-1. URG Options Option -report mydir -help and -h -log filename -split N Description Generates report in mydir instead of default directory Shows command line and options supported by URG Sends diagnostics to filename instead of stdout/stderr Controls how large files are allowed to become before being split.The argument is an integer specifying the maximum size in bytes for any generated file. This number is used as a guideline, not an absolute limit. The default is 200kb. Generate merged data files using argument Comments

-dbname argument

Generated Files
Common Elements for all pages
Coverage data boxes are used throughout the URG report pages. These are tables containing one box for each type of coverage. An example of a text version of the report is as follows:
Score 46.15 Line 87.08 Cond 40.11 Toggle 20.24 FSM -Assert 50.00 Testbench 33.33

Unified Coverage Reporting 1-5

The HTML version includes color-coded boxes, or cells left empty if no coverage data for the coverage type represented by the box was collected. For example:

The first box shown is the overall score for all metrics. By default, this is the simple average of all the metric percentages. You can control the way the score is computed with the -scorefile option (see Grading and the -scorefile Option on page 1-27). In this example we collected Line, Condition, Toggle, Assertion and Testbench coverage. FSM coverage was turned on, but no FSMs were found in this region. The Line box is green because it falls into the upper range of target values. Values display in a range of 11 colors from red (low) to green (high) as shown below. These colors are graduated every 10 percentage points (with 100 being the 11th class). All generated pages contain a common navigation menu at the top. This menu allows you to go directly to any of the main pages, including the hierarchy, modlist, groups, dashboard, or tests files. It is a simple list of the top-level pages, plus a legend showing the cutoff percentages for each color:

Unified Coveage Reporting 1-6

Dashboard
The dashboard page is the top-level view of all coverage data. It includes the coverage data boxes for the database as a whole. Note that you can weight the coverage score in various ways. For example, 60% assertions coverage may be much worse than 25% condition coverage. The following is an example of a dashboard report.

Note: The underlined words: "dashboard," "group," "tests" and "asserts" are hyperlinks in this example

Unified Coverage Reporting 1-7

"hierarchy" File
This file contains an indented list of all module, interface, and component instances in the design. The indentation corresponds to the design tree - children are indented underneath their parents. Note: The following examples are shown in HTML. The text versions of these pages contain the same content, but are missing the hyperlinks and color. The coverage data boxes for each instance in hierarchy.html shows the total coverage information for the subtree rooted at the instance. The name of the instance is linked to its part of its module's modN.html page. Each metric in the coverage data box is linked to the corresponding section of the module instance's data in the modN.html page. A section from an example hierarchy.html page is shown below. The data shown in the hierarchy pages is the cumulative coverage for the entire sub-tree rooted at each instance. So, the coverage shown for MMRK0 is the coverage for that instance, plus the coverage for

Unified Coveage Reporting 1-8

DELAY_MOD and ovac_CHKR. To see the coverage for the instance MMRK0 alone, click on it to go to the instance report.

A hierarchy may be broken into multiple pages. When this happens, you can click on 'subtree' to see the elided part of the design.

If an entire subtree in the design has no coverage data, the instances in that subtree will not have links to modN.html pages. They will still be shown in hierarchy.html but there will be empty coverage data boxes.

Unified Coverage Reporting 1-9

If a particular instance itself has no coverage data, but one of its children or other descendents does, it will have a link to a modN.html page. This way, you can still traverse through the coverage data through the modN.html page to the children or parents. If there is no design coverage information, no hierarchy will be shown. The hierarchy page will not be generated and the "hierarchy" link will not be underlined.

"modlist" File
The modlist.html file contains a flat list of all modules, entity/ architectures, and interfaces in the design. The module (or entity, or interface) names link to the corresponding modN.html page. The entries in the list are similar to those in hierarchy.html, but there is no indentation, and the labels are module names rather than instance names. The coverage data boxes show the accumulated coverage information for all instances of the module (or entity/architecture, or interface). List entries in modlist.html are sorted in "worst-first" order. That is, the first module (or entity, or interface) shown will be the one with the worst overall coverage score. The next are ones with better coverage, ultimately followed by the one with the best coverage. Following all these are the module (or entity, or interface) entries for which there is no coverage information.

Unified Coveage Reporting 1-10

In the example below, the module TR has no line, condition or assertion coverage information. Note that the modules are listed in worst-first order based on total coverage score.

If there is no design coverage information, no module list will be shown. The hierarchy page will not be generated and the "modlist" link will not be connected.

"groups" File
The file groups.html contains a flat list of coverage group definitions with coverage data boxes. The data boxes show the coverage information for the coverage group. As in the modlist.html page, all groups in the groups.html page will be shown in "worst-first" order.

Unified Coverage Reporting 1-11

The link from each group leads to a grpN.html page. The following example shows three coverage groups as they would be displayed in the groups.html page.

If there is no testbench coverage information, no groups will be shown. The groups page will not be generated and the "groups" link will not be underlined.

"tests" File
This page lists, in score order, all tests whose coverage data was loaded to generate the report. Tests are listed in overall coverage score in best-first order, unless the report was produced with grading, in which case they are listed in graded order (see Grading and Analysis on page 1-30). There will always be at least one test in the tests.html page.

Unified Coveage Reporting 1-12

When testbench coverage is enabled, the simulation and random seed information is shown in the tests.html page:

"modN" File
Each modN.html file contains the summary coverage information for a module, entity/architecture, or interface. Unless the file has been split for size, it also contains coverage information for each of the instances of the module (if it is very large, or has a large number of instances, the data for each instance and for the module itself is put in a separate modN_M.html file). Each modN.html file has a header section and a coverage data section. The header section contains the name of the module and a list of the self-instances of the module. The self-instances are listed in "worst-first" order by overall coverage score. Coverage data boxes are shown for the module summary information and for each of its instances so users can see the status of each. The

Unified Coverage Reporting 1-13

coverage data boxes for the self instances are smaller than that for the module.

The self-instance links go to the module instance information for each instance. These are the same links as from the hierarchy.html page for each of the instances. The module instance sections also have header and coverage data sections. The header is similar to the module header, but instead of source file and self instance lists, links to the parent instance and to child instances are shown. Smaller coverage data boxes are shown for the module summary information, the parent, and each child of the module instance. The

Unified Coveage Reporting 1-14

names of each of these relatives is a link to the respective module or module instance report.

As for all report pages, the coverage data boxes are linked to the corresponding coverage reports. For example, clicking on "Line" in the above example would display the line coverage information for the module instance "DUT.KPU0.MA.arbfGRLNK2". These links are convenient for movement within a modN.html page, and are also the only way to view the coverage data reports if the modN.html page has been split for size.

"grpN" File
Each grpN.html page will have a similar outline to the modN.html pages. There will be a header for each coverage group, giving its name, and list of instances. Both sections will have the appropriate data boxes linking to coverage data reports.

Unified Coverage Reporting 1-15

The header for a group shows the group's name, coverage, goal, and weight, along with smaller data boxes for each of its children. Each coverage group then contains a statistics table for variables and another for crosses showing the overall coverage for each variable and cross, as shown in the figure below.

The names of the variables and crosses in these tables are linked to their details. Group instances have similar headers, with a link to the group summary information rather in place of the list of instances. Group instances have statistics tables and detailed reports in the same

Unified Coveage Reporting 1-16

format as the group summary information shown in the examples above.

Assertions and Property Coverage Reports

Three special files are generated for assertion and property coverage, asserts.html, assertcategories.html and assertseverities.html. The asserts.html page below shows the score for each category and severity of assertions, properties and sequences.

Unified Coverage Reporting 1-17

The following assertcategories.html report shows a detailed list organized by category.

The assertseverities.html report, not pictured here, provides a detailed list organized by severity.

Coverage Data
This section discusses how each type of coverage will be formatted for the reports.

Common Elements
There are two basic types of display that will be used for showing coverage results. One is the statistics table, and the other is the table of coverable objects.
Unified Coveage Reporting 1-18

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. For example, a statistics table for line coverage will look something like this:

As shown in the example, statistics tables are colored using the same percentages used for coverage data boxes. The table of coverable objects shows the coverage results for individual coverable objects. Coverable objects do not have percentages - they are covered or uncovered. Coverable object tables show covered (and observed) objects in green and uncovered in red. The example in the Condition section shows a coverage data table for condition coverage. For all types of coverage, the data section will begin with a statistics table showing the basic categories (for example, lines, statements, and blocks, or logical and non-logical conditions). This will be followed by a table of coverable objects. Note that several metrics have options that change exactly what is covered or how it is output. For example, condition coverage has -cm_cond allops+anywidth, which affects which vectors and conditions are monitored for coverage. Unless otherwise specified below, these options will not affect the basic structure of the coverage data output.

Unified Coverage Reporting 1-19

Line
The line coverage section will begin with a table showing the overall coverage for lines, statements, and blocks. It will then show a summary of the coverage data for all types of blocks (always, caseitem, for, forever, etc.). The other type of coverage data currently in the line reports is a table showing the line number of each statement, 0 or 1 for not covered/ covered, and then the block type if that statement begins a block. An example statistics table for line coverage is shown below.

Toggle
The toggle coverage report starts with a table containing the number of Nets, Regs, and VHDL 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.

Unified Coveage Reporting 1-20

The figure below is an example toggle summary table:

This figure shows a section of a toggle coverage detailed table:

Unified Coverage Reporting 1-21

Condition
Condition coverage information will be shown as a table with each type of condition, then an enumeration of each condition showing the source code. For example:

FSM
The FSM coverage section will begin with a summary table for states, transitions, and sequences for all FSMs in the module/instance/entity.

Unified Coveage Reporting 1-22

It will then show individual state, transition and sequence tables for each FSM.

Unified Coverage Reporting 1-23

Assertions
The assertion coverage section displays a table showing the statistics for assertions.

Unified Coveage Reporting 1-24

Testbench
Each coverage group section lists all points and crosses and their coverage scores at the top.

Unified Coverage Reporting 1-25

In the table above, "hole analysis" has compressed forty nine bins into a single row of the "uncovered bins" table. There will then be a section for each point or cross, showing the individual coverage percentage, information about the point or cross, and other information essentially in the same format as the current testbench coverage reports.

Coverage Analysis
In previous sections, we have discussed how reports are generated and how collected coverage data is displayed. This section discusses more sophisticated reported methods used in the generated reports.

Grading
When the -grade option is given to URG, it will grade all of the tests that are provided as input to URG. When grading is specified, the tests.html page will list the tests in three sections. The first section will list the tests in graded order, showing the incremental coverage scores for each test with respect to the tests above it in the list. The second section consists of a simple list of tests that were not used to reach the grading goal (or were not useful). In the third section, all tests will be listed in descending order of overall coverage score. Note that if the time limit is specified, only those tests that are graded before the time limit is hit will be included in the graded list. Only the data for those tests will be used to generate the report files, even if the grading goal is not reached.

Unified Coveage Reporting 1-26

If more than one metric is specified on the URG command line along with the -grade option, all specified metrics will be used together in the grading algorithm. For example, if you specify:
% urg -grade -metric line+assert

Then each line and assertion will be considered with the same weight when grading tests. This will be as if the coverage percentage of a given test is the number of covered lines plus the number of covered assertions, divided by the total number of lines plus the total number of assertions. We will use the same basic grading algorithm (test loading/unloading of all data from that test) as in the single metric case, but compute the percentages in this unified way.

Grading and the -scorefile Option

When specifying the -scorefile option, you designate how coverage percentages should be computed in a separate file. This file allows you to give a different weight to each metric. The following is an example score file. It shows that line coverage is weighted normally, but that each testbench coverable object should be weighted double:
line 1 tb 2

The names of the metrics in the score file are the same name used as arguments to the -metric flag. As for the unified grading example in the last section, we use the same grading algorithm. The only difference is how we compute the coverage percentages. In this example, the total coverage percentage would be computed as the mean of the scores for line and twice the testbench coverage.

Unified Coverage Reporting 1-27

Command Line
This section describes the command line for URG.

Directories
-dir directory

This option will accept any coverage directory (.cm, .vdb, and any future unified directory form) and take data from that directory for its report. Multiple -dir options can be specified. You must specify at least one directory - there is no default coverage directory name. Since urg is a Unix command, the arguments may include shell variables, absolute, or relative paths, such as:
% urg -dir $MYDIR/foo.cm % urg -dir $MYDIR % urg -dir ~username/covd ~username/covd/simv1.cm

urg is invoked from the command line, and writes coverage data into designated directories. Testbench coverage data is written to the current directory Code coverage data is written to a *.cm directory Assertions coverage data is written to a *.vdb directory

So for all three types of coverage, you invoke URG as follows:

% urg -dir . simv.cm simv.vdb

Unified Coveage Reporting 1-28

Coverage Types
You use the -metric argument to select which types of coverage you want to report.
-metric [+]line+cond+fsm+tgl+assert+tb

If no -metric argument is given, all types of coverage in the indicate coverage directories will be reported. An initial plus sign is not required but is allowed. If no metrics are specified, all coverage data from the specified directories/tests will be loaded.

Controlling the Report Format

-show tests -show maxtests N

These options only apply to line and condition coverage. When given, for line and condition coverage, the reports will show which tests covered each line or condition.

Unified Coverage Reporting 1-29

Grading and Analysis

For URG, grading will be invoked with these options:
-grade [N [timelimit]] [-metric metric1[+metric2[+metric3]] -grade [N [timelimit]] [-scorefile filename]

The -grade option specifies that grading should be done to percentage N on the optionally specified metrics only, with the given timelimit. The -scorefile option gives a filename containing a description of the grading function to use. This is used when you want to give different weights to different metrics for grading. Note that only one of -scorefile or -metric may be used. You can use the -scorefile option to modify how the "worst first" score is computed. URG uses a default algorithm for computing this - each metric is weighted the same. If a -scorefile file is specified, the weights in the score file are used instead. The -scorefile file has the following simple format: metric1 weight1 metric2 weight2 metricN weightN Each metric may only be specified one time in the file. The metric names are the same as those used for the -metric option on the

Unified Coveage Reporting 1-30

command line (for example, line, cond, assert). Each weight must be a non-negative integer. When the -scorefile option is given along with -grade, grading is done for the metrics as specified in the -scorefile file. No -metric option may be given with the -scorefile option, since the score file spells out which metrics are being used. Note that grading may be restricted to only certain parts of the design using the -hier or -map options. When these options are used with grading, the tests are ranked in order based only on their effects on the specified parts of the design.

Example
Code coverage can be generated by VCS, VCS/MX or Magellan. All code coverage is generated into code coverage directories (for example, VCS's default is simv.cm). To produce a unified report showing collected code coverage from directories simv1.cm, simv2.cm, and formal1.cm, the urg command would be:
% urg -dir simv1.cm simv2.cm formal1.cm

This would automatically report on any metrics collected into these three directories, since no -metric options were given. This command would generate a set of HTML pages into the default directory, urgReport. Assertion coverage information is collected in .vdb directories. VCS, VCS/MX and Magellan can each generate assertion coverage information. To produce a unified report from one directory created

Unified Coverage Reporting 1-31

by VCS, simv.vdb, and another created by Magellan, formal.vdb, the following command would be used:
% urg -dir simv.vdb formal.vdb

These commands would generate a set of HTML pages into the default directory, urgReport. To generate a combined report of all code and assertions coverage data from the examples above, the following command should be used:
% urg -dir simv.vdb simv.cm simv1.cm simv2.cm formal1.cm

Testbench coverage can be generated by Vera, VCS or VCS/MX. Testbench coverage is stored in *.db files in the current directory (by default). The following command will read all *.db files in the current directory to report testbench coverage:
% urg -dir .

Known Issues
There is a known issue in the Opera browser where it doesn't correctly follow some "#" links. This means clicking in the hierarchy page may take you to the module section instead of the instance section for the instance you clicked on.

Unified Coveage Reporting 1-32