TWI810523B - Automated test equipment system and apparatus, and method for testing duts - Google Patents

Abstract

An automated test equipment (ATE) system comprises a system controller communicatively coupled to a tester processor, where the system controller is operable to transmit instructions to the tester processor, and where the tester processor is operable to generate commands and data from the instructions for coordinating testing of a plurality of devices under test (DUTs). The apparatus also comprises an FPGA programmed to support a first protocol communicatively coupled to the tester processor comprising at least one hardware accelerator circuit operable to internally generate commands and data transparently from the tester processor for testing a DUT of the plurality of DUTs. Further, the apparatus comprises a bus adapter comprising a protocol converter module operable to convert signals associated with the first protocol received from the FPGA to signals associated with a second protocol prior to transmitting the signals to the DUT, wherein the DUT communicates using the second protocol.

Description

Automatic test equipment system and device, and method for testing device under test

cross-references to related applications

This application is based on U.S. Patent Application No. 15/914,553 filed on March 7, 2018, entitled "A TEST ARCHITECTURE WITH A FPGA BASED TEST BOARD TO SIMULATE A DUT OR END-POINT" and the inventors are Duane Champoux and Mei-Mei Su also has Attorney Docket No. ATST-JP0090.P1, which is a continuation in part of U.S. Patent Application Serial No. 13/773,569, filed February 21, 2013, entitled "A TEST ARCHITECTURE HAVING MULTIPLE FPGA BASED HARDWARE ACCELERATOR BLOCKS FOR TESTING MULTIPLE DUTS INDEPENDENTLY", the inventors are Gerald Chan, Eric Kushnick, Mei-Mei Su and Andrew Niemic, and it is part of the continuation case with attorney case number ATST-JP0090. Both applications are hereby incorporated by reference in their entirety for all purposes.

This application also asserts U.S. Provisional Application No. 62/988,612, filed March 12, 2020, with Attorney Docket No. ATSY-0090-00.00US, entitled "Use of a Host Bus Adapter to Comply with a Computer with Full Acceleration" The priority of the technology that provides protocol flexibility in combination with FPGA (USE OF HOST BUS ADAPTER TO PROVIDE PROTOCOL FLEXIBILITY USED IN COMBINATION WITH FPGA WITH FULL ACCELERATION FOR TESTING). The entire contents of each of the applications listed above are hereby incorporated by reference for all purposes as if fully set forth in this case.

field of invention

The present invention relates generally to the field of electronic device test systems, and more particularly to the field of electronic device test equipment for testing devices under test (DUTs).

Background of the invention

Automated test equipment (ATE) may be any test component that performs a test on a semiconductor device or electronic component. ATE components can be used to perform automated testing that rapidly performs measurements and produces test results that can then be analyzed. An ATE assembly can be anything from a computer system coupled to an instrumentation to a complex automated test assembly that includes a customizable, dedicated computer control system and many different test instruments capable of automatically testing electronic Component and/or semiconductor wafer testing, such as system-on-chip (SOC) testing or integrated circuit testing. The ATE system both reduces the time spent on testing a device to ensure that the device is functioning as designed, and also acts as a diagnostic tool to determine whether a given device has a faulty component before it reaches the customer.

FIG. 1 is a schematic block diagram of a conventional automatic test equipment (ATE) body 100 for testing some typical DUTs, such as a DRAM semiconductor memory device. The ATE includes an ATE body 100 having hardware bus adapter receptacles 110A-110N. Hardware bus adapter sockets 110A-110N specific to a particular protocol (such as PCIe, USB, SATA, SAS, etc.) Agreed cables interface the DUTs. The ATE body 100 also includes a test processor 101 with an associated memory 108 to control the hardware components built into the ATE body 100, and to generate card) commands and data required for communication between the DUTs being tested. The tester processor 101 communicates with the hardware bus adapter sockets (or cards) through the system bus 130 . The tester processor can be programmed to include certain functional blocks including a type Sample generator 102 and a comparator 106. Alternatively, the pattern generator 102 and comparator 106 may be hardware components mounted on an expansion or adapter card that plugs into the ATE main body 100 .

The ATE main body 100 tests the electrical functions of the DUTs 112A-112N connected to the ATE main body 100 through the hardware bus adapters plugged into the hardware bus adapter sockets of the ATE main body 100 . Therefore, the tester processor 101 is programmed to transmit the test programs to be executed to the DUTs using the protocol unique to the hardware bus adapters. Meanwhile, other hardware components built in the ATE main body 100 transmit signals among each other and the DUTs according to the test program running in the tester processor 101 .

The test program executed by the tester processor 101 may include a functional test involving writing the input signals generated by the pattern generator 102 into the DUTs, reading them from the DUTs The written signals and the comparator 106 are used to compare the output with the expected patterns. If the output does not match the input, the tester processor 101 will identify the DUT as defective. For example, if the DUT is a memory device such as a DRAM, the test program will use a write operation to write the data generated by the pattern generator 102 into the DUT, and use a read operation Data is read from the DRAM and the comparator 106 is used to compare the desired bit pattern with the read pattern.

In conventional systems, the tester processor 101 needs to contain the functional logic blocks to generate the commands and test patterns used in testing the DUTs, such as the pattern generator 102 and the comparator 106 , they are programmed in software directly on the processor. However, in some cases, certain functional blocks such as the comparator 106 can be implemented on a Field Programmable Gate Array (FPGA), which can program logic circuits according to a user's needs. An Application Specific Integrated Circuit (ASIC) type semiconductor device.

The FPGAs used in conventional systems may be pass-through devices that rely on the tester processor 101 to transmit the commands and test patterns to the FPGA, which in turn to the DUTs. Because the tester processor, not the FPGA, is responsible for generating the commands and test patterns, the number and types of DUTs that can be tested using a given ATE subject will be limited by the number and types of DUTs that can be tested using the tester processor. Processing capacity and planning constraints. With the tester processor generating all commands and test patterns, the bandwidth limitation on the system bus 130 also places an upper limit on the number of DUTs that can be tested simultaneously. The system bus 130 connects the tester The processor is connected to various hardware components, including any FPGA devices and such hardware bus adapter sockets.

Also, in conventional systems, the communication protocol used to communicate with the DUTs is fixed because the hardware bus adapter sockets (or cards) that plug into the ATE main body 100 are single purpose devices , they are designed to communicate with only one protocol and cannot be reprogrammed to communicate using a different protocol. For example, an ATE body configured to test PCIe devices will have hardware bus adapter sockets (or cards) that only support the PCIe protocol plugged into its body. To test a DUT that supports a different protocol such as SATA, the user typically needs to replace the PCIe hardware bus adapter socket (or card) with a bus adapter card that supports the SATA protocol. Unless the PCIe hardware bus adapter socket (or card) is physically replaced by a card supporting another protocol, this system can only test DUTs that support the PCIe protocol.

In a different type of conventional ATE, the FPGA is not just a straight-through device as described above. Instead of using a hardware bus adapter socket (or card) to implement a protocol for communicating with the DUTs, it can be downloaded via a simple bitstream from a cache on a system controller , the new protocol for communicating with the DUT can be downloaded and installed directly on the FPGA of a tester system. An FPGA in a tester typically includes a configurable interface core (or IP core) that can be programmed to provide the functionality of one or more protocol-based interfaces to a DUT and can be programmed to interface The DUT. Additionally, if a new protocol is released, the FPGAs can be easily configured with that protocol via bitstream download rather than having to physically switch all the hardware bus adapter sockets (or card) is more convenient.

Typically, conventional testers only allow a single IP core to be programmed onto an FPGA. Since the FPGA accelerator of the current test system can only support a single IP core, if a different third-party IP core needs to be planned into the FPGA, it will need to redesign the FPGA. Therefore, if the DUTs connected to an FPGA need to be replaced with a different type of DUT, the FPGA needs to be reprogrammed to support a different protocol. In a test environment, reprogramming an FPGA can be very time-consuming and cumbersome.

Furthermore, the time-to-market of memory and other devices is getting shorter and shorter. Also, protocol IP is becoming more and more proprietary, so the FPGA may only support a single protocol. In addition, since many third-party IP cores are proprietary, they cannot be programmed onto an FPGA.

Summary of the invention

Therefore, there is a need for a tester architecture that can solve the above-mentioned system problems. What is needed is a test architecture in which the command and test pattern generation functions can be offloaded to the FPGA so that the processing load on the tester processor and the frequency on the system bus can be offloaded. Broad demand can be kept to a minimum. This would be more efficient than the current configuration, where the tester processor does the entire processing and the system bus passes all the DUTs connected to the ATE body. Test data and commands.

Additionally, there is a need for a test architecture by which a host bus adapter can be used in conjunction with an FPGA to provide protocol flexibility. As mentioned above, since protocol IP is becoming more and more proprietary, the FPGA only supports one protocol and if another protocol is required, a host bus adapter (HBA) can be used to bridge a third party IP protocol. In other words, the programmable interface core (or IP core) in the FPGA, which is programmable, is used in conjunction with a host bus adapter to interface a third-party protocol to communicate with a DUT, wherein the The DUT supports a different protocol than the one programmed in the IP core. This allows engineers in a test environment to be able to Switch protocols quickly.

In one embodiment, an automatic test equipment (ATE) system is disclosed. The apparatus includes a system controller communicatively coupled to a tester processor, wherein the system controller is operable to send instructions to the tester processor, and wherein the tester processor is operable to generate from the instructions Commands and data are used to coordinate testing of multiple devices under test (DUTs). The apparatus also includes an FPGA communicatively coupled to the tester processor, the FPGA including at least one hardware accelerator circuit operable to internally generate commands and data transparent to the tester processor for testing A DUT among the plurality of DUTs. Further, the device includes a bus adapter including a protocol converter module operable to convert a signal received from the FPGA associated with a first protocol to a signal associated with a first protocol The signals associated with the second protocol are then sent to the DUT, wherein the DUT communicates using the second protocol. In one embodiment, the second agreement is a proprietary third-party agreement.

In another embodiment, an automatic test equipment (ATE) apparatus includes a tester processor operable to generate commands and data for coordinating testing of a plurality of devices under test (DUTs), the apparatus Also included is an FPGA communicatively coupled to the tester processor, wherein the FPGA includes a hardware accelerator circuit operable to internally generate commands and data transparent to the tester processor for testing the complex A DUT of the DUTs, and wherein the FPGA includes an IP core operable to generate signals for sending commands and data from the FPGA to the DUT using a first protocol. The device also includes a bus adapter including a protocol converter module operable to convert the signals received from the FPGA associated with a first protocol to those associated with a The signals associated with the second protocol are then sent to the DUT, wherein the DUT communicates using the second protocol.

In one embodiment, a method for testing a DUT is disclosed. The method includes transferring instructions from a system controller to a tester processor, including a tester processor with an FPGA A board and the tester processor are coupled to the system controller, and wherein the tester processor is operable to coordinate testing of a plurality of devices under test (DUTs). The method also includes generating commands and data for testing one of the plurality of DUTs according to a first protocol implemented in an IP core of the FPGA and according to a selected acceleration mode, wherein the generating is performed by Executed by a hardware accelerator circuit included in the FPGA. Additionally, the method includes communicating signals associated with the commands and the data from the FPGA to a bus adapter using a first protocol. Additionally, the method includes converting the signals transmitted using the first protocol to signals in a second protocol using the bus adapter and a protocol IP core implementing the second protocol, wherein the bus adapter is communicatively coupled to a DUT operable to communicate using the second protocol. The method further includes relaying the signals in the second protocol to the DUT for testing.

The following detailed description together with these drawings will provide a better understanding of the nature and advantages of the present invention.

100: ATE subject

101, 204, 304, 1101: Tester processor

102: Pattern Generator

106: Comparator

108,304,308: memory

110A, 110B,...,110N: Hardware bus adapter sockets

112A,112B,...,112N,220A,220B,220C,...,220N,372A,372B,372C,...,372M,1055,1110,1207,1208,1209,1210:DUT

130,330,332: system bus

200,300: ATE equipment

201, 301: System controller

202,302: network switches

210A, 210B, 210C,..., 210N: FPGA tester blocks with instantiation of functional modules

211A, 211B,..., 210M, 316, 318, 1002, 1104: FPGA

212: Shared bus~

230A, 230B,..., 230N, 310A, 310B, 1102: field modules

240A,240B,...,240M: memory block

340A, 340B,..., 340N: tester sheet

332A, 332B: device power supply

380: load plate

390: Thermal Test Chamber

410:Instantiated FPGA tester block

420:Local memory module

430:Protocol engine module

440:Hardware Accelerator Block

443:Algorithm pattern generator module

444:Memory control module

445:Packet builder module

446:Comparator module

450: Logic Block

470: PCIe upstream port

472,474,476: paths

480:PCIe downstream port

481: Universal Connector

482: Arrange routing logic

500,600,700,800,900,1300: flow chart

502~508,602~612,702~714,800~814,902~916,1310~1316: block

1001, 1040, 1042: interface

1004: Protocol converter IP block

1008, 1106, 1206: HBA

1010, 1205: IP core

1060: Field module board

1062,1107,1215: sandwich panel

1064: device interface panel

1201, 1202, 1203, 1204: accelerator cores

In the various views of the drawings, embodiments of the present invention are shown by way of example and not by way of limitation, and wherein like reference numerals designate like elements.

FIG. 1 is a schematic block diagram of a conventional automatic test equipment body for testing a typical device under test (DUT).

Figure 2 is a high level schematic block diagram of the interconnections between a system controller, the field modules and the DUTs according to one embodiment of the present invention.

Figure 3 is a detailed schematic block diagram of the field module and its interconnection with the system controller and the DUTs according to an embodiment of the present invention.

FIG. 4 is a detailed schematic block diagram of one of the instantiated FPGA tester blocks in FIG. 2 according to an embodiment of the present invention.

Figure 5 is a high level view of an exemplary method of testing a DUT according to an embodiment of the present invention flow chart.

FIG. 6 is a continuation of FIG. 5 and is a flowchart of an exemplary method of testing a DUT in the bypass mode in one embodiment of the invention.

7 is a continuation of FIG. 5 and is a flowchart of an exemplary method of testing a DUT in the hardware accelerator pattern generator mode in one embodiment of the invention.

8 is a continuation of FIG. 5 and is a flowchart of an exemplary method of testing a DUT in the hardware accelerator memory mode in one embodiment of the invention.

9 is a continuation of FIG. 5 and is a flowchart of an exemplary method of testing a DUT in the hardware accelerator packet builder mode in one embodiment of the invention.

FIG. 10 illustrates a manner in which an HBA containing protocol converter IP can be used to connect an FPGA to a DUT with a protocol different from that for which the FPGA is programmed, according to one embodiment of the present invention. A protocol to communicate.

FIG. 11 illustrates a manner in which a sandwich board containing one or more HBAs may be used to interface between an FPGA and a DUT, according to an embodiment of the present invention.

Figure 12 illustrates an exemplary tester configuration in which each DUT is connected with a corresponding accelerator engine, according to one embodiment of the present invention.

FIG. 13 depicts a flowchart 1300 of an exemplary procedure for testing a DUT with a different protocol than that implemented on an FPGA in a tester system, according to an embodiment of the present invention. to communicate.

In these drawings, elements with the same names have the same or similar functions.

Detailed Description of the Preferred Embodiment

Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these preferred embodiments, it should be understood that they are not intended to The present invention is limited to these examples. On the contrary, the invention is intended to cover alternatives, modifications, and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.

Symbols and Terminology Section

Portions of this detailed description are presented in the form of programs, logic blocks, processes, and other symbolic representations of operations on data bits within a computer's memory. These descriptions and representations are the means commonly used by those skilled in the data processing arts to effectively convey the substance of their work to others skilled in the art. In this application, a program, logic block, process, etc. is considered to be a self-consistent sequence of steps or instructions leading to a desired result. The steps include physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, optical or quantum signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system.

It should be borne in mind, however, that all of these and similar terms are to be to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it will be apparent from this discussion that it should be understood that references to terms such as "test," "communication," "coupling," "conversion," "relay," or the like are used throughout this application The discussion of such terms refers to the operations and processes of a computer system or similar electronic computing device that convert data represented as physical (electronic) quantities in the registers and memories of the computer system into Other data similarly expressed as physical quantities in such computer system memory or temporary registers or other such information storage, transmission or display devices.

The following description provides a discussion of computers and other devices that may include one or more modules. As used herein, terms such as "module" or "box" may be understood to refer to software, Firmware, hardware and/or various combinations thereof. Note that these blocks and modules are exemplary. These blocks or modules can be combined, integrated, separated, and/or repeated to support various applications. Furthermore, a function described herein as being performed at a particular module or block may be performed at one or more other modules or blocks and/or by one or more other means, instead of or in addition to out of the functionality that is performed at the specific module or block of the description. Furthermore, implementation of such blocks or modules may span multiple devices and/or other components that may be close to or remote from each other. Additionally, the modules or blocks may be removed from one device and added to another device, and/or may be included in both devices. Any software implementation of the present invention may be tangibly embodied in one or more storage media, such as a memory device, a floppy disk, a compact disk (CD), a digital versatile disk (DVD), or a storable computer code in other devices.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of the invention. As used throughout this disclosure, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Thus, for example, reference herein to "a module" includes a plurality of such modules, a single module, and equivalents known to those skilled in the art.

Test architecture with multiple FPGA-based hardware accelerator blocks for independent testing of multiple DUTs

Test throughput can often be increased in a number of ways. One approach to reducing DUT test time is to offload functions previously performed in software on a general-purpose tester processor to hardware accelerators implemented on FPGA devices. Another approach is by increasing the number and types of devices under test (DUTs) that can be tested on popular hardware and time constraints, for example, by configuring the hardware so that many different types of protocols are supported, such as DUTs for PCIe, SATA, etc. can be tested using this same hardware without replacing or reconfiguring any hardware components. Embodiments of the present invention address this to improve test efficiency in the hardware of the automated test equipment.

FIG. 2 is an exemplary high-level block diagram of an automatic test equipment (ATE) device 200 in which a tester processor is connected to the device under test through an FPGA device with built-in functional modules according to an embodiment of the present invention. device (DUT). In one embodiment, ATE equipment 200 may be implemented within any test system capable of testing multiple DUTs simultaneously.

Referring to FIG. 2, an ATE apparatus 200 for more efficiently testing semiconductor devices according to an embodiment of the present invention includes a system controller 201, a network connecting the system controller to the field module boards 230A-230N. Road switch 202, FPGA devices 211A-211M including instantiated FPGA tester blocks 210A-210N, memory module modules 240A-240M each of which are connected to the FPGAs one of the devices 211A-211M, and the devices under test (DUTs) 220A-220N, wherein each device under test 220A-220N is connected to one of the instantiated FPGA tester modules 210A-210N .

In one embodiment, the system controller 201 may be a computer system, such as a personal computer (PC), which provides a user interface for the user of the ATE to load the test programs and be connected to the The DUTs of the ATE 200 perform the tests. Verigy's Stylus operating system is an example of test software commonly used during device testing. It provides the user with a graphical user interface from which the tests can be configured and controlled. It can also include functions for controlling the test process, controlling the state of the test program, determining which test program is running, and recording test results and other data related to the test process. In one embodiment, the system controller can be connected to and control up to 512 DUTs.

In one embodiment, the system controller 201 may be connected to the field module boards 230A- 230N through a network switch such as an Ethernet switch. In other embodiments, the network switch may be compatible with different protocols such as Fiber Channel, 802.11 or ATM.

In one embodiment, each of the field module boards 230A-230N may be a separate stand-alone board that is used for evaluation and development purposes, attached to a custom built-in load A board fixture on which the DUTs 220A-220N are loaded; and attached to the system controller 201, from which it receives the test programs. In other embodiments, the field module boards may be implemented as plug-in expansion cards or as daughter boards directly plugged into the chassis of the system controller 201 .

In one embodiment, the field module boards 230A- 230N may each include at least one tester processor 204 and at least one FPGA device. The tester processor 204 and the FPGA devices 211A-211M on the field module board execute the test methods for each test case according to the test program instructions received from the system controller 201 . In one embodiment, the tester processor may be a commercially available Intel 8086 CPU or any other well-known processor. Additionally, the tester processor can run on an Ubuntu OS x64 operating system and execute the Core software, allowing it to communicate with the Stylus software running on the system controller to execute the test methods. The tester processor 204 controls the FPGA devices on the field module and the DUTs connected to the field module based on the test program received from the system controller.

The tester processor 204 is connected to and communicates with the FPGA devices through the bus bar 212 . In one embodiment, the tester processor 204 communicates with each of the FPGA devices 211A-211M through a separate dedicated bus. In one embodiment, the tester processor 204 can transparently control the testing of the DUTs 220A- 220N through the FPGAs with minimal processing functionality allocated to the FPGA devices. In such an implementation, the FPGA devices act as pass-through devices. In this embodiment, since all the commands and data generated by the tester processor need to be sent to the FPGA devices through the bus, the data traffic capacity of the bus 212 will be quickly run out. In other embodiments, the tester processor 204 may distribute the processing load to the FPGA devices by distributing functions to control the testing of the DUTs. In these embodiments, the traffic on bus 212 is reduced because the FPGA devices can generate their own commands and data.

In one embodiment, each of the FPGA devices 211A-211M is connected to its Own dedicated memory block 240A-240M. These memory blocks may be used, inter alia, to store the test pattern data to be written out to the DUTs. In one embodiment, each of the FPGA devices may include two instantiated FPGA tester blocks 210A-210B with functional modules for performing functions including protocol engines and hardware The implementation of the accelerator, as will be described further in this paper. Memory blocks 240A-240M may each contain one or more memory modules, wherein each memory module within the memory block may be dedicated to one of the instantiated FPGA tester blocks 210A-210B. one or more. Accordingly, each of the instantiated FPGA tester blocks 210A-210B may be connected to its own dedicated memory module within the memory module 240A. In another embodiment, instantiated FPGA tester modules 210A and 210B may share one of the memory modules within memory module 240A.

Additionally, each of the DUTs 220A-220N in the system can be connected to a dedicated instantiated FPGA tester module 210A-210N in a "tester per DUT" configuration, each of which Each DUT has its own tester block. This allows testing to be performed on each DUT individually. The hardware resources in this configuration are designed in a way to support individual DUTs with a minimum of hardware sharing. This configuration also allows many DUTs to be tested in parallel, where each DUT can be connected to its own dedicated FPGA tester block and execute a different test program. In one implementation, two or more DUTs may also be connected to each FPGA tester block (eg, block 210A).

The architecture of the embodiment of the invention depicted in FIG. 2 has several advantages. First, it allows programming of protocol modules directly on the instantiated FPGA tester blocks in the FPGA devices. The instantiated tester blocks can be configured to communicate with the DUTs using any protocol supported by the DUTs. Thus, if DUTs with support for a different protocol need to be tested, they can be connected to the same system and the FPGAs can be reprogrammed to support the associated protocol. Therefore, an ATE subject can be easily configured to test DUTs that support many different types of protocols.

In one embodiment, new protocols can be downloaded and installed directly from cache on the system controller 201 via a simple bitstream download without any type of hardware interaction. An FPGA will typically include a configurable interface core (or IP core) that can be programmed to provide the functionality of one or more protocol-based interfaces to a DUT and can be programmed to interface with the DUT. For example, the FPGAs 211A-211M in the ATE equipment 200 will include an interface core that can be configured with the PCIe protocol to initially test PCIe devices, then reconfigured via a software download to Test the SATA device. Also, if a new protocol is released, the FPGAs can be easily configured with that protocol via bitstream download. Finally, if a non-standard protocol needs to be implemented, the FPGAs can still be configured to implement such a protocol.

In another embodiment, the FPGAs 211A-211M can be configured to execute more than one communication protocol, wherein these protocols can also be downloaded from the system controller 201 and configured through software. In other words, each FPGA implements custom firmware and software images to implement the functionality of one or more PC-based testers in a single chip. The required electrical and protocol-based signaling is provided by the on-chip IP cores in the FPGAs. As mentioned above, each FPGA can be programmed with pre-verified interfaces or IP cores. This ensures compliance and compatibility with a given interface standard. The programmable nature of the FPGA is exploited to optimize flexibility, cost, parallelism and scalability for storage test applications from SSDs, HDDs and other protocol-based storage devices.

For example, the instantiated FPGA tester block 210A can be configured to implement the PCIe protocol, while the instantiated FPGA tester block 210B can be configured to implement the SATA protocol. This allows the tester hardware to simultaneously test DUTs that support different protocols. FPGA 211A can now be connected to test a DUT that supports both PCIe and SATA protocols. Alternatively, it can be connected to test two different DUTs, one DUT supporting the PCIe protocol and the other DUT supporting the SATA protocol, where each instantiated functional module (e.g., 210A, 210B) is configured with a protocol to test the respective DUT to which it is connected.

In one embodiment, the interface or IP core in the FPGA is available from a third party supplier, but some customization may be required to be compatible with the embodiments described herein. In one embodiment, the interface core provides two functions: a) packaging memory commands into a standard protocol for transmission over a physical channel; and 2) being the electrical signal generator and receiver.

Another major advantage of the architecture shown in FIG. 2 is that it reduces the processing load on the tester processor 204 by distributing the command and test pattern generation functions to FPGA devices, where each DUT has A dedicated FPGA module that executes the test program specific to it. For example, instantiated FPGA tester block 210A is connected to DUT 220A and executes a test program specific to DUT 220A. The hardware resources in this configuration are designed in a way to support individual DUTs with a minimum of hardware sharing. This "tester per DUT" configuration also allows each processor to test more DUTs and more DUTs can be tested in parallel. In addition, utilizing the FPGAs, which can generate their own commands and test patterns in certain modes, after connecting the tester processor to other hardware components including the FPGA device, device power supply (DPS) and DUT The bandwidth requirements on bus 212 are also reduced. Thus, more DUTs can be tested simultaneously than with existing assemblies.

Figure 3 provides a more detailed schematic block diagram of a field module and its interconnection with the system controller and the DUTs, according to an embodiment of the present invention. Referring to FIG. 3, in one embodiment, the field modules of the ATE equipment may be mechanically assembled to tester slices 340A-340N, wherein each tester slice includes at least one field module. In some exemplary embodiments, each tester slice may include two field modules and two device power supply boards. For example, tester slice 340A of FIG. 3 includes field modules 310A and 310B and device power supply boards 332A and 332B. However, there is no limit to the number of device power supply boards or field modules that can be assembled onto a tester slice. The tester slice 340 is connected to the system controller 301 through the network switch 302 . System controller 301 and network switch 302 perform the same functions as elements 201 and 202 in FIG. 2, respectively. The network switch 302 can be connected to each of the field modules with a 32-bit wide bus.

Each of the device power supply boards 332A-332B can be controlled from one of the field modules 310A-310B. The software executing on the tester processor 304 can be configured to assign a device power supply to a specific field module. For example, in one embodiment, the field modules 310A-310B and the device power supplies 332A-332B are configured to use a high-speed serial protocol such as Peripheral Component Interconnect Express (PCIe), Serial AT Attach (SATA) or Serial Attached SCSI (SAS) to communicate with each other.

In one embodiment, each field module is configured with two FPGAs as shown in FIG. 3 . Each of the FPGAs 316 and 318 in the embodiment of FIG. 3 is controlled by the tester processor 304 and performs similar functions to FPGAs 211A-211M in FIG. 2 . The tester processor 304 may communicate with each of the FPGAs using an 8-lane high speed serial protocol interface, such as using PCIe, as indicated by system buses 330 and 332 in FIG. 3 . In other embodiments, the processor 304 of the tester can also communicate with the FPGAs using a different high-speed serial protocol, such as Serial AT Attached (SATA) or Serial Attached SCSI (SAS).

FPGAs 316 and 318 are connected to memory modules 308 and 304, respectively, which perform functions similar to memory blocks 240A-240N in FIG. 2 . The memory modules are coupled to and controllable by both the FPGA devices and the tester processor 304 .

FPGAs 316 and 318 may be connected to the DUTs 372A-372M on the load board 380 through bus bars 352 and 354, respectively. The load board 380 is a physical wire that allows a common high speed connection at the field module side independent of the protocol used on the bus bars 352 and 354 to communicate with the DUTs . However, on the DUT side, the load board needs to be designed with connectors specific to the protocol being used by the DUT.

In one embodiment of the invention, the DUTs 372A-372M are loaded on a load board 380, and the load board 380 is placed in a thermal test chamber 390 for testing. The DUTs 372A-372M and the load board 380 receive power from the device power supplies 332A and 332B.

The number of DUTs that can be connected to each FPGA depends on the number of transceivers in the FPGA and the number of I/O channels required by each DUT. In one embodiment, FPGAs 316 and 318 may each contain 32 high-speed transceivers, and buses 352 and 354 may each be 32 bits wide, however, depending on the application, more or fewer may be implemented . For example, if each DUT requires 8 I/O channels, only 4 DUTs can be connected to each FPGA in such a system.

FIG. 4 is a detailed schematic block diagram of an instantiated FPGA tester block in FIG. 2 according to an embodiment of the present invention. Referring to FIG. 4 , the instantiated FPGA tester block 410 is connected to the tester processor through the PCIe upstream port 270 and to the DUT through the PCIe downstream port 480 .

The instantiated FPGA block 410 may include a protocol engine module 430 , a logic block module 450 , and a hardware accelerator block 440 . The hardware accelerator block 440 may further include a memory control module 444 , a comparator module 446 , a packet builder module 445 , and an algorithm pattern generator (APG) module 443 .

In one embodiment, the logic block module 450 includes: decoding logic to decode the commands from the tester processor; routing logic to route all incoming commands from the tester processor 304 and data and routing of the data generated by the FPGA devices to the appropriate modules; and arbitration logic to arbitrate between the various communication paths within the instantiated FPGA tester block 410.

In one implementation, the communication protocol used to communicate between the tester processor and the DUTs is preferably reconfigurable. The protocol engine in this implementation is programmed directly into the protocol engine module 430 of the instantiated FPGA tester block 410 . The instantiated FPGA tester block 410 can thus be configured to communicate with the DUTs using any protocol supported by the DUTs. For example, the above-mentioned pre-verified interface or IP core can be programmed into the protocol engine module 430 . This ensures compliance and compatibility according to a given interface standard. In addition, the IP core enables flexibility for the tester because the IP core enables software-based Body interface changes. Embodiments provide the ability to test multiple types of DUTs independent of hardware. With this interface flexibility, new interfaces can be loaded into the IP core of a programmable chip.

For example, in one embodiment, for storage/SSD/HDD, each FPGA includes a configurable IC that is connected to an SSD and can be programmed to communicate via a storage-specific interface such as SATA or SAS Provides storage-based models. In one embodiment, for RF modules, an FPGA includes a configurable IC, wherein the configurable interface core is programmed to provide USB or PCIe interface connections using current RF modules.

In one embodiment, an FPGA may be an SSD or RF module-based tester that interfaces with a DUT or module using protocol-based communication. In one embodiment, the configurable interface core can be programmed to provide any standardized protocol-based communication interface. For example, in one embodiment, in the case of an SSD module-based test, the interface core can be programmed to provide communication interfaces based on standardized protocols, such as SATA, SAS, and the like. In one embodiment, the interface core may be programmed to provide standardized protocol-based communication interfaces such as USB, PCIe, etc. in the case of an RF module based tester. In one embodiment, in the case of a module with an optical interconnect, the interface core may be programmed to provide standardized protocol-based communication used to communicate with the module over an optical interconnect.

Therefore, from an electrical point of view, the FPGAs utilize a configurable IP core. By software programming the programmable chip resources of an FPGA, a given IP core can be easily reprogrammed and replaced with another IP core without physically replacing the FPGA chip or other hardware components. For example, if a given FPGA-based tester currently supports SATA, all that is required to enable it to connect to a Fiber Channel DUT is to reprogram the FPGA to use a Fiber Channel IP core instead of a SATA-specific Compatible with the existing IP core.

In one embodiment, the protocols may be high-speed serial protocols, including but not limited to SATA, SAS, or PCIe, among others. The new or modified protocol can be downloaded and installed directly On the FPGAs, patterns are downloaded from the system controller through the tester processor via a simple bit stream. Likewise, if a new protocol is released, the FPGAs can easily be reconfigured with that protocol via a software download.

In FIG. 4, if the DUT coupled to the PCIe downstream port 480 is a PCIe device, the instantiated bit file containing the PCIe protocol can be downloaded through the PCIe upstream port 470 and installed on In the IP core on the protocol engine module 430 . Each FPGA device 316 or 318 may include one or more instantiated FPGA tester blocks, and thus one or more protocol engine modules. The number of protocol engine modules that any one FPGA device can support is limited only by the size and gate count of the FPGA.

In one embodiment of the invention, each of the protocol engine modules in an FPGA device can be configured with a different communication protocol. Therefore, an FPGA device can be connected to test multiple DUTs, each supporting different communication protocols simultaneously. Alternatively, an FPGA device can be connected to a single DUT supporting multiple protocols and simultaneously test all modules running on the device. For example, if an FPGA is configured to run both PCIe and SATA protocols, it can be connected to test a DUT that supports both PCIe and SATA protocols. Alternatively, it can be connected to test two different DUTs, one supporting the PCIe protocol and the other supporting the SATA protocol.

The hardware accelerator module 440 of FIG. 4 can be used to accelerate certain functions on the FPGA hardware that may not be available in software on the tester processor. The hardware accelerator block 440 can provide initial test pattern data used in testing the DUT. It may also contain functionality that can generate certain commands that are used to control the DUT tests. To generate test pattern data, the accelerator block 440 uses the algorithmic pattern generator module 443 .

The hardware accelerator block 440 can use a comparator module 446 to compare the data read from the DUTs with the data written to the DUTs in a previous cycle. The comparator module 446 includes the ability to flag the tester processor 304 as a mismatch to identify non-compliant devices function. More specifically, the comparator module 446 may include an error counter that records the mismatches and communicates them to the tester processor 304 .

The hardware accelerator block 440 can be connected to a local memory module 420 . Memory module 420 performs a similar function to one of the memory modules in any of the memory blocks 240A-240M. The memory module 420 can be controlled by both the hardware accelerator block 440 and the tester processor 304 . The tester processor 304 can control the local memory module 420 and write the initial test pattern data therein.

The memory module 420 stores the test pattern data to be written into the DUTs, and the hardware accelerator block 440 accesses it to compare the stored data with the data from the DUTs after the write cycle. The data read by the DUT is compared. The local memory module 420 can also be used to record faults. The memory module will store a log file containing a record of all failures experienced by the DUTs during testing. In one embodiment, the accelerator module 440 has a dedicated local memory module 420 that cannot be accessed by any other instantiated FPGA tester block. In another embodiment, the local memory module block 420 is shared with a hardware accelerator block in another instantiated FPGA tester block.

The hardware accelerator block 440 may further include a memory control module 444 . The memory control module 444 interacts with the memory module 420 and controls read and write access to the memory module 420 . Finally, the hardware accelerator block 440 includes a packet builder module 445 . The hardware accelerator block uses the builder module in some modes to construct packets to be written to the DUTs, which include header/command data and test pattern data.

In some embodiments, the hardware accelerator module 440 may be programmed by the tester processor 304 to operate in one of several modes of hardware acceleration. In bypass mode, the hardware accelerator is bypassed and the tester processor 304 sends commands and test data via path 472 directly to the DUT. In hardware accelerator pattern generator mode, test pattern data is generated by the APG module 443 and the commands are generated by the tester processor 304. The test packets are sent to the DUT via path 474 . In hardware accelerator memory mode, the test pattern data is accessed from the local memory module 420 while the commands are generated by the tester processor 304 . The test pattern data is sent to the DUT via path 476 . Arrangement routing logic 482 is required to arbitrate between paths 472, 474 and 476 to control data flow to the DUT.

The field module may include a universal connector 481 . Because the protocol engine module 430 can be configured to implement any number of various communication protocols, a common high-speed connector 481 is required on the field module. Thus, if the protocol implemented on the protocol engine module 430 needs to be changed, no concomitant physical modification on the field module is required. The field module connects to the DUT using a load board 380 that can be connected to the universal connector at the field module end, but is specific to the protocol being implemented at the DUT end. DUTs that support different protocols will require different configurations. Therefore, if the protocol is reprogrammed to accommodate a DUT that requires a different configuration, the load board will need to be disconnected and replaced.

FIG. 5 depicts a flowchart 500 of an exemplary procedure for testing a DUT, according to an embodiment of the present invention. However, the invention is not limited to the description provided by this flowchart 500 . Rather, other functional flow diagrams are within the scope and spirit of the present invention, as will be apparent to those skilled in the art to which the present invention pertains, in light of the teachings provided herein. The flowchart 500 will continue to be described with reference to the exemplary embodiments described above with reference to FIGS. 2 , 3 and 4 , although the method is not limited to those embodiments.

Referring now to FIG. 5, at block 502, the user initiates setup and loads the test program into the system controller. Startup setup may include selecting one or more protocols from a library of available protocols to be configured on the FPGA devices in the ATE equipment 200 . The protocols are cached as files on the system controller 301 and can be downloaded as bit files to the FPGAs. The user may select the protocol from a list of available distributions through a graphical user interface. in an agreement to be one Before an option can be used, it must first be built, tested, and incorporated into a release. The published FPGA configuration contains, among other things, restrictions on the supported protocols and the number of transceivers that can be used to interface with the DUT. The distribution repository is then made available to users through a graphical user interface.

At block 502, the user also loads the test program into the system controller 301 through the GUI. The test program defines all parameters of the tests that will need to be performed on the DUTs. At block 504, the system controller sends commands to the tester processor on the field module 310A. This step includes transferring the bitfiles of the protocol engines to be programmed on the FPGAs. The system controller may include routing logic to route commands for a particular test program to the tester processor connected to the DUT controlled by the test program.

At block 506, after receiving instructions from the system controller, the tester processor 304 may determine the hardware accelerated mode for performing the tests on the DUTs connected to the field module 310A.

In one embodiment, the tester processor 304 can operate in one of four different hardware accelerated modes. Each functional mode is configured to allocate functions for generating commands and test data between the tester processor 304 and the FPGAs 316 and 318 . In one embodiment, the tester processor can be programmed to operate in a bypass mode, wherein all commands and test data for testing the DUTs are generated by the tester processor 304, and the FPGAs 316 and 318 are bypassed. In another embodiment, the tester processor 304 can be programmed to operate in a hardware accelerator pattern generator mode, wherein the pseudorandom data to be used in the testing of the DUTs is generated by the FPGAs 316 and 318, and the comparison is also done by the FPGAs, but the tester processor handles the command generation.

In yet another embodiment, the tester processor 304 may be programmed to operate in a hardware accelerator memory mode, wherein the test pattern is pre-programmed by the tester processor during initial setup. Write to the memory module connected to each FPGA 316 and 318 first. In this mode, the FPGAs access the dedicated memory device to retrieve the test data to be written to the DUTs, read the test data from the DUTs, and convert the read data to is compared with the data written to the memory device. In this mode, each of the FPGAs controls the memory device in response to read and write operations from the DUTs. However, in this mode, the tester processor is still responsible for the command generation. In yet another embodiment, the tester processor 304 can be programmed to operate in a hardware accelerator packet builder mode, wherein the data and basic read/write/compare commands are handled by the FPGAs 316 and 318 to generate.

At block 508, the tester processor branches to the mode under which the test is to be performed.

It should be noted that the FPGA 1002 of FIG. 10 can be programmed using any of the above four functional modes, i.e., the bypass mode, the hardware accelerator pattern generator mode, the hardware accelerator memory mode and the hardware accelerator packet builder mode.

FIG. 6 depicts a flowchart 600 of an exemplary procedure for testing a DUT in the bypass mode, according to an embodiment of the present invention. However, the invention is not limited to the description provided by this flowchart 600 . Rather, other functional flow diagrams are within the scope and spirit of the present invention, as will be apparent to those skilled in the art to which the present invention pertains, in light of the teachings provided herein. The flowchart 600 will be described below with continued reference to the exemplary embodiments described above with reference to FIGS. 2 , 3 and 4 , although the method is not limited to those embodiments.

Referring now to FIG. 6, in bypass mode, at block 602 the tester processor 304 generates commands and packet headers for the test packets to be routed to the DUTs. At block 604, the tester program also generates the test pattern data for the test packets to be routed to the DUTs. In this mode, there is no hardware acceleration since the tester processor generates its own commands and test data.

At block 606, the tester processor communicates with instantiated FPGA block 410 and downstream port 480 to route the test packets containing the test pattern data to the DUTs. The bypass mode is a pass-through mode in which, with some limited exceptions, the commands and data are passed transparently through the instantiated FPGA module 410 directly to the DUTs. In bypass mode, the tester processor 304 directly controls the DUTs. Although the instantiated FPGA block may include logic for routing the data packets to the downstream port, it does not participate in the command generation (also referred to as "signalling") or the data generation.

At block 608 , the tester processor 304 communicates with downstream port 480 to initiate a read operation from the DUTs, reading the data previously written to the DUTs at block 606 . At block 610 , the tester processor compares the data read from the DUTs with the data written at block 606 . If there is any mismatch between the written data at block 606 and the read data at block 610 , the tester processor 304 sends a flag to the system controller 301 at block 612 . The controller will then flag the mismatch to the consumer.

In bypass mode, the tester processor 304 is limited in the number of DUTs it can support since it can quickly maximize its processing capacity from generating all commands and test data for those DUTs. Moreover, the number of DUTs that can be supported by field module 310A is further limited by the bandwidth limitations on system buses 330 and 332 . In bypass mode, the bandwidth of buses 330 and 332 is depleted relatively quickly due to the large amount of data being sent from the tester processor 304 to the DUTs. Therefore, other modes with more hardware acceleration are provided in which the FPGA devices have more functions to generate test data and commands.

FIG. 7 depicts a flow chart 700 of an exemplary procedure for testing a DUT in the hardware accelerator pattern generator mode, according to an embodiment of the present invention. However, the invention is not limited to the description provided by this flowchart 700 . Rather, from the teachings provided herein, it will be apparent to those skilled in the art to which the present invention pertains that other functional flow diagrams are within the scope and spirit of the present invention Inside.

The flowchart 700 will be described below with continued reference to the exemplary embodiments described above with reference to FIGS. 2 , 3 and 4 , although the method is not limited to those embodiments. Referring now to FIG. 7, a hardware acceleration method is shown in which the FPGA devices offload data generation functions to relieve the processing load on the tester processor 304 and the data load on system buses 330 and 332 . At block 702 of the hardware accelerator pattern generator mode, the tester processor 304 generates commands and packet headers for the packets to be routed to the DUTs. The tester program retains this functionality for signaling in this mode. The algorithm pattern generator module 443 within the hardware accelerator block 440 generates the virtual random test data to be written to the DUTs at block 704 . The logic block module 450 includes functionality for routing the generated data and adding it to the packets to be written out to the DUTs.

This mode is considered "hardware accelerated" because the function of generating data is performed in hardware by the algorithm pattern generator of the FPGA device faster than it is performed in software by the tester processor Much faster. Likewise, the "tester per DUT" architecture allows the DUT to be directly connected to its own dedicated instantiated FPGA tester block that generates test data for the DUT as shown in Figure 4. There is a significant increase in bandwidth compared to the bypass mode, because in the bypass mode the tester processor 304 provides all commands and data to the system buses 330 and 332 DUT. By sharing the FPGA devices in the data generation function, the system buses 330 and 332 are freed so commands can be sent to the FPGAs at a faster rate than in bypass mode. Also, for devices that require multiple test iterations, such as solid-state drives, have a dedicated data path through the instantiated FPGA tester block, as opposed to the case where the resources of the tester processor are shared by several DUTs , can greatly speed up the test speed. It also allows the DUT to run at near full capacity because it does not have to wait for the tester processor to allocate processing resources to it.

In one embodiment, the algorithmic pattern generator module 443 can be programmed to generate data dynamically. The APG module can generate incremental patterns, pseudo-random patterns, or some type of constant patterns. The APG module can also have specific gating functions to generate test patterns with stripes, diagonal stripes or alternating patterns. In one embodiment, the APG module can be used to generate test patterns using finite state machines, counters or linear feedback shift registers, and the like. In some embodiments, the APG module can be provided with a starting seed as an initial value to generate more complex patterns.

At step 706, the instantiated FPGA block 410 communicates with the downstream port 480 to route the test pattern data to the DUTs according to the commands and packet headers generated by the tester processor. At step 708, the instantiated FPGA block 410 communicates with the downstream port to read the test pattern data from the DUTs according to the commands generated by the tester processor. At block 710, the comparator module 446 of the hardware accelerator block 440 is then used to compare the read data with the data written to the DUTs. The APG module 443 is designed in such a way that the comparator module can use the same parameters used to generate the pseudorandom data to perform read operations on it, and receive data written to the DUTs at block 704 of the same information. The APG module 443 dynamically regenerates the data written into the DUTs and sends it to the comparator module 446 . At block 712, any mismatch is either recorded on the memory module 420 by the memory control module 444 or communicated to the tester processor by the instantiated FPGA block. After receiving the error log, the tester processor then flags a mismatch to the system controller at block 714 .

FIG. 8 depicts a flowchart 800 of an exemplary procedure for testing a DUT in the hardware accelerator memory mode, according to an embodiment of the present invention. However, the invention is not limited to the description provided by this flowchart 800 . Rather, other functional flow diagrams are within the scope and spirit of the present invention, as will be apparent to those skilled in the art to which the present invention pertains, in light of the teachings provided herein.

The flowchart 800 will continue to be described with reference to the exemplary embodiments described above with reference to FIGS. 2 , 3 and 4 , although the method is not limited to those embodiments.

Referring now to FIG. 8 , a hardware acceleration method is shown in which the FPGA devices share data generation functions to offload the processing load on the tester processor 304 and the data load on system buses 330 and 332 . In contrast to the hardware accelerator pattern generator mode, in the hardware accelerator memory mode, the instantiated FPGA tester block accesses from local memory module 420 the data to be written to the DUTs. information instead of using the APG mod 443.

At block 800 of the emulator model, the tester processor 304 generates commands and packet headers for the packets to be routed to the DUTs. The tester program retains the functionality for signaling in this mode. At block 802, the tester processor initializes the local memory module 420 of the instantiated FPGA tester block 410 with test patterns to be written out to the DUTs. An advantage of the hardware accelerator memory mode is that, in contrast to the pseudorandom data generated by the APG module 443 in the hardware accelerator pattern generator mode, the test data generated by the tester processor Patterns can constitute truly random data. Both the tester processor and the instantiated FPGA tester block have read and write access to the local memory module 420 . However, the tester processor only accesses memory module 420 during initial setup. During the accelerator mode, the tester processor will not access the memory module because of the additional processing load on the tester processor 304 and the additional data load on the system buses 330 and 332 This acceleration is greatly reduced.

At block 804, the instantiated FPGA tester block reads from the memory module 420 the test pattern data to be routed to the DUTs. Because the memory module 420 is dedicated to the FPGA tester block or shared with only one other FPGA tester block, there is a high bandwidth connection between the two, enabling fast read operations. The logic block module 450 includes functionality for routing the generated data and adding it to the packets to be written out to the DUTs.

After the data has been added to the packets, at block 806, the instantiated FPGA block communicates with the downstream port 480 to send the packets according to the commands and packet headers generated by the tester processor. Test pattern data is scheduled to be routed to the DUTs. At step 808, the instantiated FPGA block 410 communicates with the downstream port to read the test pattern data from the DUTs according to the commands generated by the tester processor. At block 810, the comparator module 446 of the hardware accelerator block 440 is then used to compare the read data with the data written to the DUTs. At block 812, any mismatch is either recorded on memory module 420 or communicated to the tester processor by the instantiated FPGA block. After receiving the error log, the tester processor then flags a mismatch to the system controller at block 814 .

FIG. 9 depicts a flowchart 900 of an exemplary procedure for testing a DUT in the hardware accelerator packet builder mode, according to an embodiment of the present invention. However, the invention is not limited to the description provided by the flowchart 900 . Rather, other functional flow diagrams are within the scope and spirit of the present invention, as will be apparent to those skilled in the art to which the present invention pertains, in light of the teachings provided herein.

The flowchart 900 will be described with continued reference to the exemplary embodiments described above with reference to FIGS. 2 , 3 and 4 , although the method is not limited to those embodiments.

Referring now to FIG. 9, a hardware acceleration method is shown in which the FPGA devices offload data and command generation functions to offload the processing load on the tester processor 304 and the data on system buses 330 and 332. load. This mode is also known as "Full Acceleration" mode because most of the control for performing the device tests is transferred to the FPGA devices and the tester processor 304 only performs operations other than reading and writing and Commands other than comparison retain control.

At block 902 of the hardware accelerator package builder mode, the tester processor 304 generates commands to be passed to the instantiated FPGA block 410 to generate its own package. In this mode, the tester processor only retains the functionality of the non-read/write/compare commands. Functions of commands such as read, write, and compare operations are passed to the instantiated FPGA modules. At block 904, the packet builder module 445 of the instantiated FPGA tester block constructs a packet with header and command information to transmit to the DUTs. These packets include at least the command type, the Block address and the test pattern data.

The algorithm pattern generator module 443 within the hardware accelerator block 440 generates the virtual random test data to be written to the DUTs at block 906 . The logic block module 450 includes functionality to route and consolidate the data and commands generated by the instantiated FPGA blocks into packets to be written out to the DUTs.

At block 908, the instantiated FPGA block communicates with the downstream port 480 to route the test pattern data to the DUTs. At step 910, the instantiated FPGA block 410 communicates with the downstream port to read the test pattern data from the DUTs. At block 912, the comparator module 446 of the hardware accelerator block 440 is then used to compare the read data with the data written to the DUTs. At block 914, any mismatch is either recorded on memory module 420 or communicated to the tester processor by the instantiated FPGA block. After receiving the error log, the tester processor then flags a mismatch to the system controller at block 916 .

Using host bus adapters in automated test equipment to provide protocol flexibility

As described above, new protocols for communicating with the DUTs can be downloaded and installed directly from a cache on a system controller via a simple bitstream download and installed directly on a on the FPGA of the tester system. The configurable interface core (or IP core) in an FPGA can be programmed to provide functionality for one or more protocol-based interfaces to communicate with a DUT. Each FPGA implements custom firmware and software images to implement the functionality of one or more PC-based testers in a single chip. The required electrical and protocol-based signaling is provided by the on-chip IP cores in the FPGAs. Each FPGA can be programmed with pre-verified interfaces or IP cores. This ensures compliance and compatibility with a given interface standard.

It should be noted that some conventional testers only allow a single IP core to be programmed onto an FPGA, although in some cases multiple different types of cores can be programmed onto an FPGA. In other words, the FPGA protocol engine modules of some test systems (e.g., the module of FIG. 4 group 430) can only support a single IP core, and if a different third-party protocol IP core needs to be programmed into the FPGA, this will require a redesign of the FPGA. Also, the IP core may contain a third-party IP protocol, which may be proprietary and cannot be modified or copied. This can cause delays in development and test environments. Reprogramming an FPGA can sometimes be time consuming, slowing down the development or testing process.

Therefore, in some embodiments, an FPGA with a configurable IP core is used in conjunction with a host bus adapter (HBA) to speed up testing in a development or test environment. Instead of downloading a new bitstream into the FPGA to reprogram it, an HBA is used to convert the traffic from the FPGA to a DUT-specific protocol. For example, the FPGA may initially be programmed to communicate using the PCIe protocol. The HBA can be configured to convert incoming PCIe signals to SATA or SAS signals for testing a SATA or SAS DUT, respectively. Alternatively, the HBA can be configured to convert incoming PCIe signals to some third-party proprietary protocol that can only be "thrown" into the tester system via an HBA.

Figure 10 illustrates the manner in which an HBA containing protocol converter IP can be used to connect an FPGA to a DUT different from the FPGA for which the FPGA is programmed, according to an embodiment of the present invention. A protocol of protocols to communicate. Embodiments of the present invention invoke the use of an HBA 1008 that includes a protocol converter IP 1004 (eg, including a proprietary third-party protocol) to provide protocol flexibility. The protocol converter IP 1004 converts incoming traffic from one protocol before being input into the input HBA interface 1040 to a different protocol being output on the HBA output interface 1042 .

In one embodiment, the HBA 1008 with the protocol converter IP 1004 is used in conjunction with a hardware accelerator and IP core 1010 on the FPGA 1002 to test the DUTs supporting different protocols. In one embodiment, the hardware accelerator (eg, the hardware accelerator module 440 of FIG. 4 ) may be part of the IP core 1010, but in a different implementation, the hardware accelerator may be the same as the The IP core 1010 is separated into a discrete module.

In the embodiment of FIG. 10, instead of reprogramming the FPGA with a protocol that matches the coupled DUT, an HBA is used to convert the traffic from the FPGA to a protocol supported by the DUT. In some test environments, this is required because of the time it takes to reprogram the FPGA. Additionally, there may be instances in a development environment where, for example, the FPGA may not support a particular protocol. Using an HBA avoids the delays associated with re-programming the FPGA or developing FPGA firmware for a protocol that is not currently supported. Furthermore, the IP cores assembled within an FPGA may be proprietary to certain third parties, and using an HBA avoids the need to modify proprietary cores from third parties. For example, the third-party proprietary protocol IP may not be allowed to be integrated into an FPGA, and may need to be used independently as part of an HBA.

In addition, as the time-to-market of tester systems becomes shorter and shorter, there is a need for a flexible tester system that allows a test engineer to quickly switch between DUTs that support different protocols without resetting the tester system. Assemble an FPGA. The embodiment of FIG. 10 provides a tester system that combines an FPGA IP core with a hardware accelerator with an HBA (e.g., with a third-party IP protocol) to test between DUTs supporting various protocols. Switch flexibly. In one embodiment, the FPGA 1002 may receive information from a system controller (e.g., system controller 301 of FIG. 3 ) or a tester processor (e.g., tester processor 304 of FIG. 3 ) through an input interface 1001. input signal. The input interface 1001 may, for example, comprise a high speed serial interface protocol such as PCIe. The hardware accelerator and IP core 1010 implemented on the FPGA can be configured to communicate with a specific protocol, such as PCIe. Thus, the FPGA 1002 can be connected to PCIe DUTs, but cannot communicate with those DUTs that support any other protocol.

In one embodiment, in a test or development environment, if a DUT supporting a non-PCIe protocol needs to be tested, an HBA 1008 with a protocol converter IP 1004 (e.g., with a third-party proprietary protocol) can be Use the same tester to test the DUTs without reprogramming the FPGA. In one embodiment, the HBA 1008 includes a protocol converter 1004 (or third-party IP), The protocol converter 1004 acts as a protocol converter and converts traffic from one protocol to another. Accordingly, the HBA 1008 will convert the incoming signals (eg, PCIe signals) on the interface 1040 to a different protocol supported by the DUT. In this way, the HBA protocol interface 1042 to the DUT 1055 will support the protocol corresponding to the DUT 1055 .

Embodiments of the present invention advantageously allow the FPGA 1002 to quickly implement other protocols using third-party IP without redesigning the FPGA. Embodiments of the present invention also provide a better time to market for the tester system. By allowing the protocol IP cores to be interchangeable, time-to-market for tester systems to customers can be advantageously shortened.

In one embodiment, the tester system may be shipped to a client of the tester system that supports a particular protocol (eg, PCIe). At the client site, without reprogramming the FPGAs in the tester, the customer can simply transfer a third-party IP (or protocol conversion) that supports a different protocol, such as SATA, or some other proprietary protocol Add one HBA to the tester IP) to the tester system. In this way, the client can test DUTs associated with different protocols without reconfiguring the tester system.

In one embodiment, the HBA 1008 may be a bus extender with a switch. In one implementation, the input to the HBA 1008 (via interface 1040) can be a PCIE signal, and the outputs include SAS signals. For example, a PCIe input to a protocol converter IP block 1004 via interface 1040 can be converted to a different protocol such as SAS for testing a SAS DUT 1055 via interface 1042 .

In one embodiment, the HBA 1008 is combined with the accelerator engine of the FPGA (e.g., the hardware accelerator module 440 of FIG. 4 ) to generate traffic for a protocol that is compared by an HBA to a processor The traffic of one of the protocols supported by the combination should have faster throughput. For example, in FIG. 1, the tester processor 101 is used in conjunction with the hardware bus adapter sockets 110A. The tester system of FIG. 1 is inefficient because the HBA is limited to the data generated by the tester processor 101. Receive and transmit data slowly.

In contrast, in the embodiment of FIG. 10, the HBA is used in conjunction with the FPGA hardware accelerator block 440 as a protocol that is not implemented or cannot be implemented on the FPGA (e.g., due to a third-party Proprietary restrictions) provide high-speed support. In one implementation, the HBA can keep pace with the high speed data generation and transfer rates supported by the FPGA hardware accelerator block 440 . The FPGA can drive the HBA to receive and transmit data as fast as the hardware accelerator block 440 generates the data. Therefore, neither the tester processor (eg, tester processor map 304 of FIG. 3 ) nor the HBA is a bottleneck during the data transaction.

Note that the FPGA can be placed on a field module board 1060 (similar to field module 310A of FIG. 3 ), and the DUT 1055 can be placed on a device interface board 1064 (similar to load board 380 of FIG. 3 ). ). The HBA 1008 may be mounted on a sandwich board 1062 coupled to both the field module board 1060 and the device interface board 1064 . In one embodiment, the HBA 1008 can be disposed between the field module board 1060 and the device interface board 1064 .

FIG. 11 illustrates the manner in which a sandwich board containing one or more HBAs may be used to interface between an FPGA and a DUT, according to an embodiment of the invention. As previously discussed, an FPGA 1104 can be communicatively coupled to a tester processor 1102 from which it can receive instructions for testing one or more DUTs 1110 . The FPGA 1104 and the tester processor 1102 may be disposed on a field module board 1102 .

The FPGA transmits the test signals, eg, PCIe signals, to one or more HBAs 1106 disposed on a sandwich board 1107, where each HBA includes a protocol converter IP. Note that the number of HBAs placed on the sandwich depends on the type of HBA selected. Additionally, the number of DUTs 1110 connected to each HBA also depends on the selected HBA.

In the implementation shown in Figure 11, the protocol converter IP in each HBA can convert the PCIe signals from the FPGA to another protocol for testing the DUT 1110, e.g. SAS, the signal. This allows the tester to test DUTs configured with different protocols without reprogramming the FPGA and directly using a third-party protocol not integrated in the FPGA. It should be noted that the FPGA can be configured to implement any of several protocols and is not limited to PCIe. Similarly, the HBA can be configured with a protocol converter IP for any number of protocols, and is not limited to SAS.

In one embodiment, each DUT is connected to a single acceleration engine (or hardware accelerator block) in an associated FPGA. As described in connection with FIG. 2, each FPGA may have multiple instantiated FPGA tester blocks, each of which contains its own accelerator engine. In one implementation, each accelerator engine can be coupled to its own respective DUT. In one implementation, each HBA can be coupled to N instantiated FPGA tester blocks. Since each instantiated FPGA tester block contains its own accelerator engine, each HBA can be coupled with N accelerator engines.

In one implementation, each HBA can also be connected to N DUTs, wherein each accelerator engine can be connected to its own individual DUT. In one implementation, N=4, and each HBA can be connected to 4 instantiated FPGA tester blocks and 4 DUTs, where each DUT will be associated with its own accelerator core. However, it should be noted that embodiments of the present invention are not limited thereto. Each acceleration engine can be connected to more than a single DUT and each HBA can be connected to any number of DUTs.

Figure 12 illustrates an exemplary tester configuration in which each DUT is connected to a corresponding accelerator engine, according to an embodiment of the present invention. As shown in FIG. 12 , the FPGA includes a plurality of accelerator cores, such as 1201 , 1202 , 1203 and 1204 . Each accelerator core can run in the pattern generator mode (APG mode) or full accelerator mode (FA mode) as described above. Each accelerator core communicates with the IP core 1205 . The accelerator cores 1201-1204 and the IP core 1205 collectively perform substantially the same functions as the module 1010 in FIG. 10 . In the example shown in FIG. 12, IP core 1205 is a PCIe core, and thus, the FPGA implements the PCIe protocol.

The PCIe signals from the FPGA are sent to the sandwich board 1215 . HBA 1206 may be one of several HBAs disposed on sandwich panel 1215 . In this example, the HBA 1206 receives the PCIe signals and converts them to signals compliant with the SAS protocol. In one implementation, the SAS protocol can be provided as a proprietary third-party protocol IP that can be dropped into the design without changes or inspections being made to it. The HBA 1206 is communicatively coupled with four DUTs, each of which corresponds to a respective accelerator core. For example, DUT 1207 may correspond to accelerator core 1201 , DUT 1208 may correspond to accelerator core 1202 , DUT 1209 may correspond to accelerator core 1203 , and DUT 1210 may correspond to accelerator core 1204 .

FIG. 13 depicts a flowchart 1300 of an exemplary procedure for testing a DUT with a different protocol than that implemented (integrated) on an FPGA in a tester system, according to an embodiment of the present invention. A protocol to communicate. However, the invention is not limited to the description provided by this flowchart 1300 . Rather, other functional flow diagrams are within the scope and spirit of the present invention, as will be apparent to those skilled in the art to which the present invention pertains, in light of the teachings provided herein.

At block 1310, a system controller is coupled to a tester processor and an FPGA. The system controller can be a Windows-based operating system, as discussed above. The FPGA is communicatively coupled to the tester processor and is operable to generate commands and data for testing the plurality of DUTs according to one of the various acceleration modes described above.

At block 1312, commands and data for testing a plurality of connected DUTs are generated according to a first protocol implemented in an IP core of an FPGA and according to a selected acceleration mode. The accelerated mode can be a standard or bypass mode where the tester program generates all commands and data and the FPGA is bypassed. Alternatively, the acceleration mode may be a PIDA, FA, or hardware accelerator memory mode as described above.

At block 1314, signals associated with commands and data communicated using a first protocol are converted to signals comprising commands and data communicated by an HBA using a second protocol. In a In one embodiment, the HBA includes a protocol converter IP block 1004 that converts the command and data signals transmitted using the first protocol to the second protocol. In other words, the third-party protocol IP in the HBA is used to replace the protocol programmed into the FPGA. Note that, as described above, the HBA is communicatively coupled to a DUT operable to communicate using the second protocol.

At block 1316, the signals associated with the second agreement are relayed to the DUT for testing.

The foregoing description, for purposes of illustration, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. These embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to best utilize the invention and various embodiments with various modifications , such modifications may be suited to the intended particular use.

200: ATE equipment

201: System Controller

202: network switch

204: Tester processor

210A, 210B, 210C,..., 210N: FPGA tester blocks with instantiation of functional modules

211A, 211B,..., 210M: FPGA

212: shared bus

220A, 220B, 220C,..., 220N: DUT

230A,230B,...,230N: On-site modules

240A,240B,...,240M: memory block

Claims (20)

An automatic test equipment (ATE) system comprising: a system controller communicatively coupled to a tester processor, wherein the system controller is operable to send instructions to the tester processor, and wherein the test a processor operable to generate commands and data from the instructions for coordinating testing of a plurality of devices under test (DUTs); an FPGA communicatively coupled to the tester processor, wherein the FPGA includes a hardware a hardware accelerator circuit operable to internally generate commands and data transparent to the tester processor for testing the plurality of DUTs; and a bus adapter including a protocol converter module , the protocol converter module is operable to: before sending the signals to a first DUT of the plurality of DUTs, operate in a first conversion mode that converts signals received from the FPGA and converting signals associated with a first protocol into signals associated with a second protocol using which the first DUT communicates; and transmitting the signals to a first of the plurality of DUTs Before the two DUTs, operate in a second conversion mode that converts signals received from the FPGA associated with the first protocol to signals associated with a different protocol, wherein the second DUT uses The alien protocol communicates, and wherein the second protocol is a different protocol than the alien protocol. The system according to claim 1, further comprising a memory device associated with the FPGA, wherein the memory device stores test pattern data to be written into the DUT. The system of claim 1, wherein the signals associated with the first protocol include commands and data generated by the tester processor or the FPGA according to a selected acceleration mode associated with the hardware accelerator circuit . The system of claim 1, wherein the first protocol is a PCIe protocol and the second protocol is a SAS protocol. The system of claim 1, wherein the bus adapter is implemented on a circuit board disposed between a field module board including the FPGA and a device interface board including the DUT. The system of claim 1, wherein the FPGA includes an on-chip IP core for generating the signals associated with the first protocol, and wherein the second protocol is a third-party proprietary protocol. The system of claim 1, wherein the tester processor is configured to operate in one of a plurality of functional modes configured to be allocated between the tester processor and The function of generating commands and data between the FPGAs. The system of claim 1, wherein the protocol converter module is configured to interface with the hardware accelerator circuit and receive the signals associated with the first protocol at a speed at which the signals are generated by the hardware accelerator circuit such signals. An automatic test equipment (ATE) device comprising: a tester processor operable to generate commands and data for coordinating testing of a plurality of devices under test (DUTs); an FPGA whose communicatively coupled to the tester processor, wherein the FPGA includes a hardware accelerator circuit operable to internally generate commands transparent to the tester processor for testing the plurality of DUTs and data, and wherein the FPGA includes an IP core operable to generate signals for sending commands and data from the FPGA to the DUT using a first protocol; and a bus adapter including a protocol conversion converter module, the protocol converter module is operable to: before sending the signals to a first DUT of the plurality of DUTs, operate in a first conversion mode, the first conversion mode will receive the signals associated with the first protocol from the FPGA converting to signals associated with a second protocol using which the first DUT communicates; and prior to sending the signals to a second DUT of the plurality of DUTs, using a second Operating in a conversion mode, the second conversion mode converts signals received from the FPGA associated with the first protocol to signals associated with a different protocol, wherein the second DUT communicates using the different protocol. As the device of claim 9, it further includes a memory device associated with the FPGA, wherein the memory device stores test pattern data to be written into the DUT, and wherein the second protocol is a first Tripartite exclusive agreement. The apparatus of claim 9, wherein the signals associated with the first protocol include commands and data generated by the tester processor or the FPGA according to a selected acceleration mode associated with the hardware accelerator circuit . The device of claim 9, wherein the first protocol is a PCIe protocol and the second protocol is a SAS protocol. The apparatus of claim 9, wherein the bus adapter is implemented on a board disposed between a field module board including the FPGA and a device interface board including the DUT. The apparatus of claim 9, wherein the tester processor is configured to operate in one of a plurality of functional modes configured to be allocated for generation on the tester processor The function of command and data with the FPGA. The apparatus of claim 9, wherein the protocol converter module is configured to interface with the hardware accelerator circuit and receive signals associated with the first protocol at a speed at which the signals are generated by the hardware accelerator circuit such signals. A method for testing a DUT comprising: transmitting instructions from a system controller to a tester processor including a tester processor of an FPGA A tester board and the tester processor are coupled to the system controller, and wherein the tester processor is operable to coordinate testing of a plurality of devices under test (DUTs); implemented in an IP core of the FPGA according to generating commands and data for testing one of the plurality of DUTs according to a selected acceleration mode, wherein the generation is performed by a hardware accelerator circuit included in the FPGA using the first protocol to transmit signals associated with the commands and the data from the FPGA to a bus adapter; using the bus adapter and a protocol IP core implementing a second protocol, using the first protocol converting the signals communicating using the second protocol to signals communicating using the second protocol, wherein the bus adapter is communicatively coupled to a first DUT operable to communicate using the second protocol; using the bus adapter and a protocol IP core implementing a distinct protocol, converting the signals communicating using the first protocol to signals communicating in the distinct protocol, wherein the bus adapter is communicatively coupled to the a second DUT communicating using the alien protocol, and wherein the second protocol is a different protocol than the alien protocol; relaying the signals communicating in the second protocol to the first DUT for testing; and relaying the signals communicated with the distinct protocol to the second DUT for testing. The method of claim 16, wherein the bus adapter includes a protocol converter module configured to perform the conversion, and wherein the protocol IP core is proprietary to a third party. The method of claim 16, wherein the first protocol is a PCIe protocol and the second protocol is a SAS protocol. The method of claim 16, wherein the bus adapter is implemented on a circuit board disposed between a field module board including the FPGA and a device interface board including the DUT. The method of claim 17, wherein the protocol converter module is configured to interface with the The hardware accelerator circuit also receives the signals associated with the first protocol at a rate at which the signals are generated by the hardware accelerator circuit.