Visibility into the FPGA.

Posts Tagged Bandwidth

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:

Capabilities.

  • 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?

Wrong.

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.

Features.

  • 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

Debugging FPGAs at full speed

High bandwidth

Debugging FPGAs at full speed

In my previous post, I explained why increasing the available ‘window of visibility’ is a gigantic advantage when tracking system-level issues on modern complex FPGAs. EXOSTIV’s structure does not require the FPGA internal memory to grow with the depth of the capture.

Yet, mobilizing hardware resources (internal / external hardware and software, memory, logic, communication ports, …) is always the result of a compromise. Debugging FPGA at full speed requires adopting the right strategies to remove bottlenecks.

Debugging FPGA at full speed requires adopting the right strategies to remove bottlenecks.

Memory severely limits JTAG instrumentation

In traditional JTAG-based embedded instrumentation, the main bottleneck is FPGA memory. There is some ability to scale up the FPGA memory but this depends on what’s available in the FPGA after the design is implemented. Collecting a larger number of signals and deeper traces quickly exhausts the memory. Beyond a few (hundreds of?) kilobytes at best, you’re done. This severely limits the ability to debug further.

A common strategy for scaling up debug without increasing the memory consists in multiplexing data groups (see figure below), based on the principle that debugging FPGA sometimes requires to ‘overinstrument’ the design, to save on implementation iterations. ‘Multiplexing’ means segmenting the design into groups of signals. This technique helps reserve the scarce memory resources for a reduced set of signals, thereby enabling longer (‘deeper’) captures.

A displacement towards bandwidth

Unlike JTAG-based systems – where the captured data is really ‘trapped’ inside the FPGA – EXOSTIV sends the captured data to a large external memory (8 GB currently). This memory is hardly the bottleneck and it can be scaled up rather easily.

For EXOSTIV, the ‘new’ bottleneck is the available bandwidth (please note that even with this bottleneck, EXOSTIV goes much beyond the capabilities of JTAG-based embedded instrumentation).
Advanced versions of EXOSTIV provide up to 50 Gbps of total bandwidth with 8 GB of memory. However, these resources are in no way ‘unlimited’ in regard of the ‘exploding complexity’ of modern FPGA. 50 Gbps allows the continuous streaming of 1,000 bits sampled at… just 50 MHz.

Pushing the boundaries

EXOSTIV includes the following features to preserve bandwidth:

  • Data group multiplexing;
  • Data qualification;
  • Burst mode of operation;

All of the above strategies act differently with one purpose: reduce the bandwidth requirements.

Data Group Multiplexing

We have evoked this strategy previously, as a way to ‘deepen’ captures for JTAG-based systems, where the storage memory is very small.
For EXOSTIV, multiplexing the observed nodes as data groups has the function of reducing the maximal bandwidth required to flow the data out of the FPGA. While it constraints the designer to watch the data groups separately, it helps reduce the bandwidth requirements to this available on the gigabit links. If this bandwidth is kept below or equal to the maximum available, ‘continuous’ capture is possible, and data can be flown outside of the FPGA without requiring any local storage. The process can stop when the EXOSTIV Probe’s memory is full.

Data Qualification

Data qualification consists in defining ‘filters’ or ‘qualification equations’ built on the observed data. A logic condition is defined, which enables or disables the capture of data. This equation defines when ‘data is (un)interesting’. For instance, you may want to observe a data bus only when there is traffic on it and filter the IDLE times.
Coupled with some buffering in EXOSTIV IP Capture Units (click here for more details on EXOSTIV IP’s structure), this strategy effectively contributes to lowering the average bandwidth requirements.

Burst mode of operation.

Capturing repetitive chunks of data defined with a trigger condition is another solution. Like data qualification, bursting data contributes to lowering the average bandwidth requirements on the gigabit transceiver links. Using bursts must not be seen as a ‘fallback strategy’ for cases when streaming data continuously is not possible. As opposed to JTAG-based solutions, where only one single burst can be observed, EXOSTIV allows bursting data out until the Probe’s memory is full. Events occurring between bursts cannot be watched, but a large set of events that happen long in time after power up are now accessible (Remember: with JTAG-based systems, all you can see is… just one burst!).

Take away : make the most of your resources

EXOSTIV provides unprecedented memory and bandwidth resources that enable debugging modern FPGAs at full speed.
These already huge resources can be scaled with modern FPGA complexities. In addition, using the right EXOSTIV features and strategies help remove a ‘new debugging bottleneck’: bandwidth. Combining burst mode operation, data qualification and data grouping is a winning strategy to make the most of EXOSTIV’s debugging resources.

Thank you for reading.
– Frederic

STAY IN TOUCH

Sign in to our Newsletter