Productivity And The IoT

The market for devices that connect almost everything to the Internet of Things is projected to explode, creating opportunities for companies that haven’t been traditional chip developers to decide to start developing devices. Semiconductor Engineering sat down to discuss this topic with Jack Guedj, corporate VP of Tensilica products at Cadence; Bill Neifert, CTO at Carbon; Marc Evans, director of customer solutions at CEVA; Drew Wingard, CTO at Sonics; and John Koeter, VP of marketing and AEs for IP and Systems at Synopsys. What follows are excerpts from that discussion. For part one, click here. For part two, click here.

SE: What about the processor side of IoT applications and making sure it’s optimized for the the application?

Wingard: So far for the host processor, ARM is winning, so far.

Neifert: They are the best thing for lower power today because lower power dominates.

Wingard: There are plenty of people who might argue that point, Bill, but they definitely have market share.
Right now in terms of the host processor on those things, no question it’s ARM. Whether that’s the processor that’s in the ‘always-on’ or first thing woken up by the always on, the jury’s going to be out on that one for a while.

Evans: I think there’s also a question of how much of the processing gets done on the device itself versus how much gets pushed down to the cloud somewhere. One of the things that helps ARM in the cellphone and smartphone domain is that there’s a lot of processing that happens right on the device and that might not be true across the spectrum of IoT devices. One of the things we see a lot of right now is an integrated, proven, nuts and bolts platform — just establish connectivity, talk to sensors and do sensor fusion, low-power wakeup sort of functionality — that seems like nuts and bolts in a lot of the device. Then from there, does it wake up an ARM locally to do something more advanced or does it push off to a cloud?

Guedj: You’ll always need a control device. You’re always going to need some kind of processor, whether it’s an 8-bit microcontroller or something like that, which is sufficient to do the processing or a 32-bit processor certainly in smaller form factor devices. The question is, is it efficient to do that control this way, or is it more efficient to merge everything into one core to get the lowest power, or spread things to have things turn on and off, so you get the lowest power.

Wingard: One of those choices there’s been a ton of academic research in the last 15 years about the tradeoff between the cost of communication versus the cost of computation. You’re clearly going to do enough — no one is going to fail to do enough local computation to minimize the cost of the wireless communication because you lose quickly if you don’t do that. Now the question is how much more might you do?

Evans: And if you don’t have much of a display or any display, if you’re not running a wide range of apps — there’s a controller that’s doing something, but to what level does that go?

SE: What is the biggest challenge in building IoT devices today?

Wingard: It’s clear that these will end up as consumer devices and the consumer is going to decide but when we talk about the level of integration required at this point, it is a deferred cost and right now, and Jack brought up the point about people maybe using less than the most efficient implementation mechanisms, and I think that’s dead on. Right now, the problem in developing IoT devices isn’t the cost of the end chip. People can afford to be twice as expensive or three times as expensive per die as what it will be at volume, the problem is they don’t know what to build. And so anything that lets them experiment more quickly, is very attractive to them. After the last 20 years of doing integration for cost reduction’s sake, it feels weird to say this but cost isn’t the reason people integrate — they are integrating to try to enable the application so it doesn’t have to be the cheapest possible piece of silicon they can build right now. And that’s another side effect of it’s being systems companies who are doing the designs because they monetize the system not the chip. If it’s a standard products silicon company doing it, they have no choice — they’ve got to do it as a chip in the smallest possible area it could be. But that’s not where we’re at. So that’s weird. It’s very different for us.

SE: How does this impact the software side of things?

Guedj: Things are at their infancy right now. You do things like sensors and sensor fusion, and it tells you if your software is in the market or if if you have it in your hand or if you’re walking–it’s useful information but there’s tons more that needs to be done so that part of the equation is wide open and will be an immense factor in the success in the designs for IoT.

Koeter: If you think about the user interface of many of these machine to machine or wearable devices — not very sophisticated, right? From that standpoint, the software burden may be less than in application processors or in other things.

Evans: We’ve taken the TeakLite 4 DSP that does the always-listening sort of functionality, integrated the Bluetooth baseband. There’s also some sensor fusion on it. It’s a nice demonstration vehicle to show the contextual awareness, the Bluetooth communications and simple voice activation.

Koeter: Is software a big part of that solution?

Evans: It tends to be deeply embedded. That’s the things you know your end customer is not going to muck with. Certainly there’s software as part of that …

Guedj: What kind of processing do you do on sensor?

Evans: The basic taking in sensor information, contextual awareness, things of that nature.

Guedj: How do you analyze that data? How do you correlate what other people have done? You want to make some conclusion about what has happened. It’s one thing to collect data and be able to tell you a basic thing. You’re moving. You’re stopping. But now, do we know in the context you’re in, within the air that you have, whether you’re going to have a problem based on your personal health? That takes a lot of data. That data cannot reside on the standard platform – yet it needs to be somewhere in the cloud but sufficiently nimble so that it can move back and forth. That’s where those kind of software will be paramount and efficient communications-wise as you were saying, in order to enable productivity for people to say, yes, I want to use it more than, ok, I’ve burned 400 calories today, it’s interesting but I think it will get old very quickly.

Evans: Do you use that on a device that has not much of an I/O or does that get centralized and the cloud streamed to your phone, streamed to your tablet or anything else.

Guedj: Exactly. And then what do you do with it? Do you have something interesting that you come up with?

Evans: To address the other question on how much software is in the platform. Obviously, it’s a programmable platform but it’s not the type of thing we’d expect app programmers to go access. It’s typial deeply embedded.

Neifert: Towards that end though, it’s interesting, if I look on my phone, every time I look at it it’s updating 4 or 5 new programs or something like that. As you go out to the IoT, you don’t want to have to have a path to necessarily upgrade this all the time. How often do I want to reload new software in my slippers, for example. is it something that’s constantly being done? It really proves the point of making sure you get that software right.