CN113327642B

CN113327642B - Software-centric solution for arbitrary full data non-standard sector size support

Info

Publication number: CN113327642B
Application number: CN202110224734.8A
Authority: CN
Inventors: 斯德詹·马利西奇; 迟·阿尔伯特·袁
Original assignee: Advantest Corp
Current assignee: Advantest Corp
Priority date: 2020-02-28
Filing date: 2021-03-01
Publication date: 2024-06-11
Anticipated expiration: 2041-03-01
Also published as: TW202207237A; CN113327642A; TWI779458B

Abstract

The present disclosure provides a software-centric solution supported by any full data non-standard sector size. An Automated Test Equipment (ATE) system includes a computer system including a system controller, wherein the system controller is communicatively coupled to a tester processor, wherein the system controller is configured to send instructions to the tester processor. The tester processor is configured to generate commands and data for coordinating testing of a Device Under Test (DUT) in accordance with the instructions, wherein the DUT supports any sector size, and wherein a software layer on the tester processor performs computations to be able to control data flow between the tester processor and any size sector in the DUT.

Description

Software-centric solution for arbitrary full data non-standard sector size support

Cross Reference to Related Applications

The present application is a continuation-in-part application from U.S. patent application Ser. No. 16/227,389, entitled "Automated Test Equipment (ATE) support frame (AUTOMATED TEST EQUIPMENT(ATE)SUPPORT FRAMEWORK FOR SOLID STATE DEVICE(SSD)ODD SECTOR SIZES AND PROTECTION MODES)", for Solid State Device (SSD) nonstandard sector size and protection mode," filed on 12/20/2018, entitled Srdjan Malisic, micahel Jones and Albert Yuan, attorney docket No. ATSY-0062-01.01US, the entire contents of which are incorporated herein by reference for all purposes.

The present application also claims priority from U.S. provisional application 62/983,118, entitled "software only solution for any full data non-standard sector size support," docket number ATSY-0080-00.00US, filed on 28, 2020. 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 testing systems, and more particularly to the field of electronic device testing equipment for testing Devices Under Test (DUTs), such as Solid State Drives (SSDs).

Background

Automated Test Equipment (ATE) may be any test component that performs testing on semiconductor devices or electronic components. The ATE component can be used to perform automated testing that quickly performs measurements and generates test results that can then be analyzed. The ATE assembly may be any device ranging from a computer system coupled to a meter to a complex automated test assembly that may include a custom dedicated computer control system and many different test instruments capable of automatically testing electronic components and/or semiconductor wafer tests (e.g., system on a chip (SOC) tests or integrated circuit tests). ATE systems both reduce the time spent testing equipment to ensure that the equipment functions are designed, and act as a diagnostic tool to determine whether a faulty component exists for a given piece of equipment before reaching the consumer.

Fig. 1 is a schematic block diagram of a conventional automatic test equipment body 100 for testing certain 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 via cables dedicated to the respective protocol. The ATE body 100 also includes a test processor 101 with associated memory 108 for controlling hardware components built into the ATE body 100 and generating commands and data necessary to communicate with the DUT under test through the hardware bus adapter card. Tester processor 101 communicates with a hardware bus adapter card via system bus 130. The tester processor can 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 that are installed on an expansion or adapter card that is inserted into ATE body 100.

The ATE body 100 tests the electrical functions of DUTs 112A-112N connected to the ATE body 100 through hardware bus adapters that are plugged into the hardware bus adapter slots of the ATE body 100. Thus, tester processor 101 is programmed to use a protocol specific to the hardware bus adapter to deliver test programs to the DUT. At the same time, other hardware components built into the ATE body 100 communicate signals with each other and with the DUT according to the test program running in the tester processor 101.

The test program run by tester processor 101 may include functional tests involving: the input signal generated by pattern generator 102 is written to the DUT, the written signal is read from the DUT, and the output is compared to the desired pattern using comparator 106. If the output does not match the input, the tester processor 101 identifies the DUT as defective. For example, if the DUT is a memory device such as DRAM, the test program will write data generated by 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 comparator 106.

In conventional systems, the tester processor 101 needs to contain functional logic blocks to generate commands and test patterns for use in testing the DUT (e.g., pattern generator 102 and comparator 106), which are programmed directly on the processor in software. 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) semiconductor device that can program logic circuits according to user requirements.

FPGAs used in conventional systems rely on tester processor 101 to send commands and test patterns to the FPGA, which in turn forwards these commands and test patterns to the DUT. 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.

Also, in conventional systems, the communication protocol used to communicate with the DUT is fixed, as the hardware bus adapter card inserted into the ATE body 100 is designed to communicate in only one protocol and cannot be reprogrammed to a single-purpose device that communicates in a different protocol. For example, an ATE body configured to test PCIe devices will have a hardware bus adapter card inserted into the body and supporting only PCIe protocols. To test DUTs supporting a different protocol (e.g., SATA), a user typically needs to replace the PCIe hardware bus adapter card with a bus adapter card supporting the SATA protocol. Unless PCIe hardware bus adapter cards are physically replaced with cards supporting other protocols, such systems can only test DUTs supporting PCIe protocols. Therefore, on a test platform, replacing a hardware bus adapter card consumes critical time when it is required to test a DUT that runs a different protocol than that supported by an existing adapter card.

One drawback of conventional tester systems is that these test systems currently do not support testing DUTs (e.g., SSDs) having a non-standard sector size that contains full data, e.g., DUTs having a non-standard sector size that does not contain any protection information (non-PI). For example, most commercially available Solid State Drives (SSDs) are formatted to have a standard sector size, e.g., 4096 bytes per sector, 512 bytes per sector. Most modern hard disk drives use one of two standard sector sizes: 512 bytes per sector or 4096 bytes per sector. However, some vendors also support full data non-standard sector sizes, e.g., 520 Bytes Per Sector (BPS) or 528 Bytes Per Sector (BPS), particularly for drives to be used in enterprise-level systems.

These drives have an overall sector size dedicated to user data storage rather than using additional sizes for system use (e.g., protection information). Each byte of data in each sector (520 bytes or 528 bytes) is accessible to device users. The tester system cannot strip the additional bytes like a drive with additional bytes of Protection Information (PI). In addition, the tester system needs to access all sectors of the drive that include additional bytes of data. Most operating systems cannot handle such drivers. Thus, conventional ATE testing on SSDs is limited because it does not support testing of drives with full data non-standard sector sizes.

Disclosure of Invention

Accordingly, there is a need for a tester architecture that addresses the above-described system problems. What is needed is a tester system that supports software-level testing of DUTs (e.g., SSDs) that include full data non-standard sector sizes. Furthermore, there is a need for a tester system that is capable of handling all data sector SSDs for any sector size, including non-standard sizes that vary by software. For example, SSDs may have non-standard sector sizes of 520BPS, 4104BPS, 528BPS, and 4224BPS (or even any other arbitrary sector size). What is needed is a tester system that can seamlessly and efficiently test SSDs having arbitrary sector sizes (where the sectors include data).

In one embodiment, an Automated Test Equipment (ATE) system is disclosed. The system includes a computer including a system controller, wherein the system controller is communicatively coupled to a tester processor, wherein the system controller is configured to send instructions to the tester processor. The tester processor is for generating commands from the instructions and for coordinating testing of a Device Under Test (DUT), wherein the DUT supports any sector size, and wherein a software layer on the tester processor performs calculations to be able to control data flow between the tester processor and any size sector in the DUT.

In another embodiment, a method for testing using Automated Test Equipment (ATE) includes: instructions are sent from a system controller of a computer system to a tester processor, wherein the system controller is communicatively coupled to the tester processor. The method further comprises the steps of: commands are generated using a tester processor and belong to a test for coordinating a Device Under Test (DUT), wherein the DUT supports a plurality of arbitrary full data sector sizes, and wherein a software layer on the tester processor performs computations to be able to control data flow between the tester processor and the plurality of arbitrary full data sector sizes in the DUT.

Further, there is a need for a test architecture by which command and test pattern generation functions can be transferred onto an FPGA so that processing load on the tester processor and bandwidth requirements on the system bus can be kept to a minimum. Furthermore, there is a need for a test architecture by which a communication protocol engine can be programmed on an FPGA device so that the protocol used to communicate with the DUT can be reconfigured.

In various embodiments, an Automated Test Equipment (ATE) apparatus comprises: a computer system comprising a system controller, wherein the system controller is communicatively coupled to a tester processor and an FPGA, wherein the system controller is configured to send instructions to the tester processor, and wherein the tester processor is configured to generate commands and data based on the instructions for coordinating testing of a Device Under Test (DUT), wherein the DUT supports a plurality of non-standard full data sector sizes. The FPGA is communicatively coupled to the tester processor, wherein the FPGA includes at least one hardware accelerator circuit for transparently generating commands and data from within the tester processor for testing the DUT. Further, the tester processor is configured to operate in one of a plurality of functional modes, wherein each functional mode is configured to distribute functions for generating commands and for generating data between the tester processor and the FPGA in a different manner, and wherein in a standard mode the tester processor is configured to generate all commands and data for coordinating testing of DUTs comprising a plurality of non-standard full data sector sizes.

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 in which like reference numerals refer to similar elements.

Fig. 1 is a schematic block diagram of a conventional automatic 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 in accordance with one embodiment of the present invention.

FIG. 3 is a detailed schematic block diagram of a site module and its interconnection with a system controller and DUT in accordance with an embodiment of the invention.

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

FIG. 5 is a high-level flow chart of an exemplary method of testing a DUT in accordance with an embodiment of the invention.

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

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

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

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

Fig. 10 illustrates primitives that interface with a Device Interface Board (DIB) according to an embodiment of the present invention.

FIG. 11 is an exemplary high-level block diagram of an automatic test equipment device in which a host controller is connected to and controls test operations of a plurality of primitives in accordance with an embodiment of the present invention.

FIG. 12A illustrates an application layer including software executing on a tester processor according to an embodiment of the present invention.

FIG. 12B illustrates the functionality of each of the application layers including software executing on the tester processor, according to an embodiment of the invention.

FIG. 13 depicts a flowchart of an example computer-implemented process for testing DUTs supporting arbitrary sector sizes, according to an embodiment of the invention.

FIG. 14 depicts a flowchart of an exemplary computer-implemented process for testing a DUT that supports any sector size in which a tester processor directly controls the DUT, according to an embodiment of the invention.

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

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 drawings, it will be understood that they 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 so as not to unnecessarily obscure aspects of the embodiments.

Part of the expressions and terms

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 "accessing," "adding," "adjusting," "analyzing," "applying," "assembling," "assigning," "computing," "capturing," "combining," "comparing," "collecting," "creating," "debugging," "defining," "drawing," "detecting," "determining," "displaying," "establishing," "executing," "generating," "grouping," "identifying," "initiating," "modifying," "monitoring," "moving," "outputting," "executing," "placing," "presenting," "processing," "programming," "querying," "removing," "repeating," "recovering," "sampling," "simulating," "ordering," "storing," "subtracting," "suspending," "tracking," "transforming," "unlocking," "using," or the like, refer to the actions 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 the blocks and modules are exemplary. Blocks or modules may be combined, integrated, separated, and/or duplicated to support various applications. Additionally, instead of or in addition to the functions performed at the particular modules or blocks described, functions described herein as being performed on a particular module or block may be performed on and/or by one or more other modules or blocks instead of the functions performed at the particular module or block. Furthermore, modules or blocks may be implemented across multiple devices and/or other components, either local or remote to each other. Additionally, a module or block may be moved from one device and added to another device, and/or may be included in both devices. Any software implementations of the invention may be tangibly embodied in one or more storage media, such as, for example, 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 be limiting of the scope of the present invention. As used throughout this disclosure, the singular forms "a," "an," and "the" include 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.

Embodiments of the present invention allow for improved test throughput by including Operating System (OS) support within a tester for testing DUTs (e.g., solid State Drives (SSDs), hard Disk Drives (HDDs), etc.) that support different (e.g., non-standard, or arbitrary) sector sizes without requiring reconfiguration of the hardware. More specifically, the calculations and operations required to support arbitrary or non-standard sector sizes may be performed by a tester processor within the tester system. In other words, in one embodiment, the computing functions for testing any full data sector DUT (e.g., SSD) may be performed in software on a general purpose tester processor. Embodiments of the present invention advantageously increase the number and types of Devices Under Test (DUTs) that can be tested under prevailing hardware and time constraints, for example, by configuring the hardware such that DUTs supporting a plurality of different types of sector sizes can be tested with the same hardware without requiring replacement or substitution of any hardware components. Embodiments of the present invention are directed to improving the testing efficiency of hardware of an automatic test equipment.

Fig. 2 is an exemplary high-level block diagram of an Automatic Test Equipment (ATE) apparatus 200 in which a tester processor is connected to a Device Under Test (DUT) through an FPGA device with built-in functional modules, according to an embodiment of the invention. In one embodiment, ATE apparatus 200 may be implemented within any test system capable of testing multiple DUTs simultaneously. For example, in one embodiment, as shown in FIG. 10, the apparatus 200 may be implemented within a primitive.

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; the system controller is connected to the network switch 202 of the site module boards 230A-230N; including FPGA devices 211A-211M that instantiate FPGA tester blocks 210A-210N; memory block modules 240A-240M, each of which is connected to one of FPGA devices 211A-211M and Devices Under Test (DUTs) 220A-220N, wherein each device under test 220A-220N is connected to one of instantiated FPGA tester blocks 210A-210N. It should be noted that in one embodiment, DUTs 220A-220N may be Solid State Drives (SSDs). Furthermore, as shown in FIG. 2, a single instantiated FPGA tester block may also be connected to multiple DUTs.

In one embodiment, 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 ATE 200. In one embodiment, the system controller 201 may run a Windows Operating System (OS). Verigy stylus software executing in a Windows environment is one example of test software that is typically used during device testing. It provides the user with a graphical user interface for configuring and controlling the test. It may also include functionality for controlling the test flow, controlling the status of the test programs, determining which test program is running, and recording test results and other data related to the test flow. In one embodiment, a system controller may be connected to and control up to 512 DUTs.

In one embodiment, the system controller may be connected to the 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, for example, TCP/IP, 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 loadboard fixture that hosts DUTs 220A-220N and is also attached to the system controller 201 that receives test programs. In other embodiments, the site module board may be implemented as a plug-in expansion card or as a daughter board that plugs directly into the chassis of the system controller 201. Alternatively, the site module board may be housed within the enclosure of the primitive (as shown in fig. 10) and may be connected to various DUTs using a Device Interface Board (DIB).

Site module boards 230A-230N may each include at least one tester processor 204 and at least one FPGA device. In one embodiment, the tester processor and its associated memory may be located on a separate board (not shown) attached to the corresponding site module. This separate board may be referred to as a computer on module (or COM) board. In other words, the FPGA may be located on a separate site module board, whereas the tester processor (with associated memory) is located on a COM board.

The tester processor 204 and FPGA devices 211A-211M on the site module board run 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 x86 CPU or any other well known processor. In addition, the tester processor may operate and run core software on the Ubuntu OS x64 operating system that allows it to communicate with software running on the system controller to run the test methods. In one embodiment, the tester processor 204 may be an x86 processor running a Linux OS or a modified version of a Linux OS. In one embodiment, the Linux OS running on the tester processor is capable of receiving commands and data from the Windows OS running on the system controller. The tester processor 204 controls the FPGA devices on the site module and the DUTs connected to the site module 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, tester processor 204 communicates with each of the FPGA devices 211A-211M through a separate dedicated bus. In one embodiment, for example, in standard or bypass mode, the tester processor 204 can transparently control testing of DUTs 220A-220N through the FPGA, with as little processing functionality allocated to the FPGA devices as possible. In this embodiment, because all commands and data generated by the tester processor need to be transferred to the FPGA device over the bus, the data traffic capacity of the bus 212 can be quickly exhausted. In other embodiments, for example, as discussed further below, the tester processor 204 may share processing load by assigning functionality to the FPGA device for controlling testing of the DUT in a Protocol Independent Data Acceleration (PIDA) or Full Acceleration (FA) mode. In these embodiments, traffic on bus 212 is reduced because 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. In one embodiment, each of the FPGA devices may include two instantiated FPGA tester blocks 210A-210B with functional modules for performing functions including an implementation of a communication protocol engine and hardware accelerator as further described herein. 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 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, instantiating FPGA tester blocks 210A and 210B can share one of the memory modules within memory block 240A. In different embodiments, each FPGA device may have multiple instantiated FPGA tester blocks, each with a corresponding memory block.

Further, 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 testing to be performed for each DUT. The hardware resources in such a configuration are designed in a manner that supports a single DUT with minimal hardware sharing. This configuration also allows for parallel testing of many DUTs, each of which may be connected to its own dedicated FPGA tester block and run different test programs. In different embodiments, each instantiated FPGA tester block may also be connected to and configured to test multiple DUTs.

The architecture of the embodiment of the invention depicted in fig. 2 has several advantages. First, it eliminates the need for protocol specific hardware bus adapter slots and cards in the system, as the communication protocol module can be programmed directly on the instantiated FPGA tester block within the 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 support need to be tested, they can be connected to the same system and the FPGA can be reprogrammed with the relevant protocol supported. 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 bit stream 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 the functionality of one or more protocol-based interfaces for the DUT and that is programmable to interface with the DUT. In many cases, the IP core will include a third party protocol converter IP that converts signals from one protocol to another.

For example, FPGAs 211A-211M in ATE apparatus 200 will include an interface core that may be configured with PCIe protocols to initially test PCIe devices and then reconfigured via software downloads to test SATA devices. The third party protocol converter IP programmed in the FPGA may be configured to convert incoming PCIe signals to SATA signals. In addition, if a new protocol is issued, the FPGA can easily be configured with the protocol via a bitstream download without having to physically switch all hardware bus adapter cards in the system. Finally, if a non-standard protocol needs to be implemented, the FPGA may still be configured to implement such a protocol.

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

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

In one embodiment, the interface or IP core in the FPGA is available from a third party vendor, 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 the physical channel; and 2) an electrical signal generator and receiver.

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 test program specific to it. For example, an instantiated FPGA tester block 210A is connected to DUT 220A and runs test programs specific to DUT 220A. The hardware resources in such a configuration are designed in a manner that supports a single DUT 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, utilizing FPGAs that are capable of generating their own commands and test patterns in certain modes also reduces the bandwidth requirements of the bus 212 that connects the tester processor with other hardware components, including FPGA devices, device Power Supplies (DPSs), and DUTs. As a result, more DUTs can be tested simultaneously than in existing configurations.

FIG. 3 provides a more detailed schematic block diagram of a site module and its interconnection with a system controller and DUT in accordance with an embodiment of the invention.

Referring to FIG. 3, in one embodiment, site modules of an ATE device may be mechanically configured on tester dice 340A-340N, where each tester die includes at least one site module. In some exemplary embodiments, each tester tile may include two site modules and two device power boards. In other embodiments, the tester tile may include more or fewer site modules and/or power boards. For example, tester tile 340A of FIG. 3 includes site modules 310A and 310B and device power boards 332A and 332B. However, the number of device power boards or site modules that can be configured onto a tester chip is not limited. The tester chip 340 is connected to the system controller 301 through the network switch 302. The system controller 301 and the network switch 302 perform the same functions as the elements 201 and 202 in fig. 2, respectively. The network switch 302 may be connected to each site module using a 32-bit wide bus.

As described above, in one embodiment, system controller 301 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 for DUTs connected to ATE 300. Typically, the system controller will run the Windows operating system. An Advantest stylus is one example of test 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 functionality for controlling the test flow, controlling the status of the test programs, determining which test program is running, and recording test results and other data related to the test flow.

Each of the device power strips 332A-332B may be controlled from one of the field modules 310A-310B. Software running on tester processor 304 may be configured to allocate device power to specific 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, such as peripheral component interconnect express (PCIe), serial AT-link (SATA), or Serial Attached SCSI (SAS).

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

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

FPGAs 316 and 318 can be connected to DUTs 372A-372M on load board 380 via buses 352 and 354, respectively. The load board 380 is a physical harness that allows for universal high speed connections at the field module end that is agnostic to the protocol used to communicate with the DUT over 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 invention, DUTs 372A-372M are loaded on load plate 380 that is placed within hot chamber 390 for testing. DUTs 372A-372M and load board 380 obtain power from 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.

In one embodiment, the communication protocol used to communicate between tester processor 304 and DUTs 372A-M may advantageously be reconfigurable. The communication protocol engine in such an embodiment is programmed directly into one or both FPGAs on the tester chip. The FPGA (e.g., 316 or 318) can thus be configured to communicate with the DUT in any protocol supported by the DUT. This advantageously eliminates the need to swap out a tester each time a DUT having a different protocol needs to be tested. In one embodiment, the protocol may be a high speed serial protocol including, but not limited to, SATA, SAS, or PCIe, among others. The new or modified protocol may be downloaded directly from the system controller via a simple bit stream download by the tester processor and installed on the FPGA without any type of hardware interaction. In addition, if a new protocol is released, the FPGA can be easily configured with the protocol via software download.

In one embodiment of the invention, each FPGA comprises a plurality of protocol engine modules, wherein each protocol engine module within the FPGA device can be configured with a different communication protocol. Thus, FPGA devices can 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 simultaneously test all modules running on the device. For example, if the FPGA is configured to run both PCIe and SATA protocols, it can be connected to test DUTs supporting both PCIe and SATA protocols. Alternatively, it may be connected to test two different DUTs, one DUT supporting the PCIe protocol and the other DUT supporting the SATA protocol.

Referring to FIG. 4, an instantiated FPGA tester block 410 is connected to the tester processor through PCIe upstream port 270 and to the DUT through 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, logic block module 450 includes: decoding logic for decoding commands from the tester processor; routing logic for routing all incoming commands and data from the tester processor 304 and data generated by the FPGA device to the appropriate modules; and arbitration logic to arbitrate between the various communication paths within the instantiated FPGA tester block 410.

In one embodiment, 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 that instantiates the FPGA tester block 410. Thus, the instantiated FPGA tester block 410 can be configured to communicate with the DUT in any protocol supported by the DUT. For example, the pre-validated interface or IP core described 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 the tester flexibility because the IP core enables software-based changes of the interface. Embodiments provide the ability to test multiple types of DUTs independent of the hardware bus adapter socket. With such interface flexibility, new interfaces can be loaded into the IP core of the programmable chip, eliminating the need for a hardware bus adapter slot (discussed with respect to fig. 1).

In one embodiment, for example, for a storage device/SSD/HDD, each FPGA includes a configurable IC connected to the SSD and programmable to provide a storage-based mode through a storage-specific interface such as SATA or SAS.

In one embodiment, the FPGA may be an SSD 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 standardized protocol based communication interface. For example, in one embodiment, in the case of SSD module-based testing, the interface core may be programmed to provide a standardized protocol-based communication interface such as SATA, SAS, or the like.

Thus, from an electrical perspective, FPGAs utilize IP cores rather than hardware bus adapter slots. By software programming the programmable chip resources of the FPGA, a given IP core can be easily reprogrammed and replaced with another IP core without changing the physical FPGA chip or other hardware components. For example, if a given FPGA-based tester currently supports SATA, all that is required to be able to connect to a SAS DUT is to reprogram the FPGA to use a SAS IP core rather than configuring an existing IP core for SATA.

This advantageously eliminates the need for a hardware bus adapter card and eliminates the need for replacement protocol specific hardware to test DUTs with different protocol support. In one embodiment, the protocol may be a high speed serial protocol including, but not limited to, SATA, SAS, or PCIe, among others. The new or modified protocol may be downloaded directly from the system controller via a simple bit stream download by the tester processor and installed on the FPGA without any type of hardware interaction. In addition, if a new protocol is released, the protocol can be easily configured by a software download FPGA.

In fig. 4, if the DUT coupled to PCIe downstream port 480 is a PCIe device, an instantiated bit file containing the PCIe protocol may be downloaded through PCIe upstream port 470 and installed in an IP core on 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 within the FPGA device can be configured with a different communication protocol. Thus, FPGA devices can 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 simultaneously test all modules running on the device. For example, if the FPGA is configured to run both PCIe and SATA protocols, it can be connected to test DUTs supporting both PCIe and SATA protocols. Alternatively, it may be connected to test two different DUTs, one DUT supporting the PCIe protocol and the other DUT supporting the SATA protocol.

The hardware accelerator block 440 of fig. 4 may be used to accelerate certain functions on FPGA hardware, rather than executing in software on a tester processor. 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 testing of the DUT. To generate test pattern data, the accelerator block 440 uses an algorithm 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. Comparator module 446 includes functionality for marking mismatch to tester processor 304 to identify non-conforming devices. More specifically, comparator module 446 may include an error counter that tracks the mismatch and communicates it to tester processor 304.

The hardware accelerator block 440 may be connected to the local memory module 420. Memory module 420 performs similar functions as the 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 it 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 record faults. The memory module will store a log file with a record of all faults experienced by the DUT during testing. In one embodiment, the accelerator block 440 has a dedicated local memory module block 420 that is inaccessible 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. The memory control module 444 interacts with the memory module 420 and controls read and write access to the memory module 420.

Finally, hardware accelerator block 440 includes packet builder module 445. In some modes, a packet builder module is used by the hardware accelerator module to construct packets including header/command data and test mode data to be written to the DUT.

In one embodiment, 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 generic high-speed connector 481 is required on the site module. Thus, if a change is required to the protocol implemented on the protocol engine module 430, no incidental physical modification is required on the site module. The site module is connected to the DUT using a load board 380, the load board 380 being connectable to a generic connector on the site module side, but 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 loadboard needs to be switched and replaced.

Fig. 10 illustrates a primitive 1010 interfacing with a Device Interface Board (DIB) 1000 according to an embodiment of the present invention. Similar to the tester chip shown in FIG. 3 (e.g., 340A, etc.), the primitive of FIG. 10 is a type of discrete test module that fits into a test head and includes test circuitry that performs tests on DUTs according to a test plan. The primitive includes a housing 1050, and all of the various electronic devices (e.g., site modules, power supplies, etc.) are housed in the housing 1050. DIB1000 may connect with multiple DUTs 1020 using custom connectors that are sized for DUTs 1020. The DUT physically interfaces with DIB1000 and electronically. The primitive may also include a shell 1070.DIB1000 interfaces with a generic backplane (not shown) of cells 1010 (via a load board (not shown) similar to load board 380 shown in fig. 3.) cells 1010 contain test circuitry (similar to tester tile 340A shown in fig. 3) for performing a test plan on DUT 1020. Cells 1010 may operate independently of any other cells and connect to a control server (similar to system controller 301 shown in fig. 3).

It should be noted that DUTs connected to any given tester chip (e.g., 340A-340N) or any given primitive can run different protocols than one or more other DUTs connected to the same corresponding tester chip or primitive. For example, primitives 1010 may be connected to multiple DUTs 1020 and used to test the multiple DUTs 1020, each of which may run a different protocol, such as SATA, ATA, SCSI, etc. In one embodiment, primitive 1010 may be connected to and used to primarily test an SSD drive.

FIG. 11 is an exemplary high-level block diagram of an Automatic Test Equipment (ATE) device in which a host controller is connected to and controls the testing operations of a plurality of primitives, according to an embodiment of the present invention. Fig. 11 illustrates an overall integrated system or test framework 1105 for testing SSDs supporting various non-standard sector sizes (or non-standard sector sizes) and protection modes.

In one embodiment, windows-based host controller 1110 can be communicatively coupled to several different primitives, such as 1130A and 1130B. The Windows-based host controller 1110 can display a graphical user interface to a user for displaying information and accepting user input. Communication backplane 1120 is coupled between host controller 1110 and one or more primitives 1130A and 1130B. Each primitive includes a plurality of tester tiles (e.g., tester tiles 340A-340N). In one embodiment, each primitive may include a plurality of COM boards 1140 (including a tester processor and associated memory) coupled to a plurality of FPGA tester chips 1150 via drivers 1160. (As previously mentioned, in one embodiment, the tester processor may be located on a COM board that is a separate board from the tester chip containing the FPGA). In one embodiment, the tester chip is coupled to the DUT (e.g., SSD) via a device interface board 1165. Different DIBs may be used to support SSDs of different form factors and connection types. Within the chassis may be a number of primitives, with each primitive coupled to and controlled by a host controller. This allows for testing of a large number of DUTs at the same time.

In one embodiment, COM board 1140 may contain an example of an embedded OS platform in accordance with the invention. COM board 1140 may control tester chips 1150 within the primitives. The embedded OS platform is configured to communicate with host controller 1110 on one side and with various FPGA tester chips 1150 populated within the primitives on the other side. In one embodiment, the embedded OS platform may be a heavily modified version of the Linux OS. Up to 32 examples of embedded OS platforms are available within system 1105 and controlled by host controller 1110. Various OS platforms provide functionality to communicate with FPGA test board 1150 and directly with DUTS 1170.

In certain embodiments, the hardware accelerator block 440 may be programmed by the tester processor 304 to operate in one of several hardware acceleration modes.

I. Multiple hardware acceleration modes

In bypass or standard 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. Note that in one embodiment, bypass or standard mode is used to enable testing of non-standard or arbitrarily sized full data sector DUTs. In other words, in one embodiment, the bypass mode includes a feature according to which the tester processor performs calculations to test DUTs having any sector size.

It should also be noted that in one embodiment, the tester processor 304 can communicate directly with the DUT to test non-standard or arbitrarily sized full data sector DUTs. In other words, in this embodiment, an FPGA (with its programmable core and various configurable modes of operation) is not necessary, as the tester processor 304 can communicate directly with the DUT.

In the hardware accelerator mode generator mode, test mode data is generated by the APG module 443 and commands are generated by the tester processor 304. Test packets are sent to the DUT via path 474. This mode is also referred to as Protocol Independent Data Acceleration (PIDA) mode.

In the hardware accelerator memory mode, when the tester processor 304 generates commands, test pattern data is accessed from a local memory module 420 associated with the FPGA. Test pattern data is sent to the DUT via path 476. Routing logic 482 needs to arbitrate between paths 472, 474, and 476 to control the flow of data to the DUT.

In the hardware accelerator packet builder mode, test pattern data may be generated by the APG module 443 and the packet builder module 445 of the FPGA is used to construct packets including header/command data and test pattern data to be written to the DUT. Test packets are sent to the DUT via path 474. This mode is also referred to as Full Acceleration (FA) mode.

Fig. 5 depicts a flowchart 500 of an exemplary process of testing a DUT according to an embodiment of the invention. However, the present invention is not limited to the description provided by flowchart 500. Rather, other functional flows are within the scope and spirit of the present invention as will be apparent to those of ordinary skill in the relevant art in view of the teachings provided herein.

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 a setup and loads a test program into a system controller. Initiating the setup may include selecting one or more protocols from a library of available protocols to configure onto FPGA devices in ATE apparatus 200. These protocols are cached as files on the system controller 301 and can be downloaded as bit files onto the FPGA. The user may select a protocol from the list of available versions through a graphical user interface. The protocol must be built, tested and integrated into the version before it is available as an option. The published FPGA configuration contains definitions of the protocols supported 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 on the system or host controller.

At block 502, the user also loads a test program into the system controller 301 through a graphical user interface. The test program defines all the parameters of the test that need to be run on the DUT. At block 504, the system controller sends instructions to the tester processor on 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 can determine a hardware acceleration mode for running a test on the DUT connected to the site module 310A.

In one embodiment, the tester processor 304 may operate in one of four different hardware acceleration modes. Each functional mode is configured to allocate functions for generating commands and test data between tester processor 304 and FPGAs 316 and 318. In one embodiment, the tester processor can be programmed to operate in a bypass or standard mode, where 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 mode generator mode (or PIDA mode) in which pseudorandom or random data for testing DUTs 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 can be programmed to operate in a hardware accelerator memory mode, wherein during initial setup, the test mode is pre-written by the tester processor onto memory modules connected to each FPGA 316 and 318. In this mode, the FPGA accesses the 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 to 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 (or full acceleration mode), wherein 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 the test is to be run.

It should be noted that FPGA 1035 of fig. 10 can be programmed into any of the four functional modes described above (i.e., bypass mode, hardware accelerator mode generator mode, hardware accelerator memory mode, and hardware accelerator packet builder mode). In one embodiment, the computer or system controller to which the tester card 1000 is connected via connector 1010 will perform the functions of the tester processor 304.

I.A) bypass (or Standard) 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 are within the scope and spirit of the present invention as will be apparent to those of ordinary skill in the relevant art in view of the teachings provided herein.

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 commands and packet headers for test packets to be routed to the DUT. At block 604, the tester process 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 instantiated FPGA block 410 and 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 transparently passed directly to the DUT through the instantiated FPGA block 410, except for some limited exceptions. In bypass mode, the tester processor 304 directly controls the DUT. Although the 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 then marks the mismatch to the user.

It should be noted that the bypass or standard mode is the primary mode of operation for testing a full data non-standard sector size DUT. In other words, full data non-standard sector sized DUTs may be tested using only bypass or standard modes and connecting the tester processor directly to the DUT or through an FPGA (where the FPGA acts as a pass-through device) to the DUT. Other modes of operation (e.g., PIDA or full acceleration) are not important for testing a DUT of full data non-standard sector size.

Arbitrary full data non-standard sector size support in standard mode

In one embodiment, standard (or bypass) mode is used when testing DUTs with sectors of arbitrary size for full data (e.g., SSD DUTs). Note that while bypass mode is utilized to test DUTs of any size sectors, the speed of tester processor 304 may be limited because its processing power may be quickly maximized due to all of the commands and test data that are generated by the DUTs.

Embodiments of the present invention configure software (e.g., software executing on tester processor 304 of fig. 3) to provide a system that can handle testing of all data sector SSDs of any sector size, including non-standard sizes. In contrast, conventional tester systems do not provide any sector size testing. For example, linux-based systems only support sectors of 512 bytes or 4096 bytes in size. Most other systems use hardware to hide non-standard data sector sizes and there are limits to the supported sizes.

FIG. 12A illustrates an application layer including a software stack executing on a tester processor according to an embodiment of the present invention. The software stack executing on the tester software may include at least four layers. These layers include a device driver layer 1240, a Linux block layer 1230, vast System Software (VSS) layer 1220, and a user application layer 1210. Note that device driver layer 1240 is configured to communicate with DUT 1250.

In one embodiment, device driver layer 1240 is configured to communicate with DUT 1250 and query the DUT to determine the sector size. Once the DUT actual sector size (RSS) is reported to the device driver layer 1240, the device driver layer 1240 communicates this information to the user application layer 1210 through the VSS layer.

Consider, for example, a read operation for an SDD comprising a non-standard sector size of 524 bytes. When a data request is sent down the protocol stack from the user application layer 1210, the VSS layer 1220 calculates the sector size (e.g., 524 bytes for this example) and rounds it down to the nearest number (e.g., 512 bytes) supported by the Linux block layer 1230. For example, the Linux block layer 1230 may contain support for DUTs having a sector size of 512 bytes only. In addition, VSS layer 1220 maintains a record of additional 12 bytes of information (524 bytes minus 512 bytes).

In this example, if the user application layer 1210 requests N blocks (or N sectors) of data (e.g., 524 x N bytes), the VSS layer 1220 will request (n+m) blocks from the Linux block layer 1230, where N blocks will include 512 bytes of data, and where M blocks will include the remaining 12 bytes of additional data per block (in the case of 524 byte sized sectors). The value of M is calculated by software, where M blocks can hold additional data from all N blocks. For example, in the case of n=100, the total number of additional bytes would be 12×100=1200 bytes. To contain 1200 bytes, at least 3 blocks of 512 bytes in size need to be requested from the Linux block layer 1230. Thus, if m=3 is used, these 3 additional blocks hold additional bytes from N blocks (where n=100). Thus, the VSS layer 1220 may request 100+3 blocks from the Linux block layer 1230. The Linux block layer 1230 converts the request into a request for 103 blocks of 512 bytes (103 x 512 bytes), and the Linux block layer 1230 allows the operation.

The request is then passed down to the device driver layer 1240. The device driver layer 1240 communicates directly with the DUT 1250 and the device driver layer 1240 is able to determine that the DUT has a non-standard sector size of 524 bytes. In addition, the device driver layer 1240 may determine that the Linux block layer 1230 is making requests for 103 blocks, where each block is 512 bytes in size.

The device driver layer can use information about the sector size of the DUT and the number of blocks requested by the Linux block layer 1230 to determine that it was for 100 blocks that were originally requested at the user application layer 1210. Thus, the device driver layer 1240 sends a request for 100 blocks to the DUT, which responds to the request by filling the buffer in the device driver layer 1240 with 100 x 524 bytes. The information in this buffer is passed through the Linux block layer 1230. Thereafter, the user application layer 1210 obtains 100 blocks of 524 bytes in each sector. In one embodiment, the write operation is performed similarly to the example of the read operation described above.

Note that user application layer 1210, VSS layer 1220, and device driver layer 1240 include additional logic (modules 1293, 1292, and 1291, respectively) to be able to identify DUTs of any sector size. The Linux block layer 1230 does not include additional logic for determining whether the DUT includes any sector size or is capable of communicating with it.

FIG. 12B illustrates the functionality of each of the application layers comprising a software stack executing on a tester processor, according to an embodiment of the present invention. As shown in fig. 12B, user application layer 1210 receives information about DUT sector size. In the example discussed above, for reading 100 sectors of information from a DUT, user application layer 1210 will request data from 100 sectors (or blocks). Considering the limitation of the Linux block layer 1230 discussed above, the VSS layer 1220 requests 103 blocks (n+m=100+3) from the Linux block layer 1230. The Linux block layer 1230 does not support a non-standard sector size, but given a standard sector size of 512 bytes, the Linux block layer 1230 is configured to check whether the requested information length satisfies its constraint of processing data in multiples of 512 bytes. Thus, it allows requests to pass down the protocol stack and data from the DUT to pass up the protocol stack.

The device driver layer 1240 communicates with the DUT and thus the device driver layer 1240 can use information about the sector size of the DUT to calculate how many sectors are requested from the DUT. In the example discussed above, the device driver layer 1240 would request 100 information blocks. DUT 1250 will in turn receive a request from device driver layer 1240 and satisfy the request.

Embodiments of the present invention control input, output, drive and user space to advantageously provide a software-only solution for testing SSDs of any arbitrary sector size without sacrificing performance and since no data replication is required. Embodiments of the present invention advantageously extend the range of devices that can be tested and give the user of the tester system direct access to the data of the entire sector.

In one embodiment, a tester processor (in either standard or bypass mode or variations thereof) is used to read data and write data to the DUT. An FPGA may not be able to support DUTs with arbitrarily sized sectors because it supports only a limited number of predefined data sizes. Once the FPGA is configured (after downloading the bit stream to the FPGA), the FPGA can only support a limited short list of sector sizes at run-time. It will be appreciated that programming tester software on a tester processor to test DUTs of any sector size allows a user to read and write any length of user-specified data from and to the DUTs, and thus advantageously has versatility. At run-time, the tester processor can support any arbitrary sector size and is not limited to any particular predefined size.

Embodiments of the present invention provide a "pure software solution" that allows a user to test any sector-sized device with a user data pattern. In the case of writing to a Device Under Test (DUT), software running on the tester processor generates the complete data and commands for performing the test on that sector. In the case of a read, the software will read back the complete data from the sector without stripping the additional bytes.

Embodiments of the present invention are flexible and can test any sector-sized device that uses an entire sector for data storage. It provides the user with access to the entire sector without stripping or inserting any additional bytes. This does not sacrifice performance because no additional data replication is required.

Conventional ATE is relatively limited in that it does not support testing drives with full data non-standard sector sizes. Embodiments of the present invention advantageously allow software-based testing of such drives, particularly for any non-standard sector size.

FIG. 13 depicts a flowchart of an example computer-implemented process for testing DUTs supporting arbitrary sector sizes, according to an embodiment of the invention. However, the invention is not limited to the description provided by flowchart 1300. Rather, other functional flows are within the scope and spirit of the present invention as will be apparent to those of ordinary skill in the relevant art in view of the teachings provided herein.

At block 1310, a host controller is coupled to a tester processor and an FPGA. The host controller may be a Windows-based operating system as described above. Further, the tester processor may run Linux or modified versions of Linux OS. The FPGA is communicatively coupled to the tester processor and is configured to generate commands and data for testing the DUT according to one of the various acceleration modes described above.

At block 1312, an acceleration mode is selected to generate commands and data for testing the DUT. The acceleration mode may be a standard mode or a bypass mode, where the tester processor generates all commands and data and the FPGA is bypassed. Note that as noted above, in one embodiment, the standard or bypass mode may be the primary or primary mode required to test a full data non-standard size DUT.

At block 1314, the tester processor generates commands (e.g., reads, writes, etc.) to the DUT, where the DUT includes any sector size.

In response to the read command, the VSS layer of the tester software executing on the tester processor then calculates the sector size (e.g., 524 bytes for the example above) and rounds it down to the nearest number (e.g., 512 bytes) supported by the Linux block layer 1230 at block 1316. Further, if the user application layer 1210 requests N data blocks (or N sectors), the VSS layer 1220 will request (n+m) blocks from the Linux data block layer 1230, wherein each of the N blocks is a standard-sized block (e.g., 512 bytes), and wherein the M blocks will include additional bytes of data for each block.

At block 1318, linux block layer 1230 is programmed to check that the requested information length meets its constraint of processing data at multiples of a standard size block (e.g., multiples of 512 bytes in the example above). Thereafter, it allows requests to pass down the protocol stack and data from the DUT to pass up the protocol stack.

At block 1320, the device driver layer 1240 communicates with the DUT, and the device driver layer 1240 can use information about the size of sectors of the DUT to calculate the number of sectors in the DUT that need to be accessed (e.g., for a read or write operation).

At block 1322, data from the determined number of sectors of the DUT is accessed and a compare operation is performed to test the DUT. For example, data may be read from or written to the DUT and compared to expected data to determine if the DUT is functioning properly.

At block 1410, a host controller is coupled to a tester processor. The host controller may be a Windows-based operating system as described above. Further, the tester processor may run Linux or modified versions of Linux OS. The tester processor is configured to communicate directly with the DUT and issue commands and data directly to the DUT. As described above, while in one embodiment the tester processor may operate in bypass mode and test the DUT using the FPGA as a pass-through device, in other embodiments the tester processor may be directly connected to the DUT.

At block 1412, the tester processor generates commands (e.g., reads, writes, etc.) to the DUT, where the DUT includes any sector size.

In response to the read command, the VSS layer then calculates the sector size (e.g., 524 bytes for this example) and rounds it down to the nearest number (e.g., 512 bytes) supported by the Linux block layer 1230 at block 1414. Further, if the user application layer 1210 requests N data blocks (or N sectors), the VSS layer 1220 will request (n+m) blocks from the Linux data block layer 1230, wherein each of the N blocks is a standard-sized block (e.g., 512 bytes), and wherein the M blocks will include additional bytes of data for each block.

At block 1416, the Linux block layer 1230 is programmed to check that the requested information length meets its constraint of processing data at multiples of a standard size block, for example, multiples of 512 bytes in the example described above. Thus, it allows requests to pass down the protocol stack and data from the DUT to pass up the protocol stack.

At block 1418, the device driver layer 1240 communicates with the DUT, and the device driver layer 1240 can use information about the size of sectors of the DUT to calculate information of how many sectors are requested from the DUT.

At block 1420, data from a determined number of sectors of the DUT is accessed and a compare operation is performed to test the DUT. For example, data may be read from or written to the DUT and compared to expected data to determine if the DUT is functioning properly.

I.B) hardware accelerator mode generator mode (PIDA mode)

FIG. 7 depicts a flowchart 700 of an exemplary process for testing a DUT in hardware accelerator mode generator mode in accordance with an embodiment of the invention. However, the present invention is not limited to the description provided by flowchart 700. Rather, other functional flows are within the scope and spirit of the present invention as will be apparent to those of ordinary skill in the relevant art in view of the teachings provided herein.

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 functions in order to relieve processing load on tester processor 304 and data load on system buses 330 and 332. At block 702 of the hardware accelerator mode generator mode, the tester processor 304 generates commands and packet headers for packets to be routed to the DUT. In this mode, the tester process retains the signaling function. At block 704, an algorithm pattern generator module 443 within the hardware accelerator block 440 generates pseudo random test data to be written to the DUT. Logic block module 450 includes functionality for routing and adding generated data to packets to be written out to the DUT.

This pattern is considered "hardware accelerated" because the function for generating data can be done in hardware by the algorithmic pattern generator of the FPGA device faster than 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, which results in a significant increase in bandwidth in the bypass mode where the tester processor 304 provides all commands and data to the DUT over the system buses 330 and 332, as shown in fig. 4. In the case of FPGA devices sharing 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 through the instantiated FPGA tester block greatly speeds up testing than data paths where the resources of the tester processor 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 algorithm pattern generator module 443 may be programmed to generate data in a timely manner. 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 capability to generate test patterns with stripes, diagonal stripes, or alternating patterns. In one embodiment, the APG module may generate the test pattern using a finite state machine, a counter, or a linear feedback shift register, or the like.

In some embodiments, the APG module may be provided with a starting seed as an initial value to generate a more complex random pattern. As described above, using the sector number as a seed, for example, the APG module will generate a reproducible sequence of any length (e.g., a length of a non-standard sector size). When the data needs to be read back, the data can be regenerated again (using the sector address as a seed) so that it can be compared to the data read back from the DUT in order to ensure the integrity of the DUT.

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 a read operation on the same parameters used to generate the pseudo random data and to receive the same data that was written to the DUT at block 704. The APG module 443 timely regenerates the data written to the DUT and passes it to the comparator module 446. At block 712, any mismatches are recorded on the memory module 420 by the memory control module 444 or transferred to the tester processor by the instantiated FPGA block. After receiving the error log, the tester processor then marks the mismatch to the system controller at block 714.

I.C) hardware accelerator memory mode

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

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 functions in order to relieve processing load on tester processor 304 and data load on system buses 330 and 332. In contrast to the hardware accelerator mode generator mode, in the hardware accelerator memory mode, the instantiated FPGA tester block accesses the local memory module 420 to obtain data to be written to the DUT without using the APG module 443.

At block 800 of the hardware accelerator mode memory mode, the tester processor 304 generates commands and packet headers for packets to be routed to the DUT. The tester process 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 the test pattern to be written out to the DUT. One advantage of the hardware accelerator memory mode is that the test pattern generated by the tester processor may constitute truly random data as opposed to the pseudorandom data generated by the APG module 443 in the hardware accelerator mode 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 accesses the memory module 420 only during initial setup. During 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 memory module 420 to be routed to the DUT. Because memory module 420 is dedicated to an 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. Logic block module 450 includes functionality for routing and adding generated data to packets to be written out to the DUT.

After the data is added to the packet, at block 806, the instantiated FPGA tester block communicates with 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, 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 810. At block 812, any mismatch is recorded on the memory module 420 or communicated to the tester processor by the instantiated FPGA block. After receiving the error log, the tester processor then marks the mismatch to the system controller at 814.

I.D) hardware accelerator packet builder mode (FA mode)

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

Flowchart 900 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 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 processing load on tester processor 304 and data load on system buses 330 and 332. This mode is also referred to as a "full acceleration" (FA) mode because most of the control for running device tests is transferred to the FPGA device and the tester processor 304 retains control only for commands other than read and write and compare.

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

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

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

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 application, 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

1. An Automated Test Equipment (ATE) system, comprising:

a system controller communicatively coupled to the tester processor, wherein the system controller is configured to send instructions to the tester processor; and

The tester processor to generate commands and data in accordance with the instructions to coordinate testing of a Device Under Test (DUT), wherein the DUT supports arbitrary sector sizes, and wherein a software layer on the tester processor performs computations to control data flow between the tester processor and arbitrarily sized sectors in the DUT, wherein the software layer includes one or more functional layers to transfer data between the DUT supporting arbitrary sector sizes and the tester processor, and wherein the software layer includes at least a device driver layer and a user application layer.

2. The ATE system of claim 1, wherein the arbitrary-sized sector comprises a full data sector.

3. The ATE system of claim 1, wherein the system controller is to execute a Linux operating system.

4. The ATE system of claim 1, wherein the software layer comprises four functional layers for transferring data between the DUT and the tester processor that support the arbitrary sector size.

5. The ATE system of claim 1, wherein the software layers comprise four functional layers for transferring data between the DUT and the tester processor that support the arbitrary sector size, wherein the software layers comprise a device driver layer, a Linux block layer, a Vast system software layer, and a user application layer.

6. The ATE system of claim 5, wherein, in response to a command issued by the tester processor to the DUT, the Vast system software layer is to determine a sector size closest to the arbitrary sector size supported by the Linux block layer and request a calculated number of blocks from the Linux block layer, and wherein the calculated number of blocks comprises the number of blocks: the tester processor requests the block in the command, and the additional blocks needed to buffer the additional bytes of each arbitrary sector block.

7. The ATE system of claim 6, wherein the Linux block layer is to determine whether a length of information requested by the Vast system software layer meets a limit of processing data associated with the Linux block layer, and wherein the Linux block layer is further to pass the command down to the device driver layer.

8. The ATE system of claim 7, wherein the device driver layer is to determine a number of sectors to access from the DUT, and is further to send the command to the DUT.

9. The ATE system of claim 1, further comprising:

a Field Programmable Gate Array (FPGA), wherein the tester processor is communicatively coupled to the FPGA, and wherein the FPGA includes at least one hardware accelerator circuit for transparently generating commands and data from within the tester processor to test the DUT.

10. The ATE system of claim 9, wherein the tester processor operates in a standard mode to generate commands and data to test the DUT.

11. The ATE system of claim 5, wherein the Vast system software layer, the device driver layer, and the user application layer comprise logic to detect and communicate with any sector-sized DUTs.

12. A method of testing using Automated Test Equipment (ATE), comprising:

transmitting instructions from a system controller of a computer system to a tester processor, wherein the system controller is communicatively coupled to the tester processor; and

Generating commands and data using the tester processor to coordinate testing of a Device Under Test (DUT), wherein the DUT supports a plurality of arbitrary full data sector sizes, and wherein a software layer on the tester processor performs computations to control data flow between the tester processor and the plurality of arbitrary full data sector sizes in the DUT, wherein the software layer includes one or more functional layers for transferring data between the DUT supporting arbitrary sector sizes and the tester processor, and wherein the software layer includes at least a device driver layer and a user application layer.

13. The method of claim 12, wherein the system controller is configured to execute a Linux operating system.

14. The method of claim 12, wherein the software layers comprise four functional layers for transferring data between the DUT and the tester processor that support the arbitrary sector size.

15. The method of claim 12, wherein the software layers comprise four functional layers for transferring data between the DUT and the tester processor supporting the arbitrary sector size, wherein the software layers comprise a device driver layer, a Linux block layer, a Vast system software layer, and a user application layer.

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

A computer system comprising a system controller, wherein the system controller is communicatively coupled to a tester processor and an FPGA, wherein the system controller is configured to send instructions to the tester processor, and wherein the tester processor is configured to generate commands and data to coordinate testing of a Device Under Test (DUT) in accordance with the instructions, wherein the DUT supports a plurality of non-standard full data sector sizes;

Wherein the FPGA is communicatively coupled to the tester processor and includes at least one hardware accelerator circuit for transparently generating commands and data from within the tester processor to test the DUT; and

Wherein the tester processor is configured to operate in one of a plurality of functional modes, wherein each functional mode is configured to allocate functions for generating commands and for generating data between the tester processor and the FPGA in a different manner, and wherein in a standard mode the tester processor is configured to generate all commands and data to coordinate testing of the DUT including the plurality of non-standard full data sector sizes, wherein a software layer on the tester processor performs calculations to control data flow between the tester processor and the plurality of non-standard full data sector sizes in the DUT, and wherein the software layer includes functions to transfer data between the DUT supporting the plurality of non-standard data sector sizes and the tester processor.

17. The ATE apparatus of claim 16, wherein the tester processor is configured to execute a Linux operating system.

18. The ATE apparatus of claim 16, wherein the software layer comprises four functional layers for transferring data between the DUT and the tester processor that support the plurality of non-standard full data sector sizes.

19. The ATE apparatus of claim 18, wherein the software layers comprise four functional layers for transferring data between the DUT and the tester processor that support the arbitrary sector size, wherein the software layers comprise a device driver layer, a Linux block layer, a Vast system software layer, and a user application layer.