Vinod Viswanath is a Director of R&D at Real Intent, where he works on next generation tools to understand and implement low power and timing constraints. Prior to this, he was a researcher in Intel’s low power group working on formal verification of processors and SOC platforms. Vinod … More »
UPF 3.0 – Making Power Intent Manageable, Incremental and Executable
April 7th, 2016 by Vinod Viswanath
UPF provides a consistent format to specify power design information that may not be easily specifiable in a design description. In certain situations it is undesirable to specify power semantics directly in the HDL, as doing so might tie down the implementation to certain power constraints. UPF provides a way to specify the power intent for different states and contexts, external to the design, to be used for implementation, modeling, simulation and verification. The semantics of UPF are consistent across implementation and verification, guaranteeing that what is being verified is indeed what was implemented.
UPF assumes a logical hierarchy that is a more abstract model of the design hierarchy. The logical hierarchy can be viewed as a conceptual structure for locating power management objects such as power domains and power states. Each object is defined in a specific scope of logical hierarchy. This logical hierarchy can be effectively used in a top-down UPF methodology, where the more abstract states are higher up in the hierarchy (global states), and the lower hierarchical objects are more refined versions of their ancestors.
Such a top-down methodology is actually very close to current SoC design methodology. Previous designs done in-house or via third-party IP are extensively used in SoC design today to reduce development cost and time to market. To manage these IP-based flows, most SoC designs are implemented with hierarchical top-down design flows. Given the complexity of design analysis, hierarchical design flow also allows a way to overcome capacity limitations of design and verification tools. A top-down UPF flow fits seamlessly with this approach. The tricky part comes with the IP blocks. The power intent specification for an IP block to be used in a larger design typically defines the power interface to the block and the power domains within the block. This specification also typically includes constraints on using the block in a power-managed environment. The IP block UPF, which contains the atomic power domains, power states, and the state transitions of the IP block, is often referred to as a constraint UPF. When the IP is being prepared for use in a larger system, the specification can be enhanced to fit the context of the system (for example, it may require adding isolation and retention strategies). The power specification with this context information is referred to as the configuration UPF. Finally, to drive the implementation, we may have to define power distribution network information, logic for the power management cells, etc. This specification is referred to as the implementation UPF.
Once the UPF hierarchy is set up, UPF provides commands to specifying retention strategies, repeater strategies, isolation strategies and level-shifting strategies. Each of these can be defined in various ways to apply specific design features, with precedence orders in cases where multiple strategies apply to the same feature, etc.
While implementing a system, occasionally it might be necessary to implement an instance separately from the top-level scope, with the intention of integrating this block back into the system later in the flow. This flow style is a bottom-up flow. When using a bottom-up flow, the UPF partitioning has to ensure that the implementation of the lower-level instance can be done without the parent scope being available. Self-contained UPF is UPF that defines its own top-level domain and does not require power intent to be defined in any external scope to complete the power intent.
In system level design simulations, faster run times are generally attained via design abstraction. In order to extend this analysis to accommodate power, we have to annotate power information onto this simulation. UPF provides system-level IP power models for exactly this purpose. The power models are intended to be used in system-level design, although, there is nothing to prevent their use in other types of analysis at all levels of design abstraction. From the standard perspective, modeling all types of IP components is supported with no limitations on use. The IP power model cannot make any changes to the state of the system.
Specifically in the 2015 standard, the UPF power state supports a model (-model) and a power function (-pwrfn) switch to support modeling as well as refinement. Power function of a “current” power state is the natural function to use for power computations at that state. More refined power states would have more detailed power functions. The power model contains an enumeration of all the power states, power consumption data for each, and a definition of all legal power state transitions.
Even with all these power models, the larger problem remains unaddressed. Today, when SoCs are optimized for specific applications, the optimizations are done in isolation without utilizing the knowledge of the workloads. Due to lack of hardware/software cooperation in power management, the platform as a whole cannot anticipate power requirements of the application ahead of time and, instead, has to perform power management reactively.
Going forward, it is quite clear that neither hardware nor software in isolation can make the best decision about power and performance management, and cannot just manage the CPU alone, but must now include the entire platform level, in a holistic way. Any such holistic approach needs a common representation of power intent at all levels of design hierarchy, and power management engines at each level need to make decisions based on the unified set of power constraints. It is imperative that a holistic platform-level dynamic power management system be aware of (a) different power states supported by different components, both at architectural and microarchitectural level; (b) current power consumption of the platform as a whole, and at the individual component level; (c) power requirements of applications and workloads; and (d) continuous feedback from the platform on performance with respect to overall power constraints. We need a synergistic bottom line across RTL, System level, OS level, Compiler level, and Application level specifications of power intent. The kind of information available at a higher level of abstraction at the OS level or even at the Application level is just not visible to the RTL. To get the most optimized solution,we need all levels of abstraction of the design to be able to communicate their power intent.
This leads to a new set of abstractions all along the design and application hierarchies, the power abstraction. At the workload level, the application needs to specify what kind of power requirements it has. This translates to compiler level constraints and then O/S constraints and so on all the way to the RTL and gate-level designs. There are two new requirements on such a system:. (1) We need feedback going up the abstraction levels. The hardware needs to let the O/S know how it is performing, power-wise and so on. (2)We need a fast and dynamic constraint solver/power manager that can combine the feedback with the spec to generate the next set of optimizations.
Key to all this coming together is a standard way to communicate across these levels of energy abstractions. IEEE Standards Association is addressing this via three ongoing standards efforts – IEEE 1801 (system power), IEEE P2415 (power specification in software and O/S), and IEEE P2416 (power modeling).
Beyond this, thermal considerations cannot be handled in isolation either. The objective of thermal management is to meet “maximum operating temperature” constraints, while maintaining performance requirements. Typically thermal control policies manage power consumption via dynamic frequency and voltage scaling (DVFS) and can be targeted to power density reduction because it has the effect of reducing overall temperature. Thermal control policies using DVFS avoid violations of temperature bounds by transitioning processors into low power modes to cool down, but obviously this incurs a performance penalty. In addition, abrupt power mode transitions due to DVFS could also waste power.
One Response to “UPF 3.0 – Making Power Intent Manageable, Incremental and Executable”