Power? It’s The Apps, Stupid!

Shabtay Matalon
When I bought my first iPhone, I envisioned using it mostly to make phone calls and occasionally to view e-mails and browse the Web. For navigation, I used a separate GPS. But all this changed when I realized that I can use the Waze App on my iPhone for real-time navigation or to play games while listening to music on a boring coast-to-coast domestic flight. These new “apps” impacted the battery life of my phone, and 21st century concerns became part of my life: Will the battery keep my phone alive after landing? Why is my iPhone so warm after using Waze for 45 minutes?

Those of us who grew up on the hardware design side are used to thinking about power at the transistor level. When it comes to CMOS technology, static power mainly occurs due to leakage when transistors are off or because of current tunneling through the gate oxide. Dynamic power is dissipated when transistors are switching. A common formula to compute dynamic power is P= CV2Fα, where C is load capacitance, V is voltage, F the clock frequency, and α is an average activity factor, as all the transistors don’t switch every clock cycle. So what do these “low-level attributes” have to do with the apps running on my device?

Figure 1: The power design layer

With design complexity and gate count increasing, modern battery-operated designs no longer can afford to keep design blocks in full active states, consuming peak-level power. So designs are partitioned into power domains, where the hardware blocks are individually controlled by a central power controller. Techniques such as power shutdown completely turn off the power to specific blocks when they are not active. Techniques like DVFS (Dynamic Voltage and Frequency Scaling) allow reducing the frequency and voltage to particular design blocks when they are not required to operate at peak performance. And clock-gating techniques reduce toggle activity. All these hardware techniques directly “play” with and attempt to reduce the voltage, frequency, and average activity factor in the power equation.

The power controller plays a major role in applying the power reduction techniques to key hardware design blocks in each power domain. However, none of these power savings can be realized without the software “smarts” to know when these techniques can be applied based on the application running on the device. Is the user watching a video on the tablet? Is the iPhone set in Airplane mode? Or is the device polling for e-mails? What is the user priority when operating a GPS and listening to music? Will an accident alert mute the music the car driver is listening to?

Without the power/battery conservation provisions that modern embedded devices provide, only very limited power savings can be realized. But without the “smarts” in the software, devices operating at their nominal activity level will consume peak power. Power-aware operating systems (such as Nucleus) provide a power management framework that coordinates between the application software and the drivers of hardware blocks underneath.

Designing battery-operated devices nowadays requires complete control and optimization of all software and hardware power design layers, guided by an understanding of the expected impact of the applications on those underlying layers. This needs to be done as early as possible, during the design stage when hardware and software changes can be applied.

This level of understanding and optimization cannot be realized without using a virtual prototype that a) allows running the entire software stack, b) models the key power control facilities, c) models the power of each design block and d) runs fast enough to evaluate the impact of applications on the power.

Vista Virtual Prototyping from Mentor Graphics provides a prototyping platform that models all key power optimization techniques and runs the entire power aware software stack under application control. You can view the interplay between the software at all levels and the power consumption of the hardware at any design operation point and at any software state.

In Figure 2, you can see a combined HW/SW Analysis view provided by Vista Virtual Prototyping using the Mentor Embedded Sourcery Analyzer tool. It shows the power consumed by a virtual prototype along with the state of the software on the same timeline. You can view the state of the CPU, which interrupts occurred, which user software functions executed, and how these impacted the power of the design. Of course, finer granularity of the power values by power domains and by major blocks in the design can be presented—information that is very hard to measure on a real embedded device.

Figure 2: Combined power and SW analysis view.

In summary, virtual prototyping that supports combined power and software analysis on the same timeline allows you to optimize the software to reduce power and helps you understand the impact of apps on the power and battery life of embedded devices. After all, it’s the apps, stupid!

— Shabtay Matalon is ESL Market Development Manager for Mentor Graphics’ Design Creation Business Unit.