Column Control DTX

Planning Your Design for Debug: FPGA Dynamic Probe

Configuration Guides

Introduction

The FPGA dynamic probe is a flexible tool that allows you to view many internal design signals using a few pins connected to the logic analyzer or mixed-signal oscilloscope (MSO). The combination of this tool with advanced logic analysis physical probing and sophisticated triggering produces a powerful combination for finding the toughest FPGA bugs, as well as the easy ones.

Planning for debug during design will allow you to make best use of the FPGA dynamic probe. Planning can make the FPGA debug port a reliable, simple, and effective observation port for in-circuit verification. This document is a guide to help you in this planning process.

Planning for FPGA Debug

Planning for debug is the best insurance to help quickly get through power up and unexpected in-circuit problems. Planned debug can be the difference between an on time project and one that slips.

On-chip resources

The degree of project risk will influence the resources you will need to allow for debug­ging. How much of the design is new and untested in-circuit? If much of your design has not been verified in-circuit, your risk will be high. Many problems only manifest them­selves in-circuit when the FPGA is interacting with the surrounding system at full speed.

Resource headroom

Extra resources help design tools reach timing closure more quickly. For rapid validation and to allow for future product enhancement, some design teams allocate up to 25% to 40% of the FPGA fabric for headroom. Some of this headroom will be taken by the Keysight Technologies, Inc. Trace Core-2 (ATC2) used to facilitate rapid debug of your FPGA and the surrounding system.

Estimating resource consumption

Although a single ATC2 core can use as few as 65 LUTs and 54 flops1, additional overhead provides headroom if you encounter a situation where you want to route multiple ATC2 cores using full 32-bit banks with wide outputs widths. If you already know the dimensions of most of the units you will be debugging, you can use Keysight’s ATC resource calculator [2] to better estimate the fabric use for one or more of these debug cores.

Number of pins

The minimum debug pin width from Table 1 may be difficult to achieve using traditional debug methods. The demands of the mission-critical pins will always take precedence over the debug pins, so you may not have enough spare pins to debug your design. Con­sider how many pins you would need ideally for debug. This exercise will make you aware ahead of time of the observable and unobservable areas in your design. ATC2 is user configurable from 4 pins to 128 pins for logic analyzers, and 4 pins to 16 pins for MSOs.

Speed

If the design signals run below 200 MHz, you can use single-ended outputs from the ATC2 core to connect to the logic analyzer or MSO. If the design has internal signals that will be probed running above 200 MHz, the core should use differential outputs because signal fidelity is better preserved; thus high-speed data can be easily transferred using differential outputs. Note that if you use differential outputs, you must plan the printed circuit board (PCB) layout accordingly. Some logic analyzers and MSOs do not support differential inputs.

In some cases, 2x pin compression rate is not possible because the edges are too fast for the I/O, as in the LVCMOS 3.30 I/O standard. The only convenience 2x pin compression gives is the ability to view twice the signals with the same number of pins. Note that the MSO does not support 2x pin compression.

Number of cores

The number of ATC2 cores that normally would make sense in the design can be anywhere from 1 to n, where n is the total number of frequency domains in the FPGA design. In general, a single ATC2 core is sufficient to debug most problems. Adding a second core allows you to view two time domains. Two cores also can help you see a combination of two groups of signals. For instance, in one measurement you can view a group of signals on bank 1 on core 1 and a different group of signals on bank 2 on core 2. For another measurement you can keep core 1 on bank 1 but change to bank 3 on core 2. Having more cores enables even more combinations and also simplifies cross-clock domain debug.

Each ATC2 core has its own time base and thus requires a unique logic analysis acquisi­tion module to view all simultaneously. In this paper, we use the following definition for the term “module” for the Keysight 16900:

A module is a group of logic analysis channels that are grouped together on a single time base. The implementation may be a single logic analyzer (for example, an Keysight 1680 or 1690 Series logic analyzer or a single Keysight 16910, 16911, or 16950 logic analyz­er module), or a collection of logic analyzer modules that are connected together in a 16900 Series modular logic analysis system. Keysight 1680, 1690, and 16900 Series logic analyzers have a split analyzer mode where a single logic analyzer can be split into two time bases.2 Two ATC2 cores can be monitored simultaneously by a single logic analyzer that has been split.

If you are using a 1680 or 1690 logic analyzer, you will have only one main module. This module can be split into two modules, but this is the limit. A 16903A can have up to three cards. If each card is an independent module, you can have up to six ATC2 cores attached to it. The 16900A and 16902A mainframes hold up to six modules. With 6 mod­ules configured as separate modules, you can have up to 12 ATC2 cores connected to it.

If you are using a MSO, only one ATC2 core can be controlled at a time.

×

Please have a salesperson contact me.

*Indicates required field

Preferred method of communication? *Required Field
Preferred method of communication? Change email?
Preferred method of communication?

By clicking the button, you are providing Keysight with your personal data. See the Keysight Privacy Statement for information on how we use this data.

Thank you.

A sales representative will contact you soon.

Column Control DTX