The Customer EDA Forgot: Why Software and Firmware Teams Are Still Waiting for Silicon

WATCHTOWER BRIEF · VIRTUAL PROTOTYPING · EMBEDDED & FIRMWARE

AiT × MACHINEWARE × CRAFTIFAI · A VIEW FROM THE WATCHTOWER

For thirty years, electronic design automation has been built, priced and funded around one customer: the hardware team. Software and firmware teams, now as large an engineering effort as the hardware on most silicon programs, have been left to license what they can and build the rest themselves.

Ask a VP of Software at a silicon company when their team really starts working on a new chip, and the honest answer is rarely “at architecture.” It is usually “when something runs.” For some teams that means an emulator slot borrowed from hardware verification. For others it is an FPGA prototype that shows up months after RTL is stable, or a virtual platform whose models arrived late and run too slowly to boot the full stack. For too many, it still means first silicon.

That should strike us as odd. On most modern SoC programs the software and firmware effort rivals the hardware effort, and the software stack is what the end customer actually experiences. Yet the industry that exists to automate semiconductor design has spent three decades treating the people who build that stack as an afterthought.

I have spent my career on both sides of this, selling EDA at Synopsys and building silicon at Intel, so this is not an outsider's complaint. It is an observation about incentives.

Why has EDA focused on hardware instead of software?

Follow the money. EDA revenue is concentrated where the risk is most expensive: pre-silicon hardware verification. Simulation, formal, emulation and hardware prototyping exist because a hardware bug that escapes to tapeout can cost a mask set and a quarter. That fear is real and measurable, and the incumbents have priced their products against it very effectively. Three vendors hold roughly three quarters of the market, and their growth tracks the verification burden of ever larger designs.

Software enablement has never carried that premium. A software bug found on silicon is painful, but it rarely forces a respin, so it has never commanded the same budget. R&D follows revenue, and revenue follows hardware risk. We looked at the forces behind this in The Economics of EDA: Who Actually Owns the Forecast? and How EDA ROI Shapes Semiconductor Tool Decisions. Spend is decided by who owns the budget and what risk it retires, and the software organization has rarely owned either.

Even the hardware assets that could serve software are allocated to hardware first. Emulation capacity is bought to verify RTL. Software teams get nights and weekends, if the queue allows.

What happened when EDA vendors did try to serve software teams?

The incumbents' main answer has been virtual prototyping: fast, instruction-accurate models of a system that let software run before silicon exists. The idea was right. The execution has been starved, and software leaders will recognise the symptoms.

None of this reflects a lack of talent at the incumbents. It reflects a product line that has always been a small part of the business and has been funded accordingly. We traced the history in The Aachen Lineage and its follow-up, The Virtual Platform Becomes the Substrate.

Why do semiconductor software teams end up with a patchwork of tools?

Because no single supplier gives them what they need, software organizations assemble it themselves. One SoC program can easily carry a commercial virtual platform for some subsystems, an in-house QEMU fork, homegrown C models of custom accelerators, FPGA boards for performance work, borrowed emulator time for anything that needs cycle accuracy, and finally the bring-up lab.

Each of those environments has its own model of the chip, its own debug flow and its own owner. None of them agree completely. Keeping them consistent is a permanent tax on the software organization, and when a model drifts from the RTL, every result it produced quietly loses value.

That is the bifurcation. The hardware organization runs on an integrated, heavily funded tool chain. The software organization runs on whatever it could license and whatever it could build.

Who is responsible for firmware in the semiconductor supply chain?

In practice, nobody upstream. EDA vendors ship tools. IP vendors ship RTL, a verification environment and, at best, a reference driver for a reference board. The firmware that makes silicon usable, from boot and power management to security, link training, telemetry and manageability, is left to the chip company, and then often again to the OEM building the system.

That firmware sits squarely on the critical path. Silicon can arrive on schedule and still not be shippable, because a link will not train on every reference platform, power states are unstable, or attestation is incomplete. We looked at a sharp example in The Firmware Under the Fabric: PCIe 7.0, CXL 4.0 and the Bring-Up Gap, and at the broader pattern in Accelerating Firmware Integration in Embedded Systems and One Spec, Every MCU: Rethinking IoT Firmware.

Firmware teams are usually far smaller than the RTL teams they serve, and each generation typically starts with a hand port of the last generation's code once the hardware description settles. The time-to-market and quality cost of that is absorbed silently, program after program.

What does the software gap actually cost a silicon program?

Anyone who has watched twenty engineers from a supplier and a customer crowd into a lab for days, chasing a problem a model could have reproduced in minutes, knows what this costs. We described that scene in Chips to Systems, Until the System Actually Ships.

Why is this becoming untenable now?

Two curves are moving against software teams at once.

Time to market is compressing. AI accelerators and data center silicon are moving toward annual cadences, and interconnect standards double their bandwidth every two to three years. There is no slack left in the schedule to absorb a software team that starts late.

Complexity is compounding. RISC-V lets teams invent their own instructions and accelerators, which no vendor model covers out of the box. Chiplets multiply the interfaces, software stacks and failure modes in a single package. And in automotive, industrial and the data center, software-defined products make the software the product rather than an accessory to it.

A tooling model built around hardware verification, with software enablement as an underfunded side line, cannot keep pace with either curve.

What does the alternative to the EDA 2.0 “golden cage” look like?

The incumbent platforms are excellent at what they were built to do, and for hardware verification they remain the standard. For software and firmware teams, though, they have become a golden cage: polished, expensive, and designed around someone else's priorities.

In our EDA 3.0 framework, the alternative is not a better point tool. It is a lifecycle where intent, architecture, firmware and verification share executable models, and where AI acts on those models rather than on documents. For software and firmware teams that comes down to a short list of requirements.

A new set of companies is building to exactly that list. Two of them are AiT clients, and they address the two halves of the problem.

MachineWare: fast, open virtual platforms for pre-silicon software

MachineWare was spun out of RWTH Aachen's Institute for Communication Technologies and Embedded Systems in 2022, the same institute that seeded much of the virtual prototyping industry. Its product line reads like a direct response to the shortcomings of the first wave.

For a software organization the value is practical. SIM-V runs unmodified target software, including firmware, operating system kernels and applications, fast enough to live in a CI pipeline (the founders' DVCon paper covers the architecture). Because VCML is open and the extension SDK is in your hands, your team can model a custom core or accelerator without waiting on a vendor. MachineWare platforms already integrate with commercial embedded toolchains such as TASKING, and the company works with RISC-V core providers including Andes and Nuclei.

Read more on AiT's MachineWare page.

CraftifAI: AI-generated firmware, validated on target

CraftifAI goes after the half of the problem EDA never touched. Its CraftifAI Orbit platform is a multi-agent AI system for embedded software, and it is deliberately silicon-agnostic. FirmGen generates firmware from a hardware description and requirements, then builds, flashes and validates it on the target in a closed loop, with vendor SDKs already indexed. Orbit also covers perception-pipeline generation and edge AI deployment for camera, robotics and IoT products.

Two details matter to a silicon software organization. It deploys on-premises as well as in the cloud, so unreleased hardware descriptions never have to leave the building. And it targets the repetitive plumbing that consumes firmware teams every generation, such as drivers, peripheral bring-up, management and telemetry layers, so the engineers who know the hardware best can spend their time on the parts that differentiate it.

CraftifAI was founded in 2025 by Pratik Sharda and Yashwant Dagar, and raised a $3M seed round led by Ankur Capital in February 2026. For more on how the platform applies to specific domains, see The Firmware Under the Fabric, One Spec, Every MCU and From Model to Motion: The Perception-Pipeline Bottleneck in Edge AI, or AiT's CraftifAI page.

Why do these two belong in the same conversation?

Put them side by side and the shape of a software-first flow becomes visible. A fast, open virtual platform gives firmware a target long before silicon exists. AI-generated firmware gives that target something real to run early, and can be regenerated when the hardware description changes. Software and firmware validation can then start near architecture, run continuously, and arrive at first silicon with much of the bring-up already done.

That is what shift-left was always supposed to mean. It simply was never funded by the companies selling the tools.

Frequently asked questions

What is pre-silicon software development?

Pre-silicon software development is the practice of writing and validating firmware, drivers, operating systems and applications against a model of a chip before physical silicon exists, typically using virtual platforms, emulation or FPGA prototypes. Its goal is to have software ready, and hardware bugs exposed, by the time first silicon arrives.

What is a virtual platform or virtual prototype?

A virtual platform is a fast, functional software model of a processor-based system, usually built on the SystemC TLM-2.0 standard, that runs unmodified target software. It trades cycle accuracy for speed so that full software stacks can boot and run, and so tests can run in continuous integration.

Why haven't EDA vendors solved pre-silicon software enablement?

EDA revenue is concentrated in pre-silicon hardware verification, where the cost of an escaped bug is a respin. Software enablement has historically been a much smaller line of business, so it has received less investment, leaving models late, slow and tied to each vendor's own platforms.

Who is responsible for firmware when a chip uses third-party IP?

In most cases the chip company. IP vendors typically supply RTL, a verification environment and reference drivers, while production firmware for boot, power management, security, link training and manageability is written by the silicon vendor and often adapted again by the system OEM.

How does AI-generated firmware help silicon software teams?

AI firmware platforms such as CraftifAI's FirmGen generate firmware from a hardware description and requirements, then build, flash and validate it on a target in a closed loop. That gives each new chip variant a working, reviewable baseline instead of a hand port of the previous generation.

What is EDA 3.0?

EDA 3.0 is AiT's term for the shift from tool-centric, siloed electronic design automation to an AI-native lifecycle that connects intent and requirements through architecture, firmware, verification and yield, with shared executable models at its core.

AiT represents MachineWare and CraftifAI in North America. If your team is living with any of this, I would be glad to hear how it shows up in your programs, and to set up a technical session with either company. Reach me directly at simon@ai-techsales.com.

FURTHER READING ON THE WATCHTOWER BRIEF

Sources: MachineWare product information via machineware.de, VCML on GitHub and DVCon proceedings; CraftifAI funding via The SaaS News. Product capabilities described per MachineWare and CraftifAI. AiT is the North American sales representative for both companies.