power management in embedded systems
DESCRIPTION
Power Management in Embedded Systems – Colin Walls The importance of power management in today’s embedded designs has been steadily growing as an increasing number of battery powered devices are developed. Often power optimizations are left to the very end of the project cycle, almost as an afterthought. In this presentation we will discuss design considerations that should be made when starting a new power sensitive embedded design, which include choosing the hardware with desired capabilities, defining a hardware architecture that will allow software to dynamically control power consumption, defining appropriate power usage profiles, making the appropriate choice of an operating system and drivers, choosing measurable power goals and providing these goals to the software development team to track throughout the development process.TRANSCRIPT
mentor.com/embedded
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Colin Walls
Power Management in Embedded
Systems
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
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
Introduction
• Choose appropriate hardware
• Consider usage
• Select operating system
• Address driver/BSP issues
• Application code has least influence on power
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Hardware choice
Biggest influence on power consumption– 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
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
Use cases
Function that a device performs– With or without user interaction
Hypothetical example:– Medical device
– Battery powered
– LCD display
– Monitors vital signs
– Uploads data via Wi-Fi
Use cases for example
1. Device takes a complete measurement
2. Device uploads a set of measured data
3. User checks his/her own vitals using a built in display
4. Device is idle awaiting the next measurement
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
Use cases for example
Determine early whether estimated battery life is achievable
Use Case Average Current (mA)
Duration (s)
Frequency per day
Total time (s/day)
ENERGY USED (mAh/day)
Vitals Measurement 158 1 288 288 13Data Upload 250 3 288 864 60User Vitals Check 320 30 15 450 40Idle (Hibernate) 1 84798 24TOTAL 136
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
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
Power framework
= Hardware power management
= RTOS Power Mgmt Framework
= Application Software
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
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
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
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
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
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
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]
Measurement and testing
Drivers should have power functionality thoroughly tested:
– Properly enable/disable hardware
– Participate in DVFS
– Inform the OS of DMA requirements
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#1 63 MHz
OP#0 1 MHz
38Standby
0Hibernate
0 100 200 300 400 500
Impact on Battery Life …
mAh(Board)
PercentageUsage per
hr
mAh Battery (hrs)
OP #3 470 10% 47
OP #2 370 5% 19
OP #1 230 10% 23
OP #0 200 15% 30
Standby 38 20% 8
Hibernate 0 40% 0
Total 126 19
Nucleus Power Management Framework
mAh(Board)
Battery (hrs)
OP #3 470
Total 5
No Power Management
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
Agenda
Introduction
Hardware choice
Use cases
Operating system
BSP and drivers
Hibernate/suspend
Application development
Measurement and testing
Conclusions
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
mentor.com/embedded
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Colin Walls
http://blogs.mentor.com/colinwalls
Thank you