How to test the interconnections between FPGAs on a high-density FPGA-based board

Introduction
Platform verification boards typically have multiple FPGAs and hundreds of signals – either terminated or non-terminated – running between them. Checking the connectivity and locating fabrication and assembly faults becomes a must before the actual bitstream is loaded on the FPGAs for verification.

Interconnections on a typical FPGA-based verification board
The interconnections between FPGAs on a typical FPGA-based platform verification board are illustrated in Fig 1. Signals that run from one FPGA to another (point-to-point connections shown as B in the figure) can be series terminated; signals running between multiple FPGAs (shown as A in the figure) can be parallel terminated. Series termination is provided using resistor networks (8 in one package each of 0402 footprint) and parallel termination using individual resistors.

1. Interconnections between FPGAs.

Potential faults on the board
Such highly dense boards are more prone for assembly faults due to the usage of small (0402) package resistors and smaller footprint resistor networks for signal terminations. Here are a few reasons why an anomaly could be introduced between the connecting wires on the board.

1. Short between the adjacent signals on the terminations provided (resistor networks) or at the FPGA balls.
2. Trace cut in the signal due to PCB manufacturing defect or due to mishandling of the board.
3. Improper assembly due to which BGA balls or the pins of the IC are not soldered properly and do not make contact to the pads on the board.
4. Cross talk between the signals due to proximity hence hampering the connectivity at higher frequencies.
5. Signal integrity issues due to long trace lengths and inadequate termination

Connectivity tests
All the potential faults listed above make a connectivity test mandatory on the board before the actual bit streams are tested. Here are a few options available to the designer to test the connectivity of the signals on the board (only four signals are shown here for the sake of simplicity):

Option 1) Implement a 2-bit counter (incremented every few seconds) with 2-to-4 bit decoder at the source end and a 4-to-2 bit encoder at the sink end. At the sink end, this 2-bit output can be observed on a logic analyzer or used to drive two LEDs. By manual observation of the pattern, one would come to know if there are any issues with the interconnections. A diagrammatic representation of this scheme is illustrated in Fig 2. In general, if there are N signals, we would need a k-bit counter where k = log 2(N).

2. Option 1.

Option 2) Drive some pattern on the signals at the source end and implement two instances of a 2-to-1 multiplexer (along with logic to generate the multiplexer combination) at the sink end. Once again, the multiplexer outputs can be observed on a logic analyzer or on LEDs. A diagrammatic representation of this scheme is illustrated in Fig 3. In this case, if there are N signals, we would need k 2-to-1 multiplexers, where k = log 2(N).

3. Option 2.

Both of the above schemes provide feasible solutions, but there are certain limitations associated with both of these approaches as follows:

1. There is a manual process involved in observing counter's binary pattern (e.g: A 4-bit counter could be counting 0000, 0001, 0010, ... 1110, 1111) either on a logic analyzer or on some LEDs.
2. The designer has to instantiate entities like the encoder and the decoder in the first case and multiplexers in the second example.
3. Localizing the fault might not be very intuitive.