Microelectronics Reliability

Transcription

1 Microelectronics Reliability 53 (2013) Contents lists available at SciVerse ScienceDirect Microelectronics Reliability journal homepage: A Built-In Self-Test (BIST) system with non-intrusive TPG and ORA for FPGA test and diagnosis Aiwu Ruan, Shi Kang, Yu Wang, Xiao Han, Zujian Zhu, Yongbo Liao, Peng Li State Key Laboratory of Electronic Films and Integrated Devices, University of Electronic Science and Technology of China, Chengdu , China article info abstract Article history: Received 8 September 2011 Received in revised form 11 September 2012 Accepted 11 September 2012 Available online 23 October 2012 This paper presents a BIST system with non-intrusive test pattern generator (TPG) and output response analyzer (ORA) for field-programmable gate array (FPGA) test and diagnosis. The proposed BIST system physically consists of software and hardware parts with two communication channels in between. The TPG and ORA of the BIST circuitry are in the software part while a circuit under test (CUT) is in the hardware part, respectively. One more FPGA is incorporated in the hardware part to act as an interface between the TPG, ORA and the CUT. Algorithms for FPGA test and diagnosis are also presented. Compared with embedded BIST technique, configuration numbers can be reduced without exchanging the TPG, ORA for the CUT when the proposed BIST system is applied to test an FPGA. Also, the proposed BIST system can provide good observability and controllability for the FPGA-under-test due to the proposed algorithms developed for test and diagnosis. No matter what type and array size of an FPGA-under-test is, the CUT can be tested by the proposed BIST system. The BIST system is evaluated by testing several Xilinx series FPGAs, and experimental results are provided. Ó 2012 Elsevier Ltd. All rights reserved. 1. Introduction An FPGA is composed of a large amount of repeated and regular configurable logic blocks (CLBs), interconnect resources (IRs), and input/output blocks (IOBs), each of which incorporates logic gates, D flip-flops (D-FFs) and control units. FPGAs have increasingly played an important role in modern electronic industry due to their reconfigurability, flexibility, low development cost, and reduced time-to-market, since they were introduced by Philips in the early 1970s. Applications for FPGAs are diversified, e.g. communications, storage systems, adaptive computing, etc. Thanks to shrinking_size of transistors fabricated by nano- CMOS manufacturing process, more and more complicated structures of FPGAs can be implemented. As a result, more and more Abbreviations: BIST, Built-In Self-Test; CLB, configurable logic block; CUT, circuit under test; D-FF, D flip-flop; EDA, electronic design automation; FPGA, fieldprogrammable gate array; IOB, input/output block; IR, interconnect resource; ISE, integrated software environment; JTAG, joint test action group; LUT, look-up table; MVP, module verification platform; ORA, output response analyzer; PCIE, peripheral component interface express; PIP, programmable-interconnect-point; RTL, register transfer level; SM, switch matrix; SPI, software procedural interface; STAR, selftesting area; TC, test configuration; TPG, test pattern generator; TR, test response; TV, test vector; XOR, exclusive or; XNOR, exclusive nor; Verilog HDL, Verilog hardware description language; VHDL, very-high-speed integrated circuit hardware description language; VPI, Verilog hdl procedural interface. Corresponding author. address: ruanaiwu@uestc.edu.cn (A. Ruan). functions can be realized by FPGAs. However, several types of defects can be introduced by the manufacturing process, such as stuck-at faults, delay faults, etc. A study showed that FPGAs at and beyond the 45 nm technology node have low yield [1]. FPGAs have high density of transistors and interconnect wires. Hence, after FPGAs have been fabricated, they are tested extensively to find faulty ones from the batch. The idea of BIST was first proposed around 1980s and has become one of the most important testing techniques at the current time, as well as for the future. The basic idea of BIST is to design a circuit which can test itself and determine whether it is faulty or fault-free. This typically requires that additional circuitry and functionality are incorporated into the design of the circuit to facilitate the self-testing feature. This additional functionality is implemented by a TPG and an ORA. A sequence of patterns for testing a CUT is produced by the TPG, while the ORA determines whether the output responses are corresponding to those of a fault-free circuit [2]. From the perspective of whether the TPG and ORA are embedded in the FPGA-under-test or not, BIST techniques for FPGA test are categorized into intrusive BIST [3 12,15] and non-intrusive BIST approaches [16]. Usually the terminology of embedded BIST can substitute for that of intrusive BIST. In the area of FPGA test, the embedded BIST approach has been increasingly applied to FPGA test in recent years. The embedded BIST method includes configuring one part of the FPGA to undergo testing, configuring the other parts to generate test vectors and analyze test results /$ - see front matter Ó 2012 Elsevier Ltd. All rights reserved.

2 A. Ruan et al. / Microelectronics Reliability 53 (2013) Owing to the embedded BIST logic disappearing when the circuit is reconfigured for its normal system operation, area overhead can be avoided [3]. However, the parts of the FPGA configured as TPGs and ORAs have to be reconfigured as CUTs for testing. This, consequently, increases configuration numbers of the FPGA-under-test. On the other hand, there is a work done with non-intrusive BIST technique for FPGA test [16]. Although exchanging the TPG, ORA for the CUT is not necessary, the research did not study how to achieve observability and controllability for FPGA test. In the context of FPGA test, observability is the ability to observe faults, while controllability describes the capability of determining fault sites [2,17]. In our paper, observability and controllability are relevant to the capability of fault test and diagnosis respectively without fault masking. In this paper, a system based on BIST approach with nonintrusive TPG and ORA for FPGA test and diagnosis is presented. The BIST system physically consists of two parts, namely software and hardware parts with two communication channels in between. The TPG and ORA of the BIST circuitry are in the software part while the CUT is in the hardware part, respectively. One more FPGA is incorporated in the hardware part to act as an interface between the TPG, ORA and the CUT. Algorithms for FPGA test and diagnosis are also presented. As shown in Section 4.2, these algorithms can be applied to different series FPGAs with minor modifications. The proposed nonintrusive BIST system along with FPGA test algorithms can address the aforementioned disadvantages of the intrusive BIST approach and the previous work done with non-intrusive BIST method. Further, good observability and controllability for an FPGA-under-test can be achieved. Test vectors (TVs) can be applied to an FPGA-under-test no matter whether the TVs are in the form of untimed signals or not. The TVs can be written by either C language or Verilog HDL/VHDL. These text format TVs facilitate the TV revision in the process of FPGA test. Although our proposed system can be used in both online and offline testing scenarios, the latter is focused on in this paper. The rest of the paper is organized as follows. In Section 2, background related to both intrusive and non-intrusive BIST techniques for FPGA test is introduced. Our BIST system is presented in Section 3. In this section, the architecture, operational principle and synchronization mechanism of the proposed BIST system are described in detail. In Section 4, implementation of the proposed BIST system along with algorithms for FPGA test and diagnosis are evaluated, and experiment is conducted on several Xilinx series FPGAs. We conclude in Section Background In this section, we discuss why non-intrusive BIST approach is used, as well as the previous work done with non-intrusive BIST technique for FPGA test. The term of non-intrusive BIST was first proposed by Charles E. Stroud in his book A Designer s Guide to Built-In Self-Test [2]. In his book, he mentioned When the TPG and ORA functions are implemented using existing flip-flops and registers of the FPGAunder-test, the BIST architecture is generally referred to as embedded or intrusive. Therefore, non-intrusive BIST architectures refer to the TPG and ORA functions NOT implemented by existing flipflops and registers of the FPGA-under-test. Rather, the TPG and ORA functions are carried out by some resources external from the FPGA-under-test, i.e. an FPGA [16]. The intrusive BIST technique is now increasingly applied to FPGA test and diagnosis [3 12,15]. This is primarily due to the reprogrammable characteristic of FPGAs. As a result, no area overhead and delay penalties are incurred. Despite these advantages, the intrusive BIST technique has several limitations. Usually, TVs generated by embedded TPG are binary numbers, i.e. 0 and 1 [11]. It is not convenient for users to revise TVs in the process of FPGA test. Further, configuration numbers are increased because the sections occupied by TPGs and ORAs are frequently exchanged for those occupied by CUTs to bring every section of the FPGA to be tested. The configuration numbers are strongly dependent on the FPGA array size as well as the complexity of TPGs and ORAs. This approach results in complicated FPGA test procedure and, consequently higher testing cost. In order to address the aforementioned limitations of the intrusive BIST technique, the non-intrusive BIST approach is adopted. The configuration numbers obtained by our approach are not strongly dependent on an FPGA array size, thanks to specially developed algorithms for FPGA test and diagnosis which will be introduced in Section 4.2. More exactly, the configuration numbers are subject to input terminal numbers of programmable-interconnect-points (PIPs), as well as types of wire segments. A.Gardel comes up with an evaluation system of an internal state of FPGA [16]. The system includes two parts, software and hardware. The software part is a PC with software test application while the hardware part consists of two boards that bear the resources to be tested and diagnosed. The first board contains an FPGA which will manage the test patterns and the results. The second board contains an FPGA-under-test. However, the paper did not study the algorithms to diagnose fault sites. Since controllability is relevant to the capability of fault diagnosis without fault masking in FPGA test, limited controllability is provided by the system for the FPGA-under-test. 3. Proposed BIST system 3.1. Architecture of proposed BIST system The proposed architecture of the BIST system is shown in Fig. 1. The BIST system is physically composed of the software and hardware parts with two communication channels in between. The software part actually incorporates some electronic design automation (EDA) commercial software tools as well as some inhouse developed software tools. These software tools run in a PC to implement a Co-test Controller, a Configuration Controller, a TPG, an ORA, a CUT Wrapper, as well as a communication interface module. The communication interface module consists of a TPG Port Proxy and an ORA Port Proxy. The Co-test Controller is responsible for communication synchronization between the software and hardware parts. In addition, the Configuration Controller manages configurations for FPGA-under-test. The CUT Wrapper in the software side is the mapping of the CUT in the hardware side. Put another way, the virtual pin definitions of the CUT Wrapper strictly Fig. 1. Architecture of the proposed BIST system.

3 490 A. Ruan et al. / Microelectronics Reliability 53 (2013) correspond to those of the CUT in the hardware side. Since the wrapper is the mapping of the FPGA-under-test, the wrapper file is relevant to the configuration file of the FPGA-under-test. The configuration files are actually dependent on algorithms of FPGA fault test and diagnosis. The algorithms of FPGA test and diagnosis will be discussed in the later part of the paper. Generally speaking, the software part performs works such as generation of configuration files for the FPGA-under-test, developing configuration timing for the FPGA on F1, generating virtual pin files for the FPGA-under-test by an in-house developed Module Verification Platform (MVP) software tool, building a testbench, controlling the synchronization mechanism and displaying response waveforms in ModelSim Simulator provided by Mentor Graph, as well as analyzing and processing test results, etc. The testbench in the paper refers to the TPG, the ORA and the CUT wrapper in the software part. The hardware part is made up of two sub-hardware blocks, F1 and F2. F2 refers to an FPGA-under-test or a CUT. F1 includes a TPG Port, an ORA Port, and an FPGA-under-test Transactor implemented by an FPGA. One of the aforementioned communication channels, entitled Channel_1, is a bidirectional system bus and runs between the software side and F1. The second channel, denoted as Channel_2, connects F2 with the software side. Channel_2 is a bus based on Joint Test Action Group (JTAG) standard for downloading and reading back configuration bitstream. The configuration files for the FPGA-under-test are generated in the software side and transmitted to F2 via Channel_2. Also, a readback procedure is conducted through Channel_2 to verify whether errors occur or not during configuration. The TVs produced by the TPG in the software side are applied to F1 through Channel_1 and the response from the CUT is returned to the ORA in the software side via Channel_1. In fact, the FPGA-under-test itself often appears as a bus-cycle accurate, register transfer level (RTL) model or a gate-level netlist, while the TVs represent themselves as an untimed set of signals. Therefore, a proxy in the software side and a transactor in the hardware side are required to interface the bus-cycle accurate signals with the untimed signals. In other words, translation of the untimed TVs to cycle-accurate pin activity is performed by the TPG Port Proxy in the software side. Alternately, the transactor in F1 recomposes sequence of the response coming from the FPGAunder-test back into untimed signals to be sent via the ORA port to the software side. On the one hand, F1 gets data from the software side, then transfers the data into the electronic signals and assigns them to the suitable input ports of the CUT as the testing stimulus. On the other hand, F1 gets response electronic signals from the output ports of the CUT, transfers them into the format the computer software tools can read, and then sends the response data back to the software part. In other words, F1 accomplishes the communication between the software side and the CUT. Thus, F1 performs as an interface between the TPG, ORA and the CUT Operation principle of the proposed BIST scheme By definition, co-test means two different systems coupled to each other to complete the test of a single design. In the proposed BIST system, the software part and hardware part work in turn to test an FPGA. Basically, three steps are required to test an FPGA. Firstly, a configuration file is downloaded to the CUT. Secondly, a testbench runs in ModelSim Simulator. As mentioned in Section 3.1, the testbench in the paper refers to the TPG, the ORA and the CUT wrapper in the software part. In the second step, TVs generated by the TPG are sent to the CUT through Channel_1 and F1, while the responses from the CUT are transmitted back to ModelSim Simulator. In this section, mechanism of data exchange between the software part and hardware part will be discussed with synchronization mechanism between the two parts left to Section 3.3. Finally, the responses from the CUT are analyzed in the software side. The three steps are repeated until all of the internal resources of the CUT are tested. After the user chooses the configuration file of the CUT through the Configuration Controller, the Configuration Controller orders F1 to configure the CUT. The F1 internal configuration control logic sends a start signal for configuration in terms of timing requirements of the FPGA-under-test under passive configuration mode. If there is no error, the CUT will respond a ready signal of configuration to F1. It should be emphasized here that a readback procedure is conducted to verify whether errors occur or not during configuration. Actually, we can use impact to perform JTAG-based readback verify. As mentioned in Section 3.1, Channel_2 is a bus based on JTAG standard for downloading and reading back configuration bitstream. impact, the device programming software provided by Xilinx Integrated Software Environment (ISE), can perform all readback and comparison functions for SRAM-based FPGAs from Xilinx and report to the user whether there are any configuration errors. Once configuration memory is read from the device, the next step is to determine if there are any errors by comparing the readback bitstream to the configuration bitstream. After receiving the ready signal, F1 informs the software part to start sending the configuration data. The software part reads the configuration data and sends the data to F1 in 32-bit format through a Peripheral Component Interface Express (PCIE) bus. After receiving the configuration data, F1 generates a correct configuration clock Co-TEST_CLOCK according to the configuration clock requirement, and sends the serial configuration data to the CUT. After receiving the configuration data, internal SRAM unit of the CUT is configured until the configuration of all units are completed. Next, the CUT sends a finish signal to F1. Thus, the entire configuration process is completed. When the testbench runs in ModelSim Simulator, Verilog HDL Procedural Interface (VPI) of ModelSim Simulator is called to send TVs from the software part to F1 through Channel_1. Then F1 transfers the TVs into the electronic signals and assigns them to the suitable input ports of the CUT. The response electronic signals from the output ports of the CUT are transferred by F1 into the format the computer software tools can read, and then sent back to the software part for analysis. The Co-test Controller in the software part controls the test process. TC_CLOCK generated by the Co-test Controller programs the CUT to the next configuration, while Co-TEST_CLOCK produced by F1 carries out the test process. As shown in Fig. 2, it takes six Co-TEST_CLOCK cycles to test each configuration: the first cycle transmits configuration, cycle 2 disables the configuration, cycle 3 turns on the TPG, tests the CUT while the result is returned to the ORA in cycle 4, cycle 5 disables the TPG, and cycle 6 clears the ORA state for the next test. One co-test cycle is implemented. The cycle is repeated and system clock will increase until all co-test Enable TC config 1 config 2 config 3 Disable TC Enable TV Disable TV ORA Clear ORA Fig. 2. Clocking scheme for FPGA test.

4 A. Ruan et al. / Microelectronics Reliability 53 (2013) procedures are finished. Consequently, all internal resources of the FPGA can be tested automatically and repeatedly Synchronization mechanism The BIST platform cannot work without an efficient communication mechanism between the software and hardware parts. In order to ensure the correctness of the CUT test, we not only have to make sure port data are exchanged correctly between the two parts, but should learn callback mechanism, especially when a VPI callback task is called by ModelSim Simulator to invoke an execution process for the FPGA-under-test as well. This issue is usually related to software/hardware synchronization. Current digital simulators allow simulation with user defined models written in C programming language. This is usually done using Software Procedural Interface (SPI). In our system, we use Modelsim s VPI to link an FPGA-under-test into simulation scheduling model as a new simulation event. Bridging the FPGA-under-test to other Verilog simulators is also available since VPI is a part of IEEE Verilog Standard. Verilog VPI is a bunch of C programming language functions, which provide procedural access to information within a Verilog simulator. A user-defined application can use these functions to traverse the design hierarchy of the simulated design, get information about the simulator and modify logic value of any design component on the run. Verilog VPI imports the callback, which is a C function that is registered to the simulator for a specific reason. The registered callback function is called whenever the reason occurs, for example, a value changes on a specific signal. Simulation s role in the context of FPGA test is to link an FPGAunder-test into the simulation scheduling model as a new simulation event. Software simulation is based on a certain simulation algorithm. When a CUT is introduced into the simulation process, test of the CUT should follow the simulation algorithm in order to ensure the correctness of the CUT test. After the simulation has started, once any changing event for input values in the wrapper ports is detected, VPI callback task is called by ModelSim Simulator to transfer the input port data from the software simulator to the input port of the FPGA-under-test. Then a test process for one CUT clock cycle is triggered. When the CUT finishes execution, the response output port data is read back through F1 and put back into the software simulator. Following the above execution rule, the CUT is integrated into the software simulator to implement the CUT test. Fig. 3 shows the synchronization process between the software part and hardware part. After simulation has started, the two parts run in turn. As shown in figure, the ith CUT Wrapper is represented by C i, and it exists in the software simulator as a dummy wrapper along with only port information. i denotes the ith configuration in n configurations. The CUT test is led by the software simulator, and when there is a need to calculate the output value of the CUT Wrapper (C i in Fig. 3), ModelSim Simulator sends the corresponding TV i to the CUT. Then, ModelSim Simulator passes execution control to the hardware part and stop simulation. When the ith CUT test finishes execution, the test response (TR i ) is then put back to the simulator, and the software simulation continues. The procedure repeats until all resources of the CUT are tested. Therefore, the key issue for CUT test is how and when port data exchange takes place between the software and hardware parts. 4. Evaluation of the BIST system 4.1. Implementation of the BIST system An in-house BIST system with a PCIE bus as the communication Channel_1 and a bus based on JTAG Standard as Channel_2 has been developed, as shown in Fig. 4. As illustrated in Fig. 4, the FPGA test system is composed of a PC with the relevant software tools, a mother board as the hardware subsystem (F1) and a daughter board as the FPGA-under-test (F2). The hardware subsystem consists of three blocks, PCIE interface, test control circuitry and socket for the FPGA-under-test. The FPGA-under-test is mounted on the socket of daughter board, which is plugged into the mother board. When our proposed BIST system is employed for testing an FPGA consisting of IOBs, CLBs and IRs, test steps are listed as follows: The Configuration Controller in the software part automatically generates configuration files one by one for the IOBs, CLBs and IRs. Next, the configuration files are transmitted to the hardware part to configure the FPGA-under-test. A table of TVs for the CUT is predefined by the software part in the PC. In other words, The TVs are defined for all IOBs, CLBs and IRs and sent to the CUT. Test results will be returned to the software part. The test process will repeat until all IOBs, CLBs and IRs are tested exhaustively. The end time of each test step can be monitored by the Co-test Controller in the software part and consequently a new test can be initiated. After each test has been implemented one by one, the test results will be compared with the expected data in the software part. Finally, a test report will be generated. During these steps, fault sites in the FPGA-under-test are capable of being automatically positioned Algorithms for FPGA fault test and diagnosis We have published several papers about FPGA fault test and diagnosis, covering IOBs, CLBs and IRs, carry-logics, and widedecoders [18 20]. The test of the first three resources will be Fig. 3. Synchronization mechanism for ModelSim simulator and FPGA-under-test.

5 492 A. Ruan et al. / Microelectronics Reliability 53 (2013) Software side Hardware side CUT Channel_1 Channel_2 Fig. 4. Implementation of the proposed BIST system. discussed in the paper while the last two resources tests are ignored since their test approaches are straightforward and detailed information can be found in [13]. These algorithms as well as fault types will be introduced in the section with the proof of their effectiveness provided in Section Fault types The CLB and IOB Faults in this paper are classified into the following categories: Stuck-at fault on Look-up Tables (LUTs). Functional faults on D-FFs in a CLB/IOB, except the clock and reset function. The IR faults in this paper can be categorized into two groups, namely, stuck-at and bridging faults. A stuck-at fault appears in a pass transistor of a switch matrix (SM), while a bridging fault occurs on different wire segments IOB test and diagnosis Each D-FF of N IOBs is configured as a shift register and all D-FFs are connected to form a shift register chain. N denotes the number of IOBs. Since each series FPGA has similar IOB architecture, IOB configurations as well as the algorithm of test and diagnosis are alike. For example, six, five and six configurations are required for IOB test and diagnosis in XC4000, Virtex and Virtex-2 FPGAs, respectively. The IOB fault test and diagnosis flow is outlined in Fig CLB test and diagnosis A CLB in an FPGA consists of two 4-input LUTs and two D-FFs in the case of XC4000 FPGAs, four 4-input LUTs and four D-FFs in the case of Virtex FPGAs, eight 4-input LUTs and eight D-FFs in the case of Virtex-2 and Virtex-4 FPGAs, eight 6-input LUTs and eight D-FFs in the case of Virtex-5, as well as eight 6-input LUTs and 16 D-FFs in the case of Virtex-6 and Virtex-7 FPGAs. As will be shown next, both CLB configurations and associated algorithms of test and diagnosis for these series FPGAs are similar. Thus, the configuration numbers for these series FPGAs are identical. For instance, a configuration for CLBs in the case of XC4000 FPGAs is shown in Fig. 6. As can be seen in Fig. 6, the output of LUT_G i,j in CLB i,j is linked to the input of LUT_G i,j+1 in CLB i,j+1 in the identical row. i and j denote row and column numbers a CLB located. Likewise, the output of LUT_H i,j in CLB i,j is linked to the input of LUT_H i,j+1 in CLB i,j+1 in the identical row. Therefore, each CLB row has two outputs. All D-FF1 in different CLBs are connected as a chain with the output of D-FF1 in the N-th row and N-th column CLB linked to the input of D-FF2 in the identical CLB. Then, all the successive D-FF2s are formed as a chain. This kind of configuration is titled as row-based configuration. Also shown in Fig. 6, an LUT_F, an LUT_G and two D-FFs constitute a CLB. If any one of the four components in the CLB is faulty, then the CLB is faulty. Fig. 5. Pseudo code for IOB fault test and diagnosis.

6 A. Ruan et al. / Microelectronics Reliability 53 (2013) Fig. 6. Row-based configuration for CLBs for XC4000 FPGAs. When the CLBs are tested, two configurations, Exclusive OR (XOR) and Exclusive NOR (XNOR) are required to apply [14]. If either of two D-FFs is faulty, the location of the faulty CLB can be detected by these two configurations. However, the location of the faulty CLB cannot be determined when the two LUTs are fault-free. Another two configurations will be applied. In this situation, D-FFs are not necessary to be configured. The output of LUT_G i,j in CLB i,j is linked to the input of LUT_G i+1,j in CLB i+1,j in the identical column. Likewise, the output of LUT_G i,j in CLB i,j is linked to the input of LUT_G i+1,j in CLB i+1,j in the identical column. Therefore, each CLB column has two outputs. With the row and column coordinates, the position of a faulty CLB can be decided. This kind of configuration is titled as column-based configuration. Pseudo code for CLB test and diagnosis flow is illustrated in Fig. 7. In the case of Virtex-2 FPGA test, for instance, four 4-input LUTs and four D-FFs constitute a CLB. The aforementioned algorithm for CLB test and diagnosis is still applicable. Likewise, the algorithm holds true for other Virtex series FPGA test IR test and diagnosis Since global lines have been employed as clock signal lines for CLB test, it will not be tested in IR test. Hence, local lines, PIPs and pin wires are considered for testing. Each SM consists of many PIPs used to establish connections between the lines. Basically, three distinct test configurations, namely, orthogonal (TC or ), left diagonal (TC ld ), and right diagonal (TC rd ), are needed to test SMs along with local lines [14]. Since a typical FPGA architecture consists of a large amount of repeatable and regular configurable resources, concept of repeatable building block is proposed. A repeatable building block refers to the smallest unit during reconfiguration. A repeatable building block comprises an SM, two LUTs and associated wire segments as illustrated in Fig. 8a c. TR 1 and TR 2 denote test responses from the LUTs. TVs are applied to input terminals (i 1,..., i n, j 1,..., j n ) of two LUTs via the SM, respectively. n denotes the input terminal number of an LUT, for example, 4-input LUTs for XC4000, Virtex, Virtex-2, Virtex-4 FPGAs and 6-input LUTs for Virtex-5, Virtex-6,Virtex-7 FPGAs, respectively. Corresponding responses of the SM are actually input terminals ði 0 1 ;...; i0 n ; j0 1 ;...; j0 nþ of the two LUTs. The algorithm of IR test and diagnosis is based on fault mapping method of mapping the IR faults to the outputs of the two LUTs. As shown in Fig. 8d, the process of test signal propagation can be divided into two steps. Firstly, TVs are delivered through IRs to the input terminals of the LUT as its addresses. Secondly, we can get access to the values of the LUTs in terms of the addresses. Assuming that LUTs are fault-free, the output contains the test responses of IRs. If the IRs are fault-free, then the values received by the LUTs address terminals must be equal to TVs. When there is a fault in IRs, the values must be different from TVs. In this situation, a certain relationship exists between the fault value and the fault type. A fault library which will be presented in Section can be derived. In the fault library, every fault value corresponds with a fault type. A fault-free value, depending on an initial value for an LUT, is also included in

7 494 A. Ruan et al. / Microelectronics Reliability 53 (2013) Fig. 7. Pseudo code for CLB test and diagnosis flow. Fig. 8. A repeatable building block with three basic types of test configuration and fault mapping method. the library. After the SMs are initialized, TVs are applied to i 1,..., i n, j 1,..., j n respectively. Output responses of the two LUTs in repeatable building blocks are TR 1 and TR 2. ATC ld configuration for IR test and diagnosis in an FPGA-undertest is displayed in Fig. 9. The configuration structure is based on repeatable building blocks. As shown in Fig. 9, the configuration is implemented in every other row to avoid fault masking. Consequently, two configurations, TC ld_1 and TC ld_2, are required for the TC ld structure. Altogether, six configurations are needed for IR test and diagnosis. On the other hand, the output of each LUT in each repeatable building block is controlled by an enabling signal En of a tri-state buffer. Put another way, the output of an LUT is independent on other outputs of LUTs. Thus, fault masking will not be introduced. Pseudo code for IR test and diagnosis flow is illustrated in Fig Experimental results and discussion Experimental results Xilinx FPGAs including XC4000 FPGAs, Virtex FPGAs and Virtex- 2 series FPGAs were tested by the proposed non-intrusive BIST system in the experiment and the experimental results are listed in Tables 1 3. We chose an XC4010 in XC4000 FPGAs, an XCV300 in Virtex FPGAs, and an XC2V1000 in Virtex-2 FPGAs for our test experiments. Since IR test and diagnosis is much more complicated, we will demonstrate how IR test results can be obtained for XC4000 FPGAs in terms of the algorithm introduced in Section IOB and CLB test results based on the algorithms discussed in Section for XC4000 FPGAs have been published in [18,19].

8 A. Ruan et al. / Microelectronics Reliability 53 (2013) Fig. 9. TC ld_1 configuration for IR test and diagnosis in an FPGA-under-test. Fig. 10. Pseudo code for IR test and diagnosis flow. Assume that the stuck-at and bridging faults are presented in the FPGA-under-test, we get 41 cases when single or multiple faults occur, as listed below. Stuck-at-1 fault is defined as any one or several inputs of the four-input LUT being stuck-at-1. The cases of stuck-at-1 are = 15.

9 496 A. Ruan et al. / Microelectronics Reliability 53 (2013) Table 1 Experimental results of Xilinx XC4010FPGA. Resources of FPGA CLB IOB IR Configuration numbers 2 or Configuration time 1.5 s 2 or s s 6 Test application time or Table 2 Experimental results of Xilinx XCV300 FPGA. Resources of FPGA CLB IOB IR Configuration numbers 2 or Configuration time 11.5 s 2 or s s 14 Test application time or Table 3 Experimental results of Xilinx XC2V1000 FPGA. Resources of FPGA CLB IOB IR Configuration numbers 2 or Configuration time 25 s 2 or 4 25 s 6 25s 32 Test application time or Stuck-at-0 fault is defined as any one or several inputs of the four-input LUT being stuck-at-0. The cases of stuck-at-0 are = 15. Bridging fault is defined as two or more interconnect metal lines are crossed. There are totally = 11 cases. When two identical initial values were applied to two LUTs and TVs was generated by the TPG as shown in Fig. 11, a library of IR fault types can be derived from fault mapping method discussed in Section Thus, these readable TVs facilitate TV revision in the process of FPGA test. A 0,A 1,A 2 and A 3 denote IRs connected to the inputs of an LUT. Part of the library of IR fault types is shown in Table 4. Due to the limited space, only six cases including a fault-free case are listed while the other 36 cases are ignored here. For example, if TR 1 of an LUT is , a stuck-at-1 fault at A 1 can be detected. Table 4 Library of IR fault types. Faults type TR 1 TR 2 Fault-free A 1 stuck-at A 1,A 4 stuck-at A 2 stuck-at A 2,A 3 stuck-at A 1,A 2 bridging Since every member of each Xilinx series FPGAs shares the same internal architecture with varying numbers of CLB and IOB as discussed in Section 4.2, numbers of test configuration for every member of the series FPGAs are identical. The only difference between different series FPGAs lies in varying configuration numbers with small modification of algorithms for FPGA test and diagnosis. That is why IOB and CLB configuration numbers do not vary as shown in Tables 1 3. On the other hand, IR architecture including PIPs and types of wire segments is more and more complicated in the new generation of FPGAs. Luckily, the concept of repeatable building block and fault mapping method introduced in Section are still applicable for the new generation of FPGA test and diagnosis. When an FPGA is under test, these repeatable building blocks share no other than TVs. Thus, configuration numbers of an FPGA-under-test have nothing to do with the array size of an FPGA. Instead, configuration numbers are dependent on the input terminal numbers of PIPs as well as types of wire segments. For example, the input terminal numbers for a PIP for the case of XC4000, Virtex and Virtex-2 FPGAs are 3, 5, 24, respectively. Then, the minimum configuration numbers for the three types of FPGAs are 3, 5, 24, respectively. In fact, practical configuration numbers will be larger than the numbers considering PIP types. Fig. 11. TVs for IR test and diagnosis generated by the TPG. Fig. 12. Fault coverage evaluation.

10 A. Ruan et al. / Microelectronics Reliability 53 (2013) Table 5 Performance comparisons. Relevance to FPGA array size and type Observability Controllability Configuration numbers [10] 2 N M or 4 N M (CLB) [11] 120 (CLB & IR) [16] [21] 20 (IR) This work Shown in Tables Performance evaluation and comparisons (1) Fault coverage evaluation: The fault coverage evaluation for IOBs, CLBs and IRs are illustrated in Fig. 12a c to verify performance of the proposed BIST system. Take Fig. 12c for example, if only one test configuration is applied, the fault coverage is 0%, 18% and 36% for stuck-at-0 and stuck-at-1 fault, respectively. However, 100% fault coverage can be achieved if all the six test configurations are applied. (2) Test configuration numbers and test time: The algorithms for FPGA test and diagnosis have been extensively studied in Section 4.2. When the proposed BIST system is applied to FPGA test and diagnosis, functional faults in IOBs, stuckat and bridging faults in IRs, as well as stuck-at and functional faults in CLBs can be detected. In paper [11], the embedded BIST approach was employed to test Xilinx XC4000 series FPGAs. In order to achieve 100% fault coverage, apart from two configurations of pre-testing for roving self-testing area (STAR), 120 configurations are required for CLBs and IRs test and diagnosis! It is owing to the requirement of exchanging the TPG, ORA for the CUT that dramatically augments configuration numbers. On the other hand, the embedded BIST approach presented in the paper is not applicable to other Xilinx Virtex series FPGAs test. Actually, only global lines, single-to-single local lines and associated PIPs in XC4000 FPGAs are tested by the method. In contrast, except these two types of lines and associated PIPs, there are single-to-hex and hex-to-hex lines and their associated PIPS in Virtex FPGAs. In paper [10], the proposed embedded BIST approach was utilized to test CLBs of an N M FPGA. N and M denote row and column numbers of the FPGA-under-test. The configuration numbers are 2 N M for BISTer-1case and 4 N M for BISTer-2 case, respectively. Take XC4010 FPGA for example, the configuration numbers are 800 for BISTer-1case and 1600 for BISTer-2 case, respectively. The presented method mainly focused on CLBs test, and is not applicable to IRs test. The configuration numbers are strongly dependent on FPGA array size as well as complexity of TPGs and ORAs. On the other hand, the non-intrusive technique presented in paper [16] did not study how to locate a fault site, which was dependent on some special algorithm. In contrast, only 8 or 10 configurations were otherwise required for CLB and IR test and diagnosis in XC4010 FPGA when our BIST system is adopted. As discussed in Section 4.2.3, 8 configuration numbers are obtained based on two CLB configurations plus six IR configurations on the condition that a CLB fault and its site can be determined by two row-based CLB configurations. Otherwise, another two column-based CLB configurations are applied. Therefore, 10 configurations are required. The test time is defined as the time required to carry out the test to completion, which includes the time required to set up the test configurations plus the time required to apply the TVs. The test times for three FPGAs are listed in Tables 1 3, respectively. The configuration time is relevant to size of configuration bitstream, while the test application time is subject to the length of TVs. The configuration file for XC4010, XCV300 and XC2V1000 is 240 Kbit, 1.75 Mbit and four Mbit, respectively. (3) Comparisons: Comparisons between the proposed BIST system and some previous works are listed in Table 5. None of the previous works can simultaneously provide good observability and controllability, as well as derive configuration numbers independent on type, array size of an FPGAunder-test. Our proposed system along with corresponding algorithms can offer these capabilities. 5. Conclusion This paper has proposed a BIST system with non-intrusive TPG and ORA for FPGA test and diagnosis. The proposed BIST system is generic and can be applied to Xilinx Virtex series FPGAs test, Xilinx Spartan FPGAs test as well as Altera FPGAs test with small modifications. The further investigation will be presented in the future. The proposed BIST system can provide good observability and controllability for an FPGA-under-test. No matter what type, array size of an FPGA-under-test is, the CUT can be tested automatically, and repeatedly. Experimental results also verified that configuration numbers are reduced compared with embedded BIST techniques. References [1] Campregher N, Cheung YK, Vasilko M. Analysis of yield loss due to random photolithographic defects in the interconnect structure of FPGAs. In: ACM international workshop on FPGAs 2005; p [2] Stroud C. A designer s guide to built-in self-test. Kluwer Academic Publisher; [3] Stroud C, Konala S, Chen P, Abramovici M. Built-in self-test of logic of blocks in FPGAs. In: Proceedings of VLSI test symposium; p [4] Stroud C, Wijesuriya S, Hamilton C. Built-in self-test of FPGA interconnect. In: Proceedings of test conference; p [5] Abramovici M, Stroud C, Skaggs B, Emmert J. Improving on-line BIST-based diagnosis for roving STARs. In: Proceedings of on-line testing workshop; p [6] Bradley D, Stroud C. Built-in self-test of configurable logic blocks in virtex-5 FPGAs. In: Proceedings of 41st Southeastern symposium on system theory; p [7] Girard P, Heron O, Pravossoudovitch S, Renovell M. BIST of delay faults in the logic architecture of symmetrical FPGAs. In: Proceedings of the 10th IEEE international on-line testing, symposium; p [8] Wang CC, Liou JJ, Peng YL, Huang CT, Wu CW. A BIST scheme for FPGA interconnect delay faults. In: Proceedings of the 23th IEEE VLSI test, symposium; p [9] Dutt S. Mixed PLB, and interconnect BIST for FPGAs without fault-free assumptions. In: Proceedings of the 24th IEEE VLSI test, symposium; p [10] Dutt S, Verma V, Suthar V. Built-in self-test of FPGAs with provable diagnosabilities and high diagnostic coverage with application to online testing. IEEE Trans Comput-Aided Des Integr Circ Syst 2008: [11] Hsu CL, Chen TH. Built-in self-test design for fault detection and fault diagnosis in SRAM-based FPGA. In: Proceedings of instrumentation and Measurement; p [12] Kumar TN, Chong CW. An automated approach for locating multiple faulty LUTs in an FPGA. Microelectron Reliab 2008;8(11 12): [13] Sun XJ, Xu J, Trouborst P. Testing carry logic modules of SRAM-based FPGAs. In: IEEE international workshop on memory technology, design and Testing; p [14] Renovell M, Figueras J, Zorian Y. Test of RAM-based FPGA: methodology and application to the interconnect. In: 15th IEEE VLSI test, symposium; p [15] Suthar V, Dutt S. Efficient on-line interconnect testing in FPGAs with provable detectability for multiple faults. Des Autom Test Europe 2006:1 6. [16] Gardel A, Bravo I, Lazaro JL, Perez B, Balinas J, Hernandez A. Verification of FPGA internal resources. In: Proceedings of IEEE international intelligent signal processing, symposium; p [17] Grahm PS. Logic hardware debuggers for FPGA-based systems. Ph.D. thesis. Brigham Young University; 2001.

11 498 A. Ruan et al. / Microelectronics Reliability 53 (2013) [18] Liao YB, Li P, Ruan AW, Li W, Li WC. Full coverage manufacturing testing for SRAM-based FPGA. In: Proceedings of the 12th IEEE international symposium on integrated circuits; p [19] Liao YB, Ruan AW, et al. Interconnect resources testing and faults diagnosis in field programmable gate arrays. In: Proceedings of the 10th international conference on electronic measurement & instruments; p [20] Liao YB, Li P, Ruan AW, Li W, Li WC. Test scheme for wide edge decoder in F.P.G.A. Chin J Sci Instrum 2010;31(7): [In Chinese]. [21] Sun XL, Trouborst P. A unified global and local interconnect test scheme for Xilinx XC4000 FPGAs. IEEE Trans Instrum Meas 2004;53(2):