Multi-scene compatible chip testing method and system

Abstract

The invention belongs to the field of chip automatic testing, particularly relates to a multi-scene compatible chip testing method and system, and aims at solving the problems that in traditional chip testing, the number of repeated programs is large, management is difficult, and recoding and compiling need to be carried out again when temporary adjustment is carried out. The method comprises the following steps: firstly, constructing a general test framework, wherein the framework comprises a preset test item set and a test resource association rule; then obtaining configuration information of a target test scene; dynamically generating a test flow corresponding to the target test scene based on the configuration information and the general test framework; and finally, executing the test process to complete the test. Through the process, one test program can be compatible with multiple test scenes, the code repetition amount and the management cost can be reduced, the test scenes or parameters can be adjusted only by modifying the configuration information under the condition that a framework does not need to be reconstructed, and the test flexibility and efficiency are effectively improved.

Description

Technical Field

[0001] This invention belongs to the field of automated chip testing, specifically relating to a chip testing method and system compatible with multiple scenarios. Background Technology

[0002] In the field of chip mass production testing, traditional testing methods typically involve developing a separate test program for each type of chip or each process. These test programs often have specific test items and fixed test resource configurations, with the execution logic of the test items and the test resources directly bound to the program code.

[0003] When dealing with different testing scenarios, such as chip testing at different stages of production (e.g., initial packaging testing, final product functional testing), it is necessary to write independent test programs for each scenario. This results in a large number of test programs and high code duplication, which not only increases the workload of development and maintenance but also complicates the management of test programs.

[0004] Furthermore, traditional test programs require modification of the source code and recompilation after compilation if the test scenario or test parameters need to be adjusted. This cannot meet the need for temporary adjustments to the test scenario or parameters during the testing process, resulting in poor flexibility and difficulty in adapting to the requirements of efficient chip mass production testing. Summary of the Invention

[0005] The purpose of this invention is to provide a chip testing method and system that is compatible with multiple scenarios, in order to solve the above-mentioned problems.

[0006] To achieve the above objectives, in a first aspect of the present invention, a multi-scenario compatible chip testing method is provided, comprising: Construct a general testing framework, which includes a preset set of test items and test resource association rules; Obtain the configuration information of the target test scenario; Based on the configuration information and the general testing framework, the test process corresponding to the target test scenario is dynamically generated. Perform the aforementioned test procedure to complete the test.

[0007] Furthermore, in the aforementioned multi-scenario compatible chip testing method, the step of constructing the general testing framework includes: Execution conditions are configured for each test item in the test item set, and the execution conditions are associated with the test scenario identifier; Establish the test resource association rules, which include the mapping relationship between test scenario identifiers and test resources. The test resources include at least one of pin configuration, waveform data, data source selection information, and test parameters.

[0008] Furthermore, in the multi-scenario compatible chip testing method, the test item set includes basic test items common to at least two test scenarios, as well as specific test items specific to each test scenario; the execution condition of the basic test items is that they are executed in all scenarios, and the execution condition of the specific test items is that they are executed only under the corresponding scenario identifier.

[0009] Furthermore, in the multi-scenario compatible chip testing method, the configuration information of the target test scenario includes: a test scenario identifier and at least one test parameter; the test scenario identifier is used to uniquely identify the type of the target test scenario, and the test parameter corresponds to the target test scenario, including voltage parameters and timing parameters.

[0010] Furthermore, in the aforementioned multi-scenario compatible chip testing method, the step of dynamically generating the test process corresponding to the target test scenario based on the configuration information and the general testing framework includes: Parse the configuration information and extract the test scenario identifier; Based on the test scenario identifier, test items that meet the execution conditions are selected from the general test framework; Based on the test scenario identifier and the test resource association rules, match the corresponding test resources; The selected test items and matching test resources are integrated in a preset order to generate the test process corresponding to the target test scenario.

[0011] Furthermore, in the aforementioned multi-scenario compatible chip testing method, the dynamic generation of the test process corresponding to the target test scenario further includes: An intermediate description file is generated, which records the selected test items, the matched test resources, and the execution order of the test items; the intermediate description file is used as the basis for executing the test process.

[0012] Furthermore, in the aforementioned multi-scenario compatible chip testing method, the execution of the testing process includes: Read and parse the intermediate description file, and load the test resources recorded in the intermediate description file; According to the execution order recorded in the intermediate description file, each test item is called and executed sequentially.

[0013] Furthermore, in the aforementioned multi-scenario compatible chip testing method, the waveform data is stored through a waveform description file, and the data source selection information is stored through a data source selection description file; the two are independent of each other. The method further includes: combining and compiling the waveform description file with the data source selection description file to generate a test resource file; In the test resource association rules, the test scenario identifier is bound to the test resource file.

[0014] Furthermore, the multi-scenario compatible chip testing method also includes a test adjustment step: When it is necessary to adjust the test scenario or test parameters, modify the configuration information of the target test scenario; Based on the modified configuration information, the steps of dynamically generating the test process and executing the test process are re-executed without the need to rebuild the general test framework.

[0015] In a second aspect, the present invention also provides a chip testing system compatible with multiple scenarios, including a framework building module, a configuration acquisition module, a process generation module, and an execution module; The framework construction module is used to build and store a general test framework, which includes a preset set of test items and test resource association rules. The configuration acquisition module is used to acquire configuration information of the target test scenario; The process generation module is used to dynamically generate the test process corresponding to the target test scenario based on the configuration information and the general test framework. The execution module is used to execute the test process to complete the test; The process generation module is also used to regenerate the test process based on the modified configuration information when the configuration information is modified, so that the framework construction module does not need to rebuild the general test framework.

[0016] Compared with the prior art, the present invention has at least the following technical effects: By constructing a general testing framework and dynamically generating a test process for the target scenario based on configuration information, the present invention enables a test program to be compatible with multiple test scenarios. This not only reduces code duplication and management costs, but also allows for adjustment of test scenarios or parameters by modifying configuration information without rebuilding the framework, thereby improving the flexibility and efficiency of testing. Attached Figure Description

[0017] Figure 1 This is a flowchart of a multi-scenario compatible chip testing method in one embodiment of the present invention; Figure 2 This is a framework diagram of a multi-scenario compatible chip testing system in one embodiment of the present invention. Detailed Implementation

[0018] The following will describe in more detail a multi-scenario compatible chip testing method and system of the present invention with reference to the schematic diagrams, which illustrate preferred embodiments of the invention. It should be understood that those skilled in the art can modify the invention described herein while still achieving its advantageous effects. Therefore, the following description should be understood as being of general knowledge to those skilled in the art and is not intended to limit the invention.

[0019] For clarity, not all features of the actual embodiments are described. In the following description, well-known functions and structures are not detailed in detail, as they would obscure the invention with unnecessary detail. It should be understood that in the development of any actual embodiment, numerous implementation details must be made to achieve the developer's specific objectives, such as changes from one embodiment to another according to limitations related to the system or business. Furthermore, it should be understood that such development work may be complex and time-consuming, but is merely routine work for those skilled in the art.

[0020] Based on the teachings of this specification, those skilled in the art can form new technical solutions through cross-combination of different implementation methods without creating technical contradictions. Such variations should all be considered to fall within the protection scope of this invention.

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

[0022] Example 1 In the field of chip mass production testing, the traditional approach is to develop separate test programs for each type of chip or each process. While this method ensures program stability, it generates a large amount of repetitive code, causing inconvenience for program management. Furthermore, once the test program is compiled, if the test content needs to be adjusted, it must be re-coded and recompiled, which cannot meet the needs of foundries for temporary adjustments during testing and is difficult to adapt to efficient chip mass production testing scenarios.

[0023] In view of this, such as Figure 1 As shown, to address these limitations of existing technologies, this embodiment proposes a multi-scenario compatible chip testing method to solve the problems of repetitive programs, difficult management, and the need for recompilation for temporary adjustments in traditional chip testing. This multi-scenario compatible testing execution method includes the following steps: S1: Construct a general testing framework, which includes a preset set of test items and test resource association rules.

[0024] S2: Obtain the configuration information of the target test scenario.

[0025] S3: Based on the configuration information and the general testing framework, dynamically generate the test process corresponding to the target test scenario.

[0026] S4: Execute the test procedure to complete the test.

[0027] This embodiment takes the mass production testing of a certain chip as the application scenario. The chip needs to complete three types of scenario tests: OS (pre-shipment functional sampling inspection), CP1 (pin connectivity test after packaging), and CP2 (finished product performance stability test). The implementation process of this multi-scenario compatibility test execution method is explained in detail according to the complete process of steps S1-S4.

[0028] Step S1 is to build a general testing framework that includes a set of preset test items and rules for associating test resources, so that the framework can be adapted to different test scenarios such as OS, CP1, and CP2, without having to develop separate programs for each scenario.

[0029] The steps for constructing the general testing framework include: configuring execution conditions for each test item in the test item set, wherein the execution conditions are associated with test scenario identifiers; and establishing test resource association rules, wherein the rules include the mapping relationship between test scenario identifiers and test resources, and the test resources include at least one of pin configuration, waveform data, data source selection information, and test parameters.

[0030] Specifically, in constructing the preset test item set, the test item set is divided into basic test items and specific test items, and each test item is configured with execution conditions strongly bound to the test scenario identifier. Basic test items are executed in all scenarios, such as PowerOnTest (chip power-on initialization detection). In other words, regardless of whether the subsequent test scenario is OS sampling inspection, CP1 post-packaging inspection, or CP2 finished product inspection, this test must first confirm that the chip powers on normally. Therefore, its execution condition is set to be executed in all scenarios, i.e., it is executed when the scenario identifier is OS, CP1, or CP2. Specific test items are dedicated to specific test requirements for different test scenarios, and their execution condition is to be executed only under the corresponding scenario identifier. In this embodiment, the CP1 scenario requires a focus on testing pin connectivity, so PinConnectTest (pin connectivity detection) is configured, with the execution condition being scenario identifier = CP1; the CP2 scenario requires verifying performance stability under high-temperature conditions, so StabilityTest (performance stability detection under high-temperature conditions) is configured, with the execution condition set to scenario identifier = CP2; the OS scenario, as a pre-shipment functional sampling test, needs to balance efficiency and coverage, so RandomFunctionTest (random functional sampling test) is configured, with the execution condition set to scenario identifier = OS. This design of basic and specific test items avoids redundant development and accurately matches the testing requirements of each scenario.

[0031] When establishing test resource association rules, the core is to construct a one-to-one mapping relationship between test scenario identifiers and test resources, enabling different scenarios to automatically call the corresponding resources. Test resources include at least one of the following: pin configurations, waveform data, data source selection information, and test parameters. In this embodiment, the file structure and compilation logic of various test resources are as follows: In terms of pin configuration, dedicated pin description files are matched for different scenarios, such as CP1_pin.soc (complete pin definition for CP1 scenario), CP2_pin.soc (dedicated pin definition for performance testing in CP2 scenario), and OS_pin.soc (simplified pin definition for OS scenario).

[0032] Waveform data and data source selection information are stored in separate preset format files. Waveform data is stored in a waveform description file, and data source selection information is stored in a data source selection description file. In this embodiment, waveform data is stored in a .wfm file, such as CP1.wfm, which represents the low-frequency detection waveform of CP1 test, and CP2.wfm, which represents the high-frequency stability waveform of CP2 test. Data source selection information is stored in a .dss file, such as CP1.dss, which defines that CP1 data is read from the FIFO buffer, and CP2_dss.dss, which defines that CP2 data is acquired from the register in real time.

[0033] Furthermore, the method also includes: compiling the waveform description file and the data source selection description file together to generate a test resource file; and binding the test scenario identifier to the test resource file in the test resource association rules. In this embodiment, .wfm and .dss files of the same scenario are compiled together to generate unmodifiable test resource files, such as CP1_res.gnr and CP2_res.gnr, and a binding relationship between the scenario identifier and the test resource file is established in the rules.

[0034] Regarding the test parameters, key parameters are set according to the technical requirements of each scenario. For example, the CP1 scenario requires matching the voltage characteristics of the pins after packaging, so VIH=3.3V and VOH=2.8V are set; the CP2 scenario requires verifying high-frequency performance, so the timing parameter TestCycle=100ns is set; the OS scenario, as a sampling inspection, requires controlling efficiency, so the sampling parameter SampleRate=10% is set, so that the parameters are accurately matched with the scenario requirements.

[0035] The configuration information in step S2 is carried by the configuration file on the host (test workstation). The configuration information of the target test scenario includes: a test scenario identifier and at least one test parameter. The test scenario identifier is used to uniquely identify the type of test scenario, and the test parameter corresponds to the target test scenario. The test parameter includes voltage parameters and timing parameters.

[0036] Specifically, the configuration file content needs to be precisely set according to the requirements of the target test scenario. For example, when CP1 is required for the chip, the configuration file loaded on the host side will record: SceneID=CP1, VIH=3.3V, VOH=2.8V, TestTime=5min. Here, SceneID is the test scenario identifier, directly indicating that the current target is the CP1 scenario. VIH and VOH are voltage parameters, and TestTime is the test duration parameter, all of which match the pin connectivity detection requirements of the CP1 scenario. If it is necessary to switch to the CP2 scenario, there is no need to modify the general test framework. Just adjust the configuration file to: SceneID=CP2, TestCycle=100ns, Temp=85℃. At this time, SceneID=CP2 serves as the new test scenario identifier. Combined with the timing parameter TestCycle and the environmental parameter Temp, it can meet the performance stability detection requirements of the CP2 scenario under high temperature conditions.

[0037] Furthermore, step S3 requires dynamically generating a dedicated test process adapted only to the current target test scenario, based on the general test framework constructed in step S1 and the configuration information of the target test scenario obtained in step S2. The steps include: parsing the configuration information and extracting the test scenario identifier; selecting test items that meet the execution conditions from the general test framework based on the test scenario identifier; matching the corresponding test resources based on the test scenario identifier and the test resource association rules; and integrating the selected test items and the matched test resources in a preset order to generate the test process corresponding to the target test scenario. The specific steps are as follows: First, after the test system starts, it will automatically read the configuration file of the target test scenario loaded on the host. By parsing the file, it will extract the unique test scenario identifier. For example, it can parse SceneID=CP1 from the configuration file corresponding to CP1, and thus know that the target test scenario to be executed is CP1 test.

[0038] Next, based on the extracted SceneID=CP1 test scenario identifier, test items that meet the execution conditions are selected from the general test framework constructed in step S1. According to the preset execution condition rules in the general test framework, the basic test item PowerOnTest is selected because it is set to be executed in all scenarios, and the CP1-specific test item PinConnectTest is also included because its execution conditions match the CP1 scenario identifier. However, the OS-specific RandomFunctionTest and the CP2-specific StabilityTest are excluded because their execution conditions do not match.

[0039] Then, based on SceneID=CP1 and the test resource association rules in the general test framework, various test resources required for the current scenario are matched. Among them, the pin configuration corresponds to the CP1_pin.soc file, the test resource file is the CP1_res.gnr file which is generated by compiling the .wfm waveform description file and the .dss data source description file specific to the CP1 scenario, and the test parameters are matched with VIH=3.3V, VOH=2.8V, and TestTime=5min recorded in the configuration file, so that all resources are accurately adapted to the CP1 scenario.

[0040] Finally, following the preset order of basic testing followed by specialized testing, the selected PowerOnTest and PinConnectTest test items are integrated with the matched pin configurations, test resource files, and test parameters, and the intermediate description file CP1_flow.tprj is generated.

[0041] Furthermore, the intermediate description file records the selected test items, the matched test resources, and the execution order of the test items; the intermediate description file serves as the basis for executing the test process.

[0042] In this embodiment, the intermediate description file adopts JSON format, which can clearly record the scenario identifier CP1, test item name and execution order, various resource information and specific test parameters. It is the sole basis for subsequent execution of the test process, so that test resources and processes are accurately matched.

[0043] Furthermore, step S4, based on the intermediate description file generated in step S3, completes the specific test execution for the target test scenario and finally outputs the test results. The steps of executing the test process in step S4 include: reading and parsing the intermediate description file, loading the test resources recorded in the intermediate description file, and sequentially calling and executing each test item according to the execution order recorded in the intermediate description file. The entire process is mainly divided into two logical stages: loading test resources and executing test items sequentially. Specifically: During the test resource loading phase, the test system calls a pre-defined execution library (such as TestExec.so). It first reads and parses the intermediate description file, extracting all the resource information required for the current test scenario. Taking CP1 testing as an example, the system loads the CP1_pin.soc pin configuration file, initializes the chip's pin detection channels according to the pin definitions recorded in the file, ensuring accurate connection of test signals to the chip. Simultaneously, it loads the test resource file CP1_res.gnr, compiled from a waveform description file (.wfm) and a data source selection description file (.dss). This test resource file configures the waveform generation module (for outputting the electrical signal waveforms required for detection) and the data acquisition module (for capturing the chip's response data in real time). Furthermore, it imports test parameters (such as VIH and VOH) recorded in the intermediate description file, setting these parameters in the voltage detection module of the test equipment as thresholds for determining whether the chip's response is qualified.

[0044] After resource loading is complete, the system enters the test item execution phase. The system strictly follows the execution order defined in the Order field of the intermediate description file, sequentially calling and running the selected test items. For the CP1 scenario, the basic test item PowerOnTest is executed first: the test device applies an input voltage to the chip according to the configured voltage parameters, synchronously detecting the chip's initialization response after power-on. If the response is abnormal, the chip is automatically marked as Bin:2 (unqualified) and the test is terminated; if PowerOnTest passes, the CP1-specific test item PinConnectTest is executed: based on the waveform and data source configured in CP1_res.gnr, detection signals are sent to each pin of the chip, and the data acquisition module collects the pin feedback to determine if there are any connectivity problems such as open circuits or short circuits. If an abnormal pin is found, it is marked as Bin:3; if all pins are normal, it is marked as Bin:1 (qualified).

[0045] Once all tests are completed, the system will automatically generate a test report containing detailed information, recording the scenario identifier used in this test, test parameters, execution results of each test item, chip classification (Bin value), and exception logs (such as the test item where the exception occurred, specific parameter values, etc.), thus completing the test process for the target test scenario.

[0046] Furthermore, this method also includes a test adjustment step: when it is necessary to adjust the test scenario or test parameters, modify the configuration information of the target test scenario; based on the modified configuration information, re-execute the steps of dynamically generating the test process and executing the test process, without having to rebuild the general test framework.

[0047] Specifically, when a modern factory needs to adjust its test scenario, such as switching from the current CP1 test to the OS test, no modifications are required to the general test framework built in step S1, nor is it necessary to recompile the core code of the test project. Operators only need to modify the test scenario identifier and corresponding parameters in the host configuration file, for example, replacing the original CP1 configuration file with SceneID=OS, SampleRate=10%, and TestTime=3min. The system will automatically repeat steps S3 and S4 based on the modified configuration information. First, it parses SceneID=OS in the new configuration, filters out OS-specific test items (such as "RandomFunctionTest") and matching test resources (such as OS_pin.soc pin configuration and OS_res.gnr test resource file) from the general test framework, and generates the OS_flow.tprj intermediate description file; then, it loads this file and executes the test items sequentially to complete the OS scenario test.

[0048] If only test parameters need adjustment, such as increasing the ambient temperature from Temp=85℃ to Temp=105℃ in CP2 testing, the operation is equally simple. Just directly modify the Temp parameter value in the Host configuration file; there's no need to touch any code in the general testing framework or recompile the test program. The system will re-execute step S3 based on the modified parameters, generating an intermediate description file containing the new parameters. Then, step S4 loads this file and executes the test with the updated parameters. This adjustment method completely eliminates the constraint of recompiling for every parameter change in traditional testing, reducing the response time for test adjustments from hours to minutes, significantly improving the flexibility and efficiency of chip mass production testing.

[0049] Example 2 like Figure 2 This embodiment provides a multi-scenario compatible chip testing system. This embodiment uses mass production testing of mobile phone processor chips as the application scenario. The chip needs to cover three scenarios: CP1 (post-packaging pin testing), CP2 (finished product functional testing), and OS (factory inspection). The system consists of a framework construction module, a configuration acquisition module, a process generation module, and an execution module. These modules work together to achieve multi-scenario compatible testing.

[0050] The framework building module is used to construct and store a general test framework, which includes a pre-defined set of test items and test resource association rules. When constructing the test item set, it includes basic test items and specific test items. Basic test items are applicable to all scenarios, while specific test items include pin connectivity testing for CP1, signal integrity testing for CP2, and random function sampling of the OS. Each test item is configured with execution conditions bound to a scenario identifier. Simultaneously, the framework building module establishes test resource association rules, indicating the mapping relationship between test scenario identifiers and test resources. Test resources include pin configuration files (such as CP1_pin, CP2_pin), waveform description files (.wfm), data source selection description files (.dss), and test parameters such as voltage (VIH, VOH) and timing. The .wfm and .dss files are stored independently, combined and compiled to generate .gnr format test resource files, which are then bound to the corresponding scenario identifiers, ensuring accurate resource retrieval.

[0051] The configuration acquisition module is used to obtain the configuration information of the target test scenario, which is stored in the form of a host-side configuration file. The configuration file contains test scenario identifiers (e.g., flowType=CP1, flowType=CP2) and corresponding test parameters. For example, the configuration file for scenario CP1 contains flowType=CP1, VIH=3V, VOH=5V, and the configuration file for scenario CP2 contains flowType=CP2, VIH=1V, VOH=3V. When switching test scenarios or adjusting parameters is required, operators do not need to modify the core system code; they only need to update the configuration file on the host side. The configuration acquisition module will read and transmit the latest configuration information in real time, providing a basis for subsequent process generation.

[0052] The process generation module dynamically generates test processes corresponding to the target test scenario based on the configuration information passed by the configuration acquisition module and the general test framework stored by the framework building module. Taking the CP1 scenario as an example, the process generation module first parses the configuration file and extracts the scenario identifier flowType=CP1; then, based on this identifier, it filters out test items (basic test items and CP1-specific test items) that meet the execution conditions from the general test framework; subsequently, it matches the corresponding test resources (CP1_pin pin configuration, data source file, waveform file, and voltage parameters) according to the test resource association rules; finally, it integrates the test items and resources in a preset order of basic tests first, followed by specific tests, to generate the CP1-specific intermediate description file CP1.tprj. In this embodiment, the intermediate description file adopts JSON format and records test items, resource information, and execution order. When the configuration information is modified, the process generation module will re-execute the above process based on the updated configuration, without requiring the framework building module to rebuild the general test framework, greatly improving adjustment efficiency.

[0053] The execution module is used to execute the test process to complete the test. First, it reads and parses the intermediate description file, loading the test resources recorded in the file. Then, according to the execution order set in the file, it sequentially calls and executes each test item. Basic test items are executed first to complete pin pre-detection, followed by dedicated test items to complete the CP1 scenario test. During the test, the module automatically records result classification (e.g., Bin:1 is qualified) and exception information. If switching to the CP2 scenario is required, only the Host-side configuration file needs to be modified. The configuration acquisition module reads the new configuration and passes it to the process generation module. The process generation module regenerates the CP2.tprj intermediate description file. After the execution module loads this file, it can automatically switch test resources and processes without any system module reconstruction. This achieves the requirement of a single system being compatible with multiple scenario tests, solving the pain points of repetitive development and cumbersome adjustments in traditional test systems.

[0054] The above are merely preferred embodiments of the present invention and do not constitute any limitation on the present invention. Any equivalent substitutions or modifications made by those skilled in the art to the technical solutions and content disclosed in the present invention without departing from the scope of the present invention shall be deemed to have remained within the protection scope of the present invention.

Claims

1. A chip testing method compatible with multiple scenarios, characterized in that, include: Construct a general testing framework, which includes a preset set of test items and test resource association rules; Obtain the configuration information of the target test scenario; Based on the configuration information and the general testing framework, the test process corresponding to the target test scenario is dynamically generated. Perform the aforementioned test procedure to complete the test.

2. The method according to claim 1, characterized in that, The steps for building the general testing framework include: Execution conditions are configured for each test item in the test item set, and the execution conditions are associated with the test scenario identifier; Establish the test resource association rules, which include the mapping relationship between test scenario identifiers and test resources. The test resources include at least one of pin configuration, waveform data, data source selection information, and test parameters.

3. The method according to claim 2, characterized in that, The set of test items includes basic test items common to at least two test scenarios, as well as specific test items specific to each test scenario; the execution condition for the basic test items is that they are executed in all scenarios, and the execution condition for the specific test items is that they are executed only under the corresponding scenario identifier.

4. The method according to claim 1, characterized in that, The configuration information of the target test scenario includes: a test scenario identifier and at least one test parameter; the test scenario identifier is used to uniquely identify the type of the target test scenario, and the test parameter corresponds to the target test scenario, including voltage parameters and timing parameters.

5. The method according to claim 4, characterized in that, The step of dynamically generating the test process corresponding to the target test scenario based on the configuration information and the general test framework includes: Parse the configuration information and extract the test scenario identifier; Based on the test scenario identifier, test items that meet the execution conditions are selected from the general test framework; Based on the test scenario identifier and the test resource association rules, match the corresponding test resources; The selected test items and matching test resources are integrated in a preset order to generate the test process corresponding to the target test scenario.

6. The method according to claim 5, characterized in that, The test process for dynamically generating the target test scenario also includes: An intermediate description file is generated, which records the selected test items, the matched test resources, and the execution order of the test items; the intermediate description file is used as the basis for executing the test process.

7. The method according to claim 6, characterized in that, The execution of the test process includes: Read and parse the intermediate description file, and load the test resources recorded in the intermediate description file; According to the execution order recorded in the intermediate description file, each test item is called and executed sequentially.

8. The method according to claim 2, characterized in that, The waveform data is stored in a waveform description file, and the data source selection information is stored in a data source selection description file; the two are independent of each other. The method further includes: combining and compiling the waveform description file with the data source selection description file to generate a test resource file; In the test resource association rules, the test scenario identifier is bound to the test resource file.

9. The method according to claim 1, characterized in that, It also includes test adjustment steps: When it is necessary to adjust the test scenario or test parameters, modify the configuration information of the target test scenario; Based on the modified configuration information, the steps of dynamically generating the test process and executing the test process are re-executed without the need to rebuild the general test framework.

10. A multi-scenario compatible chip testing system, characterized in that, It includes a framework building module, a configuration acquisition module, a process generation module, and an execution module; The framework construction module is used to build and store a general test framework, which includes a preset set of test items and test resource association rules. The configuration acquisition module is used to acquire configuration information of the target test scenario; The process generation module is used to dynamically generate the test process corresponding to the target test scenario based on the configuration information and the general test framework. The execution module is used to execute the test process to complete the test; The process generation module is also used to regenerate the test process based on the modified configuration information when the configuration information is modified, so that the framework construction module does not need to rebuild the general test framework.

Images