Method and apparatus for application specific test of PLDs

3

DETAILED DESCRIPTION OF THE
INVENTION

Examples of PLDs include various Altera products, such as the StratixTM, APEXTM, CycloneTM, FLEXTM, ACEXTM, 5 and MercuryTM families of field programmable gate arrays (FPGAs), the datasheets of which are incorporated herein by reference. The various embodiments of the present invention are applicable to these and other types of PLDs.

FIG. 1 is a block diagram generally showing a PLD 100 10 according to an embodiment of the present invention. The PLD 100 includes numerous resources. Some specific resources shown are logic array blocks (LABs) 102, memories 104, phase-locked loops (PLLs) 106, and digital signal processors (DSPs) 108, all connected by interconnects 110. 15 Many other types of resources may also be provided on the PLD 100. The PLD 100 also includes input and output portions (not shown).

For customer applications, the resources necessary to implement the applications are connected together via the 20 interconnect 110. For a specific customer application, however, not all the resources (including not all the interconnect 110) may be necessary to implement that specific function.

Embodiments of the present invention are directed toward taking advantage of the fact that not all resources of the PLD 25 are used and applying this advantage in the PLD testing area. FIGS. 2-3 are block diagrams showing two general embodiments according to the present invention. FIG. 4 is a flowchart showing the general operation of a method according to an embodiment of the present invention. 30

In FIG. 2, the PLD 100 is tested by an external test unit 120. The test unit 120 may be similar to existing test units for testing PLDs. However, the test unit 120 is additionally programmed to be aware of the customer application. The test unit 120 tests only those resources of the PLD 100 that 35 are actually used in the customer application. Testing with the test unit 120 is most likely to be performed at the PLD manufacturer, not at the customer. For such testing, registers of the PLD may be used to drive and capture the data via test features like register scan. 40

In FIG. 3, the PLD 100 includes a set 130 of resources that is used for implementing the customer application. This set 130 may be referred to as the customer resources 130. The customer resources 130 are less than all of the resources of the PLD 100. This leaves a second set 132 of resources that 45 is used for testing the customer resources 130. This second set 132 may be referred to as the test resources 132. The testing performed by the test resources 132 may be referred to as built-in self testing (BIST) because the test resources 132 are located on the PLD 100. The remaining resources of 50 the PLD 100 may be referred to as unused resources 134. (Note that the test resources 132 were part of the unused resources prior to their configuration as test resources 132.)

In FIG. 4, the method 140 includes three steps 142, 144 and 146. In step 142, a set of resources that is used for the 55 customer application is identified. This set includes less than all of the resources of the PLD 100. In step 144, testing is performed on the resources associated with the customer application. In step 146, a test result is generated.

FIGS. 5-10 provide more details on the specific types of 60 testing performed. In general, a toolset may be used to develop application specific tests for the different component types of the PLD. FIGS. 5-6 detail interconnect testing. FIGS. 7-8 detail logic element testing. FIGS. 9-10 detail function block testing. 65

FIG. 5 is a block diagram showing interconnect testing according to an embodiment of the present invention.

4

According to one embodiment, the interconnect includes a number of 4-input lookup tables (LUTs) (not shown) for routing. The interconnect testing may be performed via a register scan (see above regarding FIG. 2) or via BIST (see above regarding FIG. 3). A standard testing function F may be used.

FIG. 6 is a flowchart detailing the steps 160 performed in interconnect testing according to an embodiment of the present invention. In step 162, the toolset identifies the interconnect being used by parsing the pattern of the customer application. In step 164, the identified interconnect is put into a routing graph format. In step 166, any combinatorial feedback paths are broken. In step 168, the toolset places all of the logic elements joined by the identified interconnect into combinatorial mode. In step 170, the standard function F is put into all of the LUTs to provide full observability of all four inputs like an exclusive-OR (XOR).

For factory testing of the interconnect, registers may be used to drive and capture the data via test features like a register scan (see above regarding FIG. 2). For in-system BIST of the interconnect, unused logic elements may be configured as BIST machines both to control the start points of the routed interconnect graph and to observe the end points. For both types of testing, all of the identified interconnect should be observed to toggle properly in order for the test pattern to pass.

FIG. 7 is a block diagram showing logic element testing according to an embodiment of the present invention. According to one embodiment, the logic elements include a number of 4-input lookup tables (LUTs) (not shown), which are function generators that can implement any function of four variables. The logic element testing may be performed via a register scan (see above regarding FIG. 2) or via BIST (see above regarding FIG. 3). A standard testing function F may be used. The customer's function (corresponding to the customer application) may also be used.

FIG. 8 is a flowchart detailing the steps 180 performed in logic element testing according to an embodiment of the present invention. In step 182, the toolset identifies the logic elements being used in the customer application. In step 184, the identified logic elements are put into registered mode. The identified logic elements otherwise retain the same configurations they would have in the customer application. In step 186, identical LUT inputs and secondary signals are routed to the active logic elements, either from pins (or register scan) or from a BIST machine. In step 188, all 16 possible LUT input combinations are applied and the results captured, either in the register or by the BIST. In step 190, the toolset calculates the expected output for each logic element based on the customer application's LUT settings. (Step 190 may be performed at any time prior to step 192, not necessarily after step 188.) In step 192, the results of step 188 are compared with the expected outputs of step 190 and a test result is generated.

For factory testing (see above regarding FIG. 2), the test may observe the registers through the register scan test feature. For in-system BIST (see above regarding FIG. 3), a scan chain may be explicitly routed in user mode, which may lead to a signature comparator implemented in unused logic elements. Other secondary signals, such as clear signals, may be tested in a similar manner.

FIG. 9 is a block diagram showing function block testing according to an embodiment of the present invention. The term function block is used to refer generically to specialpurpose blocks other than interconnect and logic elements. Examples of function blocks include memories, DSPs, PLLs, DLLs, etc. Such function blocks have varying num