Hardware Reference
In-Depth Information
Although local assertions do not completely verify the design, their advantage is
huge. They make design debugging more effective—a bug is detected and caught
close to its origin. Thus, in Fig. 1.7 an incorrect implementation of the shift register
will be immediately detected, and a failure of assertion check_shift or check_rst
will point to the problematic code because these assertions are physically adjacent to
it. Without these assertions, an implementation bug could manifest itself in another
part of the design and probably several clock cycles later. One can imagine the
difficulty of debugging that error.
Assertion Coverage
When administering a large verification project, one needs to know whether the
intended functionality has been verified in its full scope, covering all functional sce-
narios of interest and all corner cases. Clearly, just making assertions a part of
design flow does not adequately provide confidence in judging that the verification is
complete or even comprehensive. Therefore, assertion coverage plays a critical part
in decision making and tracking progress of the design verification project, keyed to
the inquiry—“Are there enough assertions?”
The question is, what kind of coverage can be obtained from assertions to
provide substantive indications? We note that, generally, there are two ways to
approach this question. In the first approach, inquiries about the functionality
are the central focus. In this regard, behavioral fragments expressed by various
assertions must be matched against the specifications to determine the extent of the
functionality included in the umbrella of the assertions. In the second approach,
structural aspects of the design form the criteria. For example, the number of
design elements (signals, registers, etc.) included in the assertion checks, the number
of input and output signals included in assertions, and the number of assertions
relative to the design code size. Both approaches are useful indicators that provide
meaningful guidance in determining the required level of verification effort.
Coverage-Based Verification
A complementary approach to assertion-based verification is coverage based verifi-
cation . Coverage-based verification starts by taking functional scenarios ( coverage
points ) from the test plan and then collecting coverage of these scenarios on
available tests. The goal is to refine tests so that all coverage points are hit.
The main problem with this approach is its practical infeasibility: some scenarios
are extremely difficult to cover, and some of them are even impossible. Usually, the
first few tests hit many coverage points, and up to 60 % coverage is quickly reached.
The additional tests cover fewer and fewer new coverage points, while reaching
80 % coverage or higher becomes increasingly challenging [ 19 , 59 ] and unlikely
in practice. Verification managers usually empirically set the desired coverage
percentage, called the coverage goal . We discuss SVA tools for checking coverage
in Sect. 4.7 and in Chap. 18 .
Search WWH ::




Custom Search