Design and Implementation of Automatic Test Equipment IP Module

Design and Implementation of Automatic Test Equipment IP Module S. Fransi SFP e engineering Munich, Germany G. L. Farré, L. G. Deiros, and S. B. Manich Electrical Engineering Dept. (EEL) Universitat Politècnica de Catalunya (UPC) Barcelona, Spain manich@eel.upc.edu Abstract This paper presents an Intellectual Property (IP) module that includes fully functional autonomous Automatic Test Equipment (ATE). The module analyses responses from the Device Under Test (DUT) after sending test vectors to the device. Communication with the DUT is maintained through a synchronous bidirectional serial channel. The module has been designed for a fail-safe level of security, which means any single fault producing an erroneous output is detected. Several IP-ATEs can be synthesized in a single hardware platform to operate independently or coordinately. Keywords-Automatic Testing; Digital Circuits; Field Programmable Gate Arrays; Intellectual Property; Low Power Tester; Low Cost ICs; Multisite Tester. I. INTRODUCTION Production test is a crucial step for maintaining the quality of ICs provided to the customer [1][2]. Although chips are continuously incorporating better Built-In Self-Tests (BIST) techniques, external test equipment is still necessary during production testing [3], for example for individual personalization data or reading out of IC parameters for diagnosis or calibration [4][5]. Production test is performed by sophisticated Automatic Test Equipment (ATE) designed to run continuously and at very high levels of quality. These high performance ATEs (H- ATEs) are expensive machines with high power consumption. Nevertheless, their impact on the cost per chip test is reduced by massive parallelization [6]. In recent years the crisis has opened the discussion on the cost of test and the possibility of substituting H-ATEs by cheaper low performance ATEs (L- ATEs) [7][4][8][9]. L-ATEs can hardly achieve the high quality levels reached by H-ATEs, and therefore the latter cannot be completely replaced by the former. However, L-ATEs can complement the work performed by H-ATEs, thus reducing the total cost of test. In factory, H-ATEs are planned to operate at maximum load in order to minimize the cost per chip test. Throughput can be increased, thus further cutting the cost if the time per chip test is shortened [4] by executing the less demanding parts in L-ATEs. Costs can be further reduced if chips include sophisticated built-in test or built-off test techniques which relax the demands of the external ATE, allowing the execution of the most demanding parts in L-ATEs [10]. Our proposal is therefore to cut production test costs introducing L-ATEs massively. The improved performance of programmable hardware like FPGA chips has led to the development of an IP module implementing a fully functional ATE machine. In fact, H-ATE machines and auxiliary equipment already use FPGA chips to execute powerful signal processing algorithms [11]. Several implementations of L-ATEs based on FPGA have been published [8] and [9]. Their advantages include great flexibility, low cost and reprogrammability. On the other hand these new L-ATEs cannot create shmoo plots or operate in failsafe mode. Shmoo plots are often necessary during the design stages of test flows while fail-safe operation is important when the tester has to run without interruption in production test. The paper presents an IP module containing an L-ATE (IP- ATE) able to conduct digital test at a very low cost. The module sends test vectors and analyzes output responses through a one bit bidirectional synchronous channel, as well as performing standard flow and shmoo tests. Apart from the digital information of the test, the IP-ATE system can control the following parameters of the DUT: clock frequency and phase, capture cycle delay and supply voltage. A low cost, customer specific external programmable power supply was designed for the controlling the supply voltage commanded from the IP-ATE system through a bus interface. Several IP- ATEs can be synthesized in one or more FPGAs to create a multisite tester. They can operate independently or in cooperation, depending on the test needs. The fail-safe design of the digital part makes the operation of the system robust against catastrophic failures of the FPGA. The rest of the paper is organized as follows. In section II, an overview of the IP-ATE system is given. Section III explains how the system is protected against hardware failures. In section IV, the experimental results obtained are summarized, and finally section V draws conclusions. II. OVERVIEW OF THE SYSTEM The IP-ATE system is specifically designed to perform tests efficiently. It includes four main modules, namely a master (MT), a test pattern generator (TPG), an output response analyzer (ORA) and a clock manager (CM), see Figure 1. Other auxiliary modules necessary for the correct operation of

IP-ATE V AN V DIG to data bus MA MT CM CLK FIFO TPG INTERFACE RST IO to DUT CLK V DIG V AN CLK FIFO ORA GND to IP-ATE RST IO RST IO to DUT to PC serial link USB EI hardware controls TG trigger signal AIC AIC bus µc serial link V CC GND Figure 1. Overview of the IP-ATE system. the whole system are: access manager (MA), trigger generator (TG), analog interface controller (AIC), USB controller, external interface (EI) and input/output buffers for correct data transaction between the IP-ATE system and DUT chip. A. Digital Part The entire digital part of the system is included in the IP module. This part has all the functionality of the IP-ATE system and can test DUT chips even if no special power supply is required. The two main modules are the Test Pattern Generator (TPG) and Output Response Analyzer (ORA). Both are designed to test a single I/O pin of the DUT. If additional I/O pins are required, these modules must be replicated and the external and all internal registers resize automatically. The TPG reads the test vectors from an external, decodes them and sends the data to the DUT chip at the required rate. Each test vector contains all the necessary information for the correct execution of the test (timing, voltage and data). The ORA verifies the responses from the DUT, compares them with the decoded data and, in case of error, generates a diagnosis into the external. Memory transactions are performed through FIFO queues to maintain a sustained data flow in the TPG and ORA. The Clock Manager (CM) generates two clocks, one for the DUT chip and another to synchronize the TPG and ORA. The timing for the DUT chip clock is defined in each test vector. The programmable parameters are the period and delay of the rising and falling edges. The clock can also be set to always high or always low. The Master (MT) supports the operation of the TPG in the flow or shmoo mode. In shmoo mode it is responsible for setting the shmoo variables. It also performs the entire internal initialization of the TPG and IP-ATE system, and decodes information from special types of test vectors whose purpose is not to test but initialize the IP-ATE system. Figure 2. IP-ATE external interface with DUT. The other modules carry out auxiliary tasks necessary for the correct operation of the system. The MA controls the access to the external, giving the right priorities to the TPG and ORA. The AIC controls the analog interface. Each test vector contains the voltage level at which the DUT chip must be tested. This information is decoded by the TPG and sent to the analog interface through the AIC controller, which communicates using a digital protocol. Communication is bidirectional and is prepared to have current consumption feedback in future versions. The TG generates a trigger signal at the desired test vector for debugging or analysis purposes. The EI interfaces with the user for automatic testing (in our prototype with a PC via the USB module). The control signals are run, reset and start, while the indication signals are end, and pass/fail test. B. Analog part The analog part is included in the IP-ATE interface and is designed according to customer requirements. This interface is responsible for generating the variable voltage supply levels. Two independent digitally controlled dc-dc converters were incorporated to allow the generation of independent voltage levels to supply the DUT chip ( and GND) and level shifting drivers of signals CLK, IO and RST (V ). The driver of signal IO is bidirectional. All the digital parts of the interface are controlled by a microcontroller that interfaces to the AIC. The digital subcircuit is powered by a third voltage converter (V ). Figure 2 shows a diagram of the interface. C. PC interface For demonstration purposes a PC was connected to control and supervise the IP-ATE system through a USB bus. The PC has three main functions: i) compile and compress the entire test flow information and send it to the IP-ATE external (in our prototype this is flash type), ii) send control signals and receive status information about the evolution of the test, including the pass/fail signal and iii) read error information from the IP-ATE external and generate diagnostic information from the DUT and the IP-ATE system itself, Figure 3 illustrates these functions.

Test flow Library of test functions Display test results Store diagnostics Compiler Binary data stored Binary data read Post processing External IP-ATE Operation control Monitor test status Figure 3. Initialization, supervision and analysis of the results of the IP- ATE with a PC. The test flow is entered using a code library that can be customized. In our prototype, the compiler translates automatically existing test flows written in commercial test languages. After reading the test flow programmed by the user the compiler generates a binary file with all the information required by the IP-ATE system. This information includes the tables required for decompressing test vectors performed in the TPG unit. Other actions carried out by the compiler are data segmentation and delay instruction insertion to avoid overflow of internal FIFOs, and check event call insertion to verify the system reliability. In the post-processing step the external of the IP- ATE system is read from the PC and binary data are decoded. Post-processing includes analysis of DUT errors and verification of the correct operation of the IP-ATE system. Data are then displayed on the screen and stored in the computer in ASCII standard format, for convenience of test engineers. The next section explains the protection system against failures included in the design. III. SECURITY OF THE SYSTEM OPERATION The IP-ATE system is described by a soft code. It can be implemented on different types of hardware platforms, such as FPGAs. Moreover, several IP-ATE units can be synthesized in the same platform to operate in parallel either independently or coordinately. The unit can also run in autonomous mode over a continuous period of time. Any piece of hardware may fail at any moment. Although running a system in an FPGA has a low ratio of failure, our IP- ATE system incorporates mechanisms to inform about any hardware failure. The system is designed to be fail-safe in the presence of single stuck-at faults [12], which means that during normal operation the system will alert if an error modifies the expected output. Other types of faults may also be detected if, at some point, they flip some logic level. This level of security makes maintenance of the digital part of the system unnecessary. If the IP-ATE system detects a hardware failure, it stops the test and the FPGA is reprogrammed. The analog part (described in II.II.B) could also be designed with self-calibrating options. Thus, it is possible to have an IP-ATE system with zero maintenance. Unexpected outputs are caused by faults excited at some critical signal, which propagates the error to the output. Failsafe systems react if the error comes from internal signals as well as from inputs. In normal operation, outputs are restricted to a subset of possible ones, named the code-set. These are the expected correct values. When the system generates an output not included in the code-set (that is belonging to the non-codeset) then an error alert is activated. The following paragraphs explain the main ideas of the failsafe design. A. Output Code Generator A critical unit for the design of fail-safe behavior is the output code generator (OCG). This unit, included in the ORA module, generates the map of DUT chip errors on-the-fly during test execution. A diagram of this unit is shown in Figure 4. This circuit receives inputs (I, f) and gives outputs (c, w). Input I is the index of test vectors. This index, internally generated in the TPG module, is an ordinal number that runs from 1 at the first test vector to its maximum value at the last test vector. The number of bits of I is r, which should be enough to store the maximum value. Output signal w is the write into signal, which is 1 each time a valid code is present in c. During test execution, the OCG unit sends new codes to the each time w 1. Let I and I be two consecutive indexes reaching the OCG for which f 1. The unit divides (I I )/(2 1) giving the quotient and residue of the division in the following way: a number of (2 1) codes are sent in c equal to the quotient of the division and a code equal to the residue is from ORA I f r r reg I 1 r s Figure 4. Output code generator. It generates the map of DUT errors onthe-fly. 2 s 3 4 s c w to

finally added to the series of (2 1) codes, in the following paragraphs this mode of operation is detailed. The total number of codes sent at test completion is bounded by equation (1) TABLE I. STATE TRANSITION TABLE OF THE OUTPUT CODE GENERATOR. Type of event call f I I I c w No (2 0 1) I (2 1) 1 No <(2 1) I 0 DUT fail/sys. check (2 1 1) I 0 1 DUT fail <(2 1) I I I 1 M s ( ) +N where M is the number of bits required to store all the codes, I is the maximum value of the index, (2 1) for the IP- ATE system, N is the maximum number of expected DUT errors, 100K in our case, and s is the size of the code word. For the IP-ATE system, this boundary is minimized for s 8; thus, a of 131K bytes is required. Signal f is the event call of the system. When signal f 1, two types of events can occur in the system: i) an error is detected during the analysis of the DUT response, and ii) a check of the system is forced while test vectors are sent to the DUT chip. When f 0 no event occurs and the code generator periodically outputs the maximum possible value (2 1) in c. If an event occurs, then a call is made with f 1 and the code generator outputs a value lower than (2 1) at c. Table I shows the state transition table of the OCG unit. After completion of the test, the stores all the indexes where some type of event has occurred as codes in the form of quotient and residue. They are decoded by adding all the codes starting from the first position of the. The partial results obtained when the codes are different from (2 1) are the expected values of the indexes. As an example, consider the case of the IP-ATE system where the codes are of s 8 bits. Assume that I is the index of the first event and that c,i 1,2, are the codes generated at the output. The sequence of codes would be and is therefore used for the event that checks the integrity of the system. If a second event occurs at index I, then we have c,ff,,ff, FF, c, q q +Q +1 if 00<c <FF c,ff,,ff, c, q q +Q if c 00 Q (I I ) (2 1) c (I I ) mod (2 1) and so on. As can be seen from the previous example, more FF codes are written into than non-ff codes, especially during testing of good DUT chips. A large reduction of codes would be expected if we had compressed the FFs. However, in the IP- ATE system these FF codes are used in combination with the 00 codes to check system correctness and reliability while test vectors are sent to the DUT chip. A detailed explanation is given in the following paragraphs. B. Analysis of the Fail-Safe Property of the OCG Unit Assume that an index H is decoded from the output. Index H must be equal to I if no error occurs. H is decoded by the following equation: H H Q, (2 1) +c Consider the case where an error alters index k, i.e. I I + E. This error will propagate through the OCG unit resulting in: Q, Q, +E and c c +E where EE (2 1) +E. The OCG unit propagates the error through either the quotient or residue or both. Therefore irrespective of the error, we always have FF,,FF,FF, c,q Q +1 if 00<c < FF FF,,FF, c,q Q if c 00 H Q, (2 1) +c +H Q, +E (2 1) +c +E +H Q (I 0) (2 1) c (I 0) mod (2 1) where Q is the quotient of the division (number of FF codes) and c is the residue (numbers are in hexadecimal notation). The case of c 00 is treated as an exception and must be added as FF during recovery of the indexes. This exception has the advantage that no increase in storage is required, H +E. If the error is in the register, then it comes in through I I I +E and propagates, giving a similar output as (4) but with the plus sign changed to minus, i.e. E. If the error is altering the operation of the adder, any combination of E and E may be generated internally. Either way, the error will appear at the output, giving the general form of (4) as well, and thus it will be detected.

For the rest of the gates and signals of the OCG unit, the following situations may occur, see Figure 4. They are analyzed for both stuck-at (sat) faults. Gate 1. If a sat-0 occurs, since this gate is also signal w no valid code will be stored into the, and neither will the FF codes, which will allow the detection of the fault. For a sat- 1, the OCG unit will never generate FF codes and thus the error will also be immediately detected. Gate 2. If a sat-0 occurs, then the register will never store any I while f 0. As a result, the first index I will be correctly calculated but from the second index on, the recovered indexes will be H H c. Therefore, the error will be detected except if all the residues are zero, in which case all the decoded indexes will be correct. Moreover, if a check event is activated to generate a 00 code, the circuit will give an FF code instead; in consequence, the fault will also be detected. A sat-1 is equivalent to gate 1/sat-1, and it can thus be detected. Gate 3. A sat-0 produces the constant 00 code, forbidding the output of the FF codes, which leads to its immediate detection. A sat-1 avoids the generation of check events (00 code), thus allowing this fault to be detected. Gate 4. A sat-0 in any of the output bits prevents the generation of the FF codes and a sat-1 behaves similarly for the 00 code. The generation of both codes during test allows the detection of faults in this gate. Output. Errors affecting the output behave similarly to the faults of gate 4. Therefore, they can also be detected. Input signal f. If a sat-0 occurs, then no 00 codes will be generated, and thus the fault can be detected. If a sat-1 occurs, then no FF codes will be generated and the fault will be detected, too. In summary, it has been shown that the OCG unit is failsafe and also that in case of faults in the output ; they can be detected during the decoding of indexes. Notice that all indexes activated by events are known in advance, during the compilation of test vectors, i.e. before sending them to the input, see Figure 3. To extend the fail-safe property to the rest of the IP-ATE system, we must make sure that any internal error can propagate to the inputs of the OCG unit, as explained below. C. Extending Fail-Safe Property to the IP-ATE System Figure 5 illustrates the model of the data rails in the IP-ATE system. After the test vector is read from the external, its integrity is verified by the CRC code included in the vector. If an error is detected at this stage, an error signal is activated. Two bits are then extracted: x is the data bit to be sent to the DUT chip and y is the check bit to be compared with the response. In a standard mode of operation these bits would be used alternatively, that is, either the x data bit is sent to the DUT chip or the response from the DUT chip is verified against y. However, to keep the fail-safe property, at least two from Error signal Test vectors C R C 2 TPG Index counter y ORA Check bit Data bit DUT loop back Figure 5. Data rails in IP-ATE system. Output codes to independent rails must operate simultaneously [12]. In our case, we benefit from the two bits to verify the full integrity of the data rails during the writing of x into the DUT. The DUT loop back (see doted box in the figure) is kept connected and a copy of x is sent back to the XOR gate. There the data bit is compared to the check bit y and the f signal is generated. In brief, the system is checked internally in the sending phase while during the receiving phase the back rail carries responses from the DUT chip. In the sending phase, the two possible values of signal f are obtained by forcing the conditions y x f0 or y x f1 (check event call). By controlling bit y the test flow compiler generates check event calls at the following index values: I I +2i(2 1) f1 for i 1,2, This mode of operation generates a code profile in the output like <,FF, 00,FF, 00,FF, > Thus, any error in the x or y rails will propagate to f and modify this profile, allowing the detection of the error. If the error comes through the index counter, it will also be detected since a noncode output will be generated. During the receiving phase the code profile is as described above <,FF,FF,FF,FF,FF, > and only the non-ff codes will indicate errors in the DUT response. IV. EXPERIMENTAL RESULTS A portable test equipment based on the IP-ATE was built to develop tests for card chips. Figure 6 contains two pictures of the equipment. The left box, is closed and only the sockets holding the DUTs are accessible. The cover of the right box is open and the hardware is partially visible. At the left side of the box the connectors for the 12 V power supply and the output trigger signal connector (white) can be seen. On the right the port to connect the PC is accessible (the other connectors are not used in this version). The technical data of the equipment are summarized in the following paragraph. The IP-ATE is synthesized in an XC3S700AN FPGA. This chip is soldered on a PCB at the bottom of the equipment (not visible in the picture). This FPGA has an internal 8Mbit flash x I f O C G DUT

This work has been partially supported by MCyT and FEDER project TEC2007-66672. The authors thank the helpful comments of the referees. Figure 6. Portable test equipment based on a Spartan3 board. The core of the system is the IP-ATE. used as the external for the IP-ATE system, allowing storage of 250K uncompressed test vectors and 249K faults. If the compression mode is used, the number of stored test vectors can raise up to 16 times, i.e. 4M test vectors. The IP-ATE system implemented in the equipment has a second ORA module operating in slave mode. This allows testing two chips simultaneously. The total occupation of the FPGA is 28% of the logic resources and 68% of the internal block RAM FPGA resources. The system is clocked at 40MHz, giving a control range of the DUT clock period from 50ns up to 6.4s; the resolution is 25ns and the number of time sets is 32. The FPGA has an internal digital clock multiplier that can raise the frequency to 350MHz. The IP-ATE can operate at this maximum frequency provided the interface boards are redesigned. At this frequency the DUT clock period ranges from 5.7ns to 731ns with a resolution of 2.86ns. The two external interface boards, one for each DUT, can be seen at the top of the equipment. The power converters can change the voltage levels from 1 to 6 volts with a resolution of 20mV and an accuracy of 1mV. Their dynamic response is 5msV -1. These values were verified for one month of continuous operation. All the PC supporting software is programmed in C. It includes the test vector compiler, post-processing software and user control interface. The post-processing step gives an Excel compatible output which allows the display of numerical and graphical data on a spreadsheet. REFERENCES [1] Test and Test Equipment (ITRS), SIA, 2007. [2] H. Deshayes, Cost of Test Reduction, ITC, pp. 265-270, Oct. 1998. [3] S. Zhang, M. Choi, F. Lombardi, Cost-Driven Optimization of Cov erage of Combined Built-In Self-Test/Automated Test Equipment Testing, Trans. Instr. & Meas.,vol. 56, no. 3, pp. 1094-1100, June 2007. [4] M. Abadir, Economics of Electronic Design, Manufacture and Test, Springer, 1994. [5] D. J. Costa Alves, E. Barros, A Logic Built-in Self-Test Architecture that Reuses Manufacturing Compressed Scan Test Patterns, SBCCI, no. 21, Aug. 2009. [6] G. Smith, The Challenge of Multisite Test, Test & Meas. World, pp. 31-34, Feb. 2006. [7] J. Rivoir, Parallel Test Reduces Cost of Test More Effectively Than Just a Cheap Tester, SEMI, pp. 263-272, July 2004. [8] L. Ciganda, F. Abate, P. Bernardi, M. Bruno, M. S. Reorda, An Enhanced FPGA-Based Low-Cost Tester Platform Exploiting Effective Test Data Compression for SoCs, DDECS, pp. 258-263, April 2009. [9] L. Mostardini, L. Bacciarelli, L. Fanicci, L. Bertini, M. Tonarelli, A. Giambastiani, M. De Marinis, FPGA-Based Low-Cost System for Automatic Tests on Digital Circuits, ICECS, pp. 911-914, Dec. 2007. [10] S. S. Akbay, A. Halder, A. Chatterjee, D. Keezer, Low-Cost Test of Embedded RF/Analog/Mixed-Signal Circuits in SOPs, Trans. on Adv. Pack., vol. 27, no. 2, May 2004. [11] R. W. Lowdermilk, F. J. Harris, Vector Signal Analyzer Implemented as a Synthetic Instrument, Trans. on Instr. & Meas., vol. 58, no. 2, pp. 281-290, Feb. 2009. [12] D. K. Pradhan, Fault-Tolerant Computing: Theory and Techniques, Prentice-Hall, vol. 1, 1986. V. CONCLUSIONS The paper presents an intellectual property module of an automatic test equipment (IP-ATE) which can be synthesized in programmable hardware like FPGAs and control an external interface for voltage variations of chips under test. To avoid unexpected hardware failures the IP-ATE system was designed to be fail-safe, which means that any single error affecting the output is detected. The system can be controlled from an external PC through a USB bus. Several IP-ATE units can operate on a single hardware platform independently or in coordination. A real prototype to test card chips using an XC3S700AN FPGA chip and able to test two chips simultaneously was built. The IP-ATE system only occupies 28% of the logic resources and 68% of the block RAM FPGA resources. ACKNOWLEDGMENTS