Multi-board-card parallel test method and system and computer readable storage medium

Abstract

The invention belongs to the field of semiconductor equipment testing, and particularly discloses a multi-board-card parallel testing method and system and a computer readable storage medium, which have both flexibility and high efficiency. The method comprises the steps that a test process is configured, a plurality of test items are included in the test process, and a plurality of test actions are included in the test items; in the first test mode, a single advanced instruction is sent to start the whole test item, and the board card end autonomously completes all specific actions in the item locally, so that the efficiency problem caused by frequent network interaction is solved, the multi-time network communication overhead of a complex test item can be reduced to one time, and the test efficiency is improved. Therefore, in a chip mass production test link with a relatively harsh efficiency requirement, the equipment throughput is improved; in the second test mode, the host side is allowed to send and control execution of each basic test action one by one, the fine management capability of the test process is provided, and the method is very suitable for problem positioning and debugging in the development stage.

Description

Technical Field

[0001] This invention relates to the field of semiconductor device testing, and in particular to a method, system, and computer-readable storage medium for parallel testing of multiple boards. Background Technology

[0002] In the field of automated test equipment (ATE) for semiconductors, test systems generally follow pre-defined test procedures to test chips. In the current mainstream distributed architecture, which includes a central control unit (such as a host or main control board MRP) and multiple execution boards, a common technical solution is centralized scheduling by the control unit. In this mode, the control unit is responsible for parsing the test procedure and sending each basic test action in the procedure, such as outputting a specified voltage or configuring function registers, as an independent instruction via the network to the corresponding board for execution.

[0003] However, this tightly coupled control method of "issuing and executing instructions one by one" has a technical drawback. Since each basic test action relies on a network communication round trip, when executing complex test items involving a large number of operations, the network communication time accumulates significantly, resulting in huge time overhead. This latency directly limits the overall test efficiency and equipment throughput. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, and computer-readable storage medium for parallel testing of multiple boards, thereby improving testing efficiency and device throughput.

[0005] This invention discloses a multi-board parallel testing method, the method comprising: Configure a test process, which includes multiple test items, and each test item includes multiple test actions; In the first test mode, the host sends a test command to the board; after receiving a single test command, the board executes the test action corresponding to the test item. In the second test mode, the host sends test commands to the board one by one, and the board executes a corresponding test action after receiving each test command.

[0006] Furthermore, before conducting the test, the same source code corresponding to the test action is compiled into a first-format executable file for use by the host and a second-format executable file for use by the board.

[0007] Furthermore, the method also includes, before conducting the test, compiling the same source code corresponding to the test action into a first format executable file for use by the host and a second format executable file for use by the board.

[0008] Furthermore, the first format executable file is configured as an executable file of the host operating system, and the second format executable file is configured as a dynamic link library of the board-side operating system.

[0009] Furthermore, the second format executable file is configured to perform only hardware interactions related to the test action; the first format executable file is configured to simulate only the test action.

[0010] Furthermore, the test actions include at least one of: applying voltage to test current, applying current to test voltage, outputting waveform in a specified mode, configuring function registers, and reading / writing stored data.

[0011] Furthermore, the method also includes synchronizing the configuration information of the test item from the host to the board before executing the test process.

[0012] Furthermore, after the host sends the instruction to start the test item to all the boards participating in the test, the host pauses the execution of subsequent test items in the test process and enters a waiting state until it receives the completion status signal from all the boards participating in the test, and then continues to execute the test process.

[0013] Furthermore, the configuration information includes at least one of the following: the execution sequence of the test item, parameters for hardware interaction, and judgment criteria for determining the test results.

[0014] On the other hand, the present invention also discloses a system for parallel testing of multiple boards, the system including a host end and multiple board ends, the system being configured to execute the above-mentioned synchronous control method for parallel testing of multiple boards.

[0015] On the other hand, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-mentioned synchronous control method for parallel testing of multiple boards.

[0016] Compared with the prior art, the present invention has at least the following technical effects: This invention provides two switchable test modes for board testing, combining flexibility and efficiency. Specifically, the first test mode sends a single high-level command to initiate the entire test item, allowing the board to autonomously complete all specific actions within that item locally. This solves the efficiency problem caused by frequent network interactions, reducing the overhead of multiple network communications for a complex test item to a single one, thereby improving device throughput in the efficiency-critical chip mass production testing phase. The second test mode allows the host to send and control the execution of each basic test action sequentially, providing fine-grained management capabilities for the test process, making it highly suitable for problem localization and debugging during the development phase. Attached Figure Description

[0017] Figure 1 This is a schematic block diagram of the test process for the multi-board parallel testing method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the test process for the multi-board parallel testing method in Embodiment 1 of the present invention; Figure 3 This is an interactive diagram of the first test mode in Embodiment 1 of the present invention; Figure 4 This is a flowchart of the end-to-end test execution process in Embodiment 1 of the present invention. Detailed Implementation

[0018] The following detailed description, with reference to schematic diagrams, outlines a multi-board parallel testing method, system, and computer-readable storage medium of the present invention, illustrating preferred embodiments of the invention. It should be noted that the following description is intended to enable those skilled in the art to understand and implement the invention, and is illustrative rather than limiting the scope of the invention. Those skilled in the art should understand that, based on the teachings of this specification, various modifications, equivalent substitutions, or improvements can be made to the described specific embodiments without departing from the core spirit and principles of the invention. For example, technical features from different embodiments can be cross-combined to form new technical solutions. As long as no technical contradictions arise, these variations and combinations should fall within the scope of protection claimed by the present invention.

[0019] The invention is described more specifically by way of example in the following paragraphs with reference to the accompanying drawings. The advantages and features of the invention will become clearer from the following description. It should be noted that the drawings are in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of the invention.

[0020] Example 1 Please refer to Figure 1 and Figure 2 This embodiment discloses a synchronous control method for parallel testing of multiple boards, the method comprising: S1. Configure a test process, which includes multiple test items, and each test item includes multiple test actions; S2. In the first test mode, the host sends a test command to the corresponding board; after receiving a single test command, the board executes the test action corresponding to the test item. S3. In the second test mode, the host sends test commands to the board one by one, and the board executes a corresponding test action after receiving each test command.

[0021] This embodiment provides two switchable test modes for board testing, combining flexibility and efficiency. Specifically, the first test mode sends a single high-level command to initiate the entire test item, allowing the board to autonomously complete all specific actions within that item locally. This solves the efficiency problem caused by frequent network interactions, reducing the network communication overhead of multiple times for a complex test item to a single time, thereby improving device throughput in the efficiency-critical chip mass production testing phase. The second test mode allows the host to send and control the execution of each basic test action one by one, providing fine-grained management capabilities for the test process, making it highly suitable for problem localization and debugging during the development phase.

[0022] For details, please refer to Figure 3 In step S3, the first test mode refers to the mass production mode, where the granularity of test scheduling is increased from "test action" to "test item". The host sends a single start command representing the entire test item to all participating boards.

[0023] The second test mode is the debug mode, where the host sends fine-grained test commands to the board one by one. Upon receiving each test command, the board executes a corresponding test action. This mode is primarily used for step-by-step debugging and problem localization during the development phase.

[0024] In this embodiment, the number of board-end cards can be 2, 3, 4 or 5, etc. Those skilled in the art can expand or reduce the number of board-end cards according to system configuration requirements, and no specific restrictions are made here.

[0025] Furthermore, this application proposes that, before conducting the test, the same source code corresponding to the test action be compiled into a first-format executable file for use on the host side and a second-format executable file for use on the board side.

[0026] Specifically, the first format executable file is configured as an executable file for the host operating system, while the second format executable file is configured as a dynamic link library for the board-side operating system. The source code can be written in programming languages ​​such as C++ or Python, and different formats of executable files are generated using a cross-compilation toolchain.

[0027] Therefore, this technical solution solves the problem of low development efficiency caused by the heterogeneity of execution environments between the host and board in a distributed testing system through unified source code management and differentiated compilation. Only one set of source code needs to be maintained, and executable files adapted to different platforms are generated through compilation, achieving both functional consistency and significantly reducing development and maintenance workload. Furthermore, the use of dynamic link libraries allows the board to flexibly load and execute test actions without recompiling the entire test program.

[0028] Furthermore, this application also proposes that the first format executable file is configured as an executable file of the host-side operating system, and the second format executable file is configured as a dynamic link library of the board-side operating system.

[0029] Specifically, the executable file of the host operating system is usually in the executable program format of Windows or Linux (such as .exe or .bin), which is designed to run on the host and simulate the execution logic of the test actions. The dynamic link library (such as .so or .dll) of the board-side operating system is compiled into a binary module that can directly call the hardware interface, which encapsulates the low-level driver functions for interacting with the specific hardware.

[0030] In a specific example, the dynamic link library receives call instructions from the host through a standardized function interface (e.g., through predefined function names and parameter lists), thereby enabling precise control of hardware operations.

[0031] To address this, the technical solution decouples the test logic from hardware operations by compiling the same source code into two different executable file formats. The host-side executable focuses on simulating and scheduling the test process, while the board-side dynamic link library directly interfaces with underlying resources such as hardware registers or power management. This allows the host to issue test commands in batch mode, while the board can quickly execute hardware operations through its local dynamic library. This improves the execution efficiency of complex test items.

[0032] Furthermore, this application also proposes that the second format executable file is configured to perform only hardware interactions related to the test actions; and the first format executable file is configured to simulate only the test actions.

[0033] Specifically, the second format executable file exists as a dynamic link library in the board's operating system. This dynamic link library is designed to contain only functional modules that directly interact with the hardware. For example, when the test involves setting a specified voltage for the power supply output, the dynamic link library only retains the read / write interface for the power control register, while removing all code related to test logic judgments.

[0034] The first format executable file exists as an executable program in the host operating system. This program reproduces the execution process of the test action through software simulation, but does not generate actual hardware signal output.

[0035] In a specific example, hardware interaction functions can be implemented through the low-level driver interface of the operating system on the board, while the simulation execution function is accomplished using the memory virtualization technology of the host.

[0036] This application embeds the hardware interaction function locally on the board. The main control terminal only needs to issue high-level test item instructions, and the board will autonomously complete the specific hardware operation sequence, effectively reducing the number of network communications.

[0037] Furthermore, in this embodiment, the test action includes at least one of applying voltage to test current, applying current to test voltage, specifying mode to output waveform, configuring function register, and reading / writing stored data.

[0038] Specifically, setting the power output voltage refers to adjusting the output voltage to the specific voltage value required for the test via the power management module on the board. This voltage value is usually determined by the parameters in the test item. Configuring the function registers involves writing to the function registers on the board to set the hardware's operating mode or state. Reading and writing memory data involves reading or writing data to the memory cells on the board to verify the correctness of the storage function. Applying voltage and testing current refers to applying a stable voltage of a preset amplitude to the unit under test (DUT) through the board's signal output interface, while simultaneously collecting the current data in the circuit in real time through the sampling module. The collected value is compared with the theoretical threshold to determine whether the conductivity characteristics of the DUT are normal. Applying current and testing voltage refers to outputting a fixed current to the DUT through a constant current source module, simultaneously monitoring the voltage drop across the DUT, and verifying whether its impedance parameters meet the design requirements by calculating the voltage deviation value. The specified mode output waveform refers to the waveform generated by the board's waveform generator module according to the signal rules preset in the test scheme. This waveform, such as a sine wave, square wave, or pulse wave, is then output to the unit under test (DUT) to verify its response performance to dynamic signals. The frequency, amplitude, duty cycle, and other parameters of this waveform are determined by the configuration information in the test command. Those skilled in the art can select different test actions or multiple test actions simultaneously based on the actual situation.

[0039] Please refer to Figure 4Furthermore, the method also includes: synchronizing the configuration information of the test items from the host to the board before executing the test process. Specifically, the configuration information includes at least one of the following: the execution sequence of the test items, parameters for hardware interaction, and criteria for judging the test results.

[0040] In a specific example, configuration information can be transmitted in the form of data packets via a network protocol, where the data packets are encoded in binary format to reduce the amount of data transmitted.

[0041] Furthermore, configuration information can also employ verification mechanisms to ensure transmission integrity, such as cyclic redundancy check (CRC) or hash check. Thus, after receiving the configuration information, the board can pre-load and parse this information, allowing it to directly call locally stored configuration parameters when performing test actions, avoiding frequent communication with the host during testing.

[0042] To address this, the technical solution of this application synchronizes the configuration information to the board in one go before executing the test process. This allows the board to store and quickly access this information locally, thereby reducing the number of communications with the host during the test. Furthermore, since the configuration information is synchronized before the test begins, the command interaction during the test is simplified, thus improving test efficiency.

[0043] Furthermore, the method also includes: after the host sends an instruction to start the test item to all the boards participating in the test, the host suspends the execution of subsequent test items in the test process and enters a waiting state until it receives a completion status signal from all the boards participating in the test, and then continues to execute the test process.

[0044] In a specific example, after sending the start command, the host can implement the pause and wait mechanism in the following ways: First, the host internally sets a status flag to record the synchronous execution status of the current test item; second, the host starts a timer module to monitor the board's response timeout; finally, the host receives the status signal returned by the board through an interrupt mechanism or polling.

[0045] After the board completes the test, it can provide feedback on its status in the following ways: generating a status packet containing the test result code and sending it to the host via a dedicated communication channel; or writing status data in a preset format to the shared memory area. As a preferred implementation, the status signal can be in binary encoding, where a high level indicates test completion and a low level indicates a test error.

[0046] Therefore, this technical solution effectively solves the problem of asynchronous test processes caused by network communication delays in distributed testing systems by introducing a synchronous waiting mechanism.

[0047] Furthermore, in this embodiment, before executing the test process, the configuration information of the test items needs to be synchronized from the host to the board. The configuration information includes at least one of the following: the execution sequence of the test items, parameters for hardware interaction, and criteria for judging the test results.

[0048] Specifically, the execution sequence of test items defines the execution order of multiple test actions. This sequence is stored in list form, with each entry containing a test action identifier and its corresponding execution conditions. Parameters used for hardware interaction include, but are not limited to, power supply voltage settings, register address mapping tables, and memory access timing parameters. The criteria for judging test results include logical expressions such as threshold ranges, data matching modes, and timing tolerances. These criteria are stored in structured text format and dynamically loaded at the board level by a parsing engine.

[0049] In a specific example, the execution sequence can be described in XML or JSON format, where each test action node includes prerequisite dependencies and timeout settings. Hardware interaction parameters can be transmitted via a shared memory region or a dedicated configuration file and loaded into the local cache during board initialization. Judgment criteria can be implemented as script functions, dynamically invoked by the board's interpreter during test execution.

[0050] Therefore, this technical solution enables the board to autonomously execute test sequences without frequent interaction with the host by pre-synchronizing complete configuration information. The pre-setting of the execution sequence solves the timing control problem of test actions, the pre-loading of hardware parameters avoids data latency in real-time transmission, and the localization of the judgment criteria reduces the communication overhead for result feedback.

[0051] Furthermore, this application also proposes a system for parallel testing of multiple boards, the system including a host end and multiple board ends, the system being configured to perform a synchronous control method for parallel testing of multiple boards.

[0052] Example 2 This embodiment also discloses a system for parallel testing of multiple boards, wherein the configuration information includes at least one of the following: the execution sequence of the test items, parameters for hardware interaction, and judgment criteria for judging the test results.

[0053] The host computer connects to multiple boards via a network. The host computer is responsible for parsing the test process and generating test commands, while the boards are responsible for executing the specific test actions. The host computer is configured to send test commands to multiple boards simultaneously, and the boards are configured to execute the received test commands in parallel. The host computer is further configured to enter a waiting state after sending a test command, and will only continue executing the subsequent test process after receiving completion status signals from all boards.

[0054] Specifically, the host computer can be a single computer running a specific operating system, while the board-side components can be multiple independent test boards, each running an embedded operating system. Communication between the host computer and the board-side components occurs via Ethernet or a dedicated test bus. As a preferred implementation, the host computer can be equipped with multiple network interface cards (NICs), each connecting to a group of board-side components to improve communication efficiency. The board-side components can be equipped with dedicated hardware interfaces for performing specific test actions, such as power control and register configuration.

[0055] It is understandable that the technical effects that the above-mentioned multi-board parallel testing system can achieve can also be achieved by the synchronization control method for multi-board parallel testing in Embodiment 1, so it will not be described again here.

[0056] Example 3 This embodiment discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements a synchronous control method for parallel testing of multiple boards.

[0057] Specifically, after the computer program is loaded into the host processor, it can perform the following operations according to preset logic: compile the source code corresponding to the test action into a host executable file and a board dynamic link library respectively; synchronize the configuration information of the test items to multiple boards through the host; implement single-instruction batch execution or instruction-by-instruction step-by-step execution in two test modes respectively; pause the subsequent process after the host sends a start command to all boards until all completion signals are received before continuing execution.

[0058] In a preferred embodiment, the computer-readable storage medium can be implemented using non-volatile memory, such as flash memory or a solid-state drive. The stored computer program can include multiple functional modules: a compilation module for generating a cross-platform executable file; a communication module for instruction transmission between the host and the board; and a status monitoring module for collecting test completion signals from each board. Furthermore, the program can be configured to support dynamically loading test process configuration files and automatically generating corresponding test instruction sequences by parsing the configuration files.

[0059] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for parallel testing of multiple boards, characterized in that, The method includes: Configure a test process, which includes multiple test items, and each test item includes multiple test actions; In the first test mode, the host sends a test command to the board; after receiving a single test command, the board executes the test action corresponding to the test item. In the second test mode, the host sends test commands to the board one by one, and the board executes a corresponding test action after receiving each test command.

2. The multi-board parallel testing method according to claim 1, characterized in that, The method further includes, before conducting the test, compiling the same source code corresponding to the test action into a first-format executable file for use by the host and a second-format executable file for use by the board.

3. The multi-board parallel testing method according to claim 2, characterized in that, The first format executable file is configured as an executable file of the host operating system, and the second format executable file is configured as a dynamic link library of the board-side operating system.

4. The multi-board parallel testing method according to claim 3, characterized in that, The second format executable file is configured to perform only hardware interactions related to the test action; the first format executable file is configured to simulate only the test action.

5. The multi-board parallel testing method according to claim 4, characterized in that, The test actions include at least one of the following: applying voltage to test current, applying current to test voltage, outputting waveform in a specified mode, configuring function registers, and reading / writing stored data.

6. The multi-board parallel testing method according to any one of claims 1-5, characterized in that, The method further includes synchronizing the configuration information of the test item from the host to the board before executing the test process.

7. The multi-board parallel testing method according to claim 6, characterized in that, The method further includes: After the host sends the command to start the test item to all the boards participating in the test, The host terminal suspends the execution of subsequent test items in the test process and enters a waiting state until it receives completion status signals from all the boards participating in the test, after which it continues to execute the test process.

8. The multi-board parallel testing method according to claim 7, characterized in that, The configuration information includes at least one of the following: the execution sequence of the test item, parameters for hardware interaction, and judgment criteria for determining the test results.

9. A system for parallel testing of multiple boards, characterized in that, The system includes a host terminal and multiple board terminals, and the system is configured to perform a synchronous control method for multi-board parallel testing as described in any one of claims 1-8.

10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements a synchronous control method for parallel testing of multiple boards as described in any one of claims 1-8.

Images