1 / 28

High-level System Modeling and Power Management Techniques

High-level System Modeling and Power Management Techniques. Jinfeng Liu Dept. of ECE, UC Irvine Sep. 2000. Background . X2000 Avionics System Architecture COTS – based building blocks for system integration Low cost component with strong commercial support

Download Presentation

High-level System Modeling and Power Management Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related