ENGINEERING INSIGHT

Why bugs still reach first silicon — and what the lab does about it.

You can run a world-class verification campaign and still watch first silicon do something no simulation ever showed you. That is not a failure of the team. It is a structural fact about the gap between a model and a physical part — and understanding where that gap lives is what makes a bring-up lab fast instead of frightening.

ENGINEERING INSIGHTBy Faststream EngineeringOctober 20267 minute read

Escapes are the behaviour silicon exercises that pre-silicon verification did not reach

The model is not the world.

Verification is extraordinarily good at what it does: it proves, before you spend a tapeout, that the design is logically correct in the world the testbench describes. The catch is in that last clause. The testbench describes a model — a digital, idealised version of the part — and the real silicon is analog, variable and physical in ways the model deliberately leaves out. Timing is exact only at the corner you simulated; a supply rail is clean only in the model; two blocks that each pass in isolation can still interact badly under real traffic.

So the first source of escapes is simply that some behaviour was never in the model to be checked. No amount of simulation finds a bug that the abstraction removed before simulation started.

And simulation runs a blink of an eye.

The second source is time. A logic simulator is many orders of magnitude slower than real silicon. A campaign that runs for weeks might exercise a number of cycles the physical part burns through in a fraction of a second of real operation. Over a service life, silicon runs astronomically more.

That gap is why the diagram above has two nested shrinkages, not one. Even for the behaviour the model does capture, you only ever simulate the slice you had time to reach. Escapes live in the crescent between what silicon exercises and what you actually simulated — and that crescent is large.

What only the bench reveals.

Because of those two gaps, the bugs that survive to first silicon have a characteristic flavour. They are rarely clean logic errors — verification catches those. They are the marginal path that just misses timing when the part is hot and the voltage is low; the analog corner the model idealised; the interaction between two correct blocks under a sequence no testbench enumerated. You find them by running the real part, across real corners, under real workloads — which is the whole purpose of post-silicon validation.

This is also why characterization produces a shmoo rather than a pass/fail: the interesting answer is not “does it work” but “where is the edge, and how far is it from where we ship.”

What the lab does when it finds one.

Finding the escape is half the job; deciding what to do about it is the other half, and it is a judgement about money and schedule as much as engineering. A firmware or software workaround costs nothing in silicon but may cost performance. A metal-layer ECO fixes the problem while reusing most of the mask set, so it is cheaper and faster than a full respin — if the fix happens to live in the layers an ECO can touch. A respin is the clean fix and the expensive one: months and a mask set.

A good bring-up team is the one that roots the bug to the right place quickly — using the scan dump, on-chip trace and debug hooks that had to be designed in before tapeout — and then picks the response that fits, rather than reflexively respinning or papering over a problem that will come back.

The lesson is not “verify less.”

It would be easy to read all this as an argument that verification is futile. It is the opposite. Strong verification is exactly what keeps the escape list short enough for a lab to handle. The two are not substitutes; they cover different ground, and a part needs both. The expensive mistake is treating validation as a formality at the end — discovering, with first silicon on the bench and a ramp date looming, that no one planned the instrumentation, the corners or the lab time the debug would need.

QUESTIONS THIS RAISES

What engineers ask next.

If verification is good, why do bugs still reach silicon?

Two reasons compound. First, verification runs against a model of the part, and the model idealises away things the real silicon does — analog behaviour, coupling, process variation, timing at the true corner. Second, even for what is modelled, simulation is slow: it exercises a tiny fraction of the cycles the part will run in a single second of real operation. A bug can be absent from the model and, even if present, never reached in the cycles you had time to simulate.

What kinds of bugs are these, typically?

The ones that survive good verification tend to be analog or margin-related — a path that just misses timing at a hot, low-voltage corner — or interaction bugs where two blocks are each correct but wrong together under real traffic, or sequences no testbench enumerated. They are rarely simple logic errors, because those are exactly what verification is good at catching.

Does this mean verification is not worth it?

The opposite. Strong verification is what keeps the escape list short enough that a bring-up lab can find and fix what remains. The point is not that verification fails; it is that verification and validation cover different ground, and a part needs both. Cutting verification to save time just moves more — and more expensive — bugs into the lab.

What does the lab actually do when it finds one?

Root-cause it on real hardware — using the scan dump, on-chip trace and debug access designed in before tapeout — then choose a response in proportion to the problem: a firmware or software workaround, a metal-layer ECO that reuses most of the mask set, or a full respin. The judgement about which one fits is most of the value a bring-up team brings.

KEEP READING

Related work.

SERVICES

Bring us the difficult part.

If bring-up, characterization or a stubborn silicon bug is on your critical path, that is exactly the work we are built for. Tell us the specification, the constraint and the deadline.

Start a project The validation offering