Using Multi-Gigabit Transceivers to Test and Debug FPGA

Introducing Thunder Series

Frédéric Leens, Sales and Marketing Manager, Byte Paradigm

This white paper introduces Byte Paradigm’s new Thunder Series probe. This new generation PC-based instrument uses FPGA multi-gigabit transceivers as high-speed interface for collecting trace data and inserting test pattern stimulus during FPGA testing and debugging. This paper shows the advantages of using high bandwidth links in combination with adequate embedded instrumentation IP implemented in FPGA.

New challenges in FPGA testing and debugging

With increasing system complexities, engineers worldwide acknowledge that using a prototype in combination with simulation and other EDA tools-based techniques is a must to efficiently debug an embedded system. The programmable nature of FPGAs makes them particularly well fitted for this approach.

Being able to reprogram FPGAs allows:

• Testing partial embedded systems, even when not everything of a design is available yet.
• Exploring test cases on real silicon at real speed, overcoming the drawbacks of a slow ‘simulation-only’ approach.
• Instrument the FPGA and correlate test and debug trace with simulation results to (more) quickly isolate a bug and correct it.

When troubleshooting a FPGA, the engineer is going to run pure simulation of HDL code and test sessions on a board equipped with the target FPGA.

From traditional to embedded instrumentation

Two main approaches are used today for FPGA debugging1 on prototype:

• Using traditional instruments such as a logic analyzer or an oscilloscope connected to FPGA I/Os (Figure 1).
• Using an embedded instrumentation unit such as Xilinx Chipscope, Altera SignalTap or Lattice Reveal together with a JTAG interface connected to the PC (Figure 2).

Let’s compare these 2 techniques.

Typically, using a logic analyzer to debug a FPGA requires routing the internal nodes that have to be observed onto FPGA I/Os equipped with an accessible board connector.

Figure 1: Using a logic analyzer to debug FPGA

A logic analyzer is a very useful piece of equipment that can help overcome the limitations of a simple scope for functional – ‘digital-only’ signals. It often features 36 digital channels and more (even much more). In addition, its rich triggering and enhanced memory options allow finding infrequent error conditions.

However, using a logic analyzer for FPGA debug has got its drawbacks:

•  Reserving a large number of functional I/Os in parallel for debug is not always possible.
•  Routing large number of internal FPGA nodes to the FPGA I/Os affects the functional design and can be the source of timing problems; it is also sometimes simply impossible.
•  There must be an accessible debug connector on the board that is mounted with the FPGA. For a large number of signals, such a connector is not always available.

FPGA internal nodes are often multiplexed onto the same set of I/Os used for debug. This helps observe more of the internal logic while avoiding extending the total number of functional I/Os required for debug.

Alternatively, an embedded logic analyzer makes use of FPGA hardware resources to store and collect FPGA trace data. This approach requires ‘some’ logic, ‘some’ memory and using the JTAG port of the FPGA.

Figure 2: Using an embedded logic analyzer to debug FPGA

This technique uses the JTAG port to access trace data, which saves FPGA’s functional I/Os. Moreover, the JTAG connector footprint is generally small. It is often present for programming the FPGA. This is an advantage over having to reserve a specific high-speed connector on board.

Trace data is collected using the internal clock resources of the FPGA – that is to say, in the same clock domain as the FPGA logic. This can be an advantage over collecting the data from the chip I/Os, as the I/O toggling rate can be more limited due to board constraints or constraints from the I/O buffers themselves.

Embedded Instrumentation seems to be the natural evolution of traditional instrumentation - for many reasons:

• There is a trend towards using FPGA as a system platform for integrating most of embedded system’s functionalities. The boundaries of a specific functionality in a complex embedded system do not match the boundaries of components any more. Hence, to test specific functional blocks, the points of measure are located inside the FPGA chip.
• Increasing data bus frequencies has made test and measurement at board level increasingly complex and invasive. In some cases, high speed data bus measurement cannot be done without seriously disturbing the system functionality.

As a consequence, the test and debug instrument tends to ‘enter the chip’. It is integrated close to the FPGA functional logic.

However, such embedded instruments require FPGA resources to:

• Store trace data: use of FPGA RAM
• Implement triggering: use of FPGA logic

How do these techniques compete?

Figure 3: FPGA debugging techniques - position chart

Table 1: Main limiting factors of FPGA analysis techniques

The table and the chart above summarize the respective limiting factor of each technique and show the usual possible solution to overcome these limitations. Of course, these solutions are always implemented at the expenses of the FPGA logic resources.

Exploring the solutions space

From the chart at Figure 4, two areas are left unexplored:

• Quadrant 4 is no improvement: it has got a high impact on both the FPGA memory and pin count.
• Quadrant 2 represents test and debug solutions that have low impact on both FPGA memory and FPGA pin count.

Let us try to reach ‘quadrant 2’ from the existing solutions.

Reducing the impact of Embedded Logic Analyzer on FPGA memory would require storing trace data outside the FPGA. To be practical, this data must flow out of the FPGA at a sufficient rate. This is true even if a limited portion of the FPGA memory is used as a temporary buffer.

On the other hand, reducing the pin count required by the Traditional Logic Analyzer solution would lead to increasing the throughput of the I/Os used for debug – if the same nodes must be observed.

Hence, the basic requirements of an alternative debug solution are:

• Placing the trace memory outside the FPGA.
• Using a small(er) number of high(er) throughput I/Os to send data outside the FPGA.

Figure 4: Thunder Series versus other solutions

Thunder Series – overview

The new Thunder Series probe from Byte Paradigm locates the trace/stimulus memory outside the FPGA while using available multi-gigabit transceivers for conveying data to and from the FPGA.

Figure 5: Overview of Thunder solution

Byte Paradigm’s Thunder solution is composed of 3 parts:

1. Thunder Instrumentation Logic IP, that is an embedded instrumentation IP implemented with the FPGA resources. This IP notably implements the logic needed to control the FPGA multi-gigabit transceivers, some buffering (FIFO), data formatting logic and trigger logic needed to isolate what needs to be observed.When Thunder is used as a source of digital stimulus, this IP manages the connection with the FPGA subsystem inputs.
2. Thunder probe, which contains the trace memory. Minimum trace memory of Thunder probe is 512 MB. Thunder probe is connected to a PC through USB 2.0 or PCIe 1x connection on cable. In its simplest version, Thunder probe supports up to 2x 3.125 Gbps multi-gigabit links.
3. Thunder Studio Software, running on PC, used to setup and control Thunder probe and Thunder IP.

Figure 6: Thunder Series probe - overview

A new solution for new FPGA challenges

FPGA has become the platform of choice for complex digital systems. Full embedded systems that used to be implemented with a choice of separate digital ICs mounted on a board can now be implemented with a single FPGA chip.

Today’s FPGAs are very powerful all-around digital chips that are able to hold multiple general-purpose RISC microcontrollers, implement a bus system, glue logic, DSP functions and other application-specific data processing.

FPGAs also contain lots of memory resources, support multiple I/O standards and have advanced communication interface building blocks such as Ethernet or PCIe PHY. Internal frequency can be as high as 500 MHz and above, making of high-end FPGA very impressive pieces of hardware reaching unprecedented levels of computing and data processing power.

This poses new challenges for FPGA design, debug and test.

First, FPGAs need powerful connections able to ‘feed’ them at a very high throughput. This is a condition for efficiently using their computing power capable to process ‘a lot of data’ in real-time. For that reason, multi-gigabit transceivers able to transmit serial data at several Gbps (now even up to 28 Gbps on optical links) have become very common FPGA features (even for entry-level FPGA).

Second, FPGA design has evolved towards real ‘platform design’, similar to ‘System-on-Chip’ (SoC) design. This evolution of FPGA architectures aims at reaching shorter product time-to-market while handling higher system complexity. Designing FPGA has become a matter of carefully choosing how to partition FPGA design between 3rd party IPs (Intellect Property) and IPs designed in-house. Debugging and testing each of these IPs or multiple IPs assembled as ‘subsystems’ is good practice before debugging and testing the whole system.

It is no wonder why embedded instrumentation has been increasingly successful. When each functional block of an embedded system was implemented with a separate component, measurement and testing used to be executed at the components boundaries. In a system implemented with a single FPGA chip, the boundaries can be IP boundaries, which must be accessed from inside the chip. Moreover probing from physical board connections is not always possible and can be too intrusive.

Thunder Series probe falls in the category of ‘embedded instrumentation solution’. It uses the available FPGA multi-gigabit transceivers as data channel to debug and test FPGA systems. It works with an instrumentation IP implemented in the FPGA to:

• Reach the FPGA internal logic
• Extract FPGA internal data and send it to an external trace memory
• ‘Inject’ input stimulus for testing FPGA IPs and subsystems

Table 2 below compares it with the other debug solutions described in this paper.

Thunder Series probe uses full-duplex connections.

With the proper embedded instrumentation IP in the FPGA, this enables generating the inputs of the internal IP as well. This can prove to be extremely useful when input stimulus must be used to test partial designs composed of IPs – especially when not everything in the system is available yet. It opens the way to new approach for testing FPGA, especially when testing partial designs or when using another kind of input source (like a digital pattern generator) is too invasive.

In its first implementation, Thunder Series probe features two multi-gigabit links at 3.125 Gbps, implementing a 6.250 Gbps total bandwidth for test and debug data. Out of this bandwidth, useable throughput can be up to 5 Gbps full duplex. While this may seem very high, this bandwidth must be used wisely:

This represents the continuous probing of 40 bits at 100 MHz, 20 bits at 200 MHz, 10 bits at 400 MHz, and so on…. With advanced triggering and filtering in the FPGA coupled with some buffering, bursts recorded from larger busses can be probed.

Table 2: Debug techniques - comparison

Conclusions

Byte Paradigm’s new Thunder Series probe complements the existing solutions for FPGA debugging.
By placing a large memory buffer outside the FPGA and using multi-gigabit transceivers to transport trace data, Thunder Series instrument extends the notion of embedded instrumentation.
It overcomes memory limitations of embedded instrumentation while having no impact on the usual I/O resources. This is made possible by using multi-gigabit transceivers left unused by the FPGA design.

Moreover, Thunder Series probe offers testing capabilities that are currently unexplored by existing instrumentation solutions.

With the adequate set of instrumentation IP, Thunder Series probe uses full-duplex multi-gigabit transceivers and allows ‘injecting’ the input stimulus inside the FPGA. In a world of FPGA being used as a platform for full complex systems, this enables testing subsystem and blocks of IPs from PC.

About the author

Frédéric Leens is Sales and Marketing Manager at Byte Paradigm.

1 Let us stress again the importance of using simulation together with testing/debugging on a ‘real’ FPGA prototype for efficient debugging.