Balancing memory performance and power consumption in IoT applications

July 03, 2017

reubenbenjamin-July 03, 2017

Two critical criteria for the selection of electronic components for IoT applications are power budget and performance. Ever since the beginning of electronics, there has been a tradeoff between these two – either you get the best power consumption or you get the highest performance. System architects have different requirements for different components in the system, based on the application. For example, a system may require a high performance controller but a low power memory. A typical case is a wearable device, where the controller needs to be powerful but as the SRAM is used as a scratchpad, it is expected to have the lowest possible power consumption.

Most systems fall into the following broad categories:

  1. Always On: These systems don’t have power consumption as a major criterion since they’re almost always powered by an uninterrupted power source. Such systems need the highest performance components possible, BOM budget permitting. Most devices that are plugged into a wall socket fall under this category.

  2. Battery Powered: These systems are at the other end of the power-performance spectrum. They are powered entirely by an on-board battery. Such systems tend to value power consumption above all else. Such systems also typically prioritize small form factor since they are usually portable. Examples systems include handheld devices we use daily.

  3. Battery-Backed Systems: These systems lie somewhere between an always on system and a battery powered system. They access external power sources but can lose access to their power supply. To avoid losing critical data during these power failures, system designers provide a small battery (typically a 240mAh coin cell) to backup critical functions like SRAM and the real-time clock (RTC). These systems usually prioritize high performance, but require that certain components be low power so that they can function solely on backup power.

There has been a technological reason for this tradeoff between performance and power consumption in SRAMs. Low-power SRAMs employ special GIDL (Gate-induced Drain Leakage) control techniques to control stand-by current and thus standby power consumption. Extra transistors are added in the pull-up or pull-down path, resulting in access delay increases and hence longer access times. With fast SRAMs, access time is the highest priority and such techniques cannot be used. Moreover, the transistors are scaled up in size to increase charge flow. This scaling-up reduces propagation delay but increases power consumption.

However, a wide range of applications are migrating wired always-on devices to battery-backed or battery powered mobile versions. This new generation of devices -- medical, handheld, consumer, communication, industrial –  are all driven by the IoT. They are revolutionizing the way devices function and communicate. For such devices, neither the components designed for high performance nor those for low power can meet design requirements. High performance components have high current consumption and thus drain the battery too quickly. Low-power components are not fast enough to handle the demands of these complex devices. There is a need for devices that are both high performance and low power. This is especially critical for memory since a system is truly only as fast as its slowest component, which in many cases is the external memory.

The need for lower power has affected microcontrollers first, forcing manufacturers to find alternatives to the traditional two operating modes - active and standby. This led companies like TI and NXP to introduce MCUs with a special low-power mode of operation called deep power down or deep sleep. These controllers run at full speed during normal operation but can drop into low-power modes when this performance is not required. These low power modes reduce power consumption without compromising high performance. Today’s controllers are capable of running at speeds above 100 MHz, significantly faster than previous generations of cutting-edge controllers. However just optimizing the controller in IoT devices isn’t sufficient to meet their stringent power budgets. During low-power mode, peripherals and memory devices are also expected to save power. The onus of power management has now shifted to memory devices interfaced to such systems.

Many portable systems execute code from Flash but use SRAMs as a cache to store results and initialization variables. Compared to other storage memories like DRAM and Flash, SRAM is limited in terms of density: the highest density SRAM available today is 8 MB, while DRAMs are available in multiples of GBs. However, it is difficult for an MCU to interface directly with a DRAM or Flash as these memories typically have long write cycles and are unable to keep pace with the MCU. Moreover, DRAMs have high power consumption due to their refresh cycles. An MCU that operates at high speed needs a cache that can store critical data and execute calculations quickly without a significant power penalty. SRAM is the best fit to act as a cache between the MCU and the storage memory.

SRAMs alternate between active and standby states, with the data expected to be non-volatile when the power goes off. These SRAMs are battery-backed, usually by a single coin battery. Such systems pose unusual challenges for the SRAM. As long as the system is active, they require the highest performance SRAM they can get, since it serves as a high-speed cache in these applications. However, they also need low power consumption in case the system has to switch to battery power.

On power failure, the SRAM is switched to the on-board battery and is disabled by the supervisor chip. The system can remain in this mode for as long as the battery lasts. Once the board power supply resumes, the supervisor chip will gradually power the SRAM with the board supply. Typically, these chips take between 1 and 10 ms for the transition. This time doesn’t hinder the system as the controller also requires time to come out of it power-on-reset routine. Refer to Design Recommendations for Battery Backed SRAMs to learn more specific implementation details.

Continue reading on page two >>


< Previous
Page 1 of 2
Next >

Loading comments...