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.
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.
Planning the Use Cases
Once the hardware is chosen and the decision has been made to use a particular OS, it is time to specify use cases for the device. A use case is typically a function that a device performs, whether with or without user interactions.
Let’s consider a hypothetical, battery powered, wearable medical device with a small LCD display that collects a patient’s vitals (body temperature, heart rate, etc.) and uploads the data periodically to a central server over Wi-Fi network. In such a device we can break out the following use cases:
1. Device takes a complete measurement
2. Device uploads a set of measured data
3. User checks his/her own vitals using a built in display
4. Device is idle awaiting the next measurement
For each use case we should determine how much functionality is required from each driver (if any), which in turn determines which drivers (and therefore hardware blocks) need to be enabled per use case. Using estimated hardware power consumption numbers and estimated time-spent in a specific use case, we can estimate the power consumed by each use case.
Combining this with the expected frequency of each use case as the weight factor, we should be able to come up with an energy breakdown showing how much of the full battery charge is consumed, per use case, over a set time period, e.g., 24 hours.
Using hypothetical numbers shown in Table 1 above , an energy breakdown for our hypothetical device is shown in Figure 2 below . This can be very helpful in determining early whether the estimated battery life has a chance to meet the original product requirements, and if not, how things can be adjusted.
For example, given the energy consumption per use case in Figure 2, one can clearly see that Data Upload is the biggest consumer of energy. If measuring vitals every five minutes and immediately uploading them to the server is too power costly, maybe measuring every five minutes, but uploading every 30 minutes is sufficient for the customer.
This would allow for the lowering of overall daily energy consumption. Of course along with the 30-minute intervals, there could be an emergency threshold set so that if the patient’s vitals exceed some critical threshold they are immediately uploaded.
User Vitals Check use case is the second biggest consumer of energy. Our assumed duration of 30 seconds use case was based on a 30-second timeout during which the built-in display continues showing the measured vitals after the user presses a key.
From this, we can see that decreasing the timeout to a lower yet still acceptable number significantly increases the battery life of the device. This use case is also an excellent candidate for average current optimization by shutting down any unnecessary hardware and setting the minimum operating point required to display static vitals measurements.
Setting BSP Requirements
Once armed with the use case data we can go back to define power requirements for the drivers. This is where the right OS choice can make it much easier on the designer. For example, when using Mentor’s Nucleus RTOS the following can be specified for each driver:
1. Exactly how many power states it has to support (ON, STANDBY, SLEEP, OFF) and what are their functional and power requirements; for example, in OFF state the device must be powered completely off and not drawing any power, in SLEEP state it must retain its state but disable functionality in lieu of set power savings, and in ON state it can be fully powered-on whenever needed in order to satisfy maximum performance as required by the applications.
2. What operating points the device driver will be operating at (specified per power state); for example, while ON the device should be fully functional at 200MHz and 100Hz while it has to be able to sustain SLEEP mode with the clock as low as 1MHz.
3. Any other requirements such as registering for DVFS participation or letting the OS know when memory DMA transfers are in progress, so that the DRAM can be put in self-refresh mode when the OS has determined that the expected idle time is sufficiently long – doing so will result in overall power savings.
It’s not uncommon when designing embedded devices that drivers are initially written with only functionality in mind with very little or no regard to power management. Designers will simply copy the reference code from the hardware vendor that turns on the entire device, leaving power optimization considerations until the very end of the project.
This usually results in sub-optimal power performance and last-minute-hacked-in code dispersed throughout the product codebase. This can also affect portability to new designs.
These types of approaches (and their shortcomings) can be avoided with some upfront planning to allow the full realization of the hardware potential. Having clear BSP requirements will go a long way to achieving the desired power performance of the design.
Some hardware nowadays allows the system to enter very low power consumption modes. There are chipsets with dedicated hibernate/suspend blocks that allow the power consumption to be cut down by well over 90% as compared to the next lowest power mode. If an operating system can take advantage of such features it will provide additional power reduction options for your design.
In Nucleus for example, two such modes are supported, called ‘hibernate’ and ‘suspend’. In suspend mode all hardware is powered off except for DRAM, which is kept in a self-refresh low-power mode. Upon exiting suspend (typically via an interrupt) the hardware is re-initialized and normal operation is resumed.
The hibernate mode is similar to suspend, except the OS also backs up all allocated DRAM content to non-volatile storage allowing it to shut down DRAM, and therefore, disables all of the hardware completely resulting in near zero power consumption.
When considering using such ultra-low-power modes, the main points to consider are the power cost to enter and exit those modes and the time cost that impacts device responsiveness. The latter has the potential to affect user experience.
Both of these costs are best estimated by actual measurements, but a general rule of thumb is that suspend enter/exit cost is affected by the number of devices that are ON when entering suspend or hibernate. Every such device increases the time necessary to enter and exit suspend due to the need to save state and power down and then reinitialize each device upon exiting suspend or hibernate.
Hibernate adds an additional cost over suspend of storing all allocated RAM contents in non-volatile storage which depends on how much RAM is in use at the time hibernate state is entered. An indirect cost of hibernate worth noting is the potential to reduce the lifetime of the system due to the maximum number of write cycles most non-volatile storage chips can handle.
What determines whether suspend or hibernate should be used is if the power benefit achieved offsets the costs. For our hypothetical medical device this will depend on the measurement interval that determines how often the device has to wake up to do something.
Whether suspend or hibernate should be used will depend primarily on how often the device is active, and for this device this means the measurement interval. Adjusting the measurement interval can make using suspend or hibernate very efficient or prohibitively expensive on power.
Application is the last tier of software that can limit overall system power performance. Badly written application can completely decimate power efficiency.
This is another area where having an operating system with built-in power features can help tremendously. In such an OS, one or more applications can be written, each running as one or more threads, concentrating solely on its own task at hand and reporting to the OS its power needs.
Using our hypothetical medical device, one such independent application can be written to collect all the vitals data. That application would simply indicate to the OS what peripheral device drivers are needed to complete its task, what minimum operating point is required, etc.
Once the application completes its task it simply lets the OS know that it no longer requires those resources. It also relinquishes the CPU by using blocking calls and/or using sleep APIs to allow the OS to schedule another task and/or switch the CPU to an idle or other low power mode.
A separate application that uploads the data would take the exact same approach, informing the OS only about its own requirements and yielding the CPU when not needed. The OS will in turn consider all running applications and their needs, turning on what is needed only when needed and set the appropriate operating point in order to minimize the system power consumption.
Very little, if any, communication between the two application writers is required; the OS power framework is all they need to know about. This also has an added benefit of application code reusability on other designs using the same operating system.
Measurement, Tracking and Testing
Power should be measured from the very first day of code development. What makes this possible is the up-front planning by setting power requirements for individual drivers, clearly defining the use cases, and mapping those use cases to each application in the system.
Both application and BSP code developers should be equipped to measure power and should consider meeting power requirement as part of the code functionality. A Wi-Fi driver, for example, that works great with all wireless networks is not complete if it cannot be turned off in such a way as to disable all the hardware and reduce its power consumption to almost nothing while disabled.
That same driver should also be able to turn back on and be just as functional as the first time it was on. Subsequently, it should be able to perform this on/off cycle 100,000 times and more with the same results.
This may seem obvious, but a lot of developers get caught on this. All drivers should have their power functionality tested thoroughly to ensure they properly enable/disable hardware, participate in DVFS transitions, and inform the OS of the DMA transaction if required.
When using the aforementioned approach, once you get to code complete, your power performance should already be meeting your system requirements. However, there may be room for more optimization. Making your device last longer can allow for smaller battery size or accommodate more feature functionality.
Measuring the power for each planned use case and applying the energy usage analysis mentioned earlier can guide you to assess where the “biggest bang for the money” is as far as applying optimization efforts. The optimization can also include changing operating parameters by adjusting or even creating new use cases.
Power will continue to challenge embedded developers. As hardware vendors offer more tantalizing power saving features it becomes crucial that the software fully utilize them. As systems become more complex, it becomes increasingly and prohibitively impractical to ignore the proper up-front planning for system power consumption while hoping to power optimize on the back-end of the development process.
Adam Kaiser is a Nucleus RTOS architect for the Mentor Embedded team at Mentor Graphics . He has extensive expertise in embedded power management and is responsible for architecture of the Nucleus Power Management Framework. Prior to joining Mentor Graphics, Adam worked as a software architect for Texas Instruments (OMAP) and for Microsoft (Windows Mobile) where he worked closely with various mobile phone and other embedded device manufacturers focusing on power management.