The first DCRouter SoCs arrive on boards. In the first hour they run more cycles than every simulation, emulation and prototype run of the whole project combined. On day two, one board starts corrupting packets after six hours of network traffic, and nothing in the chip raises an alarm. There is no waveform, no scoreboard and no assertion log, only a few status registers readable through a debug port and the knowledge that a fix now costs a new set of masks.
What changes when the chip comes back, and why do bugs still get there?
The obvious expectation after a thorough pre-silicon effort is that silicon will just work, and post-silicon is a formality. Every pre-silicon method has limits: simulation samples, formal is bounded by properties and depth, emulation runs RTL rather than physics, and none of them runs trillions of cycles of real software in real conditions. Silicon is where those remaining gaps become visible, all at once, in the least observable setting.
Pre-silicon | Post-silicon | |
|---|---|---|
Speed | Thousands to millions of cycles per second | About a billion: hours equal more cycles than the whole project ran |
Visibility | Every signal, if you ask | A few registers, trace ports, scan dumps (lesson 11.3) |
Control | Any stimulus, any state | Software, external interfaces, voltage, temperature and clock |
Cost of a fix | Minutes to edit RTL | Software workaround, metal-layer change, or a new mask set |
What is being checked | The RTL against the specification | The physical chip: RTL, implementation, process, packaging and board |
Kind of evidence | Verification: built right | Validation: the right thing, in the real chip and its real use (fact V3); screening each part for manufacturing defects is a separate activity, manufacturing test |
Functional escapes: corners pre-silicon stimulus never reached, rules nobody wrote as checks or properties (Parts 4 to 7).
Scale escapes: bugs needing trillions of cycles or real software and workloads (Part 10).
Integration escapes: chip-level interactions, firmware sequences, board-level interfaces (Part 8).
Electrical and physical effects: timing margins, voltage droop, crosstalk, temperature, process variation; invisible to RTL (lesson 11.5).
Specification escapes: the chip does what the specification said, and the specification was wrong for the real use (lesson 1.2).
Activity | Purpose |
|---|---|
Bring-up | Get the chip alive: power, clocks, reset, debug access, first software |
Functional validation | Run test programs and real software across features and configurations |
Electrical validation and characterisation | Margins across voltage, temperature, frequency and parts (lesson 11.5) |
Compliance and interoperability | Standards conformance and real partner devices |
Debug and root cause | From a symptom to a cause with almost no visibility (lesson 11.4) |
Errata and fixes | Workarounds, documentation, metal fixes or respins (lesson 11.6) |
A team (illustrative) treated post-silicon as a formality and prepared nothing: no test programs ready to run on day one, no debug features planned, no list of what had not been verified pre-silicon. The first silicon hang took a month to root-cause, mostly spent building the tools that could have been prepared before tape-out (lesson 11.2).
Silicon runs about a billion cycles per second, so an hour is trillions of cycles, more than all simulation, emulation and prototype runs put together.
Electrical and physical effects: timing margins at voltage and temperature, voltage droop, crosstalk, process variation.
At silicon, speed becomes unlimited, visibility nearly vanishes and fixes become expensive.
Bugs reach silicon through functional, scale, integration, electrical and specification gaps.
Post-silicon validation is a planned phase with its own strategy.