Vidi: Record Replay for Reconfigurable Hardware

Record/replay — capturing a running execution so you can deterministically re-run it later — transformed software debugging and testing, but no practical version existed for FPGAs running real workloads on real hardware, because recording every signal on every clock cycle is far too heavy while recording less loses what you need to replay faithfully; this paper (University of Michigan and UC Santa Cruz — Gefei Zuo, Jiacheng Ma, Andrew Quinn, Baris Kasikci) presents Vidi, the first record/replay system for real-world FPGA applications on hardware, which exploits the fact that FPGAs already talk over transaction-based protocols that hide cycle-level timing, so it records only transaction-level inputs and enforces only the necessary orderings among transaction events — replaying faithfully at just 1.98 percent performance slowdown and 5.48 percent resource overhead on Amazon EC2 F1.

The argument in one glance

Problem

FPGAs need software-like debugging tools, and that means record/replay

Field-programmable gate arrays are chips you program with your own hardware design, and they are increasingly used to accelerate cloud and data-center workloads. To develop for them productively, engineers want the same kind of agile, iterative workflow they have for software — run something, watch it misbehave, and reproduce the exact misbehavior as many times as needed to understand and fix it. In software, the key building block for that is record/replay: you capture a program's execution, including the nondeterministic events that shaped it, so you can deterministically re-run the exact same execution later for debugging, testing, and analysis. A record/replay system for FPGAs would unlock the same ecosystem of tools for hardware development. But no practical record/replay existed for real-world FPGA applications running on actual hardware, so FPGA developers were left without one of the most powerful debugging aids that software engineers take for granted.
What people did

Record the FPGA cycle-accurately, or record only a little

The natural approaches copy hardware-simulation practice. You can record cycle-accurately: capture the value of every signal on every clock cycle, so replay is a perfect reproduction of the electrical behavior. Or you can go the other way and record only a small amount of coarse information, hoping it is enough to reconstruct what happened.
Why it fell short

Cycle-accurate recording is far too heavy; recording too little cannot replay faithfully

Cycle-accurate record/replay captures far too much information. Storing every signal on every cycle imposes huge storage and performance overheads, so it does not scale to real applications running on hardware at speed — it is really a simulation-style technique, not a deployment one. Going coarse fixes the overhead but records too little: it misses the information actually needed to reproduce the execution, so the replay diverges from the original run and cannot be trusted. Both extremes fail the real goal, which is to faithfully replay real-world FPGA executions running on real hardware at acceptable overhead. What is missing is a way to record exactly the information that determines an FPGA application's behavior — no more, no less — so that replay is both faithful and cheap.
This paper's idea

Record and replay at the level of transactions, not clock cycles

Vidi is the first record/replay system for real-world FPGA applications running on hardware. Its key observation is that widely-used FPGA communication protocols (such as the AXI channels an FPGA uses to talk to its host and memory) are built around well-defined input/output transactions that deliberately hide cycle-specific timing from the developer. That means an FPGA application's behavior is determined by the transactions it exchanges and the necessary orderings among transaction events — not by the exact clock cycle each signal changed. Vidi builds on this in two parts. First, the transaction determinism insight: it tracks and enforces only the necessary orderings of transaction events across record and replay, rather than pinning down every cycle, which is enough to reproduce the execution faithfully. Second, coarse-grained input recording: a mechanism that uses the transaction abstraction to identify exactly which signals in a communication channel affect the application's semantics, and records only the transaction-level information — the signal values at a transaction's start and end events and its content — instead of every signal every cycle. This is more efficient than cycle-accurate recording and more effective than recording too little. Vidi also automatically detects any divergences between a recorded run and its replay and includes techniques to remove them. On Amazon EC2 F1 with 10 applications and two use cases, it adds only 1.98 percent performance slowdown and 5.48 percent resource overhead.

Why this problem is worth solving

FPGAs have moved from niche prototyping into mainstream acceleration, and the productivity of building for them now depends on having software-grade debugging tools.

Record/replay is one of the most valuable techniques software engineers have. The idea is simple but powerful: while a program runs, you capture its execution — in particular the nondeterministic events (inputs, timing, concurrency) that made this run come out the way it did — and store enough to deterministically re-run the exact same execution afterward. Because the replay is faithful, you can attach a debugger, single-step, add logging, run analyses, or reproduce a rare failure on demand, all against a bug that might otherwise appear once in a thousand runs. This capability underpins a whole ecosystem of debugging, testing, and analysis tools for software. FPGAs, which are increasingly used to accelerate real workloads in data centers, badly need the same agile workflow: a hardware engineer wants to reproduce a misbehavior on real hardware and study it repeatedly, not guess from a single fleeting occurrence. A record/replay system is the foundational piece that makes that possible for FPGAs. Until Vidi, there was no practical one for real applications running on real FPGA hardware, so an entire class of development tools that software takes for granted had no hardware counterpart.

The reason it is hard is that the obvious ways to record an FPGA sit at the wrong level of detail.

An FPGA is a sea of signals changing on every clock edge, so the most literal way to capture an execution is cycle-accurately: log the value of every signal on every cycle. That gives a perfect reproduction, but it captures enormously more than you need, and the cost of storing and streaming all that data is so high that it cannot keep up with a real application running at full speed on hardware — it is a technique suited to slow simulation, not live deployment. The opposite reflex is to record only a little, but then you have no principled way to know whether what you kept is enough. Miss a signal or an ordering that actually mattered, and the replay quietly diverges from the original execution — it does something different — which makes it useless for debugging, because you are no longer studying the bug you set out to reproduce. The real target is faithful replay of real-world executions on real hardware at low overhead, and neither extreme reaches it. The crux is figuring out precisely which information determines an FPGA application’s behavior, so you can record that and nothing else. Vidi’s answer comes from the structure of how FPGAs communicate, which turns a vague coarse-recording idea into a principled one.

What people did before, and where it broke

Cycle-accurate record/replay. Capture every signal on every clock cycle so replay is a perfect electrical reproduction. Where it broke. It records far too much — the storage and performance overhead is enormous, so it does not scale to real applications running on hardware; it is really a simulation-era technique, not a deployment one.
Coarse, ad-hoc recording. Record only a small amount of information to keep overhead down. Where it broke. It records too little, missing information that actually determines the execution, so the replay diverges from the original run and cannot be trusted for debugging.
Hardware simulators and waveform dumps. Reproduce behavior by re-simulating the design and inspecting signal waveforms. Where it broke. Simulation runs far slower than hardware and does not reproduce the real deployed execution on the actual FPGA and its real inputs, so it cannot capture bugs that only show up at speed in the field.
The gap. No record/replay system existed that captured exactly the information determining a real FPGA application’s behavior — enough to replay it faithfully on real hardware — while keeping performance and resource overhead low enough to deploy.

How Vidi works

Recording and replaying an FPGA at the transaction level

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Reproduce a real execution faithfully so you can study it as many times as you need. The foundational goal of Vidi is the same one that makes record/replay so valuable in software: turn a fleeting, once-seen execution into something you can deterministically re-run, so debugging and testing become repeatable instead of a matter of luck. For FPGAs, that means capturing a run on real hardware and replaying exactly that run, rather than an approximation or a slow re-simulation. Capturing enough of a real execution to reproduce its behavior deterministically later, so tooling can be applied to it after the fact, is the same ambition the work on end-to-end application cloning for networked cloud services covered elsewhere on this site pursues, recreating a workload’s behavior faithfully enough to study it elsewhere. Vidi brings that ambition to reconfigurable hardware, where the thing being reproduced is the electrical execution of a design running on an FPGA.

Record at the abstraction the hardware already exposes — transactions, not cycles. The insight that makes Vidi both faithful and cheap is that FPGA communication protocols are already built around transactions that hide cycle-level timing, so an application’s behavior is determined at the transaction level. Instead of the brute-force cycle-accurate approach, Vidi records the transaction-level inputs and enforces only the orderings among transaction events that actually matter, which is dramatically less data while still being complete. Escaping the crushing cost of reasoning cycle-by-cycle about hardware by lifting the work up to a coarser, semantically meaningful representation is the same move the work on using tensor algebra to represent and accelerate RTL simulation covered elsewhere on this site makes, trading a per-cycle grind for a higher-level structure that captures what counts. Vidi applies that principle to recording rather than simulating, using the protocol’s own transaction boundaries as the abstraction.

Give FPGA development the agile, software-like tooling it has lacked. Beyond the mechanism, Vidi is aimed at a workflow: FPGA engineers should be able to debug and test the way software engineers do, and record/replay is the enabling primitive. Making reconfigurable hardware development fast, iterative, and productive — closing the gap between hardware and software engineering practice — is the same goal the work on fast FPGA compilation to make reconfigurable acceleration practical covered elsewhere on this site advances, attacking a different bottleneck in the same workflow. Vidi contributes the debugging-and-testing half, so a developer can not only rebuild a design quickly but also reliably reproduce and diagnose what it does wrong.

Following an execution through Vidi

From a misbehaving FPGA run to a faithful, repeatable replay

A trace, drawn from the paper, of how Vidi records a real FPGA execution and replays it deterministically.

Step 1 of 5

The application runs on a real FPGA and misbehaves

An FPGA application runs at full speed on hardware (an Amazon EC2 F1 instance) and exhibits a bug or behavior a developer wants to study. It communicates with the host and memory over standard transaction-based channels such as AXI.

The target is a real deployed execution, not a slow simulation.

Why it works

Transactions carry the behavior; cycles carry noise. The protocol deliberately hides cycle-specific timing behind transactions → so an application’s behavior is determined by transactions and their orderings, not exact cycles → so recording at the transaction level captures everything that matters and skips what does not.
Coarse-grained input recording records exactly what is needed. The transaction abstraction pinpoints which signals in a channel affect semantics → so Vidi records only those signals at transaction start/end plus content → so it is cheaper than cycle-accurate capture yet, unlike ad-hoc coarse recording, complete enough to replay.
Transaction determinism keeps replay faithful. Correctness across grouped channels depends on specific orderings of transaction events → so Vidi tracks and enforces exactly those orderings → so the replay reproduces the original execution without pinning down every clock cycle.
Divergence detection makes the replay trustworthy. A replay might still drift from the recorded run → but Vidi automatically detects divergences and includes techniques to remove them → so a developer can rely on the replay actually matching the bug they set out to study.
Low overhead makes it deployable on real hardware. Recording only transaction-level information avoids the storage and performance blowup of cycle-accurate capture → so the added cost is small (1.98 percent slowdown, 5.48 percent resource overhead on EC2 F1) → so record/replay can run on real applications at speed rather than only in simulation.

What it costs (trade-offs and scope)

It assumes transaction-based communication protocols. Vidi’s whole approach rests on the application talking over protocols with well-defined transactions (such as AXI) that hide cycle-specific timing; a design that does not communicate through such a protocol, or that depends on behavior below the transaction level, would not fit the abstraction as cleanly.
Faithfulness depends on identifying the right signals and orderings. Coarse-grained recording is correct only if it truly captures every signal and ordering that affects semantics; the automatic divergence detection is Vidi’s safeguard for this, but the guarantee is ultimately as good as that mechanism and the transaction model behind it.
There is still real overhead and resource cost. The overheads are low (about 1.98 percent performance slowdown and 5.48 percent resource overhead on average) but not zero, and recording consumes FPGA resources — on F1 it can record up to five AXI interfaces, though developers can configure it to record only the interfaces an application uses to reduce that cost.
It targets record/replay, not every debugging need. Vidi provides faithful, repeatable executions for debugging and testing; turning those replays into a diagnosis still relies on the developer and the tools built on top of the replay, and the paper focuses on two use cases (debugging and testing) rather than every possible analysis.
Evaluated on a specific platform. The results come from Amazon EC2 F1 with 10 applications; the exact overheads and mechanisms are tied to that platform and those protocols, and porting to other FPGA hardware or interconnects would require re-establishing the equivalent transaction model.

The evaluation

Recording an FPGA execution for faithful replay

Property	Cycle-accurate recording	Coarse ad-hoc recording	Vidi
Overhead on real hardware
Faithful replay of a real run
Runs at speed on deployed hardware
Detects replay divergence
Resource overhead

A qualitative comparison of ways to record and replay an FPGA execution. Vidi records at the transaction level, giving faithful replay of real executions on real hardware at low overhead (1.98 percent performance slowdown, 5.48 percent resource overhead on average), evaluated on Amazon EC2 F1 with 10 applications across debugging and testing use cases.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s full text (the authors’ PDF of the ASPLOS 2023 paper). The mechanism described is the paper’s: Vidi is the first record/replay system for real-world FPGA applications running on hardware, based on the observation that widely-used communication protocols have well-defined input/output transactions that hide cycle-specific information from developers, which enables a more efficient design than heavyweight cycle-accurate record/replay. Vidi proposes (1) the transaction determinism insight, to track and enforce only the necessary orderings of transaction events across record and replay, and (2) the coarse-grained input recording mechanism, which uses the transaction abstraction to identify the signals in a communication channel that affect an application’s semantics and records transaction-level information (signal values at a transaction’s start and end events and its content). Vidi also automatically detects divergences between a recorded execution and its replay and includes techniques to remove them. It is evaluated on Amazon EC2 F1 instances with 10 applications and two use cases (debugging, testing), incurring on average 1.98 percent performance slowdown and 5.48 percent resource overhead. Exact protocol details, the divergence-detection method, and per-application numbers should be read from the paper.

Background

Why the abstraction level is the whole game

It helps to see Vidi as an instance of a recurring lesson in systems: when a problem looks impossibly expensive, the fix is often to work at a different level of abstraction rather than to work harder at the wrong one. Recording an FPGA cycle-by-cycle is the wrong level — it is faithful but drowns in detail, because most of that detail (which exact cycle a signal toggled) never affects the application’s result. The transaction level is the right one, because it is exactly the level at which the protocol was designed to expose meaning, so it captures behavior while discarding timing noise. This same shift shows up across hardware tooling, where cloud FPGAs like Amazon’s F1 have made reconfigurable acceleration widely available and therefore made software-grade development tools urgent. The broader move toward treating cloud FPGAs as a real, shared deployment platform with all the tooling and trust concerns that implies is the terrain the work on shielded enclaves for cloud FPGAs covered elsewhere on this site also occupies, from the security side. Vidi addresses the debugging-and-testing side, and its lasting idea is that choosing the transaction abstraction is what turns an impractical technique into a deployable one.

If you remember only three things

1. Record/replay — capturing an execution so it can be deterministically re-run for debugging, testing, and analysis — is a foundational tool for software engineers, but no practical version existed for real FPGA applications running on hardware. The obvious approaches sit at the wrong level: cycle-accurate recording captures every signal on every clock cycle and is far too heavy to deploy, while ad-hoc coarse recording captures too little, so its replay diverges from the original run and cannot be trusted.
2. Vidi is the first record/replay system for real-world FPGA applications on hardware. Its key observation is that FPGA communication protocols (like AXI) are built around transactions that hide cycle-specific timing, so an application's behavior is determined by transactions and their orderings, not exact cycles. Vidi contributes transaction determinism (track and enforce only the necessary orderings of transaction events) and coarse-grained input recording (record only the transaction-level signals that affect semantics), and it automatically detects and removes divergences between a recorded run and its replay.
3. By recording at the transaction level instead of cycle-accurately, Vidi replays real executions faithfully at low cost — about 1.98 percent performance slowdown and 5.48 percent resource overhead on average, evaluated on Amazon EC2 F1 with 10 applications across debugging and testing. It assumes transaction-based protocols and depends on correctly identifying the signals and orderings that matter (backed by its divergence detection), but it brings software-grade record/replay to reconfigurable hardware for the first time.

Check yourself

Check your understanding

1. Why did FPGAs lack a practical record/replay system despite how useful record/replay is for software?
2. What is Vidi's key observation that makes efficient record/replay possible?
3. What are Vidi's two main contributions?
4. What did Vidi demonstrate about its cost and faithfulness?

Sources

The paper is “Vidi: Record Replay for Reconfigurable Hardware” by Gefei Zuo, Jiacheng Ma, Andrew Quinn, and Baris Kasikci (University of Michigan and University of California, Santa Cruz), published at ASPLOS 2023, DOI 10.1145/3582016.3582040.

This explainer is written from the paper’s full text (the authors’ PDF). Vidi is the first record/replay system for real-world FPGA applications running on hardware. It is based on the observation that widely-used communication protocols have well-defined input/output transactions that hide cycle-specific information from developers, which enables a more efficient design than heavyweight cycle-accurate record/replay approaches. Vidi proposes (1) the transaction determinism insight, to track and enforce only the necessary orderings of transaction events across record and replay, and (2) the coarse-grained input recording mechanism, which utilizes the abstraction of transactions to identify the signals in a communication channel that affect an FPGA application’s semantics and records transaction-level information — the signal values associated with the start and end events and the content of a transaction — which is more efficient than recording at every clock cycle and more effective than recording too little. Vidi also automatically detects divergences between a recorded execution and its replay and includes techniques to remove them. It is evaluated on Amazon EC2 F1 instances with 10 applications and two use cases (debugging and testing) and incurs on average low performance slowdown (1.98 percent) and resource overhead (5.48 percent), making it practical for real-world deployments. The artifact is publicly available. No numbers beyond the paper’s own have been introduced; exact protocol details, the divergence-detection method, and per-application results should be confirmed in the paper.