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  I 2 C 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 2, C2 < 4 # two power consumers  C1 + C2 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. Scheduling Tool  Extended Gantt-chart in real-time scheduling for single processor Extended Gantt-chart in real-time scheduling for single processor  Event – bins Event – bins  Timing – horizontal size Timing – horizontal size  Power – vertical size Power – vertical size  Energy – area of the bin Energy – area of the bin  Power surge – compacting bins downward Power surge – compacting bins downward Power Time Starting timeEnding time Power levelEnergy consumption

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

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

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

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 System health check / T hc t hc -(t hc + T hc ) Heat wheel 1 / T hw Heat wheel 2 / T hw Heat wheel 3 / T hw Heat wheel 4 / T hw Heat wheel 5 / T hw Heat wheel 6 / T hw Heat steer 2 / T hs Heat steer 3 / T hs Heat steer 4 / T hs Hazard detection / T hd Steer / T s Drive / T d - t hw -t hs Heat steer 1 / T hs

22. Channel Specification Hazard detection (C) / T hc / P hc_C Health check (C) / T hc / P hc_C Heat steer i (C) / T hs_C / P hs_C Heat steer i (T) / T hs_T / P hs_T Heat wheel i (C) / T hw_C / P hw_C Heat wheel i (T) / T hw_T / P hw_T Steer (C) / T s_C / P s_C Steer (M) / T s_M / P s_M Drive (C) / T d_C / P d_C Drive (M) / T d_M / P d_M -t hs + T hs_E -t hw + T hw_E Health check (C) / T hc / P hc_C Computation Mechanic Thermal t hc -(t hc + T hc )

23. Scheduling Hazard detection (C) / T hc / P hc_C Heat steer i (C) / T hs_E / P hs_E Heat steer i (T) / T hs_T / P hs_T Heat wheel i (C) / T hw_E / P hw_E Heat wheel i (T) / T hw_T / P hw_T Steer (C) / T s_C / P s_C Steer (M) / T s_M / P s_M Drive (C) / T d_C / P d_C Drive (M) / T d_M / P d_M -t hs + T hs_E -t hw Primary channel: Computation Auxiliary channel: Mechanic Auxiliary channel: Thermal Health check (C) / T hc / P hc_C t hc -(t hc + T hc ) -t hs -t hw + T hw_E -T s_C + T s_M

24. Existing Results 1020304050607080901001101201301401501600 5 10 15 20 CPUHealth check Heat steer Heat wheel Hazard detection steerDrive  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. Our Solution CPUHealth check Heat steer Heat wheel Hazard detection steerDrive 5 10 15 20 Power 1020304050607080901001101201301401501600 Time  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. Our Solution CPUHealth check Heat steer Heat wheel Hazard detection steerDrive 5 10 15 20 Power 1020304050607080901001101201301401501600 Time  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. 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 CPUHealth check Heat steer Heat wheel Hazard detection steerDrive 5 10 15 20 Power 1020304050607080901001101201301401501600 Time

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