1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter11.The report Command</title><link rel="stylesheet" href="covered.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.71.1"><link rel="start" href="index.html" title="Covered User's Guide - 0.7.9"><link rel="up" href="part.command.line.usage.html" title="PartIII.Command-line Usage"><link rel="prev" href="chapter.merge.html" title="Chapter10.The merge Command"><link rel="next" href="chapter.rank.html" title="Chapter12.The rank Command"><center><img src="img/banner.jpg"></center><hr></head><body bgcolor="#dfeef8" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter11.The report Command</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="chapter.merge.html"><img src="img/prev.gif" alt="Prev"></a></td><th width="60%" align="center">PartIII.Command-line Usage</th><td width="20%" align="right"><a accesskey="n" href="chapter.rank.html"><img src="img/next.gif" alt="Next"></a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="chapter.report"></a>Chapter11.The report Command</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="chapter.report.html#section.report.usage">11.1. Usage</a></span></dt><dt><span class="sect1"><a href="chapter.report.html#section.report.options">11.2. Options</a></span></dt><dt><span class="sect1"><a href="chapter.report.html#section.report.sdv">11.3. Summary Vs. Detailed Vs. Verbose</a></span></dt><dd><dl><dt><span class="sect2"><a href="chapter.report.html#section.report.summary">Summary Report</a></span></dt><dt><span class="sect2"><a href="chapter.report.html#section.report.detailed">Detailed Report</a></span></dt><dt><span class="sect2"><a href="chapter.report.html#section.report.verbose">Verbose Report</a></span></dt></dl></dd><dt><span class="sect1"><a href="chapter.report.html#section.report.mi">11.4. Module Vs. Instance</a></span></dt><dt><span class="sect1"><a href="chapter.report.html#section.report.cu">11.5. Covered Vs. Uncovered</a></span></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.report.usage"></a>11.1.Usage</h2></div></div></div><p>
The report command is initiated with the following call:
</p><p>
<code class="code">covered report (-h | -view [<span class="emphasis"><em>CDD_filename</em></span>] | [<span class="emphasis"><em>options</em></span>] <span class="emphasis"><em>CDD_filename</em></span>)</code>
</p><p>
The <span class="emphasis"><em>CDD_filename</em></span> refers to the name of the CDD to generate the report for. This CDD may be
either the result of a score or the result of merging CDDs.
</p><p>
If the -view option is specified, Covered's GUI is run. You may specify the CDD filename to initially load with
the -view option. See <a href="chapter.gui.intro.html" title="Chapter16.Introduction to the GUI">Chapter16, <i>Introduction to the GUI</i></a> for instructions on using the GUI for interactive coverage
analysis.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.report.options"></a>11.2.Options</h2></div></div></div><p>
The following table lists the options available for use with the report command.
</p><p>
</p><div class="table"><a name="table.report.options"></a><p class="title"><b>Table11.1.Options to report Command</b></p><div class="table-contents"><table summary="Options to report Command" border="1"><colgroup><col><col></colgroup><thead><tr><th>
Option
</th><th>
Description
</th></tr></thead><tbody><tr><td>
-b
</td><td>
If combinational logic verbose output is reported and the expression is a vector operation, this option
outputs the coverage information on a bitwise basis.
</td></tr><tr><td>
-c
</td><td>
Used in conjunction with the '-d d' or '-d v' option. If set, causes covered logic to be reported instead
of default behavior of reporting uncovered logic. See <a href="chapter.report.html#section.report.cu" title="11.5.Covered Vs. Uncovered">Section11.5, “Covered Vs. Uncovered”</a>
</td></tr><tr><td>
-d (s|d|v)
</td><td>
Level of report detail (s=summary, d=detailed, v=verbose). Default is to display summary coverage
information. See <a href="chapter.report.html#section.report.sdv" title="11.3.Summary Vs. Detailed Vs. Verbose">Section11.3, “Summary Vs. Detailed Vs. Verbose”</a>.
</td></tr><tr><td>
-e
</td><td>
Outputs exclusion cases when the -d v or -d d options are specified on the command-line. The exclusion
cases are displayed in the verbose format along with an exclusion reason (if one is associated with the
excluded case).
</td></tr><tr><td>
-f <span class="emphasis"><em>filename</em></span>
</td><td>
Name of file containing additional arguments to parse. You may specify this option more than once on a
command-line.
</td></tr><tr><td>
-h
</td><td>
Outputs usage information for the report command.
</td></tr><tr><td>
-i
</td><td>
Generates report information for each instance (default is to generate per module). See
<a href="chapter.report.html#section.report.mi" title="11.4.Module Vs. Instance">Section11.4, “Module Vs. Instance”</a>
</td></tr><tr><td>
-m [l][t][c][f][r][a][m]
</td><td>
Specifies type of coverage information to report (l=line, t=toggle, c=combinational logic, f=FSM
state/arc, r=race condition, a=assertion, m=memory). Default is ltcf.
</td></tr><tr><td>
-o <span class="emphasis"><em>filename</em></span>
</td><td>
Specifies output file to stream report to (default is standard output).
</td></tr><tr><td>
-s
</td><td>
Suppresses modules/instances that do not contain any coverage information from being output to the
coverage report. This may eliminate potentially meaningless information from the report.
</td></tr><tr><td>
-view
</td><td>
Starts the interactive Covered report viewer GUI.
</td></tr><tr><td>
-w (<span class="emphasis"><em>number</em></span>)
</td><td>
Specifies the maximum line width (in characters) that can be used to output Verilog information. If this
option is not specified, all Verilog code in the report will retain the same formatting as was specified
in the original Verilog code. If this option is specified, Verilog code will be formatted to use as much
of the current line as possible, wrapping text when the line reaches the maximum line width. The default
maximum line width is 115 characters (this value is used if no number is specified with the -w option).
If a number is specified with the -w option, this value is used for the maximum line width.
</td></tr><tr><td>
-x
</td><td>
When used in conjunction with the -d v or -d d option, causes all uncovered or excluded coverage points
to display an associated "exclusion ID" to the left of the verbose output within parenthesis. This
exclusion ID can be used in calls to the <a href="chapter.exclude.html" title="Chapter13.The exclude Command">exclude</a> command for the
purposes of excluding or including coverage points.
</td></tr></tbody></table></div></div><p><br class="table-break">
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.report.sdv"></a>11.3.Summary Vs. Detailed Vs. Verbose</h2></div></div></div><p>
There are three forms of reports that can be generated by the Covered report function: summary, detailed, and
verbose. The three forms are described below.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="section.report.summary"></a>Summary Report</h3></div></div></div><p>
A summary report shows at a very high-level what the coverage for a specific module (or instance) is in terms of
line, toggle, combinational and/or FSM coverage (depending on which types are selected on the command line). Each
coverage metric for the module is given a percentage of items covered for that metric as well as the total number
of items per metric, the number of items "hit" during simulation and the number of items "missed" during
execution. See the chapter on "Reading the Report" for more information on understanding the formats of line,
toggle, combinational logic, and FSM summary information.
</p><p>
The summary report is useful for understanding exactly which modules are missing coverage (and what type(s) of
coverage are missing) as well as what modules are fully covered. This can help guide you more easily in
understanding where you need to improve your code coverage without getting lost in all of the details that the
verbose reporting provides.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="section.report.detailed"></a>Detailed Report</h3></div></div></div><p>
The detailed report is useful for understanding where logic was found to be uncovered in the design along with
some higher-level information to understand why it was considered to be uncovered. This amount of detail is
between the minimum (summary coverage) and the maximum (verbose coverage) and should be used as the first
detailed report to be looked at since it is easier to read and comprehend the coverage results.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="section.report.verbose"></a>Verbose Report</h3></div></div></div><p>
The verbose report contains all of the data that the summary report contains; however, in addition to the summary
information for a module (or instance), a more in-depth look at the exact cases that were "missed" during
simulation are provided. This report outputting option is useful for combinational logic report information when
a more in-depth look at why certain expressions did not reach full coverage is needed. This option allows the
user to look at all subexpressions of an expression that were not fully covered.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.report.mi"></a>11.4.Module Vs. Instance</h2></div></div></div><p>
Any report can be calculated by module or by instance. Both reports are of interest for verification purposes and
the differences are described as follows.
</p><p>
Module reporting combines the results of all instances that come from the same module. That is, when a module is
instantiated multiple times in a design, the coverage results from all covered instances are merged together and
output as one combined module. This reporting format allows a test writer to see if any logic within a module has
not been touched during simulation.
</p><p>
Instance reporting displays each instance in the covered design separately (no combining occurs). This reporting
format is useful for determining if certain instances within a design are being neglected. For instance, if a
module is instantiated four times (i.e., four instances of the same buffer), it may be that the first buffer is
used more often than the other three buffers. This could indicate controller errors or just an indication that
there was not enough activity during simulation to fill the other buffers (need to bolster diagnostics or possibly
some buffers could be removed?) This type of information would not be viewable if only module reporting were
performed.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.report.cu"></a>11.5.Covered Vs. Uncovered</h2></div></div></div><p>
Covered has the ability the generate reports from any given CDD file that displays either uncovered logic (the
default behavior) or covered logic. It is understandable why one would want to generate reports displaying
uncovered logic (this is probably the reason why you are interested in this tool in the first place). However, why
would anyone be interested in reporting covered logic?
</p><p>
The reason for having this option is two-fold (and maybe there are other reasons). First, this option is useful in
debugging the report command since it let's the user evaluate whether a particular signal or portion of logic was
actually fully covered or not. Second, it may be useful for user's of the tool to understand what logic is being
evaluated for coverage and what logic is not. If only uncovered logic was supplied for evaluation of the tool, one
could not evaluate the effectiveness of the tool. However, by allowing the user to see what logic is covered and
uncovered, a more full picture of the tool's capability can be understood.
</p><p>
To generate a report that specifies what logic is not covered (output only available in verbose reporting mode), no
further options are needed. To generate a report that specifies what logic is being covered, simply specify the -c
option along with the -v option when calling the report command.
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="chapter.merge.html"><img src="img/prev.gif" alt="Prev"></a></td><td width="20%" align="center"><a accesskey="u" href="part.command.line.usage.html"><img src="img/up.gif" alt="Up"></a></td><td width="40%" align="right"><a accesskey="n" href="chapter.rank.html"><img src="img/next.gif" alt="Next"></a></td></tr><tr><td width="40%" align="left" valign="top">Chapter10.The merge Command</td><td width="20%" align="center"><a accesskey="h" href="index.html"><img src="img/home.gif" alt="Home"></a></td><td width="40%" align="right" valign="top">Chapter12.The rank Command</td></tr></table></div></body></html>
|
