Posts Tagged ‘top-story’

Next Page »

Low-Density Serial Flash Is Back—and IoT’s the Reason

Friday, August 4th, 2017

Low power and enhanced system performance fuel a re-emergence.

For the past decade, we have seen an abundance of systems employing off-the-shelf MCU devices with embedded flash. However, as designers now try to future proof their applications by enhancing performance, reducing power consumption, and extending battery life, several new challenges have emerged.

Amazon Echo, Google Home, and many other home hubs, media controllers, and building/home automation controllers are beginning to have a significant impact on our lives. These technologies bring with them new protocols and standards. Designers want to add this new functionality to their applications in the form of Over-the-Air (OTA) updates. This requires larger firmware images for these new applications to retain compatibility, functionality, and interoperability. These enhanced applications need more memory space and often exceed the flash and RAM resources on the embedded MCU. OTA capabilities require extra memory to store the additional firmware code and must support up to three of four complete firmware images: factory default image, current image and the new downloaded image ready to be shadowed to the internal MCU flash. OTA updates must happen easily, reliably, securely, safely, and autonomously.

Figure 1: New edge nodes need OTA update capability, local data storage, and system flexibility. (Courtesy Adesto Technologies)

Figure 1: New edge nodes need OTA update capability, local data storage, and system flexibility. (Courtesy Adesto Technologies)

So what about the MCUs? As MCU vendors scale to smaller geometries, the size and cost of embedded flash pose problems of their own. Larger density flash embedded inside the MCU can often increase cost while reducing performance and/or increasing power consumption. Even with the latest MCUs, engineers are wondering when they will again run out of memory. We have already seen the first of a new generation of flash-less MCU devices this year: MCU vendors abandoned embedded flash and moved to a more cost-effective, higher-performance MCU-only solution.

Modern day IoT application challenges have brought about an increased demand for low-density serial flash. This is all happening while the market enters a phase of supply shortages, capacity restrictions, and a rash of portfolio-wide end-of-life notifications. An MCU used inside a smart sensor, smart door lock, or other IoT edge node device with 256Kbit to 8Mbit of embedded flash will typically need between 1Mbit and 32Mbit of external flash to provide external OTA capability.

Standard serial flash devices have been available for decades, but evolution has focused on achieving higher density, higher performance, and lower cost. Designers often select the external memory device as a last resort when it is evident they need a larger MCU with more flash; this last-minute decision comes at higher cost, with a new PCB layout and complete new code image. Alternatively, designers choose to include an external memory to allow expansion of the current system to support the new features and requirements.

At Odds
It can be argued that the current range of serial flash solutions are often at odds with application demands. The serial flash devices today have architectures suited to high read performance and lower cost, while power consumption and programming flexibility are sacrificed. Adding these memory devices substantially increases power consumption, reduces the battery life, increases MCU overheads, reduces system performance, and often exceeds the embedded SRAM resources required to temporarily support the external flash during OTA programming and updates.

Figure 2: New protocols and standards are arriving in the wake of new home hubs, media controllers, and building/home automation controllers. [Courtesy Adesto Technologies]

Figure 2: New protocols and standards are arriving in the wake of new home hubs, media controllers, and building/home automation controllers. (Courtesy Adesto Technologies)

Factors such as system security are also impacted. This is due to the need to erase and reprogram large blocks of data, the inability to permanently protect factory code images and the generic un-personalized nature of the commodity memory devices—all of which can lead to vulnerabilities in the device trust chain. In addition, components such as voltage regulators may be required to ensure correct operation.

The latest generation of low-density memory devices have architectures and features optimized to address many IoT device and edge node application demands.

  • Wide Voltage Range Operation
    • Devices that support a wide operating voltage (e.g., 1.65V to 4.4V) that matches the VCC range of the host MCU to eliminate the need for additional voltage regulation and maximize battery life.
  • Optimized Operating Power
    • Read and programming current is optimized to improve energy consumption and to further maximize battery life.
  • Ultra-Low-Power Standby Power Consumption
    • Devices that have a user command driven by ultra-low standby power consumption at under 100 Nano amps negate the need to switch the power supply to the memory device and conserve power when the memory is not being used, saving on further external components and MCU GPIO pins.
  • OTA optimized and Data Storage Small Page Program and Erase Structure
    • Small page erase capability allows code updates as small as 256Bytes to be erased and programmed with minimal MCU over heads, while improving performance and reducing update time.
  • Serial EEPROM Emulation Capabilities
    • A byte write/byte erase capability that does not require large block erase and considerable MCU resources to manage it allows simple data and system configuration to be updated a few bytes at a time.
  • One Time Programmable Lockable Secure Sectors
    • One-time-programmable sector locking capability to protect critical code and factory code images.
  • Intelligent MCU-Friendly Active Memory interface
    • Features that allow the MCU to sleep and reduce system power whilst the memory is programming or erasing. The memory device becomes an active peripheral device that generates its own interrupt signal when a process or operation is completed, negating the need for the memory to wake up, test, or poll the memory for status, or run an inefficient fixed delay loop counter for each programming or erase operation.
  • Enhanced Command Rich Serial Memory Interface
    • A rich command set reducing the MCU overheads, such as a single command that acts as both an erase and buffer program in a single operation, versus having to issue an erase command, wait and monitor the erase operation, before issuing and monitoring the programming command. This saves on MCU overheads and execution time and improves system performance and battery life.
  • On-Chip User Accessible Security Numbers
    • Memory devices that contain user accessible unique identity numbers to allow the device to be integrated into a system trust chain of components for enhanced security.
  • Flexible SRAM Buffers
    • Flexible SRAM buffers inside the memory device that can be read from as well as used in the traditional programming-only mode, allowing data and code storage to be loaded directly to the SRAM buffer and read back or modified later. These R/W SRAM memory buffers can even be used as extended scratch pad space to supplement the embedded SRAM and stack space on the MCU.

Low Density, High Interest
The rise of new IoT applications is introducing new demands and driving a resurgence of interest in low-density memory. Many of these devices are battery powered and need to be Amazon Alexa or Google Home compatible. To keep pace with evolving and growing standards all of these new edge nodes require OTA update capability, local data storage, and system flexibility. Having a low-power memory that forces the MCU to burn more energy to manage the memory is a false economy. The latest Adesto Serial Memory product options provide intelligent, MCU-friendly features to reduce overheads, improve security options, increase device flexibility, improve performance, enhance energy consumption, and extend battery life. The memory device is a critical component in any modern system, and can now be treated as an intelligent system peripheral that works autonomously with the MCU rather than just a simple memory storage solution that is a slave to the host MCU.

IMG_1270Paul Hill is Senior Director of Product Marketing for Santa Clara, CA-based Adesto Technologies. Adesto (NASDAQ:IOTS) is a leading provider of application-specific, ultra-low power, smart non-volatile memory products. Contact Paul at

Cooler, Safer Smart Home Hub: What a Difference a Diode Makes

Thursday, June 22nd, 2017

Steps taken to solve high forward voltage drop and high reverse leakage current issues.

Your customer has successfully launched a new smart home hub with a design that wirelessly controls door locks, lights, thermostats, audio, and electrical appliances, all while sending notifications to the homeowner. The soap-bar sized gadget (Figure 1, lower left corner), powered by a wall adapter, is packed with electronics and includes backup batteries in case of a power outage. However, the sleek design is pushing the device’s thermal limit, and now the customer is concerned that the heat generated by the hub may become a problem, compromising the product’s success. The customer asks for help to seamlessly reduce the heat generated without compromising the overall design. This design solution will examine the best option for addressing this issue.

Figure 1: Smart Home Hub

Figure 1: Smart Home Hub

Power Management Implementation
Figure 2 shows a diagram of the customer’s current smart hub system. It’s powered by a 5V wall adapter and has a non-rechargeable backup battery. Three AA alkaline batteries (1.5V x 3, 2Ah) support the 200mA average load and the always-on buck converter outputs a nominal 2.5V. The radio communicates with home appliances equipped with wireless protocols such as Z-Wave™ and ZigBee™. The Ethernet connection ensures exchange of notifications and events with the cloud, but the device will still work locally provided there is power.

Figure 2: Your Customer’s Smart Hub System

Figure 2: Your Customer’s Smart Hub System

The active and passive components of the smart hub’s power circuit are shown in Figure 3. The two diodes are housed in an SOT23-3 (2.6mm x 3mm) package, outlined in red.

Figure 3: Smart Hub Power Circuit Footprint (46mm2)

Figure 3: Smart Hub Power Circuit Footprint (46mm2)

Design Shortcomings
An initial thermal design analysis shows that the always-on buck regulator is operating quite efficiently. So, the focus quickly turns to the two Schottky diodes. At 200mA, these diodes develop a 600mV voltage drop, dissipating 120mW. The power delivered to the load is 2.5V x 0.2A = 500mW. This means that the diode adds a 24% power dissipation overhead.

Another concern in using Schottky diodes is leakage. In normal operation, the diode connected to the alkaline battery is reverse-biased, dumping a current of about 1µA into the load, with the leakage increasing over temperature. This leakage effectively acts like a trickle charge of the battery for an inordinately long time until a power outage comes along to discharge the battery. The problem is that these are non-rechargeable batteries that carry a warning, “If recharged they may explode or leak and cause burn injury.” This is not what we intended for the customer.

What are the Options?
Clearly, it’s critical to drastically reduce the power dissipation. One option is to use a low RDSON n-channel DMOS-based solution such as the one shown in Figure 4. The diodes intrinsic to the MOSFETs are indicated with dashed lines. In this configuration, the control IC biases the GATE according to the voltage sensed across the MOSFET. A positive source-to-drain voltage turns the MOSFET “on” with current flowing in reverse mode (source to drain). A negative source-to-drain voltage turns the MOSFET “off,” with the intrinsic diode reverse-biased. This solution requires two MOSFETS and two control ICs, making it bulky and expensive. This is a drastic solution that would require the redesign of the entire PCB.

Figure 4: A Discrete Solution to the Diode OR-ing Problem

Figure 4: A Discrete Solution to the Diode OR-ing Problem

The best solution would be a small, diode with dramatically lower losses than a Schottky diode and no or minimal reverse current. Fortunately for your customer, such a device is available.

An Ultra-Tiny, Micropower, 1A Ideal Diode with Ultra-Low Voltage Drop
Based on a low RDSON p-channel DMOS, the MAX40200 diode (Figure 5) drops a voltage about an order of magnitude lower than that of Schottky diodes. The internal circuitry senses the MOSFET drain-to-source voltage and, in addition to driving the gate, keeps the body diode reverse-biased. This additional step allows the device to behave like a true open switch when EN is pulled low, or when hitting its thermal limit. A positive drain-to-source voltage turns the MOSFET “on,” with current flowing in normal mode while the body diode is reverse-biased. A negative drain-to-source voltage turns the MOSFET “off,” with the intrinsic diode again reverse-biased. If EN is low then the device is ‘off’ independently of the VDD-OUT polarity.

Figure 5: Ideal Diode Functional Diagram

Figure 5: Ideal Diode Functional Diagram

When forward-biased and enabled, the MAX40200 conducts with less than 100mV of voltage drop while carrying currents as high as 1A. The typical voltage drop is 43mV at 500mA, with the voltage drop increasing linearly at higher currents. Figure 6 shows the ideal diode’s forward voltage vs. forward current and temperature. The MAX40200 thermally protects itself and any downstream circuitry from overtemperature conditions. It operates from a supply voltage of 1.5V to 5.5V and is housed in a tiny, 0.73mm x 0.73mm, 4-bump wafer-level package (WLP).

Figure 6: Ideal Diode Forward Voltage

Figure 6: Ideal Diode Forward Voltage

The tiny MAX40200 WLP package is about one order of magnitude smaller than the SOT23-3 housing the two Schottky diodes in Figure 3. Two MAX40200s fit easily in place of the SOT23-3 position on the PCB with additional room to spare. The MAX40200 application footprint is shown in Figure 7.

Figure 7: Integrated Smart Hub Power Solution with Two MAX40200s

Figure 7: Integrated Smart Hub Power Solution with Two MAX40200s

With a 20mV drop at 200mA, the device consumes only 20mV x 200mA = 4mW of power, greatly reducing the thermal load. Additionally, the MAX40200 reverse leakage current is mostly from Cathode/OUT to ground, while the Anode/VDD reverse current is practically null (Figure 8). This effectively eliminates the unwanted trickle charge of the non-rechargeable battery. The MAX40200-based solution, easily and quickly implemented by the relieved customer, solves both the heat and leakage problems in the smart home hub device.

Figure 8: Leakage Current Into VDD

Figure 8: Leakage Current Into VDD

We discussed the constraints of a smart hub’s power management system in the context of a customer problem case study. The customer’s smart hub had severe problems directly related to the classic shortcomings of Schottky diodes, namely the high forward voltage drop and high reverse leakage current caused by these diodes. The smart home hub generated too much heat and the reverse leakage current was unwittingly trickle-charging the non-rechargeable battery. To address this, two MAX40200 diodes were used to seamlessly replace the two Schottky diodes with little modification of the PCB. This practically eliminated the leakage current into the battery and reduced the power dissipation overhead by a factor of thirty, making for a happy, satisfied customer.

Nazzareno-Rossetti_2017Nazzareno (Reno) Rossetti, Principal Marketing Writer at Maxim Integrated, is a seasoned Analog and Power Management professional, a published author and holds several patents in this field. He holds a doctorate in Electrical Engineering from Politecnico di Torino, Italy.

Steve-Logan---800x600_smaller-fileSteve Logan is an executive business manager at Maxim Integrated, overseeing the company’s signal chain product line. Steve joined Maxim in 2013 and has more than 15 years of semiconductor industry experience, both in business management and applications engineering roles. Steve holds a BSEE degree from San Jose State University.

Fully Customizable Gateway SoC Platform Targets Wide Variety of IoT Applications

Wednesday, April 19th, 2017

How the design methods used to develop an IoT Gateway SoC with a customizable platform can reduce risk, schedule, and costs.

A gateway device plays a critical role in the Internet of Things (IoT) by collecting data from the sensors located at the network edge. It then filters, analyzes, and normalizes the data, and sends it to the cloud for sharing with the network. Designing a gateway SoC from scratch is a challenge that involves not only developing the SoC architecture, software, and hardware, but managing the integration and validation as well. These activities take a significant amount of time and require the involvement of a large design team, which results in longer design cycles and longer time-to-market. There are a variety of applications where these gateways are used, such as surveillance, deep learning, artificial intelligence, data storage, data security and more. Designing a custom SoC for each application from scratch is not a viable solution. Designing a single SoC for all the applications is also not feasible due to the huge investment, risk, and time consumption.

Gateway SoC design is greatly simplified when a gateway platform is utilized. A gateway reference platform offers a modular design that is fully customizable to enable multiple solutions on a single gateway SoC. This helps in reducing system BOM cost and speeding time-to-market. The reference platform approach enables efficient hardware and software partitioning, custom IP integration, and device software development during custom SoC development. The key to creating cost effective custom silicon for the IoT is the platform approach because it reduces risk, schedule, and cost.

A gateway SoC may be a simple device that captures the data from various slow-speed peripherals, then packs the data and sends it through low- to medium-speed peripherals to the cloud. The gateway SoC can also be a complex device that captures data from different high- and low-speed interfaces, performs pre- and post-processing of data, performs analytics, and then sends the resulting data to the cloud through high-speed interfaces. To build a gateway SoC suitable for different applications, it is important to perform partitioning of the silicon such that the simple gateway device is a subset of a complex gateway SoC. An intelligent approach is to keep the simple gateway SoC design as a basic building block and add other IP blocks to create complex gateway SoC variants. However, adding multiple application-specific IPs into a single SoC will increase cost, since each IP is expensive. Also, if an application does not use an IP, then the IP will be redundant for that SoC.

A gateway SoC needs to be validated for functionality, and this is achieved using a platform approach. All the IPs that need to be part of a simple gateway design are carefully selected such that the same IPs can be seamlessly reused in complex gateway designs. The fastest way to develop a gateway SoC is to use different pre-silicon design methodology platforms—including RTL, virtual, and FPGA platforms. By using these pre-silicon methodology platforms, the design can be verified in simulation. In addition, the software stack can be developed on the virtual prototyping platform, and the end use case application can be tested with real peripheral devices and software for functionality on the FPGA platform.

Software drivers are developed and tested along with RTL verification, so the bring-up effort on software development is greatly reduced. The FPGA prototyping platform aids the designer to test the design with real-life peripheral components or devices and check the functionality of the end product or design. This approach significantly boosts the confidence of the designer and the success rate of first-time working silicon at tape out.

Figure 1 shows the pre-silicon methodology platforms for successful IoT gateway SoC design.

Once the design is verified on pre-silicon methodology platforms and taped out for fabrication, the design team can ready for silicon bring-up by enhancing the software and designing the bring-up board. This increases the efficiency of the design team, consumes less design time, and reduces design errors.

During the gateway SoC design, the design team can create multiple designs for various end applications, retaining common core blocks and adding newer blocks to create additional variants that result in new silicon parts for different applications in a short amount of time.

Figure 1: Gateway SoC Design Platforms

Figure 1: Gateway SoC Design Platforms

The key advantages of using gateway SoC platforms is that the block, which is considered as core block, can be verified, and the software drivers can be written and used as the core library. New application-specific IPs can be seamlessly integrated with the verified core library and used to create new gateway SoC designs. By adding new test cases and designing new daughter cards for application-specific IPs, the validation of new designs can be performed faster, resulting in less design effort and minimal risk.

Figure 2 shows an example of a Gateway SoC consisting of generic and application-specific IP sections.

Figure 2: IoT Gateway SoC Partition

Figure 2: IoT Gateway SoC Partition

A sample IoT gateway SoC consists of two partitions, one with a generic IP section and the second consisting of an application-specific IP section. The generic IP section consists of IP blocks that are common across applications. Some of these are processor complex, DDR3/4 and flash memories, high speed peripherals, such as PCIe/USB/SATA, and low speed peripherals, such as SPI/I2C/UART/CAN/Timers.

The IPs in a generic IP section are carefully selected and verified on pre-silicon methodology platforms. In an FPGA platform, the daughter card is designed and contains all the peripherals required in the end application, and the design is verified close to the end application.

Figure 3. Custom SoC-Based Smart City IoT Gateway Reference Board

Figure 3. Custom SoC-Based Smart City IoT Gateway Reference Board

Once the generic IP section design is verified, different variants of the gateway SoC can be designed by adding application-specific IPs to the generic IP section based on end applications. The design with new IPs integrated is verified on the pre-silicon methodology platforms. An add-on daughter card with specific peripheral devices can be designed to validate the newly added application-specific IPs. Several SoCs can be designed in parallel for different applications. This will reduce time-to-market, minimize bugs in the design, and lower overall design cost.

Case Study

The gateway SoC methodology platforms were utilized in an IoT gateway custom SoC design. The SoC is intended to be used for IoT gateways in smart city applications. Figure 3 shows the smart city IoT gateway reference board built around the custom SoC. The gateway is a full featured device that supports various types of wireless and wireline connectivity, communicates with IoT edge devices, and connects to the cloud through 3G/LTE/WiFi.

Figure 4. IoT Gateway SoC Platform Software Features

Figure 4. IoT Gateway SoC Platform Software Features


It will be industry best practice to utilize the IoT SoC platform approach, as detailed above, to design custom SoCs for various IoT applications with reduced risk, schedule, and cost.

Naveen-HN Naveen HN is an Engineering Manager for Open-Silicon. He oversees board design, post-silicon validation and system architecture. He also facilitates Open-Silicon’s SerDes Technology Center of Excellence and is instrumental in the company’s strategic initiatives. Naveen is an active participant in the IoT for Smart City Task Force, which is an industry body that defines IoT requirements for smart cities in India.

How Richer Content is Reshaping Mobile Design

Tuesday, March 29th, 2016

Low- and mid-phone memory demand is heating up more rapidly than ever, but with 3D NAND, things are looking (and stacking) up.

Editor’s Note: When Intel and Micron together announced the availability of a NAND technology that tripled capacity compared to other solutions, the two firms pointed to “mobile consumer devices” as among the beneficiaries of the storage breakthrough. Flash forward to March of this year, when Micron’s Mike Rayfield, VP and GM of the company’s Mobile Business Unit, shared the Mobile World Live “How Richer Content is Reshaping Mobile Design” webinar stage with Ben Bajarin, Principal Analyst, Global Consumer Tech, Creative Strategies and moderator Steve Costello, Senior Editor, Mobile World Live. Following are selected edited excerpts from the webinar transcript, with organizational text, figures and captions.

Mike Rayfield, Micron

Mike Rayfield, Micron

Mike Rayfield: [In making] observations at Mobile World Congress this year, I [saw] three things:

1. The content for mobile devices is getting a lot richer. Whether it’s driven by the coming 5G pipes being a lot thicker to push a lot more data or whether it’s high resolution content or virtual reality. But, clearly the richness of data has put a huge strain on the mobile handset and what it’s got to be able to do.

2. [IoT] things are hubbed to your smartphone. And what we’re seeing is it’s becoming a much more important device.

3. One or two billion people don’t have a computer, don’t have a phone, and don’t have access to the Internet. There are now devices, full functionality devices that can be acquired by those folks for well under a hundred dollars that are going to allow them to have that first computer, make that first phone call and surf the Internet. Mobile devices, while they’re important to us now, are getting even more important and are going to become important to folks that will own them in the very near future.

Smartphone as Primary Computer

Ben Bajarin, Creative Strategies

Ben Bajarin, Creative Strategies

Ben Bajarin: So much of the component landscape and innovation from smartphones is driving other sectors. If you look back to the 90s and early 2000s era of the PC, you’d see [that PC] components, (SoCs, memory screens), drove other elements of different industries. And now we’re seeing that same thing play out in smartphones’ [components and innovation] driving the IoT. And those same products are moving to cars. Those same products are moving to virtual reality.

The smartphone, for most of the world, is not just their only computer, but even in developed markets it is their primary computer. That has huge implications on how it’s used, on engagement levels, all the way across the board to new opportunities in software and services.

Rayfield: If you think about mobile device design, the things that it cares about are performance, energy efficiency and footprint. Networking and cloud, enterprise, IoT, automotive—all of those things care about those same three things.

Figure 1: The requirements for memory in each of these areas are critical, accelerating and evolving.

Figure 1: The requirements for memory in each of these areas are critical, accelerating and evolving.

The mobile device is also now becoming a creator of content. That pushes a staggering amount of bandwidth onto the network, [forcing] the network to be more robust and higher performance. It forces more storage onto the cloud—we all want to back things up. And mobile is the reference design for automotive and IoT. All of this innovation we do, whether it be in performance, footprint or energy efficiency in mobile, is touching all of the other different markets. [It] is something that has just started to happen in the past couple of years and is going to accelerate.

Bajarin: Mobile is the catalyst for new things. Things we haven’t even thought of yet. Virtual reality is just one example of those things we weren’t talking a lot about, and now we’re talking very distinctly about how the mobile ecosystem drives the experience. That’s the emphasis of smartphones now and that whole ecosystem—driving all of these other peripheral markets. When we looked just at some usage behaviors, where we’re going in the next generation, 5G, most people are going to consume more and more and more bandwidth (Figure 1).

Burden on Memory Grows

Rayfield: Even a couple of years ago the average [handset] device had 1 GB or less of DRAM. And it was relatively small. It had 4 or 8 GB of NAND. As these devices have become your mobile computer, the burden on the memory has become significantly larger. Flagship devices on average have about 3 GB of DRAM (Figure 2) and we’re working with partners in China where they’re already working on 6 GB DRAM devices.

Figure 2: Low-end and mid-end phone memory demand is accelerating faster than ever before due to the shift to full smartphone capabilities.

Figure 2: Low-end and mid-end phone memory demand is accelerating faster than ever before due to the shift to full smartphone capabilities.

Consumers figured out more is better, and not only because it’s a larger number but because they see a difference in performance.

Everybody has talked about the idea that the cloud is going to replace local storage. The reality is we’re just too impatient for that. Connectivity is not ubiquitous by any means, and ultimately we want our pictures, we want our videos, we want our movies on our phone.

Advances in NAND have allowed us to go from 32 to 64 to 128 GB of local storage, and I see that just continuing. I do a sort of a sample size of my kids and I look at their devices. They’ve got a smartphone with 64 GB NAND and there’s about 8 GB of free storage whenever I look at it. We’re going to continue to go in that direction.

Bajarin: One of the trends that we’re looking at particularly, not just in developed markets, but also as we look more at emerging markets, is: What’s the role cloud services are going to play? If I’m thinking about increasing the capacity of what I can do on a device, and I want to move that to other products to be backed up etc., looking at how many people do this today.

In consumer research, we found that 75 percent of consumers are yet to invest in cloud services [invest meaning] pay for something—pay for iCloud, pay for Dropbox, pay for cloud storage as part of a solution.

[…] local storage is still playing a huge role. […]you’re starting to see increase again in capture. [Consider those] on Snapchat making short videos of their day. Posting them to their stories. Sometimes that’s archived, sometimes it’s not. And dual camera is something you’re going to hear a lot about this year from the component landscape.

[You’ll be able to]  take a 45-plus megapixel picture, [have] multi-range zoom, change the focal length, record two videos: one in slow motion and one in fast motion. We’re talking about a tremendous amount of file storage there. Even if everyone was pervasively subscribing to the cloud today, [consider] how much back-end infrastructure [is needed] to take all that’s being created. There are still some innovations in smartphone cycles, dual camera being one of them, which will put very significant demands on the capabilities of those products.

Mobile to Smart

Rayfield: There are 1-2 billion people that we really haven’t touched with mobile devices yet (Figure 3). Only a couple of years ago, it was assumed that those folks would buy a 20/30/50 dollar feature phone, which ultimately had very little capabilities, just the ability to make a phone call. Clearly, that wasn’t a very interesting market. If you can now look at devices that are well under 100 dollars that are full computers, that give them the ability to access the Internet, that give them the ability to make phone calls, give them the ability to have a computer, I think it changes the landscape a lot even over what we were seeing a couple of years ago.

Figure 3: Smartphone installed base per population.

Figure 3: Smartphone installed base per population.

I’ve seen three examples of phones that are well under 100 dollars (Figure 4). And they’re full functioning computers. They have 1 GB of DRAM, and 4, 8 or 16 GB of NAND, and they have great cameras and high-performance processors. Literally, these are devices that a couple of years ago would’ve been $400, $500 or $600. I think that’s a tipping point that has infrastructure folks putting better infrastructure in developing countries. That is going to open up this huge opportunity for the next 1-2 billion people.

Figure 4: Feature phones that historically had almost no memory are being replaced by very inexpensive smartphones with the same amount of memory as high-end smartphones.

Figure 4: Feature phones that historically had almost no memory are being replaced by very inexpensive smartphones with the same amount of memory as high-end smartphones.

Bajarin: In my analysis of these markets I break out: What did we do to get to this first 2 billion people who are online with their smartphones today? What are their behaviors like? The dynamics between the mid range and the high range are changing within this first 2 billion. We look at the first 2 billion [smartphone users] as a very distinct market.

You hear, ‘oh, smartphones are a saturated market, it’s slowing down,’ and while that’s true, I think we also have to recognize that there are a lot of people who still don’t have smartphones. And that a lot of this is an economic discussion. But the way that I visualize this is: I link our model of smartphone installed base by a number of countries that I track vs. their population (Figure 3). You look at places like China and India, even Brazil which is large, Indonesia, and particularly you look at the continent of Africa, and you see massive, massive, amounts of those populations that are yet to have a smartphone.

Now, what we also keep in mind is that most of them actually have a mobile phone. So it’s not like we’re starting from scratch.

I believe, over time, we will convert the two or so billion people today who are yet to have a smartphone but do have a mobile phone, we will convert those to become smartphone users. And you follow that up with the observation that it will become their primary computer to do things, engage in commerce, learn tips about farming, engage in trade in new ways, and become better educated. All of that has a huge potential increase to the GDP of those countries, particularly less developed parts of the countries.

Planar to 3D

Rayfield: We’ve talked a lot about the smartphones, let’s go back and look at what they’re made up of. Even the 100-dollar devices have computing capabilities that were in PCs only a couple of years ago. From a DRAM standpoint, it’s already the highest performing high-volume DRAM in the industry. It’s all about energy per bit, how do we get more efficient, how do we get battery life to last longer? There’s going to be next generation options whether you put the memory in package or other kinds of things. Those are things that are being driven by the smartphones and are going to be used across other markets. From a NAND standpoint, we’ve talked about people wanting additional storage and capability.

Planar NAND has pretty much run out of steam in terms of lithography, so we’re going to 3D. We’re getting to the point where it will be very easy in one or two or four die configurations to have 64, 128 or 256 GB of memory in the same footprint that you have 4 GB now. That’s an innovation that people will use once they have the storage, and it’s being designed in devices right now. The reality is we think a lot of the mobile phone design is bound by how much memory or NAND [is available].

Bajarin: […] what happens if we move now to a video era? Where all of a sudden we see an increase in capture and creativity and sharing of a range of things, again, probably video experiences we can’t even fathom today because they haven’t been created yet.

There are huge implications across the hardware, software and services landscape, but all of these devices have to be built understanding that consumer demand will be there. If we give them more capacity, they will take advantage of that, but more importantly so will the developer ecosystem. We study millennials a lot, because I think millennials globally put the most demand on their devices [and] video is a normal part of their life and usage, and that’s just going to increase, it’s not going to stop. New behaviors around video and new demands will emerge as this generation starts to get those capabilities from a capture standpoint in terms of sensors, as well as just having the throughput in 5G and beyond to now take advantage of these services. So we look toward this next video era in light of what we saw in the photo era. Unprecedented things happened with photography, and we’re on the cusp of seeing the same thing with video.

Rayfield: One of the things that video puts a burden on is storage. We’ve now gone to 3D NAND (Figure 5). What 3D allows you to do is back off on lithography, making it a little easier to scale and scale vertically. And what we gain is capacity. So in a couple nanometers of silicon you can put all the storage you need in your mobile device.

You also gain is speed. Very quickly the network is getting fast enough that it’s forcing us to get better on storage. And that is going to be the thing that continues to drive us. As we go to this 3D, we get much, much, bigger bandwidth with the storage.

Figure 5: Traditionally, flash has been built in a planar, or two-dimensional structure—much like a one-story building. When we wanted to add space, we had to make the data cells (the rooms in the building) smaller. With 3D, we’re building a vertical building—like a skyscraper.

Figure 5: Traditionally, flash has been built in a planar, or two-dimensional structure—much like a one-story building. When we wanted to add space, we had to make the data cells (the rooms in the building) smaller. With 3D, we’re building a vertical building—like a skyscraper.

In summary, the amount of data that people consume, generate and want to share is driving what the system is. The content that the developed world is generating, consuming and sharing is quickly moving to the next 1-2 billion users and again that’s going to put a lot of pressure both on the devices and their capabilities. And then if you look at a bottleneck of consumer experiences and devices, it’s all about generating, creating, and sharing content. These devices now have a capability where maybe a couple of years ago people wouldn’t have thought that they’d become as ubiquitous as we believe they’ll be around the world. 

Ultra Low Energy and the ULE Alliance

Thursday, March 24th, 2016

A new generation wireless communication technology for the IoT has applicability in cases ranging from energy savings to emergency response to the smart home.

The ULE Alliance is an organization that works to expedite the worldwide deployment and market adoption of Ultra Low Energy (ULE) products. The ULE Alliance works with its members to quickly develop new products and services in the areas of Home Automation, Security and Climate control by certifying standards conformance and ensuring interoperability between IoT products of the different vendors, thereby improving service provider selection, delivering true customer satisfaction and increasing the overall size of the market for all participants. Our goal is to ensure that the proven and superior ULE technology will be a leading infrastructure and standard for home wireless networks, enabling a more safe and convenient life for all people.

Our organization is made up of global service providers, vendors and chipset developers dedicated to developing energy-efficient and powerful solutions for the Smart Home and Office.


Comparison to Other Wireless Options on the Market

ULE is a new generation wireless communication technology for the IoT, based on DECT, an established technology with 20+ years of deployment. Since this is an established technology, the chipsets are reliable and costs are extremely competitive. ULE operates in dedicated, licensed, royalty free spectrum, giving the service provider the longest wireless range of 75-100 meters in building, and up to 300 meters in open range, compared to competitors that range from 10-30 meters from the gateway. This greatly reduces the need for expensive repeaters throughout the home, greatly simplifies the layout and installation, and reduces energy consumption and overall cost; many providers are looking at self-installation as another cost saving option for their intelligent home solutions.

ULE operates in dedicated, licensed, royalty free spectrum, giving the service provider the longest wireless range of 75-100 meters in building, and up to 300 meters in open range, compared to competitors that range from 10-30 meters from the gateway.  This greatly reduces the need for expensive repeaters throughout the home, greatly simplifies the layout and installation, and reduces energy consumption and overall cost; many providers are looking at self-installation as another cost saving option for their intelligent home solutions.

This unique band has no interference from Wi-Fi, ZigBee, Bluetooth, Z-wave, etc. and has the ability to carry two-way voice and video with great stability. This makes possible applications such as fire systems that tell you exactly where the fire rather than just sounding an alarm. Such systems can also open a northbound call to 911 to provide an open channel of communication. Critical information, e.g., “my children are trapped in the back of the house” can be conveyed in a situation where seconds matter.

The ultra-low power asset also makes great use of the battery, so much so that tests have shown some of the batteries can last seven years without changing. Imagine not having to tell customers to change the alarm batteries every six months, or worrying that the system will fail due to a dead battery. Most batteries will die of corrosion before losing power. Tens of millions of home gateways use DECT; these gateways can be easily upgraded to ULE by a software upgrade, something that the service providers perform routinely. This creates a new business opportunity for the service providers to expand the communication services to their customers’ homes by providing smart home services, re-using installed home gateways.

Tens of millions of home gateways use DECT; these gateways can be easily upgraded to ULE by a software upgrade, something that the service providers perform routinely. This creates a new business opportunity for the service providers to expand the communication services to their customers’ homes by providing smart home services, re-using installed home gateways.


ULE Alliance has established active work liaisons with ETSI, Home Gateway Initiative (HGI), AllSeen Alliance and Open Connectivity Foundation (OCF – former OIC) to help foster better interoperability, management and bridging between all sensors and devices in
the home. The DECT Forum is an active member of the ULE Alliance as well.

At CES 2016 the ULE Alliance and its partners, All-Seen and OCF, made joint demonstrations, and close cooperation is expected to continue and strengthen all the parties.


Since launching the Ultra-Low Energy Certification in mid-2015, 30+ products have successfully achieved certification. We expect the number to top 100 by 2017.

  • ULE Alliance demonstrated at CES 2016 ULE working over IPv6 (6LoWPAN).
  • Members Turkcell and DSP Group announced in January the commercial IoT deployment based completely on ULE, which will serve a 25 million household base.
  • Deutsche Telecom announced that all the next generation home gateways will be equipped with ULE.
  • Panasonic introduced the Home Automation kit, based on the ULE technology, in USA and Europe.

What’s Next

  • With the introduction of 6LoWPAN, the IPv6 connectivity will play an increasing role in extending the IP communication protocol use in the IoT, replacing the proprietary technologies and enabling better interoperability.
  • More companies will adopt the use of the wireless technology agnostic application layers, such as AllJoyn and IoTivity.
  • The consolidation and cooperation between different technologies should happen in order to achieve the goal of seamless integration of new devices into the existing networks, regardless of the wireless technology in use. Interoperability across various wireless technologies is imperative in order to support widespread adoption for IoT.

Ahead for the ULE Alliance

  • ULE Alliance will release the 6LoWPAN support for ULE in Q2’2016
  • ULE Alliance will continue to cooperation with AllSeen and OCF, introducing two projects with each partner:
  • A bridging gateway between existing ULE and AllJoin/IoTivity networks
  • Sensors running AllJoin / IoTivity application layers over ULE protocol
  • New ULE based service deployments by major European service providers
  • Increasing number of device manufacturers worldwide using ULE
  • Number of ULE based sensors/actuators surpassing 250 by end of 2017

Avi Barel_115Avi Barel is Director of Business Development, ULE Alliance. He has over 30 years of broad high tech experience, ranging from software development, semiconductor, engineering and business management.

Barel joined the ULE Alliance in April 2013 as the Director of Business Development and is actively leading the promotion of the ULE technology worldwide. Prior to ULE Alliance, at DSP Group, he served as the Corporate Vice President of sales for 8 years. Before joining DSP Group Barel established and managed Winbond subsidiary in Israel for 5 years, developing semiconductor products for speech processing and communication, managing team of 50+ engineers. At National Semiconductor he held variety of engineering, engineering management and business management positions; involved in development and management of award winning, innovative projects.

Barel holds M.Sc. degree in Computer Science and B.Sc. degree in Mathematics and Physics from the Hebrew University in Jerusalem.

Formal Low-Power Verification of Power- Aware Designs

Monday, November 9th, 2015


Power reduction and management methods are now all pervasive in system- on-chip (SoC) designs. They are used in SoCs targeted at power-critical applications ranging from mobile appliances with limited battery life to big-box electronics that consume large amounts of increasingly expensive power. Power reduction methods are now applied throughout the chip design flow from architectural design through RTL implementation to physical design.

Power-Aware Verification Challenges

Power-aware verification must ensure not only that the power intent has been completely and correctly implemented as described in the Unified Power Format (UPF) specification [1] or the Common Power Format (CPF) specification [2] , but also that the functional design continues to operate correctly after the insertion of power management circuitry.

Power estimates are made at several stages in the design flow, with accurate estimates becoming available only after physical layout. Consequently, design changes such as RTL modifications and layout reworks ripple back and forth through the design flow. This iterative power optimization increases verification and debug effort, project risk, and cost. The objective is to achieve the target power consumption while limiting the cost of doing so.

The power management scheme

Initially, an implementation-independent functional specification is devised to meet product requirements. The functionality is then partitioned across hardware and software. An initial power management scheme can be devised at this architectural level, but it defines only which functionality can or should be deactivated for any given use case, not how it should be deactivated. The functionality is then implemented in RTL, making extensive use and reuse of pre-designed silicon IP blocks, together with new RTL blocks. Some of these blocks may be under the control of software stacks.

At this stage, decisions are made about how functionality should be deactivated, using a multiplicity of power reduction methods to achieve the requisite low-power characteristics. These decisions must comprehend both hardware- and software-controlled circuit activity. Common power management methods include:

  • Clock gating
  • Dynamic voltage-frequency scaling (DVFS)
  • Power shut-off
  • Memory access optimizations
  • Multiple supply voltages
  • Substrate biasing

These early-stage power management decisions can be influenced by a physical floorplan, but they do not—and cannot— comprehend the final partitioning at P& R, where accurate power estimates are made. Consequently, the power management scheme can be modified and must be re-verified after P& R.

Clearly, the power management scheme is a moving target, and requires iterative design optimization, verification, and re-verification at every stage of the design flow—including architecture, RTL implementation, and physical design.

Additional complications

Implementing any scheme is often subject to significant additional complications, such as the impact of IP use and re-use and of DFT circuitry. A given IP block can implement several functions, each of which can be or must be switched off independently of the others, for example, by adding interfaces to the power-control registers or signals. These functions can be problematic in the case of third-party IP, where (often) only black box information about its behavior is available. In any case, the verification challenge now includes re-verifying the redesigned IP block(s) as well as verifying the power management circuitry.

In order to minimize test pattern count and test time, conventional DFT assumes that the whole chip operates with all functions up and running. That is how it operates not only on the tester, but also in field diagnostics. With power-aware design, DFT circuitry must now mesh with the design’s power management scheme in order to avoid excessive power consumption and unnecessary yield loss at final test.

Power-Aware Verification Requirements

Functional analysis, optimization, and verification throughout the design flow, complicated by inadequate visibility of third-party IP white-box functionality, mandates the following five principal requirements for implementing and verifying a low-power scheme:

  • Sufficiently accurate power estimates using representative waveforms, both pre- and post-route
  • Accurate visibility and analysis of the white box behavior of third-party IP prior to its modification and reuse
  • Deployment and ongoing optimization and verification of appropriate power reduction techniques, both pre- and post-integration
  • Exhaustive functional verification at the architectural and RT levels, both before and after the deployment of power optimization circuitry
  • Verification of hardware functionality compliance with software control sequences

The first requirement can be addressed with commercially available tools that use simulation and formal methods. The rest of this section deals with the remaining requirements.

As previously indicated, the power management scheme starts at the architectural level, so any available architectural features such as communication protocols must first be verified (see Figure 1).

Figure 1: Ongoing power-aware optimization and verification

In the subsequent functional implementation (RTL) flow, low-power management constructs are introduced at different phases in the SoC development, depending upon the data available and the optimizations required. Taking the deployment of power domains as an example, verification must ensure that:

  • Normal design functionality is not adversely affected by the addition of power domains and controls. “Before and after” checking is critical.
  • A domain recovers the correct power states at the end of the power-switching sequence, and generates no additional Xs at outputs or in given block signals.
  • It achieves a high level of coverage of power-up /power-down events, which are very control-intensive operations.
  • Switching off a power domain does not break connectivity between IP blocks.

Therefore, taking the RTL model verified prior to the insertion of power management circuitry as the “golden” reference model, power-aware verification requires a combination of:

  • Architecture-level verification
  • IP white-box functional visualization and analysis
  • Exhaustive functional verification
  • Sequential equivalence checking
  • Control and Status Register (CSR) verification
  • X-propagation analysis
  • Connectivity checking

Limitations of Traditional Power-Aware Verification

Various tools and approaches are used for power-aware analysis and verification. This patchwork of tools and approaches clearly provides limited analysis and verification capability, and demonstrably achieves inadequate QoR. Automated structural analysis and limited, manual functional analysis can identify potential opportunities for the use of power management circuitry. Such analysis can assure consistency between the RTL design and the UPF/CPF specification, but cannot verify design correctness. At the architectural level, power analysis usually is performed manually with spreadsheets.

Power-aware simulation is used at the RTL, but, like conventional simulation, is not exhaustive. This situation is exacerbated by the state space explosion resulting from the insertion of complex power management schemes. It not only significantly degrades simulation performance, but also fails to systematically avoid X optimism and pessimism.

Power-related DRC can enable limited power integrity analysis at the gate level.

Meeting Power-Aware Verification Requirements with JasperGold Apps

The JasperGold power-aware verification flow comprehensively meets power- aware verification requirements with the requisite QoR.

The front-end of the flow is the JasperGold LPV App (see Figure 2), which automatically creates power-aware transformations and automatically generates a power-aware model that identifies power domains, the power supply network and switches, isolation rules, and state retention rules. It does so by parsing and extracting relevant data from the UPF/CPF specification, the RTL code, and any user-defined assertions. It then automatically generates assertions that are used by other JasperGold Apps to verify that the power reduction and management circuitry conforms to the UPF/CPF specification and does not corrupt the original RTL functionality.

Figure 2: Jasper Gold power-aware verification flow

Power-aware model

The resulting power-aware model enables the analysis and verification of a wide-range of power management characteristics, for example:

  • Power-domain correctness, such as the absence (or otherwise) of clock glitches and correct operation of reset logic
  • Power state table consistency, analyzing all possible power-state transitions and detecting illegal ones
  • Retention cell verification, validating the integrity of saved data in all power states.
  • Power-supply network connectivity, to detect power intent errors made when defining the power-supply network
  • Power-aware correctness, ensuring equivalence between a power-aware design and the original RTL when all power domains are continuously on

LPV-generated assertions

Examples of assertions automatically generated by the JasperGold LPV App include:

  • Ensure that a power domain clock is disabled when the domain’s power supply is switched on or off
  • If a power supply net has resolution semantics, there is never more than one active driver
  • Ensure that the power supply of retention logic is on when the value of an element is restored from that logic
  • Whenever a power domain is powered down, all the isolation conditions related to this power domain are true before, during, and after power shut-off
  • No signal is isolated twice with contradictory clamp values

The JasperGold Apps approach

In contrast to the general purpose, all-in-one formal verification tool approach, the JasperGold Apps approach enables step-wise adoption of formal methods. Each JasperGold App provides all of the tool functionality and formal methodology necessary to perform its intended application-specific task. This approach requires design teams to acquire only the expertise necessary for the particular task at hand, and at a pace that suits the project requirements and user expertise.

Providing an empirical measurement on the effectiveness and progress of the formal verficiation, the JasperGold Design Coverage Verification (COV) App takes in the user’s RTL, assertion properties, and constraint properties and outputs a textual and GUI-based report showing how aspects of the DUT were verified by the formal analysis. These reports how lines of code (“statement coverage”), conditional statements (“branch coverage”), and functional coverage points that were exercised.

The JasperGold Formal Property Verification (FPV) App performs exhaustive verification of (a) all RTL functionality before the insertion of power management circuitry, and (b) the power management circuitry itself. For example, it analyzes and verifies power sequencing both during block design and after integration, including sequence safety such as clock deactivation, block isolation, and power down, as well as state correctness.

The JasperGold Control and Status Register (CSR) Verification App verifies that the design complies with the CSR specification, and that the value read from a register is always correct, both before and after power management insertion.

The JasperGold Sequential Equivalence Checking (SEC) App verifies the equivalence of blocks before and after power management circuitry is inserted, as well as those blocks subject to late-stage modification. In addition, it verifies that memory optimizations do not compromise functionality. For example, where a memory is replaced by two low-power memories with a wrapper, the JasperGold SEC App verifies that the two memory models are equiv- alent to the original memory.

The JasperGold X-Propagation App (XPROP) analyzes and verifies Xs at block outputs caused by power-down, and compares differences in output X behavior before and after application of the UPF/CPF specification.

The JasperGold Connectivity (CONN) Verification App exhaustively verifies RTL connections at the block and unit level, and after integration.


The Cadence JasperGold power-aware formal verification flow enables exhaustive analysis and verification of power-aware designs, achieving QoR superior to those designs produced by the traditional ad hoc patchwork of tools and approaches. Starting with the JasperGold LPV App to automatically generate a power-aware model and the appropriate assertions, the flow leverages an expandable range of additional JasperGold Apps, each targeted at a particular task. Design teams can deploy JasperGold Apps as needed and acquire expertise in a low-risk, step-wise fashion.

References and Further Information

[1] 1801-2013 – IEEE Standard for Design and Verification of Low-Power Integrated Circuits. Available at

[2] Si2 Common Power Format (CPF) Specification. Available at /?page=811.

To learn more about Cadence JasperGold Apps, contact your local sales office at

Contact Information

Cadence Design Systems, Inc.

2655 Seely Avenue
San Jose, CA, 95134

tele: 408.943.1234
fax: 408.943.0513

SoC Makers Recognizing the High Stakes in Low Power

Thursday, May 7th, 2015

Q&A with Sonics CTO Drew Wingard

The opportunities afforded by industrial, medical, consumer and mobile sectors—especially as the IoT grows—are closely entwined with power management.

wingardWhat time is it? Dr. Drew Wingard, CTO of on-chip networks maker Sonics, says that had he not powered off his smart watch before boarding an international flight, the device would not have been able to answer that question upon arrival—it couldn’t hold time for more than a day. During a recent EECatalog interview, Wingard spoke about the factors that led to the “crazy” idea of a smart watch that can’t tell time, where the opportunities to conserve power are to be found, and how battery thresholds enable markets. Edited excerpts of the interview follow.

EECatalog: What makes for a good understanding of power partitioning decisions?

Wingard, Sonics: It certainly has a lot to do with trying to understand the use models, in many cases, not just of the chip, but also of the system in which the chip is going to be used. This is much more difficult to do when building a chip that is truly general-purpose.

Something interesting about the SoC space is that we don’t see that many chips that are designed in a truly general-purpose way. In many respects we are fortunate—in others cursed—that SoCs tend to be pretty application-specific. Say I am building a chip that is going to be the application processor inside a mobile phone. That [choice] defines a set of use cases for the end phone that we can take advantage of in trying to make these choices, or, say it’s going to be a TV processor that is going to be for adding Internet capability. That would have another set of use cases associated with it. The best SoC architects build libraries of knowledge over time about what’s required of the systems the chip is going to plug into.

It is relatively rare that you get a new company trying to attack an SoC application these days. Most companies work with what they’ve learned over the years of integrating ever-larger system chips, making most designs at some level evolutionary. A company may make radical changes in its architecture, but this occurs within the framework of understanding this library of knowledge about what the likely use models are going to be.

EECatalog: Has the answer to what makes for the most effective power management strategy for a multicore SoC changed?
Wingard, Sonics: Before leakage was a problem, when the transistors used to shut off all the way, the biggest user of power in the chip was switching, and power management had everything to do with clock management.

That’s still a very important technique today, but leakage has become such an issue, there is now a whole host of additional techniques to deal with it. At the level of the underlying silicon, that has always been the case, but of course the manufacturing process doesn’t always give us the same transistors on every chip. Sometimes we are at the corner where the transistors are relatively slow. For power [considerations] slower transistors are better because they have lower current. And that means their leakage current tends to be low.

For speed, of course fast transistors are better, but fast transistors are the ones that tend to have the highest leakage. One technique that can be deployed, although it is not very friendly for FinFETs, is to change the voltage of the well contact. You can change the electrical characteristics of a transistor by using the fourth terminal that people rarely think about. There has been a lot of work done to try to optimize the combination of frequency and leakage by playing with the voltage on that terminal. That [playing with the voltage on the terminal] was something that was very attractive for eight of the past 10 years, but now, as the focus has shifted to 3D transistors in the form of FinFETS and others, it turns out that fourth terminal is not available to us to play with any more, so we are using other techniques.
Another technique that has become very common is to optimize the supply voltage of a circuit to match the frequency that it needed to operate at, and so people talk about techniques like dynamic voltage and frequency scaling.

If software can determine that the total loading on your computer is lower than what is needed at peak, it can slow down the clock, which helps save some power, but you can save even more power and a lot of leakage by reducing the supply voltage at the same time. By switching off whole banks of circuits, instead of just stopping their clocks when they are idle, you can cut the power to them and eliminate leakage altogether—this is another technique practiced more frequently today.
The technologies I’ve just noted have substantial implementation costs associated with them, so designers have to be careful about where and when to apply them. This is where the knowledge of use cases and the role of the different IP cores in the chip in those use cases becomes important.

EECatalog: What are the characteristics you would find in companies that are successful in creating ultra-low power solutions?

Wingard, Sonics: While we have been talking about power as being a design imperative for 10 years now, it is still the case for most design teams that power is not a primary design concern—that clearly does not make sense, but it is still the reality. So the people who tend to do the best designs for low power are those who think about low power continuously through their architecture, design and verification processes. There are design teams who do not wait for a characterization tool to tell them after they are done how much power they used, but who [instead] design low power in as part of the goal and continuously track how well they are doing versus their power goal.

Now, there are limitations in the ability of—and certainly in the use of—EDA tools to help in that process. The state of the art in EDA tooling around this is not anywhere near as advanced as it is around the design and verification challenge.

EECatalog: Why?

Wingard, Sonics: Because there has not been as much effort. It boils down to where the semiconductor designers are willing to spend their dollars—it’s not that EDA companies are not willing to build those tools, I think that the market for those tools has not yet fully emerged. There have been companies trying, and there have been some companies who have failed trying to provide tools for doing better architectural low-power analysis. It is not because their solutions didn’t work, but because for most organizations designing for low power remains an afterthought.

EECatalog: What will cause it not to be an afterthought?

Wingard, Sonics: One factor could be this crazy idea of these smart watches that you have to plug in everyday. I had a watch that could not hold time for more than a day, and I had to power it off before I got on an international flight because I knew that if I left it on, it would not know the time when I landed at my destination—that is kind of crazy, right?

We’ve seen that battery lifetime thresholds enable markets. [Say] I have a great wireless communications device that has to be plugged in all the time— that kind of defeats the purpose of having it be wireless.

There have been domains for many years where there was incredibly great work done around low-power design. The original digital watch industry did some fantastic work. They built chips that used transistors in strange regions of operation that normal digital people don’t think of because they could do it and make digital watches that lasted for a couple of years on a battery. Now the question is what part of this mammoth opportunity that we know by the umbrella term “Internet of Things” will drive people to look at the low power issue in a new way?

Certainly the first generation of chips that were all targeting wearable applications is where we saw companies who had largely failed designing cell phone processors trying to dumb down their chips for some of these imaging-capable wearable devices with graphic displays—those have not worked very well. You can make the strong argument that it is form factor and battery life that are two reasons why they haven’t worked very well.

Medical wearables is an area where there are considerable privacy and security concerns, but some people have discussed pretty publicly that maybe the time when wearables take off is when the insurance company determines that it save them money to buy you something to monitor your health.

EECatalog: Where are you seeing the need for better communication among various interest groups so as to achieve a “rising tide lifts all boats” effect with regard to ultra low power?

Wingard, Sonics: Large semiconductor companies [have already] worked very productively with the EDA companies to come up with a set of power intent formats. IEEE 1801 allows for the low-level design of things that have multiple power islands and are done in a fashion that is electrically safe. While there will probably be some small enhancements over the years, this important and productive work is largely done.

Today, it is not about the implementation of these techniques, it is about helping design teams understand how many power islands should they create, how many clock domains should they create. It goes back to some analysis challenges.

Of course most SoCs are built out of a lot of reused components which are licensed in from the outside, and then some new logic, and one thing that we are almost completely bare on is: how do we come up with some standards for the interfaces that signal “hey, I am idle, you might want to shut me down” or “hey, I want to shut you down, are you okay with me doing that?” There are some basic communication interfaces that make dynamic power control much easier to implement when you are looking at an SoC that may have 150 blocks on it. Dealing with vendor- or company-proprietary interfaces or trying to figure out how to add an interface around a block that was designed without this kind of cycling ends up being quite a daunting task for the person trying to integrate an SoC, and I think as we move forward we should start to see some real work in that area.

EECatalog: Should we anticipate announcements from Sonics on the ultra-low power front?

Wingard, Sonics: I would hope so. First we have to make sure that we design our on-chip networks and our other IP products so that they use as little power as we can by aggressively employing conventional techniques. And I think our customers would report that [compared to] competing solutions we use between 40% and 80% less power for the same amount of work.

Our announcement last year that we had been awarded a patent on some active power management technology hints at an area in which we are very interested. I would encourage your readers to watch for more information from Sonics in this area!

Anne Fisher is managing editor of Her experience has included opportunities to cover a wide range of embedded solutions in the PICMG ecosystem as well as other technologies. Anne enjoys bringing embedded designers and developers solutions to technology challenges as described by their peers as well as insight and analysis from industry leaders. She can be reached at

Optimizing and Simplifying the Process: Q&A with a Systems/IC Architect on Ultra-Low-Power-Design

Tuesday, May 5th, 2015

What will it take for ultra-low-power designs to become more prevalent—that’s one of the questions fielded here (think commitment to sub-threshhold design) but far from the only one.

Our thanks to Andy Kelly, Systems/IC Architect, Cactus Semiconductor, Inc., for his insights and observations on topics including accomplishing device miniaturization, prioritizing requirements and top-down design and simulation tools, among other subjects.

EECatalog: In what areas are you finding designers struggling most as they strive to optimize and simplify the design process, particularly when working on ultra-low power designs?

andy_kellyAndy Kelly, Cactus Semiconductor: The biggest challenge I see with our full-custom IC design projects is on the requirements definition—more so than in the design execution. Since our devices are fully customized, customers often start off under the assumption that they can have the highest performance AND the lowest power consumption AND the smallest circuit area. In practice, these requirements all need to be prioritized, and compromises must be made in order to reach a set of requirements that can be met on a reasonable budget and schedule.

EECatalog: What is being done within the semiconductor industry in general to address the challenges named in Question (1) and what role more specifically is Cactus playing?

Kelly, Cactus Semiconductor: The industry as a whole has made great progress in the development of “top-down” design and simulation tools. These tools allow the system and IC design teams to build up a virtual circuit based on behavioral models. These models can be integrated into higher-level system simulations. Then tradeoffs can be modeled and assessed with significantly less effort than with detailed circuit design. Once the behavioral modeling is complete and the requirements are finalized, the detailed circuit design can proceed with significantly better efficiency. At Cactus Semiconductor, we recognize the requirements definition as the key to success, and we include a “Definition & Specification” phase at the beginning of every project to ensure we have a good set of requirements before starting the detailed design phase.

EECatalog: What’s the argument for considering a custom ASIC design for a design that requires device miniaturization? What myths, or misconceptions, if any, have you had to dispel in making this argument?

Kelly, Cactus Semiconductor: There are two primary arguments in favor of custom IC design over standard product design. The first is that the custom design can integrate multiple functions in a single IC. This eliminates the packaging and IO overhead of numerous components, devices, and interconnects. It results in an ASIC footprint that can be an order of magnitude smaller than the footprint of the standard products it replaces. The second argument is that custom IC design enables us to design very specifically to the required function and performance. In contrast, standard product designs use a collection of devices and components meant for general purpose, and thus typically result in a sub-optimal design that inevitably consumes more power than an ASIC equivalent. In the case of implantable or hand-held devices, the system’s battery is typically the single largest component in the system. As such, a full-custom IC design can often lead to huge reductions in device size due to battery size reduction. The biggest myth we have to dispel on a fairly regular basis is the idea that once you commit to a full-custom design, you should strive to maximize integration. While this approach logically makes sense, in practice, it is very uncommon for the maximized integration approach to lead to the best overall solution. At Cactus Semiconductor, we strive for “smart integration” in favor of “maximum integration.”

EECatalog: Could you define in more detail what is meant by “smart integration?”

Kelly, Cactus Semiconductor: “Smart Integration” involves a systematic definition of all system requirements, followed by an assessment of optional paths to meeting each requirement. Finally, a tradeoff of each path is covered that includes; electrical performance, power consumption, device size, development cost and schedule, component cost, reliability and others. When all of these factors are weighed for each system requirement, we often conclude that a mix of custom ICs and standard products will result in the optimal solution. This is what we refer to as “smart integration.” A common example of smart integration comprises a system partition that includes a standard microcontroller along with a full-custom ASIC. While the microcontroller functions could be integrated if necessary, we have found that the performance, power, size, and cost of some newer microcontroller parts make them extremely attractive, and difficult to justify full integration.

EECatalog: Can the principles of smart integration apply across a number of areas where ultra-low-power and high performance design is needed, e.g., medical, gaming, digital signage, industrial control and automation?

Kelly, Cactus Semiconductor: In my opinion, the principles of smart integration can apply to any discipline or market. The end results will vary greatly due to the different system requirements, but smart integration is a process, not a result—and that process can and should be used for any project.

EECatalog: What, if anything, are you seeing as problems or challenges that are not getting their fair share of attention in the area of ultra-low-power design?

Kelly, Cactus Semiconductor: For ultra-low-power designs, we often need to apply design techniques whereby the MOS devices in a circuit are operated in their sub-threshold region. Since this is not the operating state of devices for mainstream and traditional designs, the device modeling and circuit library availability is lacking. I have recently seen progress in this area, but for most process technologies, committing to a completely sub-threshold design typically involves some extra development effort and risk. This translates into higher development cost and longer development schedules. If the models and circuit libraries supporting sub-threshold operation were to reach the level that standard operation has achieved, I think we would see a much greater emphasis on this design approach, and ultra-low-power designs would be more prevalent.

Anne Fisher is managing editor of Her experience has included opportunities to cover a wide range of embedded solutions in the PICMG ecosystem as well as other technologies. Anne enjoys bringing embedded designers and developers solutions to technology challenges as described by their peers as well as insight and analysis from industry leaders. She can be reached at

Tips for Selecting the Right Ultra-Low-Power, ARM-Based MCU for Your IoT Design

Tuesday, May 5th, 2015

Despite appearances, not all MCUs based on ARM architecture offer the same level of energy efficiency and performance, so it’s important to ask the right questions and make the best choice for your power-sensitive Internet of Things (IoT) application.

The variety of ultra-low-power 32-bit microcontroller unit (MCU) options has never been higher. Many MCU vendor portfolios include hundreds of variants based on package options, memory size, performance and peripheral set. Although it may seem like the emergence of ARM Cortex-M based MCUs is at the heart of this vast choice, in reality there has always been a wide field of low-power 32-bit options from which to choose.

In the past, support for any given instruction set was just one (albeit an important) element in the selection process, but thanks to ARM the relevance of the instruction set may have become largely moot. The ecosystem surrounding Cortex-M cores means engineers can justifiably standardize on just one architecture. But this still leaves many features to compare, especially when seeking a low-power MCU. For today’s power-sensitive IoT applications, this puts the focus squarely on a short list of parameters that can still be measured against requirements. Let’s examine eight of the most important MCU features that need to be considered.

Active Power
As with all integrated devices manufactured using CMOS technology, MCUs only consume power when their logic gates are changing state. The number of CMOS gates in a modern MCU means power consumption can become significant, particularly at high clock rates.

Most MCUs will strive to reach a balance between active power consumption and processing performance. Even when the same core lies at the heart of the device, this parameter can vary significantly based on the design expertise of the MCU vendor. While many MCU vendors have focused on reducing active power in recent years, low-power MCU designs that emphasize autonomous low-energy peripheral operation (without direct CPU involvement) are also quite effective in minimizing overall system power consumption.

Reported MCU performance is directly related to active power. It’s important to understand performance metrics, particularly when consulting a data sheet, as the specs are often reported under “ideal” (or more aptly unsustainable) operating conditions or even when running unusable code. Delivering both high performance and low active power is difficult and, again, an area where MCU vendors can differentiate their product offerings. Carefully compare data sheet performance specs and question the MCU vendor about the real-world operating conditions underlying the results.

One way of keeping active power low is to reduce the operating frequency, which inevitably and quite naturally leads to sleep modes. Any MCU can be put into a mode where it consumes the least amount of active and static power, but invariably this is achieved through clock- and power-gating, i.e., removing the clock and/or power to specific areas of the MCU. The penalty for employing this technique without due consideration to the requirements of the target application can result in an MCU that is slow to resume its duties when needed. Fast wake-up from deep sleep modes is a fiercely contested parameter among MCU vendors.

Energy Efficiency
If reduced responsiveness is the penalty for using sleep modes, the benefit is lower energy consumption. Here, the trend is—and has been for some time—to implement a range of sleep modes that offer the right level of efficiency for the right operating condition. Sleep modes that offer reduced power consumption and fast wake-up should complement deep sleep modes that reduce power consumption to an absolute minimum—even at the cost of longer wake-up times—when required by the application. The combination of ultra-low-power active and sleep modes and very fast wake-up time defines an MCU’s energy efficiency. (See Figure 1.)

Silicon Labs ULP 32-bit MCU   Article Fig1
Figure 1. Energy efficiency is defined by power consumption over time, i.e., lowest active and sleep mode energy plus fastest wake-up times.

A recent development in MCU design has been to implement greater intelligence in the peripheral subsystems, allowing various peripherals to operate autonomously. In addition to bringing a new dimension to application development, the overriding benefit of autonomous peripherals is that they allow the core to remain in a (deep) sleep mode much longer. Instead of having to periodically emerge from a deep, power-saving sleep mode to check for an event, autonomous peripherals are able to register an event and decide whether it requires the intervention of the core. If your application demands excellent energy efficiency, be sure to choose an MCU with an architecture that supports autonomous peripheral operation even in the lower sleep modes.

Autonomy doesn’t need to end with a single event; some MCUs now implement systems that allow multiple peripherals to interoperate and thus parse more complex conditions or a series of interdependent events before waking the CPU core. This feature is far less widely supported by MCU vendors but can deliver significant benefits in specific applications, typically those that are battery-powered and are required to detect infrequent events or conditions, such as environmental changes (humidity, smoke and CO2) or intrusion.

A few vendors offer MCUs with the ability to interface directly and intelligently to a wider range of signals. MCUs are inherently digital but often feature a high level of mixed-signal capability, such as integrating analog-to-digital and/or digital-to-analog converter(s). However, as the world we live in remains analog by nature, it is becoming increasingly necessary to offer greater support for analog signals, particularly those that emanate from sensors. While most advanced IoT applications use sensors with digital interfaces, some sensors will still remain analog either because of current consumption (analog is generally lower power) or because of budget (analog sensors tend to be more cost-effective than digital sensors). The ability to interface directly to small capacitive, inductive or resistive sensors and intelligently parse the signals before waking the CPU will undoubtedly become a common use-case for IoT-oriented designs.

Although, as mentioned earlier, the ARM Cortex family enjoys a strong and growing ecosystem of software providers, end-applications still need dedicated application code. Software development is now recognized as the single largest consumer of engineering resources, and so when selecting the right MCU it’s important to consider the level of software support and quality of tools available from both the ecosystem and the MCU vendor. It is still imperative that the MCU vendor offers robust, user-friendly software development tools. Even if a preferred partner supplies the IDE, elements of support will be required for specific differentiating features. Look for MCU vendors that provide comprehensive development ecosystems designed to simplify the design process, as well as energy profiling and battery estimator tools that enable low-energy system optimizations.

Benchmarking Ultra-Low-Power MCUs
Comparing and selecting ultra-low-power MCUs based on claimed current consumption specifications can be challenging. In most cases, developers initially look at the first page of an MCU vendor datasheet to glean various operating specs. This approach works well to determine the overall functionality of a device but is not as useful when trying to gauge low-power characteristics in real-world applications. To get a full view of ultra-low-power operation, developers must take into consideration active and sleep mode current consumption, state retention, wake-up time, wake-up sources and low-energy peripherals that are capable of operating while in low-power mode.

Many MCU vendors usually list the lowest power achievable on the first page of the datasheet. Although the device may be capable of achieving this specification, the actual operating mode may not be practical and useful in a real-world application. Some of the non-advertised features of the lowest power mode may include a very slow wake time, no state or RAM retention, brown-out detector (BOD) turned off or a reduced operating voltage range.

Today’s developers need a consistent, reliable way to measure the true low-power capabilities of an MCU to be used in power-sensitive IoT applications. To address this need, the Embedded Microprocessor Benchmark Consortium (EEMBC) has collaborated with leading MCU vendors to create a new ultra-low power benchmark called ULPBench. Released in September 2014, the initial version of ULPBench focuses on CPU core and RTC behaviors for 8-, 16- and 32-bit MCUs in a blend of active and low-power conditions. (See Figure 2 for example screen of ULPBench EnergyMonitor.)

Silicon Labs ULP 32-bit MCU   Article Fig2
Figure 2. EEMBC’s ULPBench enables developers to score MCU energy efficiency.

While still in its infancy, the initial release of EEMBC’s ULPBench is welcome news for the embedded industry as it provides developers with the first benchmarking tool that enables them to assess MCU energy efficiency based on objective criteria. Future versions of ULPBench will additionally focus on a common set of peripherals to provide a more comprehensive system-level view of energy efficiency. The next generation of ULPBench will support more real-world low-energy use cases, enabling developers to use the benchmarking tool to distinguish ultra-low-power MCUs with autonomous peripherals from the not-so-low-power MCU options of the world.

Alf SyvertsenAlf Petter Syvertsen is a product manager for Silicon Labs’ 32-bit EFM32 Gecko MCU portfolio. He joined Silicon Labs in 2013 following the acquisition of Energy Micro, where he had worked since 2010. While working as a digital designer at Energy Micro and now Silicon Labs, Mr. Syvertsen brought several EFM32 devices to tape-out including Wonder Gecko, Leopard Gecko, Zero Gecko and now Happy Gecko. He has a thorough understanding of the requirements for low-power MCUs, ranging from circuit design and transistor placement to marketing requirements. Mr. Syvertsen holds a master’s of science degree in nanotechnology from the Norwegian University of Science and Technology (NTNU).

Low Power Is The Norm, Not The Exception

Tuesday, October 7th, 2014

The issue of power consumption took front stage with the introduction of portable electronic devices. It became necessary for the semiconductor industry and thus the EDA industry to develop new methods and new tools to confront the challenges and provide solutions. Thus Low Power became a separate segment of the industry. EDA vendors developed tools specifically addressing the problem of minimizing power consumption, both at the architecture, the synthesis, and the pre-fabrication stage of IC development. Companies instituted new design methodologies that focused specifically on power distribution and consumption.

Today the majority of devices are designed and fabricated with low power as a major requirement. As we progress toward a world that uses more wearable devices and more remote computational capabilities, low power consumption is a must. I am not sure that dedicating a segment to low power is relevant: it makes more sense to have a sector of the industry devoted to unrestricted power use instead.

The contributions I received in preparing this article are explicit in supporting this point of view.

General Considerations

Mary Ann White, Director of Product Marketing, Galaxy Design Platform, at Synopsys concurs with my position. She says: “Power conservation occurs everywhere, whether in mobile applications, servers or even plug-in-the-wall items. With green initiatives and the ever-increasing cost of power, the ability to save power for any application has become very important. In real-world applications for home consumer items (e.g. stereo equipment, set-top boxes, TVs, etc.), it used to be okay to have items go into standby mode. But, that is no longer enough when smart-plug strips that use sensors to automatically turn off any power being supplied after a period of non-usage are now populating many homes and Smart Grids are being deployed by utility companies. This trend follows what commercial companies have done for many years now, namely using motion sensors for efficient energy management throughout the day.”

Vic Kulkarni, Senior VP and GM, RTL Power Business Unit, at Apache Design, Inc., a wholly-owned subsidiary of ANSYS, Inc. approached the problem from a different point of view but also points out wasted power.

“Dynamic power consumed by SoCs continues to rise in spite of strides made in reducing the static power consumption in advanced technology nodes.

There are many reasons for dynamic power consumption waste – redundant data signal activity when clocks are shut off, excessive margin in the library characterization data leading to inefficient implementation, large active logic cones feeding deselected mux inputs, lack of sleep or standby mode for analog circuits, and even insufficient software-driven controls to shut down portions of the design. Another aspect is the memory sub-system organization. Once the amount of memory required is known, how should it be partitioned? What types of memories should be used? How often do they need to be accessed? All of these issues greatly affect power consumption. Therefore, design must perform power-performance-area tradeoffs for various alternative architectures to make an informed decision.”

The ubiquity of low power designs was also pointed out by Guillaume Boillet, Technical Marketing Manager, at Atrenta Inc. He told me that: “Motivations for reducing the power consumed by chips are multiple. They range from purely technical considerations (i.e. ensuring integrity and longevity of the product), to differentiation factors (i.e. extend battery life or reduce cost of cooling) to simply being more socially responsible. As a result, power management techniques, which were once only deployed for wireless applications, have now become ubiquitous. The vast majority of IC designers are now making a conscious effort to configure their RTL for efficient power partitioning and to reduce power consumption, in particular the dynamic component, which is increasingly becoming more dominant at advanced technology nodes.” Of course experience by engineers has found that minimizing power is not easy.” Guillaume continued: “The task is vast and far from being straight-forward. First, there is a multitude of techniques which are available to designers: Power gating, use of static and variable voltage domains, Dynamic Voltage and Frequency Scaling (DVFS), biasing, architectural tradeoffs, coarse and fine-grain clock gating, micro-architectural optimizations, memory management, and light sleep are only some examples. When you try combining all of these, you soon realize the permutations are endless. Second, those techniques cannot be applied blindly and can have serious implications during floor planning, timing convergence activities, supply distribution, Clock Tree Synthesis (CTS), Clock Domain Crossing management, Design For Test (DFT) or even software development.”

Low power considerations have also been at the forefront of IP designs. Dr. Roddy Urquhart is Vice President of Marketing at Cortus, a licensor of controllers, noted that: “A major trend in the electronics industry now, is the emergence of connected intelligent devices implemented as systems-on-chip (SoC) – the ‘third wave’ of computational devices. This wave consists of the use of locally connected smart sensors in vehicles, the emergence of “smart homes” and “smart buildings” and the growing Internet of Things. The majority of these types of devices will be manufactured in large volumes, and will face stringent power constraints. While users may accept charging their smartphones on a daily basis, many sensor-based devices for industrial applications, environmental monitoring or smart metering rely on the battery to last months or even a number of years. Achieving this requires a focus on radically reducing power and a completely different design approach to the SoC design.”

Architectural Considerations

Successful power management starts at the architectural level. Designers cannot decide on a tactic to conserve power once that system has already been designed, since power consumption is the result of architectural decisions aimed at meeting functional requirements. These tradeoffs are made very early in the development of an IC.

Jon McDonald, Senior Technical Marketing Engineer, at Mentor Graphics noted that: “Power analysis needs to begin at the system level in order to fix a disconnect between the measurement of power and the decisions that affect power consumption. The current status quo forces architectural decisions and software development to typically occur many months before implementation-based power measurement feedback is available. We’ve been shooting in the dark too long. The lack of visibility into the impact of decisions while they are being made incurs significant hidden costs for most hardware and software engineers. System engineers have no practical way of measuring the impact of their design decisions on the system power consumption. Accurate power information is usually not available until RTL implementation, and the bulk of power feedback is not available until the initial system prototypes are available.”

Patrick Sheridan, Senior Staff Product Marketing Manager, Solutions Group, at Synopsys went into more details.

“Typical questions that the architect can answer are:

  1. How to partition the SoC application into fixed hardware accelerators and software executing on processors, determining the optimal number and type of each CPU, GPU, DSP and accelerator.
  2. How to partition SoC components into a set of power domains to adjust voltage and frequency at runtime in order to save power when components are not needed.
  3. How to confirm the expected performance/power curve for the optimal architecture.

To help expand industry adoption, the IEEE 1801 Working Group’s charter has been updated recently to include extending the current UPF low power specification for use in system level power modeling. A dedicated system level power sub-committee of the 1801 (UPF) Working Group has been formed, led by Synopsys, which includes good representation from system and power architects from the major platform providers. The intent is to extend the UPF language where necessary to support IP power modeling for use in energy aware system level design.” But he pointed out that more is needed from the software developers.

“In addition, power efficiency continues to be a major product differentiator – and quality concern – for the software manager. Power management functions are distributed across firmware, operating system, and application software in a multi-layered framework, serving a wide variety of system components – from multicore CPUs to hard-disks, sensors, modems, and lights – each consuming power when activated. Bringing up and testing power management software is becoming a major bottleneck in the software development process.

Virtual prototypes for software development enable the early bring-up and test of power management software and enable power-aware software development, including the ability to:

  • Quickly reveal fundamental problems such as a faulty regulation of clock and voltages
  • Gain visibility for software developers, to make them aware of problems that will cause major changes in power consumption
  • Simulate real world scenarios and systematically test corner cases for problems that would otherwise only be revealed in field operation
  • This enables software developers to understand the consequences of their software changes on power sooner, improving the user-experience and accelerating software development schedules.”

    Drew Wingard, CTO, at Sonics also answered my question about the importance of architectural analysis of power consumption.

    “All the research shows that the most effective place to do power optimization is at the architectural level where you can examine, at the time of design partitioning, what are the collections of components which need to be turned on or can afford to be turned off. Designers need to make power partitioning choices from a good understanding of both the architecture and the use cases they are trying to support on that architecture. They need tooling that combines the analysis models together in a way that allows them to make effective tradeoffs about partitioning versus design/verification cost versus power/energy use.”

    Dr. Urquhart underscored the importance of architectural planning in the development of licensable IP. “Most ‘third wave’ computational devices will involve a combination of sensors, wireless connectivity and digital control and data processing. Managing power will start at the system level identifying what parts of the device need to be always on or always listening and which parts can be switched off when not needed. Then individual subsystems need to be designed in a way that is power efficient.

    A minimalist 32-bit core saves silicon area and in smaller geometries also helps reduce static power. In systems with more complex firmware the power consumed by memory is greater than the power in the processor core. Thus a processor core needs to have an efficient instruction set so that the size of the instruction memory is minimized. However, an overly complex instruction set would result in good code density but a large processor core. Thus overall system power efficiency depends on balancing power in the processor core and memory.”

    Implementation Considerations

    Although there is still a need for new and more powerful architectural tools for power planning, implementation tools that help designers deal with issues of power distribution and use are reaching maturity and can be counted as reliable tools by engineers.

    Guillaume Boillet observed that: “Fine-grain sequential clock gating and removal of redundant memory accesses are techniques that are now mature enough for EDA tools to decide what modifications are best suited based on specific usage scenarios (simulation data). For these techniques, it is possible to generate optimized RTL automatically, while guaranteeing its equivalence vs. the original RTL, thanks to formal techniques. EDA tools can even prevent modifications that generate new unsynchronized crossings and ensure proper coding style provided that they have a reliable CDC and lint engine.”

    Vic Kulkarni provided me with an answer based on sound an detailed technical theory that lead to the following: “There are over 20 techniques to reduce power consumption which must be employed during all the design phases from system level (Figure 1), RTL to gate level sign-off to model and analyze power consumption levels and provide methodologies to meet power budgets, at the same time do the balancing act of managing trade-offs associated with each technique that will be used throughout the design flow Unfortunately there is NO single silver bullet to reduce power!

    Fig. 1. A holistic approach for low-power IP and IP-based SoC design from system to final sign-off with associated trade-offs [Source: ANSYS-Apache Design]

    To successfully reduce power, increase signal bandwidth, and manage cost, it is essential to simultaneously optimize across the system, chip, package, and the board. As chips migrate to sub-20 nanometer (nm) process nodes and use stacked-die technologies, the ability to model and accurately predict the power/ground noise and its impact on ICs is critical for the success of advanced low-power designs and associated systems.

    Design engineers must meet power budgets for a wide variety of operating conditions. For example, a chip for a smart phone must be tested to ensure that it meets power budget requirements in standby, dormant, charging, and shutdown modes. A comprehensive power budgeting solution is required to accurately analyze power values in numerous operating modes (or scenarios) while running all potential applications of the system.”

    Jon McDonald described Mentor’s approach. He highlighted the need for a feedback loop between architectural analysis and implementation. “Implementation optimizations focus on the most efficient power implementation of a specific architecture. This level of optimizations can find a localized minimum power usage, but are limited by their inability to make system-wide architectural trade-offs and run real world scenarios.

    Software optimizations involve efforts by software designers to use the system hardware in the most power efficient manner. However, as the hardware is fixed there are significant limitations on the kinds of changes that can be made. Also, since the prototype is already available, completing the software becomes the limiting factor to completing the system. As well, software often has been developed before a prototype is available or is being reused from prior generations of a design. Going back and rewriting this software to optimize for power is generally not possible due to time constraints on completing the system integration.

    Both of these areas of power optimization focus can be vastly improved by investing more in power analysis at the system level – before architectural decisions have been locked into an implementation. Modeling power as part of a transaction-level model provides quantitative feedback to design architects on the effect their decisions have on system power consumption. It also provides feedback to software developers regarding how efficiently they use the hardware platform. Finally, the data from the software execution on the platform can be used to refine the architectural choices made in the context of the actual software workloads.

    Being able to optimize the system-level architecture with quantitative feedback tightly coupled to the workload (Figure 2) allows the impact of hardware and software decisions to be measured when those decisions are made. Thus, system-level power analysis exposes the effect of decisions on system wide power consumption, making them obvious and quantifiable to the hardware and software engineers.”

    Figure 2. System Level Power Optimization (Courtesy of Mentor Graphics)

    Drew Wingard of Sonics underscored the advantage of having in-depth knowledge of the dynamics of Network On Chip (NOC) use.

    “Required levels of power savings, especially in battery-powered SOC devices, can be simplified by exploiting knowledge the on-chip network fabric inherently contains about the transactional state of the system and applying it to effective power management (Figure 3). Advanced on-chip networks provide the capability for hardware-controlled, safe shutdown of power domains without reliance on driver software probing the system. A hardware-controlled power management approach leveraging the on-chip network intelligence is superior to a software approach that potentially introduces race conditions and delays in power shut down.”

    Figure 3.On-Chip Network Power Management (courtesy of Sonics)

    “The on-chip network has the address decoders for the system, and therefore is the first component in the system to know the target when a transaction happens. The on-chip network provides early indication to the SOC Power Manager that a transaction needs to use a resource, for example, in a domain that’s currently not being clocked or completely powered off. The Power Manager reacts very quickly and recovers domains rapidly enough that designers can afford to set up components in a normally off state (Dark Silicon) where they are powered down until a transaction tries to access them.

    Today’s SOC integration is already at levels where designers cannot afford to have power to all the transistors available at the same time because of leakage. SOC designers should view the concept of Dark Silicon as a practical opportunity to achieve the highest possible power savings. Employing the intelligence of on-chip networks for active power management, SOC designers can set up whole chip regions with the power normally off and then, transparently wake up these chip domains from the hardware.”


    The Green movement should be proud of its success in underlying the importance of energy conservation. Low Power designs, I am sure, was not one of its main objective, yet the vast majority of electronic circuits today are designed with the goal of minimizing power consumption. All is possible, or nearly so, when consumers demand it and, importantly, are willing to pay for it.

    Next Page »