Extending UPF for incremental growth
Erich Marschner
Accellera’s Unified Power Format (UPF) is in production use today, delivering the low-power system-on-chip (SoC) designs that are so much in demand. Building upon that success, IEEE Std 1801-2009 [UPF] offers additional features that address the challenges of low-power design and verification. These include more abstract specifications for power supplies, power states, and other elements of the power management architecture, all of which provide additional flexibility for specification of low-power intent. Support for the incremental development of power architectures extends the usefulness of the standard into IP-based, hierarchical methodologies where base power architectures may have been established independent of the IP components used in the overall design. This article reviews some of the new features in IEEE Std 1801-2009 that can make UPF-based flows even more effective.
Yatin Trivedi
The Accellera standard, fully incorporated in IEEE Std 1801-2009, introduced the concept of a power architecture specification. This includes power domain definitions (i.e., groups of design elements with the same primary power supply), power distribution and switching networks, and power management elements such as isolation and level shifting cells that mediate the interfaces between power domains. The specification of state retention across power down/up cycles was also included. These capabilities encompass both the verification and the implementation semantics, so the same UPF specification can be used in both contexts. IEEE Std 1801-2009 builds on this concept to offer additional capability, flexibility and usability.
Supply sets
UPF introduced the capability of defining supply nets, which represent the power and ground rails in a design. In some cases, such as during the development and integration of soft-IP, it can be more useful to define nets that must be used in pairs to connect design elements to both power and ground. In addition, there may be other supplies involved, such as is entailed in support for bias rails. IEEE Std 1801-2009 introduced the concept of a ‘supply set’ so that it can represent such a collection of related nets.
Syntax:
create_supply_set <set_name>
{ -function { <func_name> [ <net_name> ] } }*
[ -reference_gnd <supply_net_name> ]
[ -update ]
Each of the supply nets in a supply set contributes some abstract function to it. The function names, specified via the ‘–function’ option can have either predefined values (e.g., ‘power’, ‘ground’, ‘nwell’, ‘pwell’, ‘deepnwell’, or ‘deeppwell’), or user-defined names. The predefined values allow the user to specify standard power functions such as the primary power and ground nets or bias power nets. The user-defined names may be used as placeholders for later modification or as potential extensions for analysis tools.
A supply set can be defined incrementally, as progressively more information becomes available. Initially, a supply set can be defined in terms of functions. Later, those functions can be mapped to specific supply nets. Separately, the supply set can be associated with a power domain; a power switch; or a retention, isolation, or level shifting strategy. For example, the initial definition of a supply set might be given as follows:
create_supply_set SS1 -function {PWR} –function {GND}
Later, the abstract functions ‘PWR’ or ‘GND’ can be mapped to specific supply nets, using the ‘–update’ option:
create_supply_set SS1 –function {PWR vdd} –update
create_supply_set SS1 –function {GND vss} –update
The function names defined as part of a supply set also contribute to automating the connection of supply nets to pins of design elements. When a supply set is connected to a design element, each individual supply net in the set is automatically connected to a supply port based on the correspondence between supply net function and supply port attributes. For example, for a given supply set S, the supply net that is the ‘power’ net within S will be associated with any supply port that has the ‘pg_type’ attribute ‘primary_power’.
Power States
The Accellera UPF standard introduced several commands (‘add_port_state’, ‘create_pst’, ‘add_pst_state’) to define the power states of the system in terms of the power states of the power domains of which it is comprised. These in turn are defined in terms of the states and voltage levels of supply nets. In IEEE Std 1801-2009, these capabilities are expanded to include an additional approach to defining power states: the ‘add_power_state’ command. This new command applies to both supply sets and power domains.
Syntax:
add_power_state <object_name>
-state <state_name>
{ [ -supply_expr <boolean_function> ]
[ -logic_expr <boolean_function> ]
[ -simstate <simstate>
[ -legal | -illegal ]
[ -update ]
}
Power states can be defined abstractly at first, using ‘–logic_expr’, the argument of which specifies the condition or conditions under which the object is in the given power state. The condition is given as a boolean expression that can refer to logic nets or supply nets. This is useful when power states are being defined before the power distribution network has been defined. Later, when the power distribution network is in place, the power state definition can be refined by specifying the state in terms of the states of supply nets only, using ‘–supply_expr’. The supply expression definition is the golden specification of the power state. When both ‘–logic_expr’ and ‘–supply_expr’ are given, ‘–supply_expr’ is treated as the primary definition, and ‘–logic_expr’ is then used as an assertion, to check that the more specific supply expression is indeed true only when the logic expression is also true. This helps ensure consistency as the power architecture is elaborated and further refined during development.
Incremental refinement for power states can be quite powerful. In this case, it can be applied to the boolean function that defines the power state. For example, an initial power state specification might be given as follows:
add_power_state P1 –state FULL_ON –logic_expr PWR_ON
The end result is that object P1 will be in state ‘FULL_ON’ whenever logic net ‘PWR_ON’ evaluates to ‘True’. A subsequent command can refine the logic expression to further restrict it, as in:
add_power_state P1 –state FULL_ON –logic_expr RDY –update
which would refine the logic expression for state ‘FULL_ON’ of P1 so that it is now ‘(PWR_ON && RDY)’. The same kind of refinement can be performed on the supply expression.
Simstates
The Accellera UPF standard introduced simulation semantics for UPF specifications. In IEEE Std 1801-2009, the simulation behavior semantics have been further developed under the concept of ‘simstates’. For any given power state, the simstate specifies the level of operational capability supported by that power state, in terms of abstractions suitable for digital simulation.
Several levels of simstate are defined. ‘NORMAL’ represents normal operational status, with sufficient power available to enable full and complete operational capabilities with characteristic timing. ‘CORRUPT’ represents non-operational status, in which power is either off or so low that normal operation is not supported at all, and both nets and registers are in an indeterminate state. In between these two extremes are three other simstates: ‘CORRUPT_ON_ACTIVITY’, ‘CORRUPT_STATE_ON_ACTIVITY’ and ‘CORRUPT_STATE_ON_CHANGE’. These represent intermediate levels of ability to maintain state despite lower than normal power.
Simstates are defined for power states of supply sets. As the power state of a supply set changes during simulation, the corresponding simstate is applied to the design elements, retention registers, isolation cells, or level shifters to which the supply set is connected. The simulation semantics of the various simstates are shown in Figure 1.
Incremental refinement applies to simstates as well. The simstate of a given power state can be defined initially as ‘NOT_NORMAL’, indicating that it is a non-operational state, without being more specific. A later UPF command can update the definition to specify that it is any one of the simstates other than ‘NORMAL’. By default, the ‘NOT_NORMAL’ simstate is treated as if it were the ‘CORRUPT’ simstate, a conservative interpretation. By refining a ‘NOT_NORMAL’ simstate, the corruption effects can be limited so that they only apply to activity on wires or state elements, or to changes of state elements.
Simstate |
Combinational Logic |
Sequential Logic |
Corruption Semantics |
NORMAL |
Fully Functional |
Fully Functional |
None |
CORRUPT_STATE_ON_ACTIVITY |
Fully Functional |
Non-Functional |
Regs powered by the supply corrupted when any input to the reg is active |
CORRUPT_STATE_ON_CHANGE |
Fully Functional |
Non-Functional |
Regs powered by the supply corrupted when the value of the register is changed |
CORRUPT_ON_ACTIVITY |
Non-Functional |
Non-Functional |
Wires driven by logic and regs powered by the supply corrupted when any input to the logic is active |
CORRUPT |
Non-Functional |
Non-Functional |
Wires driven by logic and regs powered by the supply corrupted immediately on entering state |
NOT_NORMAL |
Deferred |
Deferred |
By default, same as CORRUPT. Tool may provide an override |
Summary
The Accellera UPF standard provided an excellent foundation for the development of low-power design and verification capabilities and is in production use with customers today. As a standard, it has enabled the interoperability of tools, which has in turn made possible a variety of low-power design and verification flows to meet different needs. Building upon this foundation, IEEE Std 1801-2009, which completely incorporates the Accellera UPF standard,defines new abstractions that can provide more flexible capabilities to support the incremental development of power architectures. These new capabilities can help UPF users address the low-power design and verification challenges that are becoming increasingly significant in today’s product development cycles.
Erich Marschner and Yatin Trivedi are members of the IEEE 1801 Working Group.