Process · Verification & Validation
Silicon debug
Locating the root cause of a failure observed on real parts, using on-chip trace, scan dumps, JTAG access, performance counters and targeted test programs. Limited observability and non-deterministic reproduction make it far harder than simulation debug.
- Also known as
- Post-silicon debug
- Type
- Process
- Domain
- Verification & Validation, Post-silicon validation
- Also relevant to
- General Industry
Notes
The usual strategy is to make the failure reproducible first, then narrow it with instrumentation already built into the chip.
Overview
Silicon debug is the work of finding the root cause of a failure seen on real manufactured chips, whether a design bug, an electrical or timing weakness, or a problem between hardware and software, using whatever internal visibility the chip provides. It is a core part of bring-up and post-silicon validation, and it also follows failures reported by production test or customers. It is harder than debugging in simulation because only the signals made observable before tapeout can be seen.
How it works
Engineers first try to make the failure repeatable, narrowing the conditions such as voltage, temperature, clock frequency, firmware version and workload, since many silicon bugs are rare corner cases that appear only after long runs. They then gather evidence through debug features designed into the chip. Debug ports such as JTAG give a debugger access to processors, registers and memory. On-chip trace and bus monitors record instruction flow and transactions, can flag slow or wrongly privileged bus accesses, and can halt processors and start a capture when a deadlock is detected. Scan dumps shift out the state of the flip-flops after a failure, although a single snapshot says little about problems that build up over time.
With a hypothesis in hand, the team reproduces the problem in simulation, emulation or an FPGA prototype, where every signal can be seen, and then checks a fix. The outcome may be a software or firmware workaround, a published erratum, or a design change for the next silicon revision.
The central limit is that visibility is fixed at tapeout. An FPGA design can be recompiled in a day or two to add probes, but a chip cannot gain observation points without a respin taking months. Debug infrastructure therefore has to be planned early, trading area and performance against visibility, and large volumes of trace data and IP from several vendors make the search harder.
Examples
- A processor hang on first silicon traced with on-chip instruction trace to a rare interaction between two cores.
- A bus monitor flagging a wrongly privileged transaction that caused an intermittent system deadlock.
- A scan dump taken after a hang and compared with a simulation of the same test sequence.
- A failure seen only at low voltage and high temperature, narrowed down by sweeping conditions in the lab before it is reproduced in emulation.
Why it matters
Silicon debug sits on the path between first silicon and revenue: time spent chasing a failure delays production, and a missed bug risks a respin or a field problem. Silicon debug engineers, post-silicon validation teams, debug and trace architects and firmware engineers work on it together, often with IP suppliers, the foundry and the packaging house.
Related terms
Part of the Verification & Validation glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 20 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
Roles
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary