Chip verification method and device, electronic equipment, storage medium and program product

Abstract

This disclosure provides a chip verification method and apparatus, electronic device, storage medium, and program product. By acquiring a configuration file containing a first parameter combination pattern, it automatically parses and generates a second parameter combination pattern consisting of completely cross-combinations of all parameter values ​​to generate a regression list and execute regression testing. This replaces the arduous work of manual enumeration and combination, achieving fully automated configuration and full combination generation, solving the problems of high workload, error susceptibility, and omissions. The second parameter combination pattern covers all possible combinations of all parameter values, ensuring that the function under any parameter combination is verified, effectively addressing combination explosion and improving coverage. Adding, deleting, or modifying parameters only requires adjusting the configuration file to regenerate the regression list with one click, without manual intervention, greatly reducing maintenance costs and supporting rapid iteration. Simultaneously, it forms a complete automated verification closed loop, improving regression testing efficiency while ensuring verification completeness.

Description

Technical Field

[0001] This disclosure relates to chip verification technology, and in particular to a chip verification method and apparatus, electronic devices, storage media, and program products. Background Technology

[0002] During chip verification, to ensure the stability and reliability of the DUT (Design Under Test) under different configuration parameters, it is usually necessary to perform full combination regression verification on a large number of configuration parameters. These configuration parameters include bus width, clock frequency, mode switches, functional configurations, debugging parameters, C model configurations, etc. In related technologies, verification personnel rely on manually enumerating all possible values ​​of all parameters and then manually arranging and combining them to generate a regression list (test cases). This approach has the following prominent problems: (1) When there are many parameters and many possible values ​​for each parameter, the number of combinations grows exponentially, making manual enumeration almost impossible; (2) Once parameters are added, deleted or modified, the regression list needs to be reorganized, which is extremely costly to maintain and prone to errors. (3) It cannot quickly support large-scale, multi-dimensional parameter cross-combination regression, resulting in insufficient verification coverage and low iteration efficiency. Summary of the Invention

[0003] To address the technical problems in related technologies, this disclosure provides a chip verification method and apparatus, an electronic device, a storage medium, and a program product.

[0004] A first aspect of this disclosure provides a chip verification method, the method comprising: Obtain a configuration file, the configuration file including at least one first parameter combination pattern, the first parameter combination pattern including a parameter name and a parameter value corresponding to the parameter name; The configuration file is parsed to generate a second parameter combination pattern based on the parameter name and the parameter value corresponding to each first parameter combination pattern. The second parameter combination pattern is a set of parameter value combinations obtained by completely cross-combining the parameter values ​​of the parameter names in the first parameter combination patterns. A regression list is generated based on the parameter values ​​of the second parameter combination mode; Output the regression list and perform regression testing to verify the chip design based on the regression list.

[0005] As an optional embodiment, parsing the configuration file to generate a second parameter combination pattern based on the parameter names in each first parameter combination pattern and the parameter values ​​corresponding to those parameter names includes: Read the configuration file and extract each of the first parameter combination patterns from the configuration file according to a preset data structure; For any first parameter combination pattern, the parameter value corresponding to each parameter name in the first parameter combination pattern is split to obtain a list of parameter values ​​corresponding to each parameter name. Perform a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination pattern to obtain a set of parameter value combinations, and the set of parameter value combinations is the second parameter combination pattern.

[0006] As an optional embodiment, for any first parameter combination pattern, the parameter value corresponding to each parameter name in the first parameter combination pattern is split to obtain a list of parameter values ​​corresponding to each parameter name, including: Get the parameter value corresponding to any parameter name, wherein the parameter value is a first string including at least one preset symbol; The first string is segmented based on the preset symbols to obtain at least one second string, wherein the second string is a substring of the first string; Each second string is formatted and normalized, and all the processed second strings are combined into a list of parameter values ​​corresponding to the parameter name.

[0007] As an optional embodiment, performing a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination pattern to obtain the set of parameter value combinations includes: For each list of parameter values, extract one parameter value and combine all the extracted parameter values ​​into a parameter value combination according to the predetermined order of the parameter names; All generated parameter value combinations are stored in a set to obtain the set of parameter value combinations.

[0008] As an optional embodiment, generating a regression list based on the parameter value combination of the second parameter combination mode includes: For each parameter value combination in the second parameter combination mode, based on the parameter name and its corresponding parameter value in the parameter value combination, corresponding test case fragments are generated according to preset format rules. All test case fragments belonging to the same parameter value combination are identified as test cases for that parameter value combination; The regression list is determined based on the test cases corresponding to all combinations of parameter values.

[0009] As an optional embodiment, the step of generating corresponding test case fragments based on the parameter names and their corresponding values ​​in the parameter value combination according to preset format rules includes: Iterate through each parameter name and its corresponding parameter value in the parameter value combination, and determine whether the parameter name has a preset prefix; In response to the parameter name having the preset prefix, a test case fragment corresponding to the parameter name is generated according to the first format; If the parameter name does not have the preset prefix, a test case fragment corresponding to the parameter name is generated according to the second format.

[0010] As an optional embodiment, determining all test case fragments belonging to the same parameter value combination as test cases for that parameter value combination includes: All test case fragments corresponding to this parameter value combination are concatenated in a predetermined order of parameter names to obtain the concatenation result; A preset string is added to a preset position in the splicing result to form a test case for the combination of parameter values.

[0011] According to a second aspect of the present disclosure, a chip verification apparatus is provided, the apparatus comprising: The acquisition module is used to acquire a configuration file, the configuration file including at least one first parameter combination pattern, the first parameter combination pattern including a parameter name and a parameter value corresponding to the parameter name; The parsing module is used to parse the configuration file to generate a second parameter combination pattern based on the parameter name and the parameter value corresponding to each first parameter combination pattern. The second parameter combination pattern is a set of parameter value combinations obtained by completely cross-combining the parameter values ​​of the parameter names in the first parameter combination patterns. The regression testing module is used to generate a regression list based on the parameter value combination of the second parameter combination mode, so as to perform regression testing and verification on the chip design based on the regression list.

[0012] As an optional embodiment, the parsing module includes: The file reading unit is used to read the configuration file and extract each of the first parameter combination patterns from the configuration file according to a preset data structure; The splitting processing unit is used to split the parameter value corresponding to each parameter name in any first parameter combination pattern to obtain a list of parameter values ​​corresponding to each parameter name. The arithmetic unit is used to perform a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination mode to obtain a set of parameter value combinations, wherein the set of parameter value combinations is the second parameter combination mode.

[0013] As an optional embodiment, the splitting processing unit includes: The parameter value acquisition subunit is used to acquire the parameter value corresponding to any parameter name, wherein the parameter value is a first string including at least one preset symbol; A segmentation processing subunit is used to segment the first string based on the preset symbol to obtain at least one second string, wherein the second string is a substring of the first string; The normalization processing subunit is used to perform format normalization processing on each second string and combine all the processed second strings into a list of parameter values ​​corresponding to the parameter name.

[0014] As an optional embodiment, the computing unit includes: The parameter value combination determination sub-unit is used to extract a parameter value from each parameter value list and combine all the extracted parameter values ​​into a parameter value combination according to a predetermined order of parameter names. The parameter value combination storage subunit is used to store all generated parameter value combinations into a set, thereby obtaining the set of parameter value combinations.

[0015] As an optional embodiment, the regression testing module includes: The test case fragment generation unit is used to generate corresponding test case fragments according to preset format rules based on the parameter names and their corresponding parameter values ​​in each parameter value combination in the second parameter combination mode. The test case determination unit is used to determine all test case fragments belonging to the same parameter value combination as test cases for that parameter value combination. The regression list determination unit is used to determine the regression list based on the test cases corresponding to all combinations of parameter values.

[0016] As an optional embodiment, the use case fragment generation unit includes: Traverse sub-units to traverse each parameter name and its corresponding parameter value in the parameter value combination, and determine whether the parameter name has a preset prefix; The first generation subunit is used to generate a test case fragment corresponding to the parameter name in a first format in response to the parameter name having the preset prefix. The second generation subunit is used to generate a test case fragment corresponding to the parameter name in accordance with the second format in response to the parameter name not having the preset prefix.

[0017] As an optional embodiment, the test case determination unit includes: The splicing subunit is used to splice all test case fragments corresponding to the parameter value combination in a predetermined order of parameter names to obtain the splicing result; Add a sub-unit to add a preset string at a preset position in the splicing result to form a test case for the parameter value combination.

[0018] A third aspect of this disclosure provides an electronic device, including: Memory, used to store computer program products; A processor for executing a computer program product stored in memory, wherein when the computer program product is executed, it implements any of the methods described in the first aspect above.

[0019] A fourth aspect of this disclosure provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement any of the methods described in the first aspect above.

[0020] The fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed by a processor, implement any of the methods described in the first aspect above.

[0021] In summary, by acquiring a configuration file containing at least one first parameter combination pattern, automatically parsing and generating a second parameter combination pattern consisting of complete cross combinations of all parameter values, and then generating a regression list and performing regression testing verification, this method replaces the arduous task of manually enumerating parameter values ​​and manually arranging combinations. It achieves full automation from user configuration to full combination generation, solving the problems of high workload, error susceptibility, and omissions associated with manual methods. Secondly, since the second parameter combination pattern covers all possible combinations of parameter values ​​(i.e., Cartesian products) of all parameter names in the first parameter combination pattern, it ensures that the functionality under any parameter combination is verified, effectively addressing the explosion scenario of multi-parameter cross combinations and improving verification coverage. Thirdly, when parameters need to be added, removed, or their values ​​modified, users only need to adjust the configuration file to regenerate the regression list with one click, without manual intervention, greatly reducing maintenance costs and supporting rapid iteration. Furthermore, this embodiment seamlessly integrates parameter configuration, full combination generation, regression list output, and regression test execution, forming a complete automated verification closed loop, ensuring verification completeness while improving regression testing efficiency.

[0022] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0023] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0024] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a schematic flowchart of a chip verification method according to an exemplary embodiment of the present disclosure.

[0025] Figure 2 This is a schematic flowchart of a chip verification method according to another exemplary embodiment of this disclosure.

[0026] Figure 3 This is a schematic flowchart of a chip verification method, which is yet another exemplary embodiment of this disclosure.

[0027] Figure 4 This is a structural block diagram of a chip verification apparatus according to an exemplary embodiment of the present disclosure.

[0028] Figure 5 This is a structural block diagram of an electronic device according to an exemplary embodiment of the present disclosure. Detailed Implementation

[0029] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0030] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0031] The embodiments of this invention can be applied to electronic devices such as computer systems / servers, which can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with electronic devices such as computer systems / servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0032] Electronic devices such as computer systems / servers can be described in the general context of computer-executable instructions (such as program modules) executed by the computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are performed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0033] In order to accurately describe the technical content in this disclosure, and to accurately understand the embodiments of this disclosure, the terms used in the embodiments of this disclosure are explained or defined as follows: DUT (Design Under Test): Design under test refers to the design module or system that is tested during chip verification. It is usually register-transfer-level (RTL) code or gate-level netlist.

[0034] Regression testing: In chip verification, this is a testing process where existing test cases are rerun after design modifications to ensure that the new modifications do not introduce errors and that the original functionality is not compromised.

[0035] Regression List: A file containing one or more test cases, each with corresponding parameter configurations for one simulation run. The regression script reads this regression list and executes the simulation line by line.

[0036] Parameter Combination Mode: This refers to a user-specified set of parameters and the possible values ​​for each parameter. A single parameter combination mode can independently generate test cases for all combinations of parameters within that mode. Multiple parameter combination modes can coexist in the same configuration file, each generating its own set of test cases.

[0037] Parameter Value List: A list consisting of all possible values ​​for a given parameter. For example, if parameter a takes the values ​​2 and 3, then the parameter value list would be [2, 3].

[0038] Parameter value combination: A set of parameters is created by selecting one parameter value from each parameter's list of values ​​and combining them in a predetermined order. For example, if parameter a is 2 and parameter b is 4, then a parameter value combination is (a=2, b=4).

[0039] Full Cross Combination / Cartesian Product: This refers to pairing all elements of multiple sets to obtain all possible combinations. For example, if set A = {2, 3} and set B = {4, 5}, their Cartesian product is {(2, 4), (2, 5), (3, 4), (3, 5)}. In this disclosure, it is used to perform a full cross combination traversal of the parameter value lists of each parameter.

[0040] Configuration File: A file written in a lightweight data exchange format (such as JSON) to describe at least one parameter combination pattern. Each parameter combination pattern contains parameter names and their corresponding parameter values ​​(e.g., they can be expressed as comma-separated strings).

[0041] Predefined Symbol: A symbol used to separate parameter values. Predefined symbols allow you to split a parameter string into multiple substrings, each corresponding to a parameter value.

[0042] Format Normalization: Cleansing and standardizing the substrings obtained from the splitting process, including but not limited to removing leading and trailing spaces, removing quotation marks, and converting case, in order to obtain normalized parameter values.

[0043] Predefined Prefix: A string prefix used to identify parameters of special types. For example, parameters starting with "ccl_" represent C model configuration parameters, which require test case fragments to be generated according to a special format.

[0044] Test Case Segment: A formatted parameter string generated for a single parameter. For example, a regular parameter generates "a=2", while a parameter with a preset prefix generates "ccl+=mode=fast".

[0045] Test Case: A complete test command string corresponding to a combination of parameter values. It can be constructed by concatenating multiple test case fragments and adding a shell (such as "CASE_BATCH(...)"). The regression script directly parses this string and executes the corresponding simulation task.

[0046] Test Case List: A list of all test cases arranged in order, usually saved as a file with the .list extension for the regression script to execute.

[0047] Predefined Position: This refers to the position where a predefined string will be added to the concatenated result, such as the front end, back end, or both ends. For example, the predefined positions are the front end and back end of the concatenated result.

[0048] Predefined String: A fixed string added to a predefined position in the concatenation result to form a test case format that the regression script can recognize. For example, it includes the prefix string "CASE_BATCH(" and the suffix string ")".

[0049] First Format: This format is used to generate test case fragments corresponding to parameters with preset prefixes. For example, for the parameter name "ccl_mode", the first format generates "ccl+=mode=fast" (where "ccl" is the preset identifier, "+=" is the assignment operator, "mode" is the parameter name after removing the preset prefix, and "fast" is the parameter value).

[0050] Second Format: This format is used to generate test case fragments for ordinary parameters that do not have a preset prefix. For example, for the parameter name "a", the second format generates "a=2" (where "=" is the assignment operator).

[0051] The technical solution of this disclosure will be described in detail below with reference to the accompanying drawings, so that those skilled in the art can clearly and accurately understand and implement the technical solution of this disclosure.

[0052] Figure 1 This is a schematic flowchart of a chip verification method according to an exemplary embodiment of this disclosure. Figure 1 As shown, a chip verification method according to an embodiment of this disclosure may include the following steps: Step 110: Obtain the configuration file, wherein the configuration file includes at least one first parameter combination pattern, and the first parameter combination pattern includes a parameter name and a parameter value corresponding to the parameter name.

[0053] In practical chip verification applications, verification personnel need to perform full combination regression tests on multiple configuration parameters of the design under test (DUT). In related technologies, verification personnel need to manually enumerate all parameter combinations and manually write regression lists, which is labor-intensive and prone to errors.

[0054] In this step, verifiers input their test requirements by editing a configuration file. Specifically, verifiers use a text editor (such as Notepad, VS Code, etc.) or a dedicated configuration tool to write the configuration file according to a predefined format. This configuration file describes the parameters that need to be iterated in this regression test and all possible values ​​for each parameter. After completing the configuration file, verifiers save it as a file in a specific format (such as a .json file). Subsequent automated scripts will read this configuration file to obtain the parameter definition information input by the user and obtain the first parameter combination pattern.

[0055] For example, the user (verifier) ​​uses a text editor to write a lightweight data exchange format file (e.g., a JSON file) according to the verification requirements. The file structure is, for example, an array, where each element is an object representing a first parameter combination pattern. Within each object, the key is the parameter name, and the corresponding value is all possible values ​​for that parameter, given as strings, separated by specific symbols (e.g., commas). After completing the configuration file, the user saves it to local storage or a network-accessible location. The test script (e.g., a Python script), at runtime, reads the configuration file via the file path to obtain it.

[0056] The parameters (parameter names) include, but are not limited to, the following types: Bus parameters: such as bus width (bus_width, which can be 8, 16, 32, 64, etc.) and bus protocol type (bus_protocol, which can be AXI, AHB, APB, etc.). Clock and frequency parameters: such as clock frequency (clk_freq, which can be 100M, 200M, 500M, etc.) and clock phase (clk_phase, which can be 0, 90, 180, etc.). Mode switch parameters: such as working mode (work_mode, which can be normal mode, low power mode, test mode, etc.) and function enable switch (enable_feature, which can be 0 or 1). Debugging parameters: such as enabling the debug interface (debug_enable, can be true or false) and logging level (log_level, can be 0, 1, 2, 3). C model configuration parameters: usually prefixed with ccl_, such as C model mode (ccl_mode, which can be fast or safe) and C model precision (ccl_precision, which can be high, medium or low).

[0057] The configuration file contains at least one first parameter combination pattern. Each first parameter combination pattern defines a set of parameter names that need to be fully combined and their corresponding parameter values ​​(usually multiple optional values). Through this configuration file, verifiers can flexibly define the test parameter space without writing any code, and it supports defining multiple independent fully combined scenarios in the same file (for example, defining unrelated parameter groups separately to avoid unnecessary combinations), and generating test cases for each scenario.

[0058] For example, using JSON format, the configuration file structure is as follows: / / Example configuration file: test_config.json / / This file contains two independent first-parameter combination patterns, used for full combinatorial traversal of different parameter groups. [ { / / First first parameter combination pattern "a": "2, 3", / / The optional values ​​for parameter 'a' are 2 and 3, separated by a comma. "b": "4, 5" / / The possible values ​​for parameter b are 4 and 5 }, { / / Second first parameter combination pattern "ccl_mode": "fast, safe", / / Parameters starting with ccl_ represent C model configuration parameters. "ccl_level": "1, 2" / / The parameter value can be a number, but it will still be given as a string. } ] This embodiment achieves a configuration-driven, zero-coding parameter definition method. Users only need to edit the configuration file to fully describe the parameter space that needs to be traversed. It supports multiple independent full combination scenarios, and adding, deleting or modifying parameters only requires adjusting the corresponding content of the configuration file without changing any generation logic. This solves the problems of easy omission, error and maintenance difficulties of manual enumeration, and lays the foundation for the subsequent automatic generation of full combination regression lists.

[0059] Step 120: Parse the configuration file to generate a second parameter combination pattern based on the parameter name and the parameter value corresponding to each first parameter combination pattern.

[0060] The second parameter combination pattern is the set of parameter value combinations obtained by completely cross-combining the parameter values ​​of the parameter names in the first parameter combination pattern. For example, it is the set of parameter value combinations obtained by completely cross-combining some or all of the parameter values ​​in the first parameter combination pattern. In this step, the acquired configuration file is parsed to extract the parameter names and their corresponding parameter values ​​from each first parameter combination pattern, and all possible parameter value combinations are generated through, for example, complete cross-combination (i.e., Cartesian product). The set of these parameter value combinations is the second parameter combination pattern. In other words, the second parameter combination pattern is the complete set of all parameter value combinations in the parameter space defined by the first parameter combination pattern. This step achieves automatic conversion from a user-friendly configuration file to a machine-traversable parameter combination space, eliminating the need for manual enumeration.

[0061] As one implementation of this disclosure, the configuration file is first read, and each first parameter combination pattern is extracted from it according to a preset data structure (e.g., a JSON array). Then, for each first parameter combination pattern, the parameter value corresponding to each parameter name is split into a list of parameter values ​​(e.g., separated by commas and spaces are removed). Finally, the Cartesian product operation is performed on all parameter value lists in the same first parameter combination pattern to obtain a set of all parameter value combinations, thus obtaining the second parameter combination pattern.

[0062] As another implementation of this disclosure, different combination generation strategies can be employed to obtain the second parameter combination pattern, such as using orthogonal arrays or pairwise methods. Specifically, after extracting the list of parameter values ​​corresponding to each parameter name, instead of performing a full Cartesian product combination, a representative subset of parameter value combinations is selected from the full combination space based on orthogonal arrays or pairwise coverage criteria, and this subset is used as the second parameter combination pattern. This reduces the number of test cases and is suitable for scenarios with a large number of parameters but limited test resources.

[0063] As another implementation of this disclosure, the parameter values ​​in the configuration file can be given directly in list form (e.g., a JSON array). During parsing, there is no need for string splitting; the array is directly read as the list of parameter values, and then Cartesian product operations or other combined operations are performed. This simplifies the parsing logic and is suitable for scenarios where users are accustomed to writing arrays directly.

[0064] All the above implementation schemes are based on obtaining parameter names and their corresponding parameter values ​​(regardless of the original expression form or combination generation algorithm) from the first parameter combination pattern, and generating a set of parameter value combinations (called the second parameter combination pattern). This disclosure does not limit the specific scheme, and all parsing and generation methods under this concept fall within the protection scope of this invention.

[0065] For example, suppose the configuration file content obtained in step 110 is in JSON format: [ { / / First first parameter combination mode: testing normal parameter combinations / / Optional values ​​for the parameter bus_width (bus width): 8, 16, 32 (unit: bits) "bus_width": "8, 16, 32", / / Optional values ​​for the parameter freq (clock frequency): 100MHz, 200MHz "freq": "100M, 200M" }, { / / Second first parameter combination mode: Test C model configuration parameter combination / / Optional values ​​for the parameter ccl_debug_mode (C model debug mode): off (off), verbose (verbose output) "ccl_debug_mode": "off, verbose", / / Optional values ​​for the parameter ccl_log_level (C model log level): 0, 1, 2 (levels from low to high) "ccl_log_level": "0, 1, 2" } ] The configuration file is parsed in step 120: For the first parameter combination pattern: extract the parameter names `bus_width` and `freq`. Split the parameter string "8, 16, 32" of `bus_width` into a list [8, 16, 32], and split the string "100M, 200M" of `freq` into a list [100M, 200M]. Then calculate the Cartesian product of these two lists to obtain the 6 parameter value combinations: (bus_width=8, freq=100M) (bus_width=8, freq=200M) (bus_width=16, freq=100M) (bus_width=16, freq=200M) (bus_width=32, freq=100M) (bus_width=32, freq=200M) The set of these 6 combinations constitutes the first second parameter combination pattern.

[0066] For the second first parameter combination mode: extract the parameter names ccl_debug_mode and ccl_log_level, and split them into lists [off, verbose] and [0, 1, 2]. Calculate the Cartesian product to obtain 6 combinations of parameter values: (ccl_debug_mode=off, ccl_log_level=0) (ccl_debug_mode=off, ccl_log_level=1) (ccl_debug_mode=off, ccl_log_level=2) (ccl_debug_mode=verbose, ccl_log_level=0) (ccl_debug_mode=verbose, ccl_log_level=1) (ccl_debug_mode=verbose, ccl_log_level=2) The set of these 6 combinations constitutes the second combination pattern of the second parameter.

[0067] Finally, two second parameter combination patterns were generated through step 120. Each second parameter combination pattern contains 6 parameter value combinations, for a total of 12 combinations.

[0068] This achieves automated conversion from user configuration to a complete set of parameter combinations. It replaces the tedious manual enumeration of combinations, ensuring the generation of all possible parameter combinations and avoiding omissions. Furthermore, it supports an arbitrary number of parameters and an arbitrary value space, solving the problem of manual traversal being impossible under combination explosion. In addition, because the parsing logic is decoupled from the configuration file format, it can flexibly adapt to various input formats and has good scalability.

[0069] Step 130: Generate a regression list based on the parameter values ​​of the second parameter combination mode, and perform regression testing and verification on the chip design based on the regression list.

[0070] In this step, based on the generated second parameter combination pattern (i.e., the set of all parameter value combinations), each parameter value combination is converted into a test case that can be executed by the regression script, and all test cases are organized into a regression list. The regression list is a file containing several lines of test cases, with each line corresponding to a parameter value combination. The regression script reads this file and executes the simulation verification line by line.

[0071] In one embodiment of this disclosure, each parameter value combination in the second parameter combination mode can be used to generate a corresponding test case fragment according to a preset formatting rule (e.g., distinguishing between ordinary parameters and parameters with a specific prefix). Based on all test case fragments of any parameter value combination, its corresponding test case can be obtained, and a regression list can be generated from all test cases of all parameter value combinations.

[0072] In another embodiment of this disclosure, regression lists in different formats can also be generated to suit different regression scripts. For example, for regression tools that do not support a specific shell format, each parameter value combination can be directly generated as a single command-line call, such as "simulator +a=2 +b=4 +ccl_mode=fast". Specifically, each parameter name and parameter value in the parameter value combination is traversed to generate different command-line parameter strings (ordinary parameters generate "+parameter name=parameter value", ccl parameters generate "+ccl+parameter name=parameter value"), and then all parameter strings are connected with spaces to form a single command line. All command lines are written line by line to a script file (such as .sh or .bat) for the regression script to call.

[0073] In another embodiment of this disclosure, user-defined formatting templates can also be supported. The user specifies a template string in a configuration file or via command-line arguments, such as "run_test --param1={a} --param2={b} --ccl={ccl_mode}", where {parameter name} is a placeholder. The actual parameter value in each parameter value combination replaces the corresponding placeholder in the template, generating a complete test command. This approach offers maximum flexibility and is suitable for various regression frameworks.

[0074] In another embodiment of this disclosure, some auxiliary information can be added when generating the regression list, such as adding comments at the beginning of the file (e.g., generation time, parameter description, total number of test cases), or adding comments after each line of test cases to indicate the original parameter value combination corresponding to the test case, which facilitates debugging and traceability.

[0075] For example, continuing the example from step 120, suppose the second parameter combination mode contains two modes with a total of 12 parameter value combinations. Taking the parameter value combination "bus width=8, clock frequency=100M" in the first mode as an example, a test case of the form "CASE_BATCH(bus_width=8 freq=100M)" can be generated; for the parameter value combination "C model debug mode=off, C model log level=0" in the second mode, a test case of the form "CASE_BATCH(ccl+=debug_mode=off ccl+=log_level=0)" is generated. Perform the same operation on all 12 parameter value combinations, and write the generated 12 lines of test cases to a file to obtain the regression list. Further, the above combination may be generated as "simulator +bus_width=8 +freq=100M" and "simulator +ccl+debug_mode=off +ccl+log_level=0". Alternatively, if the user-defined template is "run --bus={bus_width} --freq={freq}", then the replacement will result in "run --bus=8 --freq=100M".

[0076] In this way, the conversion from a set of parameter value combinations to a regression list is automated, replacing the tedious work of manually writing regression lists. It automatically identifies parameter types and adopts different output formats to ensure that the generated test cases can be correctly parsed by the regression script. It supports multiple output formats and can flexibly adapt to different regression verification environments. After parameter changes, there is no need to manually modify the regression list. You can simply rerun the script to generate a new list with one click, improving verification efficiency and maintainability.

[0077] In this step, the generated regression list can also be output as a file, and this regression list can be used to perform regression testing on the device under test (DUT). The regression list includes test cases corresponding to all parameter value combinations, and each test case can be parsed by the regression script and converted into a simulation run. In this way, a complete automated closed loop from parameter configuration to actual verification execution is achieved, and verification personnel can complete the full traversal regression of a large number of parameter combinations without manually running each test case.

[0078] In one specific embodiment of this disclosure, the regression list is output as a plain text file, typically with the .list extension (e.g., regression.list). Each line in the file represents a complete test case string, for example: # Regression list file: regression_test.list # Generation time: XX year XX month XX day # Total number of test cases: 12 # The following are test cases generated based on the second parameter combination pattern. Each test case corresponds to a parameter value combination. # Use cases generated by the first parameter combination mode (common parameters: bus width, clock frequency) CASE_BATCH(bus_width=8 freq=100M) # Example 1: Bus width = 8, clock frequency = 100MHz CASE_BATCH(bus_width=8 freq=200M) # Case 2: Bus width = 8, clock frequency = 200MHz CASE_BATCH(bus_width=16 freq=100M) # Case 3: Bus width = 16, Clock frequency = 100MHz CASE_BATCH(bus_width=16 freq=200M) # Case 4: Bus width = 16, Clock frequency = 200MHz CASE_BATCH(bus_width=32 freq=100M) # Case 5: Bus width = 32, clock frequency = 100MHz CASE_BATCH(bus_width=32 freq=200M) # Case 6: Bus width = 32, clock frequency = 200MHz # Test cases generated by the second parameter combination pattern (C model configuration parameters: debug mode, log level) CASE_BATCH(ccl+=debug_mode=off ccl+=log_level=0) # Test Case 7: C Model debug mode=off, log level=0 CASE_BATCH(ccl+=debug_mode=off ccl+=log_level=1) # Test Case 8: C Model debug mode=off, log level=1 CASE_BATCH(ccl+=debug_mode=off ccl+=log_level=2) # Test Case 9: C Model debug mode=off, log level=2 CASE_BATCH(ccl+=debug_mode=verbose ccl+=log_level=0) # Test Case 10: C Model Debug Mode=verbose, Log Level=0 CASE_BATCH(ccl+=debug_mode=verbose ccl+=log_level=1) # Test Case 11: C Model Debug Mode=verbose, Log Level=1 CASE_BATCH(ccl+=debug_mode=verbose ccl+=log_level=2) # Test Case 12: C Model Debug Mode=verbose, Log Level=2 This format can be directly read and parsed by internal regression scripts (usually Python, Perl, or Shell scripts). The regression script reads the file line by line, extracts parameter assignment information for each line, and calls a simulator (such as VCS, ModelSim, Xcelium, etc.) to execute the corresponding simulation task.

[0079] After reading the regression list, the regression script typically performs the following operations: (1) Parse test cases: Parse the parameter name and its corresponding parameter value from each line of string. For example, extract bus_width=8 and freq=100M from “CASE_BATCH(bus_width=8 freq=100M)”; (2) Configure the simulation environment: Set the command line parameters, environment variables or configuration files of the simulator according to the analysis results so that the simulation runs under the specified parameter combination; (3) Run simulation: Call the simulator to execute the test cases of the chip design (e.g., run pre-written test stimuli).

[0080] (4) Collect results: Record the simulation log, pass / fail status, coverage data, etc. for each use case.

[0081] (5) Generate report: Summarize the execution results of all test cases, output regression test report, and mark failed test cases for verification personnel to analyze.

[0082] Because the regression list automatically covers all parameter combinations, validators can ensure that the design functionality is validated for any parameter value without manual intervention.

[0083] For example, continuing the previous example, suppose the generated regression list file is named regression_test.list and contains 12 lines of test cases. The verifier executes the following command in the Linux terminal: # Steps: Perform regression testing # Script: run_regression.py (Internal regression script, responsible for parsing the regression list and calling the simulator) # Input: regression_test.list (the regression list file generated in step 130) # Behavior: The script reads each test case in the regression list line by line, sets the corresponding parameter environment, and calls the VCS simulator to run the test stimuli of the chip design. # Output: Simulation logs, regression reports (pass / fail statistics, coverage data, etc.) python run_regression.py --list regress_test.list --simulator vcs The `run_regression.py` file contains the internal regression script. This script reads each line from `regress_test.list`. The first line, “CASE_BATCH(bus_width=8 freq=100M)”, triggers a simulation, sets the bus width to 8 and the clock frequency to 100MHz, and runs the test stimulus of the chip design. The second line, “CASE_BATCH(bus_width=8 freq=200M)”, triggers the second simulation, changing the frequency to 200MHz, and so on. For test cases containing ccl_ prefix parameters (such as "CASE_BATCH(ccl+=debug_mode=off ccl+=log_level=0)"), the regression script parses out the special ccl+= syntax, converts it into configuration parameters for the C model, and passes it to the simulation environment.

[0084] All 12 simulation tasks can be executed sequentially or submitted concurrently to the server cluster. Upon completion, the regression script outputs a summary report: "Total test cases: 12, Pass: 12, Fail: 0" or lists the failed test cases. Verification personnel use this information to determine the functional correctness of the chip design under different parameter combinations.

[0085] This disclosure applies to typical software environments (Linux / Unix workstations or server clusters) and hardware emulation accelerators for chip design verification. Verification personnel run the implementation script of this method in an environment equipped with an emulator, regression scripts, and version control tools. After outputting the regression list, the regression script can execute each test case locally in sequence (suitable for a small number of test cases or the debugging phase), and then submit it to a job scheduling system (such as LSF, SGE, PBS) for parallel distributed regression (suitable for large-scale combinations, significantly shortening the total verification time), and integrate it into a continuous integration (CI) pipeline, automatically triggering full-combination regression after code submission.

[0086] This embodiment achieves seamless integration between the regression list and regression test execution. Users only need to run a single command to complete fully automated verification of all parameter combinations, eliminating the need for manual simulation initiation. Furthermore, the regression list file can be included in version control, ensuring the repeatability and traceability of test results. The fixed test case order facilitates quick identification of failed test cases. Verification engineers do not need to concern themselves with the specific calling methods for each parameter combination; they only need to maintain the configuration file to achieve a fully automated regression process. In summary, this step directly applies the regression list generated in the previous steps to chip regression testing, forming a complete automated method from "parameter configuration" to "full combination verification," improving verification efficiency and coverage.

[0087] Figure 2 This is a flowchart illustrating a chip verification method according to another exemplary embodiment of this disclosure. Figure 2 As shown in the embodiments of this disclosure, a chip verification method may further include the following steps: Step 121: Read the configuration file and extract the combination patterns of each first parameter from the configuration file according to the preset data structure.

[0088] In this step, data is read from the configuration file, and each first parameter combination pattern is extracted according to a preset data structure. The first parameter combination pattern is a user-defined, independent unit containing parameter names and their corresponding values. Subsequent processing will generate parameter value lists and full combinations based on these first parameter combination patterns. This process converts the configuration file into structured data in memory, forming the basis for subsequent parsing and combination operations.

[0089] In one specific embodiment of this disclosure, the configuration file may be stored in a lightweight data exchange format (such as JSON). A script (e.g., a Python script) opens the configuration file using a built-in file reading function (such as open()) and converts the file content into an in-memory data structure using a corresponding format parser (such as json.load()).

[0090] The preset data structure is the agreed-upon format for organizing data in the configuration file. In a preferred embodiment of this disclosure, the configuration file is an array, and each element in the array can be an object. Each object represents a first parameter combination pattern. The key inside the object is the parameter name, and the value corresponding to the key is a string containing one or more parameter values, separated by commas. For example: { "a": "2, 3", "b": "4, 5"}, { "ccl_mode": "fast, safe", "ccl_level": "1, 2"} In addition to the JSON array structure mentioned above, the default data structure can also take other forms, such as: YAML format: Represented in list and map structures, it yields similar data organization after parsing; Direct array format: Values ​​are directly represented as JSON arrays instead of comma-separated strings, for example: { "a": [2, 3],"b": [4, 5]}; Key-value pair top-level object: The configuration file itself is an object, and each key-value pair corresponds to a first parameter combination pattern. The value can be an object or an array.

[0091] Regardless of the specific format used, the essence of the preset data structure is to be able to distinguish at least one first parameter combination pattern. Within each pattern, the parameter name and the parameter value corresponding to the parameter name can be obtained (the original representation form is not limited). This disclosure does not limit this.

[0092] One implementation approach is to use a script to iterate through the parsed memory objects of the configuration file according to a predefined data structure. For a JSON array structure, the script iterates through each element (i.e., each object) in the array, treating each object as a single first-parameter combination pattern. During extraction, there is no need for deep recursion within the object; only the correspondence between parameter names and the original parameter strings (or arrays) needs to be preserved for use in subsequent sub-steps. If the configuration file uses other predefined structures (such as a top-level object), the script must extract the data according to agreed-upon rules (e.g., all direct child objects of the object are first-parameter combination patterns).

[0093] This embodiment enables automatic reading and structured extraction of configuration files. It can understand user-written configuration files without manual intervention and convert them into internally operable data structures, laying the foundation for subsequent splitting and combination operations. The use of a preset data structure in the form of an array allows users to define unrelated parameter groups separately, avoiding invalid parameter overlaps, while enhancing the flexibility and readability of the configuration.

[0094] Step 122: For any first parameter combination pattern, split the parameter value corresponding to each parameter name in the first parameter combination pattern to obtain a list of parameter values ​​corresponding to each parameter name.

[0095] In this step, for each combination of the first parameters, the parameter values ​​corresponding to the parameter names (e.g., originally strings containing multiple values) are split to obtain a list of parameter values ​​for each parameter name (e.g., the string "2, 3" is converted into the list [2, 3]). This step converts the parameter values ​​from a user-friendly, compact string format into a machine-readable list format, preparing input data for the subsequent Cartesian product operation.

[0096] As one embodiment, step 122 can be specifically implemented as follows: First, retrieve the parameter value corresponding to any parameter name. The parameter value is a first string containing at least one preset symbol. For example, the parameter value of bus_width is "8, 16, 32", where the comma is a preset symbol.

[0097] Then, the first string is split based on preset symbols to obtain at least one second string, which is a substring of the first string. For example, "8, 16, 32" is split by commas to obtain three substrings: "8", "16", and "32" (note that leading and trailing spaces may be included).

[0098] Finally, each second string is formatted and normalized, and all the processed second strings are combined into a list of parameter values ​​corresponding to the parameter name. For example, after removing leading and trailing spaces from the three substrings above, we get "8", "16", and "32", which are combined into a list [8, 16, 32] (numeric types can be preserved or converted to an appropriate type). If the parameter value contains special identifiers required by the ccl_ prefix, the normalization process may also include base conversion (such as converting binary b1111 to decimal 15), etc.

[0099] As another example, for complex value formats (such as mixed spaces in "8, 16, 32, 64"), regular expressions can be used to match numbers or other patterns for extraction, rather than relying solely on fixed delimiters.

[0100] In addition, after splitting and normalizing, type conversion (string to integer, floating-point number, boolean value) can be performed based on the characteristics of parameter name or parameter value, and legality verification (such as value range check) can be performed, with automatic alarms and skipping illegal values.

[0101] Continuing with the previous example, for the parameter `bus_width` in the first parameter combination pattern, its value is the string "8, 16, 32". Step 122 first obtains this string, detects that the comma is the default symbol, and splits the string into three substrings: "8", "16", and "32". Then, it removes leading and trailing spaces from each substring, obtaining "8", "16", and "32", and then combines them into a list [8, 16, 32]. Similarly, for the string "100M, 200M" of the parameter `freq`, it is split and normalized to obtain the list [100M, 200M].

[0102] For the parameter ccl_debug_mode in the second first parameter combination mode, its value is "off,verbose", which can be split into the list [off,verbose]; the value of the parameter ccl_log_level is "0,1,2", which can be split into the list [0,1,2]. At this point, each parameter name has a corresponding list of parameter values, providing standardized input for the Cartesian product operation in step 123.

[0103] This step enables an efficient conversion from a compact parameter string to a structured parameter value list. Users can input multiple parameter values ​​by separating them with commas, eliminating the need to write array syntax and reducing configuration difficulty. Automatic removal of spaces and empty values ​​and basic formatting improve configuration robustness. After converting the parameter values ​​into a list, subsequent Cartesian product operations can directly use these lists to achieve automated full combinatorial traversal.

[0104] Step 123: Perform a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination pattern to obtain a set of parameter value combinations, wherein the set of parameter value combinations is the second parameter combination pattern.

[0105] In this step, for all parameter value lists within the same first parameter combination pattern, a Cartesian product (complete cross-combination) operation can be used to generate all possible parameter value combinations. Each parameter value combination includes one parameter value for each parameter name in that pattern, and the entirety of these parameter value combinations constitutes the second parameter combination pattern. This ensures that the subsequently generated regression list covers all parameter combinations.

[0106] As one implementation of this disclosure, for the list of parameter values ​​in the same first parameter combination mode (such as the list of parameter a [2, 3], the list of parameter b [4, 5]), the Cartesian product operation can be performed according to the following steps: First, for each list of parameter values, extract one parameter value from each list, and then combine all the extracted parameter values ​​into a single parameter value combination according to a predetermined order of parameter names. For example, take 2 from list 'a' and 4 from list 'b', and combine them according to the parameter name order (a, b) to get (a=2, b=4).

[0107] Then, all generated parameter value combinations are stored in a set. The final set is the set of parameter value combinations, which is the second parameter combination pattern. For example, exhaustively listing all possible combinations yields four combinations: (a=2, b=4), (a=2, b=5), (a=3, b=4), and (a=3, b=5). The set of these four combinations is the second parameter combination pattern.

[0108] As other implementations of the embodiments of this disclosure, step 123 can also be implemented in the following ways, for example: (1) You can take a list of multiple parameter values ​​as input by calling the itertools.product function of a programming language (such as Python) (a function in the itertools module of the Python standard library used to calculate the Cartesian product of the input iterable object). This function returns an iterator of all combinations, which can then be converted into a set. (2) A recursive function can be used to process a list of parameter values ​​one by one, take a value from the list, and then recursively process the remaining list, combining the results when backtracking; (3) For a fixed number of parameters (such as 2 or 3), all combinations can be generated by writing multi-level for loops (e.g., for v1in list1: for v2in list2: ...). (4) When the total number of parameter combinations is extremely large (e.g., more than one million), in order to avoid occupying a large amount of memory at once, a generator (yield) can be used to generate parameter value combinations one by one, but not immediately stored in the set, and passed to the subsequent formatting steps as it is generated.

[0109] As another implementation, specific interfaces or channels can be provided during the combination process to allow users to define constraints (e.g., "if a=2, then b cannot be 5"). Constraints are checked in real-time during combination generation, retaining only combinations that meet the conditions. This achieves a filtered Cartesian product, but the resulting set of combinations is no longer all possible combinations, but only all valid ones. While reducing the number of combinations, the resulting combinations are more… Its core remains a generation framework based on the Cartesian product. For example, using the results from step 122, for the first parameter combination mode, we have obtained two parameter value lists: bus width [8, 16, 32] and clock frequency [100MHz, 200MHz]. Step 123 performs the Cartesian product operation according to the predetermined order of parameter names (first bus_width, then freq): Take 8 from bus_width and 100M from freq → combine (bus_width=8, freq=100M) Take 8 from bus_width and 200M from freq → combine (bus_width=8, freq=200M) Take 16 from bus_width and 100M from freq → combine (bus_width=16, freq=100M) Take 16 from bus_width and 200M from freq → combine (bus_width=16, freq=200M) Take 32 from bus_width and 100M from freq → combine (bus_width=32, freq=100M) Take 32 from bus_width and 200M from freq → combine (bus_width=32, freq=200M). Store these 6 combinations into a set to obtain the first second parameter combination pattern.

[0110] For the second first parameter combination mode, the parameter value list is ccl_debug_mode:[off, verbose] and ccl_log_level:[0, 1, 2]. After the Cartesian product, 6 combinations are obtained (such as (ccl_debug_mode=off, ccl_log_level=0) etc.), which constitute the second second parameter combination mode.

[0111] By following this step, the entire list of parameter value combinations can be automatically generated. The Cartesian product operation ensures that all possible combinations of parameter values ​​are generated, solving the problem of omissions caused by manual enumeration. The generated set of parameter value combinations has a clear structure and can be directly used as source data for the formatting step, achieving seamless integration.

[0112] Figure 3 This is a flowchart illustrating a chip verification method as another exemplary embodiment of this disclosure. Figure 3 As shown in the embodiments of this disclosure, a chip verification method may further include the following steps: Step 131: For each parameter value combination in the second parameter combination mode, generate corresponding test case fragments based on the parameter name and its corresponding parameter value in the parameter value combination according to the preset format rules.

[0113] In this step, for each parameter value combination in the second parameter combination mode, each parameter name and its corresponding parameter value are traversed. Based on whether the parameter name has a preset prefix (such as "ccl_"), different formatting rules are applied to generate test case fragments corresponding to that parameter name. These test case fragments will be assembled into complete test cases in subsequent sub-steps. This step achieves automatic adaptation of parameter output formats, enabling ordinary parameters and C model configuration parameters to generate different syntax forms recognizable by the regression script.

[0114] This step can be specifically implemented as follows: First, iterate through each parameter name and its corresponding value in the parameter value combination. For each parameter name, determine whether it has a preset prefix. In a specific embodiment of this disclosure, the preset prefix can be, for example, "ccl_". This prefix is ​​used to identify that the parameter belongs to the C model configuration parameter and requires special handling.

[0115] Then, in response to a parameter name having a preset prefix (e.g., the parameter name is ccl_debug_mode), a test case fragment corresponding to that parameter name is generated according to the first format. The specific rules for the first format could be, for example, removing the preset prefix from the parameter name, and then combining the prefix-removed parameter name with the parameter value using a preset identifier (e.g., "ccl") and an assignment operator (e.g., "+="). For example, if the parameter ccl_debug_mode takes the value 'off', removing the prefix 'ccl_' yields 'debug_mode', and the first format generates the fragment 'ccl+=debug_mode=off'. This format can be recognized by the regression script as a C model configuration parameter.

[0116] Furthermore, in response to a parameter name not having the preset prefix (e.g., the parameter name is bus_width or freq), a test case fragment corresponding to that parameter name is generated according to the second format. The specific rules for the second format can be, for example, directly combining the parameter name, assignment operator (e.g., "="), and parameter value. For example, if the parameter bus_width takes the value 8, the second format generates a fragment bus_width=8. This format can be used for common simulation parameters.

[0117] In this example, each parameter name in each combination of parameter values ​​generates a corresponding test case fragment. These test case fragments preserve the correspondence between parameter names and parameter values.

[0118] As another possible implementation scheme of this disclosure embodiment, the preset prefix is ​​not limited to ccl_, and users can customize the prefix (such as dut_, cfg_) in the configuration file or command line. Meanwhile, the string templates for the first and second formats can also be provided by the user. For example, the first format template is ${prefix}+=${key}=${value} (defining a format rule for converting parameters with preset prefixes into test case fragments, where ${prefix} is the preset identifier (e.g., "ccl"), ${key} is the parameter name after removing the preset prefix (e.g., removing "ccl_" from "ccl_mode" to get "mode"), and ${value} is the specific value of the parameter in the parameter value combination (e.g., "fast")). The second format is ${key}=${value}, where ${key} is the parameter name after removing the prefix. This enhances the adaptability of the scheme to different regression environments.

[0119] As another possible implementation scheme of this disclosure, it is not limited to a fixed prefix and supports regular expression matching (such as ^ccl_.* or ^debug_.*). The matched parameters adopt the first format, and the rest adopt the second format. This approach is more flexible. For example, all parameters starting with cfg_ can be classified as configuration parameters.

[0120] In addition, extra processing can be performed based on parameter name or parameter value type before generating test case fragments. For example, for numeric parameter values, units (such as MHz, ns) can be automatically added; for Boolean parameter values, they can be converted to on / off or 1 / 0; for number systems (such as binary b1111), the original format can be preserved or converted to decimal in the test case fragment.

[0121] As another implementation method, users can also define multiple different sets of preset prefixes, each corresponding to a formatting rule. For example, parameters starting with "ccl_" use format A, those starting with "dut_" use format B, and others use format C. This is suitable for complex verification environments where multiple different types of parameters (such as DUT parameters, C model parameters, and system environment parameters) coexist.

[0122] For certain parameter value combinations, if a parameter has a default value, the generation of that parameter fragment can be skipped (i.e., not output), simplifying the test case string. For example, if the default value of `bus_width` is 8, then the fragment will only be generated when `bus_width` is not equal to 8. This can reduce the length of the regression list and improve readability.

[0123] For example, continuing with the parameter value combinations generated in step 123, let's take one of the combinations in the first second parameter combination mode: "bus width = 8, clock frequency = 100MHz" (the parameter names do not have the ccl_ prefix). Step 131 iterates through the two parameters: For bus_width=8, if there is no preset prefix, generate the segment bus_width=8 according to the second format.

[0124] For freq=100M, there is no preset prefix, and the generated fragment freq=100M is also generated.

[0125] For the second parameter combination mode, one of the combinations is "C model debug mode=off, C model log level=0", with parameter names ccl_debug_mode and ccl_log_level respectively. Both have the preset prefix ccl_. For ccl_debug_mode=off, the prefix is ​​removed to get debug_mode, and the fragment ccl+=debug_mode=off is generated according to the first format. For ccl_log_level=0, the prefix is ​​removed to get log_level, and the fragment ccl+=log_level=0 is generated.

[0126] This step enables automatic adaptation of parameter output formats. Users do not need to distinguish between ordinary parameters and C model configuration parameters. The script automatically recognizes and generates the correct format, avoiding errors from manual writing. It also supports custom prefixes, format templates, and condition generation, and can adapt to the syntax requirements of different regression scripts. When parameter types are added or deleted or format rules change, only the configuration or script rules need to be modified. There is no need to re-edit the regression list. The generated fragments conform to the parsing specifications of regression scripts, ensuring that subsequent splicing and outer encapsulation can be executed correctly.

[0127] Step 132: Identify all test case fragments belonging to the same parameter value combination as test cases for that parameter value combination.

[0128] In this step, for each combination of parameter values, all corresponding test case fragments can be combined into a complete test case string according to predetermined rules. This test case string is the smallest unit that the regression script can directly parse and execute. Specifically, this step determines the order between fragments (usually according to the predetermined order of parameter names), concatenates the fragments into a continuous string, and then adds preset strings (such as shell prefixes and suffixes) at specified positions to form the final usable test case.

[0129] Specifically, this can be achieved through the following steps: First, all test case fragments corresponding to the parameter value combination are simply concatenated according to a predetermined order of parameter names (e.g., the order in which parameters appear in the configuration file, alphabetical order, or user-defined order) to obtain a concatenated result (intermediate string). For example, for the parameter value combination (bus_width=8, freq=100M), the two generated fragments bus_width=8 and freq=100M are concatenated in a predetermined order (bus_width first, then freq) to obtain bus_width=8freq=100M (fragments are usually separated by spaces to ensure readability).

[0130] Then, a preset string is added to a preset position in the concatenated result to form a test case for the parameter value combination. In a specific embodiment of this disclosure, the preset positions are the front and back ends of the concatenated result: a preset prefix string CASE_BATCH( is added to the front end, and a preset suffix string is added to the back end). For example, adding a shell to the concatenated result bus_width=8freq=100M results in CASE_BATCH(bus_width=8 freq=100M). This format is the standard test case format agreed upon by internal regression scripts.

[0131] In this way, each combination of parameter values ​​is converted into a complete test case string that can be directly written into the regression list file.

[0132] In some embodiments, the preset string can be customized according to the requirements of the regression script, such as TEST_CASE, RUN, or even empty (i.e., without a shell). The string can also be added only to the front end or only to the back end.

[0133] In some embodiments, comments (such as # followed by text) can be added to the end or beginning of the test case string, for example, CASE_BATCH(bus_width=8 freq=100M) # First set of parameters. This helps with debugging and manual reading.

[0134] In some embodiments, different preset strings may be required for different parameter combination patterns in the regression script. For example, the common parameter combination uses CASE_BATCH(...), while the C model parameter combination uses CCL_BATCH(...). In this step, the preset string can be dynamically selected based on the parameter name characteristics contained in the parameter value combination (such as whether it contains the ccl_ prefix).

[0135] As another embodiment, if the regression script does not require the addition of a preset string, or if the preset string is already included in the test case fragment generation process, the step of adding the preset string can be skipped, and the concatenated result can be directly used as the test case.

[0136] For example, using the test case fragment generated in step 131, for a single parameter value combination (bus width = 8, clock frequency = 100MHz) in the first second parameter combination mode, step 132 first concatenates the two fragments bus_width=8 and freq=100M in the predetermined order of parameter names (bus_width first, freq second), adding a space in between to obtain bus_width=8 freq=100M. Then, CASE_BATCH( is added to the front and back of the concatenated result, finally generating the test case CASE_BATCH(bus_width=8 freq=100M). Similarly, for the second combination mode (C model debug mode = off, C model log level = 0), its fragments are ccl+=debug_mode=off and ccl+=log_level=0. Concatenating these results in ccl+=debug_mode=off ccl+=log_level=0. Adding a shell yields CASE_BATCH(ccl+=debug_mode=off ccl+=log_level=0). All generated test cases are collected sequentially to form the regression list.

[0137] This step enables automated assembly from fragmented parameter snippets to complete test cases, generating test case strings in a uniform format to ensure that regression scripts can be parsed correctly. It supports custom delimiters, shell strings, and concatenation order, adapting to the syntax requirements of various regression frameworks. Test case snippet generation (step 131) and assembly (step 132) are separated, and modifying the assembly rules does not affect the snippet generation logic, making it easy to maintain and extend.

[0138] Step 133: Determine the regression list based on the test cases corresponding to all parameter value combinations.

[0139] In this step, all test cases are collected, sorted, and organized into a final regression list file that can be directly read by the regression script. The regression list is essentially a text file, with each line corresponding to one test case. This step also allows appending metadata (such as the total number of test cases, generation time, etc.) to the file header or footer, and supports user-defined output filenames. Through this step, the final output, an executable regression list, is generated from a series of test cases.

[0140] Specifically, the test case strings generated by combining each parameter value in the second parameter combination pattern are collected sequentially into a list (or written directly to an output file). If the configuration file contains multiple independent first parameter combination patterns (i.e., multiple second parameter combination patterns), all test cases generated by each pattern are collected sequentially according to the order in which the patterns appear in the configuration file. Each test case occupies a separate line, the file is in plain text format, and the extension is usually, for example, .list. The file encoding should use UTF-8 or ASCII to ensure compatibility. In addition to .list files, other formats required by regression tools can also be output, such as YAM sequences, JSON arrays, XML, etc. Users can select the output format via command-line parameters.

[0141] In some embodiments, the output file has the same name as the input JSON configuration file (only the extension is changed to .list). For example, if the configuration file is named test.json, the default output will be test.list. The script also supports customizing the output filename via command-line arguments (such as --name), allowing users to specify any name (e.g., regression_full.list). Next, the script opens the target file (overwriting it if it already exists) and writes all collected test cases line by line, adding a newline character at the end of each line. The file is then closed after writing is complete. The script can also print statistics to the console, such as the total number of test cases: N.

[0142] In some embodiments, to facilitate traceability and debugging, a comment line (starting with #) can be added to the beginning of the file. This comment line may contain, but is not limited to, the generation time, the path to the input configuration file, the total number of test cases, and a parameter list. If the regression script supports skipping comment lines, these lines can be automatically ignored.

[0143] As an alternative implementation, in response to a very large number of test cases (e.g., exceeding 1 million), the regression list can be split into multiple smaller files, each containing a subset of test cases, to facilitate parallel execution or avoid making a single file too large. The filenames can include serial numbers, such as regression_part1.list, regression_part2.list, etc.

[0144] As an optional implementation, instead of temporarily storing all test cases during the test case generation process, each test case is generated and immediately written to a file, thereby saving memory.

[0145] As an optional embodiment, if the file size of the regression list is determined to be greater than a preset threshold, the regression list is compressed to output a compressed file (e.g., .gz), which is automatically decompressed when read by the regression script to save disk space.

[0146] As an alternative implementation, test cases can be sorted (e.g., alphabetically by parameter values) or randomly shuffled to increase the randomness of the regression, which helps to discover defects in the dependency order.

[0147] This embodiment enables the final output and management of regression lists. Users can obtain a list file that can be directly used for regression with one click without any manual editing, greatly improving efficiency. It also supports custom file names, output formats, and metadata annotations to meet the customization needs of different regression processes. For ultra-large-scale combination scenarios, it can be extended with features such as sharding, compression, and streaming writing. The output file can be included in version management to ensure the repeatability and traceability of the regression process. Furthermore, the output format is strictly consistent with the regression script's agreed format, allowing for seamless integration into existing regression processes without intermediate conversion.

[0148] In summary, by acquiring a configuration file containing at least one first parameter combination pattern, automatically parsing and generating a second parameter combination pattern consisting of complete cross combinations of all parameter values, and then generating a regression list and performing regression testing verification, this method replaces the arduous task of manually enumerating parameter values ​​and manually arranging combinations. It achieves full automation from user configuration to full combination generation, solving the problems of high workload, error susceptibility, and omissions associated with manual methods. Secondly, since the second parameter combination pattern covers all possible combinations of parameter values ​​(i.e., Cartesian products) of all parameter names in the first parameter combination pattern, it ensures that the functionality under any parameter combination is verified, thereby effectively addressing the explosion scenario of multi-parameter cross combinations and improving verification coverage. Thirdly, when parameters need to be added, removed, or their values ​​modified, users only need to adjust the configuration file to regenerate the regression list with one click, without manual intervention, greatly reducing maintenance costs and supporting rapid iteration. Furthermore, the embodiments of this disclosure seamlessly integrate parameter configuration, full combination generation, regression list output, and regression test execution, forming a complete automated verification closed loop, which improves regression testing efficiency while ensuring verification completeness.

[0149] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0150] Figure 4 This is a structural block diagram of a chip verification apparatus according to an exemplary embodiment of this disclosure. For details regarding the beneficial effects of this apparatus or the technical problems it solves, please refer to the descriptions in the methods corresponding to each apparatus, or to the descriptions in the invention summary; further details will not be repeated here.

[0151] like Figure 4 As shown, this disclosure also provides a corresponding chip verification device, which may include: The acquisition module 410 is used to acquire a configuration file, the configuration file including at least one first parameter combination mode, the first parameter combination mode including a parameter name and a parameter value corresponding to the parameter name; The parsing module 420 is used to parse the configuration file to generate a second parameter combination pattern based on the parameter name and the parameter value corresponding to each first parameter combination pattern. The second parameter combination pattern is a set of parameter value combinations obtained by completely cross-combining the parameter values ​​of the parameter names in the first parameter combination pattern. The regression test module 430 is used to generate a regression list based on the parameter value combination of the second parameter combination mode, so as to perform regression test verification on the chip design based on the regression list.

[0152] As an optional embodiment, the parsing module 420 includes: The file reading unit is used to read the configuration file and extract each of the first parameter combination patterns from the configuration file according to a preset data structure; The splitting processing unit is used to split the parameter value corresponding to each parameter name in any first parameter combination pattern to obtain a list of parameter values ​​corresponding to each parameter name. The arithmetic unit is used to perform a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination mode to obtain a set of parameter value combinations, wherein the set of parameter value combinations is the second parameter combination mode.

[0153] As an optional embodiment, the splitting processing unit includes: The parameter value acquisition subunit is used to acquire the parameter value corresponding to any parameter name, wherein the parameter value is a first string including at least one preset symbol; A segmentation processing subunit is used to segment the first string based on the preset symbol to obtain at least one second string, wherein the second string is a substring of the first string; The normalization processing subunit is used to perform format normalization processing on each second string and combine all the processed second strings into a list of parameter values ​​corresponding to the parameter name.

[0154] As an optional embodiment, the computing unit includes: The parameter value combination determination sub-unit is used to extract a parameter value from each parameter value list and combine all the extracted parameter values ​​into a parameter value combination according to a predetermined order of parameter names. The parameter value combination storage subunit is used to store all generated parameter value combinations into a set, thereby obtaining the set of parameter value combinations.

[0155] As an optional embodiment, the regression testing module 430 includes: The test case fragment generation unit is used to generate corresponding test case fragments according to preset format rules based on the parameter names and their corresponding parameter values ​​in each parameter value combination in the second parameter combination mode. The test case determination unit is used to determine all test case fragments belonging to the same parameter value combination as test cases for that parameter value combination. The regression list determination unit is used to determine the regression list based on the test cases corresponding to all combinations of parameter values.

[0156] As an optional embodiment, the use case fragment generation unit includes: Traverse sub-units to traverse each parameter name and its corresponding parameter value in the parameter value combination, and determine whether the parameter name has a preset prefix; The first generation subunit is used to generate a test case fragment corresponding to the parameter name in a first format in response to the parameter name having the preset prefix. The second generation subunit is used to generate a test case fragment corresponding to the parameter name in accordance with the second format in response to the parameter name not having the preset prefix.

[0157] As an optional embodiment, the test case determination unit includes: The splicing subunit is used to splice all test case fragments corresponding to the parameter value combination in a predetermined order of parameter names to obtain the splicing result; Add a sub-unit to add a preset string at a preset position in the splicing result to form a test case for the parameter value combination.

[0158] The chip verification device of this disclosure corresponds to the chip verification method embodiments described above in terms of specific implementation and beneficial technical effects. The relevant contents can be referred to each other, and will not be repeated here.

[0159] Below, for reference Figure 5This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0160] Figure 5 A block diagram of an electronic device according to an embodiment of the present disclosure is shown.

[0161] like Figure 5 As shown, the electronic device includes one or more processors and memory.

[0162] A processor can be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.

[0163] The memory can store one or more computer program products, and the memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor can run the computer program products to implement the chip verification methods of the various embodiments of this disclosure described above and / or other desired functions.

[0164] In one example, the electronic device may also include input devices and output devices, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0165] In addition, the input device may also include, for example, a keyboard, a mouse, etc.

[0166] This output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0167] Of course, for the sake of simplicity, Figure 5 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0168] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products, including computer program instructions that, when executed by a processor, cause the processor to perform the steps in the chip verification methods according to various embodiments of this disclosure as described in the foregoing portions of this specification.

[0169] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0170] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the chip verification methods according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0171] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0172] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0173] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0174] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0175] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0176] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0177] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0178] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A chip verification method, characterized in that, The method includes: Obtain a configuration file, the configuration file including at least one first parameter combination pattern, the first parameter combination pattern including a parameter name and a parameter value corresponding to the parameter name; The configuration file is parsed to generate a second parameter combination pattern based on the parameter name and the parameter value corresponding to the first parameter combination pattern. The second parameter combination pattern is a set of parameter value combinations obtained by completely cross-combining the parameter values ​​of the parameter names in the first parameter combination pattern. A regression list is generated based on the parameter value combination of the second parameter combination mode, and the chip design is verified by regression testing based on the regression list.

2. The method according to claim 1, characterized in that, The step of parsing the configuration file to generate a second parameter combination pattern based on the parameter names and corresponding parameter values ​​in each first parameter combination pattern includes: Read the configuration file and extract each of the first parameter combination patterns from the configuration file according to a preset data structure; For any first parameter combination pattern, the parameter value corresponding to each parameter name in the first parameter combination pattern is split to obtain a list of parameter values ​​corresponding to each parameter name. Perform a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination pattern to obtain a set of parameter value combinations, and the set of parameter value combinations is the second parameter combination pattern.

3. The method according to claim 2, characterized in that, For any given first parameter combination pattern, the parameter value corresponding to each parameter name in the first parameter combination pattern is split to obtain a list of parameter values ​​corresponding to each parameter name, including: Get the parameter value corresponding to any parameter name, wherein the parameter value is a first string including at least one preset symbol; The first string is segmented based on the preset symbols to obtain at least one second string, wherein the second string is a substring of the first string; Each second string is formatted and normalized, and all the processed second strings are combined into a list of parameter values ​​corresponding to the parameter name.

4. The method according to claim 2 or 3, characterized in that, The step of performing a Cartesian product operation on the list of parameter values ​​corresponding to all parameter names in the same first parameter combination pattern to obtain the set of parameter value combinations includes: For each list of parameter values, extract one parameter value and combine all the extracted parameter values ​​into a parameter value combination according to the predetermined order of the parameter names; All generated parameter value combinations are stored in a set to obtain the set of parameter value combinations.

5. The method according to any one of claims 1 to 3, characterized in that, The step of generating a regression list based on the parameter values ​​of the second parameter combination mode includes: For each parameter value combination in the second parameter combination mode, based on the parameter name and its corresponding parameter value in the parameter value combination, corresponding test case fragments are generated according to preset format rules. All test case fragments belonging to the same parameter value combination are identified as test cases for that parameter value combination; The regression list is determined based on the test cases corresponding to all combinations of parameter values.

6. The method according to claim 5, characterized in that, The process of generating corresponding test case fragments based on the parameter names and their corresponding values ​​in the parameter value combination, according to preset format rules, includes: Iterate through each parameter name and its corresponding parameter value in the parameter value combination, and determine whether the parameter name has a preset prefix; In response to the parameter name having the preset prefix, a test case fragment corresponding to the parameter name is generated according to the first format; If the parameter name does not have the preset prefix, a test case fragment corresponding to the parameter name is generated according to the second format.

7. The method according to any one of claims 5 or 6, characterized in that, The step of identifying all test case fragments belonging to the same parameter value combination as test cases for that parameter value combination includes: All test case fragments corresponding to this parameter value combination are concatenated in a predetermined order of parameter names to obtain the concatenation result; A preset string is added to a preset position in the splicing result to form a test case for the combination of parameter values.

8. A chip verification device, characterized in that, The device includes: The acquisition module is used to acquire a configuration file, the configuration file including at least one first parameter combination pattern, the first parameter combination pattern including a parameter name and a parameter value corresponding to the parameter name; The parsing module is used to parse the configuration file to generate a second parameter combination pattern based on the parameter name and the parameter value corresponding to each first parameter combination pattern. The second parameter combination pattern is a set of parameter value combinations obtained by completely cross-combining the parameter values ​​of the parameter names in the first parameter combination patterns. The regression testing module is used to generate a regression list based on the parameter value combination of the second parameter combination mode, so as to perform regression testing and verification on the chip design based on the regression list.

9. An electronic device, characterized in that, include: Memory, used to store computer program products; A processor for executing a computer program product stored in the memory, wherein when the computer program product is executed, it implements the method described in any one of claims 1-7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-7.

11. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-7.

Images