Test method and system for functional module in chip

Abstract

The invention relates to a test method and system for a functional module in a chip, and the method comprises the steps: judging whether the firmware type of a first test firmware file loaded by a logic processing module in a resource board card of a test machine is matched with a to-be-tested second functional module in a to-be-tested chip of the current test case or not according to the current test case; a first test module constructed based on a first test firmware file runs in the logic processing module; if not, a first instruction is issued to the logic processing module to indicate that the first test firmware file is switched into a second test firmware file, and the second test firmware file is used for constructing a second test module for testing the second function module in the logic processing module to replace the first test module; and after firmware switching is completed, issuing a second instruction to the logic processing module to instruct the logic processing module to execute the current test case based on the second test module so as to test a second function module of the to-be-tested chip. The method can improve the test efficiency.

Description

Technical Field

[0001] This application relates to the field of semiconductor testing technology, and in particular to a testing method and system for functional modules in a chip. Background Technology

[0002] With the rapid development of semiconductor technology, the integration level of semiconductor chips is increasing, and the functions within chips are becoming more complex. It has become a trend for a single chip to incorporate multiple functional modules. For example, AI chips with on-chip memory and HBM (High Bandwidth Memory) with microcontrollers are chips that combine the functions of both System-on-a-Chip (SoC) and memory, and are widely used in the industry.

[0003] Different functions within a chip typically require different dedicated test modules for testing. Each dedicated test module demands significant logic resources to implement; however, test machines have limited logic resources, making it difficult to implement dedicated test modules for all functions simultaneously while ensuring efficient resource utilization. Therefore, traditional chip test machines can usually only perform targeted testing of a specific business function, and cannot test multiple functions within a single chip using a single test machine, resulting in relatively low chip testing efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a testing method, system, electronic device, computer-readable storage medium, and computer program product for functional modules in a chip that can improve testing efficiency in response to the above-mentioned technical problems.

[0005] Therefore, it is necessary to provide a testing method, system, electronic device, computer-readable storage medium, and computer program product for functional modules in a chip that can improve testing efficiency in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a testing method for functional modules in a chip, including:

[0007] For the current test case to be executed, determine whether the firmware type of the first test firmware file loaded by the logic processing module in the resource board of the test machine matches the second functional module in the chip under test; wherein, the second functional module is the functional module to be tested in the current test case; the logic processing module runs the first test module built based on the first test firmware file;

[0008] If the firmware type of the first test firmware file does not match the second functional module, a first instruction is issued to the logic processing module; wherein, the first instruction is used to instruct the first test firmware file to be switched to the second test firmware file, and the second test firmware file is used to build a second test module in the logic processing module to test the second functional module, in order to replace the first test module;

[0009] After the second test firmware file is switched, a second instruction is issued to the logic processing module; the second instruction is used to instruct the logic processing module to execute the current test case based on the second test module in order to test the second functional module of the chip under test.

[0010] Before issuing the first instruction to the logic processing module, the method also includes:

[0011] The system checks whether the first test module is in an idle state. If so, it issues a first instruction to the logic processing module. The first test module has the function of testing the first functional module in the chip under test.

[0012] In one embodiment, the first test module includes a graphics generator, a test result storage module, and a timing control module; the timing control module includes a waveform interrupt unit; the resource board also includes an autonomous operation unit;

[0013] Check if the first test module is in an idle state. If so, issue the first instruction to the logic processing module, including:

[0014] Check whether the graphics generator, test result storage module, waveform interrupt unit, and autonomous operation unit are all in an idle state;

[0015] If all are in an idle state, then the first instruction is sent to the logic processing module.

[0016] In one embodiment, if the firmware type of the first test firmware file does not match the second functional module, a first instruction is issued to the logic processing module, including:

[0017] If the firmware type of the first test firmware file does not match the second functional module, the output mode of the pin electronics is switched from the current first output mode to the second output mode, and a first instruction is issued to the logic processing module. In the first output mode, the logic processing module controls the test signal output to the chip under test; in the second output mode, the pin electronics autonomously control the test signal output to the chip under test.

[0018] After the second test firmware file switch is completed, a second instruction is issued to the logic processing module, including:

[0019] After the second test firmware file is switched and the second output mode is switched back to the first output mode, a second instruction is sent to the logic processing module.

[0020] In one embodiment, in the first output mode, the pin electronics output a test signal for the chip under test based on the output state value of the timing control module within the logic processing module.

[0021] Switching the output mode of the pin electronics from the current first output mode to the second output mode includes:

[0022] From the logic processing module, obtain the last output state value of the timing control module in the first output mode to obtain the target output state value;

[0023] The target output status value is written to the first register of the pin electronics as the output status value in the second output mode, and the first output mode is switched to the second output mode. In the second output mode, the pin electronics autonomously outputs a test signal for the chip under test based on the output status value in the first register.

[0024] In one embodiment, the pin electronics have multiple pin channels; the target output state value is obtained from the logic processing module by acquiring the last output state value of the timing control module in the first output mode, including:

[0025] From the logic processing module, obtain the last output state value of the timing control module for each pin channel in the pin electronic device in the first output mode, and obtain the target output state value corresponding to each pin channel respectively;

[0026] The step of writing the target output state value to the first register of the pin electronics as the output state value in the second output mode includes:

[0027] The target output status value corresponding to each target pin channel is written to the first register of the pin electronics as the output status value of the target pin channel in the second output mode; wherein, the target pin channel is the pin channel in the pin electronics that has not been configured with an output status value by the user.

[0028] In one embodiment, after the second test firmware file switch is completed, the method further includes:

[0029] Write the current output status value in the second output mode to the static timing configuration register corresponding to the second test module;

[0030] The second register of the logic processing module is written to switch the second output mode back to the first output mode; after switching back to the first output mode, the timing control module outputs a test signal for the chip under test based on the output status value written in the static timing configuration register.

[0031] In one embodiment, before determining whether the firmware type of the first test firmware file loaded by the logic processing module in the test machine matches the second functional module in the chip under test for the current test case to be executed, the method further includes:

[0032] The first instruction sends a set of configuration information for test cases to the logic processing module, so that the logic processing module stores the set of configuration information for test cases in memory. The second instruction is used to instruct the logic processing module to retrieve the target configuration information of the current test case to be executed from memory, and to execute the current test case based on the second test module and the target configuration information.

[0033] In one embodiment, determining whether the firmware type of the first test firmware file loaded by the logic processing module in the test machine matches the second functional module in the chip under test includes:

[0034] Read the value of the firmware information register from the logic processing module; the value of the firmware information register is used to characterize the firmware type of the currently configured test firmware file.

[0035] The firmware type of the first test firmware file is determined based on the value of the firmware information register to determine whether it matches the second functional module in the chip under test.

[0036] In one embodiment, the logic processing module preloads a common function firmware file and a first test firmware file after the test machine is powered on; after the common function firmware file is loaded, it is used to build the common function module in the static area of ​​the logic processing module; the first test module is built in the dynamic area of ​​the logic processing module.

[0037] During the switching process of the second test firmware file, the common function modules in the logic processing module operate normally. After the switching of the second test firmware file is completed, the first test module built in the dynamic area is replaced by the second test module.

[0038] In one embodiment, the test machine includes multiple test heads, each test head includes multiple resource boards, and each resource board has a logic processing module; different test heads are used to test the same or different functional modules in the chip under test; the same test head is used to test the same functional module in the chip under test.

[0039] Secondly, this application also provides a testing system for functional modules in a chip, the system including: a logic processing module in the resource board of a lower-level machine and a test machine; the lower-level machine includes a driver module;

[0040] The driver module is used to determine, for the current test case to be executed, whether the firmware type of the first test firmware file loaded by the logic processing module matches the second functional module in the chip under test; wherein, the second functional module is the functional module to be tested in the current test case; the logic processing module runs the first test module built based on the first test firmware file;

[0041] The driver module is also used to issue a first instruction to the logic processing module when the firmware type of the first test firmware file does not match the second functional module.

[0042] The logic processing module is used to switch the first test firmware file to the second test firmware file in response to the first instruction, and to build a second test module for testing the second functional module based on the second test firmware file, so as to replace the already built first test module.

[0043] The driver module is also used to send a second instruction to the logic processing module after the second test firmware file is switched;

[0044] The logic processing module is also used to respond to the second instruction and execute the current test case based on the second test module to test the second functional module of the chip under test.

[0045] Thirdly, this application also provides an electronic device. The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method mentioned in the first aspect above.

[0046] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the method mentioned in the first aspect above.

[0047] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the method mentioned in the first aspect above.

[0048] The aforementioned testing methods, systems, electronic devices, computer-readable storage media, and computer program products for functional modules in a chip, before executing the current test case, first determine whether the firmware type of the first test firmware file loaded by the logic processing module in the resource board of the test machine matches the second functional module in the chip under test. If they do not match, a first instruction is issued to the logic processing module to instruct it to switch the first test firmware file to a second test firmware file. This second test firmware file is used to construct a second test module for testing the second functional module, replacing the already constructed first test module. After the second test firmware file switch is completed, a second instruction can be issued to the logic processing module to instruct it to execute the current test case based on the second test module, thereby testing the second functional module of the chip under test. In other words, corresponding test firmware files are set for different functional modules in the chip. Utilizing the reprogrammable nature of logic processing modules (such as FPGAs), it is not necessary to load dedicated test modules corresponding to all functional modules in the chip under test simultaneously. Instead, the target test firmware file matching the current functional module under test can be switched and loaded flexibly and conveniently to achieve dedicated testing of the current functional module under test. In this way, there is no need to replace the test machine; instead, dynamic testing of multiple test functions in the chip can be achieved with a single test machine, greatly improving testing efficiency. Furthermore, requiring only one test machine to perform testing of multiple functions in the chip, instead of setting up multiple test machines, significantly reduces hardware costs. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating a testing method for functional modules in a chip in one embodiment;

[0050] Figure 2 This is a flowchart illustrating a testing method for functional modules in a chip, as shown in another embodiment.

[0051] Figure 3 This is a schematic diagram of the firmware switching process in one embodiment;

[0052] Figure 4 This is a flowchart illustrating the state check process before firmware switching in one embodiment.

[0053] Figure 5 This is a schematic diagram illustrating the relationship between output mode switching in one embodiment;

[0054] Figure 6 This is a flowchart illustrating the output mode switching process in one embodiment;

[0055] Figure 7 This is a schematic diagram of the firmware switching and module initialization process in one embodiment;

[0056] Figure 8 This is a flowchart illustrating the process of restoring the output mode in one embodiment;

[0057] Figure 9 This is a block diagram of an electronic device in one embodiment. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0059] It should be understood that, unless otherwise defined, all technical terms used herein have the same meaning as commonly understood by those skilled in the art. The technical terms used herein are for the purpose of describing specific examples only and are not intended to limit the scope of this application.

[0060] Before formally introducing the solutions in the embodiments of this application, the relevant technical terms are explained:

[0061] Freerunning (autonomous running unit): This refers to a free clock output, a continuously oscillating clock signal that runs even without data transmission or test operations.

[0062] Breakwaveform (Waveform Interruption Unit): During the test, if the Pattern of the test list is interrupted or ends, maintain a certain level or specific clock state output.

[0063] The IOCTRL module (Input / Output Control Module) is a dedicated test module for SOCs. It converts the required SOC-type pattern data into corresponding waveform data and compares the response signals of the corresponding pins of the device under test with the expected values ​​to obtain the test comparison results. In this embodiment, it can also be referred to as the first timing control module.

[0064] The SRM module (first test result storage module) is a dedicated test module for the SOC, used for storing and processing test result information of the SOC functional modules. In this embodiment, it can also be called the cache control module.

[0065] PG module (first pattern generator): also known as the test vector generation module, is a dedicated test module for SOC, used to generate and store the pattern data required during SOC functional testing.

[0066] The ALPG module, also known as the algorithm graphics generator or algorithm test vector generation module, is a dedicated MEMORY test module (i.e., a dedicated function block for MEMORY testing). It is used to generate and store the pattern data required during MEMORY functional testing. It should be understood that both the PG module and the ALPG module are graphics generators, but they reside in different specialized test modules. For clarity, the PG module in the SOC-specific test module will be referred to as the first graphics generator, and the ALPG module in the MEMORY-specific test module will be referred to as the second graphics generator.

[0067] The TIMING module (second timing control module) is a dedicated MEMORY test module. It converts the required MEMORY-type pattern data into corresponding waveform data and compares the response signals of the corresponding pins of the device under test with the expected values ​​to obtain the test comparison results. It should be understood that both the IOCTRL module and the TIMING module belong to timing control modules, but are located in different specialized test modules. For clarity, the IOCTRL module corresponding to the SOC is referred to as the first timing control module, and the TIMING module corresponding to the MEMORY module is referred to as the second timing control module.

[0068] The MRM module (Second Test Result Storage Module) is a dedicated test module for MEMORY, used for storing and processing test result information from MEMORY functional modules. It should be understood that both the SRM and MRM modules are test result storage modules, but they reside within different specialized test modules. For clarity, the SRM module will be referred to as the First Test Result Storage Module, and the MRM module as the Second Test Result Storage Module.

[0069] PE (Pin Electronics Chip): is a dedicated circuit or integrated circuit in an automated test equipment (ATE, also known as a test machine) used to drive, sample, and control the signals of each pin of the chip under test. It is the "interface bridge" connecting the test machine and the chip under test.

[0070] Dynamic configuration module: Used to enable dynamic reconfiguration of logic processing modules.

[0071] Dynamic reconfiguration component: This is a component in the logic processing module used to dynamically reconfigure the firmware in the logic processing module.

[0072] Non-volatile memory: Used to store the default test firmware file when the logic processing module is first powered on. In some examples of this application, the non-volatile memory may also store the entire test firmware file, which is not limited thereto.

[0073] This application proposes a testing method for functional modules in a chip under test (CUT) that improves testing efficiency. This method can be applied to a testing system. The testing system includes a host computer, a slave computer, and a logic processing module. The slave computer includes a driver module, which executes the testing method for functional modules in the chip according to this application.

[0074] In some embodiments, the test system includes a host computer, a slave computer, a communication board, and a resource board. The resource board is equipped with a logic processing module. Test commands issued by the driver module of the slave computer are forwarded to the resource board via the communication board, causing the logic processing module of the resource board to execute test functions. The resource board can be a power supply board, a digital board, a high-speed test board, etc. Different resource board types receive different test commands and execute different test functions. The resource board may include a service board and service sub-boards with communication connections, and the logic processing module can be located on the service board or the service sub-board. For example, the resource board is a digital board.

[0075] For example, the host computer includes upper-level software. The upper-level software provides an interface for interaction with the user. The user can specify functional modules such as SOC / MEMORY in the test chip, configure test cases for testing the SOC / MEMORY functional modules, and configure test firmware files based on the interface provided by the upper-level software. The lower-level driver module can send the selected or configured information and other instructions generated by the upper-level software to the resource board.

[0076] In this embodiment, the driver module not only forwards data but also executes the testing methods for functional modules within the chip. For example, before instructing the execution of a specific test case, the driver module can determine whether the test firmware file loaded by the logic processing module matches the test firmware file required by the current test case. If they match, it issues an instruction to execute the current test case; otherwise, it issues an instruction to switch firmware (referred to as a firmware switching instruction). After switching to a matching test firmware file, it then issues an instruction to execute the current test case.

[0077] The logic processing module in this embodiment is reprogrammable. Therefore, different functional modules in the chip under test have different implementation structures, and different implementation structures contain different modules (not all modules are necessarily different, but at least some modules are different). Thus, the driver module can instantly switch the internal implementation structure by issuing firmware switching commands, leveraging the reprogrammable nature of the logic processing module. This allows for switching tests of different functional modules in the chip under test on the same hardware device, reducing hardware costs and significantly improving testing efficiency in multi-application scenarios.

[0078] Taking a chip under test (DUT) that includes both MEMORY and SOC functions as an example, the logic processing module can create a test module for testing the MEMORY function or a test module for testing the SOC function. The test modules for the MEMORY and SOC functions differ. For instance, the MEMORY function test module includes dedicated MEMORY test modules such as a second graphics generator, a second timing control module, and a second test result storage module, while the SOC function test module includes dedicated SOC test modules such as a first graphics generator, a first timing control module, and a first test result storage module. Exemplarily, the test modules for both MEMORY and SOC functions also include some common functional modules, such as a communication module and a main control module. The MEMORY / SOC test modules are connected to pin electronics, which transmit test signals to the DUT and also collect the DUT's response signals. In this embodiment, the pin electronics are PE chips.

[0079] like Figure 1 As shown, in some embodiments, a testing method for functional modules in a chip is provided. This method is applied to the driver module of a lower-level machine and specifically includes the following steps:

[0080] S11, for the current test case to be executed, determine whether the firmware type of the first test firmware file loaded by the logic processing module in the resource board of the test machine matches the second functional module in the chip under test; wherein, the second functional module is the functional module to be tested in the current test case; the logic processing module runs a first test module built based on the first test firmware file.

[0081] Specifically, for different functional modules in the chip under test (e.g., SOC functional modules, MEMORY functional modules), there are corresponding test firmware files. Each test firmware file is used to create a test module to test the corresponding functional module in the chip under test. That is, the test module created based on the test firmware file has the function of testing the corresponding functional module in the chip under test. The test machine tests the functional modules in the chip under test by executing test cases; each test case is used to test the corresponding functional module.

[0082] When executing each current test case, the logic processing module has already loaded the first test firmware file and created and ran the first test module based on the first test firmware file. The driver module can determine whether the firmware type of the first test firmware file currently loaded by the logic processing module matches the second functional module that the current test case wants to test for the chip under test (equivalent to determining whether the first test module created based on the first test firmware file has the testing function for the second functional module in the chip under test). If not, step S12 is executed; if yes, the current test case can be directly executed based on the first test module to test the second functional module.

[0083] In this application embodiment, the test firmware files corresponding to each functional module in the chip under test can be discussed in the following two examples (Example 1 and Example 2).

[0084] In Example 1, the test firmware files corresponding to each functional module in the chip can be complete test firmware files. That is, the first test firmware file and the second test firmware file are complete test firmware files corresponding to different functional modules. Based on the complete test firmware files, test modules with complete testing functions for the corresponding functional modules can be created.

[0085] For example, if the logic processing module loads the complete test firmware file corresponding to the MEMORY function module, loading the test firmware file can create all the modules required for testing the MEMORY function module, such as the alarm module, main control module, peripheral interface module, and MEMORY-specific test module. In other words, these created test modules can be combined to achieve complete testing of the MEMORY function module.

[0086] In Example 2, the complete test firmware file for implementing functional testing of the logic processing module is split into a common functional firmware file and a dedicated test firmware file.

[0087] The common function firmware file is used to implement basic general or common functions of the logic processing module. These general functions are not limited to the testing of a specific functional module in the chip under test, but are applicable to the testing of all functional modules in the chip under test. Therefore, loading this common function firmware file can create common function modules such as alarm modules and main control modules.

[0088] For each functional module in the chip under test (DUT), a corresponding dedicated test firmware file can be set. Therefore, the first test firmware file and the second test firmware file are respectively the first dedicated test firmware file and the second dedicated test firmware file corresponding to different functional modules. After the dedicated test firmware file is loaded, it is used to create test modules (i.e., dedicated test modules) that are only applicable to the corresponding functional module in the DUT. For example, the dedicated MEMORY test firmware file corresponding to the MEMORY functional module is only used to create dedicated MEMORY test modules such as the algorithm graphics generator and timing control module, and cannot be used to create common functional modules such as the alarm module and the main control module.

[0089] It should be understood that a dedicated test module cannot test a corresponding functional module independently. Instead, it needs to be combined with a common functional module and work together to achieve complete testing of that functional module. Therefore, in Example 2, the logic processing module loads the common functional firmware file and the default dedicated test firmware file to create the common functional module and the corresponding dedicated test module, thereby ensuring complete test functionality.

[0090] The difference between Example 1 and Example 2 lies in the following: In Example 1, since each functional module under test corresponds to a complete test firmware file, the logic processing module needs to be restarted every time firmware is switched (i.e., the test firmware file is switched). In Example 2, each functional module under test corresponds to a portion of dedicated test firmware files. When switching firmware, the common functional modules created from the common functional firmware files can continue to operate normally, and the dedicated test firmware files can be switched without restarting the logic processing module. Compared to Example 1, the solution in Example 2 improves testing efficiency and avoids other problems caused by restarting.

[0091] In some embodiments, the logic processing module includes a firmware information register. The value of the firmware information register is used to characterize the firmware type (i.e., the current firmware type) of the currently configured test firmware file. For example, a value of 0 in the firmware information register indicates that a MEMORY-specific test firmware file (i.e., a dedicated test firmware file for testing the MEMORY functional module in the chip) is currently loaded, and a value of 1 in the firmware information register indicates that a SOC-specific test firmware file (i.e., a dedicated test firmware file for testing the SOC functional module in the chip) is currently loaded. The driver module can read the value of the firmware information register from the logic processing module and determine whether the firmware type of the first test firmware file matches the second functional module in the chip under test based on the read value of the firmware information register.

[0092] S12, if the firmware type of the first test firmware file does not match the second functional module, a first instruction is issued to the logic processing module; wherein, the first instruction is used to instruct the first test firmware file to be switched to the second test firmware file, and the second test firmware file is used to build a second test module in the logic processing module to test the second functional module, in order to replace the first test module.

[0093] If the firmware type of the first test firmware file does not match that of the second functional module, it indicates that the first test module does not have the function to test the second functional module, but has the function to test other functional modules in the chip under test (such as the first functional module). Therefore, a first instruction to switch firmware can be issued to the logic processing module.

[0094] In some embodiments, if the firmware type of the first test firmware file does not match the second functional module, the driver module can directly issue a first instruction to the logic processing module.

[0095] In some embodiments, the driver module may first perform a pre-firmware switching status check to detect whether the current state of the resource board in the test machine meets the switching conditions. If so, it sends a first instruction to the logic processing module; otherwise, it waits until the resource board's state meets the switching conditions before sending the first instruction to the logic processing module. Specifically, the driver can continuously poll the logic processing module of the corresponding resource board to detect whether the resource board in the test machine meets the switching conditions. This can avoid erroneous switching that could waste system resources or cause malfunctions.

[0096] In some embodiments, if the firmware type of the first test firmware file does not match the second functional module, the driver module can switch the output mode of the pin electronics from the current first output mode to the second output mode, and then issue a first instruction to the logic processing module. In the first output mode, the logic processing module controls the test signal output to the chip under test. Taking an FPGA as an example, the first output mode can be simply referred to as the FPGA output mode. In the second output mode, the pin electronics autonomously control the test signal output to the chip under test. Therefore, the second output mode can be called the pin electronics autonomous output mode or the PE autonomous output mode. This makes the firmware switching process imperceptible to the chip under test (i.e., the user side).

[0097] Upon receiving the first instruction, the logic processing module performs a firmware switching process to switch the first test firmware file to a second test firmware file. Specifically, the logic processing module can load the second test firmware file to construct a second test module capable of testing the second functional module, replacing the first test module, thus achieving firmware switching.

[0098] S13, after the second test firmware file is switched, a second instruction is sent to the logic processing module; wherein, the second instruction is used to instruct the logic processing module to execute the current test case based on the second test module in order to test the second functional module of the chip under test.

[0099] In some embodiments, after the second test firmware file is switched and the second output mode is switched back to the first output mode, a second instruction is issued to the logic processing module. For example, the PE autonomous output mode can be switched back to the FPGA output mode through the static function (i.e., static timing configuration function).

[0100] After receiving the second instruction, the logic processing module responds to the second instruction, obtains the target configuration information of the current test case, and executes the current test case based on the second test module created after the firmware switch and the target configuration information, thereby testing the second functional module of the chip under test.

[0101] In some embodiments, the driver module may pre-deploy a set of configuration information for each test case to be executed in the current test round to the logic processing module, allowing the logic processing module to store the set of test case configuration information in memory. It should be understood that the configuration information for each test case includes specific execution information, such as sending time, length, test vector value, and expected value. The second instruction instructs the logic processing module to retrieve the target configuration information of the current test case to be executed from memory and execute the current test case based on the second test module and the target configuration information. For example, the logic processing module retrieves the target configuration information of the current test case from memory according to the address indicated by the second instruction.

[0102] Furthermore, after executing the current test case, the next test case to be executed in this round of testing is taken as the new current test case, and steps S11 to S13 are executed in a loop until the end of this round of testing.

[0103] In the above method, before executing the current test case, it is first determined whether the firmware type of the first test firmware file loaded by the logic processing module in the test machine matches the second functional module in the chip under test. If they do not match, a first instruction is issued to the logic processing module to switch the first test firmware file to a second test firmware file. This second test firmware file is used to construct a second test module for testing the second functional module, replacing the already constructed first test module. After the second test firmware file switch is completed, a second instruction can be issued to the logic processing module to execute the current test case based on the second test module, thus testing the second functional module of the chip under test. That is, corresponding test firmware files are set for different functional modules in the chip. Utilizing the reprogrammable nature of the logic processing module (such as an FPGA), it is not necessary to load dedicated test modules corresponding to all functional modules in the chip under test simultaneously. Instead, the target test firmware file matching the current functional module under test can be flexibly and conveniently switched to be loaded, enabling the dedicated test module of the current functional module under test to be tested. Thus, without replacing the test machine, dynamic testing of multiple test functions in the chip can be achieved with a single test machine, greatly improving testing efficiency. Furthermore, only one tester is needed to test multiple functions in the chip, eliminating the need for multiple testers and significantly reducing hardware costs.

[0104] In some embodiments, the test machine includes multiple test heads, each test head including multiple resource boards, and each resource board having a logic processing module. For example, each test head includes multiple service sub-boards, each of which is a resource board and contains a logic processing module. Different test heads are used to test the same or different functional modules in the chip under test; the same test head is used to test the same functional module in the chip under test. This enables multi-functional parallel testing, greatly improving testing efficiency.

[0105] For ease of understanding, Figure 2 Used to provide an overview of the overall testing process. For example... Figure 2 As shown, after the test machine is powered on, different users (such as users A to D) complete the login operation via the host computer. Then, the test head selected by each user is initialized. For example, the test machine has four test heads (i.e., four quadrants or cavities), each with the same function and configuration. Each logged-in user can select one test head, and each test head contains a resource board, thus initializing the resource board in the selected test head. The resource board is equipped with a logic processing module. It should be understood that parallel testing can be achieved through multiple test heads, improving testing efficiency. Since the processing principle is the same for each test head, the following only describes how a single test head executes the testing method for the functional modules in the chip implemented in this application.

[0106] Please continue reading. Figure 2 During initialization, the logic processing module on the resource board in each test header loads the default first test firmware file. After initialization, the configuration information of each test case configured by the user for this round of testing is sent to the driver module, which then sends the configuration information of each test case to the memory of the logic processing module for storage. Furthermore, each test case can be executed iteratively. For example, the test cases can be executed iteratively using a runflow process.

[0107] When executing each current test case, it checks whether the test firmware file required by the current test case is consistent with the first test firmware file (equivalent to checking whether the firmware type of the first test firmware file matches the second functional module to be tested in the current test case). If yes, the current test case is executed; if no, the logic processing module is instructed to perform a firmware switch, and further, complete the necessary initialization operations after the firmware switch (in this case, the second test module can be recreated to replace the first test module), and then the current test case can be executed. After executing the current test case, the driver module checks whether all test cases in this round of testing have been executed. If no, the next test case to be executed is taken as the current test case, and the execution of each test case is repeated iteratively; if yes, the current round of testing ends.

[0108] Taking an FPGA as an example, combining... Figure 3 This diagram illustrates the specific process for firmware switching. Please refer to [link / reference]. Figure 3 The driver module can obtain the test function identifier from the software provider through a preset interface. The test function identifier represents the test firmware file required by the current test case. Specifically, the test function identifier refers to the identifier of the functional module (i.e., the second functional module) that the current test case wants to test for the chip under test, and therefore reflects the test firmware file required by the current test case. Specifically, the host computer includes the software provider. Users can select or specify the second functional module they want to test through the interface provided by the software provider, and the software provider can send its function identifier to the driver module through a preset interface.

[0109] Please continue reading. Figure 3 The driver module determines whether the currently loaded first test firmware file is consistent with the test firmware file required by the current test case. If yes, the current test case is executed. If not, it checks whether the current state of the resource boards in the test machine meets the switching conditions.

[0110] If the switching conditions are met, the output mode of the pin electronics is switched from FPGA output mode to PE autonomous output mode. Further, the driver module instructs the firmware switch, and then initializes the second test module based on the switched second test firmware file. Further, the output mode of the pin electronics is switched back to FPGA output mode via static timing configuration, thus completing the firmware switch. The current test case can then be executed.

[0111] If the switching conditions are not met, a notification will be sent. This notification informs the user that the current status of the resource cards in the test machine does not meet the switching conditions and requires action. This situation indicates that the firmware switching has failed.

[0112] In some embodiments, if the firmware type of the first test firmware file does not match that of the second functional module, the driver module may detect whether the first test module is in an idle state before issuing the first instruction to the logic processing module. If so, it indicates that the current state of the resource board in the test machine meets the switching conditions, and then the driver module issues the first instruction to the logic processing module. If not, the driver module waits for the first test module to become idle before issuing the first instruction to the logic processing module.

[0113] In some embodiments, the first test module includes a graphics generator, a test result storage module, and a timing control module; the timing control module includes a waveform interrupt unit; the resource board also includes an autonomous operation unit. The driver module can detect whether the graphics generator, test result storage module, waveform interrupt unit, and autonomous operation unit are all in an idle state; if they are all in an idle state, it issues a first instruction to the logic processing module.

[0114] like Figure 4 As shown, before triggering the firmware switch, the resource board status check in the test machine is performed, and the first test module currently created is checked in the first output mode. Specifically, the check can be divided into case 1 and case 2.

[0115] Scenario 1: The first test module is used to test the on-chip system functional module (i.e., the first functional module is the SOC functional module in the chip under test). The second functional module is the memory functional module.

[0116] Scenario 2: The first test module is used to test the storage function (i.e., the first functional module is the MEMORY functional module in the chip under test). The second functional module is the system-on-chip functional module—that is, the SOC functional module.

[0117] In scenario 1, taking a resource board that includes an autonomous operating unit, and a first test module that includes a first graphics generator, a first test result storage module, and a first timing control module as an example, please refer to [link to relevant documentation]. Figure 4The system can determine whether the first graphics generator, the first test result storage module, the waveform interrupt unit in the first timing control module, and the autonomous operation unit are idle. If all are idle, the status check passes. It should be understood that the order of these checks is not limited to... Figure 4 The order shown is sufficient to detect and judge the above objects.

[0118] In scenario 2, taking a resource board that includes an autonomous operating unit, and the first test module that includes a second graphics generator, a second test result storage module, and a second timing control module as an example, please refer to the following documentation. Figure 4 The system can determine whether the second graphics generator, the second test result storage module, the waveform interrupt unit in the second timing control module, and the autonomous operation unit are all in an idle state. If all are in an idle state, the status check passes. Similarly, the order of the judgment processes is not limited to... Figure 4 The order shown.

[0119] It should be understood that if any of the above modules does not meet the switching conditions, the specific module that does not meet the switching conditions can be reported to the user, indicating that the status check failed. This solution can more accurately determine whether the switching conditions are met, thereby avoiding system resource waste or failures caused by erroneous firmware switching.

[0120] As mentioned above, when the current state of the resource board in the test machine is detected to meet the switching conditions, the current output mode of the pin electronics needs to be switched from the first output mode to the second output mode (i.e., PE autonomous output mode) before firmware switching. This ensures that the output state of the test machine remains unchanged during firmware switching. In other words, the firmware switching process is imperceptible to the chip under test.

[0121] Specifically, in the first output mode, the pin electronics output a test signal for the chip under test based on the output state value of the timing control module within the logic processing module. The driver module can obtain the target output state value from the last output state value of the timing control module in the first output mode from the logic processing module.

[0122] Furthermore, the target output status value is written to the first register of the pin electronics as the output status value in the second output mode, and the first output mode is switched to the second output mode; wherein, in the second output mode, the pin electronics autonomously outputs a test signal for the chip under test based on the output status value in the first register.

[0123] Switch switching relationship as follows Figure 5As shown. Figure 5 As shown, in FPGA output mode, the connection switch of the chip under test (DUT) is connected to the "first output" terminal (i.e., the external pin of the pin electronics) of the pin electronics. Then, the timing control module inside the FPGA transmits the test signal to the pin electronics through the "first output" terminal, and then outputs it to the DUT. Thus, the test signal output by the pin electronics is essentially determined by the signal output by the timing control module. After switching to PE autonomous output mode, the connection switch of the DUT is connected to the "second output" terminal (i.e., the module inside the pin electronics that can autonomously generate test signals). Therefore, the test signal output by the pin electronics is no longer controlled by the timing control module, but is autonomously controlled by the pin electronics itself.

[0124] For example, the pin electronics has multiple pin channels (i.e., PE channels). The driver module can obtain from the logic processing module the last output state value of the timing control module for each pin channel in the pin electronics in the first output mode, and obtain the target output state value corresponding to each pin channel respectively; write the target output state value corresponding to each target pin channel to the first register of the pin electronics as the output state value of the target pin channel in the second output mode; wherein, the target pin channel is the pin channel in the pin electronics that has not been configured with an output state value by the user. It should be understood that the pin channels whose output state values ​​are configured by the user (i.e., non-target pin channels) do not need to have their output state values ​​provided by the timing control module in the logic processing module, but are directly specified and configured by the user, and therefore are not affected by firmware switching, so no processing is required.

[0125] Taking an FPGA as an example, combining... Figure 6 This illustrates the specific switching process for the output mode. Please refer to [link / reference]. Figure 6The driver module issues instructions to write to the FPGA registers, recording relevant information about the current FPGA output mode. It should be understood that the recorded information about the FPGA output mode before the switch refers to the information needed to successfully switch back to the FPGA output mode after a subsequent firmware update. The driver module obtains the last output status value of the timing control module from the FPGA. Further, it checks the driver-level modules to determine if there is a pin channel with a user-configurable output status value. If so, for that pin channel, the user-configured output status value is overwritten with the last obtained output status value of the timing control module. It should be understood that subsequent test signals are directly output to that pin channel based on the user-configured output status value. If not, for pin channels without a user-configured output status value, the last output status value of the timing control module is used as the target output status value for that pin channel. The driver module writes the target output status value to the first register of the pin electronics as the output status value in PE autonomous output mode and switches the FPGA output mode to PE autonomous output mode.

[0126] It should be understood that firmware switching can begin after the current output mode of the pin electronics is switched to the second output mode (i.e., PE autonomous output mode). After the firmware switch is complete, the current output mode of the pin electronics needs to be switched back to the FPGA output mode. For example, this can be done according to... Figure 6 The relevant information about the FPGA output mode recorded in the document is used to switch back to the FPGA output mode.

[0127] In some embodiments, the second test firmware file required by the current test case is issued by the driver module. For example, the driver module can issue the second test firmware file required by the current test case to a designated area in the logic processing module (i.e., a dedicated area in the logic processing module's memory for storing temporary test firmware files to be switched), so that the logic processing module loads the second test firmware file to switch firmware. Issuing the test firmware file by the driver module reduces the storage space occupied by non-volatile memory.

[0128] like Figure 7As shown, the driver module selects the corresponding second test firmware file based on the firmware type to be switched. The driver module broadcasts the second test firmware file to each service slot in a single test head. Assuming there are 16 service slots, each service slot corresponds to a resource board, and each resource board corresponds to at least one service sub-board. Therefore, the logic processing module in the service sub-board corresponding to each service slot updates its firmware based on the broadcast second test firmware file. The driver module can poll each service slot to confirm whether the logic processing module within the service slot has completed the firmware update. If not (i.e., firmware update error), it returns and broadcasts the second test firmware file to each service slot in the single test head to re-broadcast the firmware. If yes (i.e., firmware update complete), it synchronizes the clocks of multiple service slots.

[0129] Then, depending on the switched firmware type, the relevant initialization operations of the test module are performed (i.e., initializing the relevant registers and driver caches of the test module). Specifically, if the switched firmware type is SOC firmware, the driver caches of each module in the SOC-specific test module and the registers of each module in the SOC-specific test module are initialized. If the switched firmware type is MEMORY firmware, the driver caches of each module in the MEMORY-specific test module and the registers of each module in the MEMORY-specific test module are initialized.

[0130] In other embodiments, the second test firmware file can also be obtained by the logic processing module from non-volatile memory. Specifically, multiple test firmware files are pre-stored in the non-volatile memory, each corresponding to a functional module in the chip under test. After the driver module issues an instruction to switch firmware, the logic processing module can obtain the indicated second test firmware file from the non-volatile memory. For example, the driver module can issue the storage address and length of the second test firmware file in the non-volatile memory, thereby enabling the logic processing module to obtain the second test firmware file.

[0131] In some embodiments, after the second test firmware file is switched, the output mode of the pin electronics needs to be restored from the second output mode (PE autonomous output recovery mode) to the first output mode (such as FPGA output mode), which is mainly achieved by the static function of the timing control module of the logic processing module.

[0132] Specifically, the driver module writes the current output status value in the second output mode to the static timing configuration register corresponding to the second test module. Further, the second register of the logic processing module can be written to switch the second output mode back to the first output mode; after switching back to the first output mode, the timing control module outputs a test signal for the chip under test based on the output status value written in the static timing configuration register.

[0133] like Figure 8 As shown, taking an FPGA as an example of a logic processing module, the output mode is restored according to the switched firmware type. If the firmware type is SOC firmware, the static timing configuration register corresponding to the first timing control module is written to the current output status value in PE autonomous output mode. If the firmware type is MEMORY firmware, the static timing configuration register corresponding to the second timing control module is written to the current output status value in PE autonomous output mode. Further, the FPGA's second register is written to switch the PE autonomous output mode back to FPGA output mode. The driver module can poll to confirm whether the FPGA output mode switch is complete. If not, it continues to wait for polling; if complete, based on the relevant information of the FPGA output mode recorded before the switch, it restores the FPGA latching PE output status register function, thereby completely restoring the FPGA output mode. For ease of understanding, combined with... Figure 6 To explain, Figure 6 Before switching firmware and when the driver issues commands, it writes information about the current (i.e., before the switch) FPGA output mode to the FPGA registers. Therefore, the information recorded before the switch can be used to restore the FPGA latched PE output status register function. The FPGA latched PE output status register function is a common function in FPGA output mode, used to inform the FPGA of the output status values ​​sent to the pin electronics each time. This function is disabled after switching to PE autonomous output mode; therefore, it is restored when switching back to FPGA output mode.

[0134] In some embodiments, the logic processing module includes a static area and a dynamic area. The functions in the static area are fixed and remain unchanged. As long as the logic processing module is powered on, this part of the logic in the static area continues to run to maintain the original functions. The functions in the dynamic area can be changed dynamically, such as by reloading a new bitstream file (i.e., a test firmware file).

[0135] As shown in Example 2 above, for any functional module in the chip under test that is specified for testing, it is no longer necessary to configure a complete test firmware file for it. Instead, two files are generated: a common functional firmware file and a dedicated test firmware file for that functional module. Therefore, the first test firmware file loaded by default can be referred to as the first dedicated test firmware file.

[0136] After power-on, the logic processing module can load the common function firmware file to build the common function module in its static area. In addition, the logic processing module will also load the first dedicated test firmware file by default to build the corresponding first test module in its dynamic area; this first test module can be referred to as the first dedicated test module. If the second function module that the current test case wants to test does not match the firmware type of the first dedicated test firmware file, the driver module can issue a first instruction to cause the logic processing module to switch to loading the second dedicated test firmware file corresponding to the second function module, thereby creating the second dedicated test module corresponding to the second function module in the dynamic area to replace the first dedicated test module.

[0137] Furthermore, the logic processing module can subsequently execute the current test case to test the second functional module through the collaborative cooperation between the common functional module and the second dedicated test module corresponding to the second functional module.

[0138] In some embodiments, the common functional module includes a dynamic configuration module. The logic processing module can reload and configure the second dedicated test firmware file through the dynamic configuration module to build the second dedicated test module in the dynamic area.

[0139] In some embodiments, the dynamic configuration module includes a bit-width conversion module and a dynamic reconfiguration component. In response to a first instruction issued by the driver module, the logic processing module performs bit-width conversion on the data in the second dedicated test firmware file using the bit-width conversion module, and transmits the converted firmware file to the dynamic reconfiguration component; wherein the bit-width of the converted firmware file conforms to the input format supported by the dynamic reconfiguration component; subsequently, the dynamic reconfiguration component loads and configures the converted firmware file to construct the second dedicated test module.

[0140] In some embodiments, the bit-width conversion module is only enabled during the dedicated test firmware file transfer phase and is disabled after the transfer is complete. The enabling and disabling of the bit-width conversion module can be controlled by instructions from the driver module in the host computer, thereby achieving reasonable utilization and control of resources.

[0141] Specifically, the first instruction could be a reconfiguration state enabling instruction issued by the driver module.

[0142] The dynamic configuration module can respond to the reconfiguration state enable command and start the bit-width conversion module to perform bit-width conversion processing. The driver module can continuously monitor whether the second dedicated test firmware file has been completely transmitted to the bit-width conversion module. After the transmission is complete, it can issue a reconfiguration state end command, thereby instructing the dynamic configuration module to shut down the bit-width conversion module.

[0143] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0144] Based on the same inventive concept, this application also provides a testing system for implementing the aforementioned testing system for functional modules in a chip. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations of one or more embodiments of the testing system for functional modules in a chip provided below can be found in the limitations of the testing method for functional modules in a chip described above, and will not be repeated here.

[0145] In one embodiment, a test system (not shown in the figure) for functional modules in a chip is provided. The system includes a lower-level machine and a logic processing module, which can interactively execute the relevant steps in the method of the embodiments of this application.

[0146] Each module in the aforementioned test system for functional modules in a chip can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware within or independently of the processor in an electronic device, or stored in software within the memory of the electronic device, so that the processor can call and execute the operations corresponding to each module.

[0147] In one embodiment, an electronic device is provided, which may be a host computer or a logic processing module. The internal structure diagram of the electronic device can be as follows: Figure 9As shown, this electronic device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a testing method for functional modules within the chip.

[0148] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0149] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the embodiments of this application.

[0150] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the embodiments of this application.

[0151] It should be noted that the user information (including but not limited to user device information, user attribute content, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0152] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. The processors involved in the embodiments provided in this application can be general-purpose processors, central processing units, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited thereto.

[0153] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0154] The above embodiments are merely illustrative of several implementation methods of this application and should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A testing method for functional modules in a chip, characterized in that, The method includes: For the current test case to be executed, determine whether the firmware type of the first test firmware file loaded by the logic processing module in the resource board of the test machine matches the second functional module in the chip under test; wherein, the second functional module is the functional module to be tested in the current test case; the logic processing module runs a first test module built based on the first test firmware file; If the firmware type of the first test firmware file does not match the second functional module, a first instruction is issued to the logic processing module; wherein, the first instruction is used to instruct the first test firmware file to be switched to a second test firmware file, and the second test firmware file is used to construct a second test module in the logic processing module to test the second functional module, in order to replace the first test module; After the second test firmware file is switched, a second instruction is issued to the logic processing module; wherein, the second instruction is used to instruct the logic processing module to execute the current test case based on the second test module in order to test the second functional module of the chip under test.

2. The method according to claim 1, characterized in that, Before issuing the first instruction to the logic processing module, the method further includes: The system detects whether the first test module is in an idle state. If so, it executes the step of issuing a first instruction to the logic processing module. The first test module has the function of testing the first functional module in the chip under test.

3. The method according to claim 2, characterized in that, The first test module includes a graphics generator, a test result storage module, and a timing control module; the timing control module includes a waveform interrupt unit; the resource board also includes an autonomous operation unit; The step of detecting whether the first test module is in an idle state, and if so, executing the step of sending the first instruction to the logic processing module, includes: Check whether the graphics generator, the test result storage module, the waveform interrupt unit, and the autonomous operation unit are all in an idle state; If all are in an idle state, then the first instruction is sent to the logic processing module.

4. The method according to claim 1, characterized in that, When the firmware type of the first test firmware file does not match the second functional module, the step of issuing a first instruction to the logic processing module includes: If the firmware type of the first test firmware file does not match the second functional module, the output mode of the pin electronics is switched from the current first output mode to the second output mode, and the first instruction is sent to the logic processing module. In the first output mode, the logic processing module controls the test signal output to the chip under test. In the second output mode, the pin electronics autonomously control the test signal output to the chip under test. After the second test firmware file is switched, a second instruction is sent to the logic processing module, including: After the second test firmware file is switched and the second output mode is switched back to the first output mode, the second instruction is sent to the logic processing module.

5. The method according to claim 4, characterized in that, In the first output mode, the pin electronics output a test signal for the chip under test based on the output state value of the timing control module within the logic processing module; The step of switching the output mode of the pin electronics from the current first output mode to the second output mode includes: The target output state value is obtained by acquiring the last output state value of the timing control module in the first output mode from the logic processing module. The target output state value is written to the first register of the pin electronics as the output state value in the second output mode, and the first output mode is switched to the second output mode; wherein, in the second output mode, the pin electronics autonomously outputs a test signal for the chip under test based on the output state value in the first register.

6. The method according to claim 5, characterized in that, The pin electronics have multiple pin channels; The step of obtaining the target output state value by acquiring the last output state value of the timing control module in the first output mode from the logic processing module includes: From the logic processing module, obtain the last output state value of the timing control module for each pin channel in the pin electronic device in the first output mode, and obtain the target output state value corresponding to each pin channel respectively; The step of writing the target output state value to the first register of the pin electronics as the output state value in the second output mode includes: The target output status value corresponding to each target pin channel is written to the first register of the pin electronics as the output status value of the target pin channel in the second output mode; wherein, the target pin channel is the pin channel in the pin electronics that has not been configured with an output status value by the user.

7. The method according to claim 5, characterized in that, After the second test firmware file switching is completed, the method further includes: Write the current output status value in the second output mode to the static timing configuration register corresponding to the second test module; Write to the second register of the logic processing module to switch the second output mode back to the first output mode; after switching back to the first output mode, the timing control module outputs a test signal for the chip under test based on the output status value written in the static timing configuration register.

8. The method according to claim 1, characterized in that, Before determining whether the firmware type of the first test firmware file loaded by the logic processing module in the resource board of the test machine matches the second functional module in the chip under test for the current test case to be executed, the method further includes: The system sends a set of configuration information for test cases to the logic processing module, so that the logic processing module stores the set of configuration information for the test cases in memory; the second instruction is used to instruct the logic processing module to retrieve the target configuration information of the current test case to be executed from the memory, and to execute the current test case based on the second test module and the target configuration information.

9. The method according to claim 1, characterized in that, The determination of whether the firmware type of the first test firmware file loaded by the logic processing module in the resource board of the test machine matches the second functional module in the chip under test includes: The value of the firmware information register is read from the logic processing module; wherein, the value of the firmware information register is used to characterize the firmware type of the currently configured test firmware file; The firmware type of the first test firmware file is determined based on the value of the firmware information register to determine whether it matches the second functional module in the chip under test.

10. The method according to claim 1, characterized in that, The logic processing module preloads a common function firmware file and the first test firmware file after the test machine is powered on; after the common function firmware file is loaded, it is used to construct the common function module in the static area of ​​the logic processing module; the first test module is constructed in the dynamic area of ​​the logic processing module. During the switching process of the second test firmware file, the common function module in the logic processing module operates normally. After the switching of the second test firmware file is completed, the first test module built in the dynamic area is replaced by the second test module.

11. The method according to any one of claims 1 to 10, characterized in that, The testing machine includes multiple test heads, each test head includes multiple resource boards, and each resource board has the logic processing module; different test heads are used to test the same or different functional modules in the chip under test; the same test head is used to test the same functional module in the chip under test.

12. A testing system for functional modules in a chip, characterized in that, The system includes: a logic processing module in the resource board of the lower-level machine and the test machine; the lower-level machine includes a driver module; The driving module is used to determine, for the current test case to be executed, whether the firmware type of the first test firmware file loaded by the logic processing module matches the second functional module in the chip under test; wherein, the second functional module is the functional module to be tested in the current test case; the logic processing module runs a first test module built based on the first test firmware file; The driver module is also used to issue a first instruction to the logic processing module when the firmware type of the first test firmware file does not match the second functional module. The logic processing module is configured to switch the first test firmware file to a second test firmware file in response to the first instruction, and to construct a second test module for testing the second functional module based on the second test firmware file, in order to replace the constructed first test module. The driver module is also used to send a second instruction to the logic processing module after the second test firmware file is switched; The logic processing module is also used to respond to the second instruction and execute the current test case based on the second test module to test the second functional module of the chip under test.

13. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

Images