iPhone Has The Power Blues

Why do some apps on the iPhone seem to draw more on the battery than others?

Is it a matter of power-aware software applications, or is it a hardware issue? Maybe it is a combination of both. I suspect it is due to the intricacies of hardware/software design and verification.

I’ve been mulling this over while researching my two articles for this month’s issue of Low-Power Engineering: “Defining Power Intent,” and “Can IP be Standardized in Low-Power Designs?”

I have gathered that it is related to the power intent, but is much more complicated than that. Cary Chin and Josefina Hobbs from Synopsys touch on the issue in my power intent article – basically, software developers creating apps for the iPhone, for instance, don’t have access to the myriad ways that their software might be used. How could they, really? But, they assert, they should be thinking about ‘activity’ of hardware as it helps with determining the power intent. This already takes place in software, and in the future will need to be connected down to the hardware as well.

In addition to thinking about hardware activity above the RT level, I am hearing that engineers are tracking power consumption to figure out why power consumption rises, or when they don’t believe they are meeting their specs. Power debug tools are being used to understand whether the design contains the right sequence of events in drawing power domains, level shifters and so on, explained Will Ruby from Apache.

“The power consumption debug says, ‘OK, I am wasting power in my design primarily due to unnecessary activity.’ A lot of times these things are not functional failures so they are not caught by functional simulators. You have to understand what are the different types of conditions that are creating these power bugs and then use power analysis technology to understand what is the ramification, what is the cost of these power bugs. You may say, ‘Here is a wasted power condition but it’s wasting a whopping nanowatt of power.’ Maybe for a pacemaker design it is really important to fix it, but maybe for other devices it’s not as important. But if I look at this other power bug and it’s wasting 300 milliwatts of power, if I’m doing a mobile processor, I’d better care about something like that.”

Interestingly, these bugs are not being caught by traditional verification tools because they are not functional failures. “You can orient a verification tool to be able to catch conditions like this, but the traditional verification tools without power analysis built in don’t give you the cost. The question is if power bugs are not hard functional failures, should I go and spend my time and fix those? Unless you have the cost associated with it, in terms of how much power is being wasted, you don’t know. And this all depends on the application,” Ruby noted.

While this is a challenge for designers today, Cadence’s Qi Wang asserted that the foremost challenge with regard to power intent is to preserve it. “One way to address this is to take a layered approach whereby one layer is ‘golden’ and it gets the highest priority; the next layer is the implementation guidance. I can say I want to turn off ‘this region’ including ‘this’ logic module – that is my primary power intent. However, how do I implement this region? That is in the implementation details and can be added later on or can be modified by the implementation tools. A third layer contains constraints for timing and power, which are used to drive optimization and can be set later on. For the functionality, there is a layer for low power functionality power intent – that one we want to keep it from RTL to netlist to the P&R.”

Power issues are painful for everyone now. It is a no-brainer for consumer electronics applications because it is all battery powered. But even for the datacenter, where everything is connected to a wall plug, power is still a concern because of the high price of energy combined with environmental concerns.

–Ann Steffora Mutschler