by Gunjan Gupta and Anand Shirahatti, CTO, Arrow Devices
Functional coverage plays a very important role in verifying the completeness of a design. However customizing a coverage plan for different chips, users, specification versions, etc. is a very tedious process especially when dealing with a complex design.
Quite often a verification engineer needs to customize the coverage plan. Customization might be required as the coverage plan can vary amongst multiple users. Additionally, users might need to reflect regular updates in specifications in the coverage plan. Making all these changes in the source coverage code leads to conflicts and confusion amongst different users and projects. Managing the above stated issues is a challenging and time consuming task for a verification engineer.
This article describes a simple methodology which addresses all the above issues. It uses the concept of inheritance and can be implemented as a tool in conjunction with Questa. This customization methodology can be used across all protocols.
There are some real use case scenarios which could benefit heavily by easy functional coverage reuse but do not have systematic and efficient way of accomplishing the same. Some of these real use cases are described below.
MULTIPLE IP CONFIGURATIONS
In keeping with the fast changing market, there are continuous version updates for standard specifications and product features. This results in continuous updates in the functional coverage plans as well. Independent coverage support for different versions of the product may be required and so multiple coverage files may need to be managed.
Apart from this “super design IPs” are being developed by design houses that support multiple configurations catering to numerous applications. When these design IPs are used in a project they might need a certain amount of customization to meet certain project specific requirements.
Different configurations and customizations may require only a subset of the complete functional coverage or may require coverage customization.
MULTIPLE SoC CONFIGURATIONS
Application specific SoCs are a new and fast growing area. Every major field, be it mobile or automobile is churning out its own SoCs to meet their requirements. These SoCs are built using several design IPs. Generally multiple variations of the same SoC are created to cater to different cost segments within the same field.
REUSE OF COVERAGE ACROSS TEAMS: THE CONFLICT PROBLEM
Typically complex designs are verified across multiple teams. These teams can be completely inhouse or involve external vendors. It’s not difficult to visualize a scenario in which one team is implementing the full coverage plan, with other verification teams reusing the plan. Typically teams reuse a subset or full coverage plan and add some of their own project specific requirements.
Imagine if users are directly making changes to the copy of an original coverage plan created by a central coverage team, it can lead to conflicts when there are future updates in the same area delivered by the central coverage team. Although one can use version control to solve this problem, but those who have undergone the pain of conflict resolution can understand how tedious, time consuming and confusing this can be. Moreover, this is an error prone process for functional coverage as any mistakes in resolution will not show up as functional errors. Any such error can cost the chip to fail and a loss of millions of dollars.
The methodology described below ensures hassle-free coverage customization and management. It helps in handling the above stated issues of customization, handling of multiple updates and multiple SoC configurations. It preserves the original coverage plan thus making it easy to revert back to the original plan at any point. This customization methodology is generic and can be used across many languages and designs.
WORKING OF THE METHODOLOGY
SystemVerilog is a popular high-level verification language (HVL). Although it is largely object oriented but the same does not apply to all its supported constructs. For example functional coverage constructs are not object oriented. If a language natively supports object orientation for functional coverage then it can be implemented in the same language.
Since SystemVerilog does not support native object orientation for functional coverage an additional scripting language is made use of to demonstrate the methodology. This methodology works on the principle of inheritance using the following simple data structures:
- Reference coverage file that implements a base coverage plan
- Specification update file(s) that contains spec updates to the base coverage plan
- User customization file(s) that contains desired customization (in terms of addition, deletion or modification of cover-groups/cover-points/crosscoverage/ bins, modifying the value of a bin, etc.)
These data structures are essentially a representation of the coverage constructs defined in a hierarchical way (cover-groups, cover-points, bins cross-coverage) and are in accordance with LRM (Language Reference Manual). The diagrams below explain the hierarchy used.
Maintaining these separate data structures ensures clean coverage across multiple users and configurations. Different users can have their own sets of customization files. This methodology provides a way to merge the three data structures to generate coverage that meets specified requirements. Since the base coverage data structure remains untouched it is very easy to update it. The generated customized coverage plan meets all user specific requirements like modifications, customization and updates. Sharing common coverage code becomes easy and efficient.
Modifications or updates in the coverage plan are generally of the following types:
- Removal/addition of cover-groups
- Removal/addition of cover-points and cross-coverage
- Modification of sampling-point and conditions
- Change in the weight of cover-groups, cover-points and cross-coverage
- Removal/addition of bins
- Modification of type of bins and values that each bin can take.
The following algorithm of the above mentioned modifications can be accomplished using the defined data structures shown below.
These data structures and the associated algorithm makes it possible to accomplish functional coverage reuse in a very systematic and efficient fashion.
Below is a demonstration of how these data structures can be implemented in Perl and their usage.
CASE STUDIES
Case#1: Customization of the cover point bin range
Below is the code snippet of base coverage plan data structure:
 |
Below is the coverage output generated from the base coverage plan:
 |
Below is the code snippet of user customization plan:
 |
Below is the coverage code generated after customization, here one can see that the range of the bin is modified:
 |
Here customization has been shown at the bin level. However the same can be done at cover-point, cross-coverage and cover-group level as well.
Now ‘n’ users can have their respective coverage customization files and generate coverage based on their requirements without affecting the others.
Case#2: Add an extra cover-bin to support the update process.
Below is the code snippet of base coverage plan:
 |
Below is the coverage output generated from the base coverage plan:
 |
Below is the code snippet of specification update plan:
 |
Below is output generated after the update, here one can see that an extra bin is added to the coverpoint:
 |
Here the update has been shown at the bin level. However the same can be done at cover-point, cross-coverage and cover-group level as well. Again with this methodology we can support ‘n’ updates and can have separate coverage code for each update.
CONCLUSION
The above methodology is designed to be user friendly, and helps in automating repetitive and time consuming coverage management. It’s useful for carrying out a particular customization at one go – and with precision.
Updates can now easily be reflected and even further customized. Overall this concept saves a lot of time and effort in coverage management and thus increases verification productivity.
Back to Top