The bug that only appears at operating speed.
Simulation says it works. Your board says it doesn’t — and JTAG can’t capture enough to find out why.
The scenario you recognize
Your design passes simulation. It passes basic hardware tests. Then, 30 seconds into real operation — or sometimes hours later — something goes wrong. A data corruption. A protocol violation. A timing failure that only surfaces under real load, with real software, on real interfaces.
You restart. You add triggers. You narrow the window. JTAG gives you a few kilobytes and stops. The bug doesn’t cooperate with your capture window.
This is not a simulation problem. This is not a design problem. This is a visibility problem.
Why this happens
Some bugs are structural — they exist in the RTL and simulation will find them. Others are emergent — they only appear when the system runs at full speed, under real conditions, for a realistic duration. No simulator runs fast enough or long enough to reproduce them. The gap between simulation and reality is where these bugs live.
JTAG-based tools were designed for a different era. A few kilobytes of capture, then a forced restart. For emergent bugs that appear after seconds or minutes of operation, this is not a debug tool — it is a lottery.
What Exostiv does differently
Exostiv captures FPGA internal signals at full operating speed, through transceivers to external memory. No clock stopping. No forced restarts. Captures that run for seconds, minutes, or hours — not milliseconds.
When the bug appears, the full history is already captured. You roll back, find the originating event, and fix it. One session instead of dozens of frustrated iterations.
In practice
A capture from a 60 fps video interface at 148 MHz, triggering on 232,000 successive frames over more than one hour — 8 GB of data from a live FPGA, in a single session. That is the scale at which emergent bugs become traceable.
See it on your board – Request a demo.
