Posted by Cary Chin on October 20, 2011
This blog originally posted on the Low Power Engineering Community 6/16/11.
Last week was the annual pilgrimage of hardware designers to the Design Automation Conference, where the latest in tools and technologies are displayed for use in upcoming generations of computer and electronic devices. And it was no surprise that low-power design continues to expand across all facets of the design space, from LED lighting to smart phones and cloud computing.
For me, one of the memorable moments was the mention of a new acronym in Alan Gibbons’ tutorial “System-Level Design and Software Development for Energy Efficient Platforms: Challenges from Models to Methods” – RFTS stands for “Run Fast, Then Stop.” Could this be a viable new strategy in our unending quest for energy-efficient hardware design? Haven’t we shown that voltage reduction is the real winner, resulting in a squared reduction in power, and even more as frequency is reduced? Won’t the inevitable leakage current in idle mode swamp any potential gains, anyway?
The answers, as expected for any complex question, are “maybe,” “kinda,” and “sorta.” While by now we’re all used to clock gating to reduce dynamic power and multi-threshold transistors to control leakage, and even voltage reduction, power shutdown, and dynamic voltage/frequency scaling, the demand for more techniques to minimize energy consumption continues to grow. Once we’ve lowered voltages to the point where noise (and timing) margins are a concern, and we’re shutting down everything possible, what’s next? RFTS is one answer to the question of whether it’s more efficient to work slowly and constantly, or finish the job as fast as possible and take a break. Clearly the general answer depends on the effectiveness of any shutdown strategy, the level of speed control, and some knowledge of the input stream of work to be done.
I was struck by the similarity of these questions to the questions we’ve raised regarding iPhone power efficiency. When we tested the AT&T iPhone vs. the Verizon iPhone for video streaming a few months ago, the results seemed to come down in favor of coverage (and a stronger signal), but in areas of similarly weak and variable signal, having a faster network was a clear advantage. Receive fast, then stop – interesting!
Optimizing for energy efficiency continues to get more complicated, requiring better and higher level analysis to make the right decisions, and extending the challenges to the design community. That’s a good reason to return to DAC next year.