The Other Side of Bug Localization

Automated debugging – starting from an unexpected behavior to find a bug root-cause or a small set of possible root-causes – is a hot topic now that agentic systems are playing a bigger role in automation. Unsurprising since debug remains the most time and resource-consuming aspect of verification, in turn the most time/resource-consuming aspect of modern chip/system design. For many of us, attention is naturally biased to finding bugs in the RTL but it is already clear that root-causes are just as likely to be found in the software test infrastructure around the RTL: software models (virtual and/or HLS), reference models and the software test stack (synthetic or production tests sitting on top of firmware and maybe OS components). How can engineers or agents localize across these diverse domains?

Agentic debugging on the test stack

Verification teams and tool suppliers have a pretty good handle on methods to drive agentic debugging in RTL from what I have seen. for hardware/software verification. The same cannot be said for debug on the software side. The heart of the problem is that agents need to perform unsupervised (or semi-supervised) exploration in tracing back to potential root causes. Not a problem in RTL simulation systems which save detailed state history for later traceback, but such recording is uncommon in software debug which depends more on human driven on-the-fly debug, using gdb for example.

Gdb has worked well for many years in software debug but trips up in supporting agentic discovery. It is difficult for an agent to reason to next steps using the atomic commands available in common software debuggers. More important, the goal is to trace back from a misbehavior rather than forward (as is common in human debug). The hope had been that agents could learn enough behavior from a static analysis of the code to support such reasoning, but experience has shown that hope was too optimistic. Just as in RTL debug, agentic systems to support software debug must be able to reason from historical dynamic context in addition to static learning.

Undo is optimized for agentic software debug

Undo has been supporting this kind of debug in software applications for many years. They are already very popular in networking software development and applications teams, as one example. Less well known is that they are also popular in EDA, HLS and virtual modeling. Users comment that Undo is particularly useful when trying to track down non-deterministic behavior (thread races for example). This is possible because their debugger can trace back through a runtime recording.

Debug based on a recording is better than Gdb for regular debug but I really saw the value in a live joint debug exercise last year at C++ Con between Undo and Anthropic. Undo provides access to their tech and a recording through an MCP server. Through this mechanism an agent can reason from an observed issue using runtime context plus static code learning, tracing back progressively to one or more possible root causes. In the exercise they tracked down a crash in the Python interpreter, and discovery of a behavior which wasn’t technically a bug but also wasn’t self-evident. Examples shown were human-in-the-loop discovery, as you might expect, but significantly more efficient than conventional debug.

How could this work with RTL debug?

It would be nice to imagine a solution that could span both hardware and software in one flow, but I’m not sure that is possible today. Instead we must divide and conquer. When need to debug misbehavior arises, use agentic debug, Undo-enabled, in the software stack with a virtual reference model for the hardware. This should be valuable to debug the reference model, HLS models and test software in the early stages of design.

Later in design, when agentic RTL debug traces unexpected behavior to the hardware-software interface, mirror the same run in the software model with agentic software debug tracing back from that same symptom to potential software root causes. Agentic bug localization both in hardware and software. That must be a big step forward.

Very interesting. Undo will be at DAC (2026). DAC plan HERE or visit them at booth 858. Worth checking out, particularly since your software development teams may already be using Undo!

Also Read:

Enabling AI to Understand Complex Runtime Behavior for Accurate, Automated Root Cause Analysis — DAC 2026

Revolutionizing Hardware Design Debugging with Time Travel Technology

Taming Concurrency: A New Era of Debugging Multithreaded Code