The Perfect Wearable SoC…?

Power is Everything
During Apollo 13 after the oxygen tank in the service module exploded forcing the crew to use the lunar module as a life boat to get back home, John Aaron – an incredibly gifted NASA engineer who was tasked with getting the Apollo 13 crew back home safely – flatly stated “Power is everything…we’ve got to turn everything off…”

His point was – the Lunar Module was burning 55 amps in steady state and it could only burn a maximum of 24 amps in order for the batteries to last the 45 hours required to get the crew back alive into earth orbit so they could then use the Command Module to parachute back to earth. I often think about that quote when working on products that require ultra low power like well…wearables! In this case it really is all about power. After an extensive worldwide tour talking to wearable SoC and OEM vendors, here is a list of the key features that end users say they want:

• Rich graphics and touchscreen functionality
• Connectivity – GPS, LTE, WiFi, BT, etc.
• LONG battery life – up to two weeks between charges
• Voice control
• Health features – biometrics
• Mobile wallet

The first two bullets are absolute POWER hogs. Let’s take a look at what I call the “power pyramid” – which shows why the third bullet is absolutely key!

Here, you see that the biggest consumer of power in a wearable is the wireless stuff, things like LTE and WiFi – but also things like GPS (I know that GPS might not be considered communications but it has an antenna and a receiver and burns power). Next comes the LCD backlight – this is always one of the worst offenders – the light for the LCD screen. After that comes the display controller – it has to refresh the display (when it is on) at 50 to 60 frames per second (let’s not debate this point – yes, you can send graphics to the display controller at any frame rate you want from 1 frame per second, or lower, up to full frame rate – but its the GPU doing the drawing. The display controller ALWAYS has to draw to the screen at the refresh rate of the screen) and to refresh the LCD it burns power like crazy.

Next comes the GPU – which draws the graphics on your LCD screen. Today’s GPUs (even small ones) are power hogs. After that comes the CPU and memory systems. Let’s look at these things one by one and see what can be done to build the perfect wearable SoC.

Communications
Here, I have one word of extraordinary coolness – Narrowband Iot (NB-IoT)…OK, two words. In order to save power, the radios in your wearable are going to have to be off most of the time. They need to be “bursty” – simply wake up – get or send what they need and shut down. Not “kind of down” – ALL the way down. When they are up and running, they need to be extraordinarily efficient in the way they handle power. NB-IoT cleverly uses the existing legacy mobile networks to address the low power wide area network markets – of which wearables certainly is a part of.
Even if NB-IoT doesn’t provide the necessary bandwidth for a wearable application, perhaps the next step up to LTE-M will – which is still lower power than LTE Cat-0 or LTE Advanced. At any rate – the capability to talk to the existing mobile wireless networks in a low power manner is here, and it will likely become prolific. Add to that Bluetooth Low Energy, super low power WiFi (HaLow – 802.11ah) and ultra low power GPS receivers all tied around exceptionally clever and efficient software and we should be able to turn this power hog into a power piglet.

LCD Backlight
Here – we just get rid of it. Just Say No. You are probably wondering what the alternative is…right? We will get to that in a moment – but the idea that we have to turn on a light to see a screen when we typically have light supplied to us essentially “for free” most of the time seems a little silly. The alternative? Sharp has some really great memory LCDs that use “transflective” illumination for the LCD. HERE is a link to a very descriptive white paper PDF from Sharp. Very cool…no light. Oh…you can ADD a backlight and control it from a light sensor (or manually) when you need it, like in low ambient light conditions, but this is a HUGE power saver.

I know what some of you are now thinking. Wait – did he say “memory” LCD? Does that mean that the image stays on the screen indefinitely after being drawn, eliminating the need to wastefully draw the same image over and over and over again when the draw rate is so much lower than the refresh rate. Yep. That’s what I am talking about. What about color? Yep – Sharp has some darn good color memory displays. What about frame rate – what if I want animation? Well, the Sharp memory displays can refresh at a rate that is suitable for full motion animation (15 – 17 fps equivalent).

Think about the case of a watch with a second hand – theoretically, you could update the screen once per second and with backlight off and using a memory display, your overall LCD power would be “noise level” compared to what it is in many of today’s wearables… So let’s say you go crazy and update the screen at 5 frames per second (which is like 200ms btw – pretty fast for us humans. The power required to do this would still be crazy low. How low? How about 25µW for a static image and 60 µW for a dynamic image. Even if you quadruple those numbers – still crazy low compared to a traditional LCD you find in today’s “high end” wearables. Yes – OLED displays are a HUGE improvement in power consumption over traditional LCD displays – but they aren’t anywhere near the numbers above and still have to be refreshed at 50 – 60 fps. Now – micro LED – THAT could be interesting…we shall see.

Display Controller
OK – so here we need a display controller that can handle “traditional” displays -or- go on a hiatus and support memory displays like the ones above. Remember that a traditional display controller must read a frame out of memory and clock it out to the LCD display at the LCD display’s required frame rate. Typically 60 fps. So, lets say the LCD display is 340×272 and is full color (24-bit RGB) – that means that you have to read 16MB from memory and pump it to the display every SECOND – even if nothing is changing on the screen! With a memory display at 15 fps – that goes down to 4MB /sec and 0MB / sec when nothing is changing on the screen (actually it is likely far less than that because you probably aren’t sending 24-bit RGB color…but I digress).

For the “perfect wearable SoC”, however, you should be able to support:

• Traditional LCDs
• OLED
• Memory Displays
• microLED

If the display controller is driving a memory display, the power requirements for the display controller should be VERY low assuming it is “off” when it isn’t updating the image on the screen.

GPU
This one is going to be controversial. The company I work for, VeriSilicon (who just recently acquired the Vivante GPU company) is one of the leading GPU suppliers in the industry for automotive, IoT, AR/VR, healthcare, and other mobile / consumer markets. 3D GPUs are near and dear to my heart, but our 2D vector graphics GPUs are nothing short of spectacular. Incredibly low power and able to deliver stunning RICH graphic experiences…I would say that for wearables – vector graphics is ideally suited.

We have created many graphically rich user interfaces from automotive to wearables using vector graphics (also jokingly referred to as 2.5D). I’m not going to debate the point much because the proof is already in the market – but consider these vector graphics samples HERE . Consider the following table:

To draw the SAME rich graphics user interface in a wearable / IoT application, our 2D vector graphics GPU is:

• 1/2 the size of our standard 2D raster GPU
• 3.5 times smaller than our “small” 3D GPU
• draws 5.5 times less power than our 2D raster GPU
• draws 8 times less power than the 3D GPU
• the driver is 1/8 the size of the 3D GPU driver

Now – before you get all “smarty pants” on me – our 2D and 3D GPUs are known to be the smallest most efficient in the world – so we are comparing apples to apples here. Also, we build and sell 2D, vector graphics AND full featured 3D GPUs so I have dogs in ALL these hunts – I am just saying that the GCNanoLiteV vector graphics GPU should warrant STRONG consideration for any wearable SoC – especially the “perfect” one.

CPU
Here, I don’t have a dog in the hunt but I would say that RISC-V is certainly something worth considering in the “perfect wearable SoC”. Consider the following table. Looks like RISC-V could be very interesting indeed and should be on anyone’s shortlist looking to build a wearable SoC – I particularly like the power numbers. For those of you who may not know, RISC-V is an “open source” RISC instruction set architecture processor. Thisis the link to the RISC-V foundation. Also, check out SiFive– they can answer all your RISC-V questions…

While we are on the subject of power, the question of operating system comes into play here. Which one to use? I would lean towards Zephyr. Zephyr is a real time operating system and an “official” project of the Linux Foundation. It sports a nano kernel AND a micro kernel architecture. It very well may be ideally suited for wearables and IoT (I think it is anyway…) You can check it out here.

So, what are my conclusions here? Here are the key technologies that I think need to be “in play” for the “perfect wearable SoC” in power consumption order.

• Narrowband IoT or CAT-M for communications
• 802.11ah HaLow WiFi
• LCD Memory Displays – display controller must support this
• 2D Vector Graphics GPU – GCNanoLiteV
• RISC-V processor consideration – although the Cortex M-Cores are pretty darn awesome (and no…they did not pay me to say that…it is just a fact). If you MUST have an A-Core – the A32 is pretty awesome too.
• Zephyr RTOS (not really an SoC feature – but can easily drive IP choices based upon RTOS features) – I personally wouldn’t necessarily look anywhere else but Zephyr but I would strongly consider adding the Google Weaveframework here.
• Oh…and last but not least – I would absolutely, positively build the “perfect wearable SoC” using FD-SOI. The ability to granularly control power by tweaking the back-gate biasing…it is just unparalleled. I would use either Samsung 28nm FDSOIor 22nm FDSOI from Global Foundries. Both are amazing and PERFECT for wearables. I did a presentation at DAC2016 about FDSOI and you can find it here.

Again, VeriSilicon is node agnostic – but FDSOI’s features just scream out for applications like wearables. Yes. We love FinFET and Bulk processes too.Well, that is the way I see it… Let the debates begin. Please be nice. If you are interested in a much more in-depth white paper about the “perfect wearable SoC” just let me know.