Semiconductor

Runtime context enables AI to solve complex chip 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 the issue.

Undo gives coding agents the runtime context they need to:

Understand complex system behavior and autonomously
Identify root causes of bugs and unexpected behavior.

Read AMD Case Study

70%

of silicon design effort
goes into verification*

35%

of silicon design effort
goes into debug*

*Wilson Research Group

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 evidence, 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.

Business challenges

Architects validate test workload performance by running applications on top of GPU and SoC models — but activity is constrained by limited simulation coverage.

Functional bugs in the model itself prevent enough workloads from running, so coverage often reaches only 50–60% of meaningful use cases.

Fewer workloads validated means architecture and parameter decisions get locked in with less confidence, directly impacting final chip quality.

It’s a big hassle when a run misbehaves. Many engineers get pulled into the debug process and every hour spent chasing a functional defect in the model is an hour not spent exploring the architecture.

How Undo helps

Give agentic exploration a foundation of design-specific runtime context — the complete picture of what actually happened when the model executed.

Diagnose and resolve functional defects in the model quickly, instead of guessing from source and logs alone.

Unblock more workloads, which means architects can evaluate more scenarios before parameters and architecture are finalized.

Higher coverage, evaluated earlier, translates directly into a higher-quality chip at tape-out.

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.

Talk to a Solutions Engineer

50%→80%

Resolving functional defects fast means more workloads run to completion — increasing architecture use-case coverage from 50% to 80% before a design is locked in.

Talk to a Solutions Engineer

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.

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 evidence, AI agents can only infer from source code and logs, which limits root  cause accuracy.

Source code + logs onlyPlausible guesses

Generic or fine-tuned LLMGeneric intelligence

Runtime context from the live designEvidence-based answers

TRUSTED BY LEADERS

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.