Low‐power MCU benchmarking: what datasheets don’t tell you

The discussion of generating low power products started decades ago. Since then, the industrial engineering and scientific community have developed new energy sources, architectures, and integration technologies. Battery capacity and technology have been extended to deliver better components for ultra‐low power products. Semiconductor companies have developed energy aware microcontrollers, system architectures, and low‐power, low‐leakage process technologies. Low‐power integrated oscillators, sophisticated power management systems, and higher performing analog circuits enable more sophisticated solutions.

These advances and new software methods have enabled operating code with lower energy demand and/or more functionality at the same or reduced energy levels. In this article we discuss the advantages and traps of different implementations of ultra-low power. We discuss parameters of components and the relevance of proposed solutions, and conclude with an outlook on the future and trends of ultra‐low power advancement.

Introduction to ultra‐low power
Many articles and publications address low power consumption, but there are no agreed upon criteria defining low‐power systems and components such as software, embedded processors, single devices or device families. Also, there is no widely established method supporting low‐power or ultra‐low power benchmarking.

Presently, low‐power programmable processors are expected to operate in high and medium performance applications. Low‐power processors are in smart phone and tablet computers, deal with internet connectivity and AV‐streams, and are used in challenging industrial and automotive control. Low‐power programmable applications are dealing well with energy at high performance levels.

Compared to low‐power systems, ultra‐low power and MCU devices operate with restricted energy budgets and long operating times. The charge budget present for end‐user products is often much smaller than 1000mAh and the expected operating time is many years. Ultra‐low power applications optimize the total system energy performance and may manage the energy source, MCU device, life‐time environment and software, and system hardware. Energy efficiency involves much more than CPU architecture, the number of operating modes, and current parameters at room temperature.

Circuit aspects to get to ultra‐low power
Ultra‐low power MCUs have several operating modes in addition to individual enable and power‐on control capabilities. The digital portion of the microcontrollers use clock and power gating to reduce energy consumption. The power gating minimizes the leakage current while clock gating optimizes dynamic current consumption.

Datasheets and user guides reflect the individual implementations, which vary from vendor to vendor. They reflect current parameters for the different operating modes, and the user guides provide the system wake‐up conditions when returning from low‐power modes. This information also enables the user to identify all data and parameters to be saved and restored. Many sources discuss background operation; no software is executed but the MCU still executes functions and tasks required by the application.

Ultra‐low power
Ultra‐low power applications and MCUs are dealing with a restricted amount of energy. For further exploration, a CR2032 coin cell (Figure 1 ) is used with 230mAh @3V. A part of the coin cell’s energy is exhausted through self‐discharge; another part is not viable due to the increased source impedance near end‐of‐life. Both are assumed to take 20% of the capacity away.

Figure 1. At the heart of many ultra-low-power microcontroller designs is the familiar CR2032 battery cell used in many consumer and mobile electronics and wireless embedded devices.

The source impedance leads to increased voltage drop and prevents the full discharge, avoiding reset situations. Thus, the entire system has 184mAh for all hardware, code execution, and low‐power modes. 40% is used for the system hardware; the other 60% of energy is used for code execution and the real‐time clock mode.

The energy budget for executing code depends on the device and process technology. Calculating the available average current for executing code confirms that the temperature of the system or product has a significant influence on the ultra‐low power performance. One conclusion is that the architecture is important but the device specifications are more so – at least in ultra‐low power applications.The active or run mode
The majority of new MCU devicesbrought to market in the last few years are based on process nodes thatoperate at nominal voltage levels that are below the typical batteryvoltage levels. Such ultra‐low power devices usually have powermanagement systems integrated on the same die as the MCU system.

Operation at reduced voltage levels. The majority of the digital portions of MCUs operate at a fixed voltagelevel even if they can also operate at some lower voltage level. Someimplementations of MCU devices use variable voltage levels. But, doeslower operating voltage really reduce the energy consumption? Are thereconditions which reduce the energy consumption?

A review of MCUdevices shows that the gain in current consumption is up to 16%; thenumber of cycles that can be executed increases by 20%. Another resultof this consideration is that “execute the code as fast as possible” maynot always be energy efficient.

Code execution at highest system frequency. The power management, clock system, supply voltage supervision, andbrownout system take some DC current; they add DC energy consumption butonly some limited dynamic energy consumption. It turns out that someintegrated solutions operate with quite high DC energy levels. Suchintegrated solutions usually need to operate at the highest possiblesystem frequency.

Looking into real devices, some cannot executethe code without wait states. The challenge is to understand theparameters in datasheets and how to translate them and their operatingmodes into the functions the application will execute. The variation inenergy consumption can be huge. One device shows – if the datasheet hasbeen correctly translated – that the operating energy varies by a factorof 10+ between 1MHz and 24MHz executing the same cycles. The exampleshows that at 1MHz operation from Flash at an active time of 23ms about128uJ while operating at 24MHz, the energy consumption is down at about11.8uJ.

Execute code from RAM. Many publicationsmention that the code execution from RAM will reduce the currentconsumption. Examples derived from datasheets of two different devicesshow that the energy consumed by executing code out of RAM is only 80%to 60% compared to the energy consumed if the code is executed from thenon‐volatile memory. Usually, the efficiency goes up with increasedsystem frequency.

The drawback is that the software code residesin the non‐volatile memory and thus the entire system has to be set upto enable proper program execution from RAM before it can be used. It isa system aspect to ensure that the RAM contains correct data wheneverthe code is executed. But not only does the code have to be copied intothe RAM, it also has to be considered that any program discontinuity(jumps, branches, calls) are still working correctly ‐ includinginterrupt addresses.

Real-time clock (RTC). Thelow‐power mode widely used in ultra‐low power applications is thereal‐time clock calendar, operating all the time. In someimplementations this points to a counter/divider circuit, in others to areal‐time clock and calendar. Regarding energy consumption, the majoraspect is the performance of this function along with the operatingtemperature. RTC implementations consume current in the range of 300nAto 1.6uA at 25°C. The current increases to 1uA and up to 5.7uA in thereviewed examples at 85°C. The result indicates that up to three timesthe cycles can be executed when the process node is optimized forleakage at defined temperature range.

Considering some basic recommendations
Somebasic ideas on the subject of energy consumption are that lowering theoperating voltage reduces energy consumption, the wake‐up wastes energy,eliminating any cycle reduces the energy consumption. The mostimportant question is if the suggestion is really relevant. One exampleis the wake‐up time; this parameter is in the datasheet. Is there aparameter that gives a figure for the energy consumption?

Example: Simple temperature logger. A simple example on a temperature logger demonstrates how  “this savesenergy” may not be accurate in practical applications. It starts with anon-energy-aware solution and ends with an optimized solution usingdedicated device implementations. The energy consumption is improvedfrom ~200uJ via 39uJ down to 7uJ. This illustrates that the MCU deviceoptions and implementation details and a well‐engineered system can savea significant amount of energy. It also shows that the real‐time clockfunction is important in the energy consumption chain.

Summary and outlook
Poweroptimization and benchmarking in low‐power and especially inultra‐low-power applications need careful analysis of the energy profileand consideration of the way in which the options of the systemarchitecture, code efficiency, and device parameters support the entireenergy consumption.

Currently, under supervision of the EEMBCorganization, the major leading MCU vendors are developing a benchmark,starting with a basic functional benchmark. The process and systemarchitecture development proves that energy efficiency still can besignificantly improved. The benchmark activity also supports an energymonitoring circuit that is affordable and that meets the huge dynamicrange of the current consumption and timing requirements.

Horst Diewald ,Distinguished Member of Texas Instruments (www.ti.com )Technical Staff,is chief architect of MSP430 microcontrollers and chair of the EEMBCultra-low power working group. This paper was presented at the Spring2012 Embedded Systems Conference as part of a class (ESC-200) taught byhim.

2 thoughts on “Low‐power MCU benchmarking: what datasheets don’t tell you

  1. This is a very choppy article that is difficult to read. I'm not sure what the point of the article is. I didn't learn what the datasheets don't tell me – or if TI's datasheets do any better. I hope EEMBC does a lot better than this mess.

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.