I’ve had a nagging question at the last few Embedded Systems Conferences I’ve attended. Why isn’t anyone here – aside from a few silicon vendors – talking about low power design?
If you go to any hardware design conference, low-power design will be a major theme, if not THE major theme. Nearly every EDA vendor is focusing on low power design. But the embedded software world is very differerent. At the recent Embedded Systems Conference in San Jose, low power design did not appear to be a significant focus, although there were a few sessions in a “green engineering” track.
Embedded software is a critical element in any low-power design strategy. You can implement all the low power features you want in a system-on-chip, but if the software doesn’t implement power-down modes at the right times, or take advantage of voltage and frequency scaling, those hardware features are worthless. You can use a processor core with lots of nifty power management features, but if the software doesn’t use those features, what’s the point?
Moreover, poorly written or poorly planned software can not only fail to save power, it can waste power and battery life. If you have too many memory accesses, inefficiently used registers, or poorly managed I/Os, batteries will drain quickly regardless of any power-saving features designed into the hardware.
With these thoughts in mind, I talked to a few of the real-time operating system (RTOS) and development tool providers to find out what, if anything, they’re doing about low power design. I’m pleased to report that there is at least some awareness about the problem.
RTOS provider Express Logic and ARM recently put together a presentation on hardware and software approaches to power management. The presentation noted the potential power savings that can accrue from a small code footprint, reduced memory accesses, and “fast” code that can run effectively on a slower processor speed. It also noted some dilemmas. Should the program always enter “sleep” mode when there’s no activity? Too much re-awakening and processing at each timer interrupt may outweight any benefits from power savings.
At the Microsoft booth, I learned that Windows Embedded CE comes with a Power Manager that will interact with system drivers to reduce power consumption. It supports power states including On, User Idle, System Idle, and Suspend, as well as five levels of driver power states. A blog posting explains these features further.
Green Hills Software, which offers development tools as well as the Integrity RTOS, addresses power in several ways. Compilers claim to minimize power consumption by generating code with small footprints. Debuggers let developers profile applications and find execution bottlenecks that can lead to wasted power. The RTOS uses an API to take advantage of the power management features of various processors, such as turning off peripherals that aren’t in use.
One RTOS company representative confided that his company isn’t doing much beyond supporting some basic power management features. This led to an interesting discussion about the potential incompatibility of hard real-time system requirements with low power demands. Suppose you power down an interface because it’s been inactive, and then an interrupt comes along. Can you awaken in time to meet real-time constraints?
Embedded Linux provider MontaVista Software has some good resources on its web site, including a whitepaper about dynamic power management for embedded systems, and a webinar and presentation on embedded Linux power management for the Intel Atom processor. MontaVista’s Mobilinux OS provides a dynamic power management capability that supports hardware features such as dynamic voltage and frequency scaling. Software developers can shut off unused portions of the chip and turn off clocks and I/O devices.
I’m pleased to see such power management features in operating systems. It would be good to see more discussion and more resources for software developers, as well as tools that specifically address power – such as software simulators that run power analysis, or profilers and debuggers that specifically point to code that wastes power.
The most important point is that low-power design is not a hardware task alone. Software developers have to be fully aware of the low-power features that hardware developers build into chips, and write software that takes advantage of these features, while avoiding tasks and functions that might disrupt them. This means that hardware and software architectures must be developed cooperatively. Without that change in corporate culture, the best tools in the world won’t solve our power consumption challenges.