Always-On Devices

One problem with battery-powered devices is that we increasingly expect them to interact with us without us pressing physical buttons. Our phone knows it is in our pocket. We can wake it up with a wake-word. Smart doorbells need to decide if there is a person around. The main processors in these devices are usually too power-hungry to keep them on all the time. This means that we need to have a separate "always on" device (AON), which might be an actual separate helper chip or a block of IP on the larger SoC that is kept powered up while the rest of the chip is powered down. These light-weight AON hardware and algorithms typically run as a precursor to a more accurate, more compute intensive, higher-power algorithm that does the heavy lifting.

Thirty years ago in the early days of cell-phones, VLSI Technology was the manufacturer of the applications processors for Ericsson handsets (probably still called "terminals" in those days). In the earliest days, the cellular networks were analog and there were no international standards. Each country had its own standard. Or, in some cases (hi Japan) more than one standard. You can read more about that era in my post 1G Mobile: AMPS, TOPS, C-450, Radiocom 2000, and All Those Japanese Ones. One area that VLSI excelled at, which helped us keep that business for years, was that we had a very low-power real-time clock (RTC). This would always be on so that your phone didn't lose the time whenever it was not connected to a network. Also, it would be extremely annoying if it lost the time whenever you took the battery out to change it (which we did all the time in that era, phones generally came with two batteries so you could use one and charge one at the same time). So it was important to have a low-power RTC that could run for a time without any battery. Ours was apparently the lowest power one around, and could last for, I think, a week on just the power stored in a capacitor. So it was the equivalent of the always-on devices of today. And, in that era, having a chipset that could be powered down except for an RTC running in the corner of one of them was not a trivial thing to design and verify. This became critical once handsets were really handsets and not big carphones with access to a huge 12V battery.

But it is not just having low-powered always-on devices. There are clever things that can be done at the software or system level. That's why we have wake words ("hey siri" and so on) so that the system doesn't have to continuously do full speech recognition. In a similar way, when GSM came along (you can read more about that story in my post 2G: Mobile Goes Digital) one big power optimization was that with a digital paging channel (the way a phone knows that it has an incoming call) the phone can spend most of its time powered down. It only needs to wake up every couple of seconds to see if it has an incoming call since the network architecture allowed the base-station to tell the phone the equivalent of "if you have a call, I'll tell you 150ms into the next exact second"). This results in a small delay in connecting a call...but I'll bet you never noticed it and you never knew it was there.

AON Requirements and Neural Networks

These days, if you look at the applications in the above image, you can see that most of them involve some sort of AI application, meaning that the AON device is running a neural network of some sort. By definition, a small one.

AON devices obviously need to be low power, but that has the corresponding tradeoff that the computational power available will necessarily be low. As I just said, typically, these devices run some sort of neural network, but these have to be significantly smaller than typical models which are not optimized for microcontrollers. For example, the table below shows some comparisons between AON MAC counts for various typical applications. The networks are typically hundreds or thousands of times smaller.

Historically, there has been a lot of audio systems with AON devices,  but there are more and more video systems with AON, which are more complex. However, the ultra-low-power requirement doesn't go away, of course. In many cases, audio systems already exist but usage needs to be upgraded by adding another sensor modality such as vision.

Vision P1 DSP

The Tensilica Vision P1 DSP is optimized for AON (and other very low-power) applications. This is a typical usage with a Vision P1 on (always) and most of the rest of the chip powered down. When the wakeup event occurs, the rest of the chip is powered up and takes over as the main CPU, initializes all the peripherals and can now handle high-performance workloads.

• Low Power Mode (Mode 0 / Standby / Always-On)
  • Vision P1 enabled; Remaining blocks Off / Standby
  • Camera / microphone stream directly into P1
  • Vision P1 responsibilities:
  • Initializes core and boots up supporting IPs (if needed)
  • Acts as CPU
  • Runs Always-On and authentication algorithms
  • Operates in low voltage and low frequency
  • Low power / energy consumption

• Full Power Mode (Mode 1 / Active)
  • Upon Vision P1 wake up signal or external trigger
  • LX7 is booted up and takes over as main CPU
  • Boots up remaining IPs
  • SoC now able of handle high performance workloads
  • Vision P1 able to do other tasks: Vision / AI, NPU co-processor…
  • (optional) Vision P1 voltage and frequency increased for higher performance

Vision P1 DSP by the Numbers

• Architecture optimized for small memory footprint and operation in lowpower mode
• Low resolution can be supported with on-chip memory (without DDR) to save power
• Key Specifications:
  • Offers up to 400GOPS
  • 128-bit SIMD, 128/256-bit memory interface
  • 128 8-bit MAC: low end AI (lower MAC available)
  • ¼ SIMD compared to Vision P6 DSP but ½ MAC 
• 1/3 area, power and 20% higher frequency compared to Vision P6 DSP
• TensorFlow Lite Micro support
• Vision DSP Family Benefits:
  • Instruction set compatible with other Vision P6 DSP
  • Same memory AXI interface & advanced iDMA as Vision P6 DSP
  • Same software libraries as other Vision DSPs
  • Can operate as CPU / controller in AON / LP mode
  • TEE / Secure mode / Secure Boot ready

Learn More

See the Vision P1 Product Page.

See Ed Sperling of Semiconductor Engineering interview Amol Borkar on the Vision P1 and AON.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.