Extreme Processing Thresholds: Low Power On-Chip Resources
Robert Cravotta - April 16, 2010
In the previous post in this series I pointed out that the “sweet spot” clock rate for active power consumption for some microcontrollers is lower than the maximum operating clock rate for that part. However, looking only at the rated power consumption of these microcontrollers at a steady always-on operating state ignores the fact that many low-power microcontrollers employ on-chip resources that can significantly impact the overall energy consumption of the part as the system transitions through multiple operating scenarios.
For low power applications, designers usually focus on the overall operating system energy draw rather than the peak draw. This focus on overall power efficiency justifies the additional design, build, and testing complexity of using low power and sleep modes when the system does not need to draw on the full processing capacity of the processor. In fact, many low power constrained systems spend the majority of their operating time in some type of sleep mode and transition to full active mode only when needed. This relationship begins to hint at why using only a single uA/MHz benchmark is insufficient to evaluate a processor’s energy performance.
There is a variety of low power modes available to processor architectures. Shutting down just the CPU and leaving all of the other on-chip resources functional is one type of sleep mode. Deeper sleep modes can turn off individual or all peripherals until the only on-chip resource drawing current is for RAM retention. Always-on resources may include a power supervisor circuit with brown-out and power-on-reset functions; these functions must be enabled 100% of the time because the events they are designed to detect cannot be predicted.
So in addition to active power draw, low power designers need to understand the system’s static or leakage current draw when the system is inactive. Another important metric is wake-up-time – the amount of time it takes the system to transition from a low-power mode to the active operating mode because the system clock needs to stabilize. The longer it takes the system clock to stabilize, the more energy is wasted because the system is performing no useful work during that time.
A DMA controller is an on-chip resource that affects a system’s power consumption by offloading the task of moving data from one location to another, say from a peripheral to memory, from the expensive CPU to the much cheaper to operate DMA controller. The following chart from an Atmel whitepaper demonstrates the value of using a DMA controller to offload the CPU, especially as the data rate increases. However, effectively using the DMA can add a level of complexity for the developer because using the DMA controller is not an automated process.
Some microcontrollers, such as from Atmel and Energy Micro, allow developers to configure the DMA controller and peripherals, through some type of peripheral controller, so that they can collect or transmit data autonomously without waking the CPU. On some devices, the autonomous data transfer can even include direct data transfers from one peripheral to another. The following chart from Energy Micro’s technology description demonstrates the type of energy reduction autonomous peripherals can create. The caveat is that the developer needs to create the highly autonomous setup as there are no tools that can perform this task automatically at this time.
On-chip accelerators not only speed up the execution of frequent computations or data transformations, they also do it for less energy than performing those functions with a software engine. Other types of on-chip resources that save energy draw can include ROM-based firmware, such as being adopted by NXP and Texas Instruments on some of their parts. There are countless approaches available to chip architects to minimize energy consumption, but they each involve trade-offs in system speed, current consumption, and accuracy that are appropriate differently to each type of application. This makes it difficult to develop a single benchmark for comparing energy consumption between processors that overlap capabilities but target slightly different application spaces.
To make following this series easier (especially as multiple series overlap each other), I am including the index below to previous posts. I encourage you to read all of the posts for each series; maybe they will inspire you to share your observations. Monday posts address the Robust Design series. Wednesday posts address the Question of the Week series. Friday posts address the Extreme Processing Thresholds series. I would love to be able to consolidate different perspectives and lessons learned here because I suspect there are some valuable lessons to be gleaned from comparing such stories. If you would like to participate in a guest post, please contact me.
Previous post in the Extreme Processing Thresholds series:
2010, April 9: Extreme Processing Thresholds: Low Power #2
2010, April 2: Extreme Processing Thresholds: Low Power #1
2010, March 26: Extreme Processing Thresholds: Low Price
2010, March 19: Extreme Processing Thresholds
Share your thoughts.
Currently no items