In one synthetic early-access run, a 47-failure regression on a 32-bit compute block included an assertion caused by a timing model that drove data on the same rising edge the DUT sampled it. The resulting X-propagation looked like an RTL defect until the waveform exposed a testbench race.
That distinction is the false failure problem. A simulation failure can come from correct RTL surrounded by an incorrect harness, constraint, reset sequence, or clocking model. In a batch of 47 failures, the log rarely identifies the source. Triage must establish whether the design produced an illegal value or the testbench created an illegal input state.
Four recurring sources of false failures
Most cases we see fit one of four categories.
Harness timing mismatch. A SystemVerilog testbench may drive a bus on the rising edge while the DUT samples that bus on the same edge. The race violates the effective setup and hold window, producing X-values and assertions at an interface boundary. The failure is not evidence of incorrect RTL logic. It is evidence that the stimulus timing does not match the DUT contract.
Uninitialized inputs. Inputs left undriven through reset remain X. Those values propagate through state machines and combinational logic, causing assertions at simulation time 0 or immediately after reset deassertion. The useful clue is an X on a DUT input that the testbench should have initialized, not an unexpected transition deep in the design.
Bus protocol misuse. A transaction generator can emit an invalid byte-enable pattern, an address alignment that this DUT does not accept, or a control sequence in the wrong order. The DUT may correctly flag the violation in its AXI or other bus checker. The source is still the testbench if the stimulus was not legal for this implementation. A checker firing inside the DUT does not, by itself, make the DUT responsible.
Clock-domain crossing artifacts. Sampling an output from the wrong clock domain, or driving an input relative to the wrong clock, can activate metastability models and spread X-values into assertions. This is a testbench construction error that produces a genuine simulator failure without requiring an RTL fix.
Why logs encourage the wrong diagnosis
A failure log records that a signal violated an assertion. It does not record whether RTL logic generated the value or whether the testbench placed the DUT in an impossible state. Every failure therefore resembles an RTL bug until someone traces the cause.
That trace crosses two hierarchies. The engineer follows the assertion through RTL nets and processes while also checking the driver, transaction generator, clocking block, reset sequence, and constrained-random assumptions in the testbench. For a block with several interfaces, this is a substantial amount of context for every failure.
Seed behavior adds another clue, but not a verdict. A real RTL defect often recurs when the design reaches the same state. A race or constraint problem may appear only for some stimulus sequences, so the failure signature changes with timing and seed. Conversely, a valid but unusual sequence can expose a real design defect only once. Repetition raises confidence; it does not prove source.
What Failure Explainer can classify well
ChipAgents' Failure Explainer examines the log, the assertion, the waveform or trace, and the path back through the hierarchy. It looks for whether the failing value terminates at a DUT boundary driven by the testbench or originates in internal RTL logic. That structural distinction is useful for known harness patterns.
Protocol misuse often has a clean signature. The assertion belongs to a bus-functional model or interface checker, and the offending transaction is traceable to the stimulus generator. The agent can mark the event as probable testbench error, leaving the engineer to verify the constraint and rerun rather than begin a JasperGold or RTL investigation.
Initial-condition failures are similarly recognizable. A failure near simulation time 0 or reset release, combined with X-values on an input that should have a defined value, supports the classification "X-propagation from uninitialized testbench input." The corrective action is usually to initialize the driver or reset sequence.
Repeated failures can also be grouped. If the same assertion fires across seeds with similar traces, Failure Explainer can reduce 18 instances to one representative case. The engineer checks the representative, then confirms that the remaining 18 failures share the same root cause instead of opening each waveform separately.
Where classification needs an engineer
Novel protocol interactions are a known weak point. A non-standard extension may permit a transaction that looks suspicious at the interface but is legal for the specification. If that transaction exposes a state-machine defect, an agent may blame the testbench because the failure ends at the boundary. The waveform and protocol definition still require human review.
Reset behavior can be ambiguous too. A design specification may call an input don't-care during reset release. One engineer may treat an assertion in that window as a testbench issue because the driver relied on an unspecified value. Another may expect the RTL to contain X-propagation. The agent should report the ambiguity, not manufacture certainty.
We are not saying an agent can prove that every interface failure belongs to the harness. We are saying it can rank evidence, expose the stimulus path, and reserve full investigation for cases where the evidence is mixed.
The dangerous error is a false positive classification: labeling a testbench failure when upstream RTL logic actually produced the bad interface value. That sends the team toward a constraint fix while the design defect remains. False negatives, which send engineers into RTL work for a harness problem, waste time but are less likely to hide a bug. For this reason, the confidence threshold should be higher when the proposed action would suppress RTL investigation.
A triage framework for regression runs
ChipAgents assigns each failure to one of three practical buckets.
High-confidence harness failure: the structural signature matches a known category, the failure is at the interface, and its timing or initialization pattern supports a testbench cause. Fix the driver, constraint, clocking, or reset sequence, rerun, and confirm that the failure disappears. Do not spend the first debugging pass in the RTL.
Probable RTL issue: the trace begins in internal RTL logic, does not match known false-failure signatures, and recurs for comparable design states across seeds. Investigate the RTL and check whether the logic is correct for that state.
Ambiguous: the path crosses testbench and RTL in a way that does not identify ownership, or the behavior is new enough that the agent lacks a useful pattern. The engineer reviews the complete waveform, protocol rules, reset assumptions, and block micro-architecture. This should be the smallest bucket, but it should not be forced to zero.
The gain is reduced triage time, not removal of failures. Sorting 47 events into three action paths is faster than treating every event as an unknown. In a testbench under active development, initialization gaps and protocol constraints may place a large fraction in the harness bucket. On a mature testbench, fewer failures may be false, but grouping and prioritization still reduce duplicate analysis.
The classification also improves through correction. An engineer can override an agent result and record why the source was different. On the next regression, that feedback supplies a block-specific pattern. By the third or fourth run, classifications for recurring failure modes should be more useful, while novel interactions remain candidates for direct review.
In practice, the most valuable output is often not "RTL" or "testbench," but the evidence supporting the label: assertion location, driver ownership, reset phase, clock relationship, X-propagation path, and cross-seed signature. That evidence lets a small verification team decide which waveform to open first and which constraint to inspect before tape-out pressure turns noise into schedule risk.