by Noel O’Riordan and Tommy Mullane, S3 Semiconductors

When you’re designing sensor node devices destined for the industrial internet of things (IIoT), chances are they need to be battery-powered. And given the number of these expected to be deployed, and their often-remote locations, changing or charging a battery frequently isn’t an option. Your device, therefore, needs to be exceptionally energy-efficient, which demands you design everything from the overall system to its individual circuits to minimize energy use.

The challenge is that anyone energy-related design decision is likely to have knock-on effects elsewhere. And then there are less obvious things that can play havoc with battery life. For example, while we know the RF transmitter will generally be a big energy user, it can sometimes be the receiver or power consumption during sleep mode that causes the battery to drain fast. We’ll explore this below.

Creating an optimal design

The good news for designers is that by following a number of overarching principles, you’ll be well on the way to creating an energy-optimized product.

Firstly, using a single custom integrated circuit (IC) is cheaper, smaller and more power-efficient than using 2D-IC or 3D-IC multi-chip packaging. This integrated, system-on-chip (SoC) approach cuts down on the number of power-hungry input/output (I/O) drivers that would be needed on a standard, circuit-board-based implementation.

Duty cycles

Next, you need to understand how the duty cycle affects energy use over your device’s lifetime. Every microjoule you draw from the battery matters when you’re aiming for very long lifespans, but then it isn’t feasible to create a device that only ever consumes a few microwatts at a time.

Instead, planning your duty cycle enables your device to do things that require more significant amounts of power for brief periods, and offset these with savings at other times.

Optimizing the RF system

Let’s look in more detail at the RF subsystem, one of the most power-hungry parts of your device. Controlling how much power the transmitter consumes is relatively straightforward: simply shut it down after delivering the required data. But the receiver may remain active, perhaps because of timing uncertainty, to wait for acknowledgments from the device(s) to which it sent the data, or to listen for other incoming messages. Consequently, though the receiver uses less instantaneous power than the transmitter, you may find it uses more over your product’s total lifespan.

To maximize efficiency, you can put as much of your circuitry as possible in a low-activity state, until your RF receiver detects a signal. You can also cut the time your receiver is active – though this will make your device less responsive to commands from outside.

Processor and memory

Elsewhere, it’s essential you address the duty cycle of your processor core and memory subsystem. While many designs rely on the processor to run the software that underpins fundamental activities (collecting sensor data or passing this to the transmitter, for example), this work is typically straightforward, meaning it doesn’t need the processor. Instead, consider using a programmable state machine or custom ICs. These can operate without the processor, and use much less power. Consequently, you don’t need to power your memory either.

Sleep time

When you consider how long IIoT nodes are likely to spend in “sleep” mode, it’s important to look at energy usage during these periods: what may seem like relatively small amounts will add up to something very significant over a device’s lifetime.

Current leakage in subsystems that must continue to operate is a particular issue. Think about using real-time clocks and nanoamp-level interrupt controllers. In certain situations, it can be tempting to disable interrupts for external events, and only run the real-time clock. This isn’t always the best option, however, because it requires your system to wake regularly to check for any inputs that may have occurred. By choosing an interrupt controller with sufficiently low energy requirements, it may be better to keep it running, so you can respond to things as they happen.

Next, what do you do with temporary data when your processor and memory are powered down? A retention register and memory-cell combination is one option, though this will lead to some power leakage. An alternative is to store important data in non-volatile memory (NVM), rather than using leakage-prone SRAM and registers. NVM enables quick access to the data when you power your system back up.

As ever, though, making the right choices can be tricky: A process that’s set up to minimize leakage and supports high-density NVM might not deliver the performance that efficient, on-chip RF modules require. And if you then go for a discrete RF transceiver and factor in the energy needed to shift data to it, you’ll likely negate or even outweigh the power savings you’ve achieved by implementing on-chip NVM. Look carefully at your application’s requirements to decide which is the best approach for your custom SoC.

Active element optimization

Let’s not forget the components that generally need to remain active. Little details, such as whether you multiplex inputs into an analog-to-digital converter (ADC), affect the way you architect these circuits. For example, the trade-off that sigma-delta ADCs offer between energy efficiency, precision, and physical footprint may seem attractive. But this type of ADC isn’t suited to multiplexing; a successive approximation (SAR) ADC often performs better in this sort of use case. Modern SAR ADCs offer exceptionally low energy usage per bit per conversion (you’re looking at tens of femtojoules).

Don’t forget your front-end analog circuits, such as the buffers and amplifiers that condition signals prior to conversion. These see significant use and can require a lot of power. You can typically cut the energy both your ADCs and front-end circuitry use by optimizing things based on the amount of bandwidth and accuracy you need.

Tying it all together

Using power-aware design techniques will help you bring your subsystems together in an effective SoC, where circuits and subsystems activate when needed, and can be shut down without impacting areas that must remain operational.

Following standards – including the Unified Power Format (UPF) – can help, though attention to detail at various levels remains essential. Imagine two subsystems (A and B) that need to run concurrently. Physical limitations may dictate that A and B sit in a bigger power island that incorporates subsystems C and D, which aren’t needed when A and B operate. To ensure your SoC works, testing must make sure the full island powers up in the right way, without exceeding the power budget. If this isn’t possible, you may need to alter your power-control architecture, perhaps moving subsystems C and D to another power island.

Lastly, look out for on-chip noise, which could lead you to further improvements around your power islands. For example, you could use a low-noise low-dropout regulator to power independent mixed-signal sections, and once you’ve taken the measurement or communicated the data, switch to a more efficient DC/DC converter for analysis.

Custom ICs: Frequently the best option

These examples demonstrate some of the complexity and intricacy involved in optimizing energy efficiency in IIoT sensor nodes. In many cases, correctly designed custom integrated circuits are the best option, both in terms of cost and energy usage. Anyone designing sensor nodes for the IIoT should, therefore, ensure they have access to expertise around implementing mixed-signal ICs.

 

About the authors

O’Riordan is a Senior Staff Design Engineer at S3 Semiconductors.  He has over 20 years’ experience in the field of mixed-signal integrated circuits.  He has worked at ITALTEL prior to joining S3 Semiconductors in 1996.  Noel has a Bachelor of Engineering and Master of Engineering Science degree from University College Dublin, Ireland.  He is also an Adjunct Senior Lecturer in Electronic Engineering at University College Dublin.

 

Tommy Mullane is a Senior Systems Architect at S3 Semiconductors.  He received the B.E. degree in Electronic Engineering from the National University of Ireland, Dublin (UCD) in 1997. He has worked in research in optoelectronic devices and received a Masters in Technology Management from UCD in 2006. From 2000 to 2014 he worked for a Dublin based start-up called Intune Networks — on next-generation optical Telecommunication systems, working in a variety of technical disciplines, from optics to chip design, software, and systems. He holds 5 patents and has published a number of papers.