1. Power Management in Embedded Systems
Colin Walls, Mentor
ESC Minneapolis

2. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

3. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

5. Introduction Importance of power steadily growing
Mainly complex battery-powered devices
Demand for connectivity
Power optimization often done late
Needs to be considered from the outset

6. Introduction Choose hardware with right capabilities
Allow software to manage power
Choose OS and drivers
Define power usage profiles
Choose measurable goals
Use goals throughout development process

7. Introduction Choose appropriate hardware Consider usage
Select operating system
Address driver/BSP issues
Application code has least influence on power

8. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

9. Hardware choice Biggest influence on power consumption CPU features
Defines the very best case power saving
CPU features
Turn off blocks; e.g. Peripherals
Dynamic Voltage and Frequency Scaling (DVFS)
Defines operating points
Low power modes
Need to look at wider design to ensure compatibility with above

10. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

11. Use cases Function that a device performs Hypothetical example:
With or without user interaction
Hypothetical example:
Medical device
Battery powered
LCD display
Monitors vital signs
Uploads data via Wi-Fi

12. Use cases for example Device takes a complete measurement
Device uploads a set of measured data
User checks his/her own vitals using a built in display
Device is idle awaiting the next measurement

13. Use cases for example How much functionality needed for each use case?
Hence which drivers [hardware blocks] need to be enabled per use case?
Estimated energy for each use case:
Estimated power consumption
Estimated time in use case
Applying use case expected frequency as scaling factor leads to energy breakdown showing battery charge usage over time period

14. Use cases for example
Use Case
Average Current (mA)
Duration (s)
Frequency per day
Total time (s/day)
ENERGY USED (mAh/day)
Vitals Measurement
158 1
288 13
Data Upload
250 3
864 60
User Vitals Check
320 30 15
450 40
Idle (Hibernate)
84798 24
TOTAL
136
Determine early whether estimated battery life is achievable

15. Use cases for example Data Upload is highest use of energy
Maybe measure and upload every 5 minutes is too costly
Perhaps measure every 5 minutes, but upload every 30 minutes
Also upload if there is a major change in vitals
User Vitals Check is second biggest
Assumes 30 second display timeout
Maybe it could be shorter
Most other hardware shut down in this use case

16. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

17. Operating system Significant impact on power saving
Must support low power features
DVFS
Idle/sleep modes
Native power framework most efficient
BSP must be written to address power issues
Each driver has well defined power states

18. Power framework = Hardware power management = Application Software
= RTOS Power Mgmt Framework

19. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

20. BSP and drivers Define power requirements for each driver. Specify:
Which power states is supports
ON, STANDBY, SLEEP, OFF
What operating points will the driver be used at. For example:
While ON it must work at 200MHz and 100MHz
SLEEP may result in 1MHz clock
DVFS participation
DMA transfer notification

21. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

22. Hibernate/suspend
Some hardware facilitates very low power consumption modes
Suspend: all hardware switched off, except for RAM, the contents of which are protected
Hibernate: RAM contents are stored in non-volatile memory and everything switched off

23. Hibernate/suspend Cost to enter/exit these modes
Power
Time – device responsiveness
Depends on how much of the system is ON when mode is entered
Need to save state and reinitialize
Hibernate also has cost of storing RAM, which varies with the amount of RAM in use
Also potentially reduces system lifetime

24. Hibernate/suspend Does power benefit offset costs?
For example device, depends on:
Measurement interval
How often wake up is required
Adjusting measurement interval might make suspend or hibernate efficient or expensive

25. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

26. Application development
Last layer of software
Badly written code can very adversely affect power performance
An OS with built-in power features [a framework] simplifies matters
Application code writer is then less concerned with details

27. Application development
Application consists of a number of independent tasks/threads
Each task [or group of tasks] registers its power needs:
Which peripherals are used
Minimum operating point
OS takes care of power management along with context switch

28. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

29. Measurement and testing
Power should be measured from day #1
Possible by planning:
Setting power requirements for drivers
Defining use cases
Mapping use cases to applications
All software engineers should be equipped to measure power

30. Measurement and testing
Meeting power requirements should be regarded as part of code functionality
For example:
A Wi-Fi driver may work well with all wireless networks
Must be able to be turned off and reduce power to [near] zero
Must turn back on and be fully functional
Functionality must be repeatable [say, 100,000 times]

31. Measurement and testing
Drivers should have power functionality thoroughly tested:
Properly enable/disable hardware
Participate in DVFS
Inform the OS of DMA requirements

32. Power Consumption at Various OPs
SOC Current Consumption
(mA)
i.MX28 Board
Operating Point voltage
(1.5V)
470
370
230
200
OP#3 454 MHz
OP#2 297 MHz
OP# MHz
OP# MHz 38
Standby
Hibernate
100
300
400
500

33. Impact on Battery Life …
mAh
(Board)
Percentage
Usage per hr
Battery
(hrs)
OP #3
470
10% 47
OP #2
370 5% 19
OP #1
230 23
OP #0
200
15% 30
Standby 38
20% 8
Hibernate
40%
Total
126
mAh
(Board)
Battery
(hrs)
OP #3
470
Total 5
Nucleus Power Management Framework
No Power Management

34. Final optimizations
The approach discussed should yield power performance on spec.
There may be room for more optimization
Do final review of use cases
Possible changes:
Different operating parameters
New use cases

35. Agenda
Introduction Hardware choice Use cases Operating system BSP and drivers Hibernate/suspend Application development Measurement and testing Conclusions

36. Conclusions
Power will continue to be a challenge for embedded developers
No longer a “hardware issue”
Support for new power saving hardware features is essential
With complex software, it is not possible to ignore up-front power planning
Power optimization at the end is impractical

37. colin_walls@mentor.com http://blogs.mentor.com/colinwalls
Thank You!
@ESC_Conf
ESC Minneapolis