Demystifying ultra-low-power benchmarks for microcontrollers
What defines an ultra-low-power (ULP) microcontroller (MCU)? Is power a sub-section of system design or the most important consideration? How can applications fit more functions into reduced energy budgets?
These are some common questions embedded developers encounter when trying to define and drive requirements for their low-energy applications. Being ‘energy aware’; encompasses all aspects of the microcontroller ecosystem starting with MCU architecture and extending across the spectrum of peripheral interconnects and system standby capabilities. This begs the question: What quick, effective and impartial tools can developers use to compare devices, architectures and solutions based on their specific application profile?
With the goal of answering this question in mind, the Embedded Microprocessor Benchmark Consortium (EEMBC) consortium has formed a working group to define and establish a new benchmark that is focused on ultra-low-power applications. Understandably, the first question to solve was ‘how to define the term ‘ultra-low-power’? While this term has broad-reaching implications based on the type of application, the consortium saw fit to limit the scope to MCUs that focus on applications running from batteries or similar power sources for an extended period of time.
A new ultra-low-power benchmark called ULPBench covers a wide variety of applications with the use of a set of commonly used ‘profiles’ that are generated and bundled into the benchmark suite. The first phase of this benchmark suite, called CoreProfile, is now available and can be used to benchmark MCUs targeted for ULP application segments that use a typical peripheral set comprising, at a minimum; real-time clock (RTC), RAM and non-volatile memory in combination with the CPU.
Requirements for profiling ultra-low-power applications
When defining ULP benchmarks one of the first hurdles to cross is the wide variances in microcontroller implementations. The CPU, in most cases, is not the most critical component as it is typically abstracted by C-compilers capable of generating highly optimised code. It is failry simple to port benchmark code between architectures if uses take care of some basic rules, such as only using ANSI C and using the data-type definitions in the the C99 standard for variables. This standard defines the bit-width with a fixed value and not based on the architecture as per Table 1.
Table1. Variable size depending on CPU architecture
However, in many applications, the CPU is not the only significant energy user. The peripherals and the system architecture can contribute significantly to the total energy consumption. This makes it harder to create a processor-agnostic benchmark since peripherals vary widely between microcontroller vendors and also between multiple platforms from the same vendor. Benchmark code must therefore be developed in a manner that allows for flexibility and easy adoption or integration into any microcontroller system. The benchmark code must also work to establish a higher-level function set for a ULP application without favouring a specific functionality provided by ‘niche’ MCUs.
Following the CPU and peripherals, the next important power contributor is the frequency at which the MCU wakes up from standby modes. It is a logical assumption that MCUs that focus on lowering their energy profile ensure that the ON duty cycle is kept as low as possible while spending a large portion of time in standby. However this needs to be balanced with the real-time needs of the system. For example, the systems may have a calendar function that needs to update every second. Another example to consider is industrial sensors requiring a collection of ADC samples at a rate of 1 ksps, following which the data is evaluated and processed. Some applications, on the other hand, may wake up every 10+ seconds or may only be on for a minute a day. Since it is not efficient to cover all duty cycles and corner cases, the ULPBench benchmark used a 1 second wake up interval. This interval serves the purpose of providing a reasonable power-down time while also incorporating the energy budget required in moving the system in and out of power-saving modes. The energy budget during wakeup is not always specified directly in MCU datasheets and is therefore a useful part of the benchmark evaluation.
Figure 1. Application wakeup frequency over time
EEMBC ULPBench Phase 1: CoreProfile
As explained in the introduction, due to the wide variance in complexity of ULP applications, the benchmark suite is being built in several developmental phases. The first phase, CoreProfile, covers the CPU, memory access, real-time clock and power-saving features. CoreProfile is applicable to a large number of applications and provides a valuable means to compare various MCUs.
In CoreProfile, the defined base rule states that a ULP application needs to be able to run off one CR2032 battery [with capacity of 225 mAh] for more than four years. The typical application profile has at least one active phase per second and performs predefined tasks in this active phase.
The MCU’s hardware requirements to run CoreProfile are as follows:
– CPU, RAM, non-volatile program memory
– RTC timer/counter for one second wake-up interrupt
– 32kHz oscillator for RTC
– Reset circuit for proper startup
– Power supply range that includes 3V
The CoreProfile benchmark has two modes. The first is active mode where the CPU performs a predefined set of functions. The second is the power-saving mode where the CPU remains in standby and the RTC wakes up the CPU once per second to re-run the predefined task.
This workload, executed once per second, consists of the following functions:
– Array writes: Data processing, for example, in a lookup table format is very commonly used
– Permutation function and a simple 8-bit data sort (Bubble Sort): Any data received by the MCU needs to be analysed, sorted and processed. The sorting algorithm represents various types of data handling.
– Simple filter using 8- or 16-bit mathematics: Mathematical functions are required in almost all parts of the code execution to evaluate data, but are also needed for pointer processing. In this code block, several mathematical functions are processed in 8-bit and 16-bit modes and a simple linear approximation filter works with 32-bit data. Float and complex mathematical functions are not implemented since these will be covered in a separate profile at a later phase.
– Simple state machine: Most applications use one or more state machines to control the software flow.
– Thread Event Switch (TES): The underlying software below the benchmark profile is called TES. This is a simple thread and task switch. This system enables the benchmark to grow over time and to integrate more profiles on the same software layer. This piece of software is responsible for executing the workload once per second after receiving a trigger signal from the RTC module or function.
Measuring the benchmark scores is simplified using the dedicated EnergyMonitor tool shown in Figure 2.
Figure 2: Screenshot of the ULPBench GUI and EnergyMonitor tool running a test. The measured energy for one capture window is shown in the Graph (running CoreProfile)
Selecting an MCU based on the ULPBench Benchmark
The ULPBench benchmark will provide a set of profiles orientated towards various real-world applications. Based on these profiles, users can identify and scale their application requirements and analyse the amount of energy the target application can be expected to consume for a given microcontroller.
When profiling TI’s ultra-low-power MSP430 family of microcontrollers, a considerable variance in the benchmark score can be observed when executing CoreProfile. These variations in the ULPBench score are driven by various factors which influence the energy consumption while executing the specified task, but also from the capability to save energy during the power saving phase and the transitions in-between.
Some other factors that can impact the score are memory size (and the associated load on the address and data bus), process technology and supply rail (digital core powered by widely varying supply rail vs. LDO regulated voltage).
Figure 3: ULPBench CoreProfile Scores comparing different MSP430 flash- and FRAM-based microcontrollers
As seen from the Figure 3, the MSP430FR5969 MCU (Figure 4), based on TI’s ultra-low-leakage FRAM process technology using the intelligent power management system, provides a very compelling ULPBench CoreProfile score that proves its intrinsic ability to meet the strictest energy budgets across a wide variety of applications.
Figure 4: Block Diagram of TI’s ultra-low-power MSP430FR5969 FRAM MCU.
ULPBench benefits
ULPBench is the first comprehensive benchmark that allows developers to use an impartial method to compare various ultra-low-power microcontrollers based on the energy consumption during the real-time execution of a predefined task. Any MCU vendor can provide the benchmark ported to their specific MCU architecture and also provide best practices to optimise their code for achieving the best results. Vendors can also provide hardware (e.g. peripheral) and software (e.g. compiler) settings used in the process of benchmarking. Developers can thus save time and effort spent in understanding energy optimisation methods and simply use the ULPBench code provided by vendors as the ‘golden standard’ for lowest energy consumption. This helps the MCU evaluation process become faster, more portable, more efficient and unbiased.
Additionally, if required, different workloads can be added with very little effort and the tests re-run to observe the energy impact. The EnergyMonitor tool and GUI can be used across all evaluation hardware platforms to obtain the EEMBC ULPBench score.
Future ULPBench profiles
As already mentioned, the CoreProfile is the first phase in a suite of benchmark profiles for ultra-low-power applications. The second phase, called PeripheralProfile will add specific peripheral accesses and functionalities to the energy benchmark suite. This profile will cover ADC conversions, PWM generation, SPI communication and RTC functionality. Following this, profiles for more advanced data processing as required for filtering and analogue signal evaluation and for components of the Internet of Things (IoT) are in discussion.
Why does ULPBench use ‘energy’ instead of ‘current’?
There are many parameters that can be used to measure and compare power consumption in applications. Each presents a different viewpoint for evaluation:
Current: Current is easy to measure with a current meter, but the tool is required to detect and measure a very high dynamic range over several decades (i.e. from several tens of mA down to some hundreds of nA) with a reasonable accuracy to ensure a good comparison. This implies that the current measured and displayed needs to be an average current over at least a second including any peaks that could happen during the power mode transitions. This means that an expensive and high-end current meter will be required.
Power: Power measurement is a function of current and voltage. When using batteries, the voltage rail drops over time or with the amount of current used up from the battery. For MCUs, the required current is normally also dependent on the voltage.
Energy: The parameter ‘energy’ accumulates the power used over time. Energy is hence most ideally suited when evaluating the lifetime of a ULP application or that of an energy-harvested system. Hence the ULPBench suite uses “energy” as the metric for comparison.
It is EEMBC’s intention that ULPBench helps developers evaluate and select the MCU that is ideal for their ULP application in the quickest and most cost efficient manner. The EEMBC ULPMark score in combination with the energy profile provided by ULPBench can significantly help narrow down the top contenders among a growing list of ULP microcontrollers. For more information on the ULPBench benchmark and the Energy Monitor Tool refer to;
EEMBC; www.eembc.org/benchmark/ulp_sl.php
About the author
Stefan Schauer is a member group technical staff (MGTS), at Texas Instruments.