How to do verification coverage?

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 4.19, Item 10.0)

From: Oki

I want to know how to calculate verification coverage, who can help me?

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

From: Jeff Cartwright

I think of verification coverage as a two step process. First, you
want to have some measure of functional coverage, and second you want
to have a measure of code coverage. Functional coverage is usually
measured via monitors. A monitor is part of your test bench, and it
records events as they occur. If you use a language like e or vera,
you will have to write the monitor. In your test plan, you should
identify the functional aspects of the design to measure. You should
write tests to exercise these functions, and develop monitors to catch
the events as they occur. Today, many simulators have options to
automatically measure RTL coverage.

In both cases, coverage is measured as a percent of the items hit by
all of the tests divided by the total number of items (e.g., RTL lines
hit/total lines of RTL).

At Obsidian we have a tool which generates assembly code sequences to
test processors. To test a processor, the verification engineer first
writes a test plan, identifying the functional areas to cover. Next,
the verification engineer writes the test bench. Using Obsidian's
RAVEN tool, the engineer develops a series of test templates to
exercise the functional aspects of the design. RAVEN generates tests
from the templates, and the tests are run on an RTL simulator. The
simulator provides RTL coverage information. An add on tool to RAVEN
measures functional coverage by scanning the generated tests. An
iterative process is used to develop more functional tests, or to
target RTL that has not been exercised.

Jeff Cartwright, VP Business Development
Obsidian Software

Anders

Another important aspect of verification coverage is structural coverage. Structural coverage refers to design independent hardware behaviour such as a FIFO full or empty signal, interrupt signals or arbiter request and grant signals. One way to measure structural coverage is to use assertions. They of course have the additional benefit of helping verify and debug the design as well.
Start by writing a number of RTL assertions such as:
- FIFO write and FIFO full are mutually exclusive
- FIFO empty and FIFO read are mutually exclusive
- Only one arbiter GNT may be asserted at the same time
If these conditions occur during any simulation the assertion will highlight the error but if the assertion is never violated you don't know why. Is it because the design is correct or because that particular case was never simulated?
There are several ways of implementing structural coverage using assertions. You can use the cover keyword in PSL or SystemVerilog and write your own list of conditions that should be exercised during simulation or you can use a library based approach such as 0-In's CheckerWare which collect statistics on the status of all assertions.
By examining the result of the assertion monitors after the simulation you will find valuable information such as a FIFO was never full or that only one request to an arbiter was tested and you can then modify your tests to cover these holes.

Regards,

Anders Nordstrom
Cadence Design Systems