Energy consumption in modern microcontroller systems
April 18, 2017
by Horst Diewald, ProJoule GmbH Is there a strategy that can be applied to both IP-based and standard semiconductor products that will allow device us...
by Horst Diewald, ProJoule GmbH
Is there a strategy that can be applied to both IP-based and standard semiconductor products that will allow device users to control energy consumption in a manner that is simple and reliable, that will give the user full visibility into operation, and that can maintain safe and secure conditions? Improved results can come with an increased degree of control of operating modes.
No matter what the area of application, a key factor today in achieving market success with an electronic system is minimizing its energy demand. The traditional approach of expressing a component’s efficiency in terms of current or steady-state power – microAmperes (µA) or microWatts (µW) per MHz seems to not work anymore. Energy storage systems hold neither µA nor µW, they store “Joules” – in other words, energy. The latest generation of ultra-low-energy efficient MCUs follows a similar power management strategy to that of high performance processors; they use a DC/DC converter in combination with linear regulators.
An interesting question is, can the same power provision methods be used across a wide range of applications without adding to the energy consumption through features in the software? Can the user refine the design from the application level to achieve optimal system energy consumption? Is an energy-profile-optimized application possible and can it be properly maintained, extended and adjusted during development and in the field?
Energy consumption can be aligned to system targets once the application is well defined. There are well-understood methods to achieve the required level of control in a design. This is quite simple assuming only a static environment at room temperature; published MCU datasheets provide data for a wide variety of different situations. MCU vendors provide more than 150 different current parameters for many different scenarios and conditions.
Rapidly-increasing demands for increased memory for program code and data is one of the drivers to the shift to smaller process geometries. This provides lower energy consumption in active modes (RUN modes). However, energy demand for devices that continue to run during sleep modes increases significantly due to unwanted leakage currents. This effect is significant at room temperature and can be severe at higher temperatures.
Early developments of consumer electronics using silicon built in smaller process geometries revealed the impact of the influence of voltage and temperature on the energy budget. Power gating, voltage, and frequency scaling have been developed to cope with these factors. Such techniques have become standard in MCU/SoCs for low-power consumption. But questions remain for the systems designer:
- Which methods and guidelines are used by the vendor, and which guidelines are important in my application environment? Do they match?
- Which operation modes have the optimum impact on energy consumption?
The first factor is the duration (time spent) in a particular energy mode, considering the contribution of each mode to the total energy consumed – and the dynamic switching conditions:
- Operating mode (1) has a direct influence on energy consumption – functions and code are being executed.
- Sleep mode (2) has its own characteristic level energy consumption – function and code are halted and need an external event to get restarted.
- Both modes (1 and 2) contribute to energy consumption – operating mode and sleep mode both contribute to energy use.
- Switching conditions of non-on/off switchable functions
[Figure 1 | The EEMBC Energy-Benchmark has two phases.]
In the widely-used EEMBC Energy Benchmark (basic sequence shown in Figure 1) Operating mode (1 – active/run) executes defined code. The users select the operation mode, e.g. Voltage regulation by LDO or DC/DC, operational frequency, etc. They can choose the lowest energy-using mode for their application. The real-time clock function (RTC/RTCC) with a 32-kHz quartz or oscillator is active and represents the second part of energy consumption. The period is one second. The benchmark measures energy consumption rather than current consumption. Future generations of this benchmark will also add a factor to account for switching losses. The operation mode dominates the energy consumption in current MCU/SoCs; for the most part the higher operating current is compensated by shorter execution time. In a period of one second the switching losses don’t play a major role. However, this aspect of switching losses – the red hatched areas on the graph in Figure 1 – are assuming ever-greater significance.
[Figure 2 | Basic power gating]
Basic power gating
Figure 2 depicts the basic principle of power gating. Turning off parts of the circuitry should reduce leakage current losses. Those unwanted currents discharge capacitances in the circuitry: the higher the temperature, the faster they discharge. These capacitances are of parasitic as well as integrated nature. They restrict voltage drops due to current peaks to a safe level. When power gating is implemented, the dynamic energy consumption worsens and the switching conditions further add to unproductive energy loss. In many operating situations power supplies are turned on and off in parallel to power gating. This increases still more the unproductive dynamic and switching losses.
Which operation condition has the most positive effect on energy consumption? The second factor that must be considered is the system environment such as energy source, temperature or temperature profile.
The energy source provides regulation to the operating voltage, e.g. by means of a linear regulator or DC/DC converter. In small scale MCUs usually only one regulator is used at a time but in high performance systems (multi-core-SoCs) multiple power supplies operate simultaneously.
The temperature profile needs to be considered when energy losses, e.g. leakage currents, account for a major part of the energy consumption. This can happen in all three operation modes.
Options open to the MCU/SoC user
The different functions of the operation modes are usually managed by some form of power manager. This is true of both the initial settings and the transitions between different energy modes. Operation modes are established based on internal system partitioning and design, and the resulting behavior of the MCU/SoC hardware.
The resulting operation modes provided in currently existing generations of low power blocks are invoked basically through instructions, and energy-mode bits and data; as well as control bits and control data as set by the user. Additionally, software library elements, for example APIs, may be offered. These features result in application-oriented, energy efficient systems and products, but with possibly limited scope.
Dream and reality
In many applications and product lines from a company, multiple components from different MCU/SoC providers are employed to achieve maximum performance and application life time, together with a range of energy sources. These devices’ energy modes and functionalities are directly activated by instructions and control bits/data. Is it possible to achieve direct access to control both functionality and energy modes, by means of features embedded within the software code? Access to different modes could also be secured by only being accessible by a supervisory-mode through a central program such as the operating system or a power manager. Restricted access provides safe operation through mode changes that take the system into critical operating conditions. Software defined energy situations are flexible; but from an energy perspective, software solutions that frequently change operation modes are not optimal. Each code execution uses (activates) major parts of the MCU/SoC hardware, with corresponding energy demand.
Protection against unwanted access in MCUs/SoCs is still a major objective, but has yet to be fully realized. It still needs software. Applications with interrupt or event-driven situations that do not involve code execution are not covered. Each software execution needs energy as they activate major hardware blocks such as main memory, bus system, code execution in a kernel and so forth.
[Figure 3 | Energy profile; frequent change between energy modes let switching currents become a major energy loss (red area). Simply, it consumes energy without benefit for the application. If, in addition, software is used to switch modes (scenario 1c) it increases the waste of energy.]
In real life, a user wants to decide his/her operation mode. The hardware provider defines basic modes and the user then designs his/her own operation modes and uses them (how, when, where, etc.). Also, these operation modes are stored at a defined place, can be edited or not, and there is even the possibility to add new customer defined operation modes. Operating modes can be dedicated, protected, and assigned to defined hard- and software portions. Furthermore, the same modes can be used during interrupts without any software support (which reduces energy demand).
Usually, defined operation modes describe the static, settled modes such as Run, Idle, etc. The method proposed here additionally manages the process of mode changes, respecting the various dynamic behaviours and includes safe transition from sourced to target mode. Safe transition needs to include a safe response (e.g. to an error handler) if such transition cannot be executed, or is only partially executed – when a safe status is also essential.
An operation mode including power management is dependent on data, not fixed to a vendor-only defined behaviour or vendor-only defined control data and bits. Parameters, which are depending on an application, can be stored as data. Should the external conditions change, only the content of the data will change, not the user code.
[Figure 4 | Effect on energy profile of applying the controlled operating mode strategy.]
The necessary operation mode can be executed with the lowest possible energy consumption, as in a sleep mode. The difference is that major switching losses are avoided! Modes can be changed without software involvement; for example, frequency of the operation mode is adjusted to the available energy source (such as a Low Power LDO).
Conclusion
Operation modes can organize the operation of a given system architecture, and not only the power- or energy modes. The system architecture controls the cooperation of different functional blocks including the dynamical aspects of the operation modes (e.g. their response to supply variations, settling conditions, etc.) as well as the change from one mode to the other. The transfer between modes becomes determined by parameter and can safely align to new requirements without changing the operation mode manager.
Safe operation parameters can be part of the operation mode data. Parameters, which assign the ownership of all or parts of the operation mode data, are also part of the data. Additionally, as the operation mode data may be located in memory they can be protected using, for example, well-known MMU methods. One example is that such data, belonging to an application or a portion of it, can be located in the same encapsulated memory as the program code and data. Supporting the generation of operation mode data sets, including the verification of safe operation, can be supported by advanced tool sets.
