Test system and method for simultaneously testing multiple connection hardware blocks

Abstract

The invention provides a test system and a method for simultaneously testing a plurality of connected hardware blocks. A memory test device uses a master control unit to operate a plurality of intelligent slave control units (slave control units, SCUs) at the same time. The SCU may have one or more processing units (i.e., finite-state machines, microcontrollers, processors) that are capable of testing volatile and / or non-volatile memory devices connected to the one or more DUT devices. Further, the SCU may have an operating system that may locally install and run host applications within each SCU unit to simulate a host application environment while performing conventional memory tests. The SCU may operate using software and / or firmware or hardware without relying on firmware or software.

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 a memory test apparatus and a parallel test method for a plurality of devices under test. 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 one order of magnitude faster than that of conventional HDD or SSD devices. Volatile memories are typically 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 typically used to store and retrieve data for longer durations and allow other computer systems to access the data.

[0004] Due to the ongoing demand for higher access speeds, most computer systems utilize a combination of volatile memories to temporarily store data and non-volatile memories to store and retrieve 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 go through a packaging process so that a final product can be constructed using individual volatile and non-volatile memory device packages.

[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 package 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.

[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 memories or non-volatile memories, 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) patterns. In summary, these limitations are problematic because the memories are not tested in end-user products running end-user software. Nor can they replicate the situations where memory failures occur in end-user products. As a result, there is no way to use general testers to effectively predict end-user needs or fix the problems of many end-users.

[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 works 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 regarding the simultaneous testing of volatile and / or non-volatile memories. Additionally, the interface boards are not intelligent, so they cannot operate according to a plurality of different test patterns downloaded from the memory controller. Nor is there any teaching, suggestion, or motivation to test the memory modules while the memory modules are running application software.

[0011] Accordingly, there is a need for a semiconductor test system that (1) can test volatile and non-volatile memory devices, (2) has one or more dies in a package, and (3) is in a test environment of a host system (i.e., personal computer (PC), laptop, server, cloud, etc.) for precision analog end-users and software. Ideally, such a system will provide detailed AC and DC level test coverage, as well as functional tests at normal operating temperature, high and low temperatures, 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 can execute 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, a 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 modes for different volatile product families and / or different non-volatile product families.

[0013] The expected memory tester unit includes several components as described below. A Master Controller Unit (MCU) manages one or more Slave Controller Units (SCUs) that can test volatile and non-volatile memory. Each SCU can perform one or more different real-time test modes on one or more fully isolated memory channels of the same or different types of memory. 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 improves productivity and test speed and reduces the total test cost. A single operator can load an appropriate test mode into an 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 a single die, dual die, quad die, octal die, or other number of dies.

[0014] 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 improve utilization, reduce human error, and improve overall test costs.

[0015] 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 art, it will be apparent after understanding this application that hundreds of memory packages can be tested using a single scanner program at any given time.

[0016] 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 enable the same ecosystem to test different memory device packages that require different operating voltage levels. (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.)

[0017] The MCU can also be connected to a clock management unit (CMU) that is configured to provide a wide range of clock intervals for the operation of the SCU core frequency in conjunction with the clock pins of the SCU I / O pins and the DUT memory sockets. This feature 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)

[0018] The MCU can also be configured to program the on-board Temperature Management Unit (TMU) chamber to provide a nominal room temperature, a low temperature, and a 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.

[0019] The MCU can also be configured to change the 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.

[0020] The MCU can also be configured as an off-the-shelf personal computer (PC) or an embedded PC to perform its tasks. The software running the MCU can advantageously perform all task management of controlling the 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) running one or more firmware (FW) to jointly control the SCU, PMU, CMU, and TMU units.

[0021] The SCU can be configured in various 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.

[0022] In some embodiments, the SCUs 516, 521 are configured to run one or more FW 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 modes to one or more sockets connected to each DUT unit. This configuration collectively allows the SCU to fully perform parametric testing and functional testing on each connected socket of each connected DUT on each SCU channel.

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

[0024] In another embodiment according to the subject matter of the present invention, the SCU has a DUT and a socket for testing a non-volatile memory device.

[0025] In yet another embodiment according to the subject matter of the present invention, the SCU has a DUT and a socket for testing a volatile Dual Inline Memory Modules (DIMM) device.

[0026] In still another embodiment according to the subject matter of the present invention, the SCU has a DUT and a socket for testing a non-volatile module device.

[0027] The expected SCU processing unit can run one or more microcontrollers, microprocessors, or processors using any standalone bare metal firmware (FW), a mini operating system, a full blow embedded operating system, or a real-time operating system (RTOS). The firmware running on the SCU processing unit can be done as one or more series of programming code, as a single firmware program, or as a modular approach to provide an effective and efficient execution of the expected functionality. The FW can be done using a low-level programming language such as assembly language or machine code, or at a higher level of abstraction or object-oriented programming (OOP) such as the C language (i.e., C, C++, C#, etc.).

[0028] It is also contemplated that a system can be implemented with multiple slave controller units (SCUs) that simultaneously execute different test modes using a master controller unit (MCU), where at least a first SCU and a second SCU operate entirely in hardware without relying on firmware or software.

[0029] The inventive subject matter described herein aims to address the dynamic programming of highly flexible tester units to test the entire ecosystem of semiconductor volatile and non-volatile memories by loading a configuration into the 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 at different voltages, different frequencies, and different thermal oscillations to fully stress them. Custom full-featured tests can run with real-time applications, enabling users to detect any AC and DC level parameters across the entire acceptable voltage, temperature, and frequency ranges, including errors that cannot be detected by standard off-the-shelf semiconductor testers.

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

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

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

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

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

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

[0036] Figure 6 is a schematic diagram of an MCU / SCU tester architecture, wherein at least a first SCU and a second SCU operate entirely in hardware and do not require firmware or software. DETAILED DESCRIPTION

[0037] Figure 1 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 off - the - shelf parameter tests on one or more volatile memory devices respectively inserted into the sockets 104#0 - 104#n.

[0038] Figure 2 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 off - the - shelf parameter tests on one or more non - volatile memory devices respectively inserted into the sockets 204#0 - 204#n.

[0039] Figure 3FIG. 0 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 via 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 off-the-shelf parameter tests on one or more volatile memory DIMM modules respectively inserted into the DIMM sockets 304#0–304#n.

[0040] Figure 4 FIG. 4 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 via 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 off-the-shelf parameter tests on one or more non-volatile memory devices respectively inserted into the module sockets 404#0–404#n.

[0041] Figure 5 FIG. 8 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 units, DIMM 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, SCUs 516, 521, and a plurality of DUTs 519, 520, 522, 523.

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

[0043] 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.

[0044] The MCU 505 is configured to program and change each of the PMU 509, CMU 510, and TMU 511 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 the communication line 512. The CMU 510 is connected to one or more SCUs 516, 521 via the communication line 513. The TMU 511 is connected to one or more SCUs 516, 521 via the 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.

[0045] 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 the communication bus 518. The DUT 519 represents the first of n1 DUTs, and the DUT 520 represents the last of the n1 DUTs controlled by the SCU 518.

[0046] The SCU 521 is connected in parallel to the DUT 522 and the DUT 523, where the SCU 521 is connected to one or more DUTs via the communication bus 521. The DUT 522 represents the first of n2 DUTs, and the DUT 523 represents the last DUT of 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 promoting a high degree of parallelism.

[0047] The communication lines 515 and 517 provide additional communication as shown in the figure.

[0048] In a simple example of processing 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 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 each memory die part's individual memory address location and 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 volatile memory at nominal levels. 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.

[0049] 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 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 each memory die part's individual memory address location and 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 nominal levels. In another example, the same program can program and test the same non-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.

[0050] In another embodiment for handling volatile and non-volatile memories, 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 nominal PMU, CMU, and TMU settings, where the SCUs 516 and 521 apply the required AC and DC level signals and test modes 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 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 nominal levels. 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.

[0051] 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.

[0052] Figure 6 is a schematic diagram of an MCU / SCU tester architecture, where at least a first SCU and a second SCU run entirely in hardware and do not require firmware or software. Except that the software and / or firmware SCU 516 has been replaced with a hardware-only SCU 616 and the software and / or firmware SCU 517 has been replaced with a hardware-only SCU 617, the components are the same as Figure 5 in.

[0053] The main benefit is speed. Each line of FW code corresponds to several lines of lower-level language code (i.e., one line of C code will translate into 3 - 5 lines of assembly code), which would require at least 4 - 5 HW clock cycles for each line of C code to execute on any given CPU, processor, microcontroller, MCU, etc. By converting FW code segments into equivalent HW blocks to eliminate the latency due to C language conversion (i.e., compiler, to assembly, to pipeline with CPU speed), pure HW logic can execute in nanoseconds rather than milliseconds, resulting in higher performance, lower power, and lower latency.

[0054] In typical FW code, the expected functionality of the FW results includes the following parts:

[0055] 1) Some inputs (i.e., inputs from the outside world such as a button press, signal reception, etc.);

[0056] 2) Some temporary variables for saving input data (i.e., FW variables for temporarily storing input data);

[0057] 3) Some temporary variables for saving intermediate values (i.e., FW variables for saving temporary calculations, formatted data, etc.);

[0058] 4) Some internal calculations (i.e., FW for addition, subtraction, multiplication, division, square root, power, etc.);

[0059] 5) Some outputs (i.e., returning the results of FW processing to other FWs in the outside world such as a printer, monitor, another computer, etc.); and

[0060] 6) Some repetitive steps (i.e., For loops, While loops, Do loops, recursive loops, if elseif - else statements, switch statements, etc.).

[0061] In Figure 6 the embodiment of

[0062] 1) External or internal inputs are directly connected to our expected HW blocks;

[0063] 2) Some flip - flops or logic gates are used as temporary variable memories to save the input values to our HW;

[0064] 3) Some internal memory blocks are used to save intermediate values for FW calculations, formatted data, etc.

[0065] 4) All internal calculations are done with pure digital logic (i.e., adders, subtractors, multipliers, dividers, shift registers, Digital Signal Processor (DSP), etc.);

[0066] 5) All final results will be sent out to the expected HW output block; and

[0067] 6) All repetitive blocks (i.e., For loop, While loop, Do loop, recursive loop, if-else-if, switch statement) are constructed as complex combinational logic and sequential logic (i.e., complex series of basic digital gates, complex series of basic digital gates with flip-flops, and feedback loops to repeat some tasks until the HW reaches the desired result, and the FSM (finite state machine) determines what the complex combinational logic and complex sequential logic and their associated memory blocks should do, and how many times they should do it until they reach the final result).

[0068] In a specific example, the 32-bit input from an external switch for turning on 32-bit output LED lights at different frequencies can be converted from FW to hardware as follows:

[0069] 1) The 32-bit input switch is connected to 32 input pins within the HW block;

[0070] 2) The external clock and reset pins are connected to the same HW block;

[0071] 3) The 32-bit D flip-flop register HW block captures the 32-bit input for further processing by using the input reset and input clock;

[0072] 4) The component with 32-bit output pins is driven by the HW block to drive the 32-bit LED lights;

[0073] 5) The circuit generates the expected frequency and all other required frequencies based on the input clock;

[0074] 6) The sequential circuit and FSM provide appropriate frequencies to turn on and off each of the 32-bit LED lights; and

[0075] 7) The FMS takes the 32-bit input, uses internal D flip-flops (D-FF), as well as sequential logic, input reset, and input clock to generate the required frequency for each of the output LED lights, and drives the output LED light circuit).

[0076] The above circuit can process everything within a few nanoseconds, while the equivalent circuit running at 100Mhz clock in FW and CPU may take a few milliseconds. Since any FW block can have the same 6 parts as above, it can be envisioned that technicians can use these concepts to convert any FW to HW, regardless of its complexity.

[0077] 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 acts or operations constituting the method / process may be performed in any suitable order and are not necessarily limited to any particular disclosed order.

[0078] The various aspects and advantages of the embodiments have been described where appropriate. It should be understood that not all of these aspects or advantages may be achieved in accordance with any particular embodiment. Thus, for example, it should be recognized that the various embodiments may be implemented in a manner that achieves or optimizes one advantage or a group of advantages taught herein, without necessarily achieving other aspects or advantages taught or suggested herein.

[0079] Priority

[0080] This application claims the priority of U.S. Patent Application Serial No. 18 / 393,510, filed on December 21, 2023.

Claims

1. A test system comprising: a master controller unit MCU configured to provide at least a first test mode and a second test mode to the first slave controller unit SCU, and to provide at least a third test mode to the second slave controller unit SCU; wherein the first SCU is configured to test at least a first connection hardware block and a second connection hardware block using the first test mode and the second test mode, respectively, and the second SCU is configured to test at least a third connection hardware block using the third test mode while the first connection hardware block and the second connection hardware block are tested by the first SCU; wherein at least the first SCU is configured to operate in a standalone configuration under control of a firmware FW circuit; and The first connection hardware block, the second connection hardware block and the third connection hardware block are different from each other.

2. The test system according to claim 1, wherein: The FW circuit is configured to implement housekeeping tasks to confirm that at least the first connection hardware block is initialized and started.

3. The test system according to claim 1, wherein: The FW circuit is configured to implement housekeeping tasks to confirm that at least the first connection hardware block is functioning properly.

4. The test system according to claim 1, wherein: The FW circuit is configured to implement one or more processes to check the status of currently-on-hand tasks and / or queued tasks of at least the first connection hardware block.

5. The test system according to claim 1, wherein: The FW circuit is configured to implement one or more processes to monitor activities of at least the first connection hardware block and report the monitored activities to the MCU.

6. The test system according to claim 1, wherein: The FW circuit is configured to implement one or more processes to fine-tune the activity of at least the first connection hardware block and report the monitored activity to the MCU.

7. The test system according to claim 1, wherein: The FW circuit is configured to perform a performance evaluation of a hardware delay of at least the first connection hardware block.

8. The test system according to claim 1, wherein: The FW circuit is configured to perform a performance evaluation of power consumption of at least the first connection hardware block.

9. The test system according to claim 1, wherein: The FW circuit is configured to execute an algorithm that tests a volatile memory and / or a non-volatile memory included in the first connection hardware block.

10. The test system according to claim 1, wherein: The FW circuit is configured to run an algorithm for testing an AC level and / or a DC level of at least the first connection hardware block.

11. The test system according to claim 1, wherein: The FW circuit is configured to run an algorithm that performs a functional test on at least the first connection hardware block.

12. The test system according to claim 1, wherein: The FW circuit is configured to run an algorithm that tests a customer application running on at least the first connectivity hardware block for at least one of performance, latency, and power consumption.

13. The test system according to claim 1, wherein: The FW circuit includes a mini operating system.

14. The test system according to claim 1, wherein: The FW circuit includes a mature embedded operating system.

15. The test system according to claim 1, wherein: The FW circuit includes a real-time operating system RTOS.

16. The test system according to claim 1, wherein: The FW circuit includes an application specific integrated circuit ASIC.

17. The test system according to claim 1, wherein: The FW circuit includes a field programmable gate array FPGA.

18. The test system according to claim 1, wherein: The FW circuit comprises a finite state machine FSM.

19. The test system according to claim 1, wherein: The FW circuit includes a bare metal circuit.

20. The test system according to claim 1, wherein: The FW circuit uses pure digital logic.

21. The test system according to claim 1, wherein: The FW circuit uses digital logic and analog logic.

22. A method for simultaneously testing at least a first connection hardware block, a second connection hardware block, and a third connection hardware block, comprising: Using the master controller unit MCU to provide at least a first test mode and a second test mode to the first slave controller unit SCU, and to provide at least a third test mode to the second slave controller unit SCU; operating the first SCU to test at least a first connection hardware block and a second connection hardware block using the first test mode and the second test mode, respectively, and simultaneously operating the second SCU to test at least a third connection hardware block using the third test mode; wherein at least the first SCU is configured to operate in a standalone configuration under control of a firmware FW circuit; and The first connection hardware block, the second connection hardware block and the third connection hardware block are different from each other.

23. The method according to claim 22, wherein: The first test mode is the same as the second test mode and the third test mode.

24. The method according to claim 22, wherein: The first test mode is different from at least one of the second test mode and the third test mode.

25. The method of claim 22, further comprising operating the FW circuit to implement housekeeping tasks to confirm that at least the first connection hardware block is initialized, started, and operating properly.

26. The method of claim 22, further comprising operating the FW circuit to implement one or more processes to check the status of currently-on-hand tasks and / or queued tasks of at least the first connection hardware block.

27. The method of claim 22, further comprising operating the FW circuit to implement one or more processes of monitoring and fine-tuning the activity of at least the first connection hardware block, and reporting the monitored activity to the MCU.

28. The method of claim 22, further comprising operating the FW circuit to perform a performance evaluation of hardware latency and / or power consumption of at least the first connection hardware block.

29. The method of claim 22, further comprising operating the FW circuit to run an algorithm that tests at least one of: (a) volatile memory and / or non-volatile memory included in the first connection hardware block, and (b) AC levels and / or DC levels of at least the first connection hardware block.

30. The method of claim 22, further comprising operating the FW circuit to run an algorithm that tests a customer application running on at least the first connectivity hardware block for at least one of performance, latency, and power consumption.

31. A testing system comprising: a master controller unit MCU configured to provide at least a first test mode and a second test mode to the first slave controller unit SCU, and to provide at least a third test mode to the second slave controller unit SCU; wherein the first SCU is configured to test at least a first connection hardware block and a second connection hardware block using the first test mode and the second test mode, respectively, and the second SCU is configured to test at least a third connection hardware block using the third test mode; wherein at least one of the test functions of at least the first SCU is configured to operate in hardware without reliance on firmware or software; and The first connection hardware block, the second connection hardware block and the third connection hardware block are different from each other.

32. The test system of claim 31, wherein: The first test mode is the same as the second test mode and the third test mode.

33. The test system of claim 31, wherein: The first test mode is different from at least one of the second test mode and the third test mode.

34. The test system of claim 31, wherein: The first SCU is configured to implement housekeeping tasks to confirm that at least the first connection hardware block is initialized, started and operates properly.

35. The testing system of claim 31, wherein: The first SCU is configured to implement one or more processes for checking the status of currently-on-hand tasks and / or queued tasks of at least the first connected hardware block.

36. The test system of claim 31, wherein: The first SCU is configured to implement one or more processes of monitoring and fine-tuning the activity of at least the first connection hardware block and report the monitored activity to the MCU.

37. The testing system of claim 31, wherein: The first SCU is configured to perform a performance evaluation of hardware latency and / or power consumption of at least the first connection hardware block.

38. The testing system of claim 31, wherein: The first SCU is configured to run an algorithm that tests at least one of: (a) volatile memory and / or non-volatile memory included in the first connection hardware block, and (b) AC levels and / or DC levels of at least the first connection hardware block.

39. The test system of claim 31, wherein: The first SCU is configured to run an algorithm that tests a client application running on at least the first connected hardware block for at least one of performance, latency, and power consumption.

Images