Grabbed by the API

Most companies like to talk about how new integrated circuits (ICs) enable novel applications through things like (and the list is long) low power, smaller size, higher reliability, support for more stringent environmental scenarios… higher integration, easier design layout, lower total solution cost (no one makes cheap ICs), lower weight, standard-and-beyond-standard compliance, data throughout, higher ESD immunity, low EMI—you name it. Microsemi, my employer, also consistently touts these features as part of our marketing efforts.

But let’s face it: semiconductors on their own, without anything around them, are commodities. While all the features mentioned above could be in many cases “great engineering facts,” from the customers’ perspective, it boils down to:

a) What are the minimum application requirements for all the parameters listed?

· Customers WILL NOT pay for features they don’t need.

b) How is the IC vendor’s relationship with the supply chain, including original design manufacturers (ODMs), contract manufacturers (CMs), etc.?

· If the customer is looking for a pre-cooked hardware solution, it needs to exist and have been tested ahead of design start.

c) How is the supplier’s support before and during design, and in case things go wrong?

· Yes, it does hit the fan occasionally; everybody knows it.

And here is the thing: all semiconductor vendors are aware of the three elements mentioned above; this is an old industry. Microsemi has been at it since 1959, around the time ICs were invented. The only shift over the years is how easy it is for companies to enter the market or create new products. While technology/know-how/the internet and the advent of the fabless model have democratized the industry, process shrinkage has made it exponentially costlier to design an IC, and has therefore increased the risk of failure. To make matters worse, some of the largest consumers of semiconductors have become more and more vertically integrated. Examples include Google (homegrown tensor processing units), Amazon (Annapurna Labs), Apple (PA Semi), Samsung (homegrown to be the second largest semiconductor vendor in the world), and Cisco (homegrown switch ICs). In the case of vertically integrated companies, the design error risk is still there but there is no market risk—whatever is created is consumed, if the teams being built or bought are competent.

So, the question that determines the long-term survivability of independent IC vendors is this: how can one differentiate and reach that unfair advantage everyone is looking for? The answer? Grabbing them by the API.

The application program interface, or API, is what determines how the customer interfaces with an IC: not just configuring, but programming the IC. If the IC is a system on a chip (SoC), with CPU, it may run one or more operating systems. Support for the “operating system (or OS) du jour” is naturally part of it, as most applications are OS-dependent and, in some cases, can run on a specific CPU platform, like ARM, x86, or RISC-V. But in many cases, if the OS runs in the SoC’s CPU, porting applications from one CPU to another is not a big deal. The big deal is the “extra” instructions, the application-specific features that turn the IC into an application-specific standard product (ASSP) or just an application-specific integrated circuit (ASIC).

So, when a new IC vendor tries to replace an incumbent IC vendor, the big question is not necessarily whether or not the challenger is better than the incumbent. The challenger’s benefits need to outweigh the customer’s cost and risk of re-writing software to fit the new IC’s API as well as the risk of dealing with possibly different ecosystem partners.

This boils down to time-to-market. And how did the incumbent IC supplier get to be the incumbent? By, at some point in time, being the first to offer the right features for the system builder before everybody else. So why would a system vendor risk being late on the offerings to its customers by adopting a challenger IC supplier solution? Only because the product is THAT much better.

So, the modern-day challenge IC vendors need to solve to in order to thrive is this: make a product so good that system vendors would obviously increase their profits by adopting it, or offer the first “good enough” solution… and grab the system vendor by the API!

Tags: , , , , ,

This entry was posted by Daniel Feldman on at and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply

You must be logged in to post a comment.