CN113391142A - Providing protocol flexibility in automated test equipment using host bus adapters - Google Patents

Abstract

This article deals with the use of host bus adapters to provide protocol flexibility in automated test equipment. An automated test equipment (ATE) system includes a system controller communicatively coupled to the tester processor, wherein the system controller is for sending instructions to the tester processor, and wherein the tester processor is for generating commands and data from the instructions to Coordinate testing of multiple devices under test (DUTs). The system also includes an FPGA programmed to support a first protocol communicatively coupled to the tester processor, the FPGA including at least one hardware accelerator circuit for transparently generating commands and data from within the tester processor to test DUT within multiple DUTs. In addition, the system includes a bus adapter having a protocol converter module for converting signals associated with the first protocol received from the FPGA to signals associated with the second protocol prior to reporting to the DUT Signaling, wherein the DUT communicates using the second protocol.

Description

Providing protocol flexibility in automated test equipment using host bus adapters

Cross Reference to Related Applications

This application is a continuation-in-part application entitled "A TEST ARCHITECTURE WITH A FPGA BASED TEST BOARD TO SIMULATE A DUT OR END-POINT (TEST ARCHITECTURE with FPGA-BASED TEST BOARDs for simulating DUTs OR endpoints)" filed on 7.3.2018, U.S. patent application No. 15/914,553 by the inventors of Duane Champioux and Mei-Mei Su, attorney docket No. ATST-JP0090.P1, this U.S. patent application, in turn, is a continuation-in-part application 0 entitled "TEST ARCHITECTURE HAVING MULTIPLE FPGA-BASED HARDWARE ACCELERATOR BLOCKS FOR INDEPENDENTLY TESTING MULTIPLE DUTS," filed on 21.2.2013, entitled "a TEST ARCHITECTURE HAVING MULTIPLE DUT accelerato BLOCKS," invented by Gerald Chan, Eric kushnik, Mei-Mei Su and Andrew Niemic, U.S. patent application No. 13/773,569 attorney docket No. attt-JP 009. The entire contents of both applications are incorporated herein by reference for all purposes.

This application also claims priority TO U.S. provisional application 62/988,612, filed on 12.3.2020, entitled "USE OF HOST BUS ADAPTER TO PROVIDE PROTOCOL FLEXIBILITY USE IN COMMUNICATION WITH FPGA WITH FULL ACCELATION FOR TESTING (providing PROTOCOL FLEXIBILITY using a HOST BUS ADAPTER USED IN conjunction with an FPGA having FULL ACCELERATION FOR TESTING)", with the case number ATSY-0090-00.00 US. The entire contents of each of the above-listed applications are incorporated herein by reference for all purposes as if fully set forth herein.

Technical Field

The present disclosure relates generally to the field of electronic device test systems, and more particularly to the field of electronic device test equipment for testing a Device Under Test (DUT).

Background

Automated Test Equipment (ATE) may be any test assembly that performs tests on semiconductor devices or electronic assemblies. ATE assemblies may be used to perform automated tests that take measurements quickly and generate test results that may then be analyzed. ATE assemblies can be any device from computer systems coupled with meters to complex automated test assemblies that can include custom, dedicated computer control systems and many different test instruments capable of automatically testing electronic components and/or performing semiconductor wafer testing (e.g., system on a chip (SOC) testing or integrated circuit testing). ATE systems both reduce the amount of time spent testing equipment to ensure that the equipment functions as designed, and act as a diagnostic tool to determine the presence of faulty components within a given device before the device reaches the customer.

Fig. 1 is a schematic block diagram of a conventional Automated Test Equipment (ATE) body 100 for one type of testing some typical DUTs, e.g., semiconductor memory devices such as DRAMs. The ATE includes an ATE body 100 having hardware bus adapter slots 110A-110N. Hardware bus adapter cards 110A-110N dedicated to a particular communication protocol (e.g., PCIe, USB, SATA, SAS, etc.) connect to hardware bus adapter slots provided on the ATE body and interface with the DUT through cables dedicated to the respective protocol. The ATE body 100 also includes a tester processor 101 and associated memory 108, the tester processor 101 being used to control the hardware components built into the ATE body 100 and to generate the commands and data required to communicate with the DUT under test through the hardware bus adapter card. The tester processor 101 communicates with the hardware bus adapter card via a system bus 130. The tester processor may be programmed to include certain functional blocks including the pattern generator 102 and the comparator 106. Alternatively, pattern generator 102 and comparator 106 may be hardware components mounted on an expansion card or adapter card that is inserted into ATE body 100.

The ATE body 100 tests the electrical functions of the DUTs 112A-112N connected to the ATE body 100 through a hardware bus adapter that plugs into a hardware bus adapter socket of the ATE body 100. Thus, the tester processor 101 is programmed to use the protocol specific to the hardware bus adapter to deliver the test program to be run to the DUT. Meanwhile, other hardware components built in the ATE body 100 transfer signals between each other and with the DUT according to a test program operating in the tester processor 101.

The test program run by the tester processor 101 may include a functional test involving the following steps: the input signals created by the pattern generator 102 are written to the DUT, the written signals are read from the DUT, and the output is compared to the desired pattern using the comparator 106. 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 may write data generated by the pattern generator 102 to the DUT using a write operation, read data from the DRAM using a read operation, and compare the expected bit pattern to the read pattern using the comparator 106.

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

The FPGA used in conventional systems may be a pass-through device that forwards commands and test patterns, which the FPGA forwards to the DUT by means of the tester processor 101 sending them to the FPGA. Because the tester processor, rather than the FPGA, is responsible for generating commands and test patterns, the number and types of DUTs that can be tested using a given ATE body is limited by the processing power and programming of the tester processor. The bandwidth limitations on the system bus 130 connecting the tester processor to the various hardware components (including any FPGA devices and hardware bus adapter slots) also set an upper limit on the number of DUTs that can be tested simultaneously, with all commands and test patterns generated by the tester processor.

Furthermore, in conventional systems, the communication protocol used to communicate with the DUT is fixed, because the hardware bus adapter card inserted into the ATE body 100 is a single-use device designed to communicate in only one protocol and cannot be reprogrammed to communicate in a different protocol. For example, an ATE body configured to test PCIe devices will have hardware bus adapter cards inserted into the body that support only the PCIe protocol. To test DUTs that support different protocols (e.g., SATA), a user typically needs to replace the PCIe hardware bus adapter card with a bus adapter card that supports the SATA protocol. Such a system can only test DUTs that support the PCIe protocol unless the PCIe hardware bus adapter card is physically replaced with a card that supports another protocol.

In conventional ATE of different types, FPGAs are not just pass-through devices as described above. Instead of using a hardware bus adapter card to implement the protocol for communicating with the DUT, a new protocol for communicating with the DUT can be downloaded directly and installed on the FPGA of the tester system by a simple bitstream download from a cache on the system controller. The FPGA in the tester may typically include the following configurable interface cores (or IP cores): which is programmable to provide one or more functions of a protocol-based interface for the DUT and programmable to interface with the DUT. In addition, if a new protocol is released, the FPGA can be easily configured with that protocol via bitstream download, which is more convenient than having to physically switch all hardware bus adapter cards in the system.

Typically, conventional testers only allow a single IP core to be programmed onto the FPGA. Because the FPGA accelerator of the existing test system can only support a single IP core, if a different third party IP core needs to be programmed into the FPGA, the FPGA needs to be reprogrammed. Thus, if a DUT connected to an FPGA needs to be exchanged for another type of DUT, the FPGA needs to be reprogrammed to support a different protocol. Reprogramming an FPGA can be time consuming and cumbersome in a test environment.

In addition, memory and other devices are coming to market for shorter and shorter times. Furthermore, the protocol IP is increasingly proprietary, so FPGAs may only support a single protocol. Furthermore, since many third party IP cores are proprietary, they cannot be programmed onto FPGAs.

Disclosure of Invention

Therefore, a tester architecture is needed that can address the problems of the above-described systems. The following test architecture is required: with this architecture, command and test pattern generation functions can be transferred to the FPGA so that the processing load on the tester processor and the bandwidth requirements on the system bus can be kept to a minimum. This would be more efficient than existing configurations where the tester processor bears the full processing workload and the system bus passes test data and commands for all DUTs connected to the ATE body.

Furthermore, the following test architecture is required: with this architecture, a host bus adapter can be used in conjunction with an FPGA to provide protocol flexibility. As described above, as the protocol IP is becoming more proprietary, FPGAs support only one protocol, and if another protocol is required, a Host Bus Adapter (HBA) can be used to bridge third party IP protocols. In other words, a configurable interface core (or IP core) in the FPGA (which is programmable) is used in conjunction with a host bus adapter to interface with a third party protocol to communicate with DUTs that support a protocol other than the one programmed within the IP core. This allows engineers to quickly switch protocols in a test environment without having to reprogram the FPGA.

In one embodiment, an Automated Test Equipment (ATE) system is disclosed. The device includes: a system controller communicatively coupled to the tester processor, wherein the system controller is operable to send instructions to the tester processor, and wherein the tester processor is operable to generate commands and data according to the instructions to coordinate testing of a plurality of Devices Under Test (DUTs). The apparatus also includes an FPGA communicatively coupled to the tester processor and including at least one hardware accelerator circuit operable to transparently generate commands and data from within the tester processor to test a DUT of the plurality of DUTs. Additionally, the apparatus includes a bus adapter including a protocol converter module operable to convert signals associated with a 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. In one embodiment, the second protocol is a proprietary third party protocol.

In another embodiment, an Automated Test Equipment (ATE) apparatus includes a tester processor operable to generate commands and data to coordinate testing of a plurality of Devices Under Test (DUTs) and an FPGA communicatively coupled to the tester processor, wherein the FPGA includes a hardware accelerator circuit operable to transparently generate commands and data from within the tester processor to test DUTs of the plurality of DUTs, and wherein the FPGA includes an IP core operable to generate signals for sending commands and data from the FPGA to the DUTs using a first protocol. The apparatus also includes a bus adapter including a protocol converter module operable to convert signals received from the FPGA associated with a first protocol to signals associated with a second protocol before transmitting the signals 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 sending instructions from a system controller to a tester processor, wherein a tester board including an FPGA 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 to test a DUT of the plurality of DUTs according to a first protocol implemented in an IP core of the FPGA and according to the selected acceleration mode, wherein the generating is performed by hardware accelerator circuitry included within the FPGA. Further, the method includes sending signals associated with the command and data from the FPGA to the bus adapter using the first protocol. Further, the method includes converting signals communicated using the first protocol to signals of a second protocol using a bus adapter and a protocol IP core implementing the second protocol, wherein the bus adapter is communicatively coupled to the DUT operable to communicate using the second protocol. The method also includes forwarding the signal in a second protocol to the DUT for testing.

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

Drawings

Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.

FIG. 1 is a schematic block diagram of a conventional automated test equipment body for testing a typical Device Under Test (DUT).

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

Fig. 3 is a detailed schematic block diagram of a site module and its interconnection to a system controller and DUT according to an embodiment of the present invention.

FIG. 4 is a detailed schematic block diagram of the instantiated FPGA tester block of FIG. 2 in accordance with an embodiment of the present invention.

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

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

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

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

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

Fig. 10 illustrates one manner in which an HBA including a protocol converter IP may be used to connect an FPGA to a DUT that communicates in a different protocol than the protocol in which the FPGA is programmed, according to an embodiment of the invention.

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

FIG. 12 illustrates an exemplary tester configuration in which each DUT has a corresponding accelerator engine connected thereto, according to embodiments of the invention.

FIG. 13 depicts a flowchart 1300 of example processing for testing a DUT that communicates in a different protocol than the protocol implemented on the FPGA in the tester system, according to an embodiment of the invention.

In the drawings, elements having the same reference number have the same or similar function.

Detailed Description

Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. While the embodiments will be described in conjunction with the appended drawings, it will be understood that these drawings are not intended to limit the embodiments. On the contrary, the embodiments are intended to cover alternatives, modifications, and equivalents. Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a thorough understanding. However, it will be recognized by one of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the embodiments.

Notes and terms part

Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In the present application, a procedure, logic block, process, etc., is conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic 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 associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as "testing," "communicating," "coupling," "converting," "forwarding," or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or 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, the term "module" or "block" may be understood to refer to software, firmware, hardware, and/or various combinations thereof. Note that blocks and modules are exemplary. Blocks or modules may be combined, integrated, separated, and/or duplicated to support various applications. In addition, functions 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 devices in place of, or in addition to, functions performed at the particular module or block described. Further, a module or block may be implemented across multiple devices and/or other components, local or remote to each other. Additionally, modules or blocks may be moved from one device and added to another device, and/or may be included in both devices. Any software implementation of the present invention can 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 other devices that can store computer code.

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

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

Test throughput can generally be improved in a number of ways. One way to reduce the test time of a DUT is to transfer functions that were previously performed in software on a general purpose tester processor to a hardware accelerator implemented on an FPGA device. Another approach is by increasing the number and types of Devices Under Test (DUTs) that can be tested under primary (legacy) hardware and time constraints, for example, by configuring the hardware so that DUTs supporting many different types of protocols (e.g., PCIe, SATA) can be tested with the same hardware without having to replace or reconfigure any hardware components. Embodiments of the present invention are directed to improving test efficiency in hardware of automated test equipment.

Fig. 2 is an exemplary high-level block diagram of an Automated Test Equipment (ATE) apparatus 200 in which a tester processor is connected to a Device Under Test (DUT) through an FPGA device having built-in functional modules, according to an embodiment of the present invention. In one embodiment, the ATE apparatus 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 invention includes: a system controller 201; a network switch 202 that connects the system controller to the site module boards 230A-230N; FPGA devices 211A-211M that include instantiated FPGA tester blocks 210A-210N; memory block modules 240A-240M, where each of these memory blocks is connected to one of the FPGA devices 211A-211M; and Devices Under Test (DUTs) 220A-220N, wherein each device under test 220A-220N is connected to one of the instantiated FPGA tester blocks 210A-210N.

In one embodiment, the system controller 201 may be a computer system, such as a Personal Computer (PC) that provides a user interface for a user of the ATE to load test programs and run tests on DUTs connected to the ATE 200. The Verigy Stylus operating system is one example of testing software that is typically used during device testing. It provides a graphical user interface for the user to configure and control the test. It may also include the following functions: control the test flow, control the state of the test programs, determine which test program is running, and record the test results and other data related to the test flow. In one embodiment, a system controller may connect to and control up to 512 DUTs.

In one embodiment, system controller 201 may be connected to site module boards 230A-230N through a network switch (e.g., an Ethernet switch). In other embodiments, the network switch may be compatible with different protocols such as fibre channel, 802.11, or ATM.

In one embodiment, each of the site module boards 230A-230N may be a separate, stand-alone board for evaluation and development purposes that is attached to a custom load board fixture that is loaded with DUTs 220A-220N and also attached to the system controller 201 that receives the test program. In other embodiments, the site module board may be implemented as a plug-in expansion card or a daughter board that plugs directly into the chassis of the system controller 201.

In one implementation, site 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 site module board run test methods for each test case according to test program instructions received from the system controller 201. In one embodiment, the tester processor may be a commercially available Intel 8086CPU or any other well-known processor. In addition, the tester processor may operate on the Ubuntu OS x64 operating system and run core software that allows the tester processor to communicate with style software running on the system controller to run the test methods. The tester processor 204 controls the FPGA devices on the site modules and the DUTs connected to the site modules based on the test programs received from the system controller.

The tester processor 204 is connected to and can communicate with the FPGA device via bus 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 may transparently control testing of the DUTs 220A-220N through an FPGA device that is assigned the lowest processing functionality. In this implementation, the FPGA device acts as a pass-through device. In this embodiment, the data traffic capacity of the bus 212 can be quickly exhausted because all commands and data generated by the tester processor need to be transferred to the FPGA device over the bus. In other embodiments, the tester processor 204 may share the processing load by assigning functions for controlling testing of the DUT to the FPGA device. In these embodiments, the amount of 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 to store test pattern data that is written out to the DUT, among other things. In one embodiment, each of the FPGA devices can include two instantiated FPGA tester blocks 210A-210B having functional modules (including implementations of a communication protocol engine and a hardware accelerator as described further herein) for performing functions. The memory blocks 240A-240M may each include one or more memory modules, where each memory module within a memory block may be dedicated to instantiating one or more of the FPGA tester blocks 210A-210B. Thus, each of the instantiated FPGA tester blocks 210A-210B can be connected to its own dedicated memory module within the memory block 240A. In another embodiment, the instantiated FPGA tester blocks 210A and 210B may share one of the memory modules within the memory block 240A.

Furthermore, each of the DUTs 220A-220N in the system may be connected to a dedicated instantiated FPGA tester block 210A-210N in a "tester per DUT" configuration, where each DUT obtains its own tester block. This allows separate tests to be performed for each DUT. The hardware resources in such a configuration are designed in a way that supports individual DUTs with minimal hardware sharing. This configuration also allows many DUTs to be tested in parallel, where each DUT can connect to its own dedicated FPGA tester block and run a different test program. In one embodiment, two or more DUTs may also be connected to each FPGA tester block (e.g., block 210A).

The architecture of the embodiment of the present invention depicted in fig. 2 has several advantages. First, it allows communication protocol modules to be programmed directly onto instantiated FPGA tester modules within an FPGA device. The instantiated tester block may be configured to communicate with the DUT in any protocol supported by the DUT. Thus, if DUTs with different protocol supports need to be tested, they can be connected to the same system and the FPGA can be reprogrammed to support the associated protocol. As a result, one ATE body can be easily configured to test DUTs that support many different types of protocols.

In one embodiment, the new protocol can be downloaded and installed directly on the FPGA by downloading via a simple bitstream from a cache on the system controller 201 without any kind of hardware interaction. The FPGA will typically include a configurable interface core (or IP core) that is programmable to provide one or more functions of a protocol-based interface for the DUT and is programmable to interface with the DUT. For example, the FPGAs 211A-211M in the ATE apparatus 200 will include an interface core that can be configured with the PCIe protocol to initially test PCIe devices and then reconfigure via software downloads to test SATA devices. Additionally, if a new protocol is released, the FPGA can be easily configured with that protocol via bitstream download. Finally, if a non-standard protocol needs to be implemented, the FPGA may still be configured to implement such a protocol.

In another embodiment, the FPGAs 211A-211M may be configured to run more than one communication protocol, where these protocols may also be downloaded from the system controller 201 and configured via software. In other words, each FPGA implements customized 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 an on-chip IP core in the FPGA. As mentioned above, each FPGA may be programmed with a pre-verified interface or IP core. This ensures compliance and compatibility according to a given interface standard. The programmable nature of the FPGA is used to optimize flexibility, cost, parallelism, and scalability for storage test applications of SSDs, HDDs, and other protocol-based storage devices.

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

In one embodiment, the interfaces or IP cores in the FPGA may be obtained from third party vendors, but some customization may be required to be compatible with the embodiments described herein. In one embodiment, the interface core provides two functions: a) encapsulating the storage command into a standard protocol for transmission over a physical channel; and 2) electrical signal generators and receivers.

Another major advantage of the architecture presented in fig. 2 is that it reduces the processing load on the tester processor 204 by assigning command and test pattern generation functions to FPGA devices, where each DUT has a dedicated FPGA module running its specific test program. For example, the instantiated FPGA tester block 210A connects to the DUT 220A and runs a test program specific to the DUT 220A. The hardware resources in such a configuration are designed in a way that supports individual DUTs with minimal hardware sharing. This "tester per DUT" configuration also allows more DUTs to be tested per processor and more DUTs to be tested in parallel. Furthermore, the bandwidth requirements of the bus 212 connecting the tester processor to other hardware components, including the FPGA device, the Device Power Supply (DPS) and the DUT, are also reduced by using FPGAs that are capable of generating their own commands and test patterns in certain modes. As a result, more DUTs can be tested simultaneously than in prior configurations.

Fig. 3 provides a more detailed schematic block diagram of a site module and its interconnection to a system controller and DUT according to an embodiment of the present invention. Referring to FIG. 3, in one embodiment, site modules of an ATE apparatus may be mechanically deployed on tester slices 340A-340N, where each tester slice includes at least one site module. In some exemplary embodiments, each tester slice may include two site modules and two device power boards. For example, tester slice 340A of FIG. 3 includes site modules 310A and 310B and device power boards 332A and 332B. However, there is no limit to the number of device power boards or site modules that can be configured 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, respectively, in fig. 2. The network switch 302 may be connected to each of the site modules with a 32-bit wide bus.

Each device power board 332A-332B may be controlled from one of the site modules 310A-310B. Software running on tester processor 304 may be configured to distribute device power to particular site modules. In one embodiment, for example, site modules 310A-310B and device power supplies 332A-332B are configured to communicate with each other using a high-speed serial protocol (e.g., peripheral component interconnect express (PCIe), serial AT attachment (SATA), or Serial Attached SCSI (SAS)).

In one embodiment, as shown in FIG. 3, each site module is configured with two FPGAs. Each of the FPGAs 316 and 318 in the embodiment of FIG. 3 is controlled by the tester processor 304 and performs similar functions as the FPGAs 211A-211M in FIG. 2. The tester processor 304 may communicate with each FPGA using an 8-channel high-speed serial protocol interface, such as PCIe as indicated by system buses 330 and 332 in fig. 3. In other embodiments, tester processor 304 may also communicate with the FPGA using a different high-speed serial protocol (e.g., serial AT connection (SATA) or serial attached scsi (sas)).

FPGAs 316 and 318 are connected to memory modules 308 and 304, respectively, where these memory modules perform similar functions as memory blocks 240A-240N in fig. 2. These memory modules are coupled to and controllable by both the FPGA device and the tester processor 304.

The FPGAs 316 and 318 can be connected to DUTs 372A-372M on a load board 380 via buses 352 and 354, respectively. The load board 380 is a physical implement of: physical instruments that allow for a universal high-speed connection at the site module end (which is not aware of the protocol used to communicate to DUTs on lines 352 and 354). At the DUT end, however, the load board needs to be designed with connectors specific to the protocol used by the DUT.

In one embodiment of the present invention, the DUTs 372A-372M are loaded on a load board 380 placed within a thermal chamber 390 for testing. The DUTs 372A-372M and load board 380 obtain 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 for each DUT. In one embodiment, FPGAs 316 and 318 may each include 32 high-speed transceivers and buses 352 and 354 may each be 32 bits wide, however, more or less may be implemented depending on the application. For example, if 8I/O channels are required per DUT, only 4 DUTs may be connected to each FPGA in such a system.

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

The instantiated FPGA block 410 may include a protocol engine block 430, a logic block 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: decode logic to decode a command from the tester processor; routing logic to route all incoming commands and data from the tester processor 304 and data generated by the FPGA devices to the appropriate modules; and arbitration logic to arbitrate (arbitrate) between various communication paths within instantiated FPGA tester block 410.

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

In one embodiment, for example, for a storage device/SSD/HDD, each FPGA includes the following configurable ICs: which is connected to the SSD and programmable to provide a storage-based pattern through a storage-specific interface such as SATA or SAS. In one embodiment, for an RF module, the FPGA includes the following configurable ICs: the configurable interface core therein is programmed to provide USB or PCIe interface connections using current RF modules.

In one embodiment, the FPGA may be an SSD or RF module based tester that interfaces with the DUT or module using protocol based communications. In one embodiment, the configurable interface core may be programmed to provide any protocol-based standardized communication interface. For example, in one embodiment, in the case of SSD module based testing, the interface core may be programmed to provide a protocol based standardized communication interface such as SATA, SAS, or the like. In one embodiment, in the case of an RF module based tester, the interface core may be programmed to provide a protocol based standardized communication interface such as USB, PCIe. In one embodiment, in the case of a module having an optical interconnect, the interface core may be programmed to provide protocol-based standardized communications for communicating with the module over the optical interconnect.

Thus, from an electrical perspective, FPGAs utilize configurable IP cores. 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 swapping out the FPGA chip or other hardware components. For example, if a given FPGA-based tester currently supports SATA, the FPGA need only be reprogrammed to enable connection to a fibre channel DUT using a fibre channel IP core instead of an existing IP core configured for SATA.

In one embodiment, the protocol may be a high speed serial protocol including, but not limited to, SATA, SAS, or PCIe, or the like. The new or modified protocol can be downloaded directly from the system controller by the tester processor via a simple bitstream download and installed on the FPGA. In addition, if a new protocol is released, the FPGA can be easily configured with the protocol via software download.

In fig. 4, if the DUT coupled to the PCIe downstream port 480 is a PCIe device, a bit file containing an instance of the PCIe protocol may be downloaded through the PCIe upstream port 470 and installed 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 of the FPGA and the gate count.

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

The hardware accelerator block 440 of fig. 4 may be used to accelerate (compared to the speed that can be achieved in software on a tester processor) certain functions on the FPGA hardware. The hardware accelerator block 440 may provide initial test pattern data for use in testing the DUT. It may also contain functionality for generating certain commands for controlling the testing of the DUT. To generate the test pattern data, the accelerator block 440 uses an algorithmic pattern generator module 443.

The hardware accelerator block 440 may use the comparator module 446 to compare data read from the DUT with data written to the DUT in a previous cycle. The comparator module 446 includes functionality for marking mismatches to the tester processor 304 to identify non-compliant devices. More specifically, comparator module 446 may include an error counter that tracks mismatches and communicates them to tester processor 304.

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

The memory module 420 stores test pattern data to be written to the DUT and the hardware accelerator block 440 accesses the module to compare the stored data with data read from the DUT after a write cycle. The local memory module 420 may also be used to log failures. The memory module will store a log file with a record of all failures experienced by the DUT during testing. In one embodiment, the accelerator block 440 has a dedicated local memory module block 420 that is not accessible 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 also include a memory control module 444. Memory control module 444 interacts with memory module 420 and controls read and write accesses to memory module 420. Finally, the hardware accelerator block 440 includes a packet builder module 445. The packet builder module is used by the hardware accelerator module in certain modes to construct packets including header/command data and test pattern data to be written out to the DUT.

In some embodiments, the hardware accelerator block 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 commands and test data are sent by the tester processor 304 directly to the DUT via path 472. In the hardware accelerator pattern generator mode, test pattern data is generated by the APG module 443 and commands are generated by the tester processor 304. The test packet is sent to the DUT via path 474. In the hardware accelerator memory mode, test pattern data is accessed from the local memory module 420 while commands are generated by the tester processor 304. The test pattern data is sent to the DUT via path 476. Routing logic 482 is required to arbitrate between paths 472, 474 and 476 in order to control the flow of data to the DUT.

The site module may include a universal connector 481. Because the protocol engine module 430 may be configured to run any number of various communication protocols, a universal high speed connector 481 is required on the site module. Thus, if a change to the protocol implemented on the protocol engine module 430 is required, no incidental physical modification on the site module is required. The site module is connected to the DUT using a load board 380, which load board 380 is connectable to a general purpose connector on the site module side, but which load board 380 is specific to the protocol implemented on the DUT side. DUTs supporting different communication protocols will require different configurations. Thus, if the protocol is reprogrammed to accommodate DUTs requiring different configurations, the load board needs to be switched and replaced.

FIG. 5 depicts a flowchart 500 of an exemplary process for testing a DUT according to an embodiment of the invention. However, the invention is not limited to the description provided by flowchart 500. Rather, other functional flows will be apparent to those skilled in the relevant art from the teachings provided herein that are within the scope and spirit of the present invention. Flowchart 500 will be described with continued reference to the exemplary embodiments described above with reference to fig. 2, 3, and 4, but the method is not limited to these embodiments.

Referring now to FIG. 5, at block 502, a user initiates setup and loads a test program into the system controller. Initiating setup may include selecting one or more protocols from a library of available protocols for configuration onto an FPGA device in the ATE apparatus 200. These protocols are cached as files on the system controller 301 and can be downloaded to the FPGA as bit files. The user may select a protocol from the list of available versions through a graphical user interface. A protocol must be built, tested, and integrated into a version before it is available as an option. The published FPGA configuration contains, among other things, definitions regarding the supported protocols and the number of transceivers available to connect to the DUT. The version library may then be made available to the user through a graphical user interface.

At block 502, the user also loads a test program into the system controller 301 through the graphical user interface. The test program defines all the parameters of the test that needs to be run on the DUT. At block 504, the system controller sends instructions to the tester processor on the site module 310A. This step involves the transmission of a bit file for the protocol engine to be programmed onto the FPGA. The system controller may include routing logic for routing instructions of a particular test program to a 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 a hardware acceleration pattern for running tests on DUTs connected to the site module 310A.

In one embodiment, tester processor 304 may operate in one of four different hardware acceleration modes. Each functional mode is configured to distribute functions for generating commands and test data between the tester processor 304 and the FPGAs 316 and 318. In one embodiment, the tester processor may be programmed to operate in a bypass mode, in which all commands and test data for testing the DUT are generated by the tester processor 304 and the FPGAs 316 and 318 are bypassed. In another embodiment, the tester processor 304 may be programmed to operate in a hardware accelerator pattern generator mode, where pseudo random data for testing the DUT is generated by the FPGAs 316 and 318 and compared by the FPGAs, but the tester processor handles command generation.

In yet another embodiment, the tester processor 304 may be programmed to operate in a hardware accelerator memory mode, where test patterns are pre-written by the tester processor onto memory modules connected to each FPGA 316 and 318 during initial setup. In this mode, the FPGA accesses a dedicated memory device to retrieve test data to be written to the DUT, reads the test data from the DUT and compares the read data with the data written on the memory device. In this mode, each of the FPGAs controls the memory device in response to read and write operations from the DUT. However, in this mode, the tester processor is still responsible for command generation. In yet another embodiment, the tester processor 304 may be programmed to operate in a hardware accelerator packet builder mode, where data and basic read/write/compare commands are generated by the FPGAs 316 and 318.

At block 508, the tester processor branches to a mode in which a test is to be run.

It should be noted that FPGA1002 of figure 10 can be programmed to have any of the four functional modes described above (i.e., bypass mode, hardware accelerator pattern generator mode, hardware accelerator memory mode, and hardware accelerator packet builder mode).

FIG. 6 depicts a flowchart 600 of an exemplary process for testing a DUT in bypass mode, according to an embodiment of the invention. However, the present invention is not limited to the description provided by flowchart 600. Rather, other functional flows will be apparent to those skilled in the relevant art(s) from the teachings provided herein and are within the scope and spirit of the present invention. Flowchart 600 will be described with continued reference to the exemplary embodiments described above with reference to fig. 2, 3, and 4, but the method is not limited to these embodiments.

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

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

At block 608, the tester processor 304 communicates with the downstream port 480 to initiate a read operation from the DUT on data previously written to the DUT at block 606. At block 610, the tester processor compares the data read from the DUT with the data written at block 606. If there is any mismatch between the data written at block 606 and the data read at block 610, a flag is sent by the tester processor 304 to the system controller 301 at block 612. The system controller will then mark the user for a mismatch.

In bypass mode, the tester processor 304 is limited in the number of DUTs that it can support because the processing power of the tester processor 304 can be quickly maximized (maximized) due to the generation of all command and test data for the DUTs. In addition, the number of DUTs that the site module 310A can support is also limited by bandwidth constraints on the system buses 330 and 332. In bypass mode, the bandwidth of buses 330 and 332 is exhausted relatively quickly because tester processor 304 sends large amounts of data to the DUT via buses 330 and 332. Thus, other modes with more hardware acceleration are provided in which the FPGA device has more functionality for generating test data and commands.

FIG. 7 depicts a flowchart 700 of an exemplary process for testing a DUT in a hardware accelerator pattern generator mode, according to an embodiment of the invention. However, the present invention is not limited to the description provided by flowchart 700. Rather, other functional flows will be apparent to those skilled in the relevant art(s) from the teachings provided herein and are within the scope and spirit of the present invention.

Flowchart 700 will be described with continued reference to the exemplary embodiments described above with reference to fig. 2, 3, and 4, but the method is not limited to these embodiments. Referring now to FIG. 7, a method of hardware acceleration is shown in which FPGA devices share data generation functionality in order to relieve the processing load on the tester processor 304 and the data load on the system buses 330 and 332. At block 702 of the hardware accelerator pattern generator mode, the tester processor 304 generates a command and packet header for a packet to be routed to the DUT. In this mode, the tester processor retains the signaled functionality. At block 704, the algorithm pattern generator module 443 within the hardware accelerator block 440 generates pseudo-random test data to be written to the DUT. The logic block module 450 includes functionality for routing and adding generated data to packets to be written out to the DUT.

This mode is considered "hardware accelerated" because the functions for generating data can be completed faster in hardware by the algorithmic pattern generator of the FPGA device (as compared to generating data in software by the tester processor). In addition, the "tester per DUT" architecture allows the DUT to be directly connected to its own dedicated instantiated FPGA tester block, generating test pattern data for the DUT, as shown in fig. 4, which achieves a significant increase in bandwidth over the bypass mode where the tester processor 304 provides all commands and data to the DUT through the system buses 330 and 332. Where the FPGA devices share data generation functionality, the system buses 330 and 332 are released so that commands can be transferred to the FPGA at a faster rate than in bypass mode. Further, for devices such as solid state drives that require multiple test iterations, having dedicated data paths by instantiating FPGA tester blocks greatly speeds testing over data paths in which the tester processor's resources are shared by multiple DUTs. It also allows the DUT to operate at near full performance because it does not have to wait for the tester processor to allocate processing resources for it.

In one embodiment, the algorithmic pattern generator module 443 may be programmed to generate data in time (on the fly). The APG module may generate an incremental pattern, a pseudo-random pattern, or some type of constant pattern. The APG module may also have some gating (gating) capability to generate test patterns with stripes, diagonal stripes, or alternating patterns. In one embodiment, the APG module may use a finite state machine, a counter, or a linear feedback shift register, among others, to generate the test pattern. In some implementations, the APG module may be provided with a start seed as an initial value for generating a more complex pattern.

At step 706, the instantiated FPGA block 410 communicates with the downstream port 480 to route test pattern data to the DUT according to commands and packet headers generated by the tester processor. At step 708, the instantiated FPGA block 410 communicates with the downstream port to read test pattern data from the DUT according to commands generated by the tester processor. The comparator module 446 of the hardware accelerator block 440 is then used to compare the read data with the data written to the DUT at block 710. The APG module 443 is designed to enable the comparator module to perform read operations on the APG module 443 and receive the same data written to the DUT at block 704, with the same parameters used to generate the pseudo-random data. The APG module 443 timely regenerates and transfers the data written to the DUT to the comparator module 446. At block 712, any mismatches are 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 marks the system controller for a mismatch at block 714.

FIG. 8 depicts a flowchart 800 of an exemplary process for testing a DUT in hardware accelerator memory mode, according to an embodiment of the invention. However, the invention is not limited to the description provided by flowchart 800. Rather, other functional flows will be apparent to those skilled in the relevant art(s) from the teachings provided herein and are within the scope and spirit of the present invention.

Flowchart 800 will be described with continued reference to the exemplary embodiments described above with reference to fig. 2, 3, and 4, but the method is not limited to these embodiments.

Referring now to FIG. 8, a method of hardware acceleration is shown in which FPGA devices share data generation functionality in order to relieve the processing load on the tester processor 304 and the data load on the 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 the local memory module 420 to retrieve data to be written to the DUT without being obtained using the APG module 443.

At block 800 of the hardware accelerator pattern memory mode, the tester processor 304 generates a command and packet header for a packet to be routed to the DUT. The tester processor retains the functionality for signaling in this mode. At block 802, the tester processor initializes the local memory module 420 instantiating the FPGA tester block 410 with the test pattern to be written out to the DUT. One advantage of the hardware accelerator memory mode is that the test patterns generated by the tester processor may constitute true random data, as opposed to pseudo random data generated by the APG module 443 in the hardware accelerator pattern generator mode. 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 the memory module 420 during initial setup. During the accelerator mode, the tester processor does not access the memory module because the additional processing load on the tester processor 304 and the additional data load on the system buses 330 and 332 significantly slow down the acceleration.

At block 804, the instantiated FPGA tester block reads test pattern data from the memory module 420 to be routed to the DUT. 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 that results in a fast read operation. The logic block module 450 includes functionality to route the generated data and add it to packets to be written out to the DUT.

After data is added to the packet, at block 806, the instantiated FPGA tester block communicates with the downstream port 480 to route test pattern data to the DUT according to commands and packet headers generated by the tester processor. At block 808, instantiate FPGA block 410 communicates with a downstream port to read test pattern data from the DUT according to commands generated by the tester processor. The comparator module 446 of the hardware accelerator block 440 is then used to compare the read data with the data written to the DUT at block 810. At block 812, any mismatches are recorded on the memory module 420 or communicated by the instantiated FPGA block to the tester processor. After receiving the error log, the tester processor then marks the system controller for a mismatch at block 814.

FIG. 9 depicts a flowchart 900 of an exemplary process for testing a DUT in hardware accelerator packet builder mode, according to an embodiment of the invention. However, the present invention is not limited to the description provided by flowchart 900. Rather, other functional flows will be apparent to those skilled in the relevant art(s) from the teachings provided herein and are within the scope and spirit of the present invention.

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

Referring now to FIG. 9, a method of hardware acceleration is shown in which FPGA devices share data and command generation functionality in order to relieve the processing load on the tester processor 304 and the data load on the system buses 330 and 332. This mode is also referred to as the "full acceleration" mode because most of the control for running the device test is transferred to the FPGA device and the tester processor 304 only retains control for commands other than read and write and compare.

At block 902 of the hardware accelerator packet builder mode, the tester processor 304 generates a command to be passed to the instantiate FPGA block 410 to generate its own packet. The tester processor in this mode only retains functionality for non-read/write/compare commands. Functions for commands such as read, write, and compare operations are delivered to instantiated FPGA blocks. At block 904, the packet builder module 445 that instantiates the FPGA tester block builds a packet with header and command information to be transmitted to the DUT. The packets include at least a command type, a block address of the device, and test pattern data.

At block 906, the algorithm pattern generator module 443 within the hardware accelerator block 440 generates pseudo-random test data to be written to the DUT. The logic block module 450 includes functionality for routing and incorporating data and commands generated by instantiated FPGA blocks into packets to be written out to the DUT.

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

Using a host bus adapter to provide protocol flexibility in automated test equipment

As described above, the new protocol for communicating with the DUT can be downloaded directly and installed on the FPGA of the tester system by a simple bitstream download from a cache on the system controller. The configurable interface core (or IP core) in the FPGA can be programmed to provide the functionality of one or more protocol-based interfaces for communicating with the DUT. Each FPGA implements a custom firmware and software image 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 an on-chip IP core in the FPGA. Each FPGA may be programmed with a pre-verified interface or IP core. This ensures compliance and compatibility according to a given interface standard.

It should be noted that some conventional testers only allow a single IP core to be programmed onto the FPGA, although in some cases many different types of cores may be programmed onto the FPGA. In other words, the FPGA protocol engine module (e.g., module 430 of fig. 4) of some test systems can only support a single IP core, and if a different third party protocol IP core needs to be programmed into the FPGA, the FPGA will need to be reprogrammed. In addition, the IP core may include third party IP protocols that may be proprietary and that cannot be tampered with or duplicated. This can result in delays in both the development and test environments. Reprogramming an FPGA can sometimes take a significant amount of time, slowing down the development or testing process.

Thus, in some embodiments, an FPGA with configurable IP cores is used in conjunction with a Host Bus Adapter (HBA) to speed up testing in a development or testing environment. Rather than downloading a new bit stream into the FPGA to reprogram it, HBA is used to convert traffic from the FPGA to a protocol specific to the DUT. For example, an FPGA may initially be programmed to communicate using the PCIe protocol. The HBA may be configured to convert incoming PCIe signals to SATA or SAS signals for testing of SATA or SAS DUTs, respectively. Alternatively, the HBA may be configured to convert incoming PCIe signals to some third party proprietary protocol that can only "drop in" through the HBA into the tester system.

Fig. 10 illustrates one manner in which an HBA including a protocol converter IP may be used to connect an FPGA to a DUT that communicates in a different protocol than the protocol in which the FPGA is programmed, according to an embodiment of the invention. Embodiments of the present invention invoke the use of an HBA 1008 that includes a protocol converter IP 1004 (e.g., including a proprietary third party protocol) to provide protocol flexibility. Protocol converter IP 1004 converts incoming traffic input to input HBA interface 1040 from one protocol to a different protocol output on HBA output interface 1042.

In one embodiment, the HBA 1008 with protocol converter IP 1004 is used in conjunction with hardware accelerators and IP cores 1010 on the FPGA1002 to test DUTs that support different protocols. In one implementation, the hardware accelerator (e.g., hardware accelerator block 440 of fig. 4) may be part of the IP core 1010, but in a different implementation, the hardware accelerator may be a separate module from the IP core 1010.

In the embodiment of FIG. 10, instead of reprogramming the FPGA with a protocol that matches the coupled DUT, the HBA is used to convert traffic from the FPGA to a protocol supported by the DUT. In some test environments, this is necessary because it takes time to reprogram the FPGA. Furthermore, there may be some situations in a development environment, for example, an FPGA may not support a particular protocol. The use of HBAs avoids the delays associated with reprogramming an FPGA or developing FPGA firmware for protocols not currently supported. Furthermore, the IP core configured within the FPGA may be proprietary to some third parties, while using HBAs avoids the need to tamper with proprietary cores from third parties. For example, the third party proprietary protocol IP may not allow integration into an FPGA and may require stand alone use as part of the HBA.

Furthermore, as the time-to-market for tester systems becomes shorter, there is a need for a flexible tester system that: the system allows a test engineer to quickly switch between DUTs supporting different protocols without having to reconfigure the FPGA. The embodiment of fig. 10 provides the following tester system: the tester system combines an FPGA IP core and hardware accelerator with an HBA (e.g., with a third party IP protocol) to flexibly switch between testing DUTs that support various protocols. In one embodiment, FPGA1002 can receive input signals 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 input interface 1001. The input interface 1001 may, for example, comprise a high speed serial protocol interface such as PCIe. The hardware accelerator and IP core 1010 implemented on the FPGA may be configured to communicate using a particular protocol (e.g., PCIe). Thus, the FPGA1002 can connect to a PCIe DUT, but it will not be able to communicate with DUTs that support any other protocol.

In one embodiment, in a test or development environment, if a DUT that supports a protocol other than PCIe needs to be tested, the DUT may be tested using the HBA 1008 with protocol converter IP 1004 (e.g., with a third party proprietary protocol) with the same tester, rather than reprogramming the FPGA. In one implementation, the HBA 1008 includes a protocol converter 1004 (or third party IP), which protocol converter 1004 acts as a protocol converter and converts traffic from one protocol to another. Thus, the HBA 1008 converts incoming signals (e.g., PCIe signals) on the interface 1040 to different protocols supported by the DUT. In this way, the HBA protocol interface 1042 to the DUT1055 will support the protocol corresponding to the DUT 1055.

Embodiments of the present invention advantageously allow FPGA1002 to quickly use third party IP to implement other protocols without reprogramming the FPGA. Embodiments of the present invention also provide better time-to-market for tester systems. By allowing the protocol IP cores to be interchangeable, it is advantageous to speed up time-to-market for tester system customers.

In one embodiment, the tester system may be shipped to a client of the tester system that supports a particular protocol (e.g., PCIe). At the client site, instead of reprogramming the FPGA in the tester, the client need only add the HBA to a tester system with a third party IP (or protocol converter IP) that supports a different protocol (e.g., SATA or some other proprietary protocol). In this manner, the client is able to 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 (through interface 1040) may be PCIe signals and the output includes SAS signals. For example, PCIe input to protocol converter IP block 1004 through interface 1040 may be converted to a different protocol on interface 1042, such as SAS for testing SAS DUT 1055.

In one implementation, the HBA 1008 in conjunction with an accelerator engine of the FPGA (e.g., the hardware accelerator block 440 of fig. 4) creates traffic for the protocol at a faster throughput than is supported by combining the HBA with the processor. For example, in FIG. 1, tester processor 101 is used in conjunction with hardware bus adapter slot 110A. The tester system of fig. 1 is inefficient because the HBA is limited to receiving and transmitting data at the slower speed at which the tester processor 101 generates data.

In contrast, in the embodiment of fig. 10, the HBA is used in conjunction with the FPGA hardware accelerator block 440 to provide high speed support for protocols that are not or cannot be implemented on an FPGA (e.g., due to third party proprietary limitations). In one implementation, the HBA is able to keep up with the high speed data generation and transmission 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 data. Thus, neither the tester processor (e.g., tester processor 304 of FIG. 3) nor the HBA will become a bottleneck during a data transaction.

Note that the FPGA can be disposed on a site module board 1060 (similar to site module 310A of fig. 3), while the DUT1055 can be disposed on a device interface board 1064 (similar to load board 380 of fig. 3). The HBA 1008 may be disposed on a sandwich board 1062 that is coupled to both the station module board 1060 and the device interface board 1064. In one embodiment, the HBA 1008 may be located between the station module board 1060 and the device interface board 1064.

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

The FPGA sends test signals (e.g., PCIe signals) to one or more HBAs 1106 disposed on a sandwich panel 1107, where each HBA includes a protocol converter IP on the sandwich panel 1107. Note that the number of HBAs arranged on the sandwich panel depends on the type of HBA selected. In addition, the number of DUTs 1110 connected to each HBA also depends on the HBA selected.

In the implementation shown in FIG. 11, the protocol converter IP within each HBA may convert PCIe signals from the FPGA to another protocol (e.g., SAS signals) to test the DUT 1110. This allows the tester to test DUTs configured with different protocols by directly using third party protocols that are not integrated within the FPGA without reprogramming the FPGA. It should be noted that an FPGA may be configured to implement any of several protocols and is not limited to PCIe. Similarly, the HBA may 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) within the associated FPGA. As described in connection with fig. 2, each FPGA may have multiple instantiated FPGA tester blocks, where each block includes its own accelerator engine. In one implementation, each accelerator engine may be coupled with its own respective DUT. In one implementation, each HBA may be coupled with N instantiated FPGA tester blocks. Because each instantiated FPGA tester block includes its own accelerator engine, each HBA can be coupled with N accelerator engines.

In one implementation, each HBA may also be connected to N DUTs, where each accelerator engine may be connected to its own respective DUT. In one implementation, N-4, and each HBA may be connected to 4 instantiated FPGA tester blocks and 4 DUTs, where each DUT will be associated with its own accelerator core. It should be noted, however, that embodiments of the present invention are not so limited. Each accelerator engine may be connected to more than one DUT, and each HBA may be connected to any number of DUTs.

FIG. 12 illustrates an exemplary tester configuration with each DUT connected to a corresponding accelerator engine, according to an embodiment of the invention. As shown in fig. 12, the FPGA includes multiple accelerator cores, e.g., 1201, 1202, 1203, and 1204. As discussed above, each accelerator core may operate in either pattern generator mode (APG mode) or full accelerator mode (FA mode). Each accelerator core communicates with an IP core 1205. Accelerator core 1201 and IP core 1205 together perform substantially the same functions as block 1010 of FIG. 10. In the example shown in FIG. 12, the IP core 1205 is a PCIe core, and thus, the FPGA implements the PCIe protocol.

PCIe signals from the FPGA are sent to the sandwich 1215. The HBA 1206 may be one of several HBAs disposed on a sandwich panel 1215. In this example, the HBA 1206 receives PCIe signals and converts them to signals that conform to the SAS protocol. In one implementation, the SAS protocol may be provided as a proprietary third party protocol IP, which may be discarded into the design without requiring modification or inspection thereof. The HBA 1206 is communicatively coupled with 4 DUTs, where each DUT 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 process, according to an embodiment of the invention: DUTs that communicate in a different protocol than the protocol implemented on (integrated in) the FPGA in the tester system are tested. However, the present invention is not limited to the description provided by flowchart 1300. Rather, other functional flows will be apparent to those skilled in the relevant art(s) from the teachings provided herein and are within the scope and spirit of the present invention.

At block 1310, a system controller is coupled to the tester processor and the FPGA. The system controller may be a Windows-based operating system as described 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 are generated to test the plurality of DUTs in accordance with the first protocol implemented in the IP core of the FPGA and in accordance with the selected acceleration pattern. The acceleration mode may be a standard mode or a bypass mode in which the tester processor generates all commands and data while 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 the commands and data transmitted using the first protocol are converted by the HBA to signals including commands and data transmitted in the second protocol. In one embodiment, the HBA includes a protocol converter IP block 1004, the protocol converter IP block 1004 converting command and data signals transmitted using a first protocol to a second protocol. In other words, the third party protocol IP within 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, signals associated with the second protocol are forwarded to the DUT for testing.

The foregoing description, for purpose of explanation, 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. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as may be suited to the particular use contemplated.

Claims (20)

1. An Automated 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 tester processor is operable to generate commands and data to coordinate testing of a plurality of Devices Under Test (DUTs) in accordance with the instructions;

an FPGA communicatively coupled to the tester processor, wherein the FPGA includes hardware accelerator circuitry operable to transparently generate commands and data from within the tester processor to test a DUT of the plurality of DUTs; and

a bus adapter comprising a protocol converter module operable to convert signals associated with a 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.

2. The system of claim 1, further comprising a memory device associated with the FPGA, wherein the memory device stores test pattern data to be written to the DUT.

3. The system of claim 1, wherein the signals associated with the first protocol comprise commands and data generated by the tester processor or the FPGA according to a selected acceleration pattern associated with the hardware accelerator circuit.

4. The system of claim 1, wherein the first protocol is a PCIe protocol and the second protocol is a SAS protocol.

5. The system of claim 1, wherein the bus adapter is implemented on a circuit board disposed between a site module board comprising the FPGA and a device interface board comprising the DUT.

6. The system of claim 1, wherein the FPGA comprises an on-chip IP core to generate signals associated with the first protocol, and wherein the second protocol is a third party proprietary protocol.

7. The system of claim 1, wherein the tester processor is configured to operate in one of a plurality of functional modes configured to distribute functions for generating commands and data between the tester processor and the FPGA.

8. The system of claim 1, wherein the protocol converter module is configured to interface with the hardware accelerator circuitry and receive signals associated with the first protocol at a speed at which the hardware accelerator circuitry generates signals associated with the first protocol.

9. An Automated Test Equipment (ATE) apparatus, comprising:

a tester processor operable to generate commands and data to coordinate testing of a plurality of Devices Under Test (DUTs);

an FPGA communicatively coupled to the tester processor, wherein the FPGA includes hardware accelerator circuitry operable to transparently generate commands and data from within the tester processor to test a DUT of the plurality of DUTs, and wherein the FPGA includes an IP core operable to generate signals for transmitting commands and data from the FPGA to the DUT using a first protocol; and

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.

10. The apparatus of claim 9, further comprising a memory device associated with the FPGA, wherein the memory device stores test pattern data to be written to the DUT, and wherein the second protocol is a third party proprietary protocol.

11. The apparatus of claim 9, wherein the signals associated with the first protocol comprise commands and data generated by the tester processor or the FPGA according to a selected acceleration pattern associated with the hardware accelerator circuit.

12. The apparatus of claim 9, wherein the first protocol is a PCIe protocol and the second protocol is a SAS protocol.

13. The apparatus of claim 9, wherein the bus adapter is implemented on: a board disposed between a site module board including the FPGA and a device interface board including the DUT.

14. The apparatus of claim 9, wherein the tester processor is configured to operate in one of a plurality of functional modes configured to distribute functions for generating commands and data between the tester processor and the FPGA.

15. The apparatus of claim 9, wherein the protocol converter module is configured to interface with the hardware accelerator circuitry and receive the signal associated with the first protocol at a speed at which the hardware accelerator circuitry generates the signal associated with the first protocol.

16. A method of testing a DUT, comprising:

sending instructions from a system controller to a tester processor, wherein a tester board comprising an FPGA and a 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);

generating commands and data to test a DUT of a plurality of DUTs according to a first protocol implemented in an IP core of the FPGA and according to a selected acceleration pattern, wherein the generating is performed by hardware accelerator circuitry included within the FPGA;

sending signals associated with the commands and data from the FPGA to a bus adapter using a first protocol;

converting, using the bus adapter and a protocol IP core implementing a second protocol, signals communicated using the first protocol to signals of the second protocol, wherein the bus adapter is communicatively coupled to a DUT operable to communicate using the second protocol; and is

Forwarding signals in the second protocol to the DUT for testing.

17. The method of claim 16, wherein the bus adapter comprises a protocol converter module configured to perform the converting, and wherein the protocol IP core is third party proprietary.

18. The method of claim 16, wherein the first protocol is a PCIe protocol and the second protocol is a SAS protocol.

19. The method of claim 16, wherein the bus adapter is implemented on a circuit board disposed between a site module board comprising the FPGA and a device interface board comprising the DUT.

20. The method of claim 17, wherein the protocol converter module is configured to interface with the hardware accelerator circuitry and receive the signal associated with the first protocol at a speed at which the hardware accelerator circuitry generates the signal associated with the first protocol.

Images