System Verilog configurable coverage model in an OVM setup – concept of reusability

With the advent of a new era in verification technology based on an advanced HVL like System Verilog, the concept of random stimulus based verification was born, to verify today’s multi‐million gate designs. In concept, every verification engineer fancies the idea of random stimuli driven verification, but as is rightly said – “Everything comes with a cost” and the cost here is a big concern that haunts the life of every verification engineer:

• How do I close my verification?
• When can I say I am done?

To answer such questions, System Verilog as a language came up with the concept of functional coverage that is much more accurate of a measure compared to the traditional code coverage techniques. We concentrate mainly on this SV feature in our write‐up, adding one more dimension to it - configurability.

Methodology like OVM has brought in the concept of reusability of environment/agent (mainly consisting of driver/monitor/sequencer) across projects. But, on the other hand, a user tends to create a coverage model that is usually coupled very tightly to the specifications of the given project. In the process, he/she ends up writing a separate coverage model for every project, compromising the reusability aspect and violating the Methodology mantra! Keeping above limitation in view, we would like to present the user with one possible solution – configurable and reusable coverage model, sighting AMBA AXI protocol as the case study for discussion.

Why configurable coverage model???

“To minimize wasted effort, coverage is used as a guide for directing verification resources by identifying tested and untested portions of the design.” - IEEE Standard for System Verilog (IEEE Std 1800‐2009)

This quote from LRM ^[2], explains the intent of functional coverage. But the crux of this paper lies in the configurability of any given coverage model. Configurability is the key to re‐usability for any setup. All our current day methodologies have brought in the concept of reusability of the agents such as BFM’s and monitors across projects. In the same project, an engineer also creates a coverage model in order to provide the management with a picture of the verification activity status. However it’s as per the given project specifications. Thus an engineer end up in writing a separate coverage model per project while re‐using the rest.

However, verification environments created from reusability perspective need to be meticulously designed to take care of coverage model reusability as well! So our main focus is on the coverage model that could be configured and re‐used. AMBA – AXI is one of the most commonly used protocols in industry for communication amongst the SOC peripherals. Thus we chose this protocol for our case study.

System Verilog coverage constructs – Key to configurability

System Verilog provides a very fast & convenient method to describe the functional coverage for any given setup with the help of pre‐defined constructs. A brief overview shall be a good starting point.

A covergroup is user‐defined type like a class, which defines a coverage model. Composed of a number of sub‐elements including the following:  

Coverpoint ‐ Describes a particular type of coverage event, how it will be counted as well as one or more bins to organize the count
Cross ‐ Defines a new coverage event by “combining” two or more existing coverpoints or variables
Bin‐ A coverage event counting mechanism, automatically or user‐defined
Options ‐ Certain built‐in options that helps to gain better controllability over the collection of coverage numbers.

Figure 1 depicts a brief overview. The main highlight of paper lies in the wise usage of the coverage/coverpoint/cross point OPTIONS, METHODS & BINS provided in the language. Let us brief on few important among them.

Firstly, the important coverage options:

1. per_instance: Each instance contributes to the overall information for the covergroup type. When true, coverage information for this covergroup instance is tracked well.
2. at_least: Minimum number of hits for each bin. A bin with a hit count less than this number is not considered covered. Say for example, if we want a particular coverpoint/bin to be hit a minimum of 5 times before user gains a confidence on the same, user should specify option.at_least=5
3. weight: If set at the covergroup level, it specifies the weight of this covergroup for computing the overall coverage. If set at coverpoint (or cross) level, it specifies the weight of a coverpoint (or cross) for computing the coverage
4. goal: Specifies the target goal for a covergroup. If the user‐specified goal, say 50 percent for that given coverpoint/bin, then this shall account towards 100 percent coverage calculation.
5. auto_bin_max: Maximum number of automatically created bins when no bins are explicitly defined for a coverpoint.

All the options can be specified for instance‐specific or type specific coverage calculation. But language restricts that type_option must be a constant parameter and does not allow variable for the same. The only configurations provided are goal, weight, strobe & comment.

There is a key difference between type and instance coverage. The instance coverage would give us coverage of each individual instance created while type coverage is a sum of all instances. Type coverage has many limitations which are described in later part of the paper.

Coverage methods are what we would discuss next.
1. sample(): Controls the triggering of a covergroup.
2. get_coverage(): Calculates type coverage number (0‐100)
3. get_inst_coverage(): Calculates the coverage number (0‐100) of a specific instance on which it is invoked.

Since these methods can be called procedurally at any point of time, gives the user an additional flexibility to control the collection of coverage for a defined covergroup as well as get the coverage numbers in any of the agents in your OVM setup say, a score‐board etc.

Now let’s look into a little detail of bins:
[open_range_list] specification ‐ one of the important features in the bin definition that enables the user to control the number of bins created in case the user has explicitly defined the bins, since the option auto_bin_max doesn’t work in this case. Another point that we have utilized is the order of precedence that the language imposes on the illegal/ignore/normal bin definition.

The priority order is as:

1. illegal_bins: doesn’t account towards overall coverage, issues an error
2. ignore_bins: doesn’t account towards overall coverage
3. bins: are user‐defined/automatically created collectors which count towards the overall coverage numbers.

“The default specification is associated with each of the above bins. It defines a bin that is associated with none of the defined value bins. The default bin catches the values of the coverage point that do not lie within any of the defined bins. However, the coverage calculation for a coverage point shall not take into account the coverage captured by the default bin. The default bin is also excluded from cross coverage.”