High-level System Modeling and Power Management Techniques

1. High-level System Modeling and Power Management Techniques Jinfeng Liu Dept. of ECE, UC Irvine Sep. 2000

2. Background • X2000 Avionics System Architecture • COTS – based building blocks for system integration • Low cost component with strong commercial support • Widely accepted specification, design, application and testing • Reduced development cost • Dual system bus architecture • IEEE 1394 bus • Hi performance on fast data rate • Moderate power • Reconfigurable structure • I2C bus • Low power • Adequate data rate for low-speed communication

3. Power Aware vs. Low Power • Low power design – as low as possible • Minimize power consumption at circuit/gate level • No system-level and application specific knowledge • Limited reconfiguration space to meet multiple mission requirement • Power aware computation – use power wisely • Power model built on application-specific knowledge • Reconfigurable system architecture to meet multiple mission requirement • Adaptive adjustment to run-time power supply • Optimize power usage on system level • Manage all power consumers – electronics, mechanics, thermal • Regulate power surge to protect battery • Shorten execution time to save energy

4. Examples – Mars Rover • Power supply • Non-rechargeable battery and solar panel • Power consumption • Electronics – computation, imaging, communication, control • Mechanic – driving, steering • Thermal – motors must be heated in low-temperature environment • Power management • Low-power electronics cannot make significant power saving • No system-level management tool available • Manual schedule must remain conservative • Serialize all operations to suppress power surge • Long execution time • Solar power not efficiently used

5. Our Approach • High-level system modeling techniques • Describe the system in high-level abstractions • Employ application specific knowledge in system models • Apply power aware management techniques on different power consumers – electronics, mechanics, thermal • System modeling • Behavioral modeling – software architecture, application specific knowledge • Architectural modeling – hardware platform built on top of parameterized components • Partitioning – mapping behavioral objects to architectural structures • Scheduling – a valid sequence of concurrent/parallel operations on multiple processors that satisfies real-time requirement

6. Our Approach • Power management and optimization • Behavioral modeling • Extract power related attributes of all objects • Architecture modeling • Use low-power devices or devices that can operate on low-power mode • Partitioning • Migration – merge computations on under-utilized processors on one processor to improve utilization • Segmentation – separate tightly coupled computations into clusters to localize communication • Scheduling • Arrange operation sequences on multi-processor / multiple power consumer to meet both performance and power requirement

7. Behavioral Model • Application specific knowledge • Input, output and function • Dependency and precedence • Control and data flow • Timing and sequence • Software architecture • Operating system features – real-time, centralized, distributed, and etc. • Execution model – event driven, interrupt, distributed agent, client-server, and etc. • Communication model – protocol stack and specification • Power related attributes • Data rate, execution time, CPU speed, memory size, communication path, and etc.

8. Architectural Model • Component – parameterized COTS • Type – processor, memory, I/O, DSP, bus, and etc. • Interface – how the components can be connected to each other • Modes – operation modes parameters, voltage, clock speed, bandwidth, power consumption, and etc. • Package – a bundle of connected components that performs certain operation • Components – a set of connected components • Internal/external interface – how components are connected • Modes – configuration space of the collected components specified by each component’s working mode and collective attributes, e.g., voltage, speed, power and etc.

9. Partitioning • Mapping – map behavioral objects to hardware • Group related OS, communication, control and application objects into processing nodes • Extract data objects into storage nodes • Allocate components/packages for each processing node • Arrange data storage for data nodes and optimize storage location to reduce communication • Establish communication paths among nodes that comply with the communication model • Setup working mode of each component/package to fit the behavioral requirement • Extract attribute of each structure • Function – computation, control, communication • CPU utilization • Bus traffic • Power consumption

10. Partitioning • Migration – combine multiple nodes to one node to improve utilization • Examine the utilization of each node • Migrate computation on under-utilized processing nodes and merge corresponding storage nodes if necessary • Balance power consumption and CPU utilization • Segmentation – arrange nodes in tight communication in a bus segmentation • Group nodes by communication localities • Settle each group in a bus segment (a feature of IEEE 1394) • Extract attributes of localized communication mode in a segmented bus • Improved performance • Reduced bus traffic • Reduced power consumption

11. Scheduling – Techniques • Deadline based real-time scheduling on multiprocessors • Rate-monotonic scheduling – extend existing RM scheduling to multiprocessors • Timing constraint graph scheduling – multiple serializable sequences in a single heart beat

12. Scheduling – Techniques • Constraint logic solving • Transfer all constraints into a pure mathematical form • Use tools to solve the problem in mathematical domain • Example – CLPR • Constraints • C1 > 3, C1 < 5, C2 > 2, C2 < 4 # two power consumers • C1 + C2 < S, S > 6, S < 12 # one power source • Inputs • C1 = 4.5, S = 7 • Results • C2 < 2.5 • 2 < C2

13. Scheduling – Objectives • Our power-aware scheduling tool • A novel graphical tool that visualizes timing and power constraint and transforms them into graph problems • Manage all power sources and power consumers in system-level • Power-aware scheduling – schedule operations based on power source output • Automated schedule to meet both performance requirement and power constraint • Regulate power surge • Use power efficiently to reduce execution time • Management and optimization tool to give designers a vision to the power surge at run-time

14. Power Power level Energy consumption Time Starting time Ending time Scheduling Tool • Extended Gantt-chart in real-time scheduling for single processor • Event – bins • Timing – horizontal size • Power – vertical size • Energy – area of the bin • Power surge – compacting bins downward

15. Power Task D follows B D D D Periodic task C C C C C C B B B B Periodic task B Constant task A A Time Scheduling Tool • Scheduling chart for multi-processor and multiple power consumers • Events can overlap vertically • Multi-processor • Multiple power consumer – electronics, mechanic, thermal • Power awareness – min and max power supply

16. Squeeze/extend bin to available time slot Slide bin within timing space Min timing constraint of D D Power C Max timing constraint of D Scheduling space of D C C C B B A Deadline of B (scheduling space) Time Deadline of B Deadline of C (scheduling space) Deadline of C Scheduling Tool • Timing constraints – bin packing problem to satisfy horizontal constraints • Independent tasks – moving bins horizontally • Dependent tasks – moving grouped bins horizontally • Power/voltage/clock scaling – extending/squeezing bins

17. Automated global scheduling to meet min-max power Power Attack spike Improve utilization C Max B B D C C Min A Time Manual scheduling while monitoring power surge Power D C C B B A Time Scheduling Tool • Power constraints – bin packing problem to satisfy vertical constraints • Automatic optimization – let tool do everything • Manual optimization – visualizing power in manual scheduling

18. Example – Mars Rover • System specification • Six wheel motors • Four steering motors • System health check • Hazard detection • Timing constraints • System health check 10s/10min • Heating motor for 5s, 100s prior to driving • Hazard detection 10s – steering 5s – driving 10s

19. Example – Mars Rover • Power constraints • Solar panel: 14.9W peak power @ noon, 11W for 6hr/sol • Battery: 10W max power output. 150W-hr energy storage • CPU: 3.7W, constant for 4h/sol • Health check: 6.3W, 10s • Hazard detection: 7.3W, 10s • Heating: 7.5W (1 motor) or 11.3W (2 motors), 5s • Steering: 6.8W, 5s (7º/s) • Driving: 12.4W, 10s (7cm) • Existing solution • Serialize each operation to satisfy power constraint • Conservative – longer execution time and under utilization of solar power • No scheduling tool is used

20. Scheduling Method • Constraint graph construction • Nodes: operations • Edges: precedence relationship between operations • Channel specification • Channels: resources that can perform operations independently • Six wheels heating channels, four steer motor heating channels • One driving channel, one steering channel • One computation channel • Operations on one channel must be serialized • Scheduling • Primary channel selection • Schedule primary channel by applying graph algorithms • Auxiliary channels and power requirement are considered as scheduling constraints

21. Constraint Graph Hazard detection / Thd System health check / Thc Heat steer 1 / Ths Heat steer 2 / Ths Heat steer 3 / Ths Heat steer 4 / Ths Steer / Ts thc -ths -(thc + Thc) System health check / Thc Heat wheel 2 / Thw Heat wheel 3 / Thw Heat wheel 5 / Thw Heat wheel 6 / Thw Heat wheel 1 / Thw Heat wheel 4 / Thw Drive / Td - thw

22. Hazard detection (C) / Thc / Phc_C Health check (C) / Thc / Phc_C Steer (C) / Ts_C / Ps_C Heat steer i (C) / Ths_C / Phs_C thc -(thc + Thc) Heat steer i (T) / Ths_T / Phs_T Steer (M) / Ts_M / Ps_M -ths + Ths_E Health check (C) / Thc / Phc_C Heat wheel i (C) / Thw_C / Phw_C Drive (C) / Td_C / Pd_C Heat wheel i (T) / Thw_T / Phw_T Drive (M) / Td_M / Pd_M Computation -thw + Thw_E Mechanic Thermal Channel Specification

23. Primary channel: Computation Auxiliary channel: Thermal Auxiliary channel: Mechanic Health check (C) / Thc / Phc_C Hazard detection (C) / Thc / Phc_C thc -(thc + Thc) Steer (C) / Ts_C / Ps_C Heat steer i (C) / Ths_E / Phs_E Heat steer i (T) / Ths_T / Phs_T Steer (M) / Ts_M / Ps_M -ths -ths + Ths_E -Ts_C + Ts_M Heat wheel i (C) / Thw_E / Phw_E Drive (C) / Td_C / Pd_C Heat wheel i (T) / Thw_T / Phw_T Drive (M) / Td_M / Pd_M -thw -thw + Thw_E Scheduling

24. CPU Health check Heat steer Heat wheel Hazard detection steer Drive 20 15 10 5 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 Existing Results • JPL solution • Over constraint – serialize every operation to satisfy power constraint • Conservative – longer execution time and under-utilization of solar power • No scheduling tool is used – manual scheduling • Not power-aware – scheduling without considering solar power output Power Time

25. CPU Health check Heat steer Heat wheel Hazard detection steer Drive 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 Power 20 15 10 5 Time Our Solution • Power-aware scheduling – high solar power • Max solar power output – 14W at noon • Relaxed constraint – heating motors while doing other operations • Aggressive – do as much as possible • Fastest moving speed – no waiting on heating • Improved utilization of solar power • Automated scheduling – use scheduling tools

26. CPU Health check Heat steer Heat wheel Hazard detection steer Drive 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 Power 20 15 10 5 Time Our Solution • Power-aware scheduling – typical solar power • Typical solar power output – 11W for 6hr/sol • Relaxed constraint –heating motors while doing other operations • Moderately aggressive – avoid exceeding power limit • Faster moving speed – some waiting time on heating • Improved utilization of solar power • Automated scheduling – use scheduling tools

27. CPU Health check Heat steer Heat wheel Hazard detection steer Drive 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 Power 20 15 10 5 Time Our Solution • Power-aware scheduling – low solar power • Typical solar power output – 8W at operation threshold • Restricted constraint – serialize operations • Conservative – save as JPL solution • Slow moving speed • Full utilization of low solar power • Automated scheduling – use scheduling tools

28. Comparison • Existing solution • Conservative – long execution time, low resource utilization • Not power aware – same schedule for all conditions • Not intend to use battery energy • Our solution • Adaptive – speedup when power supply is high • Power-aware – adaptive scheduling on different power supply • Use battery energy when needed