The Power Pyramid

Power consumption of embedded systems is currently a hot topic – one I have posted on several times before. With the conference season coming up, I am working on a few papers that address this subject and I will talk about those nearer the time. However, there is one aspect of designing for low power that I thought it would be worthwhile putting under the spotlight.

I want to introduce the “Power Pyramid” …

It is only recently that power consumption of an embedded system has been recognized as an issue at all for software – previously it was regarded as purely a hardware problem. Even now, optimizing software for power is frequently an after-thought and is only attempted at the end of the project, when the need to reduce power consumption has become apparent.

This is entirely back to front. Power issues should be considered from the very start of the project, as the initial work has the most influence on the final result. The concepts are illustrated graphically by the Power Pyramid, which shows the design issues, through the course of the project, from the bottom up, which is also in descending order of influence over device power consumption:

Hardware selection. Although this is obviously not the province of the embedded software designer, some influence should be brought to bear on their hardware counterparts, as the capabilities of the CPU and associated circuitry are critical to power management. Self-evidently, access to these capabilities for software is equally essential.

Use cases. At an early stage in software design, it is common to draft a series of Use Cases. These are modes of operation of the software, which may or may not involve user interaction. It is sensible to consider the resource requirements for use cases in order to estimate their power profile.

Operating system. An operating system which incorporates a power management framework [like Nucleus] enables low power design to be performed at every stage of the project. The availability of this functionality may be a key driver for the selection of 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 may encapsulate the “knowledge” of the device’s limitations – e.g. what voltage and clock frequencies may be acceptable.

Application code. The top level of code offers the least opportunities for power optimization. However, badly written code can influence the power profile of a design in a negative fashion.

I am sure that this is not the last that you will hear from me on this topic.

Take a look at this new video:

I think that it encapsulates a lot of the power management concepts rather well. Also, see the recently-updated Nucleus home page.