The Data Problem Slowing Down Semiconductor Adoption

Over the last five years, we have seen a significant increase in both the complexity of semiconductor chips and the pace at which new silicon is released.

The silent problem is that adoption of this silicon in real devices, the ones that move the world, such as cars, planes, industrial systems, and consumer products, is happening much more slowly.

An optimistic integration cycle for bringing up a platform on new silicon is still around 12 to 24 months. In more traditional companies, especially in regulated industries, it can still take 36 months to release a new device. A growing share of that time is now spent on software integration, testing, documentation, and compliance evidence.

For the world it means that there is a gap between what our devices are doing right now and what is possible. By the time the device hits the market, there are already faster, cheaper and more functionally capable chips available. And the problem snowballs, as modernising these devices would again take us back into a 12-18 months effort at the end of which we'd be back in the same position.

There is a structural flaw that blocks our ability to utilise the latest technological advances and slows progress down. The root cause is data.

The status quo

Let's recap the process flow that is usually required for integration of new semiconductor chip into a device:

Let's focus specifically on software integration. On paper this seems relatively straightforward:

• Driver and wider BSP artefacts - implementing the hardware specific software layer to connect our silicon with the OS

• Platform integration - handling our middleware layer and application

• Software testing - making sure it actually works, both in real life and via emulation

Theoretically, executing such a process should not create much trouble. In an ideal world we'd expect chip vendors to provide us with drivers and a reference BSP, so that we can relatively easily port our application and middleware to it.

But reality is quite different.

First, even if the chip vendor is doing it, the process is slow and manual. Software support pace is consistently lagging behind silicon release cycles. Development of a BSP for a new product family can easily take a year, and that's just for one target. 

Which gets me to the second point.

There are a lot of software targets. This means we need to multiply the integration effort. Each OS, RTOS, or even bare-metal target requires a specific implementation, and right now that is 1:1 manual work, with limited code reuse.

I have personally seen BSP backlogs at chip vendors and OS vendors that exceed 15 months. That means a customer evaluating new silicon today cannot expect to begin meaningful integration work until late next year. There are customers who can't move forward in even testing and evaluating silicon for their specific use case.

As a result, the work spills out and becomes part of the OEM and device developer load. 

That is not great news.

It means less reuse, duplicated work, diverging codebases, and limited portability. I have seen different teams inside the same organisation working on the same chip integration in parallel, without knowing about each other’s work.

Initiatives like the Zephyr project are attempting to solve for this, but someone still needs to write BSPs for Zephyr. And the myriad of OSs exists for a reason. This isn't a one-fits-all problem fundamentally, as different devices require different trade-offs.

Even when drivers and BSPs are available from suppliers, the problem can persist. With complex devices that utilise multi-core architectures, separated hardware for real-time and non-real-time operations, and silicon coming from multiple vendors at the same time, you end up with a lot of alignment challenges. Your peripheral drivers can be implemented differently across cores and vendors, meaning you can't have a uniform approach to handling these peripherals inside your application layer. So you must either change or rewrite these drivers.

How did this happen?

Historical performance limitations of hardware for decades meant that we had to optimise software for specific silicon, and that taught us to treat chips as independent, unique entities.

The approach made sense when we were fighting for bytes in memory and every cycle mattered. But in many systems today, the bigger bottleneck has shifted. The hardest problem is often no longer only raw compute or memory. It is integration complexity.

That old mental model still shapes how silicon integration works today, and what documentation artefacts we receive. If the core assumption remains that each chip is unique and requires human-centric handling, data ends up being built around human interaction.

Datasheets are written for human readability, not machine comprehension. Things get worse because of industry structure:

• There is no industry-agreed standard for how we describe semiconductor chips of the same class.

• Chip vendors integrate IP from multiple sources (Arm, RISC-V, Synopsys, internal designs). Each source delivers its data differently. The chip vendor consolidates all of this into a single device description, and the consolidation is not always standards-preserving

• Many large vendors have grown through acquisitions, where teams continued documenting products using their own pre-merger conventions.

• A lot of chip vendors operate in application-specific silos: automotive, general-purpose, AI, industrial, and so on.

I have seen examples of effectively the same silicon, with only a packaging or qualification difference, getting two datasheets written separately while the core content remains almost identical.

For example, compare TI’s ADS7142 and ADS7142-Q1 datasheets. From a product and qualification perspective, this separation makes sense. From a software integration perspective, it shows how little reusable structured data exists beneath the surface.

To summarise: we have a lot of non-standardised, human-centric data inputs that we are expected to use to efficiently deliver fast integration into a wide range of software targets. That does not scale.

Treat the hardware as data

We need to start treating our silicon, devices, and the applications that run on them from a data-centric point of view. What data flows the silicon enables, how that data is routed, and how it is used within the application.

In the age of AI, human-centric data delivery is doomed. Ask a coding agent to write a SPI driver for a specific part and watch it hallucinate register addresses. Ask it to write a React component and it nails it. The difference isn't the model, it's the data the model has access to.

However, just having digital datasheets will not solve all our problems. A PDF converted into HTML is still a document. A searchable datasheet is still human-centric. Even a better-structured datasheet is not enough if the underlying representation changes from vendor to vendor and chip to chip.

To meet the challenges of complex devices that utilise chips from multiple vendors, we have to stabilise representations across vendors. More importantly, we need to achieve true hardware-software decoupling by extracting the behavioural patterns of the device into a data model. Let's call it a digital twin of the chip.

Existing standards like CMSIS-SVD give us register maps. IP-XACT and SystemRDL describe IP block interfaces. Device tree captures board topology. These are valuable, but they are descriptive, not behavioural. They tell you what registers exist. They do not tell you what sequence of register writes brings a SPI peripheral from reset to a working transaction, what state a DMA channel must be in before that transaction can complete, or what errata constraints apply on a specific silicon revision. That behavioural layer is what's missing, and it's what every embedded engineer reconstructs by hand from a 3,000 page reference manual.

In this context, a digital twin is not a 3D visualisation or a simulation gimmick. It is a structured representation of how the chip behaves from a software point of view: registers, peripherals, configuration options, dependencies, constraints, interrupts, data paths, timing assumptions, and integration requirements.

This approach allows us to create a unified data layer that documents chip behaviour in machine-readable data structures.

Today, supporting N chips across M software targets is an N×M problem. Every new chip is a new manual integration for every target. Every new target is a fresh manual port for every chip. With a behavioural model that lives outside the driver code, it becomes an N+M problem. Each chip gets modelled once. Each target gets a code generation pathway built once. Generating a SPI driver for Zephyr or for AUTOSAR MCAL becomes a transformation, not a re-implementation. The same source of truth feeds every target. That's the difference between an industry that can absorb new silicon in weeks and one that takes 18 months.

Modelling chip behaviour completely is hard, and worth saying out loud. But modelling it well enough to generate the 80% of driver code that's mechanical, while leaving the truly novel quirks for human review, is tractable today. We don't need a perfect model. We need one that absorbs the repetitive work.

To reiterate:

1. Descriptive data (what the chip is) needs to live in a uniform schema that's stable across vendors, with extensions for class-specific quirks.

2. Behavioural data (what the chip does) needs to be modelled separately from any specific software implementation, so it can be projected onto any target (RTOS, bare metal, AUTOSAR, Linux) on demand.

Silicon is getting faster and more complex. Integration is getting slower. The gap between them is data. Closing that gap changes what devices the world can ship, and how quickly we can ship them.

Join me at the upcoming Embedded Online Conference, where I will dive deeper into this topic.

Sign in