The Virtual Platform Becomes the Substrate
A View from the Watchtower · Part Two
MachineWare is carrying the Aachen virtual-prototyping legacy into the EDA 3.0 era. The deeper point: the virtual platform is no longer a tool you use — it is the executable model the whole lifecycle runs on.
In the first part of this pair, I argued that virtual prototyping has a center of gravity, and has had one for almost fifty years: the institute Heinrich Meyr founded at RWTH Aachen, the chain of companies it produced, and the people who carried its ideas into every virtual-prototyping group in the industry. This is the other half of the argument — what the lineage is building now, and why it fits the next era of design so precisely that it almost looks like it was waiting for it.
Because here is the thing about the first wave of virtual prototyping: it was not wrong. It was early. The idea was right, the standards were sound, and the value was real for the few who could afford it. What stalled the field was not the concept. It was the implementation — and the implementation is exactly what has now changed.
01 — The honest post-mortemWhy the first virtual-prototyping wave stalled
Let's be candid about why "virtual platform" became a phrase people stopped saying out loud. The models that shipped in the ESL era shared a set of problems, and every veteran reading this knows them by heart.
They were slow — fast enough to demo, too slow to live in a continuous-integration loop. They were proprietary and binary-only — you licensed a black box, you could not see inside it, and you certainly could not extend it for the custom core your team was actually building. They were expensive — priced for the program budgets of the largest device makers, out of reach for everyone else. And despite the Lego promise of TLM-2.0, they did not interoperate cleanly; the moment you reached the off-chip interfaces that real software cares about, the standard library ran out and you were back to writing bespoke glue.
The incumbents are very good at what they do, and their platforms solved real problems for real customers. But the combination — slow, closed, costly, hard to integrate — meant virtual prototyping stayed a specialist's tool rather than the default substrate it was always meant to be. The technology went quiet not because it failed, but because the world had not yet made it indispensable.
02 — What changedSoftware now leads. Silicon is custom. AI is in the loop.
Four shifts have, in the space of a few years, turned virtual prototyping from a nice-to-have into a structural necessity.
RISC-V made silicon custom. When everyone built around a handful of fixed, licensable cores, you could wait for a vendor model. Now teams design their own instruction-set extensions, their own domain-specific accelerators, their own ISAs. A closed, binary processor model is useless to a team inventing a processor. You need a simulator you can extend — that is now table stakes, and almost nothing from the old wave clears that bar.
Software-defined everything inverted the schedule. In an automotive program, an AI accelerator, an edge device, the software is no longer something you bring up after the chip arrives — it is the product, and it has to be ready before tape-out, not after. Being late to firmware is now being late to the whole program. Shift-left stopped being a slogan and became the critical path.
Chiplets multiplied the integration surface. Heterogeneous packages mean more interfaces, more software stacks, more places for a system-level bug to hide — and a physical prototype that arrives later and costs more than ever.
And AI entered the lifecycle. This is the one that reframes everything, and I'll come back to it — because once AI is generating, exploring, and verifying designs, it needs something to act on. It needs an executable model of the system. It needs, in other words, a virtual platform.
| "The first wave asked virtual platforms to be a tool. The EDA 3.0 era asks them to be the substrate everything else runs on." |
MachineWare: the lineage, rebuilt for this era
MachineWare emerged from Meyr's old institute in 2022 — founded by Lukas Jünger and Jan Henrik Weinstock, anchored by Rainer Leupers — and it reads like a direct response to every limitation of the first wave. Where the old models were slow, MachineWare is built around a retargetable just-in-time engine. Where they were closed, MachineWare's modeling library is open source. Where they were rigid, MachineWare ships an extension SDK so you can add custom instructions in an afternoon. This is not "a faster Virtualizer." It is a generation gap.
The suite is small, sharp, and deliberately interoperable:
|
|
||
|
|
||
|
|
Notice what the open-source pieces do strategically. VCML is the answer to the Lego promise that the first wave never kept — except this time the blocks are open, the interfaces are published, and the switching cost of adopting them is close to zero. And the standards leadership is not incidental: MachineWare's CEO chairs the Accellera SystemC configuration, control and inspection working group and hosts the SystemC workshop at the major verification conferences. The company is not just using the standard; it is helping write its next chapter — the same move Aachen has been making since the COSSAP days.
04 — The fitWhere it sits in EDA 3.0 — and why that matters more than it looks
Readers of this series know the EDA 3.0 thesis: design is moving from a stack of tool-centric, siloed, human-driven point tools (EDA 2.0) to an AI-native lifecycle orchestrated across six layers, from intent all the way to yield. Map MachineWare onto that stack and the obvious answer is that it lives at the architecture-and-firmware layers — the pre-silicon software-enablement layer, where you bring up the stack before the silicon exists.
| The EDA 3.0 lifecycle — and where the virtual platform lives | ||
| L1 | Intent & Requirements | |
| L2 | Architecture & Modeling | MachineWare |
| L3 | RTL & Firmware / Pre-silicon software | MachineWare |
| L4 | Verification | |
| L5 | Yield & Physical | |
| L6 | AI Orchestration | |
That placement is correct, but it undersells the point. In EDA 2.0, a virtual platform is one tool among many — a station you visit to develop firmware early, then leave. In EDA 3.0, it becomes something categorically different: the executable substrate of the lifecycle.
Think about what the orchestration layer at the top of that stack actually needs. An AI system exploring architectures, generating firmware, or closing verification cannot act on a document or a static diagram. It needs an executable model of the system that is fast enough to run real software, open enough to instrument and read, and customizable enough to keep up with custom silicon. That description is not a wish list. It is a specification for a virtual platform — and it happens to be a precise description of what MachineWare built.
| Dimension | EDA 2.0 — VP as tool | EDA 3.0 — VP as substrate |
|---|---|---|
| Role | A station for early firmware development | The executable model the whole lifecycle acts on |
| Speed | Fast enough to demo | Fast enough to live in CI and feed AI loops |
| Openness | Binary black box, licensed per seat | Open models, published interfaces, instrumentable |
| Customization | Wait for a vendor model | Extend the ISA yourself, in hours |
| Who consumes it | A handful of firmware engineers | Architects, verification, and AI agents alike |
This is the strategic gap the incumbents have not closed. They have added AI at the tool level — a smarter optimizer here, a copilot there. What they do not have is a fast, open, customer-extensible executable substrate for the orchestration layer to stand on. You cannot build an AI-native lifecycle on a closed binary model that your own customers cannot read or extend. The substrate has to be open and fast by construction — and that is a different starting point than a thirty-year-old proprietary platform can easily reach.
|
The position, stated plainly
MachineWare is the high-speed, SystemC-native, open virtual-platform layer for the custom-silicon era — the pre-silicon software-enablement layer in EDA 3.0, and the executable substrate the orchestration layer needs underneath it. It is not an emulation box, not a generic "digital twin," not an AI-agent platform. It is the thing those things run on. |
Lineage meeting timing
There is a tidy version of this story where a clever start-up spots a gap and fills it. That is not what happened here, and the tidy version misses what makes it interesting. What happened is that a forty-five-year tradition kept refining the same hard problem — describe a processor, generate its tools, simulate it fast enough to run real software — through one hype cycle, one great consolidation, and one long quiet stretch. And the moment the industry's needs finally caught up with what that tradition had always been building toward, the latest branch of the lineage was already standing exactly where the puck was heading.
That is not luck. It is what lineage looks like when it meets timing. The company carrying the legacy forward turns out to be the one whose architecture — open, fast, extensible, SystemC-native — is the natural fit for the era that is arriving. The first wave was early. This one is on time.
In the next pieces in this series, I will get concrete about what that means for a design team deciding where to place its bets — the practical case for putting a modern virtual platform at the center of the flow. For now, the foundation: virtual prototyping is not a relic of the ESL boom. It is about to become the most-used layer in the stack — and the people building it are, once again, coming out of Aachen.
| "The first wave was early. This one is on time." |
