Shift-Left Low Power Verification With UPF Information Model

How to use UPF information model APIs to write re-usable low power testbenches that can monitor and control UPF objects.

popularity

By Himanshu Bhatt, Shreedhar Ramachandra and Narayanan Ganesan

Low power testbenches today have no visibility of the UPF objects and their states during a low power simulation. This has been one of the factors limiting the users from writing re-usable low power testbenches that can monitor the UPF objects and react to the state changes of UPF objects. To meet this requirement for the user to query the UPF data model and the states of the UPF objects during a low power simulation, the UPF LRM has defined the UPF information model (UPF IM) and added the mechanism to query the UPF data model at compile time (using TCL queries) and at runtime using (System Verilog APIs). UPF IM is the definition of how the UPF information is organized in the form of a UPF data model that can be queried using TCL and System Verilog. The TCL query mechanism lets the user query the UPF IM. The System Verilog APIs to can be used to query the UPF data model and monitor and control the UPF objects during simulation. This article explores different applications of the UPF IM APIs that will enable the users to write re-usable low power testbenches that can monitor and control the UPF objects. The UPF IM that is a part of the UPF standard is still undergoing enhancements to cater to more requirements in terms of querying the UPF information. The scope of applications that can be built on these APIs is much more than what is described here.

Need for low power assertions and reactive testbenches

Assertions (both in design and test bench) are an integral part of dynamic verification methodology. With low power their significance increases multifold because of the complexity of the current and next-generation low power SoCs. They enable a reduced turnaround time (TAT) in the debug and overall verification closure effort. Having a re-usable power aware testbench is extremely important for enabling “shift-left” considering the tight tape-out schedules. Below are the attributes of traditional and reactive power aware testbenches.

Traditional Power Aware (PA) Testbench

  • Power network not accessible
  • Disjoint RTL and UPF worlds
  • Only Drive Supplies, Controls
  • Assertions – Monitor only logic states


Figure 1: Traditional versus Native Low Power Verification

Reactive Power Aware (PA) Testbench

  • Power network accessible
  • Merges RTL and UPF worlds
  • Drive/Monitor Supplies, Controls, Power states
  • Assertions – Monitor power events


Figure 2: Reactive Power Aware Testbench

UPF information model

  • Standardized in IEEE 1801-2015 UPF 3.0 LRM
  • Enables users to create modular, scalable, reusable Power Aware Test bench
  • Access mechanism is through System Verilog APIs
  • Query objects and properties from information model


Figure 3: UPF Information Model

Objects and properties

The UPF information model consists of a collection of objects and the properties present on those objects. These objects belong to one of the various classes defined in the information model. The objects in the information model are the primary holders of information. They are instances of the classes that belong to the UPF information model. They represent information about UPF and HDL and the relationship between UPF and HDL. The information is present on these objects in the form of properties, which can be accessed via APIs. Each object shall be denoted by a unique identifier called a UPF handle, which shall be used by the APIs to access information present on it. They are broadly classified into three groups:

  • UPF objects
  • HDL objects
  • Relationship objects

Examples of objects:

  • Power Domain
  • Retention/Isolation/Level-Shifter Strategy
  • Supply Set
  • Named Object Reference
  • Supply Net/Port
  • Logic net/Port
  • Power Switch
  • Power State
  • PST
  • HDL Scope
  • UPF Extent

Properties are pieces of information present on an object, which can be either static or dynamic.

For example, in the context of a power domain (PD), the static properties would be:

  • Primary supply of PD
  • Isolation strategy of PD

Similarly, the dynamic properties would be:

  • Current state of supply set
  • Current value of control signal

Access to the UPF data can be provided using two mechanisms:

  • Immediate access
  • Continuous access

Immediate access

This allows access to current state/value of UPF objects. Immediate access is needed for the user to write custom assertions using the dynamic properties.

Dynamic property – Examples

Dynamic property Object
UPF_CURRENT_STATE,UPF_CURRENT_SIMSTATE Power domain/Supply set
UPF_CURRENT_VALUE Supply net


Figure 4: Immediate Access

Continuous access

This is achieved using the mirroring of objects. The UPF objects are mirrored to a local user defined variable. This enables continuous monitoring of UPF objects. The main application of continuous access mechanism is to monitor the power states/sim states which in turn helps in creating coverage models.

Native HDL representation for mirror variables

Mirror data type Object
upfPdSsObjT Power domain/Supply set
upfPowerStateObjT Power state
upfBooleanObjT Control value
upfSupplyObjT Supply net/port value


Figure 5: Continuous Access

Triaging low power bugs

Synopsys has implemented information model API based infrastructure that you can use to triage low power bugs. Below are two examples of bugs that can be caught using these applications. These applications can be built only using the runtime APIs, since they require monitoring the states of UPF objects during simulation.

Example 1: Incorrect isolation enable during power down

Bug: ISO control disabled during power down

Catch: Assertion using Information model

  • Mirror power domain – Monitor sim state
  • Query isolation strategy and isolation control of strategy
  • Monitor isolation control value on sim state transition


Figure 6: Incorrect ISO enable during power down

Example 2: Power switch control always enabled

Bug: Power switch control tied off – domain never shuts down

Catch: Coverage using Information model

  • Mirror PD primary supply
  • Mirror variable of type upfPdSsObjT
  • Monitor power state and sim state of supply
  • Coverage for state and transition – PD OFF state uncovered


Figure 7: Power switch control tied off

Conclusions

There are some applications that can be built only using the runtime APIs, for example monitoring states of UPF objects during simulation. However, the amount of performance impact is proportional to the number of UPF objects whose states are being monitored at runtime. The benefit propositions of this methodology are that it avoids waveform review for power collapse and power up and allows to have more random verification for power aware tests. Using the APIs, users can write covergroups/coverpoints like custom cross coverage between power domain state and design signals, between multiple power domains and cross functional cover points with power aware coverage. This greatly helps to reduce the turnaround time for verification thereby enabling a “shift-left” in the overall verification closure.

Shreedhar Ramachandra is a R&D Engineer, Senior Staff, in the low power verification team in the verification group at Synopsys. He has 14+ years of experience, starting his career as an ASIC design and verification engineer before moving to EDA (Electronic Design Automation), focused on architecting low power simulation products starting from Archpro MVSIM. He currently works as an Application Engineer for Synopsys’ VCS NLP product and also represents Synopsys in the IEEE-1801 UPF Committee.

Narayanan Ganesan is Applications Engineer, Staff, in the verification group at Synopsys. He has 16 years of experience spanning both semiconductor and EDA space, in ASIC functional/low power verification of IPs and SoCs using verification methodologies such as System Verilog UVM, UPF.



Leave a Reply


(Note: This name will be displayed publicly)