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.
4. Multiple integrated low power radios: BTLE, zigbee. More is better here.
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.
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by