Conflicting Needs For IoT Edge Designs

Custom designs are needed for power, but economies of scale are required to control costs.


The mad rush has begun to hype the Internet of Things, but the path forward isn’t quite as straightforward as the marketers would like it to be. ICs used at the edge of the IoT—the ones that gather information to be controlled by smart phones or tablets and transmitted to devices for processing and data analytics—need to be designed differently than the initial forays into this market.

There are a several big challenges to contend with for chips used inside of those devices:

1. One size does not fit all, but economies of scale are needed to reduce costs. There are common elements such as sensors, a modicum of processing power and embedded software, but there also are unique elements in each of them.
2. More features require more power. There is a debate brewing about just how many things an edge device needs to do, but more features generally mean higher energy demands and shorter the battery life.
3. Security is essential, but it adds cost and consumes power. So far, there is no protection scheme that meets everyone’s needs for security, power and low cost.

Put in perspective, there a number of factors that conflict, forcing a lot of experimentation about how to at least reduce some of these points of contention.

“We’re trying to build a common solution for the IoT, where you have common pieces and the customer can add their secret sauce,” said Kalpesh Sanghvi, senior systems design engineer at Open-Silicon. “We’ve been developing our own cores and IPs to see how you can use it as a generic solution and integrate whichever is the best fit. There are some generic things, but what we see is that a lot of it depends on what application you are running and how often you use the CPU or MCU.”

Open-Silicon isn’t alone in trying to address this challenge. From systems vendors to Intellectual Property vendors to processor and microcontroller vendors, everyone is finding that edge devices are highly specific to application and use cases.

“Where this all gets very interesting is at the collection and end user layer,” said Mike Gianfagna, vice president of marketing at eSilicon. “Today this is being done with ASSPs and off-the-shelf parts, but the need for custom silicon will emerge. And you will want custom silicon, because a layer of dark silicon is a layer of power. It is not efficient.”

Gianfagna noted that silicon designers don’t necessarily understand system design, where the emphasis is on fast, cheap and easy designs at established process nodes. “That will create a demand for push-button, automated design. We’re going to need trillions of things with silicon, but the margins will be razor thin and they will have to be ultra efficient. So the fundamental premise is this market will not be served with standard parts. That means platforms will have to be built the hard way, where you mess it up until you get it right. That’s what happened in the cell phone market, and it’s the reason why it market is flourishing right now.”

Thinking smaller and bigger, narrow and broad
One option is for design teams to think more narrowly about devices, whether that involves limited functionality or more narrowly defined process/voltage/temperature (PVT). What does the edge device really need to accomplish, how accurately, and how often?

“These are purposeful devices that may need to do just one thing well,” said Felix Baum, product manager for embedded virtualization at Mentor Graphics. “If it’s a heartbeat monitor, it needs to measure the heartbeat every 60 seconds, not at 58 seconds one time and 62 seconds the next. The software has to be right for that device. One software solution does not fit all devices. Right now the embedded software market is very fragmented. You can’t go to customers and say your software will solve all problems.”

But not every edge device will be so simple, either. In fact, designs on some edge devices may be every bit as complex as smart phones—only different.

“There is an insatiable demand for more features, more integration and more processing, said Mary Ann White, director of the product marketing for the Galaxy Design Platform at Synopsys. “It’s coming to the point where you need more than a single microcontroller. So what you’re seeing is not all that different from a smart phone, but it will be more functionally limited. You’ll have to pare down certain functionality. That’s where multi-voltage design comes into play. You design for more shutdown blocks or operate at lower voltages to save on battery.”

IoT designs typically will have operating voltages will be between 0.7 volts and 0.5 volts, compared to the current design goals of 0.9 volts to 1.2 volts. To keep costs in line for that, White said the key will be more efficient silicon design. “Decreasing the design by one metal layer will be significant,” she said. “Adding platforms for certain things will help, too. So for a smart watch, you know it’s going to need a heart monitor. You need to build on what you know will be there.”

But engineering teams also need to consider what market they’re addressing and what the needs are for those markets.

“What will happen is you will have an Internet of cars, Internet of wearables, Internet of industrial machinery, Internet of medical, Internet of home automation, and so on,” said Charles Janac, president and CEO of Arteris. “Each will have different requirements based on different levels of design complexity, power efficiency requirements, processing power needs and security sensitivity. By all means each of these segments will require new tools and IPs to be developed, delivered and supported. This will open up lots of opportunities for existing players and new participants to deliver such needed technologies. Even simple applications will actually be quite complex in order to execute functions that customers will find compelling. “

He said one of the keys to making this all work is better use of resources that are available. “Hardware and software need to make better use the available processing and electrical power to run complex software on fairly modest hardware. Interconnect technology will play a key role in making this a reality. It’s very exciting, but it requires focusing on specific requirements for widely different use cases.”

Security concerns
Another wrinkle that will need to be addressed in these designs is security—an additional consideration at the architectural level for both power and software, and during the design phase with formal verification.

“We’re not seeing many IP security companies around,” said Open-Silicon’s Sanghvi. “Security is more important where you have human interaction. Where you don’t have human interaction, there is less chance of a security breach because it’s like a closed loop. But where you do, you need to manage the security holes. That could be a hardware or a software solution, but you need a good understanding of the problem. The challenge is that every company has its own ecosystem around the IoT and there are no common standards. Right now, everyone is trying to figure out what is the best approach. They don’t want to share use cases. The only thing they’ll share is a spec.”

This complaint has been echoed by numerous companies trying to improve security in the IoT space. As  Lawrence Loh, application engineering group director at Cadence pointed out during a recent IEEE panel discussion, “One tricky thing about security is that the hackers openly share how vulnerable something is so people can do one better, but the people who deal with those hackers don’t want to expose what they’ve found. It’s one against many. We need committees to improve the certifications, the requirements, and to communicate what are the latest vulnerabilities and how to overcome them. That’s one of the most important ways to get a handle on this and not leave it in the hands of the weakest link.”

What about the tools?
The tools to make this all work will need to be modified, as well, to meet the rather demanding and conflicting requirements of edge devices.

“Beyond the obvious issues of low power and security, successfully addressing the emerging IoT market opportunity requires new tools, IP, and methodologies that support integration of pre-verified subsystems into SoCs,” said Drew Wingard, chief technology officer at Sonics. “Design complexity, productivity, and cost issues are just as important to consider in meeting IoT design and market requirements. Today silicon vendors have difficulty playing in the rapidly moving IoT market because they don’t know exactly what to integrate until the actual device requirements are understood. Furthermore, IoT applications require very high integration to deliver attractive form factors and battery lives at acceptable cost. On the other hand, systems companies have difficulty playing in IoT because they don’t possess the full skill set needed to develop SoC designs.”

That isn’t exactly a well-defined formula for success in its current form. “The EDA and IP industries must find ways of helping IoT designers work at higher levels of abstraction where system designers can actually integrate and assemble these SoCs without learning the details at the lower levels,” said Wingard.

Michael White, director of product marketing for Calibre Physical Verification at Mentor Graphics, contends EDA existing EDA tools will suffice in the short term, but concurs that in the long term there will be new requirements across the board because of the demands for ultra low power. “There will be new DRC decks, SPICE models, and what’s appropriate for 0.5 volts or less. For IP providers, that means retooling and re-characterization. What they’re finding is that they redesign a little bit and make assumptions, but when they bring the voltage down low enough those assumptions no longer hold. It will be more about turn-on, turn-off characteristics that exhibit different behavior of IP than you might have thought would happen for standard versions.”

He noted that another problem involves older nodes that will be used for IoT devices are anything but static, and the tools that are being used there need to understand the rules that were put in place. “The folks who defined the DRC deck for 90nm and 65nm have retired,” he said. “So you want to get more out of the process, but no one understands why the rules were in there in the first place.”

  • Right on! You make excellent points, and I would add that IoT might be the perfect occasion for a really good EDA makeover. Instead of being exclusively focused on highly skilled electrical engineers with thirty years of experience in designing digital hardware, it’s time to start focusing on the rest of the world who might be interested in creating the hardware they need for maximum efficiency.

    As you say, a “higher level of abstraction” is required. But I doubt that using IP cores or HLS is going to cut it. Coming from the software world, I find that these two solutions have a lot of friction compared to what you can find in languages like Java or frameworks such as Node.js (where you pull any package you need – of course, everything is open source so that helps ^^).

    I think that EDA needs to look at a bigger picture than “who can do the best filter” and start wondering how they will build systems instead.