You are browsing the archive for Functional Coverage.

Functional Coverage: The Heart of OS-VVM

November 20, 2012 in Functional Coverage, OS-VVM in general

Simply stated, the goal of verification is to test everything identified in test plan.  The goal of OS-VVM is to accelerate this process.

Like other methodologies, OS-VVM uses functional coverage to observe conditions on interfaces and within the design to determine that all items in the test plan have been tested.   Unlike other methodologies, functional coverage is the prime directive – it is where we start our process.

Functional coverage is important to all methodologies because it indicates when testing is done.  However, what other methodologies overlook, is that functional coverage also tells us what conditions our testbench needs to generate to be done.

“Intelligent Coverage” says lets take the functional coverage information and randomly pick a condition we have not seen yet and pass that to our stimulus generation process.  If the functional coverage is on an input, the stimulus generation process simply applies an appropriate transaction with the values.  If the functional coverage is on outputs or internal states, then stimulus generation process takes the desired conditions and maps them back to one or more transactions done on design inputs.

For this process to work, we need a functional coverage model that is accurate for both point and cross coverage.  This is also another strong point of OS-VVM. OS-VVM creates the functional coverage data structure sequentially using subprogram method calls.  For simple symmetric cross coverage, the modeling can be done with a single concise call.  For more complex cross coverage, the modeling can be done one item at a time or using any of the sequential language constructs.

For more details of how coverage modeling works, see CoveragePkg_user_guide.pdf (in the download zip file). This material plus additional advanced techniques are covered in the SynthWorks class, VHDL Testbenches and Verification – OSVVM Bootcamp.

Webinar about OS-VVM coming soon. Any questions?

July 12, 2012 in Event, Functional Coverage, OS-VVM in general, Randomization

Hello Fellow OS-VVMers,

A webinar introducing OS-VVM is coming soon. It will be broadcast twice on July 19th, 2012 (Thursday):

If you plan to attend, please register using links above. There will be a chance to ask questions during the webinar, but if you already have questions, please ask them now in the replies (comments) to this post. The most interesting ones will be answered live during the webinar — your name will not be mentioned unless you explicitly give us permission in the reply (something like this: “You can call me John from Chicago while answering my question.”)

Hope to see you during the webinar!

Your Friendly Admin.

randc in OSVVM – another view

April 20, 2012 in Functional Coverage, OS-VVM in general, Randomization

OSVVM has a generalized sense of randc called Intelligent Coverage accessed through the method RandCovPoint.

Intelligent coverage is a superset of randc.  While randc concerns itself with a single object, intelligent coverage works across the entire set of coverage bins.  Like Jerry pointed out in his post, “The myth of ‘randc’”, for large data sets (a 32 bit value) there can be algorithmic challenges.   However, most verification problems do not have this many bins.  Also, most verification problems are only concerned with hitting each bin once.  To emulate randc in OSVVM, add functional coverage on each value of a single object, and use RandCovPoint to randomize values.  To generate each value before repeating, set the threshold value to 0.0 (meaning only consider values that are equal to the minimum percentage of coverage – or minimum coverage if all the coverage weights are the same).   With thresholding, a limited amount of repeating values can be enabled by increasing the threshold – also a valuable thing to do in verification.

Since intelligent works across all of the coverage bins, it actually does what I suspect SystemVerilog wanted out of randc – generate each test case once without repeating.  This is important since without intelligent testbench/coverage capability, to generate a sequence of N transactions in theory takes N* LogN.   Removing the LogN factor is important if your testbenches are taking time measured in hours since even for a small number of sequences, say 25, the log N factor represents a theoretical 3X speedup (due to a reduction in redundant vectors executed).   With VHDL and OSVVM, intelligent coverage is a built-in to CoveragePkg and is language accessible;  with SystemVerilog, to get intelligent testbench capability, plan on paying for a tool feature.

Intelligent coverage goes much beyond randc.  While randc prioritizes each value equally, intelligent coverage allows each bin to have a different coverage goal and/or weight.  While randc can only think in terms of individual values, intelligent coverage allows us to aggregate values into ranges of values.

Need examples?  See the CoveragePkg_users_guide.pdf in the doc directory of the package download.

Why Functional Coverage?

March 28, 2012 in Functional Coverage, OS-VVM in general

The term ‘functional coverage’ is getting very popular recently, but not everyone has good idea what it really means. Let’s try to explain some terms to clarify any possible confusion.

Let’s start with coverage in general. It can be shortly described as the metric of design quality. Coverage data is usually collected during design verification, and depending on the items observed, different kinds of coverage can be distinguished:

  1. Code coverage counts executions of lines, statements or branches of the design code. In the end it shows you how well the design code was tested, not how well the desired behaviors of the design were tested. It means that we can have perfectly covered design code that does not match design specification…
  2. Property coverage (a.k.a. assertion coverage) verifies that design properties were exercised during verification. Since the properties (expressed in SVA or PSL) represent behaviors of the design taken from the specification, this variety of coverage is much more valuable than code coverage. Unfortunately it requires you to add properties to your design, which requires more expensive versions of verification tools.
  3. Functional coverage checks how values of selected variables and expressions were exercised during verification. When well planned, it can be as valuable as property coverage, and in OS-VVM implementation it does not require additional options in the simulator…

Let’s say that we are testing climate controller design. For some variables with small range of values we want to count occurrences of each value. If our controller can work in three different modes represented by mode variable, we probably will count occurrences of each individual mode value. For other variables we may want to create bins: groups of several values. If we have design variable temp representing temperature sensor data, bins covering ‘freezing’, ‘cold’, ‘neutral’, ‘warm’ and ‘hot’ temperatures should be defined to simplify coverage data collection.

We can also implement cross-coverage, where bins collect values from more than one variable (we can call them two- or more dimensional bins). In our climate controller we could imagine two-dimensional bins that mix values of temperature and register that activates heaters/coolers. If our cross-coverage data shows that bin mixing ‘hot’ temperature values with ‘all coolers on’ control register value was covered, it is good. If the bin mixing ‘freezing’ temperature values with ‘no heaters/coolers on’ control register value is covered, we probably have functional problem in our design.

I hope that this brief description clarified any possible misconceptions and encouraged readers to try OS-VVM in their designs.