Power Management in Embedded Systems

1,369 views

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,369
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
74
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Power Management in Embedded Systems

  1. 1. Power Management in Embedded Systems Colin Walls colin_walls@mentor.com mentor.com/embeddedAndroid 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.
  2. 2. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  3. 3. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  4. 4. IntroductionImportance of power steadily growingMainly complex battery-powered devicesDemand for connectivityPower optimization often done lateNeeds to be considered from the outset
  5. 5. IntroductionChoose hardware with right capabilitiesAllow software to manage powerChoose OS and driversDefine power usage profilesChoose measurable goalsUse goals throughout development process
  6. 6. Introduction • Choose appropriate hardware • Consider usage • Select operating system • Address driver/BSP issues • Application code has least influence on power
  7. 7. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  8. 8. Hardware choiceBiggest influence on power consumption – Defines the very best case power savingCPU features – Turn off blocks; e.g. Peripherals – Dynamic Voltage and Frequency Scaling (DVFS) – Defines operating points – Low power modesNeed to look at wider design to ensure compatibilitywith above
  9. 9. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  10. 10. Use casesFunction that a device performs – With or without user interactionHypothetical example: – Medical device – Battery powered – LCD display – Monitors vital signs – Uploads data via Wi-Fi
  11. 11. Use cases for example1. Device takes a complete measurement2. Device uploads a set of measured data3. User checks his/her own vitals using a built in display4. Device is idle awaiting the next measurement
  12. 12. Use cases for exampleHow 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 caseApplying use case expected frequency as scalingfactor leads to energy breakdown showing batterycharge usage over time period
  13. 13. Use cases for example Use Case Average Current Duration Frequency per Total time ENERGY USED (mA) (s) day (s/day) (mAh/day) Vitals Measurement 158 1 288 288 13 Data Upload 250 3 288 864 60 User Vitals Check 320 30 15 450 40 Idle (Hibernate) 1 84798 24 TOTAL 136 Determine early whether estimated battery life is achievable
  14. 14. Use cases for exampleData Upload is highest use of energyMaybe measure and upload every 5 minutes is toocostlyPerhaps measure every 5 minutes, but upload every30 minutes – Also upload if there is a major change in vitalsUser Vitals Check is second biggest – Assumes 30 second display timeout – Maybe it could be shorter – Most other hardware shut down in this use case
  15. 15. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  16. 16. Operating systemSignificant impact on power savingMust support low power features – DVFS – Idle/sleep modesNative power framework most efficient – BSP must be written to address power issues – Each driver has well defined power states
  17. 17. Power framework = Hardware power management = Application Software = RTOS Power Mgmt Framework
  18. 18. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  19. 19. BSP and driversDefine 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
  20. 20. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  21. 21. Hibernate/suspendSome hardware facilitates very low power consumptionmodes – 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
  22. 22. Hibernate/suspendCost to enter/exit these modes – Power – Time – device responsivenessDepends on how much of the system is ON whenmode is entered – Need to save state and reinitializeHibernate also has cost of storing RAM, which varieswith the amount of RAM in use – Also potentially reduces system lifetime
  23. 23. Hibernate/suspendDoes power benefit offset costs?For example device, depends on: – Measurement interval – How often wake up is requiredAdjusting measurement interval might make suspendor hibernate efficient or expensive
  24. 24. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  25. 25. Application developmentLast layer of softwareBadly written code can very adversely affect powerperformanceAn OS with built-in power features [a framework]simplifies matters – Application code writer is then less concerned with details
  26. 26. Application developmentApplication consists of a number of independenttasks/threadsEach task [or group of tasks] registers its power needs: – Which peripherals are used – Minimum operating pointOS takes care of power management along withcontext switch
  27. 27. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  28. 28. Measurement and testingPower should be measured from day #1Possible by planning: – Setting power requirements for drivers – Defining use cases – Mapping use cases to applicationsAll software engineers should be equipped to measurepower
  29. 29. Measurement and testingMeeting power requirements should be regarded aspart of code functionalityFor 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]
  30. 30. Measurement and testingDrivers should have power functionality thoroughlytested: – Properly enable/disable hardware – Participate in DVFS – Inform the OS of DMA requirements
  31. 31. Power Consumption at VariousOPsOperating Point Hibernate 0 voltage (1.5V) Standby 38 OP#0 1 MHz 200 OP#1 63 MHz 230 OP#2 297 MHz 370 OP#3 454 MHz 470 0 100 200 300 400 500 SOC Current Consumption (mA) i.MX28 Board
  32. 32. Impact on Battery Life … mAh Percentage mAh Battery (Board) Usage per (hrs) hrOP #3 470 10% 47OP #2 370 5% 19OP #1 230 10% 23OP #0 200 15% 30Standby 38 20% 8Hibernate 0 40% 0Total 126 19 mAh Battery (Board) (hrs) Nucleus Power Management Framework OP #3 470 Total 5 No Power Management
  33. 33. Final optimizationsThe approach discussed should yield powerperformance on spec.There may be room for more optimizationDo final review of use casesPossible changes: – Different operating parameters – New use cases
  34. 34. AgendaIntroductionHardware choiceUse casesOperating systemBSP and driversHibernate/suspendApplication developmentMeasurement and testingConclusions
  35. 35. ConclusionsPower will continue to be a challenge for embeddeddevelopers – No longer a “hardware issue”Support for new power saving hardware features isessentialWith complex software, it is not possible to ignore up-front power planning – Power optimization at the end is impractical
  36. 36. Thank you Colin Walls colin_walls@mentor.comhttp://blogs.mentor.com/colinwalls 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.

×