A regression test fails: how to answer the debug question

"A test failed in last night's regression. What do you do?" sounds open, but most interviewers have a checklist in mind. They want to hear that you reproduce before you guess, that you look for the first point of failure, and that you consider the testbench as a suspect, not only the design.

Re-run the same test with the same seed, the same configuration and the same build. In SystemVerilog, random stability means a given seed produces the same stimulus as long as the code that draws random numbers has not changed, so a seed is enough to reproduce most failures. If it does not reproduce, that is a finding in itself: something outside the seed changed, such as the build, a plusarg or the simulator version.

The error message tells you where the checker noticed a problem, which is often many cycles after the cause. A scoreboard mismatch on a packet may come from a corrupted write hundreds of cycles earlier. Work backwards from the error through the waveform until you find the first cycle where a signal did something the spec does not allow. Assertions close to the design shorten this search, because they fire at the point of failure rather than at the output.

Interviewers notice when a candidate assumes every failure is an RTL bug. In practice a large share of failures in a young testbench are testbench bugs, and saying so shows experience.

Send the failure to whoever owns the faulty part, with the seed, the command line and the first bad cycle, so they can reproduce it in minutes. A spec ambiguity goes to the architect, not to either side.

Then make sure it cannot come back unnoticed: add an assertion at the point of failure, a coverage point for the scenario that exposed it, and keep the failing seed in the regression. That last step is what turns one debug session into lasting protection.