Record 8GB from a running FPGA – really

Record 8GB from a running FPGA – really.

In this blog post, I demonstrate 2 different – and extreme? – capture scenarios made possible with EXOSTIV.

In the 2 cases, I have used a VCU108 Virtex Ultrascale development kit from Xilinx.
(see Xilinx’coverage of EXOSTIV in the XCell daily blog here.).

In this setup, a total of 50 Gbps bandwidth over 4 transceiver channels is available (12.5 Gbps per channel). A 4xSFP+ to QSFP+ cable was used between the probe and the target board.

Example 1: Capturing 8GB data in bursts over more than 1 hour

Example 2: Capturing a long continuous single burst of data

As you can see with the examples above, there can be many capture scenarios and options with EXOSTIV.
It is important to note that using bursts is not a fallback for not being able to stream data continuously.
It is true that the total bandwidth that you can afford on the transceivers will affect your ability to stream data continuously or not. Actually, the average available bandwidth defines the sample width that you can send continuously on your transceiver connection with EXOSTIV Probe (if you’d like to do some math about capture units width, please go to this knowledge base article: ‘How many nodes can I sample continuously without creating overflows?’).

However, you should take the following into account:

EXOSTIV extracts samples from FPGA at speed of operation, using internal clocks. While this means that you really see an FPGA in action from inside – this great feature also means that you’ll use clocks at 80 MHz, 100 MHz or even 400 MHz! The EXOSTIV Probe has a 8 Gigabyte memory and provides up 50 Gbps bandwidth.

At 200 MHz, you’ll be able to capture 50,000 / 200 = 250 bits continuously – that is 31.25 bytes.

8 Gigabytes of memory will be filled in with about 1.31 seconds of capture… Not bad.

If your goal is to observe FPGA over longer times, like during hours, you’ll need to define triggers and data qualification conditions in order to lower the average bandwidth needs.
The advantage? You focus on what’s really important in the data that is captured, you potentially enlarge the vector size and you cover more of the FPGA behaviour…

You can even define a reduced capture unit for continuous captures on a limited number of nodes, and an extended capture unit for some details or for burst captures spanning over longer times. Bottom line: Yes, you can have the best of both worlds with the same EXOSTIV IP.

Thank you for reading.
– Frederic

EXOSTIV is in Xilinx’ XCell daily blog!

Record FPGA data during 1 hour – really

Record data from FPGA over long total times - deep capture

Record FPGA data during 1 hour – really.

As ASIC, SoC and FPGA engineers, we are used to watching the operation of our designs based on single limited snapshots. RTL simulations, for instance, provide bit-level details during execution times that span over a few (milli)seconds at best. Consequently, it may not be possible to see events that happen over long times as a single coherent capture.

In this blog post, I have wanted to show what can be done in a real case with EXOSTIV. The design that runs from a FPGA board is a full system on-chip that features a Gbit Ethernet connection. The board is connected to our company network – and I have set up EXOSTIV to trigger and record the Ethernet traffic during 1 full hour. Yes, we used EXOSTIV as an Ethernet sniffer, that works from inside the FPGA – providing a ‘decoded view’ of the traffic after it has entered the FPGA Gbit Ethernet IP. Check the video below. We have accelerated it but the stop watch shows the real elapsed time.

Like it is shown on the video, we have set up EXOSTIV to record a chunk of data (256 samples) every time ‘something’ is seen on the Ethernet interface: there is an event trigger when a wide variety of events (note the ‘OR’ equation trigger definition) marking the detection of traffic happen on the Ethernet connection. Each sample is 1,248 bits wide.. This gives a quite good insight of what is ‘after’ the Gbit Ethernet IP in the FPGA. Each burst records 256 x 1,248 bits = 319,488 bits of data – and there are 30,000 such bursts collected over a total time of about 1 hour.
In total, EXOSTIV has collected a little less than 1.2 Gigabyte during this run – which is just about 15% of the total memory provided by an EXOSTIV probe.

Practically, it means that we could collect roughly 6.6 times as much data… (> 6 hours) with this single capture unit.

You can see that the bursts are recorded rather randomly, as the occurrence of a trigger depends on the actual load of our company network. (Click on pictures below to enlarge and zoom on the data)

Exostiv Dashboard after capturing 1 hour of the Ethernet traffic

Exostiv Dashboard after capturing 1 hour of the Ethernet traffic - full capture
Exostiv Dashboard after capturing 1 hour of the Ethernet traffic - detail on the deep capture

As always, thank you for reading (and watching).
– Frederic

Deep Trace & Bandwidth

Exostiv provides deep trace AND bandwidth for maximal FPGA visibility

Deep Trace & Bandwidth

Exostiv provides the following maximum capabilities for capturing data from inside FPGA running at speed:


  • 50 Gigabit per second bandwidth for collecting FPGA traces.
  • 8 Gigabyte of memory for trace storage.
  • 32,768 nodes probing simultaneously.
  • 524,288 nodes reach.
Actually, we have built EXOSTIV to provide VISIBILITY to FPGA designers performing debugging with real hardware. If you do not know why it is important, watch the following 7 minutes video. It sketches out the fundamentals of EXOSTIV.

We built EXOSTIV to provide visibility to the FPGA designer.



Interrupted captures are very useful too !

I was recently demonstrating Exostiv at a customer’s site and I received the following comment:
“Even with 50 Gbps bandwidth, this tool is hardly usable because you won’t see many nodes at a usual FPGA internal sampling frequency…”
This person was implying that – for example – probing more than 250 FPGA nodes at 200 MHz already exceeds this total bandwidth. So, Exostiv cannot be used to its fullest, right?


This reasoning is right if you think that only continuous captures are valuable for getting insight from FPGA.
The following short video explains why it is important. It features a case where the capture – from start to end – spans over 11 seconds ! . Depending on the trigger and data qualification (or data filtering options) – and by using the full provided trace data buffer (8GB) such an approach can let you observe specific moments of the FPGA in operation over hours !.


With the proper capture settings, EXOSTIV lets you observe FPGA over hours.

So, the features listed below are equally important for an efficient capture work.


  • 16 capture units that can be enabled/disabled dynamically
  • 16 multiplexed data groups per capture unit
  • 8k samples local buffer in each capture unit.
  • 1 trigger unit per capture unit. Defines start of capture.
  • Bit or bus condition. =, /=, <, >, range, out of range conditions
  • Repeating/interrupted capture based on trigger condition
  • Data qualification condition on input data. Capture only when the condition is true.
  • Interactive trigger or data qualification definition: no recompile needed
  • Sequential / state machine trigger in 2017 roadmap.

As always, thank you for reading (and for watching)
– Frederic

Debug with reduced footprint


Debug with reduced footprint

Footprint, ‘real estate’, resources, … No matter the design complexity, allocating resources to debugging is something you’ll worry about.
If you are reading these lines, it is likely that you have some interest in running some of your system debugging from a real hardware (Check this post if you do not know why it is important).

EXOSTIV enables you to get extended visibility out of running FPGA.
It impacts the target system resources in 2 ways:
– it requires logic, routing & storage resources from inside the target FPGA to place an IP used to reach internal FPGA nodes.
I’ll cover this aspect in a future post.

– it requires a physical connector to access the FPGA.
(- And NO, JTAG is not good enough because it does not support sufficiently large bandwidth – even with compression).

Read on…

Choosing the right connector

All EXOSTIV Probes provide 2 connection options:
Option #1: uses a single HDMI connector type (! this is not a full HDMI connection !)
Option #2: uses up to 4 SFP/SFP+ connectors

From there, a wider range of options is within reach if you consider using additional cables and board adapters available from Exostiv Labs or from third-party suppliers.

Which option will work for you? Follow the guidelines below:

1. Is there an existing SFP/SFP+/QSFP/QSP+ directly connected to the FPGA transceivers?

  • Check if you can reserve this FPGA resource (and the board connector) for debug – at least temporarily. You’ll need 1 SFP/SFP+ connection per used gigabit transceiver
  • QSFP/QSFP+ connectors can be used with a 4xSFP to QSFP cable with splitter.

Note: most of the Dini Group’s boards feature SFP/SFP+, quad SFP/SFP+ or QSFP/QSFP+ connectors by default. And they are directly connected to FPGA transceivers.

2. Is there another type of connector directly connected to the FPGA transceivers?

Please contact us for details on our adapters, external references and custom adapters support.

3. For all other cases: you’ll need to modify your board and add a connector.

    • Is space on the board critical? Go for HDMI or even Micro-HDMI !

See picture below – this is an Artix-7 board equipped with a tiny micro-HDMI connector, providing up to 4 x 6.6 Gbps bandwidth for debugging FPGA.

  • You do not have space constraints (lucky you)? Pick the one you like: SFP/QSFP/HDMI/micro-HDMI/other (+ adapter).

*** Check our special 12 Gbps probe test report – Click here ! ***

EXOSTIV provides standard and custom connection options that enable fast deployment with standard FPGA development kits and/or limits the footprint requirements from the target FPGA board.

Thank you for reading.
– Frederic