/usr/share/covered/doc/html/chapter.intro.html is in covered-doc 0.7.10-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 1. Introduction</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.overview.html" title="Part I. Overview"><link rel="prev" href="part.overview.html" title="Part I. Overview"><link rel="next" href="chapter.metrics.html" title="Chapter 2. Coverage Metrics"><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">Chapter 1. Introduction</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="part.overview.html"><img src="img/prev.gif" alt="Prev"></a> </td><th width="60%" align="center">Part I. Overview</th><td width="20%" align="right"> <a accesskey="n" href="chapter.metrics.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.intro"></a>Chapter 1. Introduction</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="chapter.intro.html#section.intro.covered">1.1. What is Covered?</a></span></dt><dt><span class="sect1"><a href="chapter.intro.html#section.intro.cc.cando">1.2. What can code coverage do?</a></span></dt><dt><span class="sect1"><a href="chapter.intro.html#section.intro.cc.cantdo">1.3. What can't code coverage do?</a></span></dt><dt><span class="sect1"><a href="chapter.intro.html#section.intro.cov.cando">1.4. What does Covered do?</a></span></dt><dt><span class="sect1"><a href="chapter.intro.html#section.intro.cov.cantdo">1.5. What does Covered NOT do?</a></span></dt><dt><span class="sect1"><a href="chapter.intro.html#section.intro.cov.diff">1.6. What makes Covered different?</a></span></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.intro.covered"></a>1.1. What is Covered?</h2></div></div></div><p>
Covered is a Verilog code coverage analysis tool that can be useful for determining how well a diagnostic
test suite is covering the design under test (DUT). It is command-line based with an optional Tcl/Tk GUI
report viewer, making it portable across almost all platforms.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.intro.cc.cando"></a>1.2. What can code coverage do?</h2></div></div></div><p>
Typically, in the design verification work flow, a design verification engineer will develop a self-checking
test suite to verify design elements/functions specified by a design's specification document. When the test
suite contains all of the tests required by the design specification, the test writer may ask:
</p><p>
</p><div class="itemizedlist"><ul type="disc"><li><p>"How much logic in the design is actually being exercised?"</p></li><li><p>"Does my test suite cover all of the DUT?"</p></li><li><p>"Am I done writing tests for the logic?"</p></li><li><p>"Do I have any redundant diagnostics in my test suite?"</p></li></ul></div><p>
</p><p>
When the design verification gets to this point, it is often useful to get some metrics for determining logic
coverage. This is where a code coverage utility, such as Covered, is very useful.
</p><p>
The metrics obtained by using a code coverage analysis tool can be very useful for determining the following
about a design and the test suite testing that design:
</p><p>
</p><div class="orderedlist"><ol type="1"><li><p>Completeness of the test suite in terms of logic coverage.</p></li><li><p>Unexercised logic in the design (useful in helping to determine what types of tests need to be added to the test suite).</p></li><li><p>Corner cases in design that are untestable.</p></li></ol></div><p>
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.intro.cc.cantdo"></a>1.3. What can't code coverage do?</h2></div></div></div><p>
It is important to note that any code coverage tool is only useful in indicating how much logic is being
covered by a test suite. It does not indicate that the covered logic works appropriately. This, of course,
can only be verified by the diagnostics themselves.
</p><p>
Additionally, it is possible that two or more diagnostics can achieve the same coverage and yet be
functionally testing different characteristics of a design. Since the coverage metrics are not improved in
this case, one may conclude that the second test is unnecessary. This may or may not be true depending on
what is being tested; it is always up to the test writer to determine the necessity of a diagnostic. Using
the code coverage tool results as the sole means of making this determination is not recommended. Use common
sense in these areas.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.intro.cov.cando"></a>1.4. What does Covered do?</h2></div></div></div><p>
Covered is a tool that uses your design files along with standard VCD, LXT2 or FST dump files to analyze the code
coverage of the DUT. The code coverage information is stored in a special database file that can be retrieved
and "merged" with new coverage information to create a summed coverage total for several tests. After a database
file has been created, the user may generate various ASCII reports that summarize the coverage information or
run Covered's GUI to interactively analyze the coverage information. Additionally, multiple CDD files from the
same design can be ranked for the purposes of running regressions and understanding which CDD files do not
add coverage information and can be excluded from regressions runs, if needed.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.intro.cov.cantdo"></a>1.5. What does Covered NOT do?</h2></div></div></div><p>
Though Covered does perform some resimulation of the design to derive line, combinational logic, memory, and
assertion coverage, Covered is NOT a full-fledged compiler/simulator and should not be used for such purposes.
Additionally, Covered is NOT a linting tool. Many syntax/semantic issues that are not allowed by the LRM are
allowed by Covered for purposes of making Covered's core more generic and/or simplistic. Please make sure that
your code is properly linted in your design flow using an appropriate tool.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="section.intro.cov.diff"></a>1.6. What makes Covered different?</h2></div></div></div><p>
Most Verilog code coverage tools perform a pre-compilation procedure known as instrumenting. During this procedure,
the coverage tool will read in the DUT and generate its own version of the DUT with additional code added to aid
in calculating coverage after the simulation is complete. The benefits to this style are higher performance of the
coverage tool when it is run after the simulation. The drawbacks to this approach are that it slows down simulation
speed and a trust issue that the coverage tool did not alter your simulation model when it performed the
instrumentation.
</p><p>
Covered, on the other hand, omits the instrumenting procedure all-together and only performs its analysis on a
pre-simulated design. This means that Covered cannot make a mistake to your simulation and the simulation is allowed
to run faster since there is no additional code that must be run to get coverage data. The drawback is that there is
some overhead in post-simulation for extracting coverage data but this is typically less than the simulation overhead
in the other method.
</p><p>
Additionally, unlike all other commercial coverage tools, Covered is free! No license managers to invoke and maintain.
No licensing fees and negotiations. The only thing the developers of Covered want in return are bug reports and user
input (and perhaps a donation if you find the software useful and want to see its development continue). Isn't the
open source life grand?!
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="part.overview.html"><img src="img/prev.gif" alt="Prev"></a> </td><td width="20%" align="center"><a accesskey="u" href="part.overview.html"><img src="img/up.gif" alt="Up"></a></td><td width="40%" align="right"> <a accesskey="n" href="chapter.metrics.html"><img src="img/next.gif" alt="Next"></a></td></tr><tr><td width="40%" align="left" valign="top">Part I. Overview </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"> Chapter 2. Coverage Metrics</td></tr></table></div></body></html>
|