Solving Puzzling Power-Aware Coverage: Getting An Aggregated Coverage Metric

How to fit low power coverage into the entire functional verification environment.

popularity

Coverage metrics tell us when a design has been thoroughly verified, or at least exercised to the point of diminishing returns. Rarely can every design artifact or design parameter of a highly complex design be covered 100 percent, but we can use coverage metrics to know the extent to which we have verified the design — enough to be confident that it will function as desired in the end product.

Coverage is a very familiar and well-defined technology in dynamic simulation; however, low power coverage remains a missing piece in the entire functional verification environment, specifically in dynamic simulation, primarily because low power coverage standards are lacking.

Fortunately there are tools that allow you to create automatic low power coverage testplans (aka verification plans) during low power simulation and internally link the testplan with low power coverage objects. You can also annotate the coverage data in a unified coverage database (UCDB). Mechanisms within the UCDB format allow testplan scopes and coverage scopes to be tagged so that an association can be made between them. This allows you to annotate your low power testplan with low power coverage data and represent low power coverage results based on your queries.


Figure 1. Auto-testplan generation during Questa LP-SIM.

However, this is an adhoc approach, as it only processes low power coverage. So we formulated a versatile coverage database that brings both low power and non-low power coverage under the same hood.

An adaptable low power coverage database for dynamic simulation
While considering a comprehensive and combined database that will coordinate both low power and non-low power coverage, we emphasized a few aspects; such as the database must be standard in terms of accessibility and adaptability.

The most recent version of IEEE-1801-2015 or UPF 3.0 provides a concrete model of a low power information model that consists of power-management objects, which are the results of applying UPF semantics augmentation on HDL designs. Hence the model or database defines relationships between the design and low power objects.

This low power information model database (IMDB) consists of low power objects and various information-bearing properties defined for those objects. It provides a set of well-defined APIs to access and query the low power or design information in TCL or in HDL. It also offers you the liberty to develop more complex APIs on the basis of fundamental API definitions.

The key components of a low power IMDB objects and properties, as defined by the UPF 3.0 LRM, are summarized below.

Objects are primary holders of information

  • They are accessed by handle ID / UPF Handle
  • Objects represent UPF, HDL, or a relationship between them
  • There are three major classes of objects:
    • HDL Objects: Model objects that represent HDL design
    • UPF Objects: Model objects created by UPF
    • Relationship Objects: Objects that model the relationship between UPF and HDL objects

Properties: a collection of information about an object

  • They are accessed by property IDs
  • Properties are classified as:
    • Basic Types: String, Integer, Boolean etc.
    • Complex Types: Handles to properties, list of handles to other objects etc.
    • Dynamic Types: Accessible only from HDL package functions


Figure 2. Low Power Information Model Database (IMDB).

The IMDB is ideal for extending beyond the low power paradigm. Specifically, the IMDB can be extended to match the industry-standard Accellera UCIS API to analyze, merge, and represent low power coverage data on non-low power coverage results.

The UCIS API can be used to implement the heterogeneous types of a coverage merge, which basically allows coverage analysis tools to merge coverage data from semantically different verification sources, like low power and non-low power sources. UCIS stipulates that semantically different data must be stored within the UCDB, but they are usually not automatically merged within the database. If a coverage analysis tool has an algorithm for merging heterogeneous data, it should submit a new data item with a semantic tag indicating merged data.

The UCIS standard also implements an HDL specific unique ID to query through HDL objects for manipulating and representing HDL code coverage related information. Specifically, the predefined fields of UCIS composite objects consist of design scopes, coveritems, and history nodes that allow relating UCDB coverage data through design HDL objects.

The proposed adaptive coverage database imposes IMDB components (HDL, UPF, and relational objects and relevant properties) as a subset of the regular UCIS standard. As a result, we will be able to process both UPF cover bins and UPF cross-cover bins as well as all the non-low power cover bins under the same hood. The coverage data collection, analysis, and representation is possible even from the IMDB, as we extend the IMDB HDL components to map the relevant UCIS HDL standard components.

Now, let’s look at the provisions for merging low power and non-low power coverage to provide a consolidated coverage metric from all sources and phases of the design verification and implementation flow.

Algorithm for merging low power and non-low power coverage
This methodological approach fills in the missing pieces of the entire design verification flow — low power coverage, its standardization, and its integration with standards for non-low power coverage computation models.

Our approach can be summarized as follows:

  • Identify the missing pieces of low power coverage modeling
  • Identify the complete source of low power coverage contributors
  • Define low power cover bins — the UPF cover-bins and UPF cross-cover-bins
  • Identify the low power coverage and testplan association mechanism through the UCDB
  • Implement standardization mechanism for low power coverage bins through IMDB as defined by UPF 0
  • Extend low power cover bins in the IMDB as a subset of UCDB
  • Identify database accessibility through mapping the HDL API defined by both the UPF 3.0 and UCDB standards
  • Propose an adaptive coverage database through UPF 3.0 in the IMDB and extend it with the UCDB standard for integrating the non-low power coverage
  • Identify the requirements of heterogeneous merge algorithms for merging low power and non-low power data in UCDB

The algorithm for merging low power and non-low power coverage under an extended IMDB (UCDB) is made possible through a master testplan. A master testplan is a non-low power verification plan generated manually, based on the verification specification for the design in terms of hierarchical structure and scopes that may be used in both low power and non-low power verification flows. The autogenerated low power testplan and master testplan are linked through the coverage objects or test data records to corresponding sections of each other.


Figure 3. Heterogeneous Merging of Low Power and Non-Low Power Coverage in IMDB (extension of UCDB).

Once the links between both the testplans are established under the IMDB (UCDB), merging of low power with non-low power cover-bins becomes procedural, since we already know that the UCDB allows testplan scopes and coverage scopes to be tagged so that an association can be made between them.

Now we have the initial framework for low power coverage standardization and integration with existing UCIS coverage standards. For complete RTL code coverage, the RTL code coverage data models for both UPF instrumented RTL and non-LP RTL must be formally, or logically, equivalent. This requires formal tools to understand the consolidated database and coordinate with UPF semantics to conduct equivalency checks at the design circuit level. With that, we know our dynamic simulation puzzle is complete and it is correct.

For an exhaustive understanding on this topic, including supporting concepts and case studies, please download the whitepaper Low Power Coverage: The Missing Piece in Dynamic Simulation.



Leave a Reply


(Note: This name will be displayed publicly)