Power Management--Making Every Electron Count

Re-focusing the SoC for Energy Optimization

Minimizing power consumption in SoCs involves more than just sleep modes. Often, hardware-assisted techniques can save CPU cycles and reduce power consumption.


  • Page 1 of 1
    Bookmark and Share

Article Media

Power consumption has become a major concern to users of system-on-chip (SoC) devices. Although they offer excellent cost-performance features thanks to the use of high-integration processes, energy usage has not followed such an advantageous curve. The key problem is that many SoC designs have not taken full advantage of the improvements in energy efficiency that have been made possible by the use of finer geometry processes.

The prevalent SoC methodology in use was developed primarily for IC design productivity. SoCs are rarely designed from scratch but are assembled from pre-existing intellectual property (IP) cores. This form of design reuse allows the use of tried and tested circuitry that can be applied almost as easily as placing components on a virtual printed circuit board (PCB). 

Although an SoC designer has the reassurance that a reused block has passed a series of stringent tests, each block will have been designed under a set of engineering assumptions that may not apply so readily to a new process technology. For example, a block design first implemented ten years ago may use clock gating to reduce active power consumption—the primary concern when that design was initiated—but that will do little to conserve energy when the block is idle.

Although designers of low-power SoCs will favor semiconductor processes that do not exhibit large amounts of substrate leakage, any core that is powered up for a long period of time will waste a comparatively large amount of energy. The best way to reduce that leakage energy is to power down the core whenever possible – this optimization lies at the heart of many low-energy SoCs and microcontrollers. This has led to the retrofitting of power-gating circuitry to the cores employed in low-power SoCs (Figure 1).

Figure 1
Simply adding new blocks to a microcontroller cannot remedy all power issues. The peripherals and gating structure must also be changed to achieve energy efficiency as a whole.

A Holistic View of Power

Simply powering-down cores when they are not needed does not necessarily provide the most energy-efficient architecture. What is important is the way in which functional blocks are combined and controlled. 

Low-power engineering is an exercise in thinking out of the box; it is not best implemented by treating an SoC design simply as a collection of hardware components combined with software. Low-energy design demands a combination of software, hardware and application understanding in which tradeoffs are made between flexible software-based processing and hardware. Even subtle changes to hardware implementation can make large differences to overall energy consumption.

For the holistic approach to work, design reuse moves to the architectural level. Optimized implementations are then generated from this architecture based on the requirements of the target applications and the available processes. This rethinking of design reuse, which makes it possible to migrate functionality between the hardware and software domains, results in drastic improvement in energy efficiency. 

Take, for example, the implementation of support for typical sensing applications on Energy Micro’s EFM32 Gecko series of microcontrollers. Since the introduction of the Apple iPhone, consumer device makers have recognized the advantages of incorporating capacitive touch into their products to provide more responsive and intuitive user interfaces. However, these sensors generally demand a large amount of processing to be carried out in software running on a general-purpose processor. This can be difficult to optimize for power without considering the problem at the system level first.

In a typical capacitive-sensor implementation, the sensor circuit includes a free-running RC oscillator. This generates a changing excitation voltage at a more or less constant frequency. When the user’s finger approaches the sensor, the overall frequency of the circuit will change because the capacitance within the sensor element increases. Usually, software detects this change in frequency using a counter. If the counter value after a fixed period of time drops significantly from the nominal value, the algorithm will register that as a touch event. 

The problem with this implementation is that the processor core needs to be active during the sensor reading process. It will normally set a timer to count down to zero and during that time count how many positive swings the touch-sensor oscillator has generated.

In a user-interface application, the sensing subsystem has no idea when the next contact will be made by the user. The host microcontroller can sleep periodically with the expectation that, in the context of a processor core running at several megahertz, a comparatively large number of clock cycles will complete between touch events. However, longer sleep periods will negatively affect responsiveness. Some touches may not be registered correctly until the system has fully woken up and put itself into a state that allows it to take accurate measurements.

It would be more energy efficient to perform these operations in hardware and only wake the processor core once a touch event has been registered. A processor spends most of its energy supplying instructions and data to the execution units rather than performing the computations themselves. Researchers working on the Stanford University ELM low-power processor project concluded that instruction supply alone was responsible for 42 per cent of total processor power consumption. Dedicated hardware does not incur such a large amount of overhead. 

In the case of a capacitive-sensing subsystem, it is possible to build a circuit that periodically excites the oscillator, sets a timer and then counts the number of pulses before the timer expires. At the end of the process, if the counter value is below a set minimum, it can raise an interrupt that wakes the processor. In this implementation, there is no need for the processor to wake up periodically unless there are other management functions to handle. The processor and its software will only be active when they have work to do, which reduces power consumption to the minimum level possible based on user activity.

Hardware Assist to Save Power

Including support for other sensing applications can inform the design of a more general-purpose hardware-assist unit for the main processor. For example, low-cost inductive sensors present a problem similar to capacitive touch panels in terms of power consumption. Inductive sensors are used as proximity switches giving a simple on-off output indicating whether a conductive target is present or not.

Inductive proximity sensors detect magnetic loss due to induced current generated on a conductive surface or target by an external magnetic field. When an AC current is applied to a coil, it generates an AC magnetic field. If a conductive target approaches the sensor, it generates currents, also known as eddy currents, on the sensed object due to the alternating magnetic field.

Every time energy is transferred between the two circuit elements, losses occur that will decay the oscillations. This damping process happens more quickly, however, if a metallic object is near the coil. By detecting this change in decay, a sensing algorithm can determine whether an object is within range of the sensor. This is normally performed by reading the change in voltage at regular intervals and comparing it to a reference voltage. If the input voltage falls below this reference, the algorithm can trigger a proximity event.

 As is the case for capacitive sensing, a software implementation requires that the processor be awake to generate the excitation signal and process the ADC inputs. In the case of a flow metering for water or gas utilities, it can be hard to determine how often the processor needs to wake up to be sure of registering all turns of the impeller. The supply may not be used for long periods, which will mean the processor core is waking up to find there is no useful input to process.

Moving the sensing circuitry into hardware can greatly reduce the energy consumption of the system;however, the hardware components needed to perform inductive sensing are subtly different from those needed for capacitive sensing. Many of the same features, such as DAC, are present to provide an excitation signal and timers and counters to define the measurement periods, but the inductive sensor calls for an additional ADC and requires that the individual components be wired in a different way.

The commonality between the two types of sensor interfaces can be exploited by careful design of a hardware subsystem; the key is recognizing that the primary changes lie in how the individual hardware components such as ADCs, DACs, counters and timers are connected to each other and the way in which the software sensing algorithms are usually composed. The algorithms are primarily state based and move between states based on certain properties being true, such as the count value being less than a certain value after timer expiration or the ADC input being below a certain threshold before the timer expires.

These conditions can be monitored and controlled by a state machine. A problem with many programmable state machines is that they can only act on and trigger a fixed set of outputs when they move from state to state. In LESENSE, a Low Energy Sensor Interface, system states and the conditions used to select them are programmed through descriptors that can be chained together to form relatively complex operations where needed. It is possible to build quite complex logic before intervention need be sought from the processor core (Figure 2).

Figure 2
LESENSE block for autonomous operation and monitoring of up to 16 inductive, resistive and capacitive sensors. LESENSE makes it possible to create highly efficient and long lasting sensor applications, only using the CPU when necessary.

For example, a metering application that may, using a software-intensive implementation, operate with a duty cycle in which the processor is awake for 2 percent of the time. If the processor runs at 10MHz and is rated at 200µA/MHz with a deep-sleep consumption of 2µA, it will be able to run for close to seven years on a pair of AA cells. If the use of hardware support cuts that cycle to 1 percent, battery life can be extended to almost 13 years.

By looking at the combination of hardware and software that can be implemented in a processor-based system as a whole—and by moving functions between them—it is possible to ensure that the full flexibility of software is only called upon when necessary. The overall behavior of the application at the system level remains the same—allowing reuse of the overall framework—but differences in the implementation architecture make it possible to optimize the solution on a given target for minimum power (Figure 3).

Figure 3
Coupled with an Advanced Energy Monitoring (AEM) enabled development kit, the free energyAware Profiler will correlate instant peaks in power with the C code that caused the problem.

Architectural reuse coupled with implementation optimization is enabled through the use of software tools. Active feedback on energy consumption is a major feature of the Simplicity Studio that is realized in the energyAware Profiler. This tool takes the embedded development suite beyond its conventional use as a code-writing and debugging environment. In energy-sensitive applications, you can conceivably remove all the bugs from a design and still have a system that does not meet its most crucial target: its energy budget.

The Profiler makes it possible to analyze the code in a system not just for its functionality but its energy consumption—providing engineers with a tool to help determine which functions are consuming the most power and  guide whether some functions should be devolved to hardware, either for implementation in a peripheral, such as LESENSE, or restructured to allow the processor core to sleep for longer periods of time.

By rethinking the way in which the blocks employed within SoCs are designed and realized, the experience at Energy Micro has shown it is possible to achieve major savings in power consumption. Further savings will come from greater insight into applications and how they are organized at the system level.  

Energy Micro
Oslo, Norway
+47 23 00 98 00