November 6, 1997

Self-test for FPGAs and
CPLDs requires no overhead

Miron Abramovici, Bell Labs/Lucent Technologies, and Eric Lee, Charles Stroud, and Mark Underwood, University of Kentucky

By exploiting the reprogrammability of FPGAs and CPLDs, you can create BIST logic that exists only during testing. As a result, the test has no area overhead or performance penalties to the normal system function.

The intricacy of FPGAs and CPLDs means that you need to test them both at the system-manufacturing level and in the field. Traditionally, these tests require application-specific test patterns for in-circuit board testing and offline system-diagnostic-software routines for field testing. Developing these test patterns and diagnostic routines can be time-consuming and costly, particularly when the system is difficult to test.

Manufacturers often have comprehensive device-level FPGA and CPLD tests to check all possible modes of operation of the programmable logic, as well as to detect faults affecting the programmable-interconnect network. However, you cannot reuse these device-level manufacturing tests for board- and system-level testing.

An FPGA and CPLD testing method for both device-level and in-system testing is available. This method results in your applying more tests than necessary to the devices in the system to test their in-system functions, but the system functions may change anyway for devices that are dynamically reconfigured. More important, by providing a universal, function-independent test for all instances of the same type of device, you significantly reduce the time to market by saving test-development time for all projects that use that type of device.

A built-in self-test (BIST) is especially advantageous for field-testing digital ASICs, because it provides high fault-coverage tests at the system operating frequency and reduces system diagnostic runtime and diagnostic-software development time and cost. However, designers have been reluctant to use conventional BIST approaches, because they introduce delay penalties and typical logic overhead of 10 to 30%. Adding BIST logic in FPGAs and CPLDs results in performance degradation and a reduction in the logic resources that would otherwise be available for the system function.

By using the in-system reprogrammability of these devices, though, you can create BIST logic by configuring it only during offline testing. In this way, you achieve testability without area or performance penalties to the system, because the BIST logic "disappears" when the circuit is reconfigured for its normal system operation. The only cost is the additional memory for storing the data necessary to reconfigure the FPGA/CPLD. However, using the memory involves no resources of the device or system under test, because this memory is usually part of the test machine used for board-manufacturing testing or part of the system-maintenance processor environment that controls the BIST for field testing. The test controller supplies the configurations that the device needs to create the BIST logic, initiates the tests, and reads the test results (pass/fail indication and diagnostic data).

By eliminating the need to add BIST circuitry or any design-for-test logic to the system logic, you also reduce the design interval and increase the system functionality that you can implement in each FPGA/CPLD. Because you individually test every FPGA/CPLD, this approach locates in-system defective devices; you cannot always achieve such diagnostic resolution with traditional system diagnostics. In addition, you can apply the BIST approach at all levels of testing, including manufacturing and field testing; therefore, you can reuse the test configurations you used for device testing for in-system testing. Another advantage is that you can execute BIST testing at the system operating frequency for "at-speed" testing, which allows you to detect delay faults.

Most FPGAs and CPLDs comprise an array of programmable-logic blocks (PLBs) interconnected by programmable routing resources, as well as programmable I/O cells. In CPLDs, the smallest programmable units are the macrocells, which are grouped into larger logic blocks of eight to 16 macrocells each. Therefore, you can consider the PLB for a CPLD to be a macrocell or a logic block. In this article, consider the PLB to be a logic block. The set of all programming bits establishes a configuration that determines the function of the device.

A typical PLB comprises a combinational-logic block, a flip-flop block, and an output-multiplexer block that facilitates the bypass of the flip-flop circuitry (Figure 1). The combinational-logic blocks can be configured as RAMs (in many FPGAs) or look-up tables. The look-up table is typically RAM-based in most FPGAs and PLA-based in most CPLDs. The flip-flops in the flip-flop block may also be configured as latches; other programming options deal with synchronous or asynchronous set and reset, clock enable, active levels, and similar functions.

For example, this typical PLB structure is featured in the ORCA (Lucent Technologies, Allentown, PA) programmable function unit, the XC4000 (Xilinx, San Jose, CA) configurable-logic block, the Altera (San Jose, CA) Flex8000 logic element, the Vantis (formerly, AMD) (Sunnyvale, CA) Mach series logic block, and the Cypress (San Jose, CA) Flash370 series logic block (References 1 through 5, respectively).

Start with overview of BIST

The basic idea of the BIST approach is to program some of the PLBs in the FPGA/CPLD as test-pattern generators (TPGs) and some of the PLBs as output-response analyzers (ORAs). Most of the remaining PLBs are configured as blocks under test (BUTs) to be tested in their various modes of operation. Each mode of operation requires a different configuration. The complete testing of the BUTs in all their modes of operation occurs during a test session, which is a sequence of test phases. Each test phase configures the circuit, initiates the test, generates test patterns, analyzes the responses to produce a pass/fail indication, and reads the test results.

The test controller configures the FPGA/CPLD, initiates the BIST sequence, and reads the subsequent results using the boundary-scan test-access port (Reference 6), now available on nearly all FPGAs and CPLDs, or using other system-specific means. The BIST logic concurrently generates test-patterns and analyzes responses within the device. The controller does not test the I/O pins of the FPGA or CPLD during the BIST sequence, but it can test the pins together with the board connectivity using boundary-scan tests.

Once the controller completely tests the BUTs, it changes the roles of the PLBs, such that BUTs become TPGs or ORAs, and vice versa in the next test session. Clearly, you need at least two test sessions to test all the PLBs. After the board- or system-level BIST is complete, the test controller must reconfigure the FPGA/CPLD for its normal system function; therefore, the controller must store the normal device configuration along with the BIST configurations.

The FPGA/CPLD reconfiguration time dominates the test application time. Because testing time is a major component of the testing cost, a primary goal of the testing strategy is to minimize the number of BIST configurations that the controller must download in each test session.

The basic structure of the BIST architecture has four rows of PLBs in an FPGA (Figure 2). The controller uses one row of PLBs for TPG functions, which supply test patterns to alternate rows of BUTs. The strategy relies on pseudoexhaustive testing, in which the controller tests every subcircuit of the BUT with exhaustive patterns (Reference 7). For a combinational block with n inputs, an exhaustive test comprises all possible 2ⁿ patterns.

Pseudoexhaustive testing is a suitable for the structure of a PLB, such as the one in Figure 1, because its subcircuits are relatively small and easily controllable and the system can observe them from the PLB pins. These factors result in maximal fault coverage without explicit fault-model assumptions and without fault simulation. During a test phase, all BUTs are configured to perform the same function and receive the same input patterns from the TPGs.

In every phase, a BUT is configured in a different mode of operation; therefore, its pseudoexhaustive test may also change from phase to phase. For example, the test sequence for combinational logic followed by flip-flops differs from the test sequence for a PLB in a RAM mode of operation. The latter targets the sequence of test patterns you apply to the PLB for detection of failure modes specific to RAMs (Reference 8). Thus, the TPG block may have different structures, depending on the sequence that it must generate in a test phase.

An intermediate row of PLBs configured as ORAs compares the output responses from alternate rows of the BUTs. In general, the simplest method for output-response analysis, that of comparison with the expected response, is difficult to use in most BIST applications because of the expense involved in storing the reference response or in generating it from a copy of the circuit under test.

In this BIST approach, however, the circuits under test are identical PLBs receiving the same inputs, so the PLBs' output responses should be identical if they are fault-free. As a result, creating the ORA function requires only comparing the corresponding outputs of two or more BUTs. Unlike the signature-based compression circuits in most BIST applications, comparator-based ORAs do not suffer from the aliasing problem that occurs when some faulty circuits produce the good circuit signature. As long as the BUTs being compared by the same ORA do not fail in the same way at the same time, no aliasing will occur.

To combine results of several ORAs, use an iterative comparator (Reference 9), shown within dotted lines in Figure 3. In this case, each ORA compares corresponding outputs from two BUTs, in rows adjacent to the ORA, to produce a local mismatch signal (LMM). This LMM is ORed with the previous mismatch signal (PMM) from the previous ORA to generate the ORA mismatch (MM). The flip-flop must record the first mismatch it encounters during the BIST phase. The feedback from the flip-flop output to the first ORA disables further comparisons after the flip-flop records the first error.

The floorplan for the two test sessions for an FPGA with an eight-by-eight array of PLBs (Figure 4) closely follows the connections in Figure 2. You obtain the positions for the TPGs, BUTs, and ORAs during the second test session by flipping the floorplan of the first session (Figure 4a) around the horizontal axis, a dotted line in the middle of the array, to obtain the second BIST-session floorplan (Figure 4b).

You can easily scale this structure because the usage of the global-routing resources necessary for distributing the TPG patterns does not change with the FPGA size. In other words, adding rows and columns to an array of PLBs extends the size of only the vertical and horizontal global lines that the TPG outputs feed. You can choose to not use the row labeled "used as needed," or you can employ it for fan-out drivers or additional TPGs to reduce loading on the TPG outputs or for additional ORAs to improve diagnostics. This row is configured as BUTs in the second test session.

The same basic architecture works well with most CPLDs, in which logic blocks consisting of functional groups of macrocells replace the rows of PLBs in the FPGA-BIST architecture. In this case, one or more logic blocks serve as a TPG supplying pseudoexhaustive test patterns to multiple logic blocks configured as BUTs. One or more logic blocks configured as ORAs compare the output responses of the BUTs (Figure 5). The Vantis Mach series and the Cypress Flash370 series CPLDs use this structure.

In this example, the logic blocks have 32 inputs to the PLA-based combinational-logic portion of 16 macrocells, such that two 16-output logic blocks compose a TPG. This TPG supplies test patterns to the 32 inputs of the logic blocks that are configured as BUTs. Because applying all 2³² exhaustive-input test patterns to the PLA-based combinational logic is impractical in test time, use a sequence of test patterns similar to those for traditional PLAs but modified to account for the reprogrammability of the PLA in the CPLD. For the ORA function, use one logic block configured to compare the 16 outputs from two BUTs. Figure 5 shows a CPLD with eight logic blocks configured with two logic blocks used for the TPG, four logic blocks configured as BUTs, and two logic blocks configured as ORAs during the first test session.

The second test session reverses the assignment of TPG/ORA and BUT logic blocks. You obtain this reassignment of the logic blocks for the second test session by flipping the assignments about the dashed horizontal line across the center of the CPLD to completely test the CPLD.

For most devices, two test sessions are sufficient to have every PLB under test once, although some small devices may require three sessions. Because you concurrently test all BUTs, the test application time for one configuration does not increase with the number of PLBs (that is, the size) of the device. The test time for a session depends mostly on the number of configurations necessary to completely test one PLB. Hence, the goal is to develop a minimum number of test phases per test session, which is a function of the various modes of operation of a PLB.

An important property of the general PLB architecture is that the modes of operation of its component subcircuits are orthogonal; that is, they are independent of each other (Figure 1). For example, any configuration of the look-up-table block may work with any setup of the flip-flop block. This orthogonality translates into simplified testing, because you don't have to test all combinations of modes. Thus, if m is the maximum number of configurations for testing any of the subcircuits in a BUT, testing the entire BUT requires at least m configurations.

In the ORCA 2C series PLB, the subcircuit requiring the most configurations is the output-multiplexer block that includes several 9-to-1 multiplexers that select any one of the four look-up-table outputs, four flip-flop outputs, or the carry-out from the look-up table (Reference 8). Therefore, you need nine phases to completely test this block. The modes of operation for the other blocks are also tested during these nine phases (Table 1).

The distinct modes of operation for the ORCA look-up table are RAM, fast adder, look-up-table-based logic functions of five variables, and look-up-table based logic functions of four variables. The device programmer tests these modes during the first four phases of the PLB BIST. The operation of the flip-flop module has several options: choice of flip-flop or latch; choice of active clock edge (or level for latches); optional clock enable with choice of active level; choice of preset or clear; synchronous or asynchronous preset/clear activation with choice of active level; and selection of data from the look-up-table output or directly from the PLB inputs. The last five phases in Table 1 test these operational modes for the flip-flops.

Although pseudoexhaustive testing requires no fault simulation, using a fault simulator confirms the fault coverage obtained in the phases of a BIST session. A complete gate-level model for the ORCA PLB includes the PLB-configuration bits, which are represented as primary inputs whose values are "frozen" during each test phase. This approach also lets you to simulate stuck-at faults affecting the configuration memory bits.

The PLB contains 1942 collapsed, stuck-at, gate-level faults: 1403 faults in the look-up tables, 293 faults in the flip-flops, and 246 faults in the output multiplexer. Table 2 summarizes the fault-simulation results for the nine test phases including the number of faults detected and fault coverage for each phase in each of the three modules, along with the cumulative number of total faults detected and cumulative resultant fault coverage. The first four phases provide a good test of the look-up tables, and the following five phases detect all the faults in the flip-flop/latch circuitry. All nine phases are necessary to detect all the faults in the output multiplexer. Although these tests target only the PLBs, they also detect many faults in the programmable-interconnect structure.

You can reduce the test time by eliminating phases that test functional modes not used in the system application of the FPGA/CPLD. For example, by combining Phase 1, which gives the highest fault coverage in the look-up table, with Phase 9, which gives the highest fault coverage in the flip-flop/latch circuitry, you can obtain one BIST phase that provides approximately 83% fault coverage (Reference 9). This BIST phase is useful in reducing test time and provides a good "sanity check" of the FPGA during field testing or at the system-manufacturing facility.

This BIST approach for testing all the blocks in an FPGA/CPLD invalidates the traditional complaints against BIST: that it consumes area as overhead and degrades performance. Because the test is exhaustive by construction, it requires no fault simulation for validation. This BIST approach represents a hybrid of two previous BIST approaches for FPGAs (References 10 and 11). As a result, this BIST approach is easily scalable with increases in device size, requires only two test sessions, and is applicable to both manufacturing and field testing. FPGA and CPLD users need not worry about testability of the system function and can just consider it a generic test for a generic part. e

References

1. Field Programmable Gate Arrays Data Book, Lucent Technologies, Murray Hill, NJ, October 1996.

2. The Programmable Logic Data Book, Xilinx Inc, San Jose, CA, 1993.

3. Flex 8000 Programmable Logic Device Family Data Sheet, Altera Corp, San Jose, CA, May 1993.

4. Mach Family Data Book, Advanced Micro Devices, Sunnyvale, CA, October 1995.

5. Cypress Data Book, Cypress Semiconductor, San Jose, CA, Winter 1997.

6. "Standard test access port and boundary-scan architecture," IEEE Standard P1149.1-1990, May 1990.

7. McCluskey, E, "Verification testing--a pseudoexhaustive test technique," IEEE Transactions on Computers, Vol C-33, No. 6, pg 541 to 546, June 1984.

8. Sridhar, T, and JP Hayes, "Design of easily testable bit-sliced systems," IEEE Transactions on Computers, Vol C-30, No. 11, pg 842 to 854, November 1981.

9. Stroud, C, E Lee, S Konala, and M Abramovici, "Selecting built-in self-test configurations for field programmable gate arrays," Proceedings of the IEEE Automatic Test Conference (AutoTestCon'96), pg 29 to 35, 1996.

10. Stroud, C, S Konala, P Chen, and M Abramovici, "Built-in self-test for programmable logic blocks in FPGAs (Finally, a free lunch: BIST without overhead!)," Proceedings of the IEEE VLSI Test Symposium, pg 387 to 392, 1996.

11. Stroud, C, E Lee, S Konala, and M Abramovici, "Using ILA testing for BIST in FPGAs," Proceedings of the IEEE International Test Conference, pg 68 to 75, 1996.

The basis of this material is work supported by the National Science Foundation under Grant No. MIP-9409682. The work was also supported by grants from Lucent Technologies and the University of Kentucky Center for Robotic and Manufacturing Systems.

| EDN Access | Feedback | Table of Contents |