When software defines the product, the chip stops being the thing you build first and becomes the platform the software has to run on. That inversion is what the AI era does to silicon — and the teams, tools and cadences on each side of the hardware/software line still do not meet in the middle.
For decades the order was fixed: architect the hardware, tape it out, then enable the software on top. Software teams inherited the hardware as given — including its errata and late design changes — and usually only after silicon arrived. It worked because hardware defined the product and software adapted to it.
That order is now backwards. Software defines what a product does, and increasingly the workload is an AI model whose shape — its memory movement, its arithmetic, its data types — dictates what the hardware has to be good at. The advantage goes to whoever can understand the workload, architect custom silicon for it, and get to market quickly. Hardware has become the execution platform for software, which means the two can no longer be optimised one after the other. They have to be optimised together.
Two things changed at once. First, the workload moved to the centre: a chip is now judged by how efficiently it runs a specific class of models, so the architecture has to start from the workload and work backwards. Second, software stopped standing still. Algorithms and code now improve continuously, often with AI assistance, which means a specification frozen at architecture time is frequently obsolete before the silicon that implements it exists.
Co-design is the response, but its benefits have been understood for years without being realised. What is new is that the cost of not doing it has risen: a chip architected for last year's workload is a chip that ships slow.
Hardware and software teams run on different tools, different languages and different clocks. A hardware cadence is measured in tape-outs; a software cadence in commits. Few engineers are fluent in both, so the people who could bridge the gap are rare, and the organisations are built to keep the two apart. On top of that sits risk aversion: silicon has to be correct and auditable, so teams improve their methodology incrementally rather than replacing it wholesale, which slows the adoption of exactly the practices co-design needs.
The tools each make a compromise. Virtual prototypes are the earliest way to run software against the hardware, but they trade timing accuracy for speed and tend to arrive later in the cycle than their value would justify. Emulation is cycle-accurate but struggles to run a full, representative workload at usable speed. Performance simulation is expensive, and getting enough speed while keeping enough accuracy is a standing tension. Underneath all of it is latency in the loop — the time from a change to a trustworthy conclusion — which is what really governs how fast a team can iterate.
A specification that is a genuine shared source of truth — precise enough for humans and for tools to build against — lets software development begin before RTL is complete. High-level models, typically in SystemC, give software something to run against early, provided they are kept in step with the hardware as it changes. The decisive discipline is continuity: the same representative workload should be runnable across virtual prototype, emulation, FPGA prototype and silicon, so a result at one level means something at the next. Modular verification — breaking a system into components, replicating and connecting them — makes large workloads tractable, and continuous integration at hardware scale, including FPGA images built in the cloud on every change, shortens the loop that otherwise dominates the schedule.
AI already assists with the mechanical parts — generating RTL and testbenches — and that is genuinely useful. It is absent, though, from the decisions that matter most: the architecture-level trade-offs between performance, power, thermal, form factor and cost. Those remain human, partly because system-level constraints are hard to encode as objectives, and partly because there simply are not enough worked examples of good co-design for a model to learn optimal partitioning from. For now the experienced architect making those trade-offs is both the bottleneck and the irreplaceable part.
Designing the silicon and the software that runs on it together, from architecture onward, so partitioning, interfaces and performance are decided across both domains rather than handed sequentially from one team to the next.
Because software now defines what the product does, and AI workloads dictate what the hardware must be good at. The chip has to be architected for the workload rather than enabled for it after tapeout — and the workload keeps changing, so the two have to move together.
A high-level, often untimed model of the hardware — commonly in SystemC — that lets software development start before RTL is finished. Its value is earliness; its cost is that its timing differs from the real hardware and it must be kept in sync.
Each abstraction trades speed, accuracy and cost differently: virtual prototypes are earliest and fastest but least timing-accurate; emulation is cycle-accurate but slower; FPGA prototypes run real-time with real interfaces; silicon is final. Serious programmes use all of them, on the same workload.
AI assists with RTL creation and testbench generation. It does not yet make architecture-level trade-offs — cost, power, thermal and form-factor constraints — because there are too few historical co-design examples to learn optimal partitioning from.
Continuity: keeping one representative workload runnable across virtual prototype, emulation, FPGA and silicon, and keeping the specification a living contract both humans and tools can rely on as the software keeps improving.
If the workload should shape the silicon rather than inherit it, that is a co-design programme — and it is how Faststream engages semiconductor work.