Once a failure is reproducible and localized to a time window, the team needs to see inside the chip. Two tools do most of the work: trace, which records selected signals over a window of cycles, and state dumps, which stop the chip and read out the contents of its flip-flops and arrays.
This article explains how each is used in debug, how silicon state is compared with a simulator to find the first difference, and how the two tools combine.
7 min read | Advanced
What You'll Learn
- Set up a trigger and capture window around a failure
- Use a scan dump to read the full state at one cycle
- Compare silicon state with a simulator to find the first difference
- Combine trace and state dumps in one debug flow
Trace Around a Trigger
On-chip trace, described in On-Chip Trace, records chosen signals into a buffer. A trigger decides when to stop recording: an address match, an error flag, a counter reaching a value, or a signal from another block through the cross-trigger logic.
The buffer can keep cycles before the trigger, after it, or both. For a failure, the usual choice is cycles before the trigger, so the events leading to it are captured. Debug often repeats the run many times, moving the trigger earlier or choosing different signals, until the captured window contains the first wrong event.
Quick Check
Q: The trace shows a wrong value already in a register at the start of the captured window. What should be done next?
Show Answer
The error happened earlier than the window. Move the trigger earlier, for example to the last write of that register, or trace the signals that produce the value, and run again until the window contains the moment the value went wrong.
State Dumps
A scan dump stops the clocks at a chosen cycle and shifts out every scan flip-flop through the scan chains, as in Debug Access: JTAG and Scan. Array dumps read memories such as caches and register files through their test interfaces.
A dump shows everything at one moment, where trace shows a few signals over time. Dumps are destructive for the run: after shifting, the state is disturbed, so the run usually has to be repeated to look at another cycle.
Comparing With Simulation
The most powerful use of a state dump is comparison. The failing test also runs in RTL simulation or a reference model, to the same cycle. The two states are compared, and the flip-flops that differ are mapped back to signal names.
This only works if the silicon run is cycle-reproducible and the simulation starts from the same state. Teams often load a dump taken earlier in the run into the simulator, so it only has to simulate the last few thousand cycles instead of billions.
Dumps at several cycles find the point where silicon and simulation first diverge. Between the last matching cycle and the first mismatching one lies the error. The differing bits at that point name the logic involved.
Quick Check
Q: Silicon and simulation states match at cycle 10,000 and differ at cycle 12,000 only in one cache controller's state machine. What does this suggest about the cause?
Show Answer
Between those cycles the silicon stopped following the RTL in that controller. That points to an electrical problem, a defect, or a netlist that differs from the RTL, rather than a bug in the RTL itself, which would show up in simulation too. The next step is to narrow the cycle further and trace the controller's inputs.
Putting Them Together
A typical flow uses both. Trace narrows the time window and shows the sequence of events.
A dump at the end of the window, compared with simulation, shows which state is wrong. A second trace run on the signals around that state shows how it went wrong. The result is usually a short simulation that reproduces the failure, which designers can then debug with every signal visible.
In Practice
Scan dump and comparison infrastructure is a major part of debug software: mapping millions of scan bits to signal names, loading dumps into simulators, and comparing states automatically. It must be ready at first silicon. Building it after a hard failure appears costs weeks.
Common Mistakes
Mistake #1: Triggering only on the final symptom
Move triggers earlier until the first wrong event is inside the window.
Mistake #2: Comparing dumps from non-reproducible runs
Without identical cycles, every bit can differ for harmless reasons.
Mistake #3: Leaving the scan-to-signal mapping until it is needed
Prepare mapping and comparison tools before first silicon.
Practice Exercise
Challenge: Narrow the Divergence
Silicon matches simulation at cycle 1,000,000 and differs at 1,064,000. Each dump-and-compare run takes 30 minutes.
How many runs find the first differing cycle to within 1,000 cycles? Once there, the trace buffer holds 2,048 cycles. What is the final step?
Hint
The interval is 64,000 cycles; halve it each run.
Solution
64,000 to 1,000 is a factor of 64, so 6 runs, 3 hours. The final step is one trace run triggered at the start of that 1,000-cycle window on the signals of the differing state, which shows exactly the cycle and events where the error happens.
Summary
- Trace records chosen signals around a trigger; triggers move earlier until the cause is captured.
- Scan and array dumps read the full state at one cycle but disturb the run.
- Comparing dumps with simulation finds the first cycle and the state where silicon diverges.
- Trace and dumps together usually produce a short failing simulation.
