RTL regressions have been clean for months. A gate-level run with real cell delays shows one register capturing the wrong value on a path between two flops, and the same test passes at RTL. The team asks whether this is a testbench bug, a design bug, or noise.
The signal you would look at: A mismatch that appears only in the timed gate-level run and moves with the clock arrival times, not with the random seed.
Whether you can explain why zero-delay RTL hides a race that real delays expose.
Whether you reason with launch clock arrival, clock-to-q delay, path delay and capture clock arrival, not with the waveform alone.
Whether you decide who owns the fix: timing closure, the design, or how the testbench drives signals at the clock edge.
Follow these steps in order. The order matters: each step narrows the search so that the next one is cheap.
Confirm the failure is stable: same flop, same time, independent of the seed. A seed-independent failure points at timing, not stimulus.
Look at the capturing flop at its clock edge: did its data input change before the edge, or just after it? This tells you whether new data arrived too early (a hold-type race) or too late.
Compare the clock arrival at the launching flop and at the capturing flop. If the capture clock arrives later than launch clock plus clock-to-q plus path delay, new data shoots through.
Check whether the testbench drives or samples at the clock edge with zero delay. A direct drive on the edge is a race of its own, and a clocking block with skew removes it.
Check for unknowns: a reset or an X that RTL treats optimistically may behave differently in gates.
Assign the fix: timing closure for a real hold violation, a design change for a bad clock structure, a testbench change for edge-aligned driving. Then widen the RTL environment to vary clock ratios and offsets so this class of issue is seen earlier.
A model transcript of the first part of the round. Do not memorise the words; copy the order of the moves.
Interviewer: RTL passes, the gate-level run fails on one flop. How do you decide whether it is the testbench or the design?
Candidate: First: does it depend on the seed? If the same flop fails the same way for every seed, it is a timing effect, not stimulus.
Interviewer: Same flop, same time, every seed.
Candidate: Then I open the capture flop and look at when its data input changes relative to its own clock edge. If the data changes just after the edge, the old value should have been captured, so something is arriving early or the capture clock is late.
Interviewer: The capture clock arrives about three nanoseconds after the launch clock.
Candidate: In RTL, clock-to-q is zero and both flops see the edge in the same time step, so the nonblocking assignment keeps the old value. With real delays, if launch clock plus clock-to-q plus path delay is smaller than the capture clock skew, the new data shoots through.
Interviewer: Is that a bug in the design?
Candidate: It is a timing problem on that path, usually a hold violation or a clock-tree issue, so it belongs to timing closure first. I would still check that the testbench does not drive that input at the clock edge with zero delay, because that adds a race of its own.
Interviewer: How would you catch this earlier?
Candidate: Vary clock ratios and start offsets in the RTL environment, since a fixed ratio can hide phase bugs, and keep a short timed gate-level smoke test in the regression.Blaming the testbench seed when the failure is identical for every seed.
Assuming that a clean zero-delay RTL run proves the capture order is safe once real delays exist.
Fixing the symptom by delaying the testbench instead of asking who owns the path timing.
Reading the waveform at one scale and missing that the data change is a few hundred picoseconds after the clock edge.
Work these cold, with the timer, before you rehearse the conversation.