Skip to Main Content
white paper

How to avoid the pitfalls of mixing formal and simulation coverage

Coverage as a metric

Code coverage results with formal due to trivial property targeting just that code (shown on the left), and code coverage from a property that’s checking the design’s requirements (shown on the right).
Code coverage results with formal due to trivial property targeting just that code (shown on the left), and code coverage from a property that’s checking the design’s requirements (shown on the right).
Driven by the need to objectively measure the progress of their verification efforts, and the relative contributions of different verification techniques, customers have adopted coverage as a metric. However, what exactly is being measured is different depending on underlying verification technology in use. Consequently, simply merging coverage measurements from different sources can fool the end-user into believing that they have made more progress, and/or they have observed behaviors of importance, when neither is the case. In this paper we will first review what these forms of coverage are telling the user and then discuss how to merge them together in a manner that accurately reports status and expected behaviors.

Simulation-generated code and functional coverage defined

Code coverage is simply the percentage of RTL code measuring the number of statements in a body of code that have been executed through a test run, and which statements have not. While it is important that the testbench can exercise all of the RTL code—i.e., there is no dead code, implying a bug in the DUT, the design can still be missing important functionality and/or the paths to key functions are in violation of the specification.

Functional coverage from RTL simulation is the metric of how much design functionality has been exercised—a/k/a covered by the testbench or verification environment—which is explicitly defined by the verification engineer in the form of a functional coverage model. In its basic form, it is user-defined mapping of each functional feature to be tested to a cover point, and these coverage points have certain conditions (ranges, defined transitions or cross etc.) to fulfill before it is reported as 100% covered during simulation. All these conditions for a cover point are defined in form of bins. A number of cover points can be captured under one covergroup, and a collection of cover groups is usually called a functional coverage model.

During simulation, when certain conditions of a cover point are hit, those bins (conditions) are getting covered and thus it gives a measurement of verification progress. After executing a number of testcases, a graphical report may be generated to analyze the functional coverage report and plans can be made to cover up the holes by creating new tests that will traverse the as-yet unexercised areas of the DUT code.

Share