Energy consumption in modern microcontroller systems, part 4: MCU datasheets, operation modes, controllbits, and more
March 06, 2018
Story
Supplier?s marketing statements in datasheets are sometimes hard to verify with the detailed data.
Energy consumption comparison of microcontroller/system on chip (MCU/SoC) systems – is one benchmark enough or do we need a parametric benchmark?
An important factor in the selection, market positioning, and success of a product is the energy consumption of the entire system. The traditional approach to measuring this is to express efficiency in microampere (µA) or microwatts per megahertz (µW/MHz), but this isn’t sufficient enough anymore. Energy storage systems store neither µA nor µW but Joules, which simply means energy. Comparing the energy usage of MCU/SoC devices therefore has become the prime focus of users.
Is one benchmark enough to select an MCU, an MCU family, or an entire MCU manufacturer? Are publicly available technical documents enough? How easy is it to choose the right vendor for your application?
- Part 1: A benchmark for ultra-low-power: The ULPBench-Core Profile
- Part 2: The ULPBench-Core Profile, EEMBC documents, and MCU datasheets
- Part 3: The impact of operating temperature on energy consumption
- Part 4: MCU datasheets: Operation modes, control bits, registers, current, and mode transfer parameters
Previous articles looked at the content of supplier’s datasheets. Datasheets are available in their latest revision on the web, but unfortunately not in their previous revision. Not having stored the initial revision at the start of design gives misleading results regarding calculated energy consumption. Supplier’s marketing statements in datasheets are sometimes hard to verify with the detailed data. If we want to choose the best MCU based on energy efficiency, we have several options:
- Results from benchmarks like ULPBench von EEMBC
- Articles which publish MCU application measurements
- All sorts of documents provided by the MCU supplier
- Public articles in technical trade magazines, congresses or forums.
ULPBench results from EEMBC
The ULPBench delivers basic statements about energy consumption. A RUN-Mode and RTC-Mode get executed over a period of one second with 50 ppm precision. The tested devices don’t need to meet supplier’s typical data.
Each application that goes beyond this basic definition can deliver consumption data that will negatively impact the EEMark-Ranking. Here are three examples:
- Switching losses between power modes and necessary code to switch
- Peripherals, in particular digital functions with high data throughput and analog functions such as ADC/DAC/amplifier, etc.
- Limited for switching between modes and the constraints of sequences; intermediate modes may be used going from the actual to the target mode.
All three mentioned conditions have no effect on the results by the first benchmark from EEMBC.
The MCU suppliers provide a number of different documents for their products. We limit ourselves on functional descriptions, electrical characterization data, and application oriented documentation. Software examples and development tools will not be covered here.
In Figure 1, all pages are summarized which mention operation modes and changes to assure safe operation.
[Figure 1 | Enormous amount of data are presented to the user to achieve energy efficient operation. Only one MCU family out of the entire portfolio is considered.]
Usually, less than a dozen power modes are published; getting the best power mode for any application function should be easy. The published data is contrary to what the few power modes suggest. In any power mode and mode change process, it is mandatory to secure a safe and energy efficient operation:
- The operating voltage and frequency usually cover different areas
- Instructions and power mode control bits
- External components such as an inductor in DC-DC operation
- Several ON/OFF words and bits; Power gating of internal power supplies, allowed sequences, and necessary timings.
- Clock generation, routing, and ON/OFF switching.
All pages are excluded which determine following configurations, functions and operation modes:
- Interrupt and "exception" handling
- Memory-conditions like wait state, data retention in memory (SRAM retention), etc.
- Memory protection/MMU configuration etc.
- Operation/power mode during debug mode
- Peripheral functions such as enable/disable, power/performance configuration, and change conditions
- Saving and re-configuration of functions
Most system architectures use the smallest common denominator for operating conditions. This means, for example, the acknowledgement and execution of a task like an interrupt request will be executed in a relatively high-performance power mode. This uses the operating voltage and frequency that has been most recently selected. A more appropriate operation mode requires executing additional software, which adds another demand on energy and execution time, loosing energy and performance.
Figure 1 also indicates the need for in-depth learning of available literature. The implementation with clock and power gating requires a thorough planning of numerous oscillators and operating voltages together with its control, instructions, and electrical characteristics. In addition, the dynamic operation mode transfer conditions are important and not all energy levels are directly attainable from the actual operating mode.
[Figure 2 | Via TI SLAA657A. The figure suggests zero, one or two intermediate steps are necessary to change from one mode (LDO/DC-DC und LF128KHz) to another one. Other conditions, such as latency, are not mentioned, but essential in the system planning. In figure above only the active mode transitions are shown. Transitions between operating-/low-power modes are not comprised.
The electrical characteristics are representing the static state conditions; they represent settled conditions only. Transient and start-up losses are not mentioned in datasheets. Best case, you’ll find advice in application notes.
For the STM32L476 (EEMark=153) you can calculate, based on the datasheet, a wakeup energy of ~0.1 uJ at 1700 uA@2 us/3 V. The ULPBench-CP software and hardware measures an energy consumption of 6.66 uJ. At a period of one second you can ignore the wakeup energy. But if the workload is distributed over 100 cycles the “wakeup” energy (10,2uJ) is significantly larger than the “workload” energy of 6.56 uJ. In other words, the energy to switch operation modes becomes a huge factor when you increase the number of cycles. Also, frequent changes between energy save modes and RUN modes can result in different “best” lower power modes depending on the actual wake-up period. A SiLabs example shows this.
[Figure 3 | Via SiLabs, 2013-11-25 - AN0027_Rev1.03; Power consumption for periodic wake-up from EM2 vs EM4. The report suggests that Energy Mode 4 offers the lowest current consumption, no full retention, thus requiring the device to go through a reset cycle when waking up. This reset cycle requires significantly longer time than a wake-up from EM2 or EM3.]
The transition between all different energy modes is not possible for all available combinations. See one example from NXP/Qualcomm’s Kinetis-MCUs.
[Figure 4 | Via NXP, AN4503: Power Management for Kinetis MCUs, Rev. 2, 04/2015. Not every mode is reachable from every other mode.]
As you can see in Figure 4, the mode HSRUN can only be reached from RUN-mode, by software not by hardware mode modification. Also, every "low power" mode can only be left to the RUN-mode. As there is no exception mentioned in the documents, you can assume every event or interrupt needs to be executed either in RUN-mode or "very low power RUN"-mode or needs a different mode that must be selected through software. That means you always return to a "power hungry" RUN/VLPR mode.
Those transitions between modes have time/clock conditions that range from nanoseconds to microseconds. It is interesting to compare those transition times with execution times on ULPBench. Execution time on ULPBench range from 0.4 to 2 milliseconds. The necessary clock cycles are in the range of 10000 to 23000. This clearly confirms the need for a smarter way to reconfigure a MCU and make changing operation modes a seamless and fast solution.
Where are we today?
We introduced an approach to compare MCU/SoC energy consumptions with each other. The EEMBC-organization has started it with a first step: the benchmark ULPBench. For energy-sensitive products there are more investigations necessary to verify and select a MCU/SoC-family.
A user can impact the energy demand in standby and active RUN mode through smart and dense software code, but not through semiconductor process selection or chip design. The roots for temperature dependent energy consumption are user independent. Best case the user can – together with the MCU supplier – optimize the dynamic energy consumption with advanced methods to manage comprehensive operation modes. Figure 1 shows how many documents and lengthy descriptions the industry offers to the customers to explain best possible energy consumption. Always selecting the best power mode and keeping the system constantly in safe operating conditions is a challenge. Exemplarily, the information in Figure 2 and Figure 4 show the limits in changing operation modes. The future strategy is to shorten switching cycles between modes, avoid them, or make them easier.
Quo Vadis, where are we heading?
The increased number of operation mode changes represents a challenge. We have seen a large number of information and their combinations have to be understood in order to realize a low energy system. It is a significant effort to achieve the most optimal solution. A smarter management of operation modes is a solution. Those solutions exist, but need to be adapted. A clear and easy structure to manage operation modes would make lives of both hardware and software designers much easier. Maintenance, product enhancements, and backward compatibility are yet more arguments for comprehensive operation modes.
The safe operation and secure modes set another huge challenge and a stronger demand for real lowest-energy modes at such safe operation and secure mode environment. Mainly basic hardware and software solutions are discussed – energy demand is out of the focus in those discussions. The IoT environment needs, in many aspects, the combination of both safe, secure, and energy-optimized embedded systems.
ProJoule GmbH
