The power pyramid
March 15, 2018
Story
Power consumption of embedded systems continues to be a hot topic (no pun intended). And there?s one aspect of designing for low power that should be placed under the spotlight?the Power Pyramid.
Power consumption of embedded systems continues to be a hot topic (no pun intended). And there’s one aspect of designing for low power that should be placed under the spotlight—the Power Pyramid.
As I discussed in a previous post, the idea of power consumption being an issue for software developers is quite novel. It was previously regarded as purely a hardware problem. Even now, software optimization for power is commonly an after-thought and is only attempted at the end of the project, when the need to reduce power consumption becomes apparent.
This is entirely backward. Power issues should be considered from the very outset, as the initial work has the most influence on the final result and the requirements specification will most likely specify permissible power consumption levels.
The concepts are illustrated graphically by the Power Pyramid, which shows, from the bottom up, the key design issues through the course of the project; this is also in descending order of influence over device power consumption:
Hardware selection. Although this is clearly not the responsibility of the embedded software designer, hardware developers should listen to the requirements of the software team, as the capabilities of the CPU and associated circuitry are critical to power management.
Use cases. At an early stage in software design, it’s common to draft a series of Use Cases. These are the software’s modes of operation, which may or may not involve user interaction. This is an ideal time to characterize a device’s power consumption. It’s a matter of assessing the resource requirements for each use case to estimate their power profile.
Operating system. An operating system that incorporates a power management framework enables low power design to be performed at every stage of the project. The availability of this functionality may be a key driver for selecting a specific OS.
BSP/drivers. Building power awareness into drivers is an essential aspect of using an OS with power management. It makes sense as the driver corresponds to specific hardware that may be powered down when not in use. Furthermore, the driver encapsulates the "knowledge" of the device's limitations - e.g. what voltage and clock frequencies may be acceptable for its reliable operation.
Application code. The top level of code offers the least opportunities for power optimization. However, badly written code can have a negative impact on a design power profile.
I’m quite sure that this is not the last that you will hear from me on this topic.
