Design considerations for power-sensitive embedded devices
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.
Hibernate/Suspend
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.
Loading comments... Write a comment