18 

11   The report Command

11.1  Usage

The report command is initiated with the following call:

covered report [<options>] <CDD_filename>

The CDD_filename 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.

11.2  Options

The following table lists the options available for use with the report command.

11.3  Summary Vs. Detailed Vs. Verbose

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.

11.3.1 Summary Report

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.

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.

11.3.2 Detailed Report

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.

11.3.3 Verbose Report

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.

11.4  Module Vs. Instance

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.

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.

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.

11.5  Covered Vs. Uncovered

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?

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.

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.

[  Contents  |  First Page  |  Previous Page  |  Home   | Next Page  |  Last Page  ]