Three Steps To Faster Low Power Coverage Using UPF 3.0 Information Models

Controlling power has its costs. The added power elements and their interactions make verification of low-power designs much more difficult and the engineer’s job overwhelmingly complex and tedious.

Early versions of the Unified Power Format (UPF) provided some relief, but lacked provisions for a standardized methodology for low-power coverage. Ad hoc approaches are error prone and highly time consuming.

What’s urgently needed is a reliable and straightforward verification methodology which is easy to build, easy to understand, easy to modify, and scales to match larger designs. Fortunately, UPF 3.0 introduced the low-power information model, which can be useful to address complex low-power verification challenges.

A low-power coverage methodology based on the recently introduced UPF 3.0 low-power information model HDL package helps verification engineers achieve low-power coverage closure earlier and more efficiently.

Figure 1: Low-power coverage ensures adequate testing of power-aware elements in a design.

The hunt for the elusive UPF objects
Capturing the coverage information of UPF objects and power states is challenging for several reasons. Power states are written in an abstract manner in UPF, there is no pre-defined coverage metric to capture power states and their transitions, and although the Unified Coverage Interoperability Standard defines various standard metrics related to coverage items, it does not provide any metric to capture power intent.

Tool-generated coverage metrics are used widely for low-power verification. However they may not be useful or exhaustive in all designs, primarily because a design can have a very specific requirement that is not provided by the tool-generated coverage, and low-power technology is still evolving; hence, a new set of protocols appear every now and then, which may require a different set of coverage features not yet provided by tool vendors.

Engineers may opt to write custom coverage items using SystemVerilog coverage features. These items can be grouped in a checker module, and this checker module can be instantiated into a design using the UPF command, “bind_checker”. However, the method of instantiation of such a checker module is not trivial. Low-power assertions and coverage items require access to power objects. However, at the early stages of verification, these power objects are only present in the UPF file and do not exist in the design. It is therefore not straightforward to pass these UPF objects to a checker instance. There is no clear way to describe the coverpoints and bins to capture the coverage of power states and their transitions using the handles obtained. Some of the property-checking requires access to design and power signals spanning multiple domains. Such a task is highly error prone and time consuming. Finally, as the scope and the inputs of these checker instances are defined in UPF, any change in the UPF or design might break these checkers, requiring them to be rewritten.

A modeling style using covergroups and the UPF information model query commands neatly addresses these challenges.

The UPF 3.0 Information Model
UPF 3.0 introduced the low-power information model to represent the low-power objects created in UPF. These include power domains, power states, and supply sets. UPF 3.0 also provides detailed lists of various properties which those objects have. These properties can be simple information (e.g., the name and file/line information of an object) or relatively complex information (e.g., the power states of a power domain). Some objects also have dynamic properties associated with them (e.g., the current_state of a power domain or the current voltage value of a supply net). The UPF 3.0 information model also provides an API interface to access the objects and its properties.

Two key information model concepts — native HDL representations and HDL package functions — can be used to develop a low-power coverage methodology that can be random in construction and directed in approach to target specific low-power scenarios.

UPF 3.0 defines the native HDL representation for the objects which 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, and a handle or reference to the UPF object to allow access of other properties of the object.

Figure 2: A UPF 3.0 information model is represented by a struct/record in HDL containing two fields: a value field and a handle/reference to the UPF object.

UPF 3.0 provides a number of HDL package functions that are used to access the low power objects and their properties. These are broadly grouped into five classes.

1. HDL access functions: These are the basic functions to access the low power objects and
2. Immediate read access HDL functions: All the objects in the UPF 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.
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 This is a powerful tool for manipulating 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 triggering an always block or process statement using dynamic values of the low power
5. Utility functions: These are general utility functions.

Leveraging functions and constructs
This methodology uses the UPF 3.0 package functions to achieve fast and effective low-power coverage. UPF 3.0 HDL functions can be combined with SystemVerilog coverage constructs to devise an efficient and random-directed low power coverage methodology. The aim of such a low-power coverage methodology is to enable you to write fast and reliable low power coverage infrastructures.

The methodology involves getting the handle of a low-power object in HDL, using the information model and querying the properties of that object. These properties are then passed to the coverage module as port mapping. The coverage module contains the covergroups and coverbins that represent the coverage data of the low-power strategies of that domain, or dynamic information, such as the current power state of the domain, can be queried from a testbench. The three steps in the proposed methodology are:

1. Low power object handle: The first step is to get the handle of the low power This can be achieved by using the HDL package function “upf_get_handle_by_name”. A property which is a list can be iterated through the HDL access function “upf_iter_get_next”. The following SystemVerilog code illustrates the usage of these basic function to access low power objects.

upfHandleT pd = upf_get_handle_by_name("/tb/dut/pd")
upfHandleT pd_state_list = upf_query_object_properties(pd,UPF_PD_STATES)
upfHandleT pd_state = upf_iter_get_next(pd_state_list);

2. Dynamic property (value) of low power object: In the second step, you get the dynamic value of the property of interest. For example, you might be interested in knowing the current power state of a power domain with the intention of checking the state of this power domain with regard to the current power state of some other power Also you may use a UPF 3.0 continuous access HDL package function to continually monitor the power state of a power domain and use assertions for the cases of interest or anomalies.

upfPdSsObjT pd_hdl;
upf_create_object_mirror(“/tb/dut/pd”, “pd”);
upfPowerStateObjT pwr_state = pd.current_state;
upfHandleT pd_name = upf_query_object_properties(pd.handle, UPF_NAME);
upfHandleT state_name = upf_query_object_properties(pwr_state.handle,UPF_NAME);
always@(pd)
   $display( "Power domain %s, is in Power State: %s,
   upf_get_value_str(pd_name), upf_get_value_str(state_name));

3. Coverage details: Once we have the handle of a low-power object and its dynamic value, it is passed to a coverage The coverage module can be modeled in SystemVerilog and compiled together with the design. This module is instantiated in the testbench. The low-power object extracted from the information model and its dynamic properties are passed in the interface of this coverage instance. You can instantiate as many coverage instances as required. Coverage properties (covergroups/coverpoints) are defined inside the following coverage module to calculate the coverage metrics.

module covIsoModule (int dynamicValue, string objName)reg cov_clk = 0;
covergroup LOW_POWER_STATE_COVERAGE(posedge @cov_clk)
   ACTIVE_LEVEL: coverpoint isovalue { bins ACTIVE = 1; }
   ACTIVE_LOW: coverpoint isovalue { bins ACTIVE = 0; }
endgroup
…
endmodule

The verification approach described helps achieve early low-power coverage closure. It is also possible to do directed scenario testing using this methodology. For example, you can write a custom assertion or property to check if two domains should be in a mutually exclusive state by using the UPF 3.0 information model’s immediate read access function. Because the methodology relies on UPF constructs, it is consistent and usable across different vendor tools. Even without detailed knowledge of complex UPF constructs and semantics, verification engineers can write various directed verification scenarios to achieve low-power coverage closure.

With the increasing complexities of low power verification, ad-hoc approaches are not likely to succeed and will result in incomplete verification. This methodology will help you achieve verification closure in significantly less time and with a lot less trouble.

Interested in learning more? Read the whitepaper Random Directed Low Power Coverage Methodology for more details on low-power verification challenges, the UPF 3.0 low-power information model, and the benefits and advantages of this approach over conventional low-power verification methodologies. The paper also shares relevant case studies and examples in solving low-power verification problems.