FPGA Debug

Reach 200,000 x the visibility of JTAG instrumentation.


Go beyond JTAG

FPGA programmability has traditionally enabled engineers to use board prototypes in the lab for debug and verification. Using a system at speed in its ‘real’ environment is used to overcome modeling errors and excessive simulation times.

However, with the unprecedented complexities reached by FPGAs today, the usual JTAG-based embedded logic analyzers hardly provide sufficient visibility on system-under-test and create tough board implementation constraints.

Scale your tools, not your expectations

Over time, the usual JTAG-based tools and traditional instrumentation have failed to provide the visibility required by increasing FPGA complexities.

Prototyping is still a must, though. Using a prototype provides much faster execution than simulation and reveals the imperfections of the models we use in simulation. Even with methodologies that include code coverage, testbench coverage, UVM, assertions or constrained random stimuli, prototyping should be part of any advanced verification flow. However, prototyping a complex FPGA is a good approach only if you can get a reasonable visibility out of it: once on a board, a chip is fast and essentially opaque.

EXOSTIV solves your FPGA debugging challenge

EXOSTIV provides Gigabyte-range visibility into the FPGA at speed of operation and addresses the challenges of debugging on FPGA prototypes:

– Minimal FPGA resources requirements:
EXOSTIV IP requires FPGA memory resources that do not grow with the size of the capture. No matter if you capture 1 KB or 8 GB, FPGA memory is kept as small as a few kilosamples, positively impacting the usage of routing resources in the FPGA. EXOSTIV Dashboard software provides configuration option that let you fine-tune the resources used by EXOSTIV IP.
>>Go to EXOSTIV IP details

– Limited board cost: EXOSTIV requires an access to the FPGA transceivers. The connector can be as small as 6.4 mm x 2.8 mm – much smaller than a traditional JTAG pin header or a logic analyzer probe connector. Existing connectors (FMC, SFP+, QSFP+, SATA,…) can be used temporarily for Exostiv too.
>>Go EXOSTIV Probe’s connectivity options

– Limited need to recompile: EXOSTIV IP can be inserted into RTL code or at the netlist level, after synthesis (Xilinx FPGA only). Exostiv Dashboard lets you store and reuse previously generated IPs. It provides live settings on data group selection, trigger and data qualification that enable you to change the capture parameters on the fly without the need to recompile the IP.
>>Go EXOSTIV Dashboard software page

Why traditional approaches fail

A typical on-board debugging scenario requires finding the roots of a random bug happening once in a while. It may be once every 2 hours or every 3 days.
In such a case, simulation as a sole methodology is impracticable. Furthermore, if simulation has not helped finding the bug earlier, it probably means that there is a model issue in the simulation environment.

Consequently, the FPGA engineer typically uses one of the 2 following type of tools: a logic analyzer or an embedded logic analyzer:

Traditional vs. Embedded Logic Analyzer for FPGA debugging

Choosing one of these techniques results in a trade-off between using a large number of FPGA I/Os and using a large amount of memory inside the FPGA.

By providing extreme FPGA visibility at speed, EXOSTIV helps you tackle the toughest debug & verification challenges.

EXOSTIV Embedded LA Logic Analyzer
Observable nodes

Up to 32,768

Thousands Typ. 64 to 128
Impacts nr of FPGA I/Os
Capture depth

Gigabyte

Kilobyte
Impacts FPGA memory
Megabyte
Sampling speed

At FPGA speed

At FPGA speed Limited by I/Os speed
& board routing