Parameter configuration method and device, electronic equipment and storage medium

Abstract

The invention relates to the field of chip verification, and discloses a parameter configuration method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a parameter randomization template, and analyzing the parameter randomization template to obtain a random variable and a weight; generating test commands and key data in different configuration modes by using the random variables and the weights; generating a configuration file and a command line based on the test command and the key data in different configuration modes; and calling a generation method according to the configuration file, endowing a value transmitted by the command line to the verification platform according to a dynamic random mode, integrating a packaging class on the verification platform based on the configuration file, and completing parameter configuration of the verification platform by utilizing corresponding random parameters. The problems that in traditional chip verification, parameter management is disordered, redundant scenes are too many, the coverage rate of atypical scenes is low, and verification efficiency is insufficient under complex constraints are solved.

Description

Technical Field

[0001] The present invention relates to the field of chip verification, and in particular to a parameter configuration method, device, electronic equipment and storage medium. Background Art

[0002] Traditional chip verification platforms mostly use the UVM (Universal Verification Methodology) framework, which builds a complete verification system including the design under test (DUT), the interface between the verification environment and the DUT, stimulus transactions (Sequence), drivers (Drivers), monitors (Monitors), reference models (Reference Models), and scoreboards (Scoreboards). When there are fewer verification parameters, the $valueplusargs method is usually used for parameter control and transmission, but this method has significant drawbacks. On the one hand, it lacks flexibility and is difficult to quickly adapt to diverse verification requirements; on the other hand, when faced with a large number of parameters, it is very easy to cause parameter management confusion and even omit some important joint verification scenarios, resulting in incomplete and unreliable verification results, which cannot meet the verification requirements of current complex chip designs.

[0003] Furthermore, chip design features are closely intertwined, and design flaws often hide in complex, interdependent scenarios. While random testing is widely used to uncover potential flaws, in actual verification, while typical scenarios effectively cover the basic functionality of the design, they generate a large amount of worthless, redundant verification, wasting computing resources and time. Furthermore, the lack of reasonable random probability settings in difficult-to-cover atypical scenarios makes it difficult to detect potential flaws in a timely manner. Summary of the Invention

[0004] In view of this, an embodiment of the present invention provides a parameter configuration method, device, electronic device and storage medium to solve the problems of chaotic parameter management, excessive redundant scenarios, low coverage of atypical scenarios and insufficient verification efficiency under complex constraints in traditional chip verification.

[0005] In a first aspect, an embodiment of the present invention provides a parameter configuration method, the method comprising:

[0006] Obtaining a parameter randomization template, and parsing the parameter randomization template to obtain random variables and weights;

[0007] Generating test commands and key data in different configuration modes using the random variables and the weights;

[0008] Generate configuration files and command lines based on test commands and key data in different configuration modes;

[0009] The generation method is called according to the configuration file, the value passed by the command line is assigned to the verification platform in a dynamic random manner, and the package class is integrated in the verification platform based on the configuration file, and the corresponding random parameters are used to complete the parameter configuration of the verification platform.

[0010] Furthermore, the parsing of the parameter randomization template to obtain random variables and weights includes:

[0011] Get the automation script;

[0012] The template content of the parameter randomization template is parsed using the automatic exchange method to obtain random variables and weights.

[0013] Furthermore, the generating of test commands and key data in different configuration modes by using the random variables and the weights includes:

[0014] Get the command generation rules corresponding to different configuration modes;

[0015] The command generation rules, the random variables and the weights are used to generate test commands and key data in different configuration modes.

[0016] Furthermore, the generating of test commands in different configuration modes using the command generation rule, the random variable, and the weight includes:

[0017] Obtaining a pre-constructed knowledge graph, wherein the knowledge graph is constructed by collecting random variables and their constraint relationships;

[0018] Analyzing the command generation rule, the random variable, and the weight using the knowledge graph to obtain a constraint relationship;

[0019] The test command is generated based on the constraint relationship and mode features of different configuration modes.

[0020] Furthermore, the configuration files and command lines are generated based on the test commands and key data in different configuration modes, including:

[0021] Obtain historical test commands and historical key data in different configuration modes;

[0022] Determining valid information that can be used to generate a configuration file using the historical test commands and the historical key data;

[0023] generating a parameter verification configuration file including two configurable overload modes based on the valid information;

[0024] The generated configuration file is combined with the existing test command using the preset format requirements, and the corresponding command line is generated according to the preset rules.

[0025] Furthermore, the calling of the generation method according to the configuration file and assigning the value passed by the command line to the verification platform in a dynamic random manner includes:

[0026] Instantiating a handle in the verification platform;

[0027] Determine the dynamic randomization mode and the rules for calling the generation method using the configuration file;

[0028] The generation method is called according to the rule through the handle, and the value of the command line is assigned to the verification platform in a dynamic random manner.

[0029] Furthermore, the instantiating of the handle in the verification platform includes:

[0030] Select and define a corresponding handle using the architecture of the verification platform;

[0031] Instantiating the selected handle according to a preset process in the verification platform to obtain a candidate handle, and verifying the candidate handle;

[0032] If the candidate handle passes verification, the candidate handle is used as the instantiated handle.

[0033] In a second aspect, an embodiment of the present invention provides a parameter configuration device, the device comprising:

[0034] An acquisition module is used to obtain a parameter randomization template and parse the parameter randomization template to obtain random variables and weights;

[0035] A configuration module, configured to generate test commands and key data in different configuration modes using the random variables and the weights;

[0036] Generate module, which is used to generate configuration files and command lines for test commands and key data in different configuration modes;

[0037] The processing module is used to call the generation method according to the configuration file, assign the value passed by the command line to the verification platform in a dynamic random manner, and integrate the encapsulation class in the verification platform based on the configuration file, and use the corresponding random parameters to complete the parameter configuration of the verification platform.

[0038] In a third aspect, an embodiment of the present invention provides an electronic device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, computer instructions being stored in the memory, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0039] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0040] The method provided in the embodiments of the present application has the following beneficial effects:

[0041] The method provided in the embodiment of the present application obtains parameter randomization templates and parses them to obtain random variables and weights, so that parameters can be managed in the form of structured templates, avoiding the management chaos caused by massive parameters in traditional methods. At the same time, the setting of weights can accurately control the random probability of different parameter combinations, effectively solving the problem of low coverage of atypical scenarios due to lack of reasonable random probability settings; using random variables and weights to generate test commands and key data under different configuration modes, targeted test scenarios can be flexibly generated according to diversified verification requirements, changing the disadvantage of insufficient flexibility of traditional methods, and can not only cover typical scenarios of basic functions, but also efficiently explore the complexities of potential design defects. Complex joint scenarios, reducing worthless redundant verification; generating configuration files and command lines based on test commands and key data, realizing the standardization and systematization of parameter configuration, ensuring that important joint verification scenarios are not missed, and improving the integrity and reliability of verification results; calling the generation method according to the configuration file, assigning the value passed by the command line to the verification platform in a dynamic random manner, and integrating the package class in the verification platform to complete the configuration using random parameters. This dynamic random parameter assignment method and the integration of the package class can efficiently complete the parameter configuration of the verification platform under complex constraints, optimize the use of computing resources and time, significantly improve verification efficiency, and meet the verification requirements of current complex chip designs. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0043] Figure 1 is a flow chart of a parameter configuration method according to an embodiment of the present invention;

[0044] Figure 2 is a schematic diagram of a parameter verification platform based on para_package according to an embodiment of the present invention;

[0045] Figure 3This is a schematic diagram of a dynamic randomization and management process based on config_db according to an embodiment of the present invention;

[0046] Figure 4 is a structural block diagram of a parameter configuration device according to an embodiment of the present invention;

[0047] Figure 5 FIG. 4 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0048] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present invention.

[0049] According to an embodiment of the present invention, a parameter configuration method, apparatus, electronic device, and storage medium are provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0050] In this embodiment, a parameter configuration method is provided. Figure 1 is a flow chart of a parameter configuration method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0051] Step S101: Obtain a parameter randomization template, and parse the parameter randomization template to obtain random variables and weights.

[0052] In this embodiment of the present application, the parameter randomization template package containing the para.sv, para_rand.sv, para_common.sv, para_db.sv, and para_lib.sv files is first imported. This template encapsulates basic functions such as parameter type parsing and random number generation. The verifier needs to customize the random variables prefixed with para_ and add primary control variables for the constraint variables (the enumeration types are divided into two categories: TYPICAL and IRREGULAR). At the same time, fill in the weight distribution table of each random variable in the config_cst.xls file. Subsequently, by running the automated Python script para_gen.py, the random variable definitions and weight tables in the template package are parsed, and the names, types, control enumeration values, and corresponding weight parameters of all random variables to be managed are extracted to form structured parameter configuration data, which provides basic input for the subsequent generation of test commands.

[0053] It should be noted that if Figure 2 Figure 2 shows a schematic diagram of a para_package-based parameter verification platform. Within the testbench environment, the parameter package (para_pkg) on the left contains modules such as the parameter parser (para_parser), parameter randomizer (para_rand), and parameter generator (para_gen), responsible for handling parameter-related operations. The sequence library (Seq_Lib) in the middle acts as a bridge, connecting the parameter package with the agent (Agent) on the right. The agent includes a monitor (Mon, used to receive data from the DUT), a driver (Drv, driving transaction information to the DUT port), and a sequencer (Sqr, organizing and managing sequences), enabling interaction with the design under test (DUT). The reference model (Referencemodel) below the testbench simulates the DUT's functionality and is used for data comparison during the verification process to ensure the accuracy of the DUT's functionality. Through the coordinated operation of various components, the entire platform achieves parametric verification of the DUT, ensuring its functional correctness under different parameter configurations.

[0054] The method provided in the embodiments of the present application effectively solves the problem of confusing parameter logic and difficult maintenance under traditional parameter management methods by importing a parameter randomization template package containing multiple core files, customizing random variables and weight distribution tables, and parsing and generating structured parameter configuration data with the help of automated Python scripts. The basic functions encapsulated in the template package standardize operations such as parameter type parsing and random number generation, avoiding the risk of manual configuration errors; the setting of customized random variables and control variables provides the possibility of flexible adjustment of verification scenarios; and the automated parsing of Python scripts not only significantly improves the efficiency of parameter extraction, but also ensures the accuracy and integrity of parameter data, providing a reliable foundation for the generation of subsequent test commands and ensuring orderly management even in complex parameter environments.

[0055] Step S102: Generate test commands and key data in different configuration modes using random variables and weights.

[0056] In an embodiment of the present application, based on the random variables and weights obtained by analysis, corresponding test commands are generated according to different configuration modes (orthogonal mode, random mode, directional mode): Orthogonal mode: set the maximum test command threshold, traverse the legal combinations of all random variables through the recursive function enum_all(), and generate an orthogonal test command sequence that covers the complete test set, ensuring non-redundant and comprehensive parameter combination verification. Random mode: use Python's numpy and pydantic libraries to establish an equivalent constraint relationship between random variables, dynamically generate random objects within the legal value range according to the weight table, and perform random balance checks through the built-in algorithm to avoid redundant scenarios and improve the coverage probability of atypical scenarios. Directed mode: directly generate specific test commands based on the fixed parameter values set by the user to meet the precise control requirements of specific parameters in directional testing. The test commands and associated random constraint data (such as weights, value ranges, control enumeration values and other key data) generated by the above process provide specific verification scenario inputs for subsequent configuration file generation.

[0057] It should be noted that if Figure 3 The figure shows a schematic diagram of the dynamic randomization and management process based on config_db. First, the constraint configuration (i.e., relevant constraint information) is read, followed by the GUI configuration. Branch processing is then performed based on mode judgment: if it is an orthogonal test, an enumeration test is performed to generate an orthogonal test sequence; if it is a directional test, a directional test command is directly generated; if it is a random test, a group balance check is performed before generating a random test group sequence. This process achieves dynamic randomization and management of parameters through judgment and processing in different modes, ensuring the comprehensiveness and effectiveness of the verification process, meeting the requirements of different test scenarios (orthogonal, directional, random), and improving verification efficiency and quality.

[0058] The method provided in the embodiment of the present application generates test commands and key data in three configuration modes: orthogonal, random, and directional, based on random variables and weights, significantly improving the flexibility and comprehensiveness of verification scenario generation. The orthogonal mode traverses random variable combinations through recursive functions, can cover all legal parameter combinations with a minimum test set, eliminate redundant tests, and efficiently verify chip functions; the random mode uses library functions to establish constraint relationships and perform random balance checks, and can dynamically generate test scenarios based on weights, which not only reduces repeated verification of typical scenarios, but also increases the coverage probability of atypical scenarios, accurately excavating potential defects; the directional mode meets the user's demand for precise control of specific parameters and is suitable for targeted testing. The three modes complement each other, meet diverse verification needs, ensure that the verification process is both comprehensive and efficient, and improve verification quality.

[0059] Step S103: Generate configuration files and command lines based on test commands and key data in different configuration modes.

[0060] In an embodiment of the present application, two types of core outputs are generated based on the generated test commands and key data for different configuration modes: Parameter verification configuration file: The random constraint library is exported in toml format, which contains complete parameter configurations such as random variable names, weights, value ranges, and control enumeration values, so as to facilitate the reproduction of specific verification scenarios during regression testing. Command line: Two overload modes, dist (dynamic random) and constant (constant value control), are provided. The format is make run set_config_string=\*usr_var,dist:xxx (or constant:xxx), where usr_var is strictly consistent with the name of the custom random variable, ensuring accurate mapping of command line parameters and verification platform variables. Through the above output, the abstract parameter configuration is converted into specific instructions and configuration files that can be directly executed in the verification platform, laying the foundation for the subsequent parameter injection into the verification platform.

[0061] The method provided in the embodiment of the present application realizes the standardization and executable nature of parameter configuration by converting test commands and key data into parameter verification configuration files in toml format and command lines in two overload modes. The configuration file fully records the parameter configuration information, which is convenient for rapid reproduction of specific verification scenarios during regression testing and ensures the repeatability of verification results; the two overload modes of the command line provide a flexible parameter input method, and through strict variable name mapping rules, ensure that the command line parameters and the verification platform variables accurately correspond to each other, avoiding parameter passing errors. This method of converting abstract parameter configuration into specific executable instructions and configuration files makes the verification process more standardized and efficient, reduces manual operation costs, and provides reliable protection for parameter injection into the verification platform.

[0062] Step S104, calling the generation method according to the configuration file, assigning the value passed by the command line to the verification platform in a dynamic random manner, and integrating the package class in the verification platform based on the configuration file, using the corresponding random parameters to complete the parameter configuration of the verification platform.

[0063] In an embodiment of the present application, the handle m_para of the para class is first instantiated in the verification platform, and its gen method is called: if the command line is in constant mode, the fixed value set by the user is directly captured and assigned to the corresponding parameter of the verification platform through the get() method of config_db; if it is in dist mode, the dynamic random logic inside the para class is triggered, and random parameter values are generated according to the weight table and constraint relationship in config_cst.xls. At the same time, the para_lib encapsulation class generated by para_gen.py is integrated into the verification platform. This class encapsulates custom random variables, control enumeration values, and the core methods of the para class (such as gen), and implements weight control of typical scenarios (TYPICAL) and atypical scenarios (IRREGULAR) through SystemVerilog's if constraints. Finally, the verification platform calls the corresponding random parameters through the para_lib class, completes dynamic randomization configuration or fixed value parameter injection, and realizes efficient parameter management and verification scenario generation.

[0064] The method provided in the embodiment of the present application realizes dynamic random configuration of parameters and fixed value parameter injection by instantiating the para class handle and calling its gen method on the verification platform, combined with the config_db and para_lib encapsulation classes. In constant mode, the fixed values set by the user are directly captured and assigned to meet the needs of directional testing; in dist mode, random parameter values are dynamically generated according to the weight table and constraint relationship to ensure the rationality and effectiveness of random testing. The para_lib encapsulation class integrates custom variables and core methods, and realizes scenario weight control through SystemVerilog's if constraints, simplifying parameter configuration operations. This method enables the verification platform to efficiently handle different types of parameter configuration requirements. Whether it is a dynamic random scenario or a fixed value test scenario, parameter configuration can be completed quickly, which significantly improves the parameter management efficiency and the flexibility of the verification platform, and accelerates the chip verification process.

[0065] In an embodiment of the present application, parsing the parameter randomization template to obtain random variables and weights includes: obtaining an automated script; and using the automated script to parse the template content of the parameter randomization template to obtain random variables and weights.

[0066] Specifically, first obtain the automated script para_gen.py and use it to parse the contents of the parameter randomization template, which contains the files para.sv, para_rand.sv, para_common.sv, para_db.sv, and para_lib.sv. The verifier has previously customized the random variables prefixed with para, added primary control variables for the constraint variables (enumerated into two categories: TYPICAL and IRREGULAR), and filled in the random weight distribution table config_cst.xls. After parsing, the random variables and weights are obtained.

[0067] In an embodiment of the present application, random variables and weights are used to generate test commands and key data under different configuration modes, including: obtaining command generation rules corresponding to different configuration modes; and using command generation rules, random variables and weights to generate test commands and key data under different configuration modes.

[0068] Specifically, we obtained command generation rules corresponding to different configuration modes (orthogonal, random, and directional). For orthogonal mode, we set a maximum test command threshold and called the recursive function enum_all() to retrieve all commands to be tested. For random mode, we used the numpy and pydantic verification libraries to establish equivalence constraints, generated random objects, and then performed random balance checks. For directional mode, we generated the required command lines based on the set values. Finally, we used these command generation rules, the parsed random variables, and their weights to generate test commands and key data for different configuration modes, such as random constraints and weights, providing a foundation for subsequent verification work.

[0069] In the embodiment of the present application, command generation rules, random variables, and weights are used to generate test commands in different configuration modes, including the following steps A1-A3:

[0070] Step A1: Obtain a pre-constructed knowledge graph, wherein the knowledge graph is constructed by collecting random variables and their constraint relationships.

[0071] Specifically, by building a knowledge graph, the scattered random variable definitions and their constraints are integrated into a structured model to provide comprehensive data support for subsequent test command generation. The implementation logic is as follows:

[0072] First, build a knowledge graph. From the parameter randomization template's code file (e.g., para.sv), identify all custom variables prefixed with para_ and extract their basic properties, including the variable name (e.g., para_addr), data type (e.g., 8-bit binary), variable type (dynamic random type para_dist or constant type para_const), and range. By parsing the constraints in the variable definition (e.g., inside{[0x10:0x30]}), determine the legal value range. Obtain scenario weights from the user-filled config_cst.xls weight table. For example, assign 70% and 30% weights to the typical and atypical scenarios for para_addr, respectively. Dependencies between variables are extracted, such as "When para_addr is 0xFF, para_cmd must be WRITE" to prevent invalid parameter combinations.

[0073] It should be noted that the variable node (VariableNode) records the basic information of the variable, such as name, type, value range, and the scenario types supported by the variable (such as belonging to both TYPICAL and IRREGULAR scenarios). The constraint node (ConstraintNode) corresponds to the exclusive constraints for each scenario, including the scenario name (such as IRREGULAR), weight value, special value range for the scenario (such as para_addr is limited to [0x10, 0x30] in atypical scenarios), and associated dependency conditions (such as mutually exclusive relationships with other variables). Edge definition: BELONGS_TO (belongs to) connects the variable node and the constraint node, indicating that a variable is subject to the rules of the constraint node in a specific scenario (for example, para_addr belongs to the corresponding constraint node in the IRREGULAR scenario); DEPENDS_ON (depends on) indicates the dependency relationship between variables. For example, a certain value of para_addr depends on the specific value of para_cmd, ensuring that the parameter combination conforms to the design logic.

[0074] Secondly, take the constraint extraction of the variable para_addr in the IRREGULAR scenario as an example: the association between para_addr and the IRREGULAR scenario is queried through the knowledge graph, and the weight (30%) and value range ([0x10, 0x30]) for this scenario are obtained. This information is used to guide the generation probability and value range of this scenario in random testing to avoid invalid randomness. When generating parameters, based on the IRREGULAR scenario value range recorded in the knowledge graph, the input value is checked to see if it is within the range [0x10, 0x30] to ensure that the generated parameters meet the scenario constraints. If the generated parameter combination includes para_addr = 0xFF (which exceeds the IRREGULAR scenario value range and belongs to another scenario), the knowledge graph will further check its dependency on para_cmd. If para_addr = 0xFF and para_cmd = READ are found to be mutually exclusive (i.e., they cannot appear at the same time), the system will automatically trigger resampling to avoid generating illegal test scenarios.

[0075] Step A2: Use the knowledge graph to analyze the command generation rules, random variables, and weights to obtain the constraint relationship.

[0076] Specifically, the command generation rules, random variables and weights are deeply analyzed through the knowledge graph, and the core constraint relationships that support different verification modes are extracted to ensure that the generated test commands meet the design logic and verification goals: the knowledge graph serves as the central knowledge base, integrating information such as variable definitions, scenario constraints, and dependencies, and providing support for command generation from multiple dimensions, including extracting basic variable constraints (such as obtaining the legal value range and the exclusive value domain of a specific scenario from the variable node, clarifying that the variable is a dynamic random type that needs to generate random values according to the rules or a fixed value type that directly uses a fixed value), scenario weights and probability distribution (extracting the weights of each scenario from the constraint node to calculate the generation probability under the random mode, and confirming the probability distribution of the generated command). To ensure the reasonable appearance of atypical scenarios), dependencies between variables (identifying the legitimacy of parameter combinations through dependency edges to avoid invalid scenarios); for different verification modes, the specific constraint analysis process is as follows: in random mode, the scenario weights are mapped to probability parameters and the legitimacy of random values are verified in combination with value range constraints to balance the coverage of high-frequency scenarios and the mining of low-frequency complex scenarios; in orthogonal mode, all possible parameter combinations are enumerated based on variable enumeration values and value ranges and the dependency is used to filter out redundant and conflicting combinations, thus controlling the test scale while ensuring completeness; in directional mode, the fixed value constraints set by the user are directly extracted, and the randomization process is skipped by precisely matching the variable node names to meet the precise reproduction requirements of specific scenarios.

[0077] Step A3: Generate test commands based on the constraint relationship and the mode features of different configuration modes.

[0078] Specifically, in orthogonal mode, the system uses the recursive function enum_all() to deeply traverse the legal parameter combinations of all variables based on the variable enumeration values (such as the legal values of para_addr are 0x10, 0x20, and 0xFF) and value ranges recorded in the knowledge graph. For example, for the combination of para_addr (three values) and para_cmd (two operations, READ and WRITE), 3×2=6 theoretical parameter combinations are generated. At the same time, combined with dependency edges (such as para_addr = 0xFF, para_cmd is only WRITE-only when para_addr = 0xFF), conflicting combinations (such as the invalid combination of 0xFF and READ) are filtered out, and finally an orthogonal command sequence containing 5 valid combinations is formed. To avoid computational overload caused by too many variables, the system sets a maximum test command threshold (such as 1000). When the number of combinations exceeds the threshold, non-critical combinations are truncated according to the variable priority (core function parameters marked by the user are given priority) to ensure that the core legal scenarios are covered with a minimum test set. In random mode, the system converts the scenario weights in the knowledge graph (such as the 30% weight of the IRREGULAR scenario) into a probability distribution model, and dynamically generates random parameter values within the legal value range of the variable through the numpy library. For example, for the IRREGULAR scenario of para_addr, a random value is generated with a probability of 30% in the exclusive value range [0x10, 0x30]. At the same time, through the built-in balance check algorithm, the frequency of occurrence of atypical scenarios in the last 100 generation results is counted. If the actual proportion (such as 25%) is lower than the set weight (30%), the subsequent generation strategy is automatically adjusted, and a certain proportion of atypical scenario parameters are forcibly inserted to ensure that the random results conform to the preset probability distribution, which not only reduces the redundant verification of typical scenarios, but also improves the coverage probability of complex scenarios. In directed mode, the system directly extracts fixed value constraints (such as para_timeout = 100) entered by the user via the command line from the knowledge graph. By strictly matching variable names (ensuring a one-to-one correspondence between usr_var and para_ prefixed variables), the fixed value is directly mapped to the target random variable, skipping the complex randomization process. For example, when a user needs to verify a specific function when para_addr = 0x10, directed mode will generate a test command containing only this fixed value, precisely controlling parameter values to meet the need to reproduce specific scenarios during the debugging phase or to verify known defect scenarios during regression testing. Throughout this process, the knowledge graph serves as the core hub, transforming abstract parameter configurations (such as weights, value ranges, and dependencies) into specific constraints that can be executed by each mode. Combined with the three characteristic rules of complete enumeration of orthogonal modes, dynamic balancing of random modes, and precise control of directed modes, this enables the automated generation of test commands for all scenarios, from high-frequency basic scenarios to low-frequency complex scenarios, and from comprehensive coverage to precise debugging. This effectively improves verification efficiency and the completeness of scenario coverage, while avoiding the inefficiency and blindness of traditional manual command generation.

[0079] The method provided in the embodiment of the present application obtains a pre-constructed knowledge graph, uses it to analyze command generation rules, random variables and weights, and generates test commands based on constraint relationships and configuration mode features, thereby significantly improving the accuracy and automation level of test command generation. The knowledge graph integrates random variables and their complex constraint relationships, providing comprehensive data support for test command generation, avoiding omissions or errors that may be caused by manual analysis; through in-depth analysis of command generation rules and parameters, it can accurately extract constraints such as dependency relationships between variables and weight probability distribution, ensuring that the generated test commands meet verification requirements. For different configuration modes, combined with the constraint information and pattern features of the knowledge graph, the automatic generation of test commands is achieved, reducing the workload of manually writing test commands, while ensuring the completeness of the test set in the orthogonal mode, the balance of the test in the random mode, and the accuracy of parameter control in the directional mode, effectively improving verification efficiency and verification quality.

[0080] In the embodiment of the present application, an enhanced random parameter generation method based on dynamic constraint analysis is further introduced, and the specific implementation process is as follows:

[0081] First, the weight distribution of each random variable is converted into a three-dimensional normalized probability matrix. This matrix uses the dimensions "total number of random variables," "number of control variable enumeration levels (typical / atypical scenarios)," and "number of possible values for each variable" to construct a three-dimensional weight management model. For example, for a system with three random variables, two scenarios (typical / irrelegular), and an average of five values per variable, the matrix size is 3×2×5. Within each scenario level, the weights of the variable values are normalized to ensure that the sum of the weights of all values within the same level is 1. For example, for the para_addr values [0x10, 0x20, 0x30] in an atypical scenario, if the user sets weights of 50, 30, and 20, they are normalized to 0.5, 0.3, and 0.2, making the probability distribution more statistically consistent. This modeling approach not only clearly distinguishes parameter priorities across scenarios but also provides standardized probability inputs for subsequent random sampling, avoiding imbalanced scenario coverage caused by improper weight settings.

[0082] Secondly, to handle complex dependencies between parameters, a constraint relationship topology graph is constructed, with random variables as nodes and dependencies as directed edges. Edge weights are calculated using a hybrid metric that incorporates three pieces of information: A range dependency indicator function: If the value range of variable A is constrained by the current value of variable B (e.g., para_addr must be nonzero when para_cmd = WRITE), the edge weight is increased to strengthen the constraint of this dependency; a historical data correlation coefficient: By analyzing frequently occurring parameter combinations in historical validation (e.g., para_addr = 0x10 and para_cmd = WRITE often co-occur), the association weight of these combinations is increased; and a weight product term: By multiplying the variable's own scenario weight with the dependency weight, the generation priority of core dependency combinations in high-frequency scenarios is prioritized. For example, when para_addr has an atypical scenario weight of 30% and a dependency weight of 20% with para_cmd = WRITE, the combined weight of the two is strengthened to 6% through product, significantly higher than less frequent, unrelated combinations. This modeling approach transforms implicit dependency logic into an explicit graph structure, providing clear constraint navigation for subsequent sampling algorithms and reducing invalid generation due to parameter conflicts.

[0083] Thirdly, in the parameter sampling stage, the improved Metropolis-Hastings (MH) algorithm is used for Markov chain Monte Carlo (MCMC) sampling: State chain initialization: Generate an initial parameter combination based on the three-dimensional probability matrix as the starting point of the Markov chain (such as the high-frequency parameter combination in a typical scenario); Candidate variable set selection: In each iteration, based on the edge weights of the topological graph, give priority to updating variables with strong dependencies and complex constraints (such as para_addr involving multiple dependency edges at the same time); Transition probability calculation: Combine the constraint satisfaction of the current state with the target distribution (the probability distribution of the three-dimensional matrix) to calculate the probability of transitioning from the current state to the candidate state. If the candidate state violates the dependency constraint (such as para_addr = 0xFF and para_cmd = READ), the transition probability is set to 0; State acceptance rate control: The acceptance rate formula (including the ratio of the weight distribution to the constraint satisfaction) is used to determine whether to accept the candidate state, ensuring that the stable distribution of the chain converges to a parameter combination that meets the weights and constraints. This improved algorithm guides the sampling direction through a topological map, avoiding the blindness of traditional random sampling. Especially when dealing with high-dimensional complex constraints, it can generate compliant parameter combinations with fewer iterations, thereby improving sampling efficiency.

[0084] Finally, to further improve generation efficiency under complex constraints, the method introduces a generative adversarial network (GAN) for collaborative optimization: The generator receives random noise and a constraint matrix (containing a three-dimensional probability matrix and topology information) and, through multi-layer neural network mapping, outputs potential parameter combinations. For example, given the input condition of "atypical scenario + high dependency constraint," the generator can specifically output combinations where para_addr = 0x15 (atypical value range) and para_cmd = WRITE (dependency satisfied). The discriminator performs a dual evaluation of the generated parameter combinations: checking whether the combination conforms to the probability distribution of the three-dimensional matrix (e.g., whether the proportion of atypical scenario combinations is close to 30%) and verifying whether the combination violates the dependencies in the topology (e.g., whether there are mutually exclusive variable values). Through adversarial training, the generator gradually learns how to generate parameter combinations that meet the target weight distribution while satisfying all constraints, while the discriminator continuously improves its ability to discern invalid combinations. The collaborative optimization of the two significantly reduces the constraint conflict rate, especially when dealing with nonlinear complex constraints (such as multi-variable linkage constraints). Compared with traditional sampling algorithms, it improves the generation efficiency and coverage of atypical scenarios.

[0085] In an embodiment of the present application, generating configuration files and command lines based on test commands and key data in different configuration modes includes the following steps B1-B4:

[0086] Step B1: Obtain historical test commands and historical key data in different configuration modes.

[0087] Specifically, we first use automated scripts (such as para_gen.py) to deeply analyze historical verification run logs and extract core data differentially for different configuration modes. In orthogonal mode, we extract all legal parameter combination records generated by recursive enumeration from the logs, such as the six theoretical combinations of para_addr (three values) and para_cmd (two operations) and the five filtered valid combinations. We also record the execution results of each combination (such as whether a defect is triggered). In random mode, we capture dynamically generated parameter values (such as para_addr = 0x15 for the IRREGULAR scenario), the corresponding weight distribution (such as a 30% weight for this scenario), and the probability calculation process during generation (such as a random seed generated using numpy), and correlate the defect discovery rate of this parameter combination in historical verification. In targeted mode, we extract fixed parameter values (such as para_timeout = 100) entered by the user through the command line, the target variable name (which must strictly match the para_ prefix), and the execution purpose of the targeted test (such as reproducing a specific functional defect). At the same time, data collection has been expanded to include external configuration files and template code. The weight configurations for each random variable in different scenarios (TYPICAL / IRREGULAR) are retrieved from config_cst.xls (e.g., para_addr's 70% weight for typical scenarios), ensuring consistency between historical data and the current weighting strategy. Basic attributes of custom random variables, including variable names (e.g., para_cmd), data types (e.g., enumerated types), and enumerated values for primary control variables (clearly distinguishing between typical and atypical scenarios), are parsed from the template package's SV file to ensure consistency between variable definitions in historical data and the current template. All extracted data is standardized and integrated into the historical dataset, forming a multidimensional data structure encompassing "variable definition - configuration mode - parameter values - weights - execution results." For example, a random mode record contains {"var_name":"para_addr","scene":"IRREGULAR","value":"0x20","weight":30%,"defect_found":true}, providing a unified and complete data source for subsequent data cleaning, weight optimization, and configuration file generation. This multi-source integrated historical data acquisition method not only avoids the inefficiency and omissions of manual data collection, but also ensures the seamless connection between historical experience and current verification needs, laying a solid foundation for improving the scenario reproduction capability and verification efficiency of configuration files.

[0088] Step B2: Utilize historical test commands and historical key data to determine valid information that can be used to generate a configuration file.

[0089] Specifically, we first use data cleaning technology to filter the legality of historical data, and use the pydantic verification library to build variable value range verification rules (such as defining the legal value range of para_addr as [0x00, 0xFF] and the enumeration type variable para_cmd only allowing READ / WRITE). Historical parameter combinations are scanned line by line, and illegal data containing invalid enumeration values (such as para_cmd = DELETE) or out-of-bounds values (such as para_addr = 0x100 exceeds the 8-bit binary range) are eliminated to ensure that the parameter combinations entering subsequent analysis meet the basic constraints of the variable definition. For orthogonal mode data, the system performs intelligent screening based on a preset maximum test command threshold (e.g., 1,000 commands), prioritizing parameter combinations that have triggered defects in historical verification (e.g., the combination of para_addr = 0xFF and para_cmd = WRITE once exposed a buffer overflow issue), and uses a recursive pruning algorithm to eliminate redundant combinations that only cover marginal functions (e.g., the combination of para_addr = 0x01 and para_cmd = READ has been repeatedly verified to be defect-free and has nothing to do with core functions). Ultimately, a "minimum complete test set" is formed, which reduces the test scale by 30%-50% while ensuring functional coverage. For random pattern data, statistical analysis tools calculate the frequency of occurrence of each parameter combination, identifying high-frequency redundant scenarios caused by uneven weight distribution (for example, the generation frequency of the typical scenario TYPICAL exceeds the preset weight by 20%, resulting in insufficient coverage of the atypical scenario IRREGULAR). Combinations with higher-than-average repetition rates are flagged (for example, para_addr = 0x10, para_cmd = WRITE appears 40 times out of 100 random runs, far exceeding the reasonable weight of 30%). Subsequent generation strategies are balanced by dynamically adjusting the weight distribution table (for example, increasing the weight of the IRREGULAR scenario from 30% to 40%). Specifically, the system deeply correlates historical test results with parameter combinations. For critical defects discovered in atypical scenarios (such as the timing conflict triggered by para_addr = 0x25, para_cmd = WRITE), the weight of the relevant variables in that scenario is automatically increased (for example, increasing the weight of the para_addr value in the IRREGULAR scenario from 20% to 35%), directing subsequent verification resources toward high-value scenarios. The entire analysis process not only purifies the noise information in historical data, but also transforms historical verification experience into quantifiable and effective information through defect-driven weight adjustment and scenario screening, ensuring that the generated configuration files can accurately focus on high-value test scenarios, significantly improving the defect discovery efficiency and resource utilization efficiency of subsequent verification.

[0090] Step B3: Generate a parameter verification configuration file containing two configurable overload modes based on the valid information.

[0091] Specifically, based on the valid information after cleaning and analysis, a structured parameter verification configuration file is generated in TOML format to achieve standardized integration of parameter definition, weight strategy and overload mode. The content is as follows:

[0092] The configuration file is based on the definition of random variables and clearly records the core attributes of each parameter: all variables are named with the prefix para_ (such as para_addr and para_cmd), and the type (dist dynamic random type or constant fixed value type) is clearly marked. For example, para_timeout is defined as a constant type and directly specifies a fixed value of 100; for dist type variables, the value range (such as the full range of para_addr is [0,255]) and the first-level control variable enumeration value (that is, the scenario type, such as both TYPICAL typical scenario and IRREGULAR atypical scenario) are further specified to form the basic constraint framework of the variable.

[0093] In the weight distribution module, weights are finely configured for dist-type variables based on the scenarios. For example, the TYPICAL scenario weight of para_addr is set to 70%, and the IRREGULAR scenario weight is set to 30%. This setting directly maps to the probability distribution of scenario generation in random testing. The weight value allows users to dynamically adjust it based on the historical defect discovery rate (for example, if a critical defect has been exposed in an atypical scenario, its weight can be increased to 40%), achieving precise control of the randomization process through clear numerical labeling.

[0094] Overload mode configuration provides two flexible parameter input methods: For the dist dynamic random parameter, the format *usr_var,dist:{"value1":weight1,"value2":weight2} is used. For example, *para_addr,dist:{"0x10":50,"0x20":30,"0x30":20} means that para_addr generates corresponding values with weights of 50%, 30%, and 20% during dynamic randomization, and the values are strictly limited to the value range defined by the variable; for constant fixed-value parameters, *usr_var,constant:value is used to directly specify a fixed value (such as *para_timeout,constant:100) to ensure absolute accuracy of parameter values in directional testing.

[0095] The hierarchical structure of the TOML format makes the configuration file highly readable and maintainable. Verifiers can directly view or modify variable definitions, weight ratios, and overloading rules through a text editor without relying on complex tools. At the same time, the configuration file seamlessly connects with historical valid information. For example, the high-frequency legal value range extracted from historical data and the weight distribution after defect-driven adjustment are all presented in standardized fields, providing a clear execution basis for subsequent command line generation and verification platform parameter injection, effectively solving the problems of scattered information and chaotic format in traditional parameter configuration, and significantly improving the standardization and reusability of the verification process.

[0096] Step B4: Combine the generated configuration file with the existing test command using the preset format requirements, and generate the corresponding command line according to the preset rules.

[0097] Specifically, the generated configuration file is combined with the existing test commands, and the corresponding command lines are generated according to the preset format requirements and rules to meet the testing requirements under different verification modes, while ensuring the balance of command line parameters, and exporting the results in TOML format for easy regression testing and reproduction.

[0098] In dist mode, this mode is used to process dynamic random parameters. The weight distribution in the TOML configuration file needs to be converted into a set_config_string parameter. The TOML file defines the weight distribution of each dynamic random variable in different scenarios (such as TYPICAL and IRREGULAR). For example, the para_addr variable has a weight of 70% in the TYPICAL scenario and 30% in the IRREGULAR scenario. When generating the command line, this weight information must be converted into parameters that conform to the set_config_string format so that the verification system can generate dynamic random parameters based on these weights. The constant mode is used to process fixed parameter values. Fixed values defined in the configuration file are directly mapped to the command line. For example, if the configuration file defines para_timeout = 100, this fixed value of 100 will be used directly in the command line.

[0099] The parameters in the configuration file are combined with historical test commands to generate a complete verification command sequence. Different configuration modes handle this step differently: In orthogonal mode, all valid commands are generated based on the parameter combinations in the configuration file. The recursive function enum_all() is used to iterate over all possible parameter combinations. For example, if the configuration file defines three valid values for the variable para_addr and two valid values for the variable para_cmd, the enum_all() function will generate six different parameter combinations and a corresponding verification command for each combination. In random mode, random parameter values are dynamically generated based on the weight distribution in the configuration file. These random parameter values are inserted into the historical test commands to generate a series of random verification commands. In targeted mode, the fixed parameter values defined in the configuration file are directly used and inserted into the historical test commands to generate verification commands tailored to specific scenarios.

[0100] Use the numpy library to verify the balance of command line parameters. In random mode, ensure that the probability of each parameter value matches the weight set in the configuration file. For example, if the configuration file sets the weight of para_addr in the IRREGULAR scenario to 30%, then the probability of the para_addr parameter value in the generated command line being in the IRREGULAR scenario should be close to 30%. Using the statistics function of the numpy library, you can analyze a large number of generated command lines to check whether the distribution of parameter values meets expectations. If imbalance is found, you may need to adjust the weight distribution or regenerate the command line.

[0101] The method provided in the embodiment of the present application obtains historical test commands and key data, determines valid information after cleaning and analysis, generates a parameter verification configuration file containing two overload modes based on this, and generates a command line in combination with preset rules, thereby realizing the optimization and reuse of parameter configuration. Extracting information from historical data avoids repeated configuration and improves resource utilization efficiency; cleaning and analyzing historical data, eliminating invalid data and dynamically adjusting weight distribution, so that the configuration file is more in line with actual verification needs, and improves the effectiveness of subsequent tests. The generated TOML format configuration file records the random variable definition, weight distribution and overload mode configuration in detail, which is easy to understand and maintain; the command line generated by preset rules ensures the accuracy and consistency of parameter passing, and the generated configuration file and command line support regression testing and scenario reproduction, which greatly enhances the standardization and traceability of the verification process, reduces verification costs, and improves the overall efficiency of verification work.

[0102] In the embodiment of the present application, a generation method is called according to a configuration file, and the value passed by the command line is assigned to the verification platform in a dynamic random manner, including steps C1-C3:

[0103] Step C1: instantiate the handle in the verification platform.

[0104] Specifically, in the UVM (Universal Verification Methodology) verification platform, core components (such as the env or test classes) are responsible for building and managing the verification environment. This step primarily utilizes the UVM factory mechanism to instantiate the para class handle m_para and parse command-line arguments. The detailed process is as follows: The UVM factory mechanism is a key feature of UVM, enabling dynamic class creation and configuration. In the env or test class, an instance of the para class is created using the type_id::create method and assigned to the m_para handle. After creating the para class instance, the cfgdb_override() method is called to parse the command-line arguments. Command-line arguments may include parameters in dist or constant mode, which can affect the values of random variables. The cfgdb_override() method uses the config_db#(string)::get() function to capture the command-line arguments. This function retrieves the specified parameter value from the UVM configuration database. After obtaining the parameters, the parameter type, random variable name, and value range are parsed. To avoid duplicate random variable names, the para_common::chk() method is called to check the uniqueness of random variable names. This method iterates over the para_pool queue to check for duplicate random variable names. If duplicate names are found, an error message is issued, ensuring that random variable definitions in the verification environment are unique.

[0105] Step C2, using the configuration file to determine the dynamic random method and the rules for calling the generation method.

[0106] Specifically, the configuration file in TOML (Tom's Obvious, Minimal Language) format contains important information such as parameter types, weight distribution, and value ranges. This information plays a key role in determining the value selection and generation rules of random variables. The following is a detailed operation process: Use a dedicated TOML parser to parse the configuration file to obtain information such as parameter types (dist or constant), weight distribution, and value ranges. The parsed information will be stored in the data structure of the verification platform for subsequent use. The verification platform will check the value of the type field in the configuration file and determine the calling rules based on different parameter types:

[0107] Dist type: If the value of the type field is dist, the dynamic randomization logic of the para_dist subclass is invoked. The para_dist subclass dynamically generates random values based on a weight distribution. For example, for para_addr, the weight distribution is "0x10":50, "0x20":30, "0x30":20. When generating random values, the probability of 0x10 appearing is 50%, the probability of 0x20 appearing is 30%, and the probability of 0x30 appearing is 20%. Constant type: If the value of the type field is constant, the value of the value field is used directly. For example, for para_timeout, its value is directly set to 100.

[0108] For parameters of the dist type, the key-value pairs in the weight field are converted to a probability distribution. For example, "0x10":50,"0x20":30,"0x30":20" is converted to a probability distribution of 50% for 0x10, 30% for 0x20, and 20% for 0x30. This allows random values to be generated based on these probabilities.

[0109] The pydantic library is used to check parameter values within the legal range. For example, for para_addr, the range is [0, 255], so the generated random value must be within this range. If the parameter value is outside the legal range, an error message will be issued to ensure the legality of the generated parameter value. Through these steps, the verification platform can determine the dynamic randomization method and the rules for calling the generation method based on the configuration file, ensuring that the generated random variables meet the configuration requirements.

[0110] Step C3: calling the generation method according to the rules through the handle, and assigning the value of the command line to the verification platform in a dynamic random manner.

[0111] Specifically, in the verification platform, the gen() method of the m_para handle is called. This method generates parameter values according to the rules specified in the configuration file. The configuration file contains key information such as the parameter type (such as dist or constant), weight distribution, and value range. The gen() method parses this information and generates corresponding parameter values based on the different parameter types.

[0112] Use the set method of uvm_config_db to pass the generated parameter values to various components of the verification platform, such as the env (environment class) and the agent (agent class). uvm_config_db is the configuration database in UVM (Universal Verification Methodology). It enables parameter sharing and synchronization between different components of the verification platform. This ensures that the generated parameter values are synchronized throughout the verification environment, ensuring that all components are tested using the same parameter configuration.

[0113] In dist mode, the para_dist subclass uses the NumPy library to generate random values that conform to a weight distribution. The specific operation is as follows: For each parameter of type dist, a random variable named dice is generated within the weight range [0, 100]. For example, for the parameter para_addr, its weight distribution is 0x10:50, 0x20:30, and 0x30:20. The corresponding parameter value is selected based on the range in which dice falls. If dice is in the range [0, 50), 0x10 is selected; if it is in the range [50, 80), 0x20 is selected; and if it is in the range [80, 100), 0x30 is selected. In the gen() method, the random.choice function of NumPy is used in conjunction with the weight distribution to generate random values. After generating random values, the pydantic validation library is used to check whether the generated values meet the constraints. For example, if the range of para_addr is [0, 255], the generated random values must be within this range.

[0114] In constant mode, the value in the configuration file is used directly. For example, if para_timeout = 100 is defined in the configuration file, the value of para_timeout is fixed to 100 during the verification process.

[0115] Command-line parameters (e.g., set_config_string = "*para_addr,dist:0x10:50,0x20:30,0x30:20") must be consistent with the parameter definitions in the configuration file. This means that the parameter names and types must match to ensure that the command-line parameters are correctly parsed and applied to the verification environment. In the gen() method, the command-line parameters are parsed and compared with the information in the configuration file. If any inconsistencies are found, an error message will be displayed.

[0116] Through SystemVerilog constraints encapsulated in the para_lib class, the weights of typical and atypical scenarios can be dynamically adjusted. For example, in an atypical scenario, the weight of IRREGULAR can be increased to 70%, increasing the probability of atypical scenarios and thus covering more complex test cases. This dynamic weighting approach allows the verification platform to more flexibly adapt to different test requirements, improving test comprehensiveness and effectiveness.

[0117] The method provided in the embodiment of the present application realizes efficient injection and flexible configuration of parameters in the verification platform by instantiating a handle in the verification platform, using a configuration file to determine the dynamic random method and calling rules, and assigning platform parameter values through the handle by calling the generation method according to the rules. The instantiated handle provides a carrier for parameter management and ensures the correctness of the handle and parameters through a strict verification mechanism; the configuration file is parsed to determine the dynamic random method and calling rules, so that the platform can automatically select the appropriate processing method according to the parameter type, thereby improving the flexibility of parameter configuration. By calling the generation method through the handle, the value of the command line is accurately assigned to the verification platform in a dynamic random or fixed value manner, and the synchronization of the parameters in the entire verification environment is achieved through uvm_config_db, ensuring the consistency and effectiveness of the parameter configuration. At the same time, through the dynamic adjustment of the scene weight by the encapsulation class, complex test cases can be better covered, significantly improving the adaptability and verification efficiency of the verification platform to different test scenarios.

[0118] In an embodiment of the present application, instantiating a handle in a verification platform includes steps C11-C13:

[0119] Step C11: Select and define a corresponding handle using the architecture of the verification platform.

[0120] Specifically, under the verification platform architecture based on the UVM framework, the choice of handle type needs to match the component communication and parameter management mechanism of the platform. As the core parameter management class, the para class inherits from uvm_object and is naturally adapted to the factory registration and configuration database (config_db) mechanism of UVM, which can realize the overloading of command line parameters and the encapsulation of randomization logic. In the core components of the verification platform (such as the environment class env or the test class test), the handle is defined by declaring param_para. This handle serves as the entry point for parameter management and carries core functions such as parsing command line parameters, executing randomization strategies, and synchronizing parameter configurations to various verification components. For example, this handle is defined in the build_phase stage of the test class so that its life cycle is synchronized with the verification platform, ensuring that it can be accessed by each component in the entire process of parameter configuration, and realizing unified management of dynamic random parameters and fixed value parameters.

[0121] Step C12: Instantiate the selected handle according to a preset process in the verification platform to obtain a candidate handle, and verify the candidate handle.

[0122] Specifically, the handle is instantiated by executing m_para=para::type_id::create("m_para") through the UVM factory mechanism. This method ensures that instances of the para class are correctly registered with the UVM component hierarchy, supporting subsequent parameter passing and callback function calls. After instantiation, the cfgdb_override() method is called to parse command-line arguments: config_db#(string)::get() is used to capture user-entered parameters (such as dist:para_addr=0x10-0x30@30% or constant:para_timeout=100) from the UVM configuration database. A string parsing algorithm is used to separate the parameter type (dist / constant), variable name (prefixed with para_), and range / weight information. Legal parameters are then stored in the para_pool queue. Para_common::chk() is then used to traverse the queue to check whether random variable names are unique (to avoid conflicts caused by misspellings such as para_addr and para_address). The verification process includes three checks: ① Whether the handle pointer is non-null (to ensure successful instantiation); ② Whether the usr_var in the command line completely matches the para_ prefix variable defined in the code (for example, para_addr cannot be written as Para_Addr); ③ Whether the parameter type is consistent with the definition in the configuration file (for example, generating random values for constant type variables is prohibited) to ensure the legality and consistency of the parameter input.

[0123] In step C13, if the candidate handle passes verification, the candidate handle is used as the instantiated handle.

[0124] Specifically, after the m_para handle passes instantiation and parameter parsing verification, it officially serves as the parameter management hub of the verification platform. When its gen() method is called, differentiation logic is executed based on the parameter mode: if it is in constant mode, the user-set fixed value is directly extracted from para_pool and injected into the target component of the verification platform (such as the driver or sequencer) through the set() method of uvm_config_db; if it is in dist mode, the dynamic random logic of the para_dist subclass is triggered. This generates a random number dice within the weight range defined in config_cst.xls (such as [0,100)). Based on the range that dice falls into (such as 0-50 for TYPICAL scenario), the parameter value corresponding to the value range is selected, and SystemVerilog constraints (such as if (scene == IRREGULAR) para_addrinside{[0x10:0x30]}) are used to ensure that the generated value meets the scenario constraints. The para_lib encapsulation class is also integrated. This class encapsulates the m_para handle and random parameters into a reusable interface, which is synchronized to each agent through UVM's virtualsequence mechanism, enabling weight control for typical and atypical scenarios. Ultimately, the verification platform uses this handle to dynamically randomize parameters or inject fixed values, ensuring that each verification component uses a unified parameter configuration, achieving efficient verification in complex scenarios.

[0125] The method provided in the embodiment of the present application selects and defines a handle according to the verification platform architecture, instantiates the handle and verifies it according to the preset process, and uses the verified handle as the final instantiation handle, which lays a solid foundation for the stable operation of parameter configuration in the verification platform. According to the platform architecture, the appropriate handle type is selected and defined to ensure the compatibility of the handle with the platform, so that it can effectively carry the parameter randomization and configuration management functions; strict instantiation and verification process, including operations such as capturing command line parameters, checking variable uniqueness, verifying parameter mapping and type matching, ensures the correctness of the handle instance and the accuracy of parameter transfer. The verified handle is used for parameter configuration, and the generation method can be flexibly called according to different parameter modes (constant or dist), and the scene weight control is realized in combination with the encapsulation class to ensure that the parameters are stably and efficiently dynamically randomized or injected into the verification platform, thereby improving the stability and reliability of the verification platform and ensuring the smooth progress of chip verification.

[0126] In this embodiment, a parameter configuration device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0127] This embodiment provides a parameter configuration device, such as Figure 4 Shown, including:

[0128] An acquisition module 41 is used to acquire a parameter randomization template and parse the parameter randomization template to obtain random variables and weights;

[0129] Configuration module 42, used to generate test commands and key data in different configuration modes using random variables and weights;

[0130] A generation module 43, used for generating configuration files and command lines from test commands and key data in different configuration modes;

[0131] The processing module 44 is used to call the generation method according to the configuration file, assign the value passed by the command line to the verification platform in a dynamic random manner, and integrate the package class in the verification platform based on the configuration file, using the corresponding random parameters to complete the parameter configuration of the verification platform.

[0132] Furthermore, the configuration module 42 is used to obtain command generation rules corresponding to different configuration modes; and generate test commands and key data under different configuration modes using the command generation rules, random variables, and weights.

[0133] Furthermore, the configuration module 42 further includes: an acquisition unit, an analysis unit, and a generation unit;

[0134] An acquisition unit, configured to acquire a pre-built knowledge graph, wherein the knowledge graph is constructed by collecting random variables and their constraint relationships;

[0135] An analysis unit, used to analyze command generation rules, random variables, and weights using a knowledge graph to obtain constraint relationships;

[0136] The generation unit is used to generate test commands based on the constraint relationship and mode features of different configuration modes.

[0137] In an embodiment of the present application, a generation module 43 is used to obtain historical test commands and historical key data under different configuration modes; use historical test commands and historical key data to determine valid information that can be used to generate a configuration file; generate a parameter verification configuration file containing two configurable overload modes based on the valid information; use preset format requirements to combine the generated configuration file with existing test commands, and generate corresponding command lines through preset rules.

[0138] In an embodiment of the present application, the processing module 44 is used to instantiate a handle in the verification platform; use a configuration file to determine the dynamic random method and the rules for calling the generation method; call the generation method according to the rules through the handle, and assign the value of the command line to the verification platform in a dynamic random manner.

[0139] In the embodiment of the present application, the processing module 44 further includes: a selection unit, an instantiation operation unit, and a determination unit;

[0140] A selection unit, used to select and define a corresponding handle using the architecture of the verification platform;

[0141] An instantiation operation unit, configured to perform an instantiation operation on the selected handle according to a preset process in the verification platform to obtain a candidate handle, and then verify the candidate handle;

[0142] The determination unit is configured to use the candidate handle as the instantiated handle if the candidate handle passes verification.

[0143] See also Figure 5 , Figure 5 is a structural diagram of an electronic device provided by an optional embodiment of the present invention, such as Figure 5 As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0144] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0145] The memory 20 stores instructions that can be executed by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0146] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created based on the use of an electronic device presented by a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0147] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0148] The embodiment of the present invention also provides a computer-readable storage medium. The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0149] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention. Such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A parameter configuration method, characterized in that: The method comprises: Obtaining a parameter randomization template, and parsing the parameter randomization template to obtain random variables and weights; Generating test commands and key data in different configuration modes using the random variables and the weights; Generate configuration files and command lines based on test commands and key data in different configuration modes; The generation method is called according to the configuration file, the value passed by the command line is assigned to the verification platform in a dynamic random manner, and the package class is integrated in the verification platform based on the configuration file, and the corresponding random parameters are used to complete the parameter configuration of the verification platform.

2. The method according to claim 1, characterized in that The step of parsing the parameter randomization template to obtain random variables and weights includes: Get the automation script; The template content of the parameter randomization template is parsed using the automatic exchange method to obtain random variables and weights.

3. The method according to claim 1, characterized in that The generating of test commands and key data in different configuration modes by using the random variables and the weights includes: Get the command generation rules corresponding to different configuration modes; The command generation rules, the random variables and the weights are used to generate test commands and key data in different configuration modes.

4. The method according to claim 3, characterized in that The generating of test commands in different configuration modes by using the command generation rule, the random variable, and the weight includes: Obtaining a pre-constructed knowledge graph, wherein the knowledge graph is constructed by collecting random variables and their constraint relationships; Analyzing the command generation rule, the random variable, and the weight using the knowledge graph to obtain a constraint relationship; The test command is generated based on the constraint relationship and mode features of different configuration modes.

5. The method according to claim 1, wherein The configuration files and command lines are generated based on the test commands and key data in different configuration modes, including: Obtain historical test commands and historical key data in different configuration modes; Determining valid information that can be used to generate a configuration file using the historical test commands and the historical key data; generating a parameter verification configuration file including two configurable overload modes based on the valid information; The generated configuration file is combined with the existing test command using the preset format requirements, and the corresponding command line is generated according to the preset rules.

6. The method according to claim 1, characterized in that The calling of the generation method according to the configuration file and assigning the value passed by the command line to the verification platform in a dynamic random manner includes: Instantiating a handle in the verification platform; Determine the dynamic randomization mode and the rules for calling the generation method using the configuration file; The generation method is called according to the rule through the handle, and the value of the command line is assigned to the verification platform in a dynamic random manner.

7. The method according to claim 6, characterized in that The instantiating of the handle in the verification platform includes: Select and define a corresponding handle using the architecture of the verification platform; Instantiating the selected handle according to a preset process in the verification platform to obtain a candidate handle, and verifying the candidate handle; If the candidate handle passes verification, the candidate handle is used as the instantiated handle.

8. A parameter configuration device, characterized in that: The device comprises: An acquisition module is used to obtain a parameter randomization template and parse the parameter randomization template to obtain random variables and weights; A configuration module, configured to generate test commands and key data in different configuration modes using the random variables and the weights; Generate module, which is used to generate configuration files and command lines for test commands and key data in different configuration modes; The processing module is used to call the generation method according to the configuration file, assign the value passed by the command line to the verification platform in a dynamic random manner, and integrate the encapsulation class in the verification platform based on the configuration file, and use the corresponding random parameters to complete the parameter configuration of the verification platform.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images