Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > FPGAs/PLDs
?
?
FPGAs/PLDs??

Check interconnections between FPGAs on a high-density board

Posted: 01 Jun 2007 ?? ?Print Version ?Bookmark and Share

Keywords:FPGA signal connectivity? FPGA prototyping board? test FPGA interconnection?

By Rajendra C Turakani and Ritesh Ramesh Parekh
Ittiam Systems

High-density FPGA-based boards are widely used for logic development and verification before taping out the actual IC. On a high-density FPGA-based board where multiple FPGAs are interconnected with hundreds of signals, checking and validating the interconnections between the FPGAs becomes a very challenging task.

This article describes how challenging the problem is and also suggests a simple, effective and generic solution to check the signal connectivity between the FPGAs. The method also helps the designer identify and locate faults, if any, on the board, which otherwise would be a very cumbersome task. This article also proposes a method to efficiently generate the test code, most of which could be automated.

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 Figure 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.

Interconnections between FPGAs

Figure 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 2bit counter (incremented every few seconds) with 2- to 4bit decoder at the source end and a 4- to 2bit encoder at the sink end. At the sink end, this 2bit 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 Figure 2. In general, if there are N signals, we would need a k-bit counter where k = log 2(N).

Option 1

Figure 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 Figure 3. In this case, if there are N signals, we would need k 2-to-1 multiplexers, where k = log 2(N).

Option 2

Figure 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.

A new approach
A simple, faster and more elegant approach is proposed to test the connectivity of thousands of signals on the board (Figure 4). Consider that each FPGA has eight LEDs connected to it. These LEDs are used to display the final output. Alternatively, if there are no LEDs on the board, then the signals that have been brought out of the FPGA can be observed on a logic analyzer or oscilloscope. In order to test the signal connectivity between the two FPGAs, the signals are grouped in sets of 12. The number 12 is configurable and is derived depending on the global clock (master clock) frequency so that the output signal has a measurable frequency on the oscilloscope in use.

FPGA implementation

Figure 4: FPGA implementation

The small blocks denoted as F/F in this illustration represent T-type (Toggle) flip-flops. A global clock that is derived from the on-board crystal oscillator is driven out on OP1 and it is taken as input on the second FPGA. Observe the daisy-chain structure. Each toggle flip-flop is negative-edge-triggered and takes the input from the previous T-type as its clock, thereby outputting a signal that is half the frequency of its input. The output generated from the first T-type on the first FPGA is used as the input to the first T-type on the second FPGA; the output from the first T-type on the second FPGA is used as the input to the second T-type on the first FPGA, and so forth.

At the end of the set of 12 signals the output is driven out on the LED; a similar process is used on the next set of 12 signals, and so forth. LEDs connected to a FPGA that is not in test can also be used to view the output if that FPGA has some connectivity to the FPGA under test. Thus, if we have around 180 signals, we would end up using 15 on board LEDs. As we have an independent set of 12 signals, there is a lot of scope to identify the short on the board by just observing the LEDs glowing. In many cases the designer can exactly locate the short and then correct it. The greatest advantage of such an approach is that the whole process of generating Verilog code and a User constraint file (ucf) can be automated using a Perl script and Excel file. This ensures that there are be no errors in the implementation of the algorithm provided there are no errors in the excel sheet, which contains all of the stored data.

A real-case fault isolation scenario
When the test described above was run on a real board, one LED on the board was glowing at a different frequency compared to the others. Thus, the fault was immediately isolated to the set of 12 signals that determine the frequency of the LED in question. Looking within the set of those 12 signals, observing all the outputs with prior knowledge of the expected frequency at each output, we were able to readily pinpoint at the fault on the board!a short on a series termination resistor.

Automated code generation
I/O configurations of the FPGA pins can be stored in a tabular form in an Excel spreadsheet. Part of the data stored in the Excel sheet is illustrated in Table 1. Using Excel is advantageous as the nets from the CAD software can be directly copied in to the spreadsheet.

Part of the data stored in the Excel spreadsheet

Table 1. Part of the data stored in the Excel spreadsheet

Outputs and inputs can be arranged in the spreadsheet so as to reduce the burden on the Perl script. Pin names!along with the signal names!can be used to generate the ucf (User Constraint File) file for that particular FPGA.

The flow of the Perl script!which can be used to generate the T flip-flop instance as in the Verilog file for one of the FPGAs under test!is illustrated in Figure 5. The number of signals per set (which is set to 12 in this case) can be a programmable value in the script so that the user, depending on the frequency of operation of the board, can control the number of signals that make a set. Once the T-type flip-flop instances are generated using the Perl script, they can be copied in the Verilog file.

Flowchart for the Perl Code

Figure 5: Flowchart for the Perl Code

Example code generated for the first FPGA would be as shown below (similar code for the second FPGA can be generated using the same script):

Sample code generated for the first FPGA

Advantages of this approach
The advantages associated with the approach described above can be summarized as follows:

  1. We can test the connectivity at the highest frequency possible on the board and hence find out if there are anomalies due to crosstalk at higher frequencies.

  2. Easy to isolate the shorts, as we would get a distorted waveform at led outputs, in case of a short.

  3. In case of an open in the circuit there would be no output on the LED and back tracing in the set of 12 would help in finding the fault.

  4. As the signals are grouped into sets of 12, shorts on the board can be exactly located by carefully analyzing the waveforms.

  5. This method overcomes the limitation of manual observation of binary pattern on LEDs.

  6. As the generation of the verilog file and the ucf files is automated there would be no errors in the Verilog code.

Conclusion
The method presented here has been verified and tested on multiple boards. This approach helps to generate the Verilog test code with minimum effort and effectively detect assembly and fabrication related faults.

About the authors
Rajendra C. Turakani
is senior engineer for multimedia systems at Ittiam Systems Pvt Ltd.
Ritesh R Parekh is lead engineer for multimedia systems at Ittiam Systems Pvt Ltd.




Article Comments - Check interconnections between FPGAs...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top