UPF group moves to consider system-power issues

The working group that developed the IEEE 1801 Unified Power Format standard is looking to bringing power modeling and estimation to the system level, with plans to develop a standard for the 2015 “UPF 3.0” release that will build on work performed to tighten up the specification that culminated in last week’s release of the 2013 version.

Erich Marschner, verification architect at Mentor Graphics, said at a public Accellera meeting at the Design Automation Conference (DAC) in Austin, Texas on Monday: “A lot of the changes we made [for IEEE 1801-2013] seem to be small changes but they all integrate to improve the standard in a number of areas. They provide fine-grained control for users to define what their power strategy is and improve the fidelity of modeling.

“One of the not so small changes has been in the modeling of retention registers which can be very detailed in their behavior. The third things we focused on was the incremental nature of design, verification and implementation. So there are unifying principles that organize the many small changes we have made.”

The 2013 version of the standard attempts to make the description of power intent easier for mainstream engineers to adopt. John Biggs, consultant engineer and cofounder of ARM, said: “Power is now a primary design constraint for everyone.”

Qi Wang, solutions group director at Cadence Design Systems, said: “One big trend that we see is more and more small companies are doing low-power design. Previously it was the larger companies doing those complex design. But the smaller companies dont have the large CAD resources to tap into that bigger organizations possess. The key is getting the methodology right. So with the latest, 2013 version we have an appendix that talks about low-power design methodologies.”

Heading up the flow

The next step for the working group is, having clarified the job of power intent expression, modeling and verification at the RTL level, to do more at the system level.

Marschner said: “We need to move power aspects of design earlier in the flow, making sure that you are making the right decisions for power control and partitioning. Today we have moved as far as RTL. Tomorrow we want to move it up to the system level.”

Sushma Honnavara-Prasad, senior staff engineer at Broadcom, said: “We want to do more early hardware-software co-emulation. We need to take into account how software affects power. Because power management is so intrusive it affects every part of the design. Everyone needs to take account of the power-management strategy.

Honnavara-Prasad said the complexity of the leading-edge designs, such as those developed for mobile, is increasing fast, which will push more of the low-power design effort to the system level.

“We are seeing an explosion in the number of power states. We are 20, 30 if not hundreds of states in a single SoC,” Honnavara-Prasad claimed. “It’s not just the number of power domains but the granularity of control of those power domains. In the future there will be much more software control. So power control has to be understood at a very high level. It’s a big challenge for verification.”

Biggs said: “The biggest thing we wrestle with is system-level power modeling. How can we model power at the system level so that the user can analyze design tradeoffs? People aren’t doing it earlier in the design flow because they don’t have the tools to do it. New standards may make it easier to move power further up the design flow.

Modeling thermal limits

“A new challenge will be thermal modeling,” Biggs added, as excessive usage will result in hotspots that could lead to an SoC overheating and being forced to shut down. “To analyze that, you will need to understand the history as well as the current power state. How long were you in the previous power mode?”

Honnavara-Prasad said: “At the software level we have to capture behavior such as context switching and load balancing. You can’t really do that with a static view of the design.

“Historically, the system-level modeling was done through Excel spreadsheets. You list all the different contributors to power and apply some heuristic factor to compute power numbers. You then pass that information to the software team so they can figure out how they can manage the different blocks,” Honnavara-Prasad explained. “To avoid situations such as thermal events: that’s really a dynamic problem and it will involve hardware-software co-simulation and emulation.

Is it SAIF?

Synopsys application engineer Jeffrey Lee said: “We are going to sit down for 3.0 and work out how we can put the requirements together so that people doing early work on system power can do it in a common language.”

One possible extension will be to the SAIF power-modeling file format to try to reflect the low-level power behavior of activities in different power states, such as switching power under changing supply voltages.

“Any kind of estimation we do has to be tied to accurate data from physical components,” said Marschner. “It may involve reading libraries to populate models, but it is too early to tell what this work will lead to.”