14 

7   Using Covered

7.1  Work Flow

Covered has three basic commands that it uses for gaining coverage information about a design and displaying that information to the user.

• score
• merge
• report

7.1.1 Scoring the Design

To begin using Covered, you will need to create a special database file called a coverage description database (CDD). Covered uses this file to store coverage-specific information about the DUT. This file is a text-based file that is written in a specific format (the format of this file is not discussed in this document but can be found in the developer's document) that Covered understands.

To create the CDD and populate it with the simulation dumpfile results, you must use the score (see The score Command for details) command. This command parses in the DUT files and generates an initial CDD for the design. This CDD does not contain any coverage details but only the design elements that Covered needs to gain coverage results.

Once the initial CDD has been created, the score command reads in the specified VCD/LXT dumpfile from the given DUT. If Covered recognizes that the VCD/LXT dumpfile does not correspond to the DUT that it parses (dumpfile was not generated from the DUT specified), an error message is supplied to the user telling them this. Once the dumpfile has been parsed, Covered generates a new version of the CDD containing a populated database. This CDD may be merged with another CDD from the same DUT and/or reports may be generated from this CDD.

7.1.2 Merging CDDs

When two or more CDDs have been generated from the same DUT. It is often desirable to merge their contents to see what the total coverage is for both simulation runs. The reasons why merging is desirable is that often several tests are written to exercise the entire design (not just one). This makes tests easier to write and maintain. Since, typically, only one test is run per simulation run and that test does not fully test the DUT, it is necessary to combine the results of the multiple simulations to the see the combined effect of the tests on the design. This is where merging comes into play.

Merging multiple CDDs from the same design is easy with Covered, and is accomplished with the merge (see The merge Command for details) command. This command reads in two or more CDDs, merges their results and outputs the merged CDD to a different file or replaces the first CDD with the results of the merge.

7.1.3 Creating Coverage Reports

After a CDD is created or merged, the contents of the CDD can be extracted and transformed into human readable coverage reports with the report (see The report Command for details) command. A summary report containing the percentage of metrics covered is generated for each module. Additionally, to aid in understanding what and why something was not covered, a verbose reporting mechanism exists. Verbose reporting will explicitly point to and describe why something was not fully covered for a specific metric.

Reports are text-based output that by default are directed toward standard output but may, with the use of an option flag, be output to a specific file for storage purposes.

7.2  Covered usage

Covered is initiated with the following command:

covered (-h | -v | (-P (filename)) (-D) (-Q) <command> (<command_options>))

The -v command (described below) is mutually exclusive from the rest of the commands and has the highest priority. If Covered is called with this option and any other options, the version will only be displayed.

The -h command (described below) is mutually exclusive from the rest of the commands and has the second highest priority. If Covered is called with this option and the -v option is not specified, the usage information will be displayed to the screen.

The -Q option suppresses all normal user output from standard output. The only output that will not be suppressed are messages to standard error. This option may be used with any of the Covered commands to achieve this effect. By default, normal user output is sent to standard output.

The -D option outputs debug information to standard output. Its effect overrides the -Q option. This option may be used in conjunction with any other Covered command for the purposes of debugging tool failures. By default, debug mode is turned off and must be enabled in the build of Covered (using the --enable-debug option to configure). This command should only be used for debugging as it generates an immense amount of output which may hinder performance.

The -B option obfuscates all design-sensitive signal, module, task, function, instance, file and parameter names when outputting them to either stdout, stderr or a file (with the exception of CDD file output). This mode is intended to be used for sharing output information with others (including the developer's of Covered) which is sensitive information for the purposes of debugging.

The -P option causes Covered to enable internal code profiling and generates a profiling report that is output to either the given filename or the default filename of "covered.prof". This option is only available if the --enable-profiling configuration option is specified and will cause performance degradation. This option should only be used by Covered developers or those interested in finding performance bottlenecks in Covered's code. It is not recommended that the --enable-profiling configuration option and the -P global option be specified for normal users of Covered. See Built-in Profiling for more information on profiling and understanding the profiling report file.

7.3  Covered options

The following table describes options that Covered will accept apart from its normal commands which are described in the next several chapters.

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