Our cover story in this issue treats one aspect of an increasingly important design requirement: energy consumption. It may sound like a pure hardware issue, but software design is at least as significant as hardware for energy efficiency. Once even rudimentary hardware provisions—such as standby and sleep modes—are in place, the responsibility falls on software developers at all levels to use the modes effectively. A non-power-aware OS or careless application code can negate anything the hardware designers can accomplish.
But you can't manage what you can't measure, as the saying goes. A really interesting panel at ESC Boston this September explored the problems of estimating and measuring power during design. Perhaps surprisingly, neither task is easy.
The traditional approach is to sit down with the IC datasheets, a guess at the end-user's use models, and a great deal of coffee, and build a spreadsheet. But panelists pointed out that today, when the hardware may have very complex internal power-management mechanisms of its own, the datasheet numbers may be only a vague suggestion of reality. The typical operating power, for example, may represent the average of a random scattering of very large but randomly-spaced current spikes. The real shape of the complicated supply-current waveform will probably be highly software-dependent.
Even if you could count on the average or RMS figures being reasonably representative, they may not be enough information. An audience member at the panel warned that battery life depends not just on current-drain and time but on details of the current waveform: how high are the current pulses, what is their duty cycle, and what is their impact on battery temperature, for example. Similar information is necessary for selecting regulators for AC-powered supplies.
System-level power-estimation tools can help keep track of power modes and use models. But they often work with averages, not waveforms, and are dependent on the accuracy of the hardware models you plug in. One panelist (an FPGA vendor) suggested that the most accurate power estimations come from FPGA vendors' tools, simply because a vendor can control the hardware, power-management architecture, and much of the silicon IP.
Of course you can build a prototype, load the software, and measure current through the actual supply nodes. But because of those complex waveforms, even this approach can be misleading. Current meters measure RMS or average current. And measuring current over a range of ten-thousand to one without disturbing the circuit is a huge electrical problem. Just taking the measurements may require a complex test set up and perhaps a programmable mixed-signal scope. It may also require forcing the prototype into a single operating mode during the measurements.
So on the one hand, software has very significant influence over energy consumption in embedded designs. On the other hand, estimating or even measuring that influence during the design is fraught. It is a nontrivial problem.
Ron Wilson is the director of content/ media, EE Times Group Events and Embedded. You may reach him at firstname.lastname@example.org.