editor's blog
Subscribe Now

Differentiating Your IoT Widget – in Hardware

iStock_000019503663_Medium.jpgWhat does it take to be successful as a maker of an Internet-of-Things (IoT) edge-node product? This question doesn’t have an obvious answer, partly because there are many contributors to success. But in a discussion with Open Silicon at the recent IoT DevCon, it became clear to me that taking their view into account makes for two opposing forces – forces they’re trying to unify.

On the one side, there are numerous companies trying to jump into the IoT fray. The IoT involves many technologies, and many of these companies don’t come to the party as experts in all of them. So platforms are a common way to get designers up and running as quickly as possible.

Such platforms pre-package many of the technology bits – that’s the point. The good news is that you don’t have to futz with those bits to get things working, and you can focus on domain-specific functionality and get to market quickly. The bad news is that, if everyone uses such platforms, then there is little room left for differentiation, since most of the underlying plumbing is the same.

That might not be an issue in the early days. If you’re the first guy to do a rattlesnake early-alert app for hikers, then that’s your differentiation; no one else does it. Simple. But once you have competition, if you’re all using similar platforms, then your only real differentiation is your app. Anyone ever notice the user interfaces on phone apps? Yeah, they’re dead dumb simple because fat thumbs can’t poke small buttons and over-40 eyes can’t read tiny print. (Hint: Google – or any – maps… little help?) So there’s not much room to differentiate in the app itself.

Open Silicon says that, even if you can use lower-level software to differentiate, the economics don’t work out. (I’m taking that at face value; I haven’t seen their math, nor have I gone through the process myself.) Their assertion is that you need to customize in hardware to differentiate in a way that will pay dividends.

They’re trying to ease IoT SoC development by providing the building blocks for an IoT edge node, from the sensor interface (not the actual sensor) through to the wireless radio, and then work with their customers to establish customization, implemented in hardware, that differentiates the end product. The idea is that, based on the IP already available to Open Silicon (either their own or via IP subs), they can spin something up very quickly. While not typical, they had one tier-1 customer that finished a design from spec to tapeout in six months. And, because most of this can be done on older process nodes (in the 65 – 180-nm range), mask costs aren’t as astronomical as might be feared on an aggressive node.

Their focus tends to be more industrial, so their radio preferences are LoRa for longer range (based largely on a relationship they have with Semtech) and WirelessHART (industrial-strength features over the 802.15.4 radio standard that’s familiar via Zigbee)*.

Differentiating via hardware can be a bold move, especially in a new market, where change is rapid and hardware change is not rapid. This probably isn’t a strategy for a small company with moderate volumes, and I assume that they’re not stating that only companies large enough to afford custom (or customized) SoCs will ever make money. In fact, a large company might have the capacity to do their designs in-house rather than using an outside partner like Open Silicon, so there’s this middle profile of customer that could command large volumes but require outside services.

In addition, the IoT is very much of an agile play: get something out there, see what works, fix what doesn’t. And do it with quick iterations. Accomplishing that with a hardware differentiation angle could be a tough play. But if you can manage it, there may be some money to be made if Open Silicon’s assertion is correct.

Leave a Reply

featured blogs
May 2, 2025
I can safely say that I've never seen a wheeled-legged robot that can handle rugged terrains, muddy wetlands, and debris-strewn ruins like this...

featured paper

How Google and Intel use Calibre DesignEnhancer to reduce IR drop and improve reliability

Sponsored by Siemens Digital Industries Software

Through real-world examples from Intel and Google, we highlight how Calibre’s DesignEnhancer maximizes layout modifications while ensuring DRC compliance.

Click here for more information

featured chalk talk

Vector Funnel Methodology for Power Analysis from Emulation to RTL to Signoff
Sponsored by Synopsys
The shift left methodology can help lower power throughout the electronic design cycle. In this episode of Chalk Talk, William Ruby from Synopsys and Amelia Dalton explore the biggest energy efficiency design challenges facing engineers today, how Synopsys can help solve a variety of energy efficiency design challenges and how the shift left methodology can enable consistent power efficiency and power reduction.
Jul 29, 2024
233,982 views