Wearable SoC: Let DSP Do 'Always Listening' Chores

MADISON, Wis. — Wearable devices are suffering from a fatal flaw: batteries that die too fast. Developers blame the problem on the dearth of tailor-made wearable SoCs that could meet their requirements.

With that in mind, if they were to develop their own wearable SoCs, what should be their priority?

On a system level, system designers first and foremost need to rethink displays. Will Strauss, president of Forward Concepts, said the biggest power drain in a cellphone is the screen. Switching "to black and white to save power when color is not needed" is one idea. Other power wasters include "keeping WiFi on when you're not near a hotspot."

On a silicon level, Linley Gwennap, principal analyst at Linley Group Inc., calls "higher power in the application processor" the main culprit in power drain. "Processors with four or eight cores, particularly big cores, are much more power hungry than the single- and dual-core processors from a couple of years ago." Choosing a low-power processor (CPU and/or DSP) combined with wireless communications (e.g., Bluetooth, WiFi, cellular) should be a high priority in wearable SoCs, he says.

Eran Briman, vice president of marketing at Ceva, told EE Times, "Today's IoT and wearable devices are underserved by inappropriate solutions." For the moment, we should forget about using a multicore app processor to do everything, he said. Adopting a multifunctional DSP core in combination with a small MCU/CPU is one way to design a new wearable SoC.

Last week at the Linley Mobile Conference, Ceva pitched its TeakLite-4 DSP v2 architecture with 50 new instruction sets. It now can handle Bluetooth connectivity (Classic or Low Energy). That connectivity comes on top of the same single DSP core running other functions, including audio and voice software packages, always-on user interface (UI) functions, and a full suite of sensor-fusion capabilities, according to Briman.

The basic principle behind the DSP+MCU idea is to let the DSP handle the always-listening chores. The DSP triggers an MCU to wake up when necessary, thus saving the system's overall power.

In essence, Gwennap said, Ceva's DSP platform supports "always-on functions and low-power connectivity. Those are the two capabilities that are critical in wearable devices."

Let DSP listen all the time
Let's take a closer look at the tasks that consume most of the power during screen-off. According to Briman, these include Bluetooth Low Energy, sensor fusion, always-listening (voice) and always-watching (face, gesture) functions. If a single DSP core -- running at extremely low power -- can do all that, it "dramatically lowers the cost, complexity, and power consumption of chip designs for IoT, wearables, and wireless audio devices," according to Ceva.

Moto X is the first mobile device to delegate always-on to a DSP, Briman said, instead of keeping an application processor running all the time. Moto X used Texas Instruments' C55 DSP to run low-power voice recognition. The DSP is there to wake up the application processor when it hears a voice.

Power challenge for wearables. Click here for a larger image.(Source: Ceva)

But seriously, how big an issue is this always-on feature in terms of draining power in mobile devices?

Wearables are certainly on the roadmap for me and my collective, but usually we take on more down-to-earth ideas.

For a small team of freelance product designers, it is hard to convince a typical client (usually a small factory owner) to manufacture something for his own money, unless the core product concept was validated by years of high market demand. For this reason "brave new ideas" like wearable electronics are hard to sell in this market.

Our last design that we sold successfully was a plain bluetooth keyboard to which we added proper bluetooth low energy support and backlight. You can see some here: http://goo.gl/apwdpN .

Jack, excellent question. Let me clarify here. The DSP (including some Bluetooth baseband hardware), would indeed require less than 150uW to run all these functions. And yes, this is an average figure, taking into account various processing loads on the DSP at different times.

For a DSP such as the TeakLite-4 v2 it would take very few MHz to support an always-on use-case. These always-on tasks require a processor with a powerful yet power-efficient DSP instruction set, not the type you would find with existing MCUs. This yields a significant advantage in power consumption comparing a DSP and an MCU.

With regards to power comparisons; I always tend to be very cautious when comparing power of different platforms, and the most appropriate method I can recommend is: test drive it. In the case of CEVA, licensees usually take the RTL and validate it in their system design.

When comparing power, make sure you are using the same process (the numbers quoted above relate to TSMC 28nm HPM), same conditions, same libraries and same functionality. For example, PIC processors you mention are complete ICs, usually with multiple engines, large memories, external IOs, in various processes. The power they quote would not be directly comparable to an IP platform that solely deals with always-on functions.

I suspect they're claiming an averaged number. The processor probably takes a few mA but only for a few 10's(?) of microseconds and goes back to sleep. Possibly they scan every few 100 milliseconds to check if anyone spoke/did anything. That should probably place the average at around in the uA range if their sleep numbers are good.

From the article, the DSP "can continuously listen for a voice trigger, continuously watch for a face, continuously monitor the sensors, and control the BLE link with a remote device. It can also perform simple updates to the display, such as maintaining the correct time."

"Briman told EE Times the DSP consumes 0.15 mW on average to perform all these functions."

That's 50 uA at 3V. Some PIC parts can run at around 100 uA/MHz. Are they claiming PIC-like performance or worse, while managing to do all of those complicated things?

Maybe they mean 0.15W, which will deplete a Google Glasses sized battery in around 10 hours.

1. Computing power: I will need something with a higher than regular 32 bit MCU class performance. MMU is a must.

2. On-package DRAM.

3. Power consumption: less than a typical application processor <200 mW when active, less than 20 mW idle, <2.5mW in low power mode. Deep sleep, programmable wake-ups, and power management integration.

5. Minimal non-wireless connectivity option. We don't need ethernet controllers when the whole product may be smaller than RJ45 jack.

6. Small package size, low pin count. It should be solderable by equipment of a typical Chinese factory, which means no <0.5mm pins. QFP is preferable to BGA or QFN as it allows for manual soldering and, more importantly, easy rework and inspection by non-specialist assembly line worker.

7. Integrated PMIC: on die or on package. Wide input voltage range and high efficiency are important. Few programmable outputs will be good as well, especially for charge pumps to drive EL or eInk displays.

8. A properly thought through pinout with enough programmable/reroutable pins for each model. It is very important for design reuse, and to minimize PCB re-routing.

9. An option for analog drivers to directly control smaller peripherals.

I don't know if always on DSP will be really needed unless core functionality of the product will depend on real-time processing. In such cases, a standalone purpose-built DSP may be preferable.