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 leg-
end 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 IM-
PLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WAR-
RANTIES 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 Post-
Processor, 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, MS-
3400, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Common Elements for all pages . . . . . . . . . . . . . . . . . . . . . . . 1-5
Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
"hierarchy" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
"modlist" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
"groups" File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
"tests" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
"modN" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
"grpN" File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Assertions and Property Coverage Reports . . . . . . . . . . . . . . 1-17
Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Common Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Toggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22

1
 FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Testbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Coverage Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Grading and the -scorefile Option . . . . . . . . . . . . . . . . . . . . . . 1-27
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Coverage Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Controlling the Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
Grading and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32

2
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 Description Comments
-dir directory_name Specifies coverage data directories
-metric Limit report to specified metric(s)
line+cond+fsm+tgl+assert+tb
-show text Generate text report (not HTML)
-cond exclude filename Specify excluded conditions
condition coverage
-cond ids Show condition ids in generated report only
-cond nocasedef Exclude case default from condition
reports
-fsm disable_sequence Do not show fsm sequences
fsm coverage only
-fsm disable_loop Do not show fsm sequences containing
loops

-line nocasedef
-show tests
-show maxtests N
-grade goal timelimit
-scorefile filename
Exclude case default from line line coverage only
coverage reports
Show the tests that covered each line line & condition
and condition coverage
Specify the maximum number of tests
with "-show tests"
Grade tests (see page 26)
Allows user to specify different weight
to each metric

Unified Coveage Reporting

1-4
 Table 1-1. URG Options
Option Description Comments
-report mydir Generates report in mydir instead of
default directory
-help and -h Shows command line and options
supported by URG
-log filename Sends diagnostics to filename instead of
stdout/stderr
-split N 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.
-dbname argument Generate merged data files using
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 Line Cond Toggle FSM Assert Testbench

46.15 87.08 40.11 20.24 -- 50.00 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