Platform verification boards typically have multiple FPGAs and hundredsof signals that are either terminated or non-terminated running betweenthem. Checking the connectivity and locating fabrication and assemblyfaults becomes a must before the actual bitstream is loaded on theFPGAs for verification.
The interconnections between FPGAs on a typical FPGAbased platformverification board are shown in Figure1, below.
|Figure1: Signals that run from one FPGA to another (point-to-pointconnections shown as B) can be series terminated, while signals runningbetween multiple FPGAs (shown as A) can be parallel terminated.|
Signals that run from one FPGA to another (point-to-pointconnections shown as B) can be seriesterminated, while signals runningbetween multiple FPGAs (shown as A) can be parallel-terminated. Seriestermination is provided using resistor networks, (eight in one packageeach of 0402 footprint) and parallel termination using individualresistors.
Potential board faults
Such highly dense boards are more prone to assembly faults due to theuse of small package resistors and smaller-footprint resistor networksfor signal terminations.
The following are some reasons why an anomaly could be introducedbetween the connecting wires on the board:
1) Short between theadjacent signals on the terminations provided (resistor networks) or atthe FPGA balls;
2) Trace cut in the signaldue to PCB manufacturing defect or mishandling of the board;
3) Improper assembly due toBGA balls or pins of the IC not soldered properly and don't come incontact with pads on the board;
4) Crosstalk between thesignals due to proximity, thus hampering connectivity at higherfrequencies;
5) SI issues due to longtrace lengths and inadequate termination.
All the potential faults listed above make a connectivity test onthe board mandatory before the actual bit streams are tested.
|Figure2: Implement a 2bit counter (incremented every few seconds) with a2-to-4bit decoder at the source end and a 4-to-2bit encoder at the sinkend.|
Two options available to test the connectivity of the signals on theboard (only four signals are shown here for the sake of simplicity)include:
1) Implementing a 2bitcounter (incremented every few seconds) with a 2-to-4bit decoder at thesource end and a 4-to-2bit encoder at the sink end (Figure 2 above) .
At the sink end, the 2bit output can be observed on a logic analyzeror used to drive two LEDs. Manual observation of the pattern isrequired to determine if there are any issues with theinterconnections. In general, if there are N signals, we would need ak-bit counter, where k = log2(N).
2) Driving a pattern on thesignals at the source end and implementing two instances of a 2-to-1mux (along with logic to generate the mux combination) at the sink end (Figure 3 below ).
|Figure3: Drive a pattern on the signals at the source end and implement twoinstances of a 2-to-1 multiplexer (along with logic to generate themultiplexer combination) at the sink end.|
Once again, the multiplexer outputs can be observed on a logicanalyzer or on LEDs. In this case, if there are N signals, we wouldneed k 2-to-1 mux, where k = log 2(N).
Both schemes provide feasible solutions, but there are certainlimitations associated with each of these approaches:
1) There is a manualprocess involved in observing counter's binary pattern (e.g. A 4bitcounter could be counting 0000, 0001, 0010, … 1110, 1111.) either ona logic analyzer or on some LEDs.
2) The designer has toinstantiate entities such as the encoder and the decoder in the firstcase and multiplexers in the second example.
3) Localizing the faultmight not be very intuitive.
A simple, faster and more elegant approach is proposed to test theconnectivity of thousands of signals on the board (Figure 4, below ).
|Figure4: A global clock derived from the on-board crystal oscillator isdriven out on OP1 and it is taken as input on the second FPGA.|
Consider that each FPGA has eight LEDs connected to it that are usedto display the final output. Alternatively, if there are no LEDs on theboard, then the signals that have been brought out of the FPGA can beobserved on a logic analyzer or oscilloscope.
To test signal connectivity between the two FPGAs, the signals aregrouped in sets of 12. The number 12 is configurable and is deriveddepending on the global clock (master clock) frequency so that theoutput signal has a measurable frequency on the oscilloscope in use.
The small blocks marked F/F in Figure4 above represent T-type (toggle) flip-flops. A global clockderived from the on-board crystal oscillator is driven out on OP1 andis taken as input on the second FPGA. Observe the daisy-chainstructure.
Each toggle flip-flop is negative-edge-triggered and takes the inputfrom the previous T-type as its clock, thus producing a signal that ishalf the frequency of its input.
The output generated from the first T-type on the first FPGA is usedas the input to the first T-type on the second FPGA; the output fromthe first T-type on the second FPGA is used as the input to the secondT-type on the first FPGA, and so forth.
At the end of the set of 12 signals, the output is driven out on theLED. A similar process is used on the next set of 12 signals, and soforth. LEDs connected to an FPGA that is not under test can also beused to view the output if that FPGA is connected to the FPGA undertest.
Thus, if we have about 180 signals, we would end up using 15on-board LEDs. As we have an independent set of 12 signals, there is alot of scope to identify the short on the board by just observing theglowing LEDs. In many cases, the designer can exactly locate the shortand then correct it.
The greatest advantage of such an approach is that the whole processof generating Verilog code and a User Constraint File (UCF) can beautomated using a Perl script and Excel file. This ensures that thereare no errors in the implementation of the algorithm, provided thatthere are no errors in the worksheet that contains all of the storeddata.
When the test described above was run on a real board, one LED onthe board was glowing at a different frequency compared to the others.Thus, the fault was immediately isolated to the set of 12 signals thatdetermined the frequency of the LED in question.
Looking within the set of those 12 signals and observing all theoutputs with prior knowledge of the expected frequency at each output,we were able to readily pinpoint the fault on the board—a short on aseries termination resistor.
I/O configurations of the FPGA pins can be stored in tabular form on anExcel spreadsheet, where the nets from the CAD software can be directlycopied (Table 1 below ). I/Oscan be arranged in the spreadsheet to reduce the burden on the Perlscript. Pin and signal names can be used to generate the UCF for thatparticular FPGA.
|Table1: I/O configurations of the FPGA pins can be stored in tabular form onan Excel spreadsheet, where the nets from the CAD software can bedirectly copied.|
The Perl script flow can be used to generate the T flip-flopinstance as in the Verilog file for one of the FPGAs under test. Thenumber of signals per set (12 in this case) can be a programmable valuein the script so that the user, depending on the frequency of operationof the board, can control the number of signals that make a set. Oncethe T-type flip-flop instances are generated using the Perl script,they can be copied in the Verilog file.
The following is sample code generated for the first FPGA (similarcode for the second FPGA can be generated using the same script):
The advantages associated with this approach include:
1) Connectivity can betested at the highest frequency possible on the board to find out ifthere are anomalies due to crosstalk at higher frequencies.
2) It is easy to isolatethe shorts, as a distorted waveform can be produced at LED outputs incase of them.
3) In case of an opening inthe circuit, there would be no output on the LED, and backtracing inthe set of 12 would help in finding the fault.
4) As the signals aregrouped into sets of 12, shorts on the board can be exactly located bycarefully analyzing the waveforms.
5) This method overcomes thelimitation of manual observation of binary patterns on LEDs.
6) As the generation of theVerilog file and the UCFs is automated, there would be no errors in theVerilog code.
The method presented here has been verified and tested on multipleboards. This approach helps generate the Verilog test code with minimumeffort, and effectively detect assembly and fabrication-related faults.