Functional Coverage Techniques: Leveraging DesignWare Verification IP and VMM for Efficient Testbenches

Charles Li, Corporate Applications Engineer

Introduction

Today's large and complex designs have created the need for new approaches to verification. For maximum efficiency, a combination of unified technologies offers the best gains. The "Verification Methodology Manual for SystemVerilog" (VMM for SV) used with Synopsys® DesignWare® Verification IP (VIP) is such a combination. Leveraging the benefits of each achieves functional coverage goals with a constrained random methodology.

This article is a condensed overview of using Designware VIP and VMM together to control test conditions and collect functional coverage metrics. Readers should be familiar with VMM terms and techniques. For a more complete discussion, please refer to the whitepaper "Advanced Techniques for Building Robust Testbenches with DesignWare Verification IP and Verification Methodology Manual (VMM) for SystemVerilog", available at this location:

http://www.synopsys.com/cgi-bin/systemverilog/pdfr1.cgi?file=dw_vip_and_rvm_wp.pdf

To describe how to use VMM and Designware VIP, four major topics are discussed:

Callback methods
Functional coverage definition
Factory objects
Constraints

Callback Methods

A callback method, or simply callback, is a mechanism that allows user-specific code to be inserted into otherwise general purpose code. Using the object-oriented programming technique of inheritance, VIP provides methods with no default functionality for a testbench to redefine. This creates a placeholder for user-inserted code as shown in the figure below. If provided, the user-defined code is executed when the callback is executed.

DesignWare VIP provides callbacks mostly as a way to access protocol transactions as the VIP processes them internally. Each VIP provides callbacks that are called at certain points in the normal processing and allows the user to examine or modify the transaction. This is shown graphically in the next figure.

Functional Coverage Definition

The callback access mechanism is general purpose, but in the context of this article, it affords a place to insert code for coverage metrics collection. DesignWare VIP models provide several callback methods, contained in a single callback class, that correspond to different points in the model.s functional flow. Methods with "_cov" in their names are designed for collecting functional coverage. Choosing the appropriate callback method to collect coverage is protocol-specific and also depends on the metrics that you want to collect. In most applications, however, the "_cov" callbacks are recommended.

Once the callback is chosen, the user extends the method to include code that makes a copy of the current transaction and triggers coverage sampling.

Next, the coverage metrics need to be defined. The callback class is a convenient location to add covergroup definitions.

With the definition in place and the callback method extended to trigger collection, coverage metrics are saved when the simulation executes.

The example above shows a simple way to define and trigger functional coverage from within the same class. Several of the DesignWare VIP suites use inheritance to further organize functional coverage code for better modularity. A first layer of callback extensions declares transaction attributes and extracts them from the transaction object. Events are defined for significant protocol points. This provides all the 'hooks' needed to capture coverage. A second layer of callback extensions defines the cover groups and bins. In this manner, multiple coverage definitions can share the lower layer.

Factory Objects

For protocol-based verification, there is typically a transaction class, or set of classes, that represent protocol traffic. The definition of a transaction class, including all members and constraints, can be used by a generator as a template for object generation. As in a production line, a generator can use this template to easily pump out streams of (randomized) transaction objects. An instance of a class that is used as a template is referred to as a factory object, or simply factory for short. DesignWare VIP provides ready-to-use, factory classes for protocol transactions.

The concept of using a factory object is a general one and can be applied whenever objects are randomized. In addition to transactions, VIP models provide ready-to-use factory classes for other applications including configurations, scenarios and exceptions (error injection).

Constraints

Constraints form a rule set that is used for randomization. Constraints serve a critical role in protocol verification because, while constrained randomization produces legal, useful objects, unconstrained randomization would create mostly non-sensical, non-compliant objects. Constraints are also a primary mechanism for a testbench to specify test conditions.

The classes provided with DesignWare VIP models already have constraints defined and use a layered constraint architecture. The constraints are the key to easily generating objects that are protocol compliant, and they can be quite extensive. Because the VIP provides an initial set of constraints, the user need only make incremental modifications or additions to create desired test conditions.

The first constraint layer is implemented completely by the VIP model. Each data object provided by DesignWare VIP has a constraint called valid_ranges. This is the broadest constraint possible, and is intended to keep class members within ranges that will function with the particular VIP model. These ranges may not align with protocol limits, so objects generated with only this constraint may not make sense. Because the model cannot operate outside of the limits set by valid_ranges, this constraint should never be disabled.

The next layer is a set of .reasonable. constraints. The main objective of these constraints is to enforce protocol limits and it is this set which turns random generation into protocol-based generation. A secondary objective is to provide some tradeoffs to keep simulations within practical bounds. Unlike valid_ranges, the .reasonable. constraints are intended to be reviewed by the user and modified as desired to suit the needs of the current test.

The third constraint layer consists of any user-defined or user-modified constraints. These are the customizations that the testbench applies.

Each individual constraint defines a possible solution space and a constraint solver must find values that satisfy all constraints. Each of the three layers described above will define a different solution space. For a given test, the resulting set of possibilities is defined by the overlap areas shared by all three constraint layers. Keep in mind that protocol rules often prohibit some conditions as represented below by the irregular shape of reasonable solution space. Constraints steer the test and influence the ultimate functional coverage.

Summary

The combination of DesignWare VIP and VMM provides key mechanisms that facilitate the control of test conditions and the collection of functional coverage metrics. Leverage these two technologies in order to: