Visibility into the FPGA.

Posts Tagged FPGA

Exostiv boosts RTL simulation

Exostiv boosts RTL simulation

It is essential to reduce the wasted machine cycles used for simulation workloads.

Simulation dominates ASIC/SoC/FPGA verification process

‘The 2018 Wilson Research Group ASIC and FPGA Functional Verification Study’ (you may have to register for free to watch this) reports that an ASIC, SoC or FPGA designer can spend up to 40% of the total verification time on creating testbenches, writing tests or running simulation. In addition up to 44% of the time spent on debug – and this involves running simulation too.
It is safe to say that simulation is the most dominant technique in the overall verification effort.

Simulation speed is losing the race against FPGA complexity.

Over the last decade, simulation software has improved at many levels. Simulation software needed these improvements so they would be able to cope with the increasing complexity of designing FPGAs and chips with hundreds of millions gates.

Simulation software now supports more languages, assertions, and verification methodologies such as Accellera UVM. Code coverage now includes testbench coverage – in order to keep track of whether a team has exercised specific test stimuli.

Interestingly, these efforts have improved the test coverage, provided metrics for signoff and standardized verification approaches based on simulation, but did not accelerate simulation that much. Even the most recent claims from simulation software vendors show RTL simulation acceleration by 4x or maybe 5x thanks to the execution of the simulation on multi-core servers… whereas the complexity of FPGA has been multiplied by 100 in the same period of time!

In 2018, 84% of FPGA designs had at least 1 non-trivial bug escape to production (source: The Wilson Research Group)

How to make the most of the simulation time

In the study mentioned above, The Wilson Research Group reports that a staggering 84% (!) of the FPGA designs have had at least 1 non-trivial bug escape to production – and that: 65% of the typical simulation times exceed 5 hours.

That is why it has become critical to make the most of the time spent in simulation, and limit – as much as it is possible – the wasted machine cycles. Otherwise, our verification techniques are at risk of becoming irrelevant.

In our experience, the following approaches have proven to be successful:
– Performing ‘per IP’ simulations to verify them helps spread the effort on multiple engineers in parallel and run shorter simulations;
– Make use of ‘snapshot’ simulation features – which consists in saving the state of a simulation and re-start from there to run specific simulations.

In the illustration below, two frequent snapshots are saved – after the boot of the processor and after the DUT is initialized respectively. This conveniently helps running combinations of initialization sequences and test stimuli without having to simulate the boot sequence over and over again.

Simulation shnapshot technique

Full system bugs can require multiple days of simulation.

As demonstrated in this presentation from Cadence on simulation tools, full-chip bugs, which occur when the full system is put together, can require days of simulation. A ballpark estimate is up to 54 hours of simulation for 43 milliseconds of SoC HW runtime! For these kinds of bugs, it has become equally crucial to:
– Speed up simulation; (that’s the job of simulation software vendors)
– Make sure that the simulated models are accurate; (EXOSTIV can definitely help !)
– Provide additional visibility from the real system to converge faster on finding the bug; (EXOSTIV can definitely help!)

What EXOSTIV can do to BOOST simulation.

Exostiv lets you record very long data sets from inside FPGAs running at full speed of operation.
Typical probing scenarios with their most common usages are summarized in the two tables below:
The first table lists common usages that boost simulation – illustrated below the table:

What is probedTarget usage
Specific IP inputs
(or group of IPs)
- Overcome modelling issues;
- Make test case match reality.
Specific IP outputs
(or group of IPs)
- Reference response database;
- See the effects of non- or hardly simulable elements,
(such as CDC or metastability).

Exostiv lets you record input vectors from reality for IPs and full systems

Other Exostiv usages that complement simulation:
What is probedTarget usage
A full system bus
- Verify / develop software;
- Evaluate system overall efficiency / performance over large - and real - data;
- Check system behaviour;
Specific nodes
- Functional verification and debug.

Conclusion

Exostiv complements simulation by providing a source of real-world stimulus for IPs, groups of IPs and full systems. It therefore helps overcome modelling problems that are the most common source of FPGA bugs escaping to production. Coupling simulation with the huge recording capability of Exostiv means you avoid wasting your quota of machine cycles dedicated to simulation and improves the quality of FPGA system sign-off.

When 84% of the FPGA designs report at least 1 non-trivial bug escaping to production, and 65% of the typical simulation times exceed 5 hours (source: The 2018 Wilson Research Group ASIC and FPGA functional verification study), boosting simulation is an absolute necessity.

As always, thank you for reading.
– Frederic

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 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:

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

RTL or Netlist flow?

RTL or Netlist flow for FPGA debug?

RTL or Netlist flow?

EXOSTIV Dashboard ‘Core Inserter’ now proposes 2 alternate flows* for inserting EXOSTIV IP into the target design: the ‘RTL flow’ and the ‘Netlist flow’.

With the RTL flow, EXOSTIV IP is generated as a RTL (HDL) code ‘black box’, with a synthesized netlist underneath. EXOSTIV IP is inserted ‘manually’ by the designer into the target design by editing the RTL source code (VHDL or Verilog). Once inserted, the user manually runs the synthesis and implementation (place & route) of the instrumented code.

The Netlist flow lets the user pick the nodes to be observed from a synthesized design. EXOSTIV IP is then synthesized and automatically inserted into the target design netlist. The instrumented netlist can be placed and routed automatically too.

Which one is right for you?

You can choose the flow when creating a new project with EXOSTIV Dashboard software.

This choice has got consequences on the output files, on the results of the core insertion process and on the operations that you need to execute for obtaining an instrumented design.
See the table below:

RTL flow

  • Manual core insertion in RTL code
  • EXOSTIV IP is not linked to specific nodes
  • Nodes names are mapped during analysis
  • Requires synthesis, place & route and bitstream generation after insertion
  • Produces: a netlist of EXOSTIV IP, a RTL instantiation template and pinout / timing constraints

Netlist flow

  • Automatic core insertion in Netlist
  • EXOSTIV IP is linked to nodes selected from the design
  • Nodes names are mapped during EXOSTIV IP generation
  • Requires place & route and bitstream generation after insertion
  • Produces: an instrumented design netlist and optionally, a fully placed and routed design

The RTL flow…

…produces a generic debugging IP with the chosen resources and generic input port. The process of configuring EXOSTIV IP in EXOSTIV Dashboard is merely a matter of choosing the number of capture units in the IP and the width of them (see for instance an example of such IP component declaration in VHDL below). The generated modules will have ports numbered as: ‘cu0_Trig’ or ‘cu2_Data’.
Once generated, you can connect EXOSTIV IP to any RTL signal / wire from your RTL code.

Once the IP is connected in the target design RTL code and once the synthesis, P&R have run, the EXOSTIV IP inputs really have a functional meaning. It is then desirable to specify a logic name rather than an obscure ‘cu#_Trigger(0)’. It just eases analysis. So, this will be done in the analyzer, with the ‘Data Probes Remapping’ function (see screenshot below).

Typically, the RTL flow will be used when:

  • The same sets of nodes are observed for debugging. This would be the case for a AXI bus-based system, where debugging the system requires watching the AXI bus traffic.
    Typically, this supposes that there is little or no iteration for selecting the nodes observed during debug.
  • Interesting nodes are optimized, removed or renamed after synthesis, preventing from probing them. In such a case, the RTL flow gives a better ‘insurance’ to be able to watch interesting nodes. Using properties on signals such a ‘MARK_DEBUG’ for Xilinx Vivado or ‘SYN_KEEP’ for Synplify would, however, limit the risk of ‘loosing’ the interesting nets after synthesis.

The Netlist flow…

… uses a communication between the FPGA vendor tool and EXOSTIV Dashboard software to dig into the design hierarchy, extract nodes and clock information from the synthesized design (see the node selection window below).

Typically, the Netlist flow will be used when:

  • You want to save the time of design synthesis when a new EXOSTIV IP core is generated. This would be the case when successive core insertions must be run to track bugs.
  • You do not want to manually modify the RTL code – which can be time-consuming. Leaving the work of inserting and connecting EXOSTIV IP to EXOSTIV Dashboard software and the FPGA vendor tool suite proves extremely efficient.

Takeaways

EXOSTIV Dashboard flows are 2 alternate ways of generating and inserting EXOSTIV IP into your target design. Which one is right for you very much depends on your habits and the flow you are using for creating and debugging FPGA.

It would be too quick to dismiss the RTL flow because it is not fully automated – and requires editing the RTL code to bring the right ‘wire connections’ at the level where EXOSTIV IP is instantiated. The RTL flow fits well when the same specific nodes are systematically probed. Using scripts with conditional instantiation of IPs is a very efficient way to generate and debug designs based on a RTL approach. As we’ll explore in a future post, coding techniques exist for easing the work of wiring nodes across the hierarchy.

Similarly, you should think again before dismissing the Netlist flow because node names cannot be found after synthesis: some properties can be used for limiting this effect – and we’ll come back on this later. The integration of EXOSTIV with the FPGA vendor tool allows browsing the design hierarchy, selecting nodes to observe and then automatically generate an instrumented design. When available*, the Netlist flow can be a wonderfully productive approach for debug.

It will be also interesting to see how each flow make the most of a new feature (coming soon…):
a full scripting interface for using EXOSTIV Dashboard. We’ll come back on this too.

Thank you for reading.
– Frederic

*The Netlist flow is currently available for Xilinx FPGA only.

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.

ISDF
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

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

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

You can capture tons of data. Now what?

EXOSTIV can capture very large data sets

You can capture tons of data. Now what?

Offering huge new capabilities is not always seen positively. Sometimes, engineers come to us and ask:
‘Now that I am able to collect Gigabytes of trace data from FPGA running at speed… how do I analyze that much data?’.

Does EXOSTIV just displace the problem?

No, it does not.

In this post, I’ll show:
1) why it is important to enlarge the observation window. – and:
2) how to make the most of this unprecedented capability, based on EXOSTIV Dashboard’s capture modes, triggers and data qualification capabilities.

Random bugs happen

The figure below shows a typical debug scenario. A bug occurs randomly ‘some time’ after system power up. During an initial time interval, the effects of the bug are not noticeable – after which, the system’s behaviour is sufficiently degraded to obviously see the bug’s effect. Typically, the engineer will need to detect a ‘start of investigation’ condition from which he’ll have to ‘roll back in time’ – ultimately to find the root cause of the bug. In the case of an FPGA the engineer observes the FPGA’s internal logic.

Random bugs typically occur as a result of a simulation model issue. The system’s environment could not be simulated with complete accuracy and/or some part of the system behaves differently than initially thought int he ‘real world’. In addition, long operating times are not really the ‘simulation’s best friend’.

Size matters.

Suppose that we capture some ‘observation window’ of the system. If we are lucky enough to observe a bug right when it occurs, we can get an understanding of what happens. Similarly, we are able to recognize the effects of the bug, as shown by the orange ‘X’ on the picture (called ‘start of investigation). Conversely, we have no idea about how to trigger on such conditions (if we had the ability to trigger on unknown and random bugs, they would have been corrected already).

With a reduced observation window, the process of debugging requires some luck. We can miss everything, recognize an effect without having sufficient data to find the start of investigation. We can be lucky enough to find the start of investigation but no history to roll back to the root cause… – Or: we can hope to ‘shoot right on the bug’.

You do not want to leave the debugging process to chance?

Enlarge the observation window!

VS.


With a properly sized observation window, you can be certain of finding a random bug.

Not ‘brute force’ only

EXOSTIV provides a total observation window of 8 Gigabytes.
However, EXOSTIV is not a ‘brute force’ solution only. Many of its features are equally important to implement ‘smarter’ captures in the lab.

Trigger, Data Qualification, Streaming and Burst help you define better capture windows.

1. Trigger

The total capture window may be gigantic, a triggering capability remains essential. During EXOSTIV IP setup, the nodes that need to be observed are optionally marked as ‘source for trigger’. Currently, EXOSTIV is able to implement a single or repeating trigger based on AND and OR equations defined on these signals. The AND and OR equations can also be combined. (In a future release, EXOSTIV will provide sequential triggers as well.)

With the growing complexity of systems, defining a very accurate trigger condition has sometimes become a way to overcome a too limited capture window.

This time is over. You are now able to use trigger to collect a better capture window. Maybe you can relax a little bit about defining complex triggering, because you can count on a very large capture window to collect the information that you need.

2. Data Qualification

‘Data qualification’ enables you to define a logic condition on the observed signals. Data is captured and recorded by EXOSTIV only when this condition is true.

For instance, this can be used to filter out the times when nothing happens on a bus. This is a very powerful feature that helps you preserve the bandwidth that you use to extract data.

3. Streaming or Burst?

EXOSTIV provides 2 modes of capture:

  • Streaming mode: data is captured continuously. If the bandwidth required to capture data exceeds its EXOSTIV Probe capabilities, it stops and resumes capture once it is able to do so. Triggers and capture length can be used to define a repeating start condition.
  • Burst mode: data is captured by ‘chunks’ equal to the ‘burst size’. The maximum burst size is defined by the size of the Capture Unit’s FIFO (click here for more details about EXOSTIV IP). So, ‘burst mode’ is always an ‘interrupted’ type of capture.


Takeaways

Using EXOSTIV reduces to 2 types of capture: continuous or interrupted.
‘Continuous capture’ is easy to understand: EXOSTIV starts capturing data and has sufficient bandwidth on its transceivers to sustain data capture until its large probe memory is full.

This is an unprecedented capability for a FPGA debug tool.

‘Interrupted capture’ – whether based on trigger, data qualification, burst mode or a combination of them – help ‘better capture windows’ that focus on data of interest. Interrupted captures also help go beyond the maximum bandwidth of the transceivers and capture data even farther in time than what a continuous capture would allow.

This considerably extends your reach in time, after starting up the FPGA.

Thank you for reading.
– Frederic

STAY IN TOUCH

Sign in to our Newsletter