NEW RESEARCH REPORT: Overcoming the limitations of coding agents in complex software systems

Products

Pricing

Solutions

Customers

Resources

Company

Products

Pricing

Solutions

Customers

Resources

Company

Semiconductor

Runtime context enables AI to solve complex pre-silicon bugs

It’s a big hassle when a run misbehaves and it can get very difficult (and time-consuming) to identify the root cause of complex issues in TLM.

Undo gives coding agents the runtime context they need to:

Understand complex system behavior autonomously

Identify root causes of bugs and unexpected behavior

Animated AI agent chat asked why a run gave a wrong result, finding input_queue.ref_count changed without a lock

70%

of silicon design effort goes into verification*

35%

of silicon design effort goes into debug*

Solution

Verification and architecture hit the same wall — for different reasons

Both teams need to understand exactly what a SystemC or C++ model did at runtime. What they’re blocked on is different. Here’s how Undo helps.

System verification teams

Regressions can originate in the testbench, a fast model, synthetic software load, or RTL – making it extremely hard to locate the root cause. And time spent on complex debug eats into the schedule.

System design architects

Coverage is capped, not by compute, but by functional bugs in the models themselves. Every architecture decision is made with less validation than the team would like.

PICK YOUR ROLE

System verification teams

System design architects

Business challenges

According to the Wilson Research Group, up to 70% of design investment goes into verification — and roughly half of that time goes into debug alone.

Root cause can be hiding in the testbench, a fast functional model, the synthetic software load, or the RTL — including the interaction between all of them.

Large SystemC and C++ simulation models are often opaque and multi-threaded, making them especially slow to debug with logs or waveforms alone.

Coding agents hit the same wall engineers do: without runtime context, they hallucinate plausible-sounding but wrong root causes.

How Undo helps

Record a failing regression once, then AI agents replay the exact program execution — forward and backward — instead of re-instrumenting and re-running.

Give coding agents the design-specific runtime context the agent needs to understand the software behavior when it ran: every variable, every event, every I/O, across every module.

Turn intermittent, non-deterministic failures into a repeatable, deterministic recording.

Agents move from guessing to reasoning: they explain not just what broke, but why, grounded in a recording of what actually happened.

Up to 75%

Undo customers reduce debug time in system verification by up to 75% once agents can query a full execution recording instead of inferring from logs.

How it works

The recording

Record a failing run once and capture the issue in it

Undo records the models – capturing the full execution history (from process down to instruction level) in a single run.

AI agents can use Undo to create that recording and get complete visibility into that run:

Full signal values and data flow, inspectable at any point in the timeline

Intermittent, hard-to-reproduce failures become deterministic recordings

No rebuilding models or re-running scenarios to chase a repro

Replay and reason

Agents query the recording to autonomously root cause the issue in minutes

Instead of inferring behavior from source code and logs, coding agents ask direct questions of the recording — and get evidence-based answers.

Engineers (or their AI agents) simply ask questions such as: ‘Why did this process crash?’ or ‘Where was the memory corrupted?’

AI can now reliably explain what went wrong and why - backed by what actually happened

Works with any coding agent via Undo’s MCP server that lets AI agents drive the Undo Engine to investigate Undo recordings

Grounding the AI in real runtime behavior avoids hallucination problems that plague traditional AI debugging tools. Engineers remain responsible for the final decision, but the investigation work is dramatically accelerated.

AI coding agent chat tracing a reference count back to its root cause: input_queue object changed without locking

Why models alone aren’t enough

AI = Model + Context

Scaling engineering expertise with AI

Generic LLMs — even fine-tuned ones — can’t capture the experience-based knowledge engineers apply when diagnosing failures on real silicon. Runtime context from the live design beats static training data every time. Undo provides that context, and you can’t get it any other way.

AI lacks visibility into C/C++ execution

RTL verification has waveforms — a complete picture of signal activity over time. C/C++ and SystemC have no equivalent. Without that runtime context, AI agents can only infer from source code and logs, which limits root cause accuracy.

Source code + logs only

Plausible guesses

Generic or fine-tuned LLM

Generic intelligence

Runtime context from the live design

Evidence-based answers

Trusted by leaders

  • Regression failures

    We love the recording of our regression failures! It means we can quickly debug a test failure first thing in the morning, without having to spend an hour or more reproducing the problem ready to get started. This gets our regressions passing again sooner, reducing the time the rest of the team are blocked on submissions.

  • HLS debug

    HW engineers aren’t used to HLS debug and can get easily lost if there aren’t waveforms or some temporal view. Those who are familiar with setting breakpoints in GDB find the ability to step backward and forward in time really improves and accelerates their ability to solve bugs, leaving more time for quality and PPA improvements.

  • Debug time 4x

    We estimate our debug time on issues is reduced by about 4x. This productivity improvement gives us more time back to focus on closing coverage more completely, prior to tape-out.

  • Concurrency bugs

    Concurrency bugs, such as deadlocks and race conditions, can take ages to find using traditional techniques such as logging and forward-only debugging. These kinds of bugs are pretty common in SystemC designs, where many threads can be accessing the same data and resources. With time travel debugging we can isolate these issues very quickly.

  • We love the recording of our regression failures! It means we can quickly debug a test failure first thing in the morning, without having to spend an hour or more reproducing the problem ready to get started. This gets our regressions passing again sooner, reducing the time the rest of the team are blocked on submissions.

  • HW engineers aren’t used to HLS debug and can get easily lost if there aren’t waveforms or some temporal view. Those who are familiar with setting breakpoints in GDB find the ability to step backward and forward in time really improves and accelerates their ability to solve bugs, leaving more time for quality and PPA improvements.

  • We estimate our debug time on issues is reduced by about 4x. This productivity improvement gives us more time back to focus on closing coverage more completely, prior to tape-out.

  • Concurrency bugs, such as deadlocks and race conditions, can take ages to find using traditional techniques such as logging and forward-only debugging. These kinds of bugs are pretty common in SystemC designs, where many threads can be accessing the same data and resources. With time travel debugging we can isolate these issues very quickly.

Cut debug time. Expand coverage. Ground AI agents in truth.

Accelerate system verification workflows and get to market faster

Reduce debug time from days to minutes for shorter verification cycles and faster design iteration.

Boost architectural coverage - design better chips

Quickly diagnose functional defects in simulation models. Evaluate more workloads and corner cases and improve chip architecture optimization.

Reduce the risk of releasing a broken silicon design

Ensure defects don’t remain undiagnosed during development and test and significantly reduce the risk of shipping a broken silicon chip design.

TRUSTED BY INDUSTRY LEADERS

  • Cadence
  • Juniper Networks
  • Palo Alto Networks
  • SAP
  • Altair
  • Actian
  • Siemens
  • Synopsys
  • AMD
  • Infineon
  • Cadence
  • Juniper Networks
  • Palo Alto Networks
  • SAP
  • Altair
  • Actian
  • Siemens
  • Synopsys
  • AMD
  • Infineon
  • Cadence
  • Juniper Networks
  • Palo Alto Networks
  • SAP
  • Altair
  • Actian
  • Siemens
  • Synopsys
  • AMD
  • Infineon

Want to see it on your models?

Let’s talk about your verification or architecture bottleneck

Tell us whether you’re debugging DV regressions or exploring architecture — we’ll show you what runtime context looks like on code like yours.