Interconnect Testing in Cluster Based FPGA Architectures

1. Interconnect Testing in Cluster Based FPGA Architectures Research by Ian G.Harris and Russel Tessier University of Massachusetts. Presented by Alpha Oumar Barry McGill University MACS 304-649B March 2001

2. Motivation • IC densities increase • More complex FPGA Architectures • Cluster-based architectures become an architecture of choice for a lot of FPGA manufacturers.

3. Definition / Challenge • Several logic blocks are grouped together into a cluster. Clusters are connected to other clusters via Switch Matrices. • High density local interconnect within clusters : - improves FPGA utilization BUT!!! - greatly complicates FPGA testing problem.

4. FPGA: composed of an array of identical tiles (Fig. 1a). Tile: composed of a cluster and surrounding interconnect (Fig 1b). Interconnect: set of lines which can be connected by a set of programmable interconnect points (PIP) which act as switches. Fig 1c: is a commonly used structure for PIPs. Each dashed line is a PIP. A PIP connects each line to one line on each side of the matrix. For testing purposes we need to make a difference between cluster I/O and tile I/O. Cluster I/O are internal to the tile while tile I/O connects to neighboring tiles.

5. Cluster: composed of a set of basic logic elements (BLE) BLE: composed of a set of programmable lookup tables (LUT), multiplexers and flip- flops. Each BLE input can connect to the output of any other BLE and to any cluster input. The output of each BLE is assumed to be connected directly to a cluster output.

6. Testing Methodology • Hierarchical approach : defines several FPGA configurations that detect bridging faults involving intra-cluster and extra-cluster interconnects • Hierarchical structure of a cluster-basedtile is exploited in defining the different configurations (To facilitate test configuration generation process).

7. Testing Methodology • In each configuration, FPGA circuitry dedicated as BIST logic will perform test generation and response analysis to test non-BIST FPGA circuitry • Consequently, FPGA will be configured as many independent BISTers structure similar to the one in Fig. 3

8. BISTer: composed of a test pattern generator (TPG), an output response analyzer (ORA), and two blocks under test (BUT). TPG: simply a counter which applies an exhaustive test sequence to the BUT BUT: each BUT is a single tile in the FPGA which is being tested ORA: a comparator which sets the Pass/Fail flip-flop to ‘1’ if the outputs of both BUTs do not agree (XOR). Each BISTer will be implemented as a rectangular block of tiles. The number of tiles in a BISTer will depend on the number of tiles needed to implement TPG and ORA. BISTers will be implemented to cover an entire tile array.

9. !!! Tiles dedicated to TPG and ORA !!! Are not completely tested. >> FPGA will be reconfigured to shift the BISTers across the entire array (Fig. 4) Tile is fully tested when it acts as a BUT. But BUT must be surrounded by TPG/ORA. !!! Perimeter tiles will not be fully tested (by this uniform repetitive reconfiguration procedure !!! >> BISTer layout must be modified to use I/O pads to access the tiles on the periphery

10. Interconnect Faults • Permanent Connection (PC): Short between two lines • Permanent Disconnection (PD): Line broken in two or more lines • Stuck-At 0 (SA0): PC of a line and ground • Stuck-At 1 (SA1): PC of a line and power

11. Observability/Controllability • PC defect: Both lines separately controllable At least one line observable PIP configured off • PD defect: Both lines controllable Both lines observable PIP configured on • SA0/SA1: Line must be controllable+observable

12. Intra-Cluster Configuration • LUT configured as 4-input XOR • All BLE outputs are separately controllable from each other, and from all cluster inputs • Each IMUX configured to select data from each of its inputs in at least one configuration • There is a sensitized path from each cluster input stem to a cluster output in each conf.

13. Algorithm 1: Intra-cluster Configuration Algorithm label all intra-cluster faults as undetected repeat repeat select a BLE which is not configured, b initialize IMUX configurations of b repeat enumerate next IMUX configuration compute BLE output function until BLE function is unique until all BLEs are configured identify detectable faults until all faults are detectable in some configuration

14. Extra-Cluster Configurations Goal: create current flow paths between tile I/O nodes which allow the detection criteria for each fault to be satisfied in at least one configuration

15. Algorithm 2: Extra-cluster Configuration Algorithm Create interconnect graph Repeat Label all nodes as untouched Repeat Select an untouched node n Identify an untouched path from n to a cluster I/O label all nodes on the path as touched Identify an untouched path from n to a tile I/O label all nodes on the path as touched Until paths connect all cluster I/O to tile I/O Repeat Select an untouched node n Identify an untouched path from n to a tile I/O label all nodes on the path as touched Identify an untouched path from n to a tile I/O label all nodes on the path as touched Until no more untouched paths can be created Identify detectable faults Until all faults are detectable in a configuration

16. Experimental Results N: Number of BLEs Confs: Number of FPGA configurations I: Number of Cluster Inputs Min : Theoretical minimum number of configurations Fcov: Fault coverage (One additional configuration would give 100% fault coverage in all cases)

17. Advantages • This BIST strategy decomposes testing problem of entire FPGA into many identical problems of a size which is fixed by the test requirements for a single tile (design of TPG and ORA is same for all tiles!) • Size of smaller problem is fixed, so this approach is easily scalable to FPGA arrays of any size

18. Advantages / Disadvantages • Many ASIC DFT approaches involve modifying the circuit functionality to incorporate test functionality • FPGA reconfiguration avoids that circuit overhead • BUT!!! Several configurations are needed and time to reconfigure FPGA is not negligible