Test method, system and equipment for functional module in chip

Abstract

The invention relates to a test method, system and device for a functional module in a chip. The method comprises the steps that after electrification, a logic processing module in a testing machine loads a public function firmware file so as to construct a public function module in a static area of the logic processing module, and loads a first special testing firmware file in a default mode so as to construct a first special testing module in a dynamic area of the logic processing module; the first special test module has a test function for a first functional module in the chip to be tested; the logic processing module responds to a target instruction for indicating firmware switching and reloads and configures a second special test firmware file so as to construct a second special test module replacing the first special test module in the dynamic area; the second special test module has a test function for a second functional module in the to-be-tested chip; and the logic processing module tests the second function module based on the second special test module. 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, system and device 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) chips with microcontrollers are chips that simultaneously possess both SOC (System-on-a-Chip) and memory (storage) functions, and are widely used in the industry.

[0003] Different functions within a chip typically require different dedicated test modules. For example, testing the SOC (System-on-a-Chip) function requires a microinstruction module, while testing the MEMORY (Memory) function requires an ALPG (Algorithm Test Vector Generation) module. Each dedicated test module demands significant logic resources; however, test machines have limited logic resources, making it difficult to implement all dedicated test modules 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. For instance, a dedicated SOC test machine can only test the SOC function, and a dedicated MEMORY test machine can only test the MEMORY function. This necessitates using different test machines to test different functions within the chip, resulting in low 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] Firstly, this application provides a testing method for functional modules in a chip, including:

[0006] After power-on, the logic processing module in the test machine loads the common function firmware file to build the common function module in the static area of ​​the logic processing module, and loads the first dedicated test firmware file by default to build the first dedicated test module in the dynamic area of ​​the logic processing module; the first dedicated test module has the test function for the first function module in the chip under test.

[0007] In response to the target instruction indicating firmware switching, the logic processing module reloads and configures the second dedicated test firmware file to build a second dedicated test module in the dynamic area to replace the first dedicated test module; the second dedicated test module has test functions for the second functional module in the chip under test.

[0008] The logic processing module tests the second functional module based on the second dedicated test module.

[0009] In one embodiment, the common functional module includes a dynamic configuration module;

[0010] In response to a target instruction indicating a firmware switch, the logic processing module reloads the configuration file for the second dedicated test firmware to build a second dedicated test module in the dynamic area, replacing the first dedicated test module, including:

[0011] The logic processing module responds to the target instruction by reloading the configuration of the second dedicated test firmware file through the dynamic configuration module in order to build the second dedicated test module in the dynamic area.

[0012] In one embodiment, the dynamic configuration module includes a bit-width conversion module and a dynamic reconfiguration component;

[0013] The logic processing module responds to the target instruction by reloading the configuration of the second dedicated test firmware file through the dynamic configuration module to build the second dedicated test module in the dynamic area, including:

[0014] The logic processing module responds to the target instruction by performing bit-width conversion on the data in the second dedicated test firmware file through the bit-width conversion module, and then 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;

[0015] A second dedicated test module is built to replace the first dedicated test module by loading the configured and transformed firmware file through a dynamic reconfiguration component.

[0016] In one embodiment, the target instruction is a reconfiguration state enable instruction issued by the host computer;

[0017] The logic processing module responds to the target instruction by performing bit-width conversion on the data in the second dedicated test firmware file through the bit-width conversion module, including:

[0018] In response to the reconfiguration state enable command, start the bit width conversion module;

[0019] The bit width conversion module converts the data in the second dedicated test firmware file, and then transmits the converted firmware file to the dynamic reconfiguration component.

[0020] Obtain the reconfiguration status end command from the host computer and shut down the bit width conversion module.

[0021] In one embodiment, the dynamic configuration module further includes a receiving module;

[0022] The bit-width conversion module performs bit-width conversion on the data in the second dedicated test firmware file, including:

[0023] The receiving module obtains bitstream data from the second dedicated test firmware file sent by the host computer, and the bit width conversion module performs bit width conversion on the bitstream data.

[0024] Obtain the reconfiguration status end command issued by the host computer, including:

[0025] After the host computer sends out the complete second dedicated test firmware file, the reconfiguration status end command is obtained through the receiving module.

[0026] In one embodiment, the common function module further includes a communication module and a main control module; the communication module is used to transmit the bit stream data in the second dedicated test firmware file issued by the host computer to the main control module;

[0027] The bitstream data obtained by the receiving module from the second dedicated test firmware file sent by the host computer includes:

[0028] The receiving module obtains bitstream data from the second dedicated test firmware file transmitted by the main control module.

[0029] In one embodiment, the dynamic configuration module further includes a configuration startup module;

[0030] Before performing bit-width conversion on the data in the second dedicated test firmware file using the bit-width conversion module, the method also includes:

[0031] Obtain the target start address and target file length sent by the host computer; the target start address is the starting address of the second dedicated test firmware file in non-volatile memory, and the target file length is the length of the second dedicated test firmware file;

[0032] By configuring the boot module, the second dedicated test firmware file is obtained from the non-volatile memory based on the target start address and the target file length, and then the second dedicated test firmware file is transmitted to the bit width conversion module.

[0033] In one embodiment, the logic processing module tests the second functional module based on the second dedicated test module, including:

[0034] The logic processing module receives the linked list address of the current test case and loads the linked list data of the current test case from memory based on the linked list address;

[0035] The logic processing module executes the current test case to test the second functional module based on the second dedicated test module and the linked list data.

[0036] In one embodiment, the common functional module includes a message arbitration module;

[0037] The logic processing module, based on the second dedicated test module and linked list data, executes the current test cases to test the second functional module, including:

[0038] The linked list data is input into the second dedicated test module in the dynamic area through the message arbitration module;

[0039] The second functional module is tested by executing the current test case based on the linked list data using the second dedicated test module.

[0040] In one embodiment, the first functional module includes either an on-chip system functional module or a storage functional module; the second functional module is another functional module, different from the first functional module, that is included in the on-chip system functional module and the storage functional module.

[0041] Secondly, this application also provides a testing method for functional modules in a chip, including:

[0042] Determine whether the second functional module of the chip under test targeted by the current test case matches the current test firmware type corresponding to the logic processing module; wherein, the static area of ​​the logic processing module contains a common functional module corresponding to the common functional firmware file, and the dynamic area contains a first dedicated test module corresponding to the first dedicated test firmware file represented by the current test firmware type.

[0043] If not, a target instruction is sent to the logic processing module; the target instruction is used to instruct the logic processing module to reload the configuration of the second dedicated test firmware file to build a second dedicated test module in the dynamic area to replace the first dedicated test module.

[0044] After the second dedicated test firmware file is reconfigured, the logic processing module is instructed to execute the current test case based on the second dedicated test module to test the second functional module of the chip under test.

[0045] In one embodiment, the logic processing module includes a firmware information register; the value of the firmware information register is used to characterize the current test firmware type.

[0046] Determine whether the second functional module of the chip under test targeted by the current test case matches the current test firmware type corresponding to the logic processing module, including:

[0047] The value of the firmware information register is used to determine whether the second functional module matches the current test firmware type.

[0048] In one embodiment, the second dedicated test module includes a second indicator register;

[0049] The method also includes:

[0050] During the process of reloading the configuration of the second dedicated test firmware file, the value of the firmware information register and / or the value of the second indicator register are continuously read back;

[0051] If the value of the firmware information register changes or the value of the second indicator register is read back, it is determined that the reconfiguration of the second dedicated test firmware file is complete.

[0052] In one embodiment, after the second dedicated test firmware file is reconfigured, the logic processing module is instructed to execute the current test case based on the second dedicated test module, including:

[0053] After the second dedicated test firmware file is reconfigured, the linked list address of the current test case is sent to the logic processing module;

[0054] The linked list address is used to instruct the logic processing module to load the linked list data of the current test case from memory, and to execute the current test case based on the second dedicated test module and the linked list data to test the second functional module.

[0055] In one embodiment, before determining whether the current test firmware type corresponding to the second functional module of the chip under test targeted by the current test case matches the current test firmware type corresponding to the logic processing module, the method further includes:

[0056] Obtain configuration information for at least one test case;

[0057] Compile the configuration information for each test case to obtain the linked list data for each test case;

[0058] Load the linked list data of each test case into memory for storage.

[0059] Thirdly, this application also provides a testing system for functional modules in a chip, the testing system including a host computer and a logic processing module;

[0060] The logic processing module is used to load a common function firmware file after power-on to build a common function module in the static area of ​​the logic processing module, and to load a first dedicated test firmware file by default to build a first dedicated test module in the dynamic area of ​​the logic processing module; the first dedicated test module has the testing function for the first function module in the chip under test.

[0061] The host computer is used to send target instructions to the logic processing module to switch firmware;

[0062] The logic processing module is also used to reload the configuration of the second dedicated test firmware file in response to the target instruction, so as to build a second dedicated test module in the dynamic area to replace the first dedicated test module; the second dedicated test module has the test function for the second functional module in the chip under test;

[0063] The logic processing module is also used to test the second functional module based on the second dedicated test module.

[0064] Fourthly, 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 in the methods mentioned in the first or second aspect above.

[0065] Fifthly, 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 methods mentioned in the first or second aspect above.

[0066] Sixthly, 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 methods mentioned in the first or second aspect above.

[0067] The aforementioned testing methods, systems, electronic devices, computer-readable storage media, and computer program products for functional modules in chips split the test-related firmware in the logic processing module into common functional firmware files and dedicated test firmware files. Different functional modules in the chip under test (DUT) have their own dedicated test firmware files. Upon power-up, the logic processing module in the test machine loads the common functional firmware file by default to construct the common functional module in the static area of ​​the logic processing module. It also loads the first dedicated test firmware file by default to construct a first dedicated test module specifically for testing the first functional module in the DUT in the dynamic area of ​​the logic processing module. When testing the second functional module of the DUT is required, a target instruction to switch firmware can be received. In this case, the common functional module of the logic processing module can continue to run, keeping the logic processing module in a non-restarting state, while reloading the second dedicated test module configured for testing the second functional module in the DUT. Then, based on the second dedicated test module, the second functional module is tested. Thus, without replacing the test machine, dynamic testing of multiple test functions in the chip can be achieved using a single test machine, greatly improving testing efficiency. Furthermore, only one test machine is needed to test multiple functional modules in the chip, eliminating the need for multiple test machines and significantly reducing hardware costs. Moreover, switching between different functional modules for testing does not require restarting the logic processing module, improving switching efficiency and avoiding other problems caused by restarts. Attached Figure Description

[0068] Figure 1 This is a block diagram of a test system for functional modules in a chip, as shown in one embodiment.

[0069] Figure 2 This is a structural block diagram of a business board subclass in one embodiment;

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

[0071] Figure 4 This is a schematic diagram and a simplified flowchart illustrating a testing method for functional modules in a chip, as shown in one embodiment.

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

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

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

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

[0076] Figure 9 This is a block diagram of the internal structure of a logic processing module in one embodiment;

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

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

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

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

[0081] Main control module: Completes downlink parsing and unpacking of communication data, distributes different data to different functional modules; completes uplink arbitration for data readback from each functional module; and completes process status monitoring for each functional module.

[0082] Alarm module: Detects health information of the board and logic processing module (such as FPGA), such as chip operating voltage and temperature.

[0083] Peripheral interface module: responsible for controlling other peripheral chips within the board, reading and sending communication commands.

[0084] Loading module: Used to transfer and load timing configuration information from internal storage chips (such as DDR) to the business logic processing module for execution. In the following embodiments, the MEMORY-specific test module or SOC-specific test module mentioned in this application refers to the business logic processing module.

[0085] The memory control module is responsible for interacting with the internal memory chip (DDR) on the board, including writing data, reading pattern data, and initializing data. In the following text, the linked list data mentioned in the embodiments of this application refers to the pattern data; the written data includes linked list data and initialization data. The initialization data is the configuration data for the logic processing module, including timing configuration information, PE chip configuration information, etc.

[0086] Algorithm Test Vector Generation Module: This is a dedicated MEMORY test module (i.e., a dedicated function block for MEMORY testing services) used to generate pattern data required during storage function testing.

[0087] Timing control module: This is a dedicated MEMORY test module used to convert the required MEMORY type pattern data into corresponding waveform data, and to collect the response signal of the corresponding pin of the device under test and compare it with the expected value to obtain the test comparison result.

[0088] Test result storage module: This is a dedicated test module for MEMORY devices, used for processing and storing test result information of MEMORY type devices.

[0089] Protocol parsing module: This is a dedicated test module for the SOC, used to parse and forward data sent by the main control module to the various sub-modules within the dedicated test module.

[0090] Microinstruction module: This is a dedicated test module for SOC, used to generate pattern data required during SOC functional testing.

[0091] Input / output control module: This is a dedicated test module for SOCs. It is used to convert the required SOC type pattern data into corresponding waveform data and to collect the response signals of the corresponding pins of the device under test and compare them with the expected values ​​to obtain test comparison results.

[0092] Cache control module: This is a dedicated test module for SOC, used for processing and storing test results of SOC type devices.

[0093] Dynamic configuration modules (such as FPGA configuration modules): are used to complete online upgrade functions and dynamic reconfiguration functions of logic processing modules;

[0094] Online upgrade module: Used to update test firmware files stored in non-volatile memory.

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

[0096] Configuration startup module: This is a component in the logic processing module used to communicate with non-volatile memory.

[0097] 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 is off-chip FLASH. The off-chip FLASH can also store all test firmware files, and this is not limited.

[0098] Figure 1 This is a structural block diagram of a test system (hereinafter referred to as the test system) for functional modules in a chip, as described in one embodiment. Figure 1 As shown, the test system consists of a host computer, slave computers (taking 4 slave computers as an example, but not limited to 4), communication boards, and resource boards. The resource boards are used to receive test commands issued by the host computer and execute test functions. Different types of resource boards receive different test commands and execute different test functions. Resource boards can be power supply boards, digital boards, high-speed test boards, etc.

[0099] like Figure 1 As shown, in this embodiment, the resource board includes a service board and service sub-boards (i.e., service sub-boards) that are connected for communication. The resource board is a digital board, and one service board can be connected to 16 service sub-boards. The service sub-boards are service sub-boards 1 to 16.

[0100] The host computer interfaces with the user to complete operations such as selecting the specified test service (i.e., the functional module to be tested), configuring and compiling test cases. For example, the user can select the specified test service (such as specifying the SOC / MEMORY functional module in the chip to be tested), configure test cases for testing the SOC / MEMORY functional module in the chip, and configure test firmware files based on the host computer.

[0101] The lower-level machine, communication board, and service board interact with each other to complete different test services such as resource board test synchronization, communication data forwarding, test machine health monitoring, and power management.

[0102] Service board subclasses 1 to 16 receive test commands from the service board and generate test waveforms for testing the chip under test (DUT) to test the functional modules within the DUT. Each service board subclass is equipped with the logic processing module described in this embodiment. This logic processing module is reprogrammable, allowing for multiple implementation structures for the service board subclasses. This integrated design combines test functions for different functional modules within the DUT, enabling switching tests on different functional modules on the same hardware device. This reduces hardware costs and significantly improves testing efficiency in multi-application scenarios. Furthermore, in the ever-evolving semiconductor technology, the solution described in this embodiment can meet a wider range of testing needs.

[0103] Taking the example of a test machine being able to test the memory and SOC functions of the chip under test through firmware switching, such as... Figure 2As shown, the business board subclass has two implementation structures. Business board subclass structure 1 includes a dedicated MEMORY test module (a dedicated test module for testing the MEMORY function in the chip under test), an alarm module, and a main control module. The dedicated MEMORY test module includes an algorithm test vector generation module, a timing control module, and a test result storage module. Business board subclass structure 2 includes a dedicated SOC test module (a dedicated test module for testing the SOC function in the chip under test), an alarm module, and a main control module. The dedicated SOC test module includes a microinstruction module, an input / output control module, and a cache control module. Clearly, these two business board subclass structures have different modules (i.e., the dedicated SOC test module and the dedicated MEMORY test module), and they belong to different implementation structures. Figure 2 The examples provided are only partial illustrations and do not represent all modules in the MEMORY-specific test module / SOC-specific test module.

[0104] Business board class 1 to business board class 16 can switch their internal implementations instantly based on the specified test function modules selected by the host computer and the reprogrammable feature of the logic processing modules. This is equivalent to switching between the two implementation structures mentioned above in a timely manner. After switching, the original interface can be adapted to continue testing the business.

[0105] like Figure 3 As shown, in some embodiments, a testing method for functional modules in a chip is provided, specifically including the following steps:

[0106] 3-1. After power-on, the logic processing module loads the default test firmware file.

[0107] The default test firmware file is a bitstream file that implements the default test functions, that is, it is used to implement the test functions to test the default functional modules in the chip under test.

[0108] 3-2, The host computer obtains the test cases that need to be executed in this round of testing as configured by the user.

[0109] 3-3, The host computer compiles the test cases to be executed, obtains the linked list data of each test case, and loads it into memory.

[0110] 3-4. The host computer determines whether the type of the current test case (i.e., the test case to be executed) matches the type of the current test firmware in the logic processing module. If they match, proceed to step 3-7; if they do not match, proceed to steps 3-5 and 3-6, and then proceed to step 3-7.

[0111] 3-5, The host computer sends firmware switching instructions to the logic processing module.

[0112] 3-6, The logic processing module loads the target test firmware file indicating the switch from the non-volatile memory.

[0113] For easier understanding, please refer to Figure 4 .like Figure 4 As shown, in this embodiment, test firmware files with different implementation structures are pre-stored in the non-volatile memory. For example, test firmware files for testing different functional modules such as SOC function, MEMORY function, and calibration function in the chip are stored.

[0114] It should be noted that, in Figure 3 and Figure 4 In the illustrated embodiment, the test firmware files corresponding to each functional module in the chip are all complete test firmware files. These complete test firmware files are used to create a complete set of modules for fully testing the corresponding functional modules of the chip. Figure 2 For example, if the logic processing module loads the complete test firmware file corresponding to the SOC functional module, it can achieve... Figure 2 The test of the SOC functional module shown in (b) includes all modules required, such as the alarm module, main control module, peripheral interface module, and SOC-specific test module. If the logic processing module loads the complete test firmware file corresponding to the MEMORY functional module, the test can be completed. Figure 2 The MEMORY functional module test shown in (a) includes all the modules required, such as the alarm module, main control module, peripheral interface module, MEMORY-specific test module, etc.

[0115] Please continue reading. Figure 4 Users can specify a scenario to switch to from multiple test scenarios (equivalent to a switch in the functional module to be tested). The host computer then issues a firmware switch command to restart the logic processing module. Upon receiving the firmware switch command, the logic processing module restarts and resets, then selects and loads the target test firmware file from multiple pre-stored test firmware files in non-volatile memory. In other words, after the logic processing module restarts, it loads the target test firmware file, then loads the linked list data of the current test case, and begins testing the functional module.

[0116] 3-7. The host computer sends the linked list address of the current test case to the logic processing module.

[0117] 3-8. The logic processing module loads the linked list data of the current test case from memory based on the linked list address.

[0118] 3-9, Host computer startup test.

[0119] 3-10. The logic processing module, based on the test functional modules constructed from the target test firmware file, executes the current test case in conjunction with the linked list data of the current test case to test the corresponding functional modules in the chip under test.

[0120] It should be understood that after loading the target test firmware file, the corresponding test functional modules (i.e. test modules) can be built. These test functional modules provide hardware support for executing test cases. Based on this, combined with the linked list data of the current test case, the corresponding waveform data can be generated to test the corresponding functional modules in the chip under test.

[0121] 3-11. The host computer determines whether all test cases (i.e., all test cases to be executed in this round of testing) have been completed. If not, the next test case to be executed is taken as the current test case, and the process returns to step 3-4 to continue processing. If yes, the current round of testing ends.

[0122] In the above scheme, the required test firmware file is dynamically loaded from non-volatile memory to achieve dynamic switching of test firmware. This allows a single test machine to test different functional modules in the chip under test. Compared with a single test machine that can only test a single function in the chip, this reduces costs and improves test efficiency to some extent.

[0123] However, the above solution requires storing test firmware files for different implementation structures in non-volatile memory, which places certain demands on memory size and capacity, resulting in significant storage resource consumption. Furthermore, the switching process requires a complete restart of the logic processing module, leading to relatively low switching efficiency. Additionally, because the logic processing module needs to completely restart during firmware switching, it cannot monitor the board. If the board malfunctions during the firmware switching loading process, the logic processing module will be unable to obtain and report the error.

[0124] like Figure 5 As shown, in some embodiments, a testing method for functional modules in a chip is provided, specifically including the following steps:

[0125] 5-1. After power-on, the host computer sends a default test firmware file to the logic processing module, which then loads the default test firmware file to build the corresponding test function module.

[0126] 5-2, The host computer obtains the test cases to be executed in this round of testing as configured by the user.

[0127] 5-3. The host computer compiles the test cases to be executed, obtains the linked list data of each test case, and loads it into memory.

[0128] 5-4. The host computer determines whether the type of the current test case matches the type of the current test firmware in the logic processing module. If yes, proceed to step 5-6; otherwise, proceed to step 5-5 and then to step 5-6.

[0129] 5-5, The host computer sends the target test firmware file that matches the current test case to the logic processing module, so that the logic processing module loads the test firmware file to build the corresponding test function module.

[0130] Similarly, in this embodiment, the test firmware files corresponding to each functional module in the chip are all complete test firmware files (for a detailed description of "complete test firmware files," please refer to the descriptions in sections 3-6 above). Therefore, after receiving the firmware switching command from the host computer, the logic processing module will also restart and reset, and then reload the target test firmware file sent by the host computer.

[0131] 5-6, The host computer sends the linked list address of the current test case to the logic processing module.

[0132] 5-7, The logic processing module loads the linked list data of the current test case from memory based on the linked list address.

[0133] 5-8, Host computer startup test.

[0134] 5-9. The logic processing module, based on the reconstructed test function module and the linked list data of the current test case, executes the current test case to test the corresponding function module in the chip under test.

[0135] 5-10. The host computer determines whether all test cases have been executed. If not, the next test case to be executed is taken as the current test case, and the process returns to step 5-4 to continue. If yes, the current round of testing ends.

[0136] The above solution achieves dynamic firmware switching by dynamically sending the complete test firmware file to be switched from the host computer, thus enabling testing of different functional modules in the chip under test using a single test machine. It also saves space occupied by the test firmware file in non-volatile memory, relieving storage pressure. However, the firmware switching process still requires a complete restart of the logic processing module, resulting in relatively low switching efficiency. Furthermore, it also suffers from the problem of not being able to promptly obtain and report abnormal information during the restart.

[0137] like Figure 6 As shown, in some embodiments, a testing method for functional modules in a chip is provided. This method is applied to a logic processing module (e.g., an FPGA) in a test machine, and includes:

[0138] S61, after power-on, the logic processing module in the test machine loads the common function firmware file to build the common function module in the static area of ​​the logic processing module, and loads the first dedicated test firmware file by default to build the first dedicated test module in the dynamic area of ​​the logic processing module; the first dedicated test module has the test function for the first function module in the chip under test.

[0139] The logic processing module in the test machine refers to the logic processing module on the resource board of the test machine. The logic processing module includes a static area and a dynamic area. The functions in the static area are fixed and unchanging. As long as the logic processing module is powered on, this part of the logic in the static area will continue to run to maintain the original function. The functions in the dynamic area can be changed dynamically. For example, by reloading a new bitstream file (i.e., firmware file), the functions in the dynamic area can be changed.

[0140] In this embodiment of the application, the complete test firmware file (i.e., test-related firmware) for implementing functional testing of the logic processing module is split into a common functional firmware file and a dedicated test firmware file.

[0141] Common function firmware files are used to implement basic general functions or common functions of logic processing modules. These general functions are not limited to the testing of a certain functional module in the chip, but are applicable to the testing of all functional modules in the chip.

[0142] For each functional module in the chip under test (DUT), a dedicated test firmware file can be set. This dedicated test firmware file is specifically designed for testing the corresponding functional module within the DUT. For example, dedicated test firmware file 1 for functional module A in the DUT can only perform the testing functions for functional module A, but cannot perform the testing functions for functional module B.

[0143] Specifically, after power-on, the logic processing module loads a common function firmware file to build the common function module in its static area. For example, the common function module may include a communication module, a main control module, etc. Obviously, regardless of which functional module of the chip is being tested, the communication module or main control module built in the static area of ​​the logic processing module is applicable. In addition, the logic processing module also loads a first dedicated test firmware file by default to build a first dedicated test module in its dynamic area; the first dedicated test module has testing functions for the first functional module in the chip under test.

[0144] It should be understood that common functional modules are essential for implementing testing. A dedicated test module cannot test a corresponding functional module independently; instead, it needs to be combined with common functional modules and work together to achieve complete testing of the corresponding functional module. For example, with the support of common functional modules, the logic processing module can use the first dedicated test module to perform complete testing of the first functional module in the chip under test.

[0145] S62, in response to the target instruction indicating firmware switching, the logic processing module reloads the configuration of the second dedicated test firmware file to build a second dedicated test module in the dynamic area to replace the first dedicated test module; the second dedicated test module has test functions for the second functional module in the chip under test.

[0146] It should be understood that if the target device is not the first functional module of the chip under test, but another functional module of the chip under test—the second functional module—the host computer can send a target instruction to the logic processing module to instruct it to switch firmware.

[0147] In some embodiments, the host computer can determine whether the second functional module in the chip under test targeted by the current test case (i.e. the test case to be executed) matches the current test firmware type (i.e. the type of the first dedicated test firmware file currently loaded) corresponding to the logic processing module. If they do not match, the host computer sends a target instruction to the logic processing module to instruct it to switch firmware.

[0148] Upon receiving the target instruction, the logic processing module can reconfigure only the second dedicated test firmware file corresponding to the second functional module in the chip under test, thereby constructing a second dedicated test module in the dynamic area to replace the first dedicated test module. It should be understood that during the reconfiguration process, the common functional modules implemented in the static area of ​​the logic processing module can continue to operate normally, maintaining the basic general functions of the logic processing module. For example, the communication module works normally, eliminating the need to rebuild the communication link between the logic processing module and other modules; the alarm module works normally, continuously monitoring the health status of the resource board; and the peripheral interface module works normally, allowing the logic processing module to configure the corresponding peripherals according to the test case requirements during reconfiguration, reducing pre-test preparation time. Thus, without restarting the logic processing module, only the second dedicated test firmware file is reconfigured to construct the second dedicated test module—that is, only some functions are reloaded and recreated. This approach is time-efficient and has significant advantages in scenarios involving multiple test cases and no power-off testing.

[0149] In some embodiments, the common functional module includes a dynamic configuration module. In response to a target instruction, the logic processing module reloads and configures the second dedicated test firmware file via the dynamic configuration module to construct the second dedicated test module in the dynamic area.

[0150] In some embodiments, the dynamic configuration module includes a bit-width conversion module and a dynamic reconfiguration component. In response to a target instruction, 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.

[0151] 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 a host computer.

[0152] Specifically, the target instruction is a reconfiguration state enable instruction issued by the host computer. For example, the dynamic configuration module may include a receiving module to obtain the reconfiguration state enable instruction from the host computer. Then, in response to the reconfiguration state enable instruction, the dynamic configuration module can initiate the bit-width conversion module to perform bit-width conversion processing. After obtaining a reconfiguration state end instruction from the host computer (e.g., obtaining the reconfiguration state end instruction through the aforementioned receiving module), the bit-width conversion module is controlled to close.

[0153] S63, the logic processing module tests the second functional module based on the second dedicated test module.

[0154] In some embodiments, after the second dedicated test firmware file is reconfigured (i.e., the second dedicated test module is built in the dynamic area), the logic processing module can obtain the linked list data of the current test case. This linked list data contains the specific execution information of the current test case (including sending time, length, test vector value, expected value, etc.). Then, the logic processing module can execute the current test case based on the second dedicated test module and the linked list data to test the second functional module.

[0155] In some examples, the linked list data of the current test case is pre-stored in memory. The logic processing module can receive the linked list address of the current test case from the host computer and retrieve the linked list data of the current test case from memory based on the linked list address.

[0156] In some examples, the common functional module also includes a message arbitration module. After obtaining the linked list data of the current test case, the logic processing module can input the linked list data into the second dedicated test module reconstructed in the dynamic area through the message arbitration module. The second dedicated test module then executes the current test case based on the linked list data to test the second functional module.

[0157] In some embodiments, the first functional module may be a system-on-chip (SoC) functional module, and the second functional module may be a memory functional module. Alternatively, the first functional module may be a memory functional module, and the second functional module may be a SoC functional module.

[0158] In the above method, by splitting the test-related firmware in the logic processing module into common functional firmware files and dedicated test firmware files (different functional modules in the chip under test each have their own dedicated test firmware files), and combining this with the technique of reconfiguring the required dedicated test firmware files, dynamic testing of multiple test functions in the chip can be achieved with a single test machine without replacing the test machine, greatly improving testing efficiency. Furthermore, only one test machine is needed to test multiple functional modules in the chip, eliminating the need for multiple test machines and significantly saving hardware costs. Moreover, switching between different functional modules does not require restarting the logic processing module; that is, using dynamic reconfigurable technology, the switching of dedicated test modules is completed during the normal operation of the logic processing module's static area, improving switching efficiency (data stored in memory is not lost during firmware switching) and avoiding other problems caused by restarts, thus improving board reliability to some extent.

[0159] In some embodiments, the second dedicated test firmware file to be reconfigured is sent from the host computer to the logic processing module. That is, the dynamic configuration module (e.g., through the receiving module in the dynamic configuration module) obtains the bitstream data in the second dedicated test firmware file sent from the host computer, performs bit-width conversion on the bitstream data through the bit-width conversion module, and transmits the converted firmware file to the dynamic reconfiguration component.

[0160] In some examples, the common functional module may also include a communication module and a main control module. The communication module is used to transmit the bitstream data in the second dedicated test firmware file issued by the host computer to the main control module. The receiving module obtains the bitstream data in the second dedicated test firmware file transmitted by the main control module.

[0161] In some examples, after the host computer sends the complete second dedicated test firmware file, the host computer can send a reconfiguration state end command to the logic processing module. After receiving the reconfiguration state end command from the host computer, the bit width conversion module is shut down.

[0162] In some embodiments, the second dedicated test firmware file to be reconfigured is obtained from non-volatile memory by the logic processing module. Exemplarily, the dynamic configuration module further includes a configuration initiation module. The logic processing module can obtain the second dedicated test firmware file from non-volatile memory through this configuration initiation module.

[0163] Specifically, the host computer can send the target start address and target file length to the logic processing module; the target start address is the starting address of the second dedicated test firmware file in the non-volatile memory, and the target file length is the length of the second dedicated test firmware file. The logic processing module (or the configuration startup module in the logic processing module) can retrieve the second dedicated test firmware file from the non-volatile memory based on the target start address and the target file length, and transmit the second dedicated test firmware file to the bit-width conversion module for bit-width conversion and subsequent reconfiguration processing.

[0164] like Figure 7 As shown, in one embodiment, a testing method for functional modules in a chip is provided. This method is applied in a host computer and specifically includes the following steps:

[0165] S71, determine whether the second functional module of the chip under test targeted by the current test case matches the current test firmware type corresponding to the logic processing module; wherein, the static area of ​​the logic processing module contains a common functional module corresponding to the common functional firmware file, and the dynamic area contains a first dedicated test module corresponding to the first dedicated test firmware file represented by the current test firmware type.

[0166] In some embodiments, the logic processing module includes a firmware information register (e.g., the firmware information register is included in the dynamic configuration module of the logic processing module). The value of the firmware information register is used to characterize the current test firmware type. For example, a value of 0 in the firmware information register indicates that a MEMORY-specific test firmware file is currently loaded (i.e., a dedicated test firmware file for testing the MEMORY functional module in the chip), and a value of 1 in the firmware information register indicates that a SOC-specific test firmware file is currently loaded (i.e., a dedicated test firmware file for testing the SOC functional module in the chip). The host computer can read back the value of the firmware information register in the logic processing module to determine whether the second functional module targeted by the current test case matches the current test firmware type.

[0167] S72, if not, then issue a target instruction to the logic processing module; the target instruction is used to instruct the logic processing module to reload the configuration of the second dedicated test firmware file to build a second dedicated test module in the dynamic area to replace the first dedicated test module.

[0168] After the host computer sends the target instruction to the logic processing module, the logic processing module can perform corresponding processing to reconfigure the second dedicated test firmware file corresponding to the second functional module targeted by the current test case in the dynamic area, thereby constructing the second dedicated test module for the second functional module. See the description above for detailed processing.

[0169] S73, after the second dedicated test firmware file is reconfigured, instructs the logic processing module to execute the current test case based on the second dedicated test module to test the second functional module of the chip under test.

[0170] Specifically, after the second dedicated test firmware file is reconfigured, the host computer can send the linked list address of the current test case to the logic processing module. The linked list address is used to instruct the logic processing module to load the linked list data of the current test case from memory and execute the current test case based on the second dedicated test module and the linked list data to test the second functional module.

[0171] For example, the linked list data of each test case to be executed in this round of testing can be pre-stored in memory, so that the corresponding linked list data can be retrieved from memory for each current test case. Specifically, the host computer can obtain the configuration information of at least one test case (i.e., the test cases to be executed in this round of testing), compile the configuration information of each test case to obtain the linked list data of each test case; and load the linked list data of each test case into memory for pre-storage, so as to be used when the test cases are formally executed later.

[0172] In some embodiments, the second dedicated test module includes a second indicator register. During the process of the logic processing module reloading and configuring the second dedicated test firmware file, the host computer can continuously read back the values ​​of the firmware information register and / or the second indicator register in the logic processing module. If the value of the firmware information register changes or the value of the second indicator register is read back, it is determined that the reconfiguration of the second dedicated test firmware file is complete.

[0173] It should be understood that if the reconfiguration of the second dedicated test firmware file is complete, the second dedicated test module will be created, and thus the value of the second indicator register can be read. If the reconfiguration is not complete, the value of the second indicator register cannot be read. Furthermore, since the value of the firmware information register in the logic processing module (such as the dynamic configuration module of the logic processing module) represents the current firmware file type, if the reconfiguration of the second dedicated test firmware file is complete, it indicates that the current firmware file type has changed, and the value of this firmware information register will also change.

[0174] like Figure 8As shown, in one embodiment, a testing method for functional modules in a chip is provided. This method is illustrated using an example where the logic processing module is an FPGA, the first default-loaded dedicated test firmware file is a SOC-specific test firmware file, and the second dedicated test firmware file is a MEMORY-specific test firmware file. It should be understood that the default-loaded firmware file can also be a MEMORY-specific test firmware file; this is not a limitation and is merely an example. The method includes the following steps:

[0175] After power-on, the S81 FPGA loads the common function firmware file and the SOC-specific test firmware file.

[0176] exist Figure 8 In the illustrated embodiment, instead of setting a complete test firmware file for each functional module under test in the chip, a complete test firmware file is split into two files—a common functional firmware file and a dedicated test firmware file corresponding to that functional module. If the default test is of the SOC functional module, then step S81 is executed.

[0177] S82, the host computer obtains the test cases to be executed in this round of testing as configured by the user.

[0178] S83, the host computer compiles the various test cases to be executed, obtains the linked list data of each test case, and loads it into memory.

[0179] S84, the host computer reads back the value of the firmware information register on the dynamic configuration module in the FPGA.

[0180] In step S85, the host computer determines whether the type of the current test case matches the type of the current test firmware based on the value of the firmware information register read back. If they match, step S810 is executed; if they do not match, steps S86 to S89 are executed before step S810 is executed.

[0181] Specifically, a value of 0 in the firmware information register indicates that the FPGA is currently loading a MEMORY-specific test firmware file, while a value of 1 indicates that the FPGA is currently loading a SOC-specific test firmware file.

[0182] The S86 host computer sends a reconfiguration status enable command to instruct the test firmware switching process.

[0183] The S87 host computer sends the MEMORY-specific test firmware file to the FPGA in binary form to instruct the FPGA to reload and configure the MEMORY-specific test firmware file.

[0184] After all the S88 and MEMORY-specific test firmware files have been distributed, the host computer sends a command to end the reconfiguration status.

[0185] In other embodiments, step S87 can be replaced by: the host computer sending the starting address and file length of the MEMORY-specific test firmware file in non-volatile memory (such as FLASH); the FPGA reading the MEMORY-specific test firmware file from the non-volatile memory based on the starting address and file length; and transmitting the MEMORY-specific test firmware file to the dynamic reconfiguration component (such as the ICAPE3 component) for reconfiguration. Then, step S88 can be replaced by: after the MEMORY-specific test firmware file transmission is complete, the host computer sending a reconfiguration status end command.

[0186] S89, the host computer continuously reads the value of the firmware information register until the read is correct.

[0187] It should be understood that the firmware configuration information register value of the FPGA will change accordingly after dynamic reconfiguration. Therefore, the host computer can continuously read back the value of the firmware information register in the FPGA to determine whether the reconfiguration is complete.

[0188] A successful readback means that the value of the firmware information register has changed from 1 to 0, indicating that the MEMORY-specific test firmware file has been successfully switched and loaded, meaning that the reconfiguration is complete.

[0189] For example, in addition to reading back the value of the firmware information register, the host computer can also read back the value of the indicator register in the MEMORY-specific test module corresponding to the MEMORY-specific test firmware file. If the value of the indicator register in the MEMORY-specific test module is read back, it is determined that the reconfiguration is complete and the firmware switch is successful.

[0190] S810: The host computer sends the linked list address of the current test case to the FPGA.

[0191] S811, the FPGA retrieves the linked list data of the current test case from memory based on the linked list address.

[0192] The S812 FPGA sends the linked list data of the current test case to the MEMORY dedicated test module in the dynamic area through the service arbitration module.

[0193] S813, host computer startup test.

[0194] The S814 FPGA uses the MEMORY dedicated test module to generate corresponding test vector waveforms based on the linked list data of the current test case, in order to execute the current test case to test the MEMORY functional module in the chip under test.

[0195] In step S815, the host computer determines whether all test cases have been executed. If not, the next test case to be executed is taken as the current test case, and the execution returns to step S84. If yes, the current round of testing ends.

[0196] In some embodiments, taking an FPGA as an example where the logic processing module is a chip and the functional module to be tested in the chip includes a SOC or MEMORY functional module, combined with... Figure 9 The internal structure diagram of the FPGA shown illustrates the testing methods for the functional modules in the chip.

[0197] Please see Figure 9 Data is transmitted from the host computer to the slave computer via Ethernet, and then to the communication board via the PCIe bus. The communication board sends the data to the communication module in the service board (used to complete the communication data interaction with the communication board) through the protocol. The service board then transmits the data to the service board subclass (i.e., the service sub-board).

[0198] The FPGA on the business board includes dynamic and static areas. Figure 9 The two areas are illustrated by dashed lines. The dynamic area contains a dedicated MEMORY test module and a dedicated SOC test module (it should be understood that these two types of dedicated test modules are selective and will not be implemented simultaneously on the same type of FPGA board). Figure 9 In order to illustrate that FPGAs have different implementation structures, both types of modules are shown simultaneously. Figure 9 In the FPGA, other modules are located in the static area.

[0199] After the data sent from the service board enters the service board subclass, it first passes through the communication module in the FPGA. The communication module performs protocol parsing (converting it into a custom protocol for the test machine) and then sends the data to the main control module. The main control module performs protocol parsing and forwards instructions / data to various sub-modules based on the parsed content, such as the peripheral interface module, alarm module, memory control module, service message arbitration module, and dynamic configuration module.

[0200] When a dynamic reconfiguration operation is to be performed, the host computer first sends a reconfiguration status enable command, which is ultimately transmitted to the dynamic configuration module of the FPGA via the aforementioned communication link. Upon recognizing this command, the dynamic configuration module activates the bit-width conversion module to open the communication bit-width conversion and reconstruction path. The subsequently acquired dedicated test firmware file for reconfiguration (MEMORY-specific test firmware file or SOC-specific test firmware file) undergoes bit-width conversion (e.g., 64-bit to 32-bit) through the bit-width conversion module to adjust it to an input format supported by the dynamic reconfiguration component. The adjusted data (e.g., 32-bit data) is then input to the dynamic reconfiguration component. Simultaneously with receiving the data from the dedicated test firmware file, the dynamic reconfiguration component reconfigures the dynamic area of ​​the FPGA to rebuild a dedicated test module adapted to the current test case based on the reconfigured dedicated test firmware file. For example, if the default loaded test module is the SOC-specific test module, but the current test case wants to test the MEMORY function in the chip under test, then dynamic reconfiguration is performed according to the above process to rebuild the MEMORY-specific test module.

[0201] It should be noted that the aforementioned reconfigured dedicated test firmware file can be directly sent from the host computer to the dynamic configuration module via a communication link (i.e., sent to the receiving module, which then transmits it to the bit-width conversion module), or it can be obtained by the dynamic configuration module from the external FLASH. Specifically, the external FLASH pre-stores dedicated test firmware files corresponding to each functional module in the chip under test. The host computer sends the starting address and file length of the reconfigured dedicated test firmware file to the receiving module in the dynamic configuration module via a communication link. The receiving module forwards it to the configuration startup module. The configuration startup module reads the reconfigured dedicated test firmware file from the external FLASH based on the starting address and file length, and transmits the reconfigured dedicated test firmware file to the bit-width conversion module for bit-width conversion processing. For example, the various dedicated test firmware files stored in the external FLASH can be updated through the online upgrade module. For example, the host computer can send the firmware address to be updated and the new dedicated test firmware file to the online upgrade module. The online upgrade module then updates the old dedicated test firmware file located at the firmware address to be updated in the external FLASH to the new dedicated test firmware file by configuring the startup module.

[0202] It should be understood that, based on the dedicated test firmware file (i.e., the BIT file) for reconfiguration, combined with dynamic reconfiguration, the FPGA functionality can be changed from the ground up without restarting the FPGA, enabling the FPGA to dynamically switch between different functional modules of the chip for testing. The time required for dynamic reconfiguration is related to the size of the BIT file used. After transmitting the BIT file, the host computer also needs to send a reconfiguration status end command to shut down the bit-width conversion module.

[0203] Before dynamic reconfiguration, the host computer can send the linked list data of each test case to be executed in this round of testing to the memory control module in the static area of ​​the FPGA through the communication link. The memory control module stores the linked list data of each test case in memory (such as DDR).

[0204] After reconfiguration, the host computer can send the linked list address of the current test case to the memory control module via the communication link. The memory control module then retrieves the linked list data of the current test case from memory based on the linked list address and transmits the linked list data directly or indirectly to the business message arbitration module. The business message arbitration module determines whether the data should ultimately be sent to the target dedicated test module in the dynamic area, namely the MEMORY dedicated test module (also known as the MEM dedicated function block) or the SOC dedicated test module (also known as the SOC dedicated function block). Subsequently, the target dedicated test module in the dynamic area executes the current test case based on the linked list data to test the corresponding functional modules in the chip under test.

[0205] It should be understood that the port configuration of the dynamic area must be consistent. For example, the SOC dedicated test module also retains the port of the MEMORY dedicated test module. However, when the SOC dedicated test module is active, the relevant ports of the MEMORY dedicated test module are left floating and not connected.

[0206] The communication registers in the dynamic area can only be read and written normally when the current dedicated test module (i.e., the current function block is active). For example, the communication registers of modules such as the test result storage module, timing control module, and algorithm test vector generation module can only be accessed when the current module is the MEMORY dedicated test module.

[0207] Depend on Figure 9 As can be seen, in the above scheme, the FPGA has different dedicated implementation structures (such as a dedicated MEMORY test module or a dedicated SOC test module) for different functional modules that need to be tested. In this way, without changing the external pins and hardware circuits, the switching of different test functions can be completed by switching the implementation structure of the FPGA chip, so as to achieve the effect of testing multiple functional modules in the chip in the same set of hardware devices (such as testing both SOC functions and MEMORY functions).

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

[0209] 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 implementation 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.

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

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

[0212] 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 10As 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.

[0213] Those skilled in the art will understand that Figure 10 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.

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

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

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

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

[0218] The technical features of the above embodiments can be combined in any way. 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.

[0219] 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: After power-on, the logic processing module in the test machine loads a common function firmware file to build a common function module in the static area of ​​the logic processing module, and loads a first dedicated test firmware file by default to build a first dedicated test module in the dynamic area of ​​the logic processing module; the first dedicated test module has the testing function for the first function module in the chip under test. In response to a target instruction indicating firmware switching, the logic processing module reloads and configures a second dedicated test firmware file to construct a second dedicated test module in the dynamic area, replacing the first dedicated test module; the second dedicated test module has test functions for a second functional module in the chip under test. The logic processing module tests the second functional module based on the second dedicated test module.

2. The method according to claim 1, characterized in that, The common functional modules include a dynamic configuration module; In response to a target instruction indicating firmware switching, the logic processing module reloads the configuration of the second dedicated test firmware file to construct a second dedicated test module in the dynamic area, replacing the first dedicated test module, including: In response to the target instruction, the logic processing module reloads and configures the second dedicated test firmware file through the dynamic configuration module to build the second dedicated test module in the dynamic area.

3. The method according to claim 2, characterized in that, The dynamic configuration module includes a bit-width conversion module and a dynamic reconfiguration component; The logic processing module, in response to the target instruction, reloads and configures the second dedicated test firmware file through the dynamic configuration module to construct the second dedicated test module in the dynamic area, including: In response to the target instruction, the logic processing module performs bit-width conversion on the data in the second dedicated test firmware file through 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; The converted firmware file is loaded and configured through the dynamic reconfiguration component to construct a second dedicated test module that replaces the first dedicated test module.

4. The method according to claim 3, characterized in that, The target instruction is a reconfiguration state enable instruction issued by the host computer; The logic processing module responds to the target instruction by performing bit-width conversion on the data in the second dedicated test firmware file through the bit-width conversion module, including: In response to the reconfiguration state enable command, the bit width conversion module is started; The bit-width conversion module performs bit-width conversion on the data in the second dedicated test firmware file, and then transmits the converted firmware file to the dynamic reconfiguration component. Obtain the reconfiguration status end command issued by the host computer and shut down the bit width conversion module.

5. The method according to claim 4, characterized in that, The dynamic configuration module also includes a receiving module; The step of performing bit-width conversion on the data in the second dedicated test firmware file through the bit-width conversion module includes: The receiving module obtains bitstream data from the second dedicated test firmware file sent by the host computer, and the bit width conversion module performs bit width conversion on the bitstream data. The step of obtaining the reconfiguration status end instruction issued by the host computer includes: After the host computer sends out the complete second dedicated test firmware file, the reconfiguration status end instruction is obtained through the receiving module.

6. The method according to claim 5, characterized in that, The common functional module also includes a communication module and a main control module; the communication module is used to transmit the bit stream data in the second dedicated test firmware file issued by the host computer to the main control module; The step of obtaining the bitstream data in the second dedicated test firmware file sent by the host computer through the receiving module includes: The receiving module obtains the bitstream data from the second dedicated test firmware file transmitted by the main control module.

7. The method according to claim 3, characterized in that, The dynamic configuration module also includes a configuration startup module; Before performing bit-width conversion on the data in the second dedicated test firmware file via the bit-width conversion module, the method further includes: Obtain the target starting address and target file length sent by the host computer; the target starting address is the starting address of the second dedicated test firmware file in the non-volatile memory, and the target file length is the length of the second dedicated test firmware file; The configuration startup module retrieves the second dedicated test firmware file from the non-volatile memory based on the target start address and the target file length, and then transmits the second dedicated test firmware file to the bit width conversion module.

8. The method according to claim 1, characterized in that, The logic processing module, based on the second dedicated testing module, tests the second functional module, including: The logic processing module receives the linked list address of the current test case and loads the linked list data of the current test case from memory according to the linked list address. The logic processing module executes the current test case to test the second functional module based on the second dedicated test module and the linked list data.

9. The method according to claim 8, characterized in that, The common functional modules include a message arbitration module; The logic processing module, based on the second dedicated test module and the linked list data, executes the current test case to test the second functional module, including: The linked list data is input to the second dedicated test module in the dynamic area through the message arbitration module; The second dedicated test module executes the current test case based on the linked list data to test the second functional module.

10. The method according to any one of claims 1 to 9, characterized in that, The first functional module includes either an on-chip system functional module or a storage functional module; the second functional module is another functional module that is different from the first functional module, either an on-chip system functional module or a storage functional module.

11. A testing method for functional modules in a chip, characterized in that, The method includes: Determine whether the second functional module of the chip under test targeted by the current test case matches the current test firmware type corresponding to the logic processing module; wherein, the static area of ​​the logic processing module contains a common functional module corresponding to the common functional firmware file, and the dynamic area contains a first dedicated test module corresponding to the first dedicated test firmware file represented by the current test firmware type. If not, a target instruction is sent to the logic processing module; the target instruction is used to instruct the logic processing module to reload the configuration of the second dedicated test firmware file to build a second dedicated test module in the dynamic area to replace the first dedicated test module. After the second dedicated test firmware file is reconfigured, the logic processing module is instructed to execute the current test case based on the second dedicated test module to test the second functional module of the chip under test.

12. The method according to claim 11, characterized in that, The logic processing module includes a firmware information register; the value of the firmware information register is used to characterize the current test firmware type. The step of determining whether the second functional module of the chip under test targeted by the current test case matches the current test firmware type corresponding to the logic processing module includes: The value of the firmware information register is used to determine whether the second functional module matches the current test firmware type.

13. The method according to claim 12, characterized in that, The second dedicated test module includes a second indicator register; The method further includes: During the process of reloading the configuration of the second dedicated test firmware file, the value of the firmware information register and / or the value of the second indicator register are continuously read back; If the value of the firmware information register changes or the value of the second indicator register is read back, it is determined that the reconfiguration of the second dedicated test firmware file is complete.

14. The method according to claim 11, characterized in that, After the second dedicated test firmware file is reconfigured, the step of instructing the logic processing module to execute the current test case based on the second dedicated test module includes: After the second dedicated test firmware file is reconfigured, the linked list address of the current test case is sent to the logic processing module; The linked list address is used to instruct the logic processing module to load the linked list data of the current test case from memory, and to execute the current test case based on the second dedicated test module and the linked list data to test the second functional module.

15. The method according to claim 14, characterized in that, Before determining whether the current test firmware type corresponding to the second functional module and the logic processing module of the chip under test targeted by the current test case matches, the method further includes: Obtain configuration information for at least one test case; Compile the configuration information of each test case to obtain the linked list data of each test case; The linked list data for each test case is loaded into memory and stored.

16. A testing system for functional modules in a chip, characterized in that, The testing system includes a host computer and a logic processing module; The logic processing module is configured to load a common function firmware file after power-on to construct a common function module in the static area of ​​the logic processing module, and to load a first dedicated test firmware file by default to construct a first dedicated test module in the dynamic area of ​​the logic processing module; the first dedicated test module has a testing function for the first function module in the chip under test. The host computer is used to send a target instruction to the logic processing module to switch firmware. The logic processing module is further configured to reload and configure the second dedicated test firmware file in response to the target instruction, so as to construct a second dedicated test module in the dynamic area to replace the first dedicated test module; the second dedicated test module has test functions for the second functional module in the chip under test; The logic processing module is also used to test the second functional module based on the second dedicated test module.

17. 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 10 or 11 to 15.

Images