How To Build An IoT Chip

Semiconductor Engineering sat down to discuss IoT chip design issues with Jeff Miller, product marketing manager for electronic design systems in the Deep Submicron Division of Mentor, a Siemens Business; Mike Eftimakis, IoT product manager in ARM‘s Systems and Software Group; and John Tinson, vice president of sales at Sondrel Ltd. What follows are excerpts of that conversation.

SE: There are three conflicting challenges with the IoT. First, the cost needs to come down, particularly for edge devices. Second, these devices need to be semi-customized or fully customized for different markets. And third, there needs to be more pre-processing in devices to limit the amount of data being moved around. How do we resolve these competing demands?

Eftimakis: What we’ve been trying to do is to introduce simpler processing on the edge nodes and to make that easily affordable to SoC design teams. We’re trying to make it easier to design these devices by pre-assembling the different elements in systems, which are ready-to-use and easier to customize. This also includes security, because security is an increasingly important area of IoT. We have migrated TrustZone technology from the mobile world to the IoT. We have extended that to the subsystem, making it easier to use in a subsystem context. All of this is designed to make life easier for IoT design teams. It’s a better way than to design something from scratch, assembling small bits of IP.

Fig. 1: L-R: Mike Eftimakis, Jeff Miller, John Tinson.

SE: So you’re starting with building blocks that are pre-configured and tested?

Eftimakis: Yes, and we have larger building blocks already in the process. We have done research that shows we can generate an IoT test chip within a few months from the subsystem. This is proof that if you don’t want something very custom, you can get very quick results. It’s a kind of LEGO play, where you plug in the processor, memory and data compression.

Miller: When you take apart one of these IoT edge devices, you’re looking at four domains here. You have an analog sensor or sensor. You have signal conditioning or analysis. And you have processing that does processing, or perhaps pre-processing. And then there is a communications interface, which is used to send that data up to the real world. If you look at these devices, you have the challenge of integrating most of those domains into one system. That’s a big challenge because not everyone has core competencies in all of those areas. So you have MEMS guys adding analog and digital to their designs. You have RF guys adding digital and analog to their designs. And you have some doing all four together. We’ve seen customers doing MEMS, analog, digital and RF all on one die. That’s a tremendous integration challenge. The biggest challenge is being able to take your MEMS model into analog and mixed signal simulation, and deal with RF all as one integrated system. Ultimately that’s what these devices are, and you have to pre-converge them just to be able to hit the target cost.

Tinson: It’s important to remember that many of these devices are being produced by startup companies. What’s vital to them is time to market and time to money. They’re burning cash, and there may only be a certain amount of time they have to burn that cash. The more you can use pre-built units, the more you can reduce the number of engineers required for projects and the months of development and design work. You’re really helping that company reach the market faster. There’s also less risk, because you can pre-verify parts. And you can add security, which has been tested and verified altogether. We’d prefer not to start from scratch. Ideally, we’d prefer to be tweaking and configuring and focusing on where the value is added. That’s where we should focus our design time.

SE: But a lot of these markets aren’t so clearly defined. Is there enough that can be pre-built? Or are we talking about new designs for new markets that will have to be updated in ways we don’t know about yet?

Tinson: The market the device goes into may not be known. It may go into multiple markets. That creates a real challenge for some of these IPs. For what standards should they be created and tested? It’s one thing if you know something is going into the automotive market to design it for the automotive standard. It’s another if you don’t know where the product will end up. But it’s very important to have standardization of those IPs and the level to which they’re created.

Miller: There’s a lot of customization. You can do these whole systems as a custom piece, but very early in the lifecycle you’ve got to get from time to money. So a lot of time companies will come up with a few key building blocks that they can build around, and then add a few distinct pieces that need to be done for that specific market. So if it’s a dedicated pressure sensor for truck tires, you build that as a custom piece. And over time, as the market matures, you will do higher and higher levels of integration until it’s finally one monolithic piece of silicon, which is the cheapest way to make these.

Eftimakis: In IoT we have two different effects. One is that you want to automate as much as possible to be as efficient as possible. The other movement is to add as much flexibility as possible to follow the evolution of the market. You can’t build configurability and be optimal at the same time. As an IP provider we try to serve as broad a market as possible, but we know there are constraints that need to be taken into account. You still need to leave some room for flexibility. Processes are, of course, flexible by definition. The IP that goes around that also need to be flexible. We also try to promote the fact that IP shouldn’t just meet the specs, because in IoT you may have a device that will be out in the field a long time and it will have to be upgraded regularly. We have to have new features in the future. If you design an SoC that will be in the field for 10 years, you will have to upgrade the firmware, the security, and make sure it is still usable 10 years from now. There will have to be additional processing power and memory in your design to make sure you can use it in the future.

SE: Some of these designs will end up in places you didn’t expect, too, which could include safety-critical markets. Those have completely different parameters. And we don’t know what security will be like in 10 years, so how can you possibly expect a chip to be secure a decade from now?

Eftimakis: It’s difficult to convert something that is not functionally safe to something that is. You have to design that from scratch. Security you can improve over time by upgrading the firmware. But you do need to design in features that allow you to upgrade that security. You’re making sure you can upgrade the firmware without having to change the nodes one by one.

SE: But something that is designed for a car’s infotainment system may be connected to other safety-critical systems in the future. You never worried about that in the past, right?

Eftimakis: Some people consider cars as things. But you do have to manage different levels of safety in the car and the interactions between different things.

Miller: Security and safety are both very closely related because they’re about a process rather than a product. At every level of your design you have to make sure it’s functionally safe or that it’s secure. Those things have to happen not just across the design of the semiconductor or the system, but across the design of the service they enable. So IoT security touches every part of the supply chain. We have to think about it at every level or else it will fail. It’s the same for functional safety. If you haven’t planned for it in advance, you won’t succeed. For security, that means field upgradeability, and for both it means very careful attention needs to be paid to this. It’s also a matter of upgrading the supply chain. If it’s manipulated along the way, that can be a big problem, too. Everyone has to take responsibility for functional safety and for security, or we’ll be in the mess we’re in now.

Tinson: From a design house perspective, this is not something you can deal with in retrospect. You can’t decide that a chip will be used in all environments. But if you are planning to use a chip in certain environments, you may have to figure out which IPs can be used and the levels of verification required and the sign-off rules. If you expect that a chip might be used for automotive, you may have to create something that adheres to automotive standards because you can’t go back afterward. This creates challenges when customers come in and don’t know what their end market is.

Related Stories
How To Build An IoT Chip (part 2)
Where data gets processed, how to secure devices, and questions about whether there can be economies of scale in this sector.
What Does An IoT Chip Look Like?
As the definition of IoT evolves, so do architectures.
Flexible Devices Drive New IoT Apps
Flexible technology becomes a critical component of new markets.
IoT Startups Rake In Cash
Funding is free-flowing for the field, but hurdles persist.
When Digital, Physical Worlds Merge
What the IoT will look like in the next five years, and what problems need to be solved to get there.