1. Power Modeling and Power Management Framework Dexin Li December 2002

2. Outline Background Power management architecture Component-level power modeling System-level power simulation Energy optimization Preliminary results

3. Background Challenges on power management in complex embedded systems –Interaction and cooperation among multiple components –Existence of inter-component dependencies –Complicated local mode transitions for a global mode change –High cost for a global mode change Scope of the work –Purpose a software architecture dealing with power management complexity –Model components and component modes with dependency –Generate feasible sequence of mode transitions –Optimize the energy for the cost of mode changes

4. Power Management Architecture Separation of policy-maker and component details –Modular, retargetable, –Lessen the burden of policy-maker Hierarchical component model –Capable of handling complex systems Modeling of inter-component dependency –Enabling complicated mode transition optimization Online or offline power simulation –Helpful in obtaining feasible mode transitions and optimizing system energy

5. Execution Model of Power Management Hardware device Operating System Middle-ware Application Power manager We assume this model in the rest of the presentation.

6. Top-Level Power Manager Power Manager Requirements Device status OS/MW status System spec Component library Power simulator External policy App. status Interdependency Task constraint Power/battery status Control command app os hw Message to app. Message to os

7. Decoupled Power Management Architecture Diagram

8. Policy Handler Responsibilities –monitor system status –Make system-level power management policies –Send mode change commands System interaction –Accept service requests from applications –Accept system requirement or environment input from middle-ware –Obtain system status from middle-ware or OS –Send mode change commands to Component Manager

9. Component Manager Command Interpreter –Receive system command from policy handler –Translate system command into local command Core algorithms –Generate sequence of mode transitions –Optimize it for energy reduction –Send results to device drivers –Feed results to simulation engine

10. Component Manager Diagram MTG 1 MTG 2 MTG n Mode Dependency Model Device status System status Command Interpreter Core Algorithms Policy Handler Device driver Component Manager

11. Component Modeling Example: Power Amplifier Device status System status Command Interpreter All-pair-shortest-path Algo. (Floyd-Warshall) Component manager for PA offsb tx rx f1: fsm_lb offsb tx rx f2: fsm_hb offon f3: temp_lb offon f4: temp_hb F1.sb->f2.off F1.tx->f2.off F1.rx->f2.off F2.sb->f1.off F2.tx->f1.off F2.rx->f1.off F1.sb->f3.on F1.tx->f3.on F1.rx->f3.on F2.sb->f4.on F2.tx->f4.on F2.rx->f4.on Dependency model

12. Component Manager Example: Power Amplifier offsb tx rx f1: fsm_lb offsb tx rx f2: fsm_hb Current state: low band transmit System command: change to high band receive State transition sequence: f1.tx -> f1.sb -> f1.off f2.off -> f2.sb -> f2.rx f4.off -> f4.on offon f4: temp_hb Optimized for energy reduction: f1.tx -> f1.sb -> f1.off f4.off -> f4.on f2.off -> f2.sb -> f2.rx Energy: 3.88J Energy: 1.88J

13. System-level Mode Simulation Responsibility –Receive sequence of mode transitions –Simulate mode transitions –Parallelize possible mode transitions –Obtain time and energy information –Send the information back to Policy Handler Requirement –Detailed timing information for synchronization –Hierarchical component management –Parallelism among different components –Interface to other power management units

14. Simulation Engine Diagram

15. Energy Optimization Objective –Optimize energy consumption for mode changes Techniques –Shortest-path algorithm to optimize for one mode change on one component –Topological sorting to power up high power component as late as possible –Mode simulation to parallelize certain mode changes

16. Modeling a JTRS Channel Complex system composition –13 power manageable components –Multiple power modes on each component Complicated inter-component dependencies –derived from system specification and application requirements Complicated mode changes –Involve more than one component for a mode change –Take a period of time comparable to the service time

17. Experimental Results Test cases: –Case 1: all power-up –Case 2: two modes: on and off –Case 3: 5 system modes without our model –Case 4: 5 system modes with our modes Results: –Saves 50%-80% energy when service time is comparable to overhead time –Saves 20%+ energy when service time is 1000x larger than overhead time

18. Conclusion A new software architecture supporting efficient power management in complex systems Component power model enabling power management in complex systems with dependency Multiple optimization techniques reducing energy cost for global mode changes System-level simulation providing optimized component-level details to global policy-maker

19. End Slide

20. Execution Model of the Power Manager Not clear what execution model is best/feasible/practical … Hardware device Operating System Middle-ware Application Power manager

21. Device Broker MTG 1 MTG 2 MTG n Mode Dependency Model Device status System status Command receiver/ interpreter Broker core System power manager Device driver

22. Mode Transition Graph offstb tx rx

23. Execution Model of the Power Manager Not clear what execution model is best/feasible/practical... Hardware device Operating System Middle-ware Application Power manager

24. Execution Model of the Power Manager Not clear what execution model is best/feasible/practical … Hardware device Operating System Middle-ware Application Power manager

25. Execution Model of the Power Manager Not clear what execution model is best/feasible/practical … Hardware device Operating System Middle-ware Application Power manager

26. More Detailed Power Manager Composition Power Manager (core) Component library Simulation Engine Sys. specification App. Requirements App/task Constraints Power management policy Device driver Device model Device broker I Device status Device driver Device model Device broker II Device status Sys/app status