The functionality of an edge node can be described by four characteristics (Figure 1). One characteristic is the type of transducer it uses to convert real world information to electrical signals, and vice versa (e.g., temperature, pressure, blood chemistry, or brain waves). Another way to characterize an edge node is by the interfaces it uses to connect the transducers and the processor or microcontroller (MCU), for example using SPI/I2C, GPIO, PWM, or ADC/DAC. The functionality of the edge node is also described by the processing required to adapt the transducer information to the network, and vice versa (e.g., encryption, compression, error correction, protocol stack, and data analysis). Lastly, the edge node can be described by its communication mechanism and the protocol used to send or receive information between the thing and the network (i.e., a wired or wireless communications channel).

Categorizing edge nodes

Edge nodes can be grouped more or less arbitrarily according to their application domain. For example, home automation encompasses anything that is used to control or monitor home or office systems and devices, such as lighting or environmental control, or appliances (e.g. freezer, washing machine, coffee maker, fire alarm). On the other hand, “wearable” or “portable” is anything that is worn or carried on the person while in use. Examples include smart watches, smart glasses, heart rate monitors, pedometers, GPS tracking devices, blood sugar monitors, music or video players, and wireless headsets or microphones. There are also categories for health, environmental, and of course the traditional machine-to-machine (M2M) applications. There is a considerable degree of overlap between categories, for example a heart-rate monitor falls in both the “health” and “wearable” domains.

Many edge nodes, especially in the “wearable” domain, are ultra-low-power (ULP) applications. These applications are characterized as battery-powered, with short, occasional periods of activity interspersed with long periods of inactivity, and possibly infrequent human intervention. Ultra-low power highlights energy efficiency as a key performance criterion for such devices, and dictates battery lives of weeks, months, years, or even decades.

ULP MCUs for IoT applications

Now that you’ve digested all the acronyms of this section’s subhead, recall from our previous discussion that many “things” living on the edge must utilize ULP MCUs to handle user interfaces, collect and transmit sensor data, provide security functions, and manage other tasks. One issue that ”thing” designers face is determining if these MCUs are optimized to meet their application’s performance and efficiency requirements to enable the long battery lives that are expected.

Ultra-low power implies different things to different applications. In some cases, the lowest active current is required when the power source is severely limited (e.g., energy harvesting). Alternatively, the lowest sleep current is required when the system spends most of its time in standby or sleep mode, waking up infrequently (periodically or asynchronously) to process some task. Furthermore, ULP can also imply great energy efficiency whereby the most work is performed in a limited time period. Overall, the application will require a combination of or tradeoffs on all of the above.

There are many factors that enable an MCU to earn its ULP title. One factor is the type and degree of intelligence available through an MCU’s peripherals. For example, peripherals such as SPI, GPIO, PWM, and ADC that we mentioned earlier, if designed correctly by the vendor, can significantly help offload the CPU and thereby allow the device to spend more time in sleep mode. There’s also a trend moving from 8- and 16-bit CPUs towards 32-bit CPUs to help achieve quicker execution of the active mode tasks. The quicker a task is executed the less energy is consumed because the energy wasted due to static currents is proportional to the time spent in active mode, whereas the useful energy spent in executing the task is more or less a constant value.

Other factors that help yield an ULP MCU include choices of physical IP, low-leakage process nodes, and low-power memory technologies. Using smaller geometries reduces active power due to smaller gate capacitance and lower operating voltages, but tends to increase leakage current when the clock is stopped. For this reason, power gating becomes more important at smaller geometries.

Also from a chip design standpoint, a vendor can implement various forms of gating. Clock gating automatically switches off clock signals to various blocks of circuitry whenever possible. Even more effective is power gating, which switches off power to blocks inside the chip when possible. Even further energy efficiency can be achieved by the use of state retention power gating (SRPG), whereby power is switched off to most logic blocks inside the chip with the status of the digital circuits held in retention elements.

One of the biggest factors affecting energy efficiency is the use of low supply voltages. Since power is proportional to the square of the voltage, moving from 3V to 1.5V gives a fourfold reduction in energy, all other things being equal. High efficiency step-down regulators allow this even if the battery voltage is much higher.he use
of lowgn ncy n conjunction with high efficiency step-down regulatorsaease
leakage current in sleep m

IoT designers beware of datasheet parameters

While datasheet parameters are typically accurate and essential for anyone doing a system design, one must take care when using these parameters to analyze and compare different devices (this includes MCUs and just about everything else). Vendors tend to utilize different specifications when quantifying parameters. For an MCU, for example, what workload should be used when performing the power analysis? The workload could be something as simple as a few lines of code running a “while (1)” loop, or something a bit more real world.

Some vendors are moving towards using the EEMBC CoreMark benchmark as the standard workload for power and/or energy measurement. In general, CoreMark is sufficient for low-power MCUs, but for ULP it’s going to go off the charts. In an experiment, the life time of a CR2032-230 mAh / 90 percent usable battery was calculated running CoreMark at 16 MHz and 1 iteration per second. On the 32-bit MCUs used, the battery life time came out to 46-59 hours, compared to the MCU’s real-time calendar function that would operate between 9-11 years – this represents a several orders of magnitude difference.

However, a smaller workload than CoreMark would be required to determine ULP energy efficiency, and furthermore CoreMark only applies to active mode power without taking into account the fact that most ULP applications spend a large amount of time in idle mode with the processor stopped. Besides the workload determination, what should the conditions and physical setup be for the device under test? What duty cycles should be used to represent the transitions from an active to low-power state? How should the clock source be utilized? Should the workload run from flash or RAM? What is the input voltage? All of these details must be specified and utilized by all vendors in order to allow a system designer to make apples-to-apples comparisons.

For the benefit of designers of things and other ULP applications

Deriving an industry-standard benchmark for energy efficiency powering ULP devices is far more complex than a straight-up performance benchmark. At a minimum, all questions in the preceding paragraph must be answered, but the toughest challenge is getting all vendors to agree on a consistent methodology. With the hard work and determination of representatives from Analog Devices, ARM, Atmel, Cypress, Freescale, Microchip, Renesas, Silicon Labs, Spansion, STMicroelectronics, and Texas Instruments, EEMBC established the ULPBench, a benchmark that provides a consistent method for measuring energy efficiency demonstrating both active power and idle (sleep) power states.

In addition to establishing the run rules and operating environment, the group also realized that for ULPBench to proliferate an accurate energy measuring tool in the sub-$100 price range was needed. Although most MCU vendors in the ULP domain have integrated proprietary tools for measuring power into their evaluation/development boards, there is still no commonly agreed upon method. To accommodate this need, the EEMBC produced EnergyMonitor, a USB-powered voltage/current supply for the target device under test. It connects to a target device through a 100 mm, 2-pin header, and can measure the energy consumption of literally anything running on 3V up to 28 mA. The intended application of the EnergyMonitor is to measure MCU energy consumption, but it can also be used to measure energy consumed by sensors or other components used in IoT applications. However, most importantly, it integrates directly with EEMBC ULPBench to provide a standardized method for measuring energy consumption (Figure 2).

The MCU vendors are creating ULPBench in phases. Phase 1 – called the Core Profile – focuses on energy consumed by the core as well as the automatic wakeup function. Phase 2 and all subsequent phases will focus on more of the system integration, including the use of various peripherals. With the Core Profile, the workload consumes 10,000-20,000 CPU cycles during each duty cycle depending on the efficiency of the MCU’s architecture. The device uses a low-power timer to wake up the MCU once per second to perform the workload (as seen by the staircase effect in Figure 2).

Quantifying data sheet numbers

ULPBench is definitely a step in the right direction for establishing consistent rules for specifying energy values in datasheets. The user must still look carefully at the exact details. For example, the duty cycle (the length of time spent in active mode versus the time spent in idle mode) of the application must be compared to that of ULPBench. If the application wakes up often or for long periods of time then the active mode energy will dominate, and, conversely, if the application wakes up infrequently and briefly then the idle mode energy will dominate. In such cases, the ULPBench score could be misleading, since it tries to achieve a balance between active mode and idle mode energy.

Additionally, the user should look at what low-power mode was enabled (this will be a balance between the lowest energy state and the latency or time required to transition to active mode). Since a significant portion of the energy is consumed during the active mode of the test, it’s best to use workload code that is compiled for maximum performance (minimizing the active cycles). Ideally, results will be shown for multiple compilers and compile options.

ULPBench is available free with the purchase of EnergyMonitor, enabling users to run tests themselves and even post the results on EEMBC. This will open the community of developers of ULP applications as the number of IoT applications continues to shatter expectations and estimates and challenge engineers and management to create products that rise above the hype and generate real value. To meet the forecasts of 10 to 20 billion nodes in the next several years, developers need to understand and address obstacles such as extended battery life and efficient designs. The energy consumption of MCUs varies tremendously, so choose carefully – a few extra μJ per second can mean the difference between one year and 10 years of battery life.

Markus Levy is president of EEMBC.

Mark Wallis is a system architect, microcontroller applications at STMicroelectronics.

EEMBC

www.eembc.org

@eembc_org

LinkedIn

STMicroelectronics

www.st.com

@ST_World

LinkedIn

Facebook

Google+

YouTube