I’ve been tempted to upgrade to a Smartphone like the iPhone 3GS or Droid because of the rich set of features and I want to appear hip.
Doing some research on each of these phones reveals a common weakness – short battery life. The Droid or iPhone battery can last a mere 4 hours with just a few emails, phone calls and minutes of web surfing.
Being a real enthusiast for efficiency I’ve decided to pass on getting one of these phones for right now however the question remains – why is the battery life so short?
It could be just a case of the marketing department adding too many features that all consume power:
- Huge screens
- WiFi
- Navigation
- Music
- Video
- Web browsing
- Bluetooth
Some people think that the power issue will be resolved with the next release of the operating system, so that it auto detects how you are using the Smartphone and aggressively manages power to keep the device running for the maximum time.
I’m wondering if these phone companies did any high-level simulations of power consumption?
Are there EDA simulators that would predict power consumption on a complete consumer electronic device like the Droid or iPhone?
Did the marketing departments ignore the battery life issue?
How will engineering produce a longer living Smartphone?
EDA could add some real value here in helping the system-level designers of Smartphones to get extended life out of a single battery charge.
Even the foundries could add some value by offering a process with lower leakage currents, and lower switching power.
Daniel,
Since smartphones are really handheld portable computers, it should come as no surprise that the major consumer of battery charge is the same as in laptops: the display, or more specifically – the LCD backlight. You see the same thing now in netbooks; 3-cell equipped netbooks are good for 3-4 hours, while 6-cell netbooks double that.
I used to carry a spare battery for my laptop, and I wish that the iPhone had a replaceable battery as well (go DROID!).
I think that all iPhone users learn to apply their own power management protocol. For me the goal is not to make it through 24 hours, it’s to make it through a whole day of a conference or trade show (8 – 10 hours). By following these procedures, I can usually get there:
1) Dim the display as low as possible to be usable.
2) Turn off unused radios: GPS, Bluetooth, WiFi if you have a 3G connection or vice-versa.
3) Avoid using the camera.
This way, I can generally use Twitter and access email enough to get through the day with my iPhone.
Mike,
Thanks for the power-saving tips.
I agree with your points however I’m still trying to understand if the system-level designers at Apple and Motorola knew how short-lived their Smartphones were going to be in actual use?
If they did know how brief the battery life was, then did marketing push to get out to market in spite of the consumer backlash?
Not to toot our own horn, but Mentor does, indeed, have tools that will predict power consumption from a SystemC TLM view of the design.
Power is the next frontier of simulation.
Ray, Thanks for the update. Can you share any customer data for a consumer electronic device like a Smartphone where simulation predicted battery life compared to the real hardware, software and OS?
I read about Emulex however they design products powered by AC not batteries.
Hi Daniel,
with complex software stacks like the Linux based Android SW platform it requires a lot of discipline on the software side to get power under control. We frequently read about power analysis and optimization on the platform and block architecture level, however it feels like the software developer is more or less left alone. But, the software developer has huge impact on the real system level power consumption. However, even this is often interpreted in a very hardware centric way. Thus, when people hear about software and power they tend to immediately relate that to software implementation-level optimizations, memory/bus access power penalties etc. While this is for sure an important aspect, much more important is the overall system energy management from a software perspective. Here, the software developer needs to make sure that power management is vertically integrated across the different layers of the software stack. Next to that, software modules need to cooperate on power. With Android and background applications a simple background application that wakes up your phone every 10 minutes for 8 seconds reduces the standby time by 50% while the phone would be idle otherwise. But, modem, GPS, LCD backlight, sensors contribute in a significant way to the overall power consumption that allow you to almost neglect the power of the CPU on its own. However, this is heavily dependent on usage scenarios. There is a nice presentation from Google on youtube called “coding for life” talking about this.
The software developer needs to be made aware of the system level power consumption. Just understanding what is going on is a fair challenge in the software today. You have Java, Native Layer, Hardware adaptation layers, OS and drivers etc. who all are involved in power management. Thus, the software developer should be aware of why, when, which component in his system is at what power state and also what that means for the battery. E.g. we found out that the tickless kernel feature in Linux has almlost no impact on power-saving for an Android phone because the kernel is woken up every second by the battery dis-charging animation. And, we found out that you can ignore that and do not need to worry because the LCD even in dim-mode is consuming much more power than the CPU in this scenario. A couple of seconds later the phone will suspend anyway so optimization effort should be spend elsewhere. There are hundreds of scenarios such as walking-navigation. How often do you need the GPS for an update while walking vs. driving etc.?
We are working on making Virtual Platforms a development target for power optimizations by providing the ability to analyze power over time, component and software activity. Virtual platform are nicely suited for that since they can be easily stimulated to create scenarios (e.g. GPS, phone call etc.), they are deterministic for analysis comparisons and they can be easily instrumented with power states for the different blocks.
Achim,
Thank you for all the insight, I learned something today about how complex and interrelated power consumption is on the Smartphone. It’s really a holistic issue. CoWare seems to really understand how to help address this.