Visibility into the FPGA.

Posts Tagged demonstration

Exostiv supports Intel Stratix 10 FPGA

Exostiv supports Intel Stratix 10 FPGA

As Intel Stratix 10 FPGA gets deployed for real applications, we are ready too at Exostiv Labs! Stratix 10 devices are supported from Exostiv Dashboard for Intel v. 1.8.4 (and stay tuned, because Cyclone 10 FPGA are around the corner…).

We have shot a short video with the Intel Stratix 10 GX Development kit. You can watch it below or click on this link to view it.


Our ‘Exostiv for Intel page’ gathers Intel FPGA – related resources for Exostiv.
You might want to check this one too.

As always, thank you for reading.
– Frederic

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

Get your money back in 4 weeks

Exostiv pays back in 2 weeks

Get your money back in 4 weeks

Debug productivity is notoriously hard to sell.

Engineers who ask budgets for debugging tools are still too often blamed by the Management for creating the bugs in first instance.
(‘Why would I pay more for correcting the bugs that YOU inserted in the design?’).

Putting a value on debugging is a particularly hard task… It is all about reducing the time spent on debugging but how much does it really cost and how can we be sure that a specific tool really brings an improvement?

Saving how much of the engineering time would justify buying EXOSTIV?
A rule of thumb is 4 weeks per year (or even as low as 2 weeks for the lucky ones located in high salary areas).

A good example

I recently visited a company where the engineering team wanted to evaluate EXOSTIV on an existing board. This board was mounted with an FPGA supported by EXOSTIV and featured a single SFP connector. As such, it was usable ‘out of the box’. We offered to set up the project files for EXOSTIV with the engineering and within 30 minutes, we could insert a debug EXOSTIV IP into the target design. As we did it ourselves, there was no initial setup cost nor learning curve cost in this example. After FPGA implementation, EXOSTIV connected right away and we could capture data. A good demonstration as it seemed. After 2 hours, I left the engineering team with a trial unit of EXOSTIV and allowed them to use it for free until the next day.

The next day, the engineering team told me that the tool was easy to use for those used to JTAG-based logic analyzers such as Chipscope / Xilinx logic analyzer. Basically, the flow was identical. Configuring transceivers required some additional experience to understand the metrics, clock sources and so on, but this was general knowledge of FPGA structure that any engineer should learn someday.

Then, they told me that the visibility provided by Exostiv had allowed them to find and correct a bug in an Ethernet IP, that they had not been able to see before, because their tools could not reach such debug scenarios. They were about to go to production and said that the result was ‘invaluable’. This result had totally exceeded my expectations.

I was absolutely delighted.
I expected to receive a purchase order the same day.

I was wrong.

When ‘invaluable’ kills business

Actually, they were puzzled. They somehow went to the conclusion that EXOSTIV was priced too high because our model involves subscribing for EXOSTIV software for a minimum of 12 month – and here the bug resolution had been so fast… (I am still perplexed by this reasoning…). Anyway, they decided to wait until they had a new bug or alert that could justify buying the tool
EXOSTIV had revealed an issue that they were not aware of – and before being painful to anyone.

And what about the management? Practically, nothing harmful had happened at all – so the management was not even considering a purchase…

Missed market opportunity cost

Going to production with unknown bugs has a cost that generally reduces to how much market (share) you’ll loose by arriving late on the market with a working product. In this case, it seemed that the product was already reasonably stable: the engineering team was perfectly qualified and had not seen anything wrong.

This cost is called ‘(missed) market opportunity cost’ and can be estimated at the value of the market that is left to the competitor because you are delaying your product launch. Even if this cost can be large (loosing a few % of market share should be a lot of money – or you do not address a market that is large enough), it can have no impact on a decision to invest in a new EDA tool to debug FPGA. The value can hardly be estimated accurately and its consequences are usually unpredictable and too distant. Much too complicated…

Bottom line: ask the right questions

– Will there be bugs in your design? Absolutely. FPGA are such complex beasts that this cannot be avoided. No wonder why 40% of the total design time is spent on debug and verification.

– When do those bugs cost the most? When they ‘escape’ to production: the cost of having to stop the production and get back to design is gigantic. And it si your responsibility as an engineer to find them.

– Can EXOSTIV help you find them? You bet. EXOSTIV provides unprecedented visibility.

And finally:

– Why would you reserve a budget for EXOSTIV? Because it pays back if you save 4 weeks of engineering per year. And this can be 4 weeks total for a team that shares one license.

Thank you for reading.
– Frederic

Exostiv for Intel (Altera) FPGA – announcement

Exostiv for Intel FPGA

Announcing… EXOSTIV for Intel FPGA

Using Intel FPGA?

We have exciting news for you: EXOSTIV will soon support Intel FPGA!
Please check the pictures above and below – this is EXOSTIV working with the ‘Attila’ dev kit of our partner, Reflex-CES, equipped with one Arria 10 GX 10AX115N4F40I3SG device.

We are now able to use EXOSTIV Dashboard Analyzer connected to an IP loaded into the design through the board QSFP port (with a QSPF to 4xSFP cable with splitter).
The board FMC connector mounted with our FMC to HDMI adapter works as an access port too! (Click here to check about the connectivity options for EXOSTIV.)

This beta version was shown during the training we co-organized with Telexsus Ltd. in Maidenhead (UK) on October 13rd and at the Europe edition of the Intel SoC FPGA Developer’s Forum (ISDF) held in Frankfurt on October 19th, where Exostiv Labs participated as a Regional Sponsor.

The Intel SoC FPGA Developer’s Forum was held in Frankfurt on Oct. 19th.

We are happy to announce the availability of EXOSTIV for Intel FPGA (formerly Altera) for the end of 2016. That’s an exciting new step for us and for EXOSTIV !

Exostiv at ISDF

We would like to thank all our customers using Intel FPGA for their patience. We’ll be in touch!
– 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

EXOSTIV is there – and it is not a monster

Happy Halloween

EXOSTIV is there – and it is not a monster

As you might have noticed, EXOSTIV for Xilinx is now released. With the launch, I have been on the roads to demonstrate the product.

The good thing about meeting FPGA engineers is the flurry of questions, ideas and suggestions received as I show the product. Your feedback helps us find new ideas, find where the most acute pains are and understand what you actually do. I would like to thank you, who have already dedicated some time from your supercharged week to see the product in action. (If you are interested to see the product, please contact me to check our scheduled events with me).

What is EXOSTIV?

Here is one of the slides I use to present EXOSTIV (click here for the complete presentation in PDF):


EXOSTIV is not an emulator.

Why is it important?

Well, because it is sometimes expected from EXOSTIV to be everything at once. Some examples:
– Can it partition design onto multiple FPGA?
(Nope, that’s the role of a partitioning tool. We have to define how our IP can be used with such tools, though).
– Can it implement this (specific) trigger condition?
(Well, some of them, some not. But with it capture capacity, you might not need such a complex trigger).
– Will it be able to replace a protocol analyzer?
(It depends on the protocol and where it is observed…).
– …

Of course, some of your suggested additional features are already in the development pipe at Exostiv Labs… But not all of them.

EXOSTIV’s main value is in the level of visibility it provides for systems running at speed.

New features will be built around this value

Ask yourself: what can you do with 8GB of captured data flowing out of your FPGA at multi-gigabit speed? Would it add something to the flow that your current tools cannot achieve?

At Exostiv Labs, we believe that a tool that tries to be everything at once would probably be very good at nothing, not well fitted to your flow and much too expensive for the value.

EXOSTIV is not such a monster.

Thank you for reading – and Happy Halloween to all!
– Frederic


Sign in to our Newsletter