I’ll never forget the shock when I upgraded from a Feature Phone to my first Android-powered SmartPhone, because all of a sudden my battery life went from 6 days down to only 1 day between charges. As a consumer, I really want my battery to last much longer than one day, so the race is on for mobile phone companies to design their devices with the maximum possible battery life. The combination of operating system, power management policies and hardware are what determine the battery life in a modern, Android-based device. On the EDA side there are companies like DOCEA Power that focus on modeling power at the Electronic System Level (ESL), before RTL coding has even started.
ESL power modeling and simulation addresses the key factors in the evaluation of power management policies, as you can develop, update and maintain power models from the IP block level to the complete system inclusive of the process technology-dependent factors.
With the DOCEA Power approach, you can build power models bottom up and model power states and power events from the application and software from the top down. You can automate the power model generation, clock and voltage connections and parametrize the models to also include PVT and implementation level details necessary for accurate power analysis. Models can be refined with characterization data as the design matures to track the power and performance targets.
Power models which contain system power, thermal and performance states for computational elements (PU’s or processing elements), interconnect, both active and idle power states with dynamic power calculations to account for task load, task consumption and idle power including temperature dependent leakage as well as clock and power gated idle power reduction techniques.
DOCEA power provides the ability to model power as a function of power state residency, system activity, and power state event transitions from realistic workloads and applications.
Power Management Policies
Let’s take an overview of power management policies typically found on Android devices.
Performance Governor
This locks the phone’s CPU at maximum frequency, producing impressive benchmark results and providing a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state.
Related – ESL Tool Update from #51DAC
Conservative Governor
This controls the phone to prefer the lowest possible clock speed as often as possible. The conservative governor can introduce choppy performance, however it can be good for battery life.
OnDemand Governor
This governor has a hair trigger for boosting clock speed to the maximum speed set by the user. If the CPU load placed by the user slows, the OnDemand governor will slowly step back down through the kernel’s frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
Userspace Governor
This governor allows any program executed by the user to set the CPU’s operating frequency, something more common for servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clock speed.
Powersave Governor
The opposite of the Performance governor is the Powersave governor, and it locks the CPU frequency at the lowest frequency set by the user.
Related – Power Modeling and Simulation of System Memory Subsystem
Interactive Governor
Similar to the OnDemand governor, the Interactive governor dynamically scales CPU clock speed in response to the workload placed on the CPU by a user. Interactive is significantly more responsive than OnDemand, because it’s faster at scaling to maximum frequency. Interactive is the default governor of choice for today’s smartphone and tablet manufacturers.
Android battery life using Interactive Governor
InteractiveX Governor
Created by kernel developer “Imoseyon,” the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor’s defining feature, however, is that it locks the CPU frequency to the user’s lowest defined speed when the screen is off.
Hotplug Governor
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel’s frequency table as the governor measures the user’s CPU load. However, the Hotplug governor’s defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as “hotplugging.”
Related – Power and Thermal Analysis of Data Center and Server ICs
All of these power management policies can be quite complex and the policies which might provide added battery life may have significant tradeoffs in terms of design and validation complexity as well as functionality and performance. Evaluation of power management policies and algorithms should take into account the hardware interaction with the application and software behavior:
Traditional power management which improves battery life benchmarks may assume that the system is idle 70-90% of the time so a “race to halt” and optimizations for idle power reduction are key. Applications which require high quality of service such as media playback, communications and isochronous support require policies that use low latency and sustained performance.
Summary
Android devices may use many different power management policies, and we only covered a handful of possible policies in this blog. My follow-on blog will describe the methodology proposed by DOCEA Power to model, simulate and optimize power prior to RTL coding.
Next Generation of Systems Design at Siemens