Increase The Battery Mileage With Virtual Prototypes

By Achim Nohl
With this post, I would like to continue the topic of my earlier post “Can we stop power-hungry bugs from clawing their way through application software stacks?” In my previous post, I wrote about the difficulties software developers face with writing battery-friendly software. I indicated that virtual prototypes (VPs) can address many of those challenges by providing visibility into the energy consumption of the software under development. Now, I would like to shed some light on how virtual prototypes can accomplish this.

To allow software developers to profile the impact of software changes on energy consumption, the underlying execution target needs to expose the energy consumed by the different components that make up the system—over time and ideally through the perspective of software activity. Therefore, the profiling environment needs to be able to quantify the energy contribution from the different platform components. However, development boards with power measurement probes are only accessible for a handful of software engineers, and are typically made available too late in the design cycle to allow development and testing of the power management software functions. Moreover, they are not available to the community of application software providers whose software has significant influence on a battery’s mileage.

The virtual prototypes that are typically used today by software developers have no notion of power. Their models are purely functional, abstract in their timing behavior and with no link to implementation or silicon process technology. If you claim that VPs can still be very helpful for software developers to get energy under control, it is likely that hardware engineers will view you as a charlatan. From their perspective, gate-level simulation is a minimum requirement to gain a decent impression on the energy footprint of the system. This is somewhat true, but the hardware engineers have a different problem to solve. Software developers do not intend to optimize logic circuits. Instead, they need to make sure they utilize the system power management features in the best possible way. A debuggable, repeatable, deterministic, scenario-driven trend-based analysis of the system’s dynamic power consumption is more relevant for them than the ability to derive the exact energy consumption of the system (uWh). This task is perfectly feasible with a VP.

Here, the characterization of the important power states and events in the system components is the most relevant task. For example, a CPU can switch to the lower power idle state if software synchronization is performed via a semaphore rather than a spin-lock style active wait. The LCD brightness can be reduced if no user interface interaction is required. A position update can be done via 3G or GPS with different power states and durations. Exposing the power states is of great benefit to the software developer, but even energy-trend estimation can be accomplished with coarse-grained, state/event-based characterization from datasheets.

The question is will the incorporation of power data into system simulation simply increase the complexity of the modeling problem? In addition to making sure that we have all of the functional models, do we now also need all of the associated power models? The answer is no. Power and functionality can be orthogonalized. With VPs, power models can be provided as an overlay to the functionality of the VP. Through the introspection capabilities of a VP, functional models can drive power model overlays through observable properties such as signals, registers or other instrumentation. This allows the user to create power models for only the aspects of the system s/he is interested in.

A single VP can be characterized to reflect the energy dynamics for very different system flavors. A functional Ethernet model can be characterized to mimic different hardware vendor parts, and can be even characterized to mimic the dynamic power of a WiFi radio. A WiFi radio may transmit/receive in a low-power or high-power state depending on the data rate requested by the software. Such a coarse grain WiFi power model can be driven by inspecting the data rate of the generic Ethernet model. This is sufficient for many software design decisions and proven by the success of the Power Tutor Android Application. This Android application comes with power models for various handsets (e.g. HTC Dream/Magic), and implements such a WiFi model with surprising accuracy. In this case, the power models are driven by embedded software.

Here lies another big opportunity for VPs. We can use embedded software functions (e.g. driver suspend, resume, send) to realize power models for parts of the system that are not even functionally modeled in the VP. Now we are starting to use VP as an enabling tool for software developers, rather than a pure simulation model of a piece of hardware.

In the future, we expect that temperature will become part of the puzzle for the software developer. Power consumption is highly temperature dependent. Interestingly, this impacts the software developer in the choice of CPU idle management strategy (Run-Fast-Then-Stop or Dynamic-Voltage-Frequency-Scaling).

There is much more to say with regard to this topic, even going beyond the software perspective and how VPs can help to architect power-friendly platforms. Also, there are a lot of imperfect aspects such as standardization of formats etc. However, already today, there is a great chance to get some aspects of the pest under control using virtual prototyping.