Design considerations for power sensitive embedded devices

The importance of power management and optimization in today’s embedded designs has been steadily growing as an increasing number of battery-powered devices continue to perform more complex tasks.

The unrelenting demand for connectivity and new features presents a growing challenge to designers. Yet, very often power optimizations are left to the very end of the project cycle, almost as an afterthought. When setting out to design a power-optimized embedded device, it is important to consider power management from the very inception of the project.

This article discusses design considerations that should be made when beginning a new embedded design. The considerations include choosing the hardware with appropriate capabilities, defining hardware design constraints to allow software to manage power, making the right choice of an operating system and drivers, defining appropriate power usage profiles, choosing measurable power goals, and providing these goals to the software development team to track throughout the development process.

Early Design Choices Limit Power Performance

The best possible power performance of an embedded device is limited by a number of factors starting with very early design choices. Figure 1 below shows the power constraints pyramid. Starting with the hardware choice, each progressive level in the pyramid introduces compounding constraints on top of the previous level.

At the very top of the pyramid is the application(s) layer. An application’s power performance potential is limited by all of the lower levels of the power constraints pyramid combined – the application can do no better on power than the hardware, use cases, operating system, and the device drivers allow for.

Figure 1: The Power Constraints Pyramid.

The first design decision and the one that imposes the widest set of power performance limitations is hardware choice. When choosing the chipset for a device you have to consider both the functionality that the hardware offers as well as the power consumption and power saving features of the hardware.

Things to look for include the ability to turn off individual blocks such as peripherals (a.k.a. clock and power gating); CPU idle and other low-power modes; Dynamic Voltage and Frequency Scaling (DVFS) capabilities; hibernate blocks and other power management features.

If the device incorporates different chips/modules interconnected via a bus of some type, you should pay close attention in the design stage to ensure that the individual modules can be turned on and off independently and/or that they can operate (or at least survive while disabled) at all desired operating points (voltage/frequency pairs) of the bus that they connect to.

Once the hardware choices are made, it dictates the absolute best case power consumption the device will theoretically be able to achieve. The next limitation is the operating system. If the operating system does not have the facilities to take advantage of the low-power features of the hardware, such as DVFS or CPU Idle modes, the design will not be able to reach its full hardware potential.

The OS choice also has a tremendous impact on the performance of the BSP, which is the next limiting factor of the design. If an OS has a native power framework it can make things more efficient by allowing each driver to have a clearly defined set of power states and by providing a mechanism for the drivers to participate in DVFS operating point transitions.

Since the OS together with its BSP can severely limit your device’s ability to realize the full hardware power saving potential, it is crucial that the BSP be written with proper power requirements from the very beginning. Before specifying the power requirements for each driver however, use cases for the device need to be considered.