System and method for reducing space required for error log in semiconductor testing

Abstract

The invention provides a test system and a method for simultaneously testing a plurality of hardware blocks. A memory test device uses a master control unit (MCU) to operate a plurality of intelligent slave control units (slave control units (SCU)) at the same time. A memory address of a device under test (DUT) is converted into a matrix by the MCU or the SCU. The SCU accumulates error data by traversing test bits of a plurality of cells of the matrix to test the memory, post-processes the accumulated error data to determine whether the test bits are faulty, and repeats the process for other test bits. The post-processed data is analyzed to identify one or more of the test bits as faulty, and then preferably only a single instance of memory addresses corresponding to each of the one or more faulty test bits is included in the test log.

Description

Technical Field

[0001] The present invention relates to apparatuses, systems, and methods for a dynamic reconfigurable semiconductor tester for volatile and non-volatile memories, and more particularly to systems and methods for reducing the space required for error logs in semiconductor testing. Background Art

[0002] Computer systems utilize volatile and non-volatile memories to store and retrieve data. Volatile memories are advantageous because they achieve faster access times compared to conventional hard disk drive (HDD) or solid state drive (SSD) devices. Typically, the access time of volatile memories is at least an order of magnitude faster than that of conventional HDD or SSD devices. Volatile memories are generally used to store and retrieve data for shorter durations because they lose data when power is lost / removed.

[0003] The advantage of non-volatile memories is that they retain data even after power is lost / removed. Thus, non-volatile memories are generally used to store and retrieve data for longer durations and allow other computer systems to access the data.

[0004] Due to the current ongoing demand for higher access speeds, most computer systems utilize a combination of volatile memory for temporarily storing data and non-volatile memory for storing and retrieving data over longer time periods, including, for example, seconds, minutes, hours, days, months, or even years.

[0005] Volatile and non-volatile memories are typically assembled from individual dies of semiconductor wafers fabricated by a specific lithography process. Typically, the proper electrical operation and functionality of these wafers and their dies are tested according to given voltage (direct current (DC) level) and timing (alternating current (AC) level) parameter specifications. Once one or more known good dies are identified within a wafer, these dies will be passed through a packaging process so that a final product can be constructed using a single packaged volatile and non-volatile memory device.

[0006] Both volatile and non-volatile memories can be packaged and assembled using a single die, or using dual dies, quad dies, octal dies, and more. In some cases, the packaging includes a single or multiple dies arranged in a subsystem.

[0007] Manufacturers and suppliers desire that volatile and / or non-volatile memories be reliable, robust, and operational throughout the life of the product. To help ensure these qualities, memory components typically undergo rigorous testing. Given the complexity of volatile and non-volatile packages, it is conceivable the importance of robustness testing for building subsystems and ultimately fully assembled systems. Since one or more dies within a volatile and / or non-volatile memory package may have manufacturing-related issues (e.g., open or short circuits due to process and setup variations during package assembly and manufacturing), there is a need to test for and detect open signals (i.e., not connected to the expected point) or shorts (i.e., incorrectly connected to a nearby power supply, ground, or other signal), resulting in undesired behavior. Poor connections to the memory module printed circuit board (PCB) may also exist due to mechanical stress, manufacturing issues, thermal issues, electrical issues, or any other manufacturing-related process variations. Applying an appropriate DC level test can detect these faulty open, short, and connection issues.

[0008] Many companies offer general semiconductor test equipment that is customized to test the voltage, frequency, and temperature of specific memories using application-specific integrated circuits (ASICs) or Field Programmable Gate Arrays (FPGAs).

[0009] Generally speaking, such general testers are limited to testing either volatile memory or non-volatile memory, but not both simultaneously. General testers are also limited because they can only implement fixed functional test patterns according to existing industry standards using Automatic Test Pattern Generation (ATPG) mode. In summary, these limitations are problematic because the memories are not tested in end-user products running end-user software. They also cannot replicate the situations where memory failures occur in end-user products. Therefore, there is no way to use general testers to effectively predict end-user needs or fix many end-user problems.

[0010] Volkerink's US 7,707,468 describes a test device in which the memory controllers are arranged in a star configuration, where each of a plurality of interface boards operates in parallel to test a plurality of memory modules. This arrangement allows various memory modules to be tested simultaneously at different operating rates, but the patent is silent on the simultaneous testing of volatile and / or non-volatile memories. Additionally, the interface boards are not intelligent, so they cannot run according to a plurality of different test patterns downloaded from the memory controller. There is also no teaching, suggestion, or motivation to test the memory modules while the memory modules are running an application software.

[0011] Accordingly, there is a need for a semiconductor test system that (1) is capable of testing volatile and non-volatile memory devices, (2) has one or more dies in a package, and (3) is in a test environment that closely mimics an end-user's host system (i.e., personal computer (PC), laptop, server, cloud, etc.) and software. Ideally, such a system would provide detailed AC and DC level test coverage, as well as functional tests at normal operating temperature, high temperature, and low temperature, high nominal low voltage levels, and high nominal low operating frequencies to fully stress, exercise, and perform real-world functional tests at the operating speed of the host system. Such a system should be able to run end-customer applications on a local operating system (OS) that is capable of executing one or more applications to simulate the target host application environment. SUMMARY OF THE INVENTION

[0012] The inventive subject matter described herein provides dynamic real-time testing for volatile and non-volatile memory arrays. In the envisioned devices, systems, and methods, the memory tester unit is capable of dynamically reconfiguring (a) the voltage levels of its input and output (I / O) pins, and (b) its operating frequency, without any system restart requirements, and performing different real-time test patterns for different volatile product families and / or different non-volatile product families.

[0013] The expected memory tester unit includes several components as described below. The Master Controller Unit (MCU) manages one or more Slave Controller Units (SCU) that are capable of testing volatile and non-volatile memories. Each SCU can execute one or more different real-time test modes on one or more fully isolated memory channels of the same or different types of memories. By using this modular approach, the MCU can program one or more SCUs in parallel to perform gang / parallel tests on one or more memory devices, which increases productivity and test speed and reduces the total test cost. A single operator can load an appropriate test mode into one MCU, and the MCU can upload the test mode to one or more SCUs. Each SCU runs in the required real-time test mode, and each SCU memory channel tests one or more memory devices, regardless of whether the individual memory being tested has one, two, four, eight, or other number of dies.

[0014] Master control unit

[0015] As described herein, the MCU can be connected to each SCU by traditional wired or wireless methods to program and initialize the SCU unit. The MCU can advantageously use an intelligent, fully automated scanner method to automatically load the appropriate MCU program to load and execute each SCU. This automated process is designed to further increase utilization, reduce human error, and improve the overall test cost.

[0016] As described above, each memory tester unit can have one or more MCUs, where each MCU is connected to one or more SCUs, and each SCU can address one or more memory channels. It is also contemplated that each memory channel can have one or more Device Under Test (DUT) boards, where each of the DUTs has one or more sockets to test a single memory package of volatile or non-volatile memory. To those with expertise in the field, it will be apparent after understanding this application that hundreds of memory packages can be tested using a single scanner at any given time.

[0017] When starting to test the configuration file, the MCU can apply one or more operation tasks, programs, functions, or algorithms to one or more SCUs to detect undesired manufacturing, assembly, or packaging defects of one or more dies of volatile and / or non-volatile memory packages with open circuits and short circuits. The SCU, as well as analog and digital logic, can use various devices to detect these anomalies and error faults in the volatile and / or non-volatile memory packages. In one embodiment of the present invention, the SCU can inject and control current into each device under test (DUT) socket pin and its associated volatile and / or non-volatile memory package to measure its corresponding read voltage from the internal protection circuit diode of each volatile or non-volatile memory package pin to see if there is current continuity from the SCU input / output pin to the volatile and / or non-volatile memory device connected to the DUT socket. If the device has the correct connection, the SCU will be able to read the correct voltage drop across the internal protection diode and detect the correct connection. Otherwise, if the reading is zero, the SCU knows that the pin is open and faulty. In another embodiment, the SCU can inject current into one pin of a DUT with a volatile or non-volatile memory package and read the appropriate voltage drop at the adjacent pin location of the same volatile or non-volatile memory package to detect a short circuit to a nearby power supply, ground, or other adjacent nearby pin signals, thereby detecting potential short circuits and faulty volatile and non-volatile memory packages.

[0018] The MCU can be connected to a Power Management Unit (PMU) that is configured to increase and decrease the input voltage and current of the SCU I / O pins, the voltage rails of the DUT memory sockets, and the rest of the circuit. This flexibility allows the MCU to be able to test different memory device packages that require different operating voltage levels in the same ecosystem test. (i.e., Dynamic Random Access Memory (DRAM) 5.0V, Synchronous Dynamic Random Access Memory (SDRAM) 3.3V, DDR (Double Data Rate SDRAM)-I 2.5V, DDR-II 1.8V, DDR-III 1.5V, DDR-IV 1.2V, etc.)

[0019] The MCU can also be connected to a Clock Management Unit (CMU), which is configured to provide a wide range of clock intervals for the operation of the SCU core frequency together with the SCU I / O pins and the clock pins of the DUT memory socket. This function allows the SCU to support many different memory technologies that require different operating frequencies. (i.e., SDRAM 100Mhz, DDR-I 200Mhz, DDR-II 400Mhz, DDR-III 800Mhz, and DDR-IV 1600Mhz)

[0020] The MCU can also be configured to program the on-board Temperature Management Unit (TMU) chamber to provide a nominal room temperature, low temperature, and high temperature (i.e., -50°C to +155°C) to further stress the device under test, thereby better sorting and separating good devices and marginal devices in the test.

[0021] The MCU can also be configured to change voltage, frequency, and temperature to perform solid 3corner testing when applying the customer memory test mode and to operate the DUT device under real-time operations such as a similar target customer system.

[0022] The MCU can also be configured to perform its tasks as an off-the-shelf personal computer (PC) or an embedded PC. The software running on the MCU can advantageously perform all task management of controlling voltage, frequency, and temperature together with the SCU. In some embodiments, the MCU can be a dedicated processing unit (PU) composed of one or more microcontrollers, microprocessors, or processor units, with or without an operating system (OS) that runs one or more firmware (FW) to jointly control the SCU, PMU, CMU, and TMU units.

[0023] From the control unit

[0024] The SCU can be configured in a variety of ways, including embodiments where the SCU can use any combination of software running on a PC, hardware running on an ASIC, or dynamic hardware running on an FPGA. The SCU can be configured to have solid-state analog and digital logic, a Finite State Machine (FSM), one or more processing units (i.e., microcontrollers, microprocessors, processors, etc.), or a combination of one or more of these methods.

[0025] In some embodiments, the SCUs 516, 521 are configured to run one or more FWs to manage one or more tasks on one or more channels of each SCU. These SCUs can be connected to one or more DUTs and apply one or more series of volatile and / or non-volatile memory test patterns to one or more sockets connected to each DUT unit. This configuration collectively allows the SCUs to fully perform parameter testing and functional testing on each connected socket of each connected DUT on each SCU channel.

[0026] In one embodiment according to the subject matter of the present invention, the SCU has DUTs and sockets for testing volatile memory devices.

[0027] In another embodiment according to the subject matter of the present invention, the SCU has DUTs and sockets for testing non-volatile memory devices.

[0028] In yet another embodiment according to the subject matter of the present invention, the SCU has DUTs and sockets for testing volatile Dual Inline Memory Modules (DIMM) devices.

[0029] In still another embodiment according to the subject matter of the present invention, the SCU has DUTs and sockets for testing non-volatile module devices.

[0030] The expected SCU processing unit can run one or more microcontrollers, microprocessors, or processors using any independent bare metal firmware (FW), mini operating system, full blow embedded operating system, or real-time operating system (RTOS).

[0031] Generally, the inventive subject matter described herein aims to solve the problem of dynamically programming highly flexible tester units to test the entire ecosystem of semiconductor volatile and non-volatile memories by loading a configuration into an MCU to dynamically program and execute one or many SCUs, PMUs, CMUs, and TMUs. The envisioned devices, systems, and methods create a fully flexible, dynamic, programmable semiconductor test system to test different generations of volatile and non-volatile memories under different voltages, different frequencies, and different thermal oscillations to fully stress them. Customized full-function tests can run with real-time applications, enabling users to detect any AC and DC level parameters within the entire acceptable voltage, temperature, and frequency ranges, including errors that cannot be detected by standard off-the-shelf semiconductor testers.

[0032] Firmware

[0033] In some embodiments, the SCU may use one or more firmware (FW) codes by using one or more internal processing units, and may also perform specific operation tasks, programs, functions, or algorithms as a stand-alone firmware, scheduler, operating system, or RTOS to test volatile and non-volatile memory packages. The FW may perform any write, read, modify, read-modify-write, or compare activities.

[0034] The firmware running on the SCU processing unit may be completed as one or more series of programming codes, as a single firmware program, or as a modular approach to provide efficient and effective execution of the expected functions. The FW may be completed using a low-level programming language (such as assembly language or machine code) or a higher level of abstraction or object-oriented programming (OOP) such as the C language (i.e., C, C++, C#, etc.).

[0035] The firmware may also implement one or more operation tasks (i.e., internal housekeeping tasks to ensure that all hardware blocks connected to the SCU are always initialized, started, and working properly, and to check the health status of each hardware block from time to time), one or more processes (i.e., internal operation processes to ensure that the hardware block status of the current task at hand and / or queued tasks are all known, and to collect any relevant information to monitor, fine-tune, and report all relevant activities to the MCU unit), one or more functions (i.e., internal functions to perform performance evaluation, hardware and firmware operation latency, hardware power consumption, etc.), and one or more algorithms (i.e., any volatile and / or non-volatile memory tests, AC and / or DC level tests, function tests, customer AC and / or DC tests, function tests, customer AC and / or DC tests, customer function tests, customer application tests to improve performance, reduce latency, and reduce power consumption), which are executed by one or more microcontrollers, microprocessors, or processors using any one of a stand-alone bare-metal firmware (FW), a small operating system, a full-blown embedded operating system, or a real-time operating system (RTOS) with one or more processing units (PU), and may also be used as digital or analog logic, ASIC, FPGA, or FSM.

[0036] Any firmware algorithm can be converted into its equivalent hardware algorithm for any operation task, process, function, or algorithm to be run by one or more processing units (PU), and the hardware algorithm can be further improved by implementing it in pure digital logic, analog logic, ASIC, or FPGA to improve speed, reduce latency, and reduce power consumption. Such a hardware implementation is necessarily more efficient in terms of speed, size, and power, which can significantly improve the performance of the tester unit.

[0037] Reduce the size of the error log

[0038] The firmware may perform a series of common memory transactions to access a volatile or non-volatile memory package, thereby performing firmware write, firmware read, firmware modify, firmware read-modify-write, or firmware compare activities. In some methods, the firmware will access a volatile or non-volatile memory package of size "N" starting from the beginning (i.e., address zero "0") or the end (i.e., address N-1) to perform any task, program, function, or algorithm that includes writing, reading, modifying, or comparing. This can be done by accessing each data line (i.e., x4 bits, x8 bits, x16 bits, x32 bits, x64 bits, x72 bits, x80 bits, etc.) sequentially (i.e., one address after another) or randomly (i.e., the address can jump to any location within the valid address range from "0" to "N-1").

[0039] The memory of a volatile or non-volatile memory package can be tested by converting a linear memory address to row and column addresses. In the case where the memory package has multiple dies, the linear memory address can be converted to row and column addresses for each die so that the host can conveniently write to, read from, modify, or compare addresses in any size of data.

[0040] Traditional test devices and methods can create very large error logs. A typical volatile memory can have a capacity of 8 Gbit (i.e., 1 Gbit x 8 or one billion 8-bit locations internally arranged in rows, columns, and memory banks). Large implementations have multiple packages, such as 8 volatile packages in an 8 Gbit (1 Gbit x 8) configuration, which are commonly used in modern processors with at least 64-bit data bus access. If there are potential contact problems related to the manufacturing process in one or more packages, the memory test must test all rows, all columns, all memory banks, all packages, and all internal dies of a given memory module to generate all possible errors. Since traditional testers access the memory module in 64-bit chunks, the error log memory required within a typical tester unit must have the ability to retain the maximum number of rows x maximum number of columns x maximum number of memory banks x die locations, with each location being able to hold 64 bits of data. This translates to 1 Gig locations x 64 bits or 1 Gig x 8 bytes = 8 GB (8 Gigabytes) of error log locations.

[0041] The present invention can significantly reduce this error log and improve the manufacturing-related error detection log by several factors. In one aspect, all possible rows x columns x memory banks x dies are tested for a single data bit (test data bit), and the error data is post-processed for all known manufacturing-related problems (such as open circuits, short circuits, or poor contacts). The process is then repeated for the next test data bit at all possible address locations until each test data bit has been tested.

[0042] Once all rows x all columns x all repositories x all dies x each data bit have been collected and post - processed, the final root cause of the error can be placed in the error log. Depending on the type of error, the error log can be as small as a few hundred bytes. For example, a failure in traversing test data bits across multiple rows, columns, repositories, and dies clearly indicates that the test data bit is either OPEN (i.e., meaning no actual expected test data is written to all relevant addresses, so the failure traverses all addresses), or shorted to power, ground, or an adjacent signal nearby (i.e., meaning shorted to power "stuck at faulty logic 1", shorted to ground "stuck at faulty logic 0"). Thus, by performing firmware writes, firmware reads, firmware comparisons, the test task, program, function, or algorithm will detect these well - known issues and mark this test data bit as faulty. For each combination of row, column, repository, and die address locations, there is no need to record the same repeated error in the error log file. This will greatly reduce the manufacturing - related error log, saving storage space, processing, and power consumption compared to other verbose error logs.

[0043] Overall, these functions will help users reduce operating costs, reduce human errors, increase yields, reduce system errors, and improve system performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 is a schematic diagram of a prior - art volatile memory device tester.

[0045] Figure 2 is a schematic diagram of a prior - art non - volatile memory device tester.

[0046] Figure 3 is a schematic diagram of a prior - art volatile memory DIMM tester.

[0047] Figure 4 is a schematic diagram of a prior - art non - volatile memory module tester.

[0048] Figure 5 is a schematic diagram of the tester architecture of a device according to the concepts of the present invention.

[0049] Figure 6 is a schematic diagram of the steps in a method contemplated by the present invention. DETAILED DESCRIPTION

[0050] Figure 1FIG. 0 is a schematic diagram of a prior art volatile memory device tester 100, which generally includes a volatile memory tester unit 101 connected to a device under test (DUT) 103 through a connection 102. The DUT 103 includes one or more sockets 104#0–104#n configured to communicate with a volatile memory device (not shown). The volatile memory device tester 100 allows an end user to perform standard end-product parameter tests on one or more volatile memory devices respectively inserted into the sockets 104#0–104#n.

[0051] Figure 2 FIG. 4 is a schematic diagram of a prior art non-volatile memory device tester 200, which generally includes a volatile memory tester unit 201 connected to a device under test (DUT) 203 through a connection 202. The DUT 203 includes one or more sockets 204#0–204#n configured to communicate with a non-volatile memory device (not shown). The non-volatile memory device tester 200 allows an end user to perform standard end-product parameter tests on one or more non-volatile memory devices respectively inserted into the sockets 204#0–204#n.

[0052] Figure 3 FIG. 8 is a schematic diagram of a prior art volatile memory DIMM tester 300, which generally includes a volatile memory tester unit 301 connected to a device under test (DUT) 303 through a connection 302. The DUT 303 includes one or more DIMM sockets 304#0–304#n configured to communicate with a volatile memory DIMM module (not shown). The volatile memory DIMM tester 300 allows an end user to perform standard end-product parameter tests on one or more volatile memory DIMM modules respectively inserted into the DIMM sockets 304#0–304#n.

[0053] Figure 4 FIG. 12 is a schematic diagram of a prior art non-volatile memory module tester 400, which generally includes a volatile memory tester unit 401 connected to a device under test (DUT) 403 through a connection 402. The DUT 403 includes one or more module sockets 404#0–404#n configured to communicate with a non-volatile memory module (not shown). The non-volatile memory module tester 400 allows an end user to perform standard end-product parameter tests on one or more non-volatile memory devices respectively inserted into the module sockets 404#0–404#n.

[0054] Figure 5FIG. 0 is a schematic diagram of an embodiment of a tester architecture of a device 500 according to the inventive concept. The device 500 is capable of testing both volatile and non-volatile memory device cells, DIMMs, and module units. The device 500 generally includes a test profile 501 for volatile and non-volatile memory test modes, a network 503, an MCU 505, a PMU 509, a CMU 510, and a TMU 511, an SCU 516, 521, and a plurality of DUTs 519, 520, 522, 523.

[0055] The test profile 501 communicates with the network 503 via a communication line 502, and the network 503 communicates with the MCU 505 via a communication line 504. The communication line 502 can be wired or wireless. The network can be any suitable network, including, for example, an intranet or an extranet.

[0056] The MCU 505 is configured to send a copy of any test profile 501 to one or more SCUs 516, 521 via a communication line 515. The MCU 505 is connected to the PMU 509, the CMU 510, and the TMU 511 via a communication bus (not shown) via communication lines 506, 507, and 508, respectively.

[0057] The MCU 505 is configured to program each of the PMU 509, the CMU 510, and the TMU 511 individually and change them individually, serially, or in parallel according to the requirements of the test profile 501. The PMU 509 is connected to one or more SCUs 516, 521 via a communication line 512. The CMU 510 is connected to one or more SCUs 516, 521 via a communication line 513. The TMU 511 is connected to one or more SCUs 516, 521 via a communication line 514. This architecture allows the PMU, CMU, and TMU units to be able to program and control one or more SCUs 516, 521 in parallel, respectively.

[0058] The SCU 518 is connected in parallel to the DUT 519 and the DUT 520, where the SCU 516 is connected to one or more DUTs via a communication bus 518. The DUT 519 represents the first of n1 DUTs, and the DUT 520 represents the last of n1 DUTs controlled by the SCU 518.

[0059] The SCU 521 is connected in parallel to DUT 522 and DUT 523, where the SCU 521 is connected to one or more DUTs via a communication bus 521. DUT 522 represents the first of n2 DUTs, and DUT 523 represents the last DUT among the n2 DUT boards controlled by the SCU 521. Due to the many dedicated internal buses between the connections, the architecture of the present invention should be interpreted as facilitating a high degree of parallelism.

[0060] Communication lines 515 and 517 provide additional communication as shown.

[0061] In a simple example of processing volatile memory, the MCU 505 applies only one of the test profiles 501 in the network 503 to one or more SCUs 516, 521 via the network 503, and performs all required tests using the nominal PMU, CMU, and TMU settings. Among them, the SCUs 516 and 521 apply the required AC and DC level signals and test patterns to all DUTs 519, 520, 522, 523, and each of the DUTs 519, 520, 522, 523 performs the required tasks. The test results of a single memory address location with each memory die part and the data error logs can be recorded in the corresponding SCU, and the aggregated logs can be provided to the MCU 505 and stored in the network 503 for further analysis. In this example, the MCU 505 can program and test all sockets to test one type of volatile memory at the nominal level. In another example, the same program can program and test the same volatile memory sockets, but with voltage variations using the PMU 509, or clock frequency variations using the CMU 510, or temperature variations using the TMU 511, or a combination of one or more variations of the PMU 509, CMU 510, and TMU 511, to test the same volatile memory sockets using multi-corner testing.

[0062] In another embodiment of processing non-volatile memory, the MCU 505 applies only one of the test profiles 501 to one or more SCUs 516, 521 via the network 503 and performs all required tests using the nominal PMU, CMU, and TMU settings, where the SCUs 516 and 521 apply the required AC and DC level signals and test patterns to all DUTs 519, 520, 522, 523, and each of the DUTs 519, 520, 522, 523 performs the required tasks. The test results for a single memory address location of each memory die part and the data error logging can be recorded in the corresponding SCU, and the aggregated logs can be provided to the MCU 505 and stored in the network 503 for further analysis. In this example, the MCU 505 can program and test all sockets to test one type of non-volatile memory at the nominal level. In another example, the same program can program and test the same non-volatile memory sockets, but with a voltage change using the PMU 509, or a clock frequency change using the CMU 510, or a temperature change using the TMU 511, or a combination of one or more variations of the PMU 509, CMU 510, and TMU 511 to test the same volatile memory sockets using multi-corner testing.

[0063] In another embodiment of processing volatile and non-volatile memory, the MCU 505 applies only one of the test profiles 501 to one or more SCUs 516, 521 via the network 503 and performs all required tests using the nominal PMU, CMU, and TMU settings, where the SCUs 516 and 521 apply the required AC and DC level signals and test patterns to all DUTs 519, 520, 522, 523, and each of the DUTs 519, 520, 522, 523 performs the required tasks. The test results for a single memory address location of each memory die part and the data error logging can be recorded in the corresponding SCU, and the aggregated logs can be provided to the MCU 505 and stored in the network 503 for further analysis. In this example, the MCU 505 can program and test some sockets to test one type of volatile memory, and can program and test some sockets to test one type of non-volatile memory at the nominal level. In another example, the same program can be applied to the same volatile and non-volatile memory sockets, but with a voltage change using the PMU, or a clock frequency change using the CMU, or a temperature change using the TMU, or a combination of one or more changes of the PMU, CMU, and TMU to test the same volatile and non-volatile memory sockets using multi-corner testing.

[0064] One or more SCUs are intelligent. In some embodiments, for example, the SCU is configured to run a functional test mode while the DUT is running a host application. In some embodiments, the SCU is even capable of running some or all of the host applications using the DUT's memory.

[0065] Figure 6 It is a schematic diagram of steps in the method contemplated by the present invention. Step 601, convert the memory addresses of the volatile memory and / or non-volatile memory into a matrix; 602 accumulate error data by traversing multiple cells of the matrix to test the test bits of the memory; Step 603 post-process the accumulated error data to determine whether the test bits are faulty; 604, repeat steps 602 and 603 for other test bits; 605 evaluate the post-processed error data to identify one or more of the test bits as open or short; and Step 606, include exemplary instances (preferably only one) of the memory addresses corresponding to each of the faulty test data bits in the test log.

[0066] Although certain preferred embodiments and examples have been discussed above, it should be understood that the subject matter of the present invention extends beyond the specifically disclosed embodiments to other alternative embodiments and / or uses of the present invention and their obvious modifications and equivalents. The scope of the invention disclosed herein should not be limited by the specifically disclosed embodiments. Thus, for example, in any method or process disclosed herein, the actions or operations constituting the method / process may be executed in any suitable order and are not necessarily limited to any particular disclosed order.

[0067] Priority

[0068] This application is a divisional continuation of pending U.S. Patent Application Serial No. 17 / 985,037, filed on November 10, 2022.

Claims

1. A method for testing a memory in a device under test (DUT), the method comprising: (a) converting the memory addresses of the memory into a matrix; (b) accumulating error data by testing test bits of the memory by traversing multiple cells of the matrix; (c) post-processing the accumulated error data to determine whether the test bits are faulty; (d) repeating steps (b) and (c) for other test bits; (e) evaluating the post-processed error data to identify one or more of the test bits as open or short; and (f) including exemplary instances of the memory addresses corresponding to each of the faulty test data bits in a test log.

2. The method according to claim 1, comprising converting at least 8 Gbit of the memory addresses into the matrix.

3. The method according to claim 1, further comprising converting at least 8 GB of the memory addresses into the matrix.

4. The method according to claim 1, wherein, The device under test (DUT) comprises at least two dies, and further comprises converting the memory addresses of the at least two dies into the matrix.

5. The method according to claim 1, wherein The device under test (DUT), wherein the matrix comprises a first axis and a second axis, each cell of the matrix comprises each of the memory addresses in the memory addresses, and the first axis specifies the test bits.

6. The method according to claim 5, wherein, The first axis and the second axis are rows and columns.

7. The method according to claim 1, further comprising testing at least one of the test bits for known manufacturing-related problems.

8. The method according to claim 1, further comprising using a slave controller unit (SCU) to perform at least step (b).

9. The method according to claim 8, further comprising using the slave controller unit (SCU) to additionally perform at least step (c).

10. The method according to claim 8, further comprising using the slave controller unit (SCU) to additionally perform at least step (e).

11. The method according to claim 8, further comprising using a main controller unit (MCU) to operate the slave controller unit (SCU), and using the main controller unit (SCU) to perform step (f).

12. The method according to claim 8, further comprising using firmware in the first slave controller unit (SCU) to perform at least step (b).

13. The method according to claim 1, wherein The memory comprises volatile memory components.

14. The method according to claim 1, wherein The memory comprises non-volatile memory components.

15. The method according to claim 1, wherein, The memory comprises a combination of volatile and non-volatile memory components.

16. A memory test device, comprising: a main controller unit (MCU) configured to provide a first functional test mode to each of at least a first slave controller unit (SCU) and a second slave controller unit (SCU); wherein the first SCU is configured to operate at least a first device under test board (DUT) using the first functional test mode, and the second SCU is configured to operate at least a second device under test board (DUT) using the first functional test mode simultaneously with the operation of the second DUT; wherein the first SCU comprises firmware configured to selectively perform read / write tests on the memory addresses of at least the first DUT; Among them, the first SCU is configured to: (a) Convert the first memory address of the first DUT into a first matrix; (b) Accumulate error data from the first memory by traversing multiple cells of the first matrix to test the test bits of the first memory; (c) Post-process the accumulated error data from the first memory to determine whether the test bits are faulty; and (d) Repeat steps (b) and (c) for other test bits from the first memory; and Among them, at least one of the MCU and the first SCU is configured to: (e) Evaluate the post-processed error data to identify one or more of the test bits as open or short; and (f) Include exemplary instances of the memory addresses corresponding to each of the faulty test data bits in the test log.

17. The apparatus according to claim 16, wherein, The first SCU is configured to convert at least 8 Gbit of the first memory address into the first matrix.

18. The apparatus according to claim 16, wherein, The first SCU is configured to convert at least 8 GB of the first memory address into the first matrix.

19. The device according to claim 16, wherein, The first matrix includes at least a first axis and a second axis, and the first SCU is configured to convert the first memory address into the respective cells of the first matrix, wherein the first axis specifies the test bits.

20. The apparatus according to claim 16, wherein, The second MCU is configured to: (g) Convert the memory address of the second memory of the second DUT into a second matrix; (h) Accumulate error data from the second memory by traversing multiple cells of the second matrix to test the test bits of the second memory; (i) Post-process the accumulated error data from the second memory to determine whether the test bits are faulty; And (j) Repeat steps (g) and (h) for other test bits from the second memory.

21. The apparatus according to claim 16, wherein, The second MCU is configured to include other exemplary instances of the second memory addresses corresponding to the other test bits among the faulty test bits in the test log.

22. The method according to claim 16, wherein The memory includes volatile memory components.

23. The method according to claim 16, wherein, The memory includes non-volatile memory components.

24. The method according to claim 16, wherein, The memory includes a combination of volatile and non-volatile memory components.

Images