1. 1 Integrated Management of Power Aware Computing & Communication Technologies PI Meeting Nader Bagherzadeh, Pai H. Chou, Fadi Kurdahi University of California, Irvine, ECE Dept. DARPA Contract F33615-00-1-1719 November 1-3, 2000

2. 2 Outline Introduction  Concepts and goals  Program overview  Application Accomplishments to date  Architecture configuration  Scheduling Development platforms and tools Metrics Anticipated transitions

3. 3 Personnel & teaming plans UC Irvine- Design tools  Nader Bagherzadeh  Pai Chou  Fadi Kurdahi  Dexin Li  Jinfeng Liu  Duan Tran USC- Component power optimization  Jean-Luc Gaudiot  Seong-Won Lee JPL- Applications and benchmarking  Nazeeh Aranki  Nikzad “Benny” Toomarian students

4. 4 Quad Chart Innovations Component-based power-aware design  Exploit off-the-shelf components & protocols  Best price/performance, reliable, cheap to replace CAD tool for global power policy optimization  Optimal partitioning, scheduling, configuration  Manage entire system, including mechanical & thermal Power-aware reconfigurable architectures  Reusable platform for many missions  Bus segmentation, voltage / frequency scaling Impact Enhanced mission success  More task for the same power  Dramatic reduction in mission completion time Cost saving over a variety of missions  Reusable platform & design techniques  Fast turnaround time by configuration, not redesign Confidence in complex design points  Provably correct functional/power constraints  Retargetable optimization to eliminate overdesign  Power protocol for massive scale Behavior Architecture high-level simulation functional partitioning & scheduling composition operators high-level components behavioral system model busses, protocols system architecture mapping system integration & synthesis static configuration dynamic power management parameterizable components 2Q 00 Kickoff 2Q 01 2Q 02 Static & hybrid optimizations  partitioning / allocation  scheduling  bus segmentation  voltage scaling COTS component library FireWire and I2C bus models Static composition authoring Architecture definition High-level simulation Benchmark Identification Dynamic optimizations  task migration  processor shutdown  bus segmentation  frequency scaling Parameterizable components library Generalized bus models Dynamic reconfiguration authoring Architecture reconfiguration Low-level simulation System benchmarking Year 1Year 2

5. 5 Program Goals Power-aware system-level design  Enhance mission success (time, task)  Rapid customization for different missions Design tool  Exploration & evaluation  Optimization& specialization  Technique integration System architecture  Statically configurable  Dynamically adaptive  Use COTS parts & protocols

6. 6 Technical approach High-level specification  Separate behavior from architecture  Explicit constraints (timing, power)  Library characterization System synthesis tool  Source-aware power usage scheduling  Bus topology transformation and communication scheduling Configurable architecture  Task migration & selective shutdown  Bus segmentation and voltage scaling Domain knowledge  Encompass mechanical / thermal power  Aware of power supply model

7. 7 Application requirements System specification  6 wheel motors  4 steering motors  System health check  Hazard detection Power supply  Battery (non-rechargeable)  Solar panel Power consumption  Digital Computation, imaging, communication, control  Mechanical Driving, steering  Thermal Motors must be heated in low-temperature environment

8. 8 Design issues Timing constraints  System health check 10s/10min  Heating motor for 5s, 50s prior to driving  Hazard detection 10s – steering 5s – driving 10s Power management  Low-power electronics cannot make significant power saving  No system-level management tool available Conservative hand-crafted schedule  Serialize all operations to avoid power surge  Long execution time  Solar power wasted

9. 9 Power-aware vs low-power Low power  Minimize power consumption only  Minimal application specific knowledge, limited reconfiguration space  Conservative Power aware: Make best use of available power  Use MAX solar power while it's available  Increase parallelism, perform more tasks, reduce mission time  Both MIN and MAX power constraints  Application-specific knowledge Multiple mission requirement Adapt to run-time power supply, operating environment

10. 10 What's needed? Reconfigurable system architecture  NASA X-2000  Statically configurable for different missions  Reconfiguration for dynamic power management  Support state-of-the-art power management policies System-level design tool  Support design space exploration  Take full advantage of COTS components  Optimize mission-specific system configuration  Synthesize system-level power manager  Support simulation for early validation

11. 11 PA system architecture The NASA X2000 Avionics System high-rate input (camera) high-speed bus (e.g. IEEE 1394) communication module (CDMA) bus power controller symmetric multiprocessor modules altimeter subnet microcontroller-directed subnet - power regulations & control - analog telemetry sensors - safety inhibits - valve & pyro drive reconfigurable hardware blocks low-speed bus (e.g. I 2 C )

12. 12 Design tool Library  Components and bus protocols  Provides power estimation  Defines configuration space Authoring  Behavioral description, architecture description  Mapping from behavior to architecture Synthesis  Scheduling, partitioning  Bus segmentation, voltage scaling  Synthesis of power manager with task scheduler Simulation  High-level: explore design space  Detailed-level: power/performance for a given design point

13. 13 Accomplishments to date Power-aware scheduling  Multiple processors, mechanical, thermal  Min / Max power and timing constraints  Power-aware Gantt chart user interface Architectural optimization  Bus topology optimization  Bus segmentation  Power-mode-change optimization

14. 14 Legend CAM: camera MC: micro controller HD: hard drive NVM: non-volatile memory SCI: scientific equipment RF modem: radio frequency modem I2C bus omitted on this diagram FireWire 1394 Bus SCI HD / NVM CPU 1 RF Modem CAM MC 1 SCI 1 SCI 2 CPU2 (Bus controller) MC 2 MC 3 Tasks: MC's are responsible for sensing, drive control, steering control Capture picture, compress in CPU1, and send data to RF Modem SCI's carry out scientific experiments, sending data to CPU2 After analysis, CPU2 stores data in HD/ NVM X2000 architecture mapping Map Mars Rover application onto X2000 architecture

15. 15 Segmentation example Three bus segments SCI2RF ModemCAMMC1 HDMC2 SCI1 CPU2/ Bus controller CPU1/DSP MC3 MC sensing drive control steering control SCI scientific experiment CAM picture capture image compression RF transmission

16. 16 Summary of architecture optimization Towards loose coupling  Reduced bus contention  Increased parallel bandwidth  Enabling voltage/frequency scaling Application-driven clustering  Communication bandwidth requirements between processes  Knowledge from high-level behavioral model Static optimization2.4x energy reduction  Bus segmentation  Cluster shutdown Dynamic reclustering1.9x energy reduction

17. 17 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 Demo IMPACCT scheduler Power constraints – bin packing problem to satisfy vertical constraints  Automatic optimization – let the tool do everything  Manual optimization – visualizing power in manual scheduling

18. 18 Example – Mars Rover Power constraints  Different solar power supply over time  Different power consumption over temperature/time

19. 19 Application-level evaluation Mission description  Target location – 48 (distance-) steps away from current location Power condition  14.9W solar power for first 10 minutes, 12W for next 10 minutes, 9W thereafter Metrics  Execution time  Total energy drawn from battery

20. 20 Application-level evaluation Power-awareness  Execution speed scales with power condition adaptively Smart schedule  Maximize best case  Avoid worst case Tradeoff  Power vs. performance  Energy renewability Application-specific  Application-level knowledge  Working mode parameters of components

21. 21 Technology Transition -- Consystant Design Technologies Proprietary, Do Not Distribute

22. 22 Development plans Web-based CAD tool  Python/CGI scripts for arch. configuration (unix/web based)  Java applets for interactive scheduling UI (JDK)  Interface with database engine (mySQL) Interface with commercial CAD backend  Detailed power estimation tools  Functional simulation with proprietary models Rationale  No software installation needed by end user  Ready to use by everyone on the Internet  Open source with all publicly available development tools

23. 23 Updated schedule 2Q 00 Kickoff 2Q 01 2Q 02 Static & hybrid optimizations  Partitioning / allocation  Scheduling  Bus segmentation  Voltage scaling Library  COTS components  FireWire and I2C bus models Static composition authoring High-level simulation Benchmark Identification Architecture definition Static & hybrid optimizations  Partitioning / allocation  Scheduling  Bus segmentation  Voltage scaling Library  COTS components  FireWire and I2C bus models Static composition authoring High-level simulation Benchmark Identification Architecture definition Dynamic optimizations  Task migration  Processor shutdown  Bus segmentation  Frequency scaling Library  Parameterizable components  Parameterizable bus models Reconfiguration authoring Architecture reconfiguration Low-level simulation System benchmarking Dynamic optimizations  Task migration  Processor shutdown  Bus segmentation  Frequency scaling Library  Parameterizable components  Parameterizable bus models Reconfiguration authoring Architecture reconfiguration Low-level simulation System benchmarking option Year 1Year2

24. 24 http://www.ece.uci.edu/impacct/

25. 25 The need for a system-level CAD tool Avoid pitfalls with manual design  Overdesign (too conservative)  Hardwired assumptions in implementation (hard to change/adapt)  System integration (bottleneck in projects) Scalable methodology  Specification: separation of concerns Behavior vs. architecture Policy vs. mechanism Constraint vs. implementation  Exploration Framework for technique integration Rapid feedback  Manage complexity Knowledge base for component/bus details Consistent knowledge propagation through design stages