Run-time reconfigurable testing of programmable logic devices

[0003] The present invention generally relates to testing circuitry of programmable logic devices (PLDs), and more particularly to testing PLDs in a run-time reconfigurable computing arrangement.

[0004] The methods and tools used to test programmable logic devices (PLDs) are currently very similar to those used in testing other types of integrated circuit devices. For example, standard commercially available test machines are used to test the PLDs. The PLDs are configured and then tested using test vectors. The test vectors are written to the device via device input pins and test results are extracted via device output pins. The output data are then compared to expected result data to verify correct operation of the configured PLD.

[0005] Some PLDs, for example field programmable gate array (FPGA) devices, have a wide variety of configurable resources, which makes testing time consuming. Given the variety of configurable resources, no single configuration is sufficient to exercise all the capabilities of the device. Thus, many reconfigurations of the PLD are performed, and new test vectors are used with each new configuration. Not only are current test methods time-consuming, but the limited bandwidth of the device constrains the ability to move test vectors into and retrieve results data from the device. Furthermore, once a fault or defect is detected, it may take many additional iterations to isolate the fault to a particular resource.

[0006] Built-in self test (BIST) approaches include storing the test vectors and results analysis logic in the PLD, which addresses PLD bandwidth issues. However, the BIST approach consumes PLD memory for storage of test vectors and results data at the expense of other potential uses. In addition, the location of the BIST circuitry must itself be defect-free, and special software is required to interface with the BIST circuitry.

[0007] The traditional and BIST approaches to testing PLDs each have different advantages but also have certain disadvantages. The traditional approach uses standard tools and methodologies and requires no changes to the PLD hardware, which reduces the learning required to construct a test for a device. The disadvantage is that the traditional approach is better suited to a production environment than an application environment. The BIST approach provides the flexibility of testing a PLD in an application environment. However, special test circuitry must be designed into the PLD, which may consume more than an inconsequential portion of device resources.

[0008] A system and method that address the aforementioned problems, as well as other related problems, are therefore desirable.

[0009] In various embodiments, the present invention tests the circuitry of a programmable logic device (PLD). A host data processing arrangement is configured with a run-time reconfiguration programming interface, and a run-time reconfiguration test program that invokes methods of the interface executes on the host arrangement. In response to a method of the programming interface invoked from the test program, the PLD is configured with a first configuration bitstream. State data are then read back from the PLD in response to a method of the programming interface invoked from the test program. The test program also identifies differences between the state data and expected-results data.

[0010] Various other embodiments are set forth in the Detailed Description and Claims which follow.

[0011] FIG. 1 is a block diagram of an example system for run-time reconfiguration of a PLD.

[0012] FIG. 2 is a flowchart of an example process for testing a PLD using a run-time reconfiguration test program.

[0013] FIG. 3 is a functional block diagram of a circuit that tests a single wire of an field programmable gate array (FPGA).

[0014] FIG. 4 is a block diagram of an FPGA-implemented circuit for testing timing characteristics of lookup tables in an FPGA.

[0015] The various embodiments of the invention described below provide an environment for testing a programmable logic device (PLD) using a run-time reconfiguration test program. The test program generates a configuration bitstream, which is then used to configure the PLD. Under control of the test program, the PLD is activated and clocked in accordance with test-specific requirements. Result data are then read back from the PLD and compared to expected results under control of the test program. The testing environment allows further testing of the PLD by way of generating additional configuration bitstreams for testing other configurable resources of the PLD.

[0016] FIG. 1 is a block diagram of a system 200 for configuring a PLD 202 in a run-time reconfigurable (RTR) system. System 200 includes a run-time reconfiguration test program 204 that is written in the Java® language, for example. The test program 204 is written to control overall testing of PLD 202. Depending on the test requirements, the functions of test program 204 range from generating a configuration bitstream for testing various configurable resources of PLD 202 to determining whether the test produced the expected results.

[0017] Run-time reconfiguration application program interface (API) 208 allows test program 204 to manipulate configurable resources of PLD 202 via a set of functions that can be called from the test program. Test program 204 uses API 208 to establish configuration data 210 to be downloaded to PLD 202 and to download the configuration data to the PLD at a program-selected time. In one embodiment, the configuration data are an in-memory copy of the configuration data present in the PLD. In-memory refers to memory that is accessible to the test program, either directly or via a network connection. An example run-time reconfiguration API is provided in the JBits Software Development Kit from Xilinx.

[0018] API 208 also provides a core library that includes a collection of macrocell or “core” generators which are implemented as Java classes. The cores are generally parameterizable and relocatable within a device. Examples of cores include registers, counters, adders, multipliers, constant adders, constant multipliers, flip-flops and other standard logic and computation functions. The core generators can be used in constructing various tests for the device.

[0019] Configuration data 210 comprise a cached version of the current configuration state of PLD 202 together with any changes to the configuration made by test program 204. API 208 tracks which portions of PLD 202 need to be reconfigured relative to the state of configuration data 210, as described in the application/patent entitled, “Automatic Tracking and Assembly of Changed portions of Configuration Data for Partial Run-time Reconfiguration of a Programmable Logic Device,” by Guccione et al., filed on Apr. 24, 2001, having application/patent number 09/841,270, and incorporated herein by reference. By tracking the changed portions of the configuration data, PLD 202 can be partially reconfigured, thereby greatly reducing the overhead of configuring the entire device.

[0020] Hardware interface 214 includes a portable layer of software and accompanying hardware to couple test program to programmable logic device 202. For example, hardware interface 214 may be the Xilinx Hardware Interface (XHWIF) which is available from Xilinx, Inc.

[0021] Computing arrangement 216 is coupled to programmable logic device 202 via hardware interface 214. The functional requirements of system 200 dictate the particular style and capabilities of processor 216. For example, some applications may call for a RISC based processor while others may call for a CISC. Various ones of special purpose or general purpose processors from manufacturers such as Intel, Sun Microsystems, Motorola, IBM, AMD and others may be suitable.

[0022] FIG. 2 is a flowchart of an example process for testing a PLD using a run-time reconfiguration test program. Unlike current test techniques that rely on static configuration bitstreams and external stimulation to perform testing, the present invention supports dynamic modifications of PLD configurations for configuring, driving, and probing selected sections of the device under test. This reduces the bandwidth requirements for testing, both in the amount of configuration data necessary for the desired coverage and in the number of test input signals and vectors used to stimulate the device. Modification of the configuration bitstream by a run-time reconfiguration test program allows selected PLD resources to be reconfigured and faults to be quickly isolated.

[0023] The process begins with the generation of configuration data (step 302). In one embodiment the run-time reconfiguration test program 204 generates the configuration data via calls to the run-time reconfiguration API 208. In an alternative embodiment, the test program uses a pre-generated configuration bitstream. The configuration data programs selected resources of the PLD 202. For example, different configuration data are used for testing configuration memory cells of the PLD, programmable logic, wires PLD, and device timing.

[0024] The test program configures the PLD with the configuration data via the run-time reconfiguration API (step 304). Depending on test requirements, the configuration of the PLD may be full or partial, both of which are supported by the run-time reconfiguration API.

[0025] Test requirements dictate whether the PLD is activated (step 306) and the device clock is stepped, and whether test signals are input to the device. For example, testing configuration memory cells would not require stepping the device clock after all the cells are configured.

[0026] When the test is complete, the PLD is deactivated by stopping the device clock (step 308), and the test results are read back via the run-time reconfiguration API (step 310). Whether the test passed or failed is determined by comparing the test results to expected results data (step

[0027] A logical first test to perform on a PLD, such as an FPGA, is a test of the configuration memory. If any of the configuration memory cells are defective, testing other parts of the device will be difficult or impossible. Additionally, if a memory cell is defective, an impermissible configuration could result and damage the device or other components connected to the device.

[0028] Using the run-time reconfiguration API 208, a test program 204 that tests configuration memory can be easily constructed and executed. For example, the code fragment below obtains previously established configuration data, downloads the configuration data to the PLD, reads back data (“read-back data”) from the PLD, and performs a bit-wise comparison between the configuration data and the read-back data.

[0029] /* download previously defined bitstream to configuration memory */ device=Devices.XCV800;

[0030] board.setConfiguration(device, bs1);

[0031] /* read back configuration memory */

[0032] bs2=board.getConfiguration(device, bytes);

[0033] /* compare the data */

[0034] for (i=0; i<bs1.length; i++)

[0035] if (bs1[1]!=bs2[i])

[0036] System.out.print1n(“Bitstream diff in byte ” +i);

[0037] It will be appreciated that in a few lines of code a complete test of the configuration memory is performed. In another embodiment, the program includes code that generates the configuration data. For completeness the test should be repeated with several different configuration bitstreams to exercise the memory. For example, each configuration memory cell should be tested in storing logical zero and logical one values.

[0038] The code above also shows that the device type (XCV800) is hard-coded in the test program. In an alternative implementation, the device type is passed as a parameter to the test program, which allows the same test program to be used for different types of devices.

[0039] Once the configuration memory has been verified, other resources of the device can be tested, for example, the lookup tables of an FPGA. The code fragment below configures the F-lookup tables in slice 0 of a Virtex FPGA from Xilinx with logic zeros.

[0040] /* set LUT values to zeros */

[0041] jBits=new Jbits(Device.XCV800);

[0042] clbRows=jBits.getClbRows( );

[0043] clbCols=jBits.getClbColumns( );

[0044] for (row=0; row<clbRows; row++)

[0045] for (col=0; col<clbCols; col++)

[0046] jBits.set(row, col, LUT.SLICE0_F, 0);

[0047] /* download the configuration data */

[0048] bs1=jBits.getAllPackets( );

[0049] board.etConfiguration(device, bs1);

[0050] /* read back the configuration data */

[0051] bs2=board.getConfiguration(device, bytes);

[0052] jBits.setClbConfig(bs2);

[0053] /* compare original and read-back data */

[0054] for (row=0; row<clbRows; row++)

[0055] for (col=0; col<clbcols; col++)

[0056] if ((jBits.get(row, col, LUT.SLICEO₁₃F) !=0);

[0057] writeDefect(row, col, LUT.SLICE_F);

[0058] It will be appreciated that to also test the slice-1 lookup tables, the example code can be supplemented with additional jBits.set( ) and jBits.get:( ) statements that reference the slice-1 lookup tables. In a further enhancement to the test, the code fragment is repeated to test stuck-at-zero defects by setting the lookup tables to logic ones instead of zeros. Faults can be quickly identified by comparison of read-back data from specific resources to the original data.

[0059] Another set of PLD resource to be tested is the set of wires in a device. Because modern PLDs, such as FPGAs, have a large number of interconnection resources, testing the resources is both a complex and large task. Generating a test that covers PLD wires is difficult using traditional design tools because of the limited control provided for explicitly controlling the routing. Thus, the generated configuration data are either stochastic or the wires are isolated using low-level design entry tools, which is time-consuming and error prone.

[0060] Even though low-level manipulation of PLD routing resources is required by use of the run-time reconfiguration API 208, the programming interface is simple. In addition, the high-level functions are also available for other manipulations of the configuration data. It will be appreciated that if the memory cells and lookup tables are previously tested, other resources of the device, such as wires, can be tested.

[0061] FIG. 3 is a functional block diagram of a circuit that tests a single wire of an FPGA. Two 4-input lookup tables (“4-LUTs”) are configured as sixteen-bit shift registers (SRL16). SRL16402 supplies the input test data that drive the wire 404 under test. The input data pass through switch block 406, which drives the wire under test. Switch block 406 connects input wire 408 to wire 404. The data then pass through switch block 410, which connects wire 404 to output wire 412 and feeds the data into the input port of SRL16414.

[0062] Typically, a single logic zero and a single logic one can be sent on the wire under test and shifted into SRL16414. After the data have been transmitted on the wire and shifted into the shift register, the data are read from the output port of the shift register and compared to expected data. It will be appreciated that the number of bits shifted through SRL16414 depends on test-specific requirements.

[0063] Switch blocks 406 and 410 are configurable to connect any one of 12 input wires to any one of 4 output wires. Note that switch blocks 406 and 410 are considered part of the wire under test in the example implementation. A different wire can be tested by changing the switch configuration in the configuration bitstream and reconfiguring the device under test. It will be appreciated that additional tests would be required to isolate a defect detected in the connection between SRL16402 and SRL16414.

[0064] In addition to tests that identify logic defects in a PLD, other characteristics, for example, device timing, can be tested using the run-time reconfiguration API 208.

[0065] FIG. 4 is a block diagram of an FPGA-implemented circuit for testing timing characteristics of lookup tables in an FPGA. A pattern of logic zeros and ones is sent through a chain of lookup table-implemented buffers and captured in a shift register. If the transmitted pattern matches the captured pattern under a tests at a selected clock speed, then the lookup tables are operable at the selected clock speed. It will be appreciated that the concepts presented for testing lookup tables can be adapted to testing other FPGA resources, such as flip-flops, wires, and input/output resources. In an example application, this test allows a designer to easily identify a maximum clock rate at which the PLD may be operated. Since specific devices may have slightly different delays due to manufacturing variability, the clock rate recommended by a conventional timing analysis tool may be less than that of which a specific chip is capable. Thus, the test may be used for device-specific characterization and grading.

[0066] A first 4-LUT 452 is configured as an SRL16. SRL16452 shifts a pattern of logic zeros and ones and presents the output data to buffer 454, which is implemented with a 4-LUT. Buffer 454 is the first buffer in a chain (output-to-input port connections), and buffer 456 is the last buffer in the chain. It will be appreciated that the number of buffers in the chain depends on the type of device and test requirements. A second 4-LUT 458 is configured as an SRL16 for receiving the transmitted pattern. From SRL16458, the data are stored for comparison to the pattern input to SRL16452. Depending on the test requirements, the captured pattern may be stored either on or off the FPGA.

[0067] Variable clock 460 is configured on the FPGA to generate a clock signal to the SRL16s and chain of buffers for transmission of the pattern at a program-selected clock rate. To test the timing characteristics of the FPGA, a first pattern is sent across the chain a selected number of times at a first frequency and the captured data are compared to the transmitted pattern to determine whether the lookup tables are operable at the selected frequency. If the FPGA passes the test, the test is rerun at a higher frequency, and the testing continues until the captured pattern does not match the transmitted pattern. In another embodiment, an external clock generator is used to control the clock frequency. For example, the test program 204 calls hardware interface 214 which controls the clock frequency.

[0068] Various embodiments of the present invention are described with reference to FPGAs and tools, such as JBits, for developing run-time reconfiguration applications. Those skilled in the art will appreciate, however, that the invention could be implemented with other run-time reconfiguration tools and applied to programmable logic devices (PLDs) other than FPGAs. Other aspects and embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and illustrated embodiments be considered as examples only, with a true scope and spirit of the invention being indicated by the following claims.