What’s Next for System-Level Power Modeling?

Competitive pressure needs to be applied to EDA and IP vendors to ensure that power-aware system-level design is pervasive.


Availability of models and libraries has long been one of the biggest barriers to the adoption of new EDA tools and methodologies, whether due to the investment needed to create these models and libraries or because of the “at-risk” nature of developing complex models in proprietary formats.

With the approval of UPF3.0 (IEEE 1801-2015) this past December, we now have an industry standard way to model the salient power characteristics of a piece of IP for use in system level design. The ability to source system-level IP power models from a wide variety of vendors with common syntax and semantics knocks down a sizeable barrier to the adoption of power aware system-level design tools and methodologies and will help usher in a new era of automation in low power system design. In fact, we already have power-aware system-level design tools available on the market today that support UPF3.0 as my colleague Pat Sheridan discussed in his article last month.

System architects now have what can be considered a solid baseline solution for power-aware system-level design, based on industry-standard power models that they can use immediately to help deliver increased energy efficiency for their platforms. Having an approved industry standard in place for system-level IP power modeling, coupled with a variety of EDA tools supporting that standard, will place increased pressure on the IP vendors to provide the necessary power models—and that’s a good thing. To help get over the hump in our adoption of power aware system-level design, we need to see some competitive pressure placed on both the EDA and IP vendors to ensure that power-aware system-level design is fully enabled across our industry.

Having the industry standard (UPF3.0) in place accompanied by some EDA tool support for that standard is a first step towards delivering comprehensive power aware system level design solutions. The next step is to focus on the quality of the data contained within our industry standard power model and its usefulness in helping deliver improvements in energy efficiency.

System-level IP power models, by design, can be used in a variety of system-level design methodologies, from software tuning through the development of system power management to energy-efficient hardware architecture exploration. This requires the power models to be flexible in their construction and content, providing the necessary tradeoffs between useful-accuracy, abstraction, portability and refinement. Enabling flexibility does not mean that we want a one-size-fits-all power model. We certainly don’t. We do, however, want a consistent look and feel to our power models with a common syntax and semantic definition, consistent interfaces and application, and a consistent methodology (or set of methodologies) to allow their automatic creation where possible.

There are three primary parts to a UPF3.0 system-level IP power model: (a) power state enumeration, (b) power state transition definitions and (c) power consumption per enumerated power state. In most cases, power state enumeration is very closely coupled to the functionality of the IP itself and derived from the functional specification. Power state transition definitions will be defined to some extent by the IP functionality, but also by the system-power management strategies employed for the IP so both (a) and (b) can be defined prior to implementation. Power consumption data for the IP typically will take one of two forms—either early guestimates or more accurate data obtained through power characterisation of the IP after physical implementation.

Accuracy requirements for the power consumption data vary by application and use-model and can be stated simply as, “The accuracy only needs to be as good as it needs to be.” There is no absolute target here for accuracy. Software teams will tolerate a much greater inaccuracy than the team tasked with signing off the power consumption of an SoC prior to tape-out. And even then, the term “accuracy” needs clarification.

Specifying the dynamic power consumption of a piece of IP in a particular power state is a delicate matter and one open to misuse in competitive benchmarking. The dynamic power consumption of the IP is highly dependent on the scenario(s) being used for characterization, as well as a number of design parameters including IP configuration, silicon process, variability, temperature, voltage and frequency, etc. In other words, the data is really only accurate for a very specific set of design parameters and scenarios.

In UPF3.0 we deal with this problem by separating the qualitative parts of the power model from the quantitative parts by use of a power function to calculate power consumption for a piece of IP in a particular power state. The power function accepts as input a number of these design parameters and returns both static and dynamic power consumption to the EDA environment.

Automating the creation of system-level IP power models, including the power function, is the natural next step now that we have the industry standard in place. It is currently a major area of focus for development teams. However, this is a non-trivial problem and requires careful definition of power characterization scenarios, identification of power critical design parameters, optimal implementation of the power function that can trade off speed of calculation with accuracy of data while protecting IPR and consideration of the refinement of power states within the IP itself — how many power states should be visible and when? All of these aspects present unique challenges to the author of a system-level IP power model and consequently automation of that process is considerably more challenging.

Finally, once we believe we have an automated power model creation process in place, how do we validate what we have created? How far into the design process do we need to travel in order to be sure that our power models correlate well with silicon? Then we have to determine how best to couple our system-level power models to thermal models, which will themselves need an industry standard definition in the near future.

Clearly there is still much work to be done in the area of system-level power modeling, but we have a good platform on which to build comprehensive solutions to the problem. An excellent opportunity exists to shift the focus of low-power system design into the system-level design arena with comprehensive automation and industry standard enablement.

  • Kev

    As far as I can tell UPF is only power-intent, like RTL is a behavioral description of logic (not the actual gates), and while gates generated from synthesis of RTL can be verified with formal or functional approaches, there is no flow for verifying UPF has been synthesized properly other than SPICE level simulation.

    Progress towards supporting post-synthesis power verification is almost non-existent, despite techniques like DVFS being used for over a decade, and you’re SOL with FDSOI body biasing.