A new version of IEEE 1801 enables complete power-aware flows to be constructed using a meet-in-the-middle concept. What will it mean to you and what new parts of the flow will it enable?
In December the IEEE released the latest version of the 1801 specification, entitled the IEEE standard for design and verification of low-power integrated circuits. Most people know it as UPF, or the Unified Power Format. That was the name the first version of it held while being developed within Accellera. The standard provides a way to specify the power intent associated with a design, enabling a designer to define the various power states of the design and the contexts associated with those states. That information can be used for modeling, verification and implementation.
UPF version 1.0 was handed over to the IEEE and turned into the first version of the standard IEEE 1801-2009. “The naming is getting no less murky,” says Dennis Brophy, director of strategic business development for Mentor Graphics. “We call it IEEE 1801-2015 and it has lost its UPF moniker. However, because of the commitment made by Accellera in the early development of the standard, the name UPF has stuck. With 3.0 it is a recognition that it has moved to a higher level of expression and integration of concepts, predominantly motivated by the CPF members coming together. Continuing to call it UPF makes it easy for those who are using it in the market and makes its heritage known.”
What’s new in 1800-2015
“Historically, UPF has been used to define power intent for the low power implementation and verification of circuits,” says Alan Gibbons, principal engineer at Synopsys. “With UPF3.0 we can now extend that to IP power modeling and provide an efficient way to model the salient power related characteristics of a piece of IP for use at the system level.”
The acknowledgement of a design hierarchy becomes an important part of it. “Now you can start with states and very logical states and then refine them into the voltage and supply nets,” says Ellie Burns, product manager at Mentor. “So we are growing up through the design flow.”
Vinod Viswanath, director of research and development at Real Intent provides more explanation about those states. “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 the current SoC design methodology, where IP blocks are assembled into the chip. It also establishes the three primary views of the UPF description, Viswanath says. “The power intent specification for an IP block 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 and logic for the power management cells. This specification is referred to as the implementation UPF. Once the UPF hierarchy is set up, UPF provides commands for specifying retention strategies, repeater strategies, isolation strategies and level-shifting strategies.”
This is a significant improvement for IP suppliers. “The goal is for IP to be defined in a way so that they can be used in any system without having to have the power intent be design specific,” says Arti Dwivedi, senior product specialist at Ansys. “That concept has been significantly developed in 3.0. There are more constructs to define power intent at the system level, and the idea of successive refinement is useful. With the successive refinement approach, a user can bring in the power intent and perform power analysis to see if the consumption meets the power budget. If not, they can identify any blocks that have power but are not in use. These are the types of questions that now can be asked, and designers can refine the power intent to make sure that the design meets the budgets and is power efficient.”
The successive refinement methodology is important. “Power state refinement is a new concept,” says Gabriel Chidolue, verification technologist for Mentor. “Some of the existing constructs were clarified to provide a basis on which to make the model and the refinement steps taken as you from abstracts descriptions to model implementation. More refined means that you may have more detail, more control or signals that can activate a particular state. A good example is at the software level where you might say an IP could be on. As you refine it further, you may have various categories of on, with additional logic and controls to differentiate between the different on-states.”
But not everyone is constructing systems in a top-down flow. “There are two areas that are the most important in the new specification,” says John Decker, solutions architect at Cadence. “The first is the concept of the terminal boundaries so that we can handle bottom-up design flows more efficiently. The second is the system-level power modeling.”
Viswanath expands on the concept of bottom-up design. “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 partitioning of the UPF 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.”
The second important aspect defined by Decker was system-level power modeling. “In the current version of UPF, you have the ability to model power at higher levels of abstraction so that you can do dynamic power analysis,” says Chidolue. “If you had a virtual platform, you can now create models for the IP blocks and add power attributes or functions to them. These can be activated either from software behavior or from the hardware and this provides you with a picture of the total power consumed.”
There are few who would doubt the value of this. “Anything that makes it easier to exchange models of dynamic power is a good thing,” says Drew Wingard, chief technology officer at Sonics. “If UPF 3 removes a barrier to doing analysis, this is good because there has been a lack of interfaces or even an agreed upon ways for doing power models.”
Aspects of this had to be finely crafted. “To extend this analysis to accommodate power, we have to annotate power information onto simulation,” says Viswanath. “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 difficult part is that “the IP power model cannot make any changes to the state of the system.” The two have to remain separated.
A final area of new capabilities is the introduction of an information model. “This is the first time this has existed,” says Ellie Burns, product manager at Mentor. “This information model and the API that goes with it, gives you a clear way to move through and understand the information that is brought in from UPF into your RTL. This is equivalent to VPI for RTL. This will be exciting to users who will now have the ability to build and add tools that can query and move through it. This will become a natural part of the infrastructure of your design.”
Power concerns spreading
While significant progress has been made in building the tools and standards necessary for a low-power design methodology, not all is well within the community. “It is ridiculous that we are more than 10 years into this era of being power limited in design and yet the amount of power reduction that goes on is still very small,” says Wingard. “We hope that 2016 is the year in which these types of techniques start to get applied outside of just the battery powered space.”
Many applications areas just do not seem to that mindful of power, and users are equally to blame. “The State of California (a regulatory body) has realized that users leave most of their devices plugged in and the amount of power being consumed by them is relatively small in terms of a monetary charge for each device,” states Brophy. “The difference between the consumer paying an extra 50 cents a month in electricity and zero is not enough to motivate them to make changes, but to the State of California it means they have to have more electrical generation online to service those types of needs. If they didn’t have to worry about them as much, maybe we could be nicer to the environment.”
Decker adds that “in Europe, there are many emerging power and energy standards that are driving even more mainstream devices to become power aware.” Unfortunately, little of that is happening in the United States.
But change is happening, even if slowly. “Several years ago, we had to convince designers about the importance of RTL power,” says Dwivedi. “Today, everyone cares about it and they want to start early and make sure they meet their power budget. Most of the power methodologies are coming from the mobile and processor groups, but other applications such as radio, storage and even automobiles are seeing increasing levels of interest.”
It is clear that in some segments the power pressure is mounting. “Networking is a traditional wall-powered industry, but people now have to conform to power budgets in data centers,” adds Preeti Gupta, director for RTL product management at Ansys. “Although mobile is still at the forefront and they care about tens of microwatts, wall powered devices are now keenly interested in power.”
So will UPF 3.0 help? “Being aggressive in power management really boils down to the complexity of the power management strategies and policies employed and pushing the boundaries on dynamic and leakage power savings,” says Gibbons. “To some extent the format used to define the power intent is orthogonal to how aggressive designers wish to be in their attempts to minimize power consumption across a wide range of scenarios.”
For anyone attending DVCon—or those in the Bay Area on March 3rd and who want to learn more about the latest version of IEEE 1801—there will be a half day tutorial provided by ARM and Mentor Graphics. More details are available here.