Bring-up can be rehearsed months before silicon exists. Emulators and FPGA prototypes run the chip's RTL fast enough to execute the boot ROM, the bring-up scripts, firmware and even an operating system.
Running the real lab software on them finds bugs in the design, in the software and in the tools while they are still cheap to fix. This article explains how emulators and FPGA prototypes differ, what a rehearsal covers, and what it cannot show.
7 min read | Intermediate
What You'll Learn
- Compare emulators and FPGA prototypes
- Describe what a bring-up rehearsal runs and finds
- Explain how a chip is adapted to run on FPGAs
- List what a rehearsal cannot reveal
Emulators and FPGA Prototypes
Both run the design in hardware, about 100 to 1,000 times faster than RTL simulation, as in Pre-Silicon and Post-Silicon: What Changes. They make different trade-offs:
| Emulator | FPGA prototype | |
|---|---|---|
| Hardware | a large dedicated system built for verification | one or more commercial FPGAs on boards |
| Speed | slower | faster, often several megahertz or more |
| Visibility | good: many signals can be captured and changed between runs | limited: probes chosen before compiling |
| Bringing up a new design | days | weeks; partitioning and timing take effort |
| Typical use | hardware debug, long tests, early software | software development, system tests with real peripherals |
What a Rehearsal Runs
The point is to run what the lab will run, unchanged:
- the boot ROM image exactly as it will be in the mask,
- the bring-up scripts and checklist of The Bring-Up Checklist and Smoke Tests,
- firmware and drivers,
- debug software: trigger setup, trace readout, scan dump decoding,
- validation tests and test generators,
- an operating system boot, if the platform is fast enough.
When the first chips arrive, all of this is already debugged. The only new thing in the lab is the silicon.
Quick Check
Q: Why is it important to rehearse with the exact boot ROM image that will be in the mask?
Show Answer
The ROM is fixed in silicon, so a bug in it costs a mask change. Running the exact image on an emulator or FPGA, with the real boot sequence, finds its bugs while the image can still be changed for free before tapeout.
What It Finds
Rehearsals find three kinds of problem:
- Design bugs that short simulations missed. Long software runs reach states RTL tests do not, and on large processors this phase has found a small but valuable share of all pre-silicon bugs.
- Software and firmware bugs, including in the debug tools themselves.
- Debug-feature gaps. Engineers try to debug a rehearsal failure with only the chip's real debug features, as if it were silicon, and discover what they cannot see.
The third kind is the most valuable early on. A missing trace signal discovered in rehearsal can still be added; discovered on silicon, it needs a new revision.
Fitting a Chip Into FPGAs
A large chip does not fit in one FPGA, and some of its parts cannot be built in FPGA logic at all. Preparing a prototype involves:
- Partitioning the design across several FPGAs, with signals crossing between them on cables, often multiplexed.
- Replacing memories with FPGA memory blocks or external memory, with matching interfaces.
- Replacing analog parts such as PLLs, data converters and physical layers of high-speed links with simple models or external chips.
- Simplifying clocks: clock gating and many clock domains are adapted to the FPGA's clocking.
The prototype is therefore close to the chip's logic but not identical to it. Its timing, analog behaviour and physical effects are different.
What a Rehearsal Cannot Show
- Electrical behaviour: supply noise, speed paths, temperature, process variation.
- Real analog and high-speed interfaces, which are modelled or replaced.
- Full-speed effects: races between software and hardware that depend on real timing.
- Very long workloads: even a fast prototype is far slower than silicon.
These remain for silicon, which is exactly where the following chapters on functional and electrical validation pick up.
Quick Check
Q: A driver works on the FPGA prototype but fails on silicon. Name two differences between the platforms that could explain it.
Show Answer
Timing: silicon runs hundreds of times faster, so a race between software and hardware, such as polling a status bit too early, can appear only at full speed. Models: the prototype may replace a PLL, memory or physical layer with a simplified model that behaves differently from the real block.
In Practice
Shortly before tapeout, many teams hold a formal "silicon readiness" review based on the rehearsal: which bring-up steps passed on the emulator, which tests run, and which debug flows were exercised end to end. The review often produces the regression suite that runs on the first day of silicon, chosen from the tests that reached the most coverage on the emulator.
Common Mistakes
Mistake #1: Rehearsing with special software versions
Software changed to suit the emulator is not the software the lab will run. Rehearse with the real images.
Mistake #2: Debugging rehearsal failures with full visibility only
Use only the chip's own debug features on some failures, to find what silicon debug will miss.
Mistake #3: Treating a passing prototype as proof
Prototypes do not model electrical, analog or full-speed behaviour. Silicon will still find bugs.
Practice Exercise
Challenge: Plan the Rehearsal
Tapeout is in four months. You have one emulator slot for six weeks and two FPGA prototypes. Assign these tasks to the platforms: boot ROM checking, operating system boot with a real USB keyboard, debugging a hang using only the chip's trace buffer, running the smoke test suite, developing the DRAM training firmware.
Hint
Emulator for visibility and exactness, FPGA for speed and real peripherals.
Solution
Emulator: boot ROM checking with the exact image, the hang debug using only the trace buffer, and the smoke test suite, which benefit from visibility and exact RTL. FPGA: the operating system boot with a real USB keyboard and day-to-day software work. DRAM training firmware can start on the FPGA if it has a real memory interface, but its final behaviour depends on the real physical layer and must be confirmed on silicon.
Summary
- Emulators and FPGA prototypes run the RTL fast enough to rehearse bring-up with the real software.
- Emulators offer visibility and quick setup; FPGA prototypes offer speed and real peripherals.
- Rehearsals find design bugs, software bugs and gaps in the chip's debug features.
- FPGA prototypes need partitioning and replacements for memories, analog blocks and clocks.
- Electrical, analog, full-speed and very long behaviour can only be validated on silicon.
