Pre-silicon verification and post-silicon validation have the same goal, a chip that works, but they work under almost opposite conditions. Before tapeout, tests are slow but every signal is visible and any change is cheap.
After tapeout, tests run at full speed for hours or days, but only a handful of signals can be seen and changing the hardware means a new silicon revision. Most of what makes post-silicon work hard, and most of the debug features designed into chips, follow from this trade. This article compares the platforms used before and after silicon, and the challenges that only appear once the chip is real.
7 min read | Beginner
What You'll Learn
- Compare simulators, FPGA prototypes, emulators and silicon by speed and visibility
- Explain observability and controllability and why silicon has so little of both
- Describe why reproducing a failure is harder on silicon
- Explain why bugs found in silicon are worked around rather than fixed one by one
Four Platforms
A design is run on several platforms during its life, and each trades speed against visibility:
| Platform | Speed | Internal signals visible | Changing what you see |
|---|---|---|---|
| RTL simulation | about a billion times slower than the chip | every signal, every cycle | rerun the test |
| Emulation and FPGA prototypes | about 100 to 1,000 times faster than simulation | hundreds to thousands, chosen in advance | recompile, which may take hours |
| Silicon | full speed | about a hundred per run | a new silicon revision |
An example makes the speed difference concrete: booting an operating system takes seconds on silicon, a few hours on an FPGA or emulator, and would take years in an RTL simulator. That is why long software workloads are first run in the lab, and why the bugs they expose are found there.
Observability and Controllability
Two words come up constantly in post-silicon work:
- Observability is how much of the chip's internal state can be seen. To observe a signal on silicon, its value must be routed to somewhere it can be read: an output pin, or an on-chip memory called a trace buffer. The number of pins and the size of that memory limit how much can be seen.
- Controllability is how much of the chip's behaviour can be set from outside: forcing a mode, disabling a feature, setting a register, stopping a clock. It is limited to the configuration options the designers built in.
In a simulator both are unlimited. On silicon both are fixed at tapeout.
The uncomfortable consequence: designers must decide what to make observable before they know which bugs silicon will show, and a missing signal is typically discovered only when a failure cannot be root-caused. Adding it then needs a new silicon spin. The planning chapter of this tutorial, starting with design for debug, is about making that decision well.
Quick Check
Q: A bug appears after six hours of an operating system workload on silicon. Why is it unlikely to be reproduced in RTL simulation, and what does the team need from the chip instead?
Show Answer
Six hours at full speed is far too many cycles for a simulator, which runs about a billion times slower. The team needs on-chip observability, such as trace buffers or state dumps triggered near the failure, to capture what happened inside the silicon itself, and enough controllability to reproduce it faster.
Problems That Only Silicon Has
Noise and reproducibility
A simulator gives the same result every time. Silicon does not.
A logic error may be masked by a glitch or a fluctuating supply, or may appear only in a certain temperature range. Part of debugging is finding a recipe, a set of voltage, frequency, temperature and software conditions, that makes the failure appear often enough to study. Because silicon is fast, the definition of "reproducible" is looser: a failure that appears once in a few runs is already workable.
One bug can hide the next
In software, and in pre-silicon verification, a bug is found, fixed and the search moves on. A hardware bug in silicon cannot be fixed until the next revision, and nobody can afford a new silicon revision per bug.
So when a bug is found, even before its cause is known, the team needs a workaround that avoids it, so that validation can continue. A good workaround removes the bug's effect without masking other bugs. The chapter on living with bugs covers the techniques.
Features that fight observability
Two features of modern chips work against debug. Security hardware is designed to keep keys and secrets hidden, while debug features are designed to expose internal state, so the same debug port that helps validation can help an attacker.
Power management switches off idle blocks, which can also switch off the path that carries debug signals out of the chip. Both conflicts are covered later: security in its own chapter, and power-aware debug in the planning chapter.
Physics
Only silicon has real power consumption, temperature, supply noise and process variation. That is a strength as well as a problem: electrical validation, characterization and reliability qualification are only possible on real parts.
Quick Check
Q: A team finds a bug in a cache coherency mode on the first silicon. The fix is clear, but the next silicon revision is months away. What should validation do in the meantime?
Show Answer
Apply a workaround, for example disable that mode through a configuration bit or software, and continue validating everything else on the current silicon. Waiting for the fixed revision would stall all other validation, and other bugs would then be found months later.
A Fixed Deadline
Pre-silicon schedules can stretch; post-silicon schedules usually cannot. The time from first silicon to the production release decision is fixed far in advance by the market, for example a product launch for a holiday season, and missing the window can cost revenue or the market altogether. The validation plan therefore has to find the important bugs early and keep the remaining work predictable, which is the subject of the next chapter's planning articles.
In Practice
Teams use all four platforms in sequence. Emulators and FPGA prototypes let software and firmware teams start before silicon and let the post-silicon team rehearse bring-up.
When silicon arrives, failures found in the lab are often reproduced on the emulator, where every signal is visible, once a short enough failing scenario has been found. Moving a failure back to the slower but more visible platform is one of the most common debug moves.
Common Mistakes
Mistake #1: Expecting simulator-style debug on silicon
Only signals that were made observable before tapeout can be seen. Plan the debug features as carefully as the design.
Mistake #2: Stopping validation to wait for a fix
Each silicon revision is expensive and slow. Work around the bug and keep finding the next ones.
Mistake #3: Debugging an intermittent failure without a recipe
First find the voltage, frequency, temperature and software conditions that make the failure appear reliably, then debug it.
Practice Exercise
Challenge: How Long Does a Boot Take?
An operating system boot takes 5 billion clock cycles. Assume a full-chip RTL simulator runs at 1,000 cycles per second, an emulator at 1 million cycles per second, and the silicon at 1 GHz.
How long does the boot take on each? These rates are assumptions for the exercise; real ones depend on the design and the platform.
Hint
Time = cycles / cycles per second.
Solution
Simulator: 5,000,000,000 / 1,000 = 5,000,000 s, about 58 days. Emulator: 5,000 s, about 1.4 hours.
Silicon: 5 s. The emulator makes the boot practical before silicon exists; only silicon makes it routine enough to run thousands of times.
Summary
- Simulation sees everything but runs about a billion times slower than silicon; emulators and FPGA prototypes are in between.
- Silicon runs at full speed but shows only about a hundred signals per run, all chosen before tapeout.
- Observability and controllability are designed in; missing ones cost a new silicon spin.
- Silicon failures depend on noise, temperature and voltage, so reproducing them needs a recipe.
- Bugs are worked around rather than fixed one at a time, under a schedule fixed by the market.
