Unraveling the Ultra-Low Power Design Issues
Robert is a very diligent engineer, so his boss had full confidence that his ultra-low power design would exceed the requirements for the product’s 12-year battery life. Six years later, customers started complaining about the prematurely depleted batteries. What went wrong with the design? Robert diligently followed the microcontroller datasheet specifications, which indicated an active current of 1000 microAmps. However, the datasheet failed to indicate the precise workload that was being applied during this measurement. Unfortunately, Robert’s design had a more computationally intensive workload than the specification utilized, resulting in a significantly increased amount of power consumption.
Robert is a very diligent engineer, so his boss had full confidence that his ultra-low power design would exceed the requirements for the product’s 12-year battery life. Six years later, customers started complaining about the prematurely depleted batteries. What went wrong with the design? Robert diligently followed the microcontroller datasheet specifications, which indicated an active current of 1000 microAmps. However, the datasheet failed to indicate the precise workload that was being applied during this measurement. Unfortunately, Robert’s design had a more computationally intensive workload than the specification utilized, resulting in a significantly increased amount of power consumption.
For all you “Roberts” out there, you probably realize that this is an overly simplified and exaggerated story, but the key point is that you cannot rely on the datasheet numbers. While you might be able to extrapolate the specifications to match your design characteristics, you’ll never be 100% sure until the product is completed. This issue is further exacerbated because microcontroller vendors rarely, if ever, provide specifications that are derived from the exact same system-level stresses. So even at the onset of your system design, when you are selecting the appropriate microcontroller for the job, the variance on specification details makes the comparisons nearly impossible. This topic begs for industry standardization on performance and energy metrics. It also highlights the topic and issue of datasheet values versus real-world behavior. Both of these topics (and many more) are contained within the upcoming “Ultra-Low Power System Design Workshop” that will be delivered at the 2013 Embedded World Congress.
When designing a product to achieve an extended-battery life, the workload must be carefully analyzed, and you must fully comprehend what functions dominate the energy consumption. Furthermore, the operating periods (and even more important, the inactive periods) must be accounted for in the design – not just from the perspective of the duty cycle, but also with attention to the latency associated with the ramp-up time. By the way, the latter is a function of performance as well as wasted energy.
In trying to establish metrics for industry standardization on microcontroller performance and energy, we evaluated more than 200 (small battery) applications and determined that active operating mode differs significantly. The usage of microcontroller peripherals also varies significantly in these applications, although the majority of applications utilize a timer, and many a display.
Figure 1. The blood glucose meter is an example application requiring ultra-low power operation combining an advanced microcontroller and a digital display.
Although CoreMark has become a very popular benchmark to measure microcontroller performance and approximate the typical application workload, it completely dominates the run-time energy of an ultra-low power (ULP) device. To put this into context, the energy consumed by 16MHz microcontrollers running CoreMark at the rate of one iteration per second is the same order of magnitude of the simple function of analog-to-digital conversions (ADC) at a modest rate of 4kHz, but two orders of magnitude more energy than the real-time calendar update function.
| Device Type | CoreMark at 1 iteration/second | 4kHz ADC | Real Time Calendar |
| 16-bit | 34.2 Hours | 61.2 Hours | 29.5 Years |
| 32-bit | 58.9 Hours | 42.5 Hours | 11.2 Years |
| 32-bit | 46.6 Hours | 21.1 Hours | 8.7 Years |
Table 1. Battery-life time for various functions (CR2032-230mAh / 90% usable).
Table 1 compares the battery-life time for various functions running on three different microcontrollers. It points out that the real-time calendar function consumes significantly less energy than the CoreMark workload and the ADC. But it also shows that battery-life varies substantially depending on the device used, further complicating the system design choices. To summarize on this topic, EEMBC is developing a new industry standard for ultra-low power applications that will take these factors into consideration to ensure an appropriately balanced run-time and stand-by mode behavior.
In developing this standard, or perhaps even more importantly, developing your application, the energy measurement procedure must be carefully established for ultra-low power devices. The workload defined must be relevant to the intended application, and measurement of the energy must be taken at a high enough sampling frequency to enable comparison of processor features such as low power modes. An important point for ULP applications is that the workload includes not just the work that must be performed, but how often it is performed (this is based on the duty cycle). ULP applications also spend significant time in various low power modes, and the measurement methodology must account not only for the different modes, but also for the transition between different operating modes. Ideally, these energy measurements should at least allow you to visualize (and subsequently optimize) the performance and energy hotspots in your application program.
Figure 2. The current ramps up (green line) when the microcontroller begins executing code, coming out of it low-power mode.
Another topic of interest in this area of ultra-low power design relates to the capabilities of intelligent peripherals to offload the CPU. The goal here is to have the peripheral blocks function without waking the main processor core until its services are needed. For example, intelligent peripherals can collect data (i.e. ADC) into their memory buffers and in turn wake the CPU core when the buffer is full. Alternatively, a smart CAN peripheral can wake the CPU only when messages arrive that the CPU actually must handle. For example, in a system with multiple sensors and processors that divide the work, there may be many messages flowing on the CAN bus, but a specific controller may only need to analyze messages from a particular sensor that are identified by a specific CAN ID. In such an application, without a smart peripheral, the CPU will always be alive to process CAN traffic, where a smart CAN peripheral will enable the CPU to remain in sleep or other low power mode for most of the time.
All of these topics will be presented at the upcoming “Ultra-Low Power System Design Workshop” that will be delivered at the 2013 Embedded World Congress. Combining presentations and hands-on labs, the workshop will also train attendees on other topics such as optimizing code segments to minimize energy consumption, understanding the overabundance of MCU low-power modes, and architectural features for optimized power. Clearly, designing with low power and ultra-low power microcontrollers has become an extremely important topic for many embedded systems.
