Power Aware Computing and Communications (PAC/C) 1. FY2000 • PAC/C ... EAC/C • Solicit support • MACHO-FLOPS • Embeddable systems, ubiquitous • Focus on power constrained systems • all systems 2. Navy, Army, Air Force • on ground, in the ground • on water, under water • in the air, in space • Size, Weight, Area, Power: SWAP limitations • PAC/C will have a positive impact in addressing each of these SWAP issues. • Direct impact on ubiquitous embeddable systems: watches, pagers, cell phones, PDAs, laptops, ... 3. Prepare for the worst case, just in case, is wasteful • engineers mult worst by a factor --- just to make sure • Result is that typically are systems that are over-designed... larger, weighs more, costs more, life-cycle • 45.4 lbs of batteries • 59 batteries over 4 battery types • 50% of communication system weight!! 4. Intelligent memory management • systems w/limited energy • Integrated PA environment from algorithm level to system level • Both HW & SW approaches are of interest: compiler, algorithms, middleware, OS • "First class citizen" • 30,000 ft. view: right power, at the right place, at the right time • Min power to get the job done • < fails to get the job done • > wasteful • Energy/performance tradeoffs • Extend life of missions • enable new missions 5. 2-3 Orders of magnitude reduction in energy needs as compared to conventional technologies • Integrated suite • HW-arch solutions & circuits designed for PA demands • SW - PA algorithms, middleware, compilers & OS power-aware scheduling • Required to make POWER a 1st class citizen 6. Graphic depicts the PAC/C holistic approach • As you can see.... • Let's take a closer look at elements of the PAC/C program in greater detail • Application-Level Power Management • System and Architecture-Level Power Management • System Integration, Experiments, Benchmarks 7. Algs specifically designed with energy conservation in mind • avoid energy "hogs" • embrace energy conserving • dev envs to support this • Energy conserving protocols that are flexible -- dialable • how robust, how reliable? • Tradeoffs: Key component compute/comm tradeoff • move computation onboard... less energy to xmit? 8. Tradeoff example • Brodersen at Berkeley • digital radio • 1 bit = 300 ops of energy • 100Kbits worth of data to xmit, could be compressed to 10Kbits... worthwhile? • Only if compression can be done in 270 MOPS or less • further complicated when distance is factored in... greater distance, more energy • 1 order mag. Reduction in distance translates to 0.27MOPS 9. Work at the coarsest scale wherever possible, dropping to finer scales only when necessary. Coarser scale... less energy • Energy for image proc f(ops/pixel) • bottom picture is 16:1 reduction • Dev algs and middleware that would exploit this capability automatically. • Distributed arithmetic is another example of multi-scale processing. MSb processing is done first. 10. This element contains items that are indirectly available to the user • compilers (automated and assisted) • instruction scheduling for energy mgnt. • operating systems for energy scheduling • dynamic volt/freq mngt • clock gating • PA libraries • energy efficient FFT • PA componentry... energy aware technologies • micro devices that support the adaptive use of power • dyn volt/freq scaling • clock gating • adaptive encoding/decoding • Another area demanding attention is CAD tools to support designing and simulating energy aware devices • "Look and feel" of conventional counterparts, but focus on energy as the resource to be controlled 11. This example comes from Chan-dra-kasan from MIT • COTS Strong-arm processor • digital encryption algorithm • implemented in both C and assm. • Assm, tighter code and exploit Strongarm PA instructions not used by the compiler • Difference, as represented by the gap between the lines, is one order of magnitude alone... just using compilation • Not advocating going back to programming in assm.!! 12. Rabaey at Berkeley is exploring dynamic voltage/frequency scaling in his Pleiades DARPA project • Shown are energy-delay, for FFT processing, versus various processors: Strongarm, DSPs and the Pleiades processor • 3 orders of magnitude improvement!!! • But.. This is a point solution • PAC/C is looking for widely applicable solutions 13. 3rd and last PAC/C element • Integrate PAC/C, or other power-aware technologies • Develop power-aware benchmarks and measurement mechanisms • Identify experiments and demonstration opportunities • Identify candidate applications • Downselect and retain the more promising approaches 14. Dial in the energy required to provide a given level of performance • Tools and environment applicable to a broad range of problems that are solved with point solutions today • Exploit existing devices, such as the Strongarm • retrofit • Enable new missions • Applicable even to low-power systems!! 15. 4th quarter of FY99 • Focus on exploiting existing technology • get some PAC/C benefits early • Algorithms and middleware • Compilers • Benchmarks • Early demonstrations 16. Fortunate to have two phrases that capture the PAC/C vision of empowering the user to control and manage energy in systems in response to mission needs as a function of time • right power, at the right place at the right time • Just In Time Power (JIP) • Hope I've "sparked" your interest and encourage your participation in the PAC/C program