The power pyramid

March 15, 2018 Colin Walls, Mentor Graphics

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.

Colin Walls is an Embedded Software Technologist at Mentor Graphics’ Embedded Software Division.

Previous Article
Populating smart devices with the right IQ
Populating smart devices with the right IQ

Will the 3X growth rate from 2015 to 2020 in connected things – up to 21 billion connections, per that well...

Next White Paper
3 Mandates for Successfully Managing Your Things
3 Mandates for Successfully Managing Your Things

The Industrial Internet of Things (IIoT) has quickly evolved from concepts and pilot projects to fleet-wide...