《p108roostap.docNASA Office of Logic Design.doc》由会员分享，可在线阅读，更多相关《p108roostap.docNASA Office of Logic Design.doc（7页珍藏版）》请在三一办公上搜索。
1、A Re-Programmable Platform for Dynamic Burn-in Test of Xilinx VirtexII 3000 FPGA for Military and Aerospace ApplicationsRamin Roosta, Jet Propulsion Laboratory, California Institute of Technology, PasadenaXinchen Wang, Ixia Communications, Calabasas, CaliforniaMichael Sadigursky and Phil Tracton, Ca
2、lifornia State University, NorthridgeAbstract Field Programmable Gate Arrays (FPGA) have played increasingly important roles in military and aerospace applications. Xilinx SRAM-based FPGAs have been extensively used in commercial applications. They have been used less frequently in space flight appl
3、ications due to their susceptibility to single event upsets (SEUs). Reliability of these devices in space applications is a concern that has not been addressed. The objective of this project is to design a fully programmable hardware/software platform that allows (but is not limited to) comprehensiv
4、e static/dynamic burn-in test of Virtex-II 3000 FPGAs, at speed test and SEU test. Conventional methods test very few discrete AC parameters (primarily switching) of a given integrated circuit. This approach will test any possible configuration of the FPGA and any associated performance parameters.
5、It allows complete or partial re-programming of the FPGA and verification of the program by using read back followed by dynamic test. Designers have full control over which functional elements of the FPGA to stress. They can completely simulate all possible types of configurations/functions. Another
6、 benefit of this platform is that it allows collecting information on elevation of the junction temperature as a function of gate utilization, operating frequency and functionality. A software tool has been implemented to demonstrate the various features of the system. The software consists of three
7、 major parts: the parallel interface driver, main system procedure and a graphical user interface.1.0 Proposed Testing Setup and Its AdvantagesA number of people have attempted to test FPGAs using a modified Xilinx development board. This allows them to put their design and testing methods into prac
8、tical use and acquire reasonable results. This approach actually does similar steps but does not stop there. The goal of this project is to develop a flexible test platform for the Xilinx VirtexII that can overcome most of the common shortcomings: lack of useable IOs, configuration varieties, clock
9、schemes, and connections. Another goal of a desired testing hardware is the ability to adapt to major industrial test setups such as burn-in logic test, burn-in IO test, component screening tests, at speed test, as well as to configure for single-event testing for aerospace and military applications
10、 with few or no modifications. The design of this project consists of the FPGA test programs and the testing setups, including two printed circuit boards (PCBs); the driver board and a burn-in proof UUT board, with high-quality impedance controlled connectors and cables. The two boards are called th
11、e driver board and test board, respectively, each containing a VirtexII 3000 chip (commercial version on driver board and a military/radiation hardened grade on UUT board). The driver board will connect to the host PC via the EPP parallel interface and will be self-configured using Xilinx EEPROMS. T
12、he EEPROMS will be configured through industry standard JTAG interface. Once the driver board is configured successfully, it will provide configuration streams to the UUT board via the relatively high- speed Xilinx Select Map interface, which is capable of FPGA downloading and read-back operations.
13、Also, between the driver board and the UUT board are roughly 20 general IOs flowing in each direction. Thus 40 pins are connecting the two boards through high-quality and individually shielded impedance- controlled connectors and cables. This setup will enable the test algorithm to verify the FPGA u
14、nder test with relatively high-frequency ranges. Signal integrity has been a major concern since few people have attempted this before on burn-in test setups. A BGA-728 pin socket is placed on the test board to provide mounting for the FPGA under test. On the UUT board, there are loop-back connector
15、s that route to almost all the IOs available to the test FPGA for various IO testing. The clocking arrangement between the two boards allows multiple clock domain operations. Users can select any one of four independent oscillators or any combination of oscillators. The VirtexII digital clock manage
16、r (DCM) phase-shift functionalities can be used to achieve the best results especially at high frequencies.1.1 Building Blocks of the Testing SetupsThe testing system can be described in the following block diagramFigure 1: Burn-In Setup, System Block DiagramThe entire system consists of two boards,
17、 a driver board and a UUT board (test FPGA) and a high-speed cable to interconnect them. The driver boards roles are communicating with the host PC via EPP, setting up test vectors, read-back configuration bit streams for the test FPGA, and retrieving and comparing tests results. The UUT boards role
18、 is to host the FPGA under test, to accept test vectors, and return test results.2.0 Description Of Major ComponentsThe main components used on the boards are:-Various commercial and Mil Spec oscillators.-Three XC18V04 EPPROMs. These are Xilinx specially designed XC18V00 series In-System Programmabl
19、e (ISP) Configuration PROMs for re-programming and storing various sizes of Xilinx FPGA configuration bitstreams. VirtexII FPGA XC2V3000 requires a 10,494,368-bit configuration string.-A 728-pin socket for the test FPGA to improve signal integrity while providing 100% fan-out. The burn-in socket was
20、 placed in the center of the board. The socket allows for easy solderless replacement of UUT whenever desired. Two different burn-in sockets were used for the first revision of the UUT board. The first version used a socket manufactured by Enplas. For the second version of the board, a 728BG12B143 s
21、ocket by Plastronics was used. The latter allows UUT temperature monitoring using infrared sensors and is well suited for radiation testing. Both sockets are rated for an operating temperature range of -60C +150C. -Three sets of high-speed, individually shielded Teflon 50-Ohm coaxial pin cables with
22、 Samtec impedance matched high-density connectors. The length of each cable is 1 meter. There are two cable assemblies, one used for data and the second is used for program/configure the UUT. 3.0 Driver Board FPGA The VirtexII 3000 on the driver board (driver FPGA) acts as the brain of the entire sy
23、stem. It is responsible for communication with the user through the PCs parallel port. It stores user-defined test vectors and sends them out to the test FPGA upon receiving a specific command. It provides necessary download/read-back protocol signals and a datastream to configure and debug the test
24、 FPGA. It also acts as the built-in-self-test (BIST) logic to determine whether the incoming results from the test FPGA contain any errors. 3.1 Internal/External Test-Vector Storage InterfaceAt this time the hardware does not generate random test vectors. The software or the user must supply random
25、data as desired. It can be the same value such as commonly used AA or 55, or entirely random with any kind of distribution. Initially it will be stored in a text/data file in the Host PCs hard disk. Once the test FPGA is downloaded and the communication between the host PC and the test FPGA is succe
26、ssfully established, upon the users command the software will start to move the test vector files from the host PCs hard disk to the internal/external RAM onto the driver board. In the first release of the test platform internal block RAMs are used. The RAMs are 16 Kbits each with 8 being used. This
27、 results in a total maximum test vectors size of 128 Kbits (16 Kbytes). The size of the RAM is not particularly large but sufficient to demonstrate the functionality of the hardware. The user can generate appropriate test vectors to stress (exercise) the intended components (functional blocks) insid
28、e FPGA. The 8 block RAMs are combined into one 8-bit-wide 14-bit-deep true dual-port RAM. PortA of the RAMs will be used as read and write ports. This is used to initially set up the test vectors. Once all the addresses are being walked through, the start command is given by the user to start sendin
29、g test vectors to the test FPGA. PortAs address will then be driven by another counter/state machine to act as a read port for sending the data out. 3.2 Fault-Detection Interfaces (Internal or External)The block RAMs are configured as a true dual-port RAM, i.e., they can independently read/write on
30、both ports with totally separate addresses. Thus, PortA can be used for sending out the test vectors to the test FPGA. Then PortB can be used for comparison with the data coming back from the test FPGA. Once the RXEN signal goes from zero to one, the driver FPGA starts reading from address zero of P
31、ortB and comparing with the RXDATA stream. This is true for the Shifter and FIFO cases, since the data should stay unchanged. Once there is any discrepancy, an error bit will be set for that clock, and the error counter will be incremented by one to record the event. There are two sets of 8-bit coun
32、ters for showing error statistics. The assumption was made that the error rate will not be big enough to overflow the 64- bit counter in the software polling interval; otherwise the counter will roll over. One counter is used to count and the other is used to latch the first counter in case the soft
33、ware has to update the total error count. For example, if counterA is being read, it will latch counterBs value, and counterB will be cleared to zero and start counting from the beginning. If failure occurs during the read event, then countBs initial value will be set to one and not zero like it wou
34、ld have been otherwise. Thus it is impossible to miss any error count. Note that the total error count is accumulated and maintained by the software. The hardware is just keeping track of the incremental values. It is entirely up to the user to start or stop the comparison. Once the RXEN goes from o
35、ne to zero, the error counting and data comparison will stop. The software will still display the total error count from the last test. The calculators fault detection is somewhat complicated since it will have multiple CRC chains and the results for each chain are unknown until the data string is f
36、ully shifted in. In this case, the driver FPGA will know the total number of CRC chains and when data has been sent. After data ends, the driver FPGA will start to pull the results back from the test FPGA for each CRC chain. The driver FPGA will then compare the CRCs of each chain with pre-recorded
37、values. Once a discrepancy occurs, it will use the same counter mechanism as the other two cases to report error counts. 4.0 Unit Under TestThe objective of this approach is to effectively test the UUTVirtexII 3000. It is expected that most numerous components/building blocks of FPGA will produce mo
38、re failures. Therefore, it is natural to focus the testing on LUTs and block RAMs as well as other arithmetic units. In fact, for most of the designs, these three major resource components are in high demand both in terms of quantities as well as qualities. How much they are utilized and how they ar
39、e interconnected and what timing can be achieved directly dictate how well the system performs. 4.1 Interfacing the Driver FPGA and Possible Clocking Schemes The driver FPGA is interfaced with the test FPGA via two 8-bit data buses (for each direction) plus some control bits. On actual boards there
40、are a total of 20 pins in each direction for data, control, and test signals. There are two bases: one for each direction to maximize the signal integrity and to utilize digitally controlled impedance-matching (DCI) feature offered in VirtexII FPGAs. In case of dimensional constraints, the user can
41、reduce the number of interface lines between the two boards. The minimum number of lines for each direction is 12. They are TXEN as the data valid, TXDATA 8:0 as the 8-bit data flowing into the test FPGA, and TXCLK together in phase with the TXDATA, and two bits of TXCONTROL for 4 possible condition
42、s. At higher frequencies (80 MHz and up), transmission line delay becomes a factor. Several approaches are used to synchronize data between the two boards by compensating for the transmission line (cable) delay. In the first approach, by using the same clock on both boards, the driver board sends th
43、e TXCLK together with its data and the test board then clocks all its internal logic with this TXCLK. The test FPGA uses the falling edge of the TXCLK to clock all its logics. So when the test FPGA sends the data back to the driver FPGA, it will not send back the clock, and the driver FPGA on the re
44、ceiving end has to phase-shift its clock to be able to correctly clock in the data to compensate for the cable wire delay. If the test FPGA uses the falling edge of the TXCLK, the driver FPGA still uses its original clock. In the second approach, two clock domains may exist inside the driver FPGA an
45、d only one in the test FPGA. This method is suitable if the operating frequency is relatively low, since it is easier and safer to say one fixed phase shift value will work for any board under any temperature variations. But for higher-speed clock rates, the window is a lot smaller and using two-clo
46、ck domains is more complex. Using only one clock domain for the entire system is simpler. However, one has to watch and compensate for the delay introduced by the long cables. At clock rates over 25 MHz, the DCM feature of VirtexII FPGA becomes available. This feature offers the capability of deskew
47、ed clocks with proper feedback. In the given test bed, all the cables are as short as possible having exactly the same length, to simplify single-clock-domain utilization for both boards. The design can effectively use the driver board to clock out data early enough to compensate for the wire delay
48、so that when the test FPGA gets the data, it will satisfy all the setup and hold time. The fan-out traces for UUT FPGA are almost the same length of about 4 inches. The test system offers a choice of four independent oscillators; two commercial on the driver board and two MIL Spec on the UUT board.T
49、he challenge of using multiple clock domains deserves more attention. Considering that in the design, the feedback path is exactly the same length as the source path, it is possible for two FPGAs to operate using totally independent clocks. That means that the two clocks have no phase relationship whatsoever, even if they are relatively the same in frequencies. This choice leads to a s
