The software team gets an FPGA prototype of the SoC six months before silicon. It runs at 30 MHz, fast enough to boot the OS in minutes and run applications for hours, with real Ethernet cables plugged in. They find dozens of driver bugs. They also spend a week on a crash that turns out to be the prototype's own clock-domain crossing between two FPGAs, which does not exist in the real chip, where the logic sits in one clock domain.
What is an FPGA prototype good for, and what does it miss?
The obvious view is that a prototype is the chip, only slower. It is the RTL, implemented differently: split across several FPGAs, with clocks divided down, ASIC memories replaced by FPGA memories, analogue replaced or missing, and only a small fraction of signals visible. Behaviour that depends on any of those differences can appear on the prototype and not in silicon, or the reverse.
Strength | Limitation |
|---|---|
Tens of millions of cycles per second (fact V12) | Long bring-up: synthesis, partitioning across FPGAs, timing closure |
Real peripherals and cables | Clocks slower and differently related than in the chip |
Cheap enough for many software engineers | Little visibility: only signals routed to probes can be seen |
Long runs: hours of real workloads | Changes take hours to rebuild |
A stable platform for software development | Partitioning adds delays and crossings the chip does not have |
Misses: timing-dependent bugs at the real clock speed; analogue and mixed-signal behaviour; real memory timing; power behaviour.
Invents: crossings and delays between FPGAs; memory behaviours of FPGA RAMs; reset and clock sequencing of the prototype board.
Treat every prototype-only failure as a question: is it a design bug, or a prototype artefact? Reproduce it in simulation or emulation before concluding.
Practice | Purpose |
|---|---|
Prototype a stable RTL release, not every change | Rebuild cost is hours; software needs stability |
Plan probe signals and on-chip logic analysers before building | Visibility for the bugs you expect |
Keep a list of known prototype artefacts | Software engineers do not chase them |
Reproduce prototype failures on emulation or simulation | Separate design bugs from artefacts |
Practice | Purpose |
|---|---|
Prototypes for software teams months before silicon | Drivers, firmware and OS ready at first silicon |
Real-world interface testing | Cables, peripherals and compliance equipment connected |
Long-run stability tests | Bugs that appear after hours, beyond emulation budgets |
The opening story is typical: a prototype artefact costing a week. The opposite also happens. A team (illustrative) saw a rare data corruption in silicon that had never appeared on the prototype: it depended on the real memory's read timing at full clock speed, which the prototype's FPGA memories did not model. The prototype had run for thousands of hours, all of them faithful to the RTL and none faithful to the timing.
The prototype adds structures the chip does not have, such as crossings between FPGAs or different clock relationships, which can fail on their own.
The bug depends on real timing, memories or analogue behaviour that the prototype does not reproduce.
FPGA prototypes run the RTL at tens of millions of cycles per second, with real peripherals.
They miss timing, analogue and power behaviour, and add artefacts of their own.
Use them for software at speed and long runs; reproduce prototype-only failures elsewhere.