The effective verification of low-power designs has been a challenge for many years now. The IEEE Std 1801-2015 Unified Power Format (UPF) standard for modeling low-power objects and concepts is continuously evolving to address the low-power challenges of today’s complex designs. One of the main challenges for low-power verification engineers has been the fact that there is a disconnect between the traditional RTL and low-power objects. Users cannot access and manipulate the low-power objects in the same way as they do the RTL objects. Low-power concepts are abstract and complexities arise because of the number of sources like UPF, HDL and Liberty all provide power intent in a low-power design. It has also been seen that the majority of verification time is spent debugging complex low-power issues. There are not too many ways in which users can do self-checking of their designs. As the low-power architecture is complex and the number of power-domains used in designs is high, selective reporting of a part of a design is needed. The lack of an industry standard in this regard has resulted in inconsistencies in the different ad-hoc approaches adopted by different tool vendors.
To keep pace with the increasing complexity of low-power architectures, the IEEE 1801 standard is expanding its gamut of constructs and commands to include more low-power verification and implementation scenarios. In this article we will present some innovative ways of writing Power Aware Apps using the UPF 3.0 information model HDL package functions and Tcl query functions. The article also demonstrates how these Power Aware Apps can help in reporting, debugging and self-checking low-power designs. We will also highlight how these apps will help offer an efficient way to significantly save verification effort and time.
POWER INTENT SPECIFICATION AND BASIC CONCEPTS OF UPF
The IEEE Std 1801-2015 UPF allows designers to specify the power intent of the design. It is based on Tcl and provides concepts and commands which are necessary to describe the power management requirements for IPs or complete SoCs. A power intent specification in UPF is used throughout the design flow; however it may be refined at various steps in the design cycle. Some of the important concepts and terminology used in power intent specification are the following:
- Power Domain: A collection of HDL module instances and/or library cells that are treated as a group for power management purposes. The instances of a power domain typically, but do not always, share a primary supply set and typically are all in the same power state at a given time. This group of instances is referred to as the extent of a power domain.
- Power State: The state of a supply net, supply port, supply set, or power domain. The power state is an abstract representation of the voltage and current characteristics of a power supply and the operating mode of the elements of a power domain or module instance (e.g., on, off, sleep).
- Isolation Cell: An instance that passes logic values during normal mode operation and clamps its output to some specified logic value when a control signal is asserted. It is required when the driving logic supply is switched off while the receiving logic supply is still on.
- Level Shifter: An instance that translates signal values from an input voltage swing to a different output voltage swing.
- Hard Macro: A block that has been completely implemented and can be used as-is in other blocks. This can be modeled by a hardware description language (HDL) module for verification or as a library cell for implementation.
UPF 3.0 INFORMATION MODEL
UPF 3.0 has come up with the concept of an information model to represent low-power objects and concepts in a structured and consistent manner.
The information model captures the low-power management information taken from the application of low-power UPF commands on a design. The information model consists of a set of objects and various information-bearing properties defined for those objects. It also defines the relationship between the HDL and UPF. The information model provides a set of well-defined APIs to query the low-power information in either Tcl or HDL. The Tcl APIs can be used to query the static information of a low-power object; e.g. the file/line detail of a UPF object or a list of isolation strategies of a power domain. To get the dynamic information, we can rely on the Tcl APIs provided by verification tools (simulators) to access the dynamic values of the UPF and RTL objects. Together with the static and dynamic information, innovative applications can be written to help with the checking and debugging of a design.
UPF 3.0 also presents the HDL package functions and native HDL object definitions for the UPF object, which has some dynamic information; e.g. power domain, power states, etc. Native object definition and usage is described in the example in the following section. Using these HDL package functions, the user can access the static and dynamic information of low-power object in HDL. This capability can be leveraged to help verification engineers create random verification scenarios.
KEY COMPONENTS OF THE UPF 3.0 INFORMATION MODEL
There are two main components of the information model.
Objects: These are the primary holders of information, accessed by a handle ID. They represent UPF, HDL and the relationship between them.
There are three main classes of objects, namely:
- UPF Objects: Model objects created by UPF.
- HDL Objects: Model objects representing the HDL design.
- Relationship Objects: Objects that model the relationship of UPF and HDL objects; e.g. upfExtentT, upfCellInfoT.
Properties: These are the basic pieces of information accessed by a property ID; such as UPF_NAME, UPF_ISOLATION_STRATEGIES.
UPF 3.0 HDL PACKAGE FUNCTIONS
Native HDL Representation
UPF 3.0 defines the native HDL representation for objects that have dynamic properties. The native HDL representation is the struct/record type in HDL that contains two fields.
- A value field corresponding to the dynamic property of the object.
- A handle or reference to the UPF object to allow access of other properties of the object.
The following HDL types are supported with a native HDL representation:
In Table 1, the field representing the dynamic property of the object has been highlighted in bold. For example, for a power domain or supply set, the associated dynamic property is the current power state of the power domain which is represented by the current_state field of the struct in the SV native representation of the upfPdSsObjT type. The other field is a handle to the low-power object, which has all the static information about the object; e.g. object name, its creation scope, and file/line information.
Table 2 summarizes the UPF 3.0 information model objects with native HDL information. The HDL types defined in Table 1 are used to represent the dynamic properties of these objects.
HDL Package Functions
UPF 3.0 provides a number of HDL package functions that are used to access low-power objects and their properties. These are broadly classified in the following five classes of functions:
1. HDL access functions: These are the basic functions to access the low-power objects and properties. For example, the following access function can be used to get the handle of an object.
- returns the handle of power domain ‘pd’
One of the key HDL access functions is the “upf_query_object_properties”.
This function returns the handle to a property corresponding to an enumerated value passed as property, e.g.,
- returns the creation scope of power domain with handle ‘pd’.
2. Immediate read access HDL functions: All the objects in the UPF 3.0 information model allow read access to its properties. In the case of dynamic properties, these functions return the current dynamic value/state of that property when this function is called; for example:
3. Immediate write access HDL functions: Some objects of the information model allow the immediate write access only if they don’t have an existing driver. This allows the manipulation of low-power objects from a testbench or simulation model. For example: supply_on(“supply_net_name”, value). The following objects allow immediate write access:
These functions are a powerful tool for users to manipulate low-power objects during simulation from a testbench.
4. Continuous access HDL functions: These functions enable continuous monitoring of dynamic values of an object in the information model. It enables the user to trigger an always block or process statement using the dynamic values of the low-power objects.
5. Utility functions: These functions are general utility functions to assist users. For example:
- returns the type of a handle. Using this, the user can find out if the object is a power domain, supply set, or some other low-power object.
UPF 3.0 TCL API
The UPF 3.0 information model defines a number of Tcl query commands to access low-power objects and properties. UPF 3.0 introduced a Tcl-based Information Model Application Programmable Interface. This API can be used to access power-aware information:
Basic Tcl API
## To get various attributes on a given object
## To get the type of the object
## To check if an object belongs to a particular group
## To get the full hier path of an object relative to given scope
An object handle is used to access any power aware information. A handle can be a pathname; e.g., /tb/top1/PD1.ret1, or some tool assigned ID; e.g., #UPFEXTENT1234#.
Building Tcl Based Power Aware Apps Using Tcl APIs
Tcl based apps are nothing more than Tcl procedures users can write for special requirements, such as reporting, debugging or checking the design. Building blocks of Tcl procedures (Tcl Power Aware Apps) include:
- Four basic UPF 3.0 APIs which can be used to access any UPF information.
- Tcl APIs provided by verification tools (simulators) to access the dynamic data.
Once an app is built using the above APIs, it can be run either in a verification tool environment, at their static time, to get static information or in post-simulation to get both static and dynamic waveform data. The following is an example of how the user can build an app to find the source of corruption/retention of a signal and see the values of these signals.
Here the signal in question is /tb/chip_top/c, which is corrupted at some time instance in simulation. The goal is to find the source of corruption of this signal: #aliasing upf_query_object_properties to simple name such as alias alias query upf_query_object_properties.
# Step 1: Get the properties of the signal
# Step 2: Get the properties of cell applied on that signal
# Step 3: Get the properties on source extent (extent of power domain, retention strategy, etc.) of the cell
# Step 4: Get the supplies of the upf_object (power domain, retention strategy etc.)
# Step 5: Get the power (or other relevant function) of the primary supply set
# Step 6: Check the value of UPF supply net
EXAMPLES AND CASE STUDIES
When using Tcl APIs and HDL package functions a number of novel objectives can be achieved. This section captures some of the innovative Power Aware Apps based on information model APIs to solve practical low-power verification problems, which otherwise are relatively difficult to solve and users have to rely on tool vendors for those specific features. The article captures a few useful applications. However, along similar lines, users can write their own application for various needs.
There are two main approaches to access and manipulate the low-power objects and properties. First we will describe Power Aware Apps using HDL package functions and then Power Aware Apps using Tcl APIs.
Power Aware Apps Based on HDL Package Functions
Low-Power App 1: (Coverage App) Coverage of a Low-Power Design Using HDL Package Functions
In a low-power design, it is of utmost importance for a verification engineer to ensure that all IP in the design behaves properly in OFF/ON mode. They also need to ensure that transitions from ON->OFF and OFF->ON have been verified. This requirement can be achieved by creating a coverage infrastructure to ensure the full coverage of the simstate property of the primary supply set of all power domains.
The aim of this application is to do simstate coverage (Normal/Corrupt) of all the power domains in the design. The application will cover the NORMAL-> CORRUPT and CORRUPT->NORMAL transitions for each power domain in the design. The following shows how UPF 3.0 HDL package functions can be used to achieve this.
Step 1: Mirror UPF objects to HDL objects
Use the mirror function to continuously monitor the simstate of all the power domain in the design:
Step 2: Covergroup definition for state and transition coverage
Step 3: Instantiation of coverage module:
Monitor the simstates of a power domain: User can also monitor the simstates of one or more power domains of interest.
Low-Power App 2: Write Function to Print Current Simstates of a Power Domain Using HDL Package Functions
Users can write the following set of functions to print the simstates of all the power domains of the design at any instance of time in simulation.
Power Aware Apps Based on Tcl APIs
Low-Power App 3: (Reporting App) UPF query_* commands
Reporting is an essential part of the low-power verification process. Once the power intent is captured in a UPF file, it is important for the verification and design engineers to know that it has been captured as the original intention. This requirement can be fulfilled by query_* procedures. These query commands can query the UPF data as interpreted by the verification tools and stored in the information model. The output of query commands can be used to do selective reporting.
Low-Power App 4: (Debug/Reporting App) Get All Attribute Information
In a low-power design, along with the UPF file, some of the power intent can be present in a Liberty file. The Liberty information is annotated on RTL objects using attributes which can then be further updated using the UPF command set_port_attributes. In a low-power design containing hard macros, attribute information plays a vital role when debugging or reporting. These low-power attributes can be present on an instance or port of an instance. This low-power app can be used on any signal or instance in the design to get the attribute information and the respective signal values if wave data is available.
Low-Power App 5: (Debugging App) Trace Drivers of UPF Objects
For a low-power design consisting of RTL along with UPF, all the supply network including creation of ports, nets, and their connections is written inside the UPF file. Debugging of the supply network is a major problem that many verification engineers come across. This low-power app is useful as it can trace the driver of any UPF objects along with printing the values of all the ports and nets in the path. The input of this app can be either a UPF created supply, Liberty created supply pin, or a supply defined in HDL.
POSSIBLE USAGE OF HDL PACKAGE FUNCTIONS AND TCL APPS
As observed in the above sections, there are two main approaches to access and manipulate the low-power objects and properties. One is HDL package functions and the other is to use the Tcl query commands. There are different scenarios in which one or the other approach is suited. Table 3 summarizes the various usage scenarios where HDL package functions or Tcl query commands can be used.
Verification engineers can use the proposed verification approach to achieve early low-power verification closure. The approach mentioned in this article using the UPF 3.0 information model provides a number of benefits. This approach is consistent across tool vendors as it is based on the UPF 3.0 standard. The learning curve for users is not steep. Also the user scripts created to use the proposed solution are easily scalable to bigger and more complex design scenarios.
Low power designs today are incredibly complex with intricate power architectures. Thorough low-power verification is a must for such designs, as any power bug left can cause a huge setback. In this article we have discussed the challenges of current low-power verification methods and how those challenges can be addressed better with UPF 3.0. We discussed the concepts of the UPF 3.0 information model and API to represent and access the low power information which is the result of the application of UPF on the design. We also presented examples and case studies showing how the UPF 3.0 information model concepts can be used to develop a more consistent, robust, and scalable low-power verification platform. In the end we discussed the benefits of using the proposed approach over conventional approaches.
Following the original publication of this article, there have been further developments that affect how SV-based testbenches that leverage the UPF SV API could be used in simulation. These additions are part of the forthcoming IEEE1801-2018 standard:
- A new relationship singleton object has been added to the UPF information model. Using this relationship object, an SV testbench can retrieve all power domains in a design.
- The native HDL type upfPdSsObjT (implemented as struct in SV) now has an additional field in upfSimstate current_simstate that reflects the current simstate of a supply_set or, in the case of a power domain, the current simstate of the domain’s primary supply set handle.
-  IEEE Std 1801™-2015 for Design and Verification of Low Power Integrated Circuits. IEEE Computer Society, 05 Dec 2015.
-  “Amit Srivastava, Awashesh Kumar”, PA-APIs: Looking beyond power intent specification formats, DVCon USA 2015
-  “Awashesh Kumar, Madhur Bhargava”, Random Directed Low Power Coverage Methodology: A Smart Approach to Power Aware Verification Closure, DVCon USA 2017
-  “Awashesh Kumar, Madhur Bhargava”, Unleashing the Power of UPF 3.0: An innovative approach for faster and robust Low-power coverage, DVCon India 2017
Back to Top