• Print
• |
• Email
• |
• Reprints
• |
• RSS
• |
• 

Page 1 of 3

Battery life has become the Achilles heel for the success of mobile software platforms, such as Android. The mileage users can get from their battery is severely impacted by software. Software implicitly and explicitly defines the power states of major system components when the phone is used and even when it is not used.

Just the LCD can consume as much power as the CPU in a mobile phone. A software power inefficiency or malfunction can quickly cause a drop of 5x in terms of standby time. Evidence for this is available in the user forums of all the major phone vendors where people have updated their phone with new firmware or applications.

Although power efficiency is a major quality and sign-off criteria for hardware platforms, it is still a poor cousin in the quality checklist for software. There are multiple reasons for this.

The software community still considers power as something that is taken care of by either hardware or the software layer they are building the functions on. Application developers trust that the application framework will make sure that while using services the underlying resources are used in a battery-friendly manner.

But the reality is that a simple RSS feed application that wakes up the phone every 10 minutes for just eight seconds to do some updates via the internet can cut the standby time of a phone in half. Software platforms for mobile applications must be engineered in such a way that smart heuristics make sure only those services required in the active usage scenario are provided. Components must be turned off when not in use.

When porting such platforms, the power control capabilities of the OS and their drivers must be made available to the application framework. During OS development and porting, software engineers have to make sure that all power saving features of the underlying hardware are leveraged and supported by drivers.

With dynamic frequency and voltage scaling of the CPU this can reach deep into the internals of the OS kernel, since it is impacting scheduling through work-load prediction.

Finally, in order to guarantee an efficient use of the battery, all highly distributed software entities for power saving and management have to be vertically integrated and need to cooperate.

Obviously, a minor malfunction or inefficiency in just one software module can trigger a cascade that severely reduces battery mileage. It is also obvious that debugging those cause-effect chains can become a nightmare.

Debugging is extremely problematic since the cause-effect search space is not limited to one software layer. While software looks fine from a functionality and performance standpoint, it could well be that the battery drains four times faster.

Imagine a scenario where the phone is locked and it is located in the pocket of a user who is hiking. After the hike the battery is empty because the accelerometer was not shutdown and constantly woke the phone up when it would have been idle otherwise.

This example shows another challenge for power profiling and debugging. In contrast to software for a desktop PC, the usage scenario plays an important role, as it defines how the phone interacts with the environment. How can you debug your phone however, while it is locked in your pocket? How can you make sure that scenarios are deterministic to compare different implementation options?

Debugging power defects moreover comes with another major issue. In a low power mode, such as suspend, the embedded debug service is likely to be suspended as well. In addition to that, any debug interaction with the device is intrusive and severely tampers the power figures in itself.

A debug daemon would not let the phone go to suspend, require USB/UART/Ethernet drivers, fire additional interrupts, increase the CPU load, change workload prediction and the frequency and voltage control. Furthermore, expensive lab equipment is required to perform a sufficiently fine granular power profiling to determine which of the components is the most critical.

On top of all the technical challenges, software centric power profiling and debugging is an educational challenge. Software engineers may not be able to interpret what it means if 250mW are saved for a specific component configuration. Here, it becomes much more important to provide qualitative results, such as the stand-by time has dropped by 50 percent because the component is used 90 percent of the time in the profiling window.

Virtual Prototype Based Software Centric Power Analysis and Debug

Virtual Prototype (VP) based solutions enable software centric power analysis and debug to address the previously detailed challenges of:

• Deterministic repetition of real-world scenarios on the developer’s desktop

• Non-intrusive debugging during suspend and low-power modes

• Understanding system level hardware and software behavior and interaction

• Power measurement, debugging and root cause analysis

A VP is a software emulation of an entire system, such as a Smartphone ash shown in Figure 1 below. VPs can be made available early in the development stage of an electronic system, even before hardware is available. A VP is able to run the exact same binary software that the hardware system would execute.

However, execution is performed on simulation models of all the system components, including the application processor, the memories, DMAs, timers interrupt controllers etc. Those models can be instrumented with information that characterize power.

The execution is controlled via scenario scripts that drive the I/O of the VP, and include generating user-input via the touchscreen controller, setting GPS coordinates through the UART or initiating a phone call. Software optimization is made possible by collecting power analysis data along with running other hardware and software traces during simulation, in order to enable root-cause analysis and debugging.

Figure 1 -Virtual Prototype Framework

Page 2: Software Debugging
Page 3: Power Debugging

Page 1 2 3