Parameter configuration method and device for chip verification, electronic equipment and medium

Abstract

This disclosure provides a parameter configuration method, apparatus, electronic device, storage medium, and program product for chip verification. Each parameter to be configured is instantiated as a parameter object, and its current value is initialized to a preset flag value to indicate random generation. Parameter configuration information is received through a preset unified interface, the current value of the corresponding object is updated, and the parameter value of the corresponding parameter to be configured is determined based on the comparison result between its current value and the preset flag value. Users only need to change a few parameters to switch working modes, solving the problems of cumbersome batch modification and poor reusability of multi-mode configurations, and improving the reusability and regression efficiency of verification test cases. The unified interface solves the problems of non-universality and inconsistency among various configuration methods. Using each parameter value as a configuration parameter for the chip algorithm functional module to drive simulation verification allows the verification environment to automatically generate a large number of random combination scenarios in the same process and allows for targeted control of key parameters, improving verification flexibility and efficiency.

Description

Technical Field

[0001] This disclosure relates to chip verification technology, and in particular to a parameter configuration method and apparatus, electronic device, storage medium, and program product for chip verification. Background Technology

[0002] In the verification of algorithm modules in video processing, image processing, and AI (Artificial Intelligence) acceleration, the modules involved include at least algorithmic functional modules (such as transform / quantization / entropy coding units in video codecs, denoising / sharpening / color conversion units in image signal processors, convolution / pooling / activation units in AI accelerators, or corresponding reference models / behavioral models used to verify the above hardware modules). These modules generally adopt a pipelined architecture design, that is, they are composed of multiple processing units connected in series, with the output of the previous unit serving as the input of the next unit. Under this architecture, there are often tight couplings and correlation constraints between the parameters of each module.

[0003] Overall, in related technologies, the verification of algorithm functional modules for pipelined architectures suffers from problems such as insufficient flexibility, weak constraints, inconsistent configurations, and difficulties in state switching, resulting in low verification efficiency, insufficient scenario coverage, and difficulty in maintaining regression test cases. Summary of the Invention

[0004] In view of the above-mentioned problems in related technologies, this disclosure provides a parameter configuration method and apparatus, electronic device, storage medium and program product for chip verification.

[0005] In a first aspect, this disclosure provides a parameter configuration method for chip verification, applied in a chip design verification environment, the chip design verification environment including at least one parameter to be configured, the method comprising: Each of the parameters to be configured is instantiated into a parameter object, the parameter object including a parameter name and a current parameter value, wherein the initial state value of the current parameter value is a preset flag value, the preset flag value is used to indicate that the parameter value is randomly generated; In response to receiving parameter configuration information through a preset unified configuration interface, the current value of the parameter of the corresponding parameter object is updated according to the parameter configuration information. The preset unified configuration interface supports at least two preset configuration methods. During the randomization of parameters in the chip design verification environment, for each parameter object, the parameter value of the corresponding parameter to be configured is determined based on the comparison result between its current parameter value and the preset flag value. The parameter value of each parameter to be configured is used as the configuration parameter of the algorithm function module in the chip design to drive the algorithm function module to perform simulation verification.

[0006] As an optional embodiment, the step of responding to receiving parameter configuration information through a preset unified configuration interface and updating the current value of the corresponding parameter object according to the parameter configuration information includes: The parameter configuration information is received through the preset unified configuration interface, wherein the preset unified configuration interface supports at least two of the following configuration methods: command line assignment, batch assignment of configuration files, and assignment within code, in order to configure the parameter configuration information; In response to receiving parameter configuration information from two or more configuration methods, the target configuration information is determined from the parameter configuration information received from the multiple configuration methods according to a preset priority rule; Update the current value of the parameter of the corresponding parameter object according to the target configuration information.

[0007] As an optional embodiment, the step of responding to receiving parameter configuration information from two or more configuration methods, and determining the target configuration information from the parameter configuration information received from the multiple configuration methods according to a preset priority rule, includes: Obtain the priority of each configuration method, compare the priorities of the two or more configuration methods, and obtain the comparison result; Based on the comparison results, the parameter configuration information of the configuration method with the highest priority among the two or more configuration methods is determined as the target configuration information.

[0008] As an optional embodiment, the format of the command line assignment includes a preset prefix symbol, a parameter name, and a parameter value, wherein the preset prefix symbol is used as the starting point, followed by the parameter name and the parameter value, and the parameter name and the parameter value are connected by a first preset separator. The format for batch assignment of configuration files includes a preset prefix symbol, a preset configuration keyword, a configuration file path, and assignment statements within the configuration file, wherein: it begins with the preset prefix symbol, followed by the preset configuration keyword and a second preset separator, and then the configuration file path; each line of assignment statements within the configuration file includes the preset prefix symbol, a parameter name, and a parameter value, and the parameter name and the parameter value are connected by the second preset separator; The format for assigning values ​​within the code is as follows: In the test code of the verification environment, the current value of the parameter object corresponding to the parameter to be configured is assigned using an assignment statement.

[0009] As an optional embodiment, during the randomization of parameters in the chip design verification environment, for each parameter object, the parameter value of the corresponding parameter to be configured is determined based on the comparison result between its current parameter value and the preset flag value, so that the parameter value of each parameter to be configured is used as the configuration parameter of the algorithm function module in the chip design to drive the algorithm function module to perform simulation verification, including: For each parameter object, the current value of the parameter in the parameter object is compared with the preset flag value; In response to the current value of the parameter being equal to the preset flag value, randomization processing is performed on the parameter to be configured corresponding to the parameter object to generate a random value, which is then used as the parameter value of the parameter to be configured. In response to the fact that the current value of the parameter is not equal to the preset flag value, the current value of the parameter is directly used as the parameter value of the parameter to be configured; The parameter values ​​of each parameter to be configured are output to the algorithm function module in the chip design as configuration parameters for the algorithm function module, so as to drive the algorithm function module to perform simulation verification according to the configuration parameters.

[0010] As an optional embodiment, the step of responding to the current value of the parameter being equal to the preset flag value by performing randomization processing on the parameter to be configured corresponding to the parameter object to generate a random value, and using the random value as the parameter value of the parameter to be configured, includes: In response to the current value of the parameter being equal to the preset flag value, a preset random constraint condition is obtained for any of the parameters to be configured. The randomized solver in the chip design verification environment is invoked to generate a random value that satisfies the randomized constraints, which is then used as the parameter value for the parameter to be configured.

[0011] As an optional embodiment, the method further includes: In response to the chip design verification environment including at least two levels of algorithm function modules, each configurable parameter in the at least two levels of algorithm function modules is identified, and the parameter pair to be linked is determined. The parameter pair to be linked includes the output parameters of the front-end module and the input parameters of the back-end module, or parameters with the same function in different modules. Obtain the preset linkage constraints of the parameter pair to be linked, wherein the preset linkage constraints are preset based on the data transmission relationship between the algorithm functional modules; The preset linkage constraint is added to the random constraint set of the chip design verification environment so that the random value obtained by randomizing the parameter to be configured satisfies the preset linkage constraint and the preset random constraint. The random constraint set includes the preset random constraint.

[0012] As an optional embodiment, the method further includes: In response to the received reset command, the current value of the parameter of each parameter object is restored to the preset flag value, so that the configuration parameter of each parameter object is restored to the random state.

[0013] A second aspect of this disclosure provides a parameter configuration apparatus for chip verification, applied in a chip design verification environment, the chip design verification environment including at least one parameter to be configured, the apparatus comprising: The parameter instantiation module is used to instantiate each of the parameters to be configured into a parameter object. The parameter object includes a parameter name and a current parameter value. The initial state value of the current parameter value is a preset flag value, which is used to indicate that the parameter value is randomly generated. The parameter update module is used to respond to receiving parameter configuration information through a preset unified configuration interface, and update the current value of the parameter of the corresponding parameter object according to the parameter configuration information. The preset unified configuration interface supports at least two preset configuration methods. The final value determination module is used to determine the parameter value of the corresponding parameter to be configured for each parameter object based on the comparison result between its current parameter value and the preset flag value during the randomization of parameters in the chip design verification environment. The parameter value of each parameter to be configured is used as the configuration parameter of the algorithm function module in the chip design to drive the algorithm function module to perform simulation verification.

[0014] As an optional embodiment, the parameter update module includes: The information receiving unit is used to receive parameter configuration information through the preset unified configuration interface, wherein the preset unified configuration interface supports at least two configuration methods among command line assignment, batch assignment of configuration files and assignment in code, to configure the parameter configuration information; A priority processing unit is used to determine target configuration information from the parameter configuration information received from two or more configuration methods in response to receiving parameter configuration information from two or more configuration methods, according to a preset priority rule. The parameter update unit is used to update the current value of the parameter of the corresponding parameter object according to the target configuration information.

[0015] As an optional embodiment, the priority processing unit includes: The priority comparison subunit is used to obtain the priority of each configuration method, compare the priorities of the two or more configuration methods, and obtain the comparison result. The configuration information determination subunit is used to determine the parameter configuration information of the configuration method with the highest priority among the two or more configuration methods as the target configuration information based on the comparison result.

[0016] As an optional embodiment, the format of the command line assignment includes a preset prefix symbol, a parameter name, and a parameter value, wherein the preset prefix symbol is used as the starting point, followed by the parameter name and the parameter value, and the parameter name and the parameter value are connected by a first preset separator. The format for batch assignment of configuration files includes a preset prefix symbol, a preset configuration keyword, a configuration file path, and assignment statements within the configuration file, wherein: it begins with the preset prefix symbol, followed by the preset configuration keyword and a second preset separator, and then the configuration file path; each line of assignment statements within the configuration file includes the preset prefix symbol, a parameter name, and a parameter value, and the parameter name and the parameter value are connected by the second preset separator; The format for assigning values ​​within the code is as follows: In the test code of the verification environment, the current value of the parameter object corresponding to the parameter to be configured is assigned using an assignment statement.

[0017] As an optional embodiment, the final value determination module includes: The comparison unit is used to compare the current value of the parameter in each parameter object with the preset flag value. A random unit is used to perform randomization processing on the parameter to be configured corresponding to the parameter object in response to the current value of the parameter being equal to the preset flag value, and generate a random value so as to use the random value as the parameter value of the parameter to be configured. The parameter value determination unit is used to directly use the current value of the parameter as the parameter value of the parameter to be configured in response to the current value of the parameter not being equal to the preset flag value. The verification unit is used to output the parameter values ​​of each parameter to be configured to the algorithm function module in the chip design, as the configuration parameters of the algorithm function module, so as to drive the algorithm function module to perform simulation verification according to the configuration parameters.

[0018] As an optional embodiment, the random unit includes: The constraint condition acquisition subunit is used to acquire a preset random constraint condition for any of the parameters to be configured in response to the current value of the parameter being equal to the preset flag value. The random solver subunit is used to call the randomized solver in the chip design verification environment to generate a random value that satisfies the randomized constraints, which is then used as the parameter value of the parameter to be configured.

[0019] As an optional embodiment, the device further includes: The linkage parameter determination module is used to respond to the chip design verification environment, which includes at least two levels of algorithm function modules, to identify each configurable parameter in the at least two levels of algorithm function modules, and to determine the parameter pair to be linked. The parameter pair to be linked includes the output parameters of the front-end module and the input parameters of the back-end module, or parameters with the same function in different modules. The linkage constraint condition acquisition module is used to acquire the preset linkage constraint conditions of the parameter pair to be linked. The preset linkage constraint conditions are preset according to the data transmission relationship between the algorithm functional modules. The condition addition module is used to add the preset linkage constraint conditions to the random constraint set of the chip design verification environment, so that the random value obtained by randomizing the parameter to be configured satisfies the preset linkage constraint conditions and the preset random constraint conditions. The random constraint set includes the preset random constraint conditions.

[0020] As an optional embodiment, the device further includes: The parameter reset module is used to respond to the received reset command and restore the current value of the parameter of each parameter object to the preset flag value, so that the parameter to be configured of each parameter object is restored to the state to be randomized.

[0021] 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 the method of any of the first aspects described above.

[0022] 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 the method of any one of the first aspects described above.

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

[0024] In this embodiment, each configurable parameter is instantiated as an independent parameter object, and a preset flag value is set for it to indicate the initial state of the current value. Combined with a unified configuration interface supporting multiple configuration methods and a randomization mechanism that determines the final parameter value based on the comparison between the current value and the preset flag value, users can arbitrarily specify the values ​​of one or more configurable parameters through the unified configuration interface. The current value of the specified parameter is updated to the specified value, and during randomization, the specified value is forced to be used because the current value is not equal to the preset flag value. Unspecified parameters retain their current values ​​as the preset flag value and are automatically randomly generated. This achieves parameter setting results where some parameter values ​​are specified and the rest are randomized, improving the flexibility of parameter configuration. Users only need to change the specified values ​​of a small number of parameters to switch the entire configuration. The system addresses the technical challenges of batch modification of parameters across different working modes, cumbersome and error-prone configuration, and the need to write multiple test cases with poor reusability for multi-mode configurations. This improves the reusability and regression efficiency of verification test cases. Simultaneously, it pre-defines a unified configuration interface with at least two configuration methods. Regardless of the user's chosen method, configuration information is received and the current value of the corresponding parameter object is updated through the same interface, resolving the issues of multiple configuration methods being independent, non-universal, and inconsistent. Finally, the final parameter values ​​of each configurable parameter are used as configuration parameters for the algorithm functional modules in the chip design, driving their execution of simulation verification. This allows the verification environment to automatically generate a large number of random combination scenarios within the same test process while allowing users to perform targeted control of key parameters, thereby improving the efficiency and scenario coverage sufficiency of chip design verification while ensuring coverage.

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

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

[0027] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a flowchart illustrating a parameter configuration method for chip verification, which is an exemplary embodiment of this disclosure.

[0028] Figure 2 This is a flowchart illustrating a parameter configuration method for chip verification, which is another exemplary embodiment of this disclosure.

[0029] Figure 3 This is a flowchart illustrating a parameter configuration method for chip verification, which is another exemplary embodiment of this disclosure.

[0030] Figure 4This is a structural block diagram of a parameter configuration apparatus for chip verification, which is an exemplary embodiment of the present disclosure.

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

[0032] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0033] The following description of at least one exemplary embodiment is merely illustrative and is not intended to limit the scope of this disclosure or its application or use.

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

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

[0036] This disclosure 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.

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

[0038] 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: Chip design verification environment: A software simulation platform used to perform functional verification of circuit modules or systems in chip designs (including but not limited to application-specific integrated circuits, field-programmable gate arrays, etc.). This environment includes, but is not limited to, components such as the module under test, reference model, stimulus generator, parameter configuration module, result comparator, and randomized solver, used to detect design errors before chip tape-out. The parameter configuration method for chip verification provided in this disclosure embodiment can run in this verification environment, configuring, randomizing, and applying linkage constraints to the parameters to be configured, and driving the algorithm functional module to perform simulation verification.

[0039] Parameters to be configured: In the chip design verification environment, these are variables that need to be assigned specific values ​​to drive the algorithm function modules to perform simulation verification, such as the configuration register values ​​of the algorithm function modules, mode selection signals, data bit width, image size, etc.

[0040] Parameter object: A software object generated after encapsulating the parameters to be configured. This object contains at least the parameter name and the current value of the parameter, and may further include functions such as reset method and initialization method. Each parameter to be configured corresponds to an independent parameter object instance.

[0041] Preset flag value: This is a pre-defined numerical value with a special meaning, used to identify the initial state of the parameter's current value. When the parameter's current value equals the preset flag value, it indicates that the parameter to be configured needs to have its final value randomly generated; when the parameter's current value does not equal the preset flag value, it indicates that the parameter to be configured has been specified by the user, and its current value should be used as the final value. This preset flag value is usually selected as a value outside the legal range of the parameter to be configured to avoid conflicts.

[0042] Preset unified configuration interface: In the chip design verification environment, this is a unified entry point for receiving parameter configuration information, supporting at least two configuration methods: command line, configuration file, and in-code assignment. This preset unified configuration interface processes configuration information from different methods and then updates the current value of the corresponding parameter object.

[0043] Command line assignment: In the command line that starts the simulation verification, the parameter value of the parameter to be configured is specified in a specific format (e.g., starting with a preset prefix symbol, followed by the parameter name and parameter value).

[0044] Batch assignment of configuration files: Write multiple command-line format assignment statements into a text file (i.e., configuration file), and then specify the path of the configuration file in the simulation command line to achieve batch parameter configuration.

[0045] Assignment within code: In the test code of the chip design verification environment, the current value variable of the parameter object corresponding to the configuration parameter is directly assigned using assignment statements.

[0046] Randomization: In a chip design verification environment, this is the process of generating random values ​​for the parameters to be configured that satisfy preset constraints. This process is typically performed by a randomization solver (such as the constraint solver in SystemVerilog) based on predefined random constraints.

[0047] Random constraints: rules that restrict the range or relationship of random values ​​of the parameters to be configured, such as the parameter values ​​must be within a certain range, or the parameters must be equal or have a size relationship.

[0048] Linkage constraints: In pipelined or multi-module architectures, these are the relationships between parameters of different algorithm functional modules, used to ensure the consistency of parameters or the legality of data transfer between modules. For example, the output parameters of a preceding module must be equal to the corresponding input parameters of a subsequent module, or the values ​​of parameters with the same function in different modules must remain consistent.

[0049] Reset instruction: A command or function call used to trigger a reset operation. In response to a reset instruction, the chip design verification environment restores the current values ​​of all parameter objects to preset flag values, thereby restoring each parameter to be configured to a pending random state so that it can be reconfigured in the next round of verification.

[0050] The state to be randomized: This is the state where the current value of the parameter object is equal to the preset flag value, so that the final value will be randomly generated in the subsequent randomization process.

[0051] The technical solutions involved in the embodiments of this disclosure will be described in detail below.

[0052] Figure 1 This is a flowchart illustrating a parameter configuration method for chip verification, as an exemplary embodiment of this disclosure. Figure 1 As shown in the embodiments of this disclosure, a parameter configuration method for chip verification can be applied to or run in a chip design verification environment, which may include at least one parameter to be configured. The method may include the following steps: Step 110: Instantiate each parameter to be configured into a parameter object. The parameter object includes the parameter name and the current value of the parameter. The initial state value of the current value of the parameter is a preset flag value, which is used to indicate that the parameter value is randomly generated.

[0053] In this step, each configurable parameter (i.e., the variable that will later participate in randomization or assignment) in the chip design verification environment (hereinafter referred to as the verification environment) is objectified and encapsulated to generate an independent parameter object. A preset flag value is set as the initial state of the parameter's current value in the object to indicate whether the parameter needs to be randomly generated later. Specifically, raw variables (such as simple integer or string variables) in the traditional verification environment are replaced with objects containing parameter name attributes and storage units for the parameter's current value. The specific technical means to achieve this function include, but are not limited to, specific programming languages ​​or verification frameworks. In verification environments supported by languages ​​such as SystemVerilog, C++, and Python, classes or structs can be used. Any technical means that can allocate independent storage space for each configurable parameter, record the parameter name and current value, and support the initialization and subsequent modification of the current value are covered by this step.

[0054] Specifically, this step can be completed through the following operations: (1) Define a parameter object template: Pre-build a generic parameter wrapper class (e.g., named opts_object), which contains at least three members: parameter name (string type), current parameter value (generic type), and a default value for initialization. This template supports instantiation into different data types (such as integer, string, long integer, etc.); (2) Create an object instance for each parameter to be configured: In the configuration module or test case of the verification environment, for each parameter that needs to participate in randomization or configuration (e.g., the image width i_h_num of module A, the working mode mode of module B, etc.), use the above template to instantiate an independent parameter object; (3) Set initial state: Initialize the current value of each parameter object to a preset special value that cannot appear within the normal parameter value range (i.e., a preset flag value, such as 0xFFFF_FFFF for 32-bit or 0xFFFF_FFFF_FFFF_FFFF for 64-bit). The purpose of this special value is to serve as a random identifier. When the current value is equal to this special value, it means that the parameter has not yet been specified by the user and needs to be randomly generated later; when the current value is not equal to this special value, it means that the parameter has been specified by the user and the current value should be used as the final value later.

[0055] Through the above object-oriented encapsulation, each parameter object contains a parameter name identifier and a current value storage unit, thus providing a data structure foundation for subsequent unified configuration reception, randomization judgment, and reset operations.

[0056] The following example uses SystemVerilog to illustrate a specific implementation of step 110. It should be noted that those skilled in the art can implement the same functionality using other hardware verification languages ​​(such as C++, Python, etc.) or verification frameworks; this example does not constitute a limitation on the scope of this disclosure.

[0057] First, a generic parameter wrapper class `opts_object` is defined. This class contains at least the following members: parameter name (string type), current parameter value (generic type), and initial state value of the current value (generic type). This class provides an initialization function `init_set()`. Specifically, in this embodiment, the parameter wrapper class is designed to support parameterized classes of arbitrary data types and can inherit from the UVM sequence item base class. The parameter wrapper class includes at least the following member variables: a string parameter name used to match parameter identifiers in the command line or configuration file; a generic parameter current value; a generic initial value, set to a preset flag value in actual use; and a string parameter type flag indicating whether the current parameter is an integer or a string. Furthermore, the parameter wrapper class provides an initialization function that receives three input parameters: a parameter name string, a parameter type flag string, and an initial value (i.e., the preset flag value). Internally, the function saves the input parameter name, type flag, and initial value to their respective member variables and assigns the current parameter value to the initial value, thereby initializing the current parameter value to the preset flag value. This initialization function is called after the parameter object is instantiated.

[0058] Then, in the verification environment or test case, instantiate an `opts_object` object for each parameter to be configured and call `init_set()` to initialize the current value to a preset flag value (e.g., 'hFFFF_FFFF'). Example code is as follows: After defining the parameter object class as described above, you need to create an independent parameter object instance (e.g., an `opts_object` object) for each configurable parameter in the verification environment or test case, and initialize its current value to a preset flag value. The following code example shows how to instantiate parameter objects and perform initialization operations for four configurable parameters of module A and module B (the input width of module A, `a_i_h_num`, the working mode of module A, `a_mode`, the input width of module B, `b_i_h_num`, and the working mode of module B, `b_mode`). First, declare four parameter object variables using the `opts_object#(int)` template, where `#(int)` indicates that the data type stored in the parameter object is integer. Then, allocate actual object storage space for each variable by calling the `new()` constructor. Finally, call the `init_set()` function of each object, passing in three parameters: parameter name (a string used to match identifiers in the command line or configuration file), parameter type flag (here, "int", indicating integer), and preset flag value (e.g., 'hFFFF_FFFF,' which serves as the initial state of the parameter's current value and indicates that the parameter needs to be randomly generated later). After these initialization operations are completed, the val member of each parameter object is equal to the preset flag value, indicating that it has not yet been specified by the user and is in a state of waiting for randomization.

[0059] For example, in the verification environment or test case, first declare a parameter object variable for each parameter to be configured: for example, declare an integer parameter object named "a_i_h_num_obj" for the input width parameter of module A, declare an integer parameter object named "a_mode_obj" for the working mode parameter of module A, declare an integer parameter object named "b_i_h_num_obj" for the input width parameter of module B, and declare an integer parameter object named "b_mode_obj" for the working mode parameter of module B. Subsequently, during the initialization phase before the constructor or simulation runs, each object is instantiated (by calling the constructor to create an object instance) and initialized sequentially: the "new" method (used to create an object instance and allocate storage space for it) is called to allocate storage space for each object, and then the "init_set" method (an initialization function used to set the name, type flag, and initialize the current value to a preset flag value) of each object is called, passing in three parameters—the parameter name string (e.g., "a_i_h_num"), the parameter type flag string (both are "int" here), and the preset flag value (e.g., a 32-bit hexadecimal number "hFFFF_FFFF"). This operation sets the current value of the parameter object to the preset flag value, indicating that the parameter is initially in a state awaiting randomization.

[0060] It should be noted that the parameter name string mentioned above (such as "a_i_h_num") should be consistent with the identifier used in subsequent command lines or configuration files to ensure that the configuration information can be correctly matched to the corresponding parameter object.

[0061] As an alternative implementation, in a pure C++ chip verification framework, the template class Parameter can be used. <t>The constructor receives parameter names and default flag values, and manages all parameter object instances through the std::map container.

[0062] As an alternative implementation, in a Python-built validation environment, decorators or metaclasses can be used to automatically convert class attributes into parameter objects and set flag values ​​to None or specific constants.

[0063] As another implementation, in UVM (Universal Verification Methodology), opts_object can be derived from uvm_object, and UVM's factory mechanism can be used for unified management.

[0064] This embodiment objectifies each configurable parameter and initializes it with a preset flag value, achieving a binding between the parameter and its name. Each parameter object stores not only its current value but also its name and initial flag value, allowing it to correspond to external configuration information in command lines and configuration files without requiring manual maintenance of a mapping table between parameter names and variables. Furthermore, the preset flag value provides a unified standard for determining randomness. The verification environment only needs to check if the parameter object's current value equals the flag value to determine the subsequent processing path (random generation or forced specification). This flag value can be flexibly selected to avoid the legal value range of different data types. Moreover, developers only need to write one line of instantiation and initialization code for each configurable parameter, without needing to worry about parameter value storage, parsing, and reset logic. When the number of parameters is large, the amount of code for this object-oriented encapsulation is significantly lower than traditional methods. In summary, this step provides a data structure foundation. By encapsulating the configurable parameters into parameter objects containing parameter names and preset flag values, it lays the necessary groundwork for subsequent implementations of partial specification, randomization of the remainder, a unified configuration interface, linkage constraints, and reset operations.

[0065] Step 120: In response to receiving parameter configuration information through the preset unified configuration interface, update the current value of the parameter of the corresponding parameter object according to the parameter configuration information. The preset unified configuration interface supports at least two preset configuration methods.

[0066] This step establishes a unified mechanism for receiving and distributing parameter configuration information. This ensures that parameter configuration information from different sources (including but not limited to command lines, configuration files, and test code) can be transmitted to the corresponding parameter objects via a consistent path, thereby achieving decoupling and unification of configuration methods. The specific technical means to achieve this functionality are not limited to a particular programming language or verification framework. Any mechanism that can provide a unified configuration parsing entry point and map external input key-value pairs (parameter names and parameter values) to the current value of the corresponding parameter object can achieve the functionality of this step.

[0067] To implement the pre-defined unified configuration interface function, a unified configuration interface component can be provided. This component has at least the following functions: it can receive parameter configuration information from at least two configuration methods, including but not limited to command line, configuration file, or code assignment, and parse the received configuration information; it can provide an interface for querying the configuration value by parameter name for each parameter object; when the same parameter is configured in multiple ways, it can determine the final parameter value according to, for example, a pre-defined priority rule. As a specific implementation, this component can be encapsulated into an independent software package using, for example, SystemVerilog, and can be named, for example, "ccl_opts". Internally, this component can contain a data structure (such as an associative array or hash table) for storing the mapping from parameter names to configuration values, and provide external query functions (such as get_int and get_string). Those skilled in the art will understand that the above naming and specific implementation language are merely examples and do not constitute a limitation on the scope of this disclosure.

[0068] As one implementation, this step is accomplished through the following operations: First, a unified configuration interface can be pre-defined, that is, a global configuration parsing module (e.g., named ccl_opts) can be pre-built in the verification environment. This module can parse configuration information from sources including but not limited to command lines, configuration files, or code assignments, and provide a query interface for parameter objects to obtain their own configuration values. Then, during parameter object initialization, registration or association is performed. Specifically, each parameter object, during initialization (such as the init_set call in step 110), passes its parameter name and default value to the pre-defined unified configuration interface. This unified configuration interface returns the user-specified value based on the currently received parameter configuration information (command line or file), or returns the default value (i.e., the preset flag value) if no value is specified. Finally, the current parameter value is updated, that is, the parameter object stores the value returned by the unified configuration interface (if specified by the user) or the default flag value (if not specified) into its own current parameter value member, thus completing the update of the current value. In this way, the verification environment can process input from different configuration sources (or configuration methods) in a unified manner, while the parameter object does not need to care about the specific source or specific configuration method of the configuration information, but only needs to obtain the final parameter value from the unified interface.

[0069] As another implementation method, the current value of the parameter object can be updated through environment variable-based configuration. For example, in a verification framework built in C++ or Python, the parameter name and parameter value can be written into the operating system environment variable. The unified configuration interface obtains the parameter configuration information by reading the environment variable and maps the parameter name to the corresponding parameter object through a hash table to obtain the current value of the parameter.

[0070] As another implementation method, the unified configuration interface can support reading JSON or YAML format configuration files, parsing the key-value pairs, obtaining parameter configuration information, and updating the current parameter values ​​of the corresponding parameter objects through reflection or registry mechanisms.

[0071] As another implementation, standard command-line parsing libraries (such as getopt in C++ and argparse in Python) can be used to store the parsing results in a global configuration mapping table. When the parameter object is initialized, it queries the mapping table to find the configuration value (parameter value) of the parameter corresponding to the parameter name in order to update the current value of the parameter.

[0072] As another implementation method, in the UVM environment, the uvm_config_db mechanism can be used to pass configuration, write the parameter name and value (parameter value) into the configuration database, and the parameter object reads the configuration through uvm_config_db::get to update the current value of the parameter.

[0073] The following example illustrates this step using SystemVerilog and the aforementioned unified configuration interface component (e.g., named ccl_opts) to receive and distribute parameter configuration information. It should be noted that those skilled in the art can implement the same functionality using other hardware verification languages ​​or frameworks; this example does not constitute a limitation on the scope of this disclosure.

[0074] First, an implementation of a predefined unified configuration interface (e.g., named ccl_opts) is provided. This predefined unified configuration interface receives and distributes parameter configuration information. It may include two core query functions, for example: `get_int(string name, int default_val)`: This method retrieves the configuration value of an integer parameter. If configuration information for the parameter `name` exists in the environment (via command line or configuration file), it returns the configured value; otherwise, it returns the default value passed in. get_string(string name, string default_val): Used to retrieve the configuration value of a string parameter.

[0075] These two functions can support at least two configuration methods, such as: command-line assignment, batch assignment of configuration files, and assignment within code.

[0076] Then, for the parameter object, the parameter configuration information is obtained through the preset unified configuration interface to update the current value of the parameter. For example, within the `init_set` function of the parameter object `opts_object` in step 110, the interface of `ccl_opts` can be called to obtain the configuration value and update the current value of the parameter. The implementation of `init_set` can be as follows: the `init_set` function receives three input parameters: the parameter name, the type flag, and the initial default value (which is the preset flag value). Inside the `init_set` function, the passed parameter name, type flag, and initial default value are first stored in the object's own member variables. Then, a branch is determined based on the value of the type flag: if the type flag is "int" (representing integer), the integer parameter query function in the unified configuration interface component is called, passing in the parameter name and the initial default value, and the value returned by the function is assigned to the object's current value member variable; if the type flag is "string" (representing string), the string parameter query function in the unified configuration interface component is called, similarly passing in the parameter name and the initial default value, and the value returned is assigned to the object's current value member variable. Through the above operations, the init_set function enables the parameter object to obtain configuration values ​​from the unified configuration interface or retain default flag values.

[0077] Suppose that when the user specifies +a_mode=2 via the command line, the internal call to ccl_opts::get_int("a_mode", 'hFFFF_FFFF) in a_mode_obj.init_set will return 2. Therefore, a_mode_obj.val will be updated to 2 (no longer the default flag value). Unspecified parameters (such as a_i_h_num) will retain their default flag values, indicating that they will need to be randomly generated later.

[0078] In this embodiment of the disclosure, the preset unified configuration interface can support parameter configuration information from multiple preset configuration methods. In order to solve the problem that the parameter configuration information of any parameter to be configured comes from multiple preset configuration methods at the same time, the target configuration information can be determined according to the priority of the preset configuration methods and the priority rules. Alternatively, the target configuration information can be determined by the order in which the parameter configuration information is received, with the later received parameter configuration information overwriting the earlier received one. Or, when a conflict between multiple parameter configuration information is detected, the verification environment generates a warning or error, prompting the user to explicitly specify the parameter configuration information as the target configuration information in the test case.

[0079] Thus, by receiving parameter configuration information from at least two configuration methods, including but not limited to command line, configuration files, or code assignment, through a pre-defined unified configuration interface, and updating the current value of the corresponding parameter object based on the parameter configuration information, configuration information from different sources is processed uniformly, making different configuration methods equivalent. Users can flexibly choose the most convenient configuration method according to the scenario, solving the technical problems of various configuration methods being independent, non-universal, and inconsistent in traditional methods. Secondly, the unified configuration interface centrally encapsulates the configuration parsing logic. Parameter objects do not need to parse command lines or read files themselves; they only need to call the interface function to obtain their final configuration value, which can reduce the repetition and complexity of parameter configuration-related code. In addition, since the configuration information reception and the current value update of the parameter object are decoupled, the verification environment can re-call the interface at different time points (such as the processing interval between different frames) or dynamically switch the configuration mode by resetting and then specifying it again, providing a foundation for implementing specified configuration in one frame and random configuration in the next frame in subsequent steps.

[0080] Step 130: During the randomization of parameters in the chip design verification environment, for each parameter object, the parameter value of the corresponding parameter to be configured is determined based on the comparison result between its current parameter value and the preset flag value, so as to use the parameter value of each parameter to be configured as the configuration parameter of the algorithm function module in the chip design, so as to drive the algorithm function module to perform simulation verification.

[0081] In this step, the current parameter values ​​(which may be preset flag values ​​or user-specified values) are converted into actual parameter values ​​used by the algorithm's functional modules, achieving a mixed configuration effect of partially specified and the rest randomized. As one implementation method, when the verification environment initiates the randomization process (e.g., by calling the `randomize()` method), it iterates through all parameter objects, comparing the current parameter value of each object with the preset flag value. Based on the comparison results, it determines which parameters to be configured will undergo randomization and which will use the updated current parameter values ​​from the parameter configuration information. Finally, the final parameter values ​​of all parameters are passed to the algorithm's functional modules in the chip design as their configuration parameters, and then the module's simulation verification is initiated. In this way, the verification environment can process both random and specified parameters in a single randomization call, eliminating the need for users to write multiple sets of random constraints or manually manage parameter lists for different scenarios.

[0082] As an alternative implementation, in a C++-based validation framework, a custom randomization function can be defined to determine whether to call a random number generator (such as std::mt19937) to generate a random value or to directly return the current value of the parameter, based on a preset flag value of the parameter to be configured. The validity of the random value can be verified using a manually written constraint checking function.

[0083] As another approach, in a Python environment, random numbers can be generated using the `random` module or `numpy.random`, and conditional statements can be used to compare preset flag values ​​and perform branching operations. For complex constraints, attribute-based testing libraries such as `hypothesis` can be used.

[0084] As an alternative implementation in the UVM environment, the parameter object can be designed to derive from uvm_object, and randomization can be performed using UVM's built-in constraint solver when the randomize() method is called. By overriding the pre_randomize() or post_randomize() methods, preset flag value judgment logic can be inserted.

[0085] In this embodiment, simulation verification in the chip design verification environment refers to applying configured parameter values ​​to the algorithm function module under test (such as a video codec unit, image signal processing pipeline, AI accelerator, or other hardware modules or their reference models), and using a simulator (such as Synopsys VCS or Cadence Xcelium) to simulate the chip's behavior in actual operation, thereby verifying whether the module's function is correct, whether the timing meets the requirements, and whether it works normally with other modules. Specifically, in this step, after the final values ​​of each parameter to be configured are determined, the verification environment loads these values ​​into the configuration register or input signals of the algorithm function module through direct port assignment, bus register writing, or backdoor access. Subsequently, the simulator executes the simulation cycle by cycle according to the chip design logic: the algorithm function module processes the input stimulus data (such as test images and data streams) and generates output results based on the internal state machine transitions, data path selection, and arithmetic unit configuration of the configuration parameters. The verification environment compares the output results with the standard output (or expected results) of the reference model to determine whether the module's function under the current parameter combination meets the design requirements. If assertion violations or output data discrepancies with expectations occur during simulation, it indicates that the parameter combination exposes a design flaw, allowing verification engineers to debug and fix it. This simulation verification process can be repeated frame-by-frame: before each frame begins, steps 110 to 130 can be re-executed to configure different parameter combinations for the module. Then, the simulator processes the input for the new frame, and this process is repeated, thus covering a large number of parameter combination scenarios within the same test case. This disclosure, through a mechanism that mixes randomized and specified values ​​for parameter objects, ensures that the parameter values ​​used in each simulation verification include both user-directed key parameters and other automatically randomly generated parameters. This significantly expands the coverage of the verification space while ensuring thorough verification of key scenarios.

[0086] The following example uses SystemVerilog to illustrate this step. It should be noted that those skilled in the art can implement the same functionality using other hardware verification languages ​​or frameworks; this example does not constitute a limitation on the scope of this disclosure.

[0087] After creating the parameter objects and initializing their current values ​​in steps 110 and 120, the verification environment constructs a top-level configuration class (e.g., named pipe_cfg). This class contains all the parameters to be configured (e.g., parameters of module A and module B) and a set of parameter objects. In the top-level configuration class, a constraint block is written to implement branching based on the current value (i.e., determining the value of the actual parameter variable based on the comparison between the current value of the parameter object and the preset flag value). Specifically, for the input width parameter of module A, the constraint block first checks whether the current value of the corresponding parameter object (opts.a_i_h_num) is not equal to the preset flag value (e.g., 'hFFFF_FFFF'). If not, the actual parameter a_i_h_num is constrained to be equal to the current value of the parameter object (i.e., the user-specified value); if equal, a_i_h_num is constrained to be within a valid random range (e.g., between 4 and 128). Similarly, for the working mode parameter of module A, if the current value of the parameter object is not equal to the flag value, a_mode is forced to be equal to that value; otherwise, a value is randomly selected from the set {0,1}. Module B's input width and operating mode also employ the same branching logic. Furthermore, the constraint block defines pipeline linkage constraints: the input width of module B must equal the output width of module A (assuming module A's output width equals its input width), and the input height of module B must also equal the output height of module A. Through these constraint blocks, the randomized solver, when generating final values ​​for actual parameters, considers both the user's explicit specification (through the current value of the parameter object) and ensures the legal randomness of unspecified parameters, while simultaneously maintaining the dependency relationships between parameters in the pipeline.

[0088] In the test case, this step is triggered by calling the `randomize()` method of the `pipe_cfg` instance. When `randomize()` is executed, the SystemVerilog constraint solver generates a final value for each parameter based on the condition branches in the constraint block. For example, for user-specified parameters (where the current parameter value is not equal to the preset flag value), the specified value is directly assigned; for unspecified parameters (where the current parameter value equals the preset flag value), a value is randomly generated within the valid range (i.e., the constraint conditions are met). Ultimately, the values ​​of all parameters are determined and used to drive the subsequent simulation of the algorithm's functional modules.

[0089] By comparing the current value of each parameter object with a preset flag value, the system determines whether the final value is randomly generated or forced to use the current value based on the comparison result. The final parameter values ​​of all parameters are then output to the algorithm function module to drive simulation verification. This eliminates the need for users to manually specify whether each parameter is random before randomization is called. Instead, the system automatically distinguishes between parameters that need to be randomized and those that have been specified based on the current value of the parameter, achieving automated processing of partial specification and the rest being randomized. The output parameter values ​​are directly used as configuration parameters for the algorithm function module and drive its simulation verification. This ensures that parameter configuration and module execution are closely integrated in the verification process, without the need for additional parameter passing or data conversion steps. This step, together with steps 110 and 120, forms a complete technology chain of encapsulation-configuration-randomization-driving, solving problems such as poor parameter configuration flexibility, difficulty in switching between multiple modes, and inconsistent configuration methods, thereby improving the efficiency and scenario coverage of chip design verification.

[0090] Figure 2 This is a flowchart illustrating a parameter configuration method for chip verification, as shown in another exemplary embodiment of this disclosure. Figure 2 As shown in the embodiments of this disclosure, a parameter configuration method for chip verification is also provided, which may further include the following steps: Step 121: Receive parameter configuration information through a preset unified configuration interface. The preset unified configuration interface supports at least two of the following configuration methods: command line assignment, batch assignment of configuration files, and assignment within code, to configure parameter configuration information.

[0091] This step enables the use of a pre-defined unified configuration interface to receive parameter configuration information from at least two configuration methods: command line, configuration file, or code assignment. This information is then parsed into key-value pairs (parameter name and parameter value) that can be used for subsequent updates. This pre-defined unified configuration interface provides a unified access point for different configuration sources (configuration methods), ensuring that regardless of the user's configuration method, parameters are ultimately passed to the parameter object in the same data format and path. Its implementation is independent of specific programming languages ​​or validation frameworks, establishing a parameter configuration information receiving and parsing layer to identify and extract parameter names and values ​​from different channels, process various input formats (such as command line strings, file content, and code statements), and store the parsing results in a temporary data structure (such as a hash table) so that the parameter object can retrieve its configuration value through the query interface.

[0092] As one implementation method, the format of command-line assignment includes a preset prefix symbol, parameter name, and parameter value, wherein it begins with the preset prefix symbol, followed by the parameter name and the parameter value, and the parameter name and the parameter value are connected by a first preset separator; the format of batch assignment in the configuration file includes a preset prefix symbol, a preset configuration keyword, the configuration file path, and assignment statements in the configuration file, wherein it begins with a preset prefix symbol, followed by a preset configuration keyword and a second preset separator, and then the configuration file path; each line of assignment statements in the configuration file includes a preset prefix symbol, a parameter name, and a parameter value, and the parameter name and parameter value are connected by a second preset separator; the format of assignment in code is as follows: in the test code of the verification environment, the current value of the parameter corresponding to the parameter to be configured parameter is assigned through the assignment statement.

[0093] For example, command-line assignment formats begin with a preset prefix (e.g., "+") followed by the parameter name and value, separated by a first preset separator (e.g., "="). A complete example: +parameter_name=parameter_value. Multiple such parameters can be added consecutively in simulation commands, for example, +a_i_h_num=1920 +a_mode=0. Configuration file batch assignment formats begin with a preset prefix, followed by a preset configuration keyword (e.g., "cfg") and a second preset separator (e.g., "="), followed by the configuration file path. A complete example: +cfg=. / params.cfg. Each line within the configuration file contains an independent assignment statement, with the same format as command-line assignments: beginning with a preset prefix, followed by the parameter name and value, separated by a second preset separator. An example of in-code assignment in SystemVerilog is: a_mode_obj.val = 2. It should be noted that the first and second preset separators can be set to the same character (e.g., both can be "=").

[0094] As another implementation, parameter names and values ​​can be written to operating system environment variables. The unified configuration interface retrieves parameter configuration information by reading these environment variables (e.g., using C++'s `std::getenv` or Python's `os.environ`). This method is suitable for cross-process or scripted verification workflows, such as setting `export A_MODE=1` in the simulation startup script and then reading it in the verification environment. Alternatively, it can be based on parsing structured parameter configuration files (e.g., JSON, YAML, XML). The unified configuration interface has a built-in JSON or YAML parser that generates key-value pair mappings after reading the parameter configuration file. These implementations offer clear data structures, support nested parameters, and are easy to maintain and version-manage.

[0095] As another implementation, in a UVM environment, the UVM configuration database can be utilized. For example, `uvm_config_db#(int)::set(null, "*", "a_mode", 2)` sets the configuration at the top level of the test, and then the parameter object retrieves the parameter configuration information via `uvm_config_db#(int)::get(null, "*", "a_mode", val)`. This method integrates well with the UVM component hierarchy.

[0096] The following SystemVerilog implementation will be used as an example to further explain: For example, in the example of receiving and parsing command-line assignments, if the user inputs `simv +a_i_h_num=1920 +a_mode=0 +cfg=. / my.cfg`, the pre-defined unified configuration interface (component) (such as the aforementioned `ccl_opts`) scans all command-line parameters starting with "+" during the simulation initialization phase. For each parameter, it identifies the prefix symbol "+", and then splits the string into parameter name and parameter value by the first "=". For example, `+a_i_h_num=1920` is parsed as `name="a_i_h_num", value="1920"`, and this key-value pair is stored in the internal mapping table. For `+cfg=. / my.cfg`, the interface identifies the keyword "cfg", then reads the configuration file `. / my.cfg` at the specified path, parses the assignment statements in the file line by line (each line also starts with "+" and contains the pre-defined "=" separator), and stores the parsed key-value pairs in the mapping table as well.

[0097] Within the test case code, the current value member variable of the parameter object can be directly modified. For example: `a_mode_obj.val = 2`. This operation updates the object's internal state directly without going through command line or file parsing. The default unified configuration interface, upon receiving subsequent parameter query requests, needs to be able to identify the priority of values ​​assigned within the code, for example, values ​​parsed from the command line or file. This can be achieved by maintaining an assignment source flag for each parameter object or by setting overriding rules in the query logic.

[0098] Furthermore, the implementation method for parsing command-line arguments and configuration files and storing mapping relationships within the pre-defined unified configuration interface component can include: encapsulating the pre-defined unified configuration interface component as an independent software package (e.g., named ccl_opts). The unified configuration interface component internally maintains a static string associative array as a mapping table, where the key is the parameter name and the value is the configuration value in string form. The component provides a parsing function, called before the simulation begins, to process command-line arguments and configuration files. The parsing function first scans all command-line arguments starting with a pre-defined prefix symbol (such as "+"), and judges each parameter: if the parameter starts with "+cfg=", the file path after the equals sign is extracted, and then the configuration file parsing sub-function is called; otherwise, the parameter is split into parameter name and parameter value by the first equals sign, the parameter name prefix "+" is removed, and the key-value pair is stored in the mapping table. The configuration file parsing sub-function receives the file path parameter, reads each line of the file, performs the same parsing logic as the command-line arguments on each line (i.e., starting with "+" and containing "=" separators), and appends the parsed key-value pairs to the mapping table. In addition, the component provides an integer parameter lookup function that takes a parameter name and a default value as input: if the parameter name exists in the mapping table, its corresponding string value is converted to an integer and returned; otherwise, the passed-in default value is returned. Through the above mechanism, the unified configuration interface realizes the unified collection and storage of command-line and configuration file configuration information.

[0099] In this step, a pre-defined unified configuration interface supports at least two configuration methods from command line, configuration files, and in-code assignment, integrating multiple configuration methods into a single entry point. Users do not need to learn multiple different parameter passing mechanisms and can flexibly choose the convenient method according to the scenario. For example, single assignment via command line is used for quick debugging, batch assignment via configuration file is used for a large number of parameters, and in-code assignment is used for dynamically generated configurations. This solves the problem of incompatibility and inconsistency between command line, configuration file, and in-code configuration. At the same time, by defining a unified format syntax (such as pre-defined prefix symbols and delimiters), command line and configuration files have the same expression rules, reducing the user's learning cost and error probability. The introduction of configuration files simplifies the maintenance of a large number of parameters. Users only need to edit text files to switch between complex modes without modifying test code or simulation commands. In addition, the pre-defined unified configuration interface decouples the reception of parameter configuration information from the update of the current value of parameter objects. Parameter configuration information is first parsed and stored in an internal mapping table. Parameter objects obtain their configuration values ​​through a query function during initialization. This decoupling design facilitates the subsequent expansion of new configuration methods (such as environment variables, JSON files, etc.) without modifying any code of the parameter objects, improving the scalability of the verification environment.

[0100] Step 122: In response to receiving parameter configuration information from two or more configuration methods, determine the target configuration information from the parameter configuration information received from multiple configuration methods according to a preset priority rule.

[0101] In this embodiment, the same parameter can be specified using multiple configuration methods simultaneously (through parameter configuration information). For example, +a_mode=0 can be specified in the command line, +a_mode=1 can be specified in the configuration file, and a_mode_obj.val = 2 can be executed in the code. In this case, the verification environment can determine which configuration value (i.e., the target configuration information) to use in the end according to the predefined priority rules, avoiding conflicts or ambiguities.

[0102] Independent of any specific programming language or validation framework, its essence is a priority-based multi-source configuration arbitration mechanism. This mechanism must at least possess the following capabilities: the ability to identify whether the same parameter comes from multiple configuration sources; the ability to obtain the preset priority of each configuration source; and the ability to select the highest priority configuration based on the priority comparison results.

[0103] One possible approach is to pre-define a fixed priority value for each configuration method. For example, code-based assignment priority = 3, command-line assignment priority = 2, and batch configuration file assignment priority = 1 (the higher the value, the higher the priority). When the pre-defined unified configuration interface parses multiple parameter configuration information for any parameter to be configured, it records each parameter configuration information and obtains the priority of the configuration method corresponding to each parameter configuration information. It then iterates through all parameter configuration information, compares the priorities of two or more configuration methods, obtains the comparison result, and selects the parameter configuration information with the highest priority as the target configuration information. Another possible approach is to determine the target configuration information if two parameter configuration information come from the same priority (e.g., two different configuration files with the same priority). This can be done by using a rule that the later read overrides the earlier read, or by using predefined secondary rules (such as lexicographical order of file paths), thus determining the parameter value of the parameter to be configured.

[0104] As another possible approach, parameter configuration information can be received in the order it is received, with later received information overwriting earlier received information. For example, during simulation startup, the configuration file is parsed first, then the command line is parsed, and finally, the assignments within the code are executed. Since the assignments within the code are executed during the simulation run, they naturally overwrite previous values. This method does not require explicit priority values; instead, it uses the chronological order as the priority rule.

[0105] As another possible approach, a mapping table from configuration source type (preset configuration method) to priority is maintained within the pre-defined unified configuration interface, allowing users to customize and adjust priorities. For example, users can specify "command line priority=2, file priority=1, code priority=3" through an external configuration file. This provides greater flexibility and suits the needs of different projects.

[0106] As an alternative approach, when a conflict is detected, the verification environment generates a warning or error, prompting the user to explicitly specify the target configuration information in the test case (e.g., via the additional parameter +override= command line). This approach returns the decision-making power to the user and can be applied to scenarios with extremely high deterministic requirements.

[0107] For example, suppose a user uses multiple configuration methods simultaneously: The configuration file params.cfg contains: +a_mode=1 Add the following to the command line: +a_mode=0 Execution within the code: a_mode_obj.val = 2 The analysis process is as follows: First, parse the configuration file and add an entry {value:"1", priority:1} to config_map["a_mode"].

[0108] Then parse the command line and add the entry {value:"0", priority:2}.

[0109] Finally, when assigning values ​​in the code, set_by_code("a_mode", "2") is called to add the entry {value:"2",priority:3}.

[0110] When get_int("a_mode", 'hFFFF_FFFF) is called, it iterates through the three entries, selects the one with the highest priority (priority=3), and finally returns a value of 2, which is used as the target configuration information.

[0111] This embodiment responds to parameter configuration information from two or more preset configuration methods and determines the target configuration information according to preset priority rules. When the same parameter is configured repeatedly by multiple configuration methods, the verification environment can automatically determine which value to use, avoiding uncertainty and errors caused by configuration conflicts. Secondly, through preset priority rules (e.g., code-based assignment has the highest priority, command line is second, and configuration file has the lowest priority), the configuration method can be flexibly selected according to different scenarios, and it can be assured that the high-priority method will override the low-priority method. For example, during debugging, parameters can be temporarily modified directly in the code without cleaning up the command line or files. Furthermore, the priority comparison mechanism can be independent of the specific configuration parsing logic, making the unified configuration interface more extensible. When adding a new configuration method (such as environment variables), only a priority value needs to be assigned to it and added to the comparison logic, without modifying the core arbitration code. In addition, by explicitly comparing priorities, the predictability and determinism of the results are guaranteed. Regardless of the order in which the configuration information is received, the final result is always determined by the source with the highest priority, which helps to improve the consistency of regression testing.

[0112] Step 123: Update the current value of the parameter of the corresponding parameter object according to the target configuration information.

[0113] In this step, the determined target configuration information (i.e., the unique and valid parameter value determined by priority) is written into the current value member variable of the corresponding parameter object, completing the configuration update of that parameter. Implementation methods include, but are not limited to, directly modifying member variables, calling a setting function, or using a callback mechanism.

[0114] One implementation approach is direct member variable assignment. After determining the target configuration information, the current value member of the parameter object is directly modified via an assignment statement (e.g., "parameter object.parameter current value = target value"). This method is simple, efficient, and suitable for scenarios where the parameter object's internal members are accessible. Another approach is through setter functions (public methods (functions) specifically designed to modify private member variables within an object, typically named with a prefix like "set_" or similar, such as "set_val()" or "set_width()"). The parameter object provides a public setting method (e.g., "set_val"), which can contain additional logic such as validity checks and event triggering. After determining the target value (target configuration value), this setting method is called to complete the update. This approach helps encapsulate and protect the object's internal state, facilitating future expansion.

[0115] For example, suppose the default unified configuration interface has determined the target configuration information for the parameter "a_mode" to be the value 2 based on priority rules (e.g., assigned from within the code, which has higher priority than command line and configuration file). Then, in the test code, an assignment statement is executed, directly writing the value 2 corresponding to the target configuration information into the current value member variable of the corresponding parameter object, i.e., "a_mode_obj.val = 2". Before the update, the current value of this parameter object is equal to the default flag value (e.g., all 32 bits are 1), indicating that it has not yet been specified; after the update, the current value becomes 2, indicating that it has been specified by the user. For other parameters that have not received any configuration (such as "a_i_h_num"), their current values ​​remain unchanged, still being the default flag value, and are automatically randomly generated during subsequent randomization processing.

[0116] In this way, the target configuration information determined by the priority rules is written into the parameter object, realizing the physical mapping from external configuration to internal state, ensuring that the parameter values ​​specified by the user can be forcibly used in subsequent randomization; at the same time, it supports multiple update methods, improving the flexibility and maintainability of the verification environment; unspecified parameters retain preset flag values, thus providing a direct implementation mechanism for partially specified and the rest randomized.

[0117] Figure 3 This is a flowchart illustrating a parameter configuration method for chip verification, as shown in another exemplary embodiment of this disclosure. Figure 3 As shown in the embodiments of this disclosure, a parameter configuration method for chip verification is also provided, which may further include the following steps: Step 131: For each parameter object, compare the current value of the parameter in the parameter object with the preset flag value.

[0118] In this step, for each parameter object in the verification environment, the current value of the parameter stored in the parameter object is compared with a preset flag value to determine whether the parameter has been explicitly specified by the user. This comparison operation compares the current value of each parameter object with the preset flag value sequentially, producing, for example, a Boolean comparison result (equal or unequal), which serves as the direct basis for subsequent branch processing (randomization or forced assignment). The technical implementation of this comparison operation depends on the programming language and data types used in the verification environment. Specifically, for basic types such as integers, enumerations, and strings, built-in equality operators (such as == or the equals method) can be used. For custom types or cases with inconsistent bit widths, type conversion or bit width alignment can be performed before comparison, ensuring that the comparison result accurately reflects whether the current value of the parameter is equal to the preset flag value, avoiding misjudgments due to type or bit width issues.

[0119] One implementation method is to use the language's built-in equality operators for direct comparison. For example, in SystemVerilog, you can use `if (param_obj.val == 'hFFFF_FFFF)`, in C++, you can use `if (param_obj.val == 0xFFFFFFFFUL)`, and in Python, you can use `if param_obj.val == 0xFFFFFFFF`. This method is simple and efficient, and suitable for scenarios where the current value of the parameter and the preset flag value have the same data type and bit width.

[0120] As another implementation, when the bit widths are inconsistent, for example, the current value of a parameter object is an 8-bit integer, while the default flag value is defined as 32 bits all 1s, the two are first converted to a uniform bit width before comparison. For example, zero extension or sign extension can be used to extend the narrow-bit value to the wide-bit value, or the wide-bit value can be truncated to the narrow-bit value (ensuring that the truncated value does not conflict with a valid value), before performing an equality check. For example, in SystemVerilog, the 8-bit value can be extended to 32 bits using {24'b0, 8-bit value}, and then compared with the 32-bit flag value; or the 32-bit default flag value can be truncated to 8 bits 'hFF and compared with the 8-bit current value (provided that the truncated default flag value is not within the valid range of the parameter).

[0121] As an alternative implementation, the comparison logic can be encapsulated using a dedicated comparison function or method. For example, an `is_random()` method can be provided within the parameter object, which returns a boolean value indicating whether the current value of the parameter is a preset flag value. This method can encapsulate details such as type conversion and bit width alignment, so external callers don't need to worry about the specific comparison method; they only need to call `if (param_obj.is_random())`. This approach improves code readability and maintainability, especially when the representation of the preset flag value changes in the future. Only the `is_random()` method needs modification, without altering the comparison code at all call sites. For instance, the `is_random()` method can be a parameterless member method that returns a boolean value, used to indicate whether the current value state of the object is in a pending randomization mode. When the method returns true (True / 1), it indicates that the current value of the object has been marked as invalid or a placeholder value, and a valid value needs to be generated by a randomization mechanism to replace it. When it returns false (False / 0), it indicates that the current value of the object has been explicitly specified externally and can be used directly as the final value without further randomization. A typical implementation of this method is to compare a specific flag value (i.e., a preset flag value) stored internally with the current value of the object and return the comparison result.

[0122] In this way, by comparing the current value of each parameter object with the preset flag value, the specified parameters and the parameters to be randomized are accurately distinguished, providing a clear and unified basis for judgment in subsequent branch processing; it supports multiple comparison implementation methods (built-in operators, bit width adaptation, encapsulated comparison methods), which can adapt to different data types and bit width configurations, improving the versatility of the solution; in addition, the comparison operation is simple and efficient, without introducing additional complexity, enabling the verification environment to automatically process parameters in different states in a single randomization call, thus laying the foundation for the automated implementation of partial specification and the rest randomization.

[0123] Step 132: In response to the current value of the parameter being equal to the preset flag value, randomization processing is performed on the parameter to be configured corresponding to the parameter object to generate a random value, which is then used as the parameter value of the parameter to be configured.

[0124] In this step, when the current value of the parameter equals the preset flag value, it is determined that the user has not explicitly specified the parameter through any configuration method. At this time, the verification environment should automatically generate a valid random value for the parameter that meets the preset constraints to cover various possible input scenarios. Randomization can be performed by selecting a specific value through a random algorithm within the possible value space of the parameter (limited by constraints such as type, range, and relationship). This value should have unpredictability and uniform distribution characteristics to improve the verification coverage.

[0125] For example, preset random constraints for the parameter can be obtained (e.g., range of values, set of values, equality or inequality with other parameters), and then a random number generator or constraint solver can be called to generate a valid random value based on these random constraints. The generated random value is then assigned to the corresponding input or configuration port of the algorithm function module to drive the simulation execution.

[0126] As one implementation method, specifically, in response to the current value of a parameter equaling a preset flag value, the preset random constraints for any configurable parameter are obtained. A randomized solver in the chip design verification environment is then invoked. The randomized solver generates a random value that satisfies the random constraints, which is then used as the parameter value for that configurable parameter. For example, for each configurable parameter, a set of random constraints can be predefined in the verification environment (e.g., the parameter value must be between 4 and 128, or it must belong to the set {0, 1, 2}, etc.). When the current value of the parameter is determined to be equal to the preset flag value, the random constraints for that parameter are obtained. Then, the built-in randomized solver of the verification environment (e.g., the constraint solver in SystemVerilog, a random number distribution engine in C++ combined with manual constraint checking, or the random module in Python combined with conditional judgment, etc.) is invoked. The solver generates a random value as the final value of the parameter, provided that all random constraints are satisfied. This method can handle complex constraint relationships (such as cross-parameter constraints, conditional constraints, etc.), and the generated random value has good validity and distribution.

[0127] As an alternative approach, a random number generator can be used in conjunction with boundary checks, without relying on complex constraint solvers. For parameters without complex constraints (such as enumeration types with independent values ​​or simple range limitations), random number functions in the language library (such as C++'s `rand()` and Python's `random.randint()`) can be directly called to generate random numbers between preset minimum and maximum values. Then, several `if` statements are used to check whether additional conditions are met (such as excluding certain illegal values). If not, the random number generator is regenerated until a valid value is obtained. This method is simple to implement, fast to execute, and suitable for parameters with relatively simple constraints.

[0128] As an alternative approach, for parameters with a limited value space (e.g., only three possible modes: 0, 1, and 2), a random value sequence table can be predefined, and an unused value can be selected sequentially or randomly from the table as the parameter's value. This method is suitable for regression testing scenarios where determinism is required.

[0129] For example, in the constraint block of a top-level configuration class (such as pipe_cfg), for each parameter object, when its current parameter value is determined to be equal to the preset flag value 'hFFFF_FFFF', the corresponding actual parameter is constrained to a legal random range. For example, for the input width parameter a_i_h_num of module A, the constraint condition is a_i_h_num inside {[4:128]}. When the verification environment executes pipe_cfg.randomize(), the SystemVerilog built-in constraint solver will automatically generate a random integer value between 4 and 128 based on this constraint condition, as the final value of a_i_h_num. For the mode selection parameter a_mode, the constraint condition is a_mode inside {0,1}, and the solver randomly generates 0 or 1. If a parameter is simultaneously subject to linkage constraints (such as the input width of the subsequent module being equal to the output width of the preceding module), the solver will search for a set of solutions that simultaneously satisfy all constraints in the value space of all related parameters, ensuring that the generated random value combination is legal and consistent. The entire randomization process is completed automatically by the solver, and users do not need to write any random number generation code.

[0130] Based on this embodiment, by responding to the current value of a parameter being equal to a preset flag value, randomization processing is performed on unspecified parameters and random values ​​are generated, thus achieving automatic random configuration of unspecified parameters. By using a constraint solver or random number generator to generate legal random values ​​according to preset random constraints, the diversity and coverage of random values ​​are ensured, and illegal parameter combinations are avoided. Working in conjunction with the determination in step 131, an automated branching logic is formed, eliminating the need for users to explicitly write randomization code for each parameter, thereby reducing the cost of setting up and maintaining the verification environment. At the same time, this step supports multiple implementation methods, from simple range randomization to complex linkage constraint solving, which can adapt to parameter configuration requirements of different complexities and improve the flexibility and efficiency of chip design verification.

[0131] Step 133: In response to the current value of the parameter not being equal to the preset flag value, the current value of the parameter is directly used as the parameter value of the parameter to be configured.

[0132] In this step, when the current value of a parameter is not equal to the preset flag value, it is determined that the user has explicitly specified the parameter through any configuration method (command line, configuration file, or in-code assignment). The verification environment directly uses the specified value as the final value according to the user's intention, without performing randomization. This ensures the user's precise control over key parameters while avoiding the erroneous behavior of random values ​​overwriting user-specified values.

[0133] Specifically, when it is determined that the current value of a parameter is not equal to a preset flag value, the current value of the parameter object can be copied to the configuration variable corresponding to the algorithm function module by executing an assignment statement. For example, in SystemVerilog: a_mode = a_mode_obj.val;. This method is simple and efficient, suitable for most scenarios. Alternatively, a mapping relationship from parameter objects to configuration variables of algorithm function modules can be pre-established. The mapping table is traversed, and for each parameter object, if its current value is not equal to the flag value, the current value of the parameter object is written to the corresponding target variable in the mapping table. This method is suitable for scenarios with a large number of parameters that require centralized management. Furthermore, when the current value of a parameter object is updated (as in steps 1, 2, and 3), an update event is automatically triggered. The updated value is then checked to see if it is not equal to the preset flag value; if so, the value is pushed to the algorithm function module. This method decouples configuration updates from value applications, making it suitable for dynamic configuration scenarios.

[0134] For example, this assignment method can be embedded in a randomization constraint block or placed in the `post_randomize` callback. In the constraint block, when the current value of the parameter object's parameter is not equal to the preset flag value, the constraint condition directly constrains the actual parameter to be equal to the current value, for example, `if (opts.a_mode.val != 'hFFFF_FFFF) a_mode == opts.a_mode.val`. When `randomize()` is executed, the constraint solver finds that the parameter is forced to be equal to a specific value, so it will not randomize it and will directly use the specified value. Another implementation is in the `post_randomize` phase, where a conditional statement assigns the determined value to the port of the algorithm's functional module, for example: `if (a_mode_obj.val != 'hFFFF_FFFF) a_mode=a_mode_obj.val; else a_mode = a_mode.random_value`. This method is more intuitive, but care must be taken to avoid conflicts with the constraint block.

[0135] By directly using the current value of a parameter that is not equal to the preset flag value as the final parameter value, the forced use of user-specified parameters is realized, ensuring that the user's intention is accurately executed in the simulation verification. Together with the aforementioned steps, it forms a complete branch logic, enabling the verification environment to automatically distinguish between parameters that need to be randomized and those that have been specified, without the need for manual intervention. It is simple to implement, has no additional computational overhead, and supports multiple assignment or mapping methods, making it easy to integrate into verification environments with different structures, thus providing a reliable forced path for partially specified and the rest randomized.

[0136] Step 134: Output the parameter values ​​of each parameter to be configured to the algorithm function module in the chip design as the configuration parameters of the algorithm function module, so as to drive the algorithm function module to perform simulation verification according to the configuration parameters.

[0137] In this step, the final parameter values ​​of each configurable parameter are output to the algorithm function module in the chip design (such as video codec unit, image signal processing pipeline, AI accelerator, etc.) as the configuration parameters of the module, and the module is triggered to perform simulation verification. For example, the final parameter values ​​are actually applied to the corresponding configuration port or register of the algorithm function module, so that the algorithm function module runs according to the parameter combination expected by the user and completes the simulation verification in a specific scenario.

[0138] For example, this can be achieved in ways including but not limited to the following: (1) Direct port assignment can be used, that is, the parameter value can be directly assigned bitwise or bytewise to the input signal of the algorithm function module through the interface driver in the verification environment (such as the virtual port or channel of the SystemVerilog interface). For example, for the input width parameter a_i_h_num of module A, top.u_module_a.i_h_num = a_i_h_num_val can be executed. This method is suitable for scenarios where the parameter value is configured once before the simulation starts and does not change frequently.

[0139] (2) Register configuration buses (such as APB, AHB, AXI-Lite) can be used to write parameter values ​​to the configuration registers inside the algorithm function module through bus transactions. This method is closer to the real application scenario of the chip (the chip usually configures the registers through the bus) and supports dynamic modification of parameters during simulation. For example, a register model can be built in the UVM environment, and the write operation can be called to write the parameter values ​​to the corresponding register address.

[0140] (3) Backdoor access can be used to directly modify the variables or registers inside the module under test by using the hierarchical path reference of the verification language or the DPI-C interface. This method does not consume simulation time and is suitable for scenarios where configuration is fast and does not interfere with normal bus timing. It is often used in verification processes with a large number of parameters or where frequent configuration switching is required.

[0141] (4) A message passing or transaction-level model (TLM) can be used to package parameter values ​​into configuration transactions and send them to the reference model or proxy component of the algorithm function module through the TLM port. The proxy component then converts the configuration of the module into a specific protocol. This approach is suitable for high-level, abstract verification environments and facilitates module reuse.

[0142] Assume that algorithm functional modules A and B are both RTL designs, and their parameters are directly input through module ports. In the top-level test case, after `pipe_cfg.randomize()` completes, all final parameter values ​​are stored in the member variables of `pipe_cfg.a` and `pipe_cfg.b` (e.g., `a_i_h_num_val`, `a_mode_val`, etc.). The verification environment then executes a configuration task, assigning each parameter value to the corresponding port of the module under test (i.e., the corresponding algorithm functional module): for example, `top.inst_A.i_h_num = pipe_cfg.a_i_h_num_val;`, `top.inst_A.mode = pipe_cfg.a_mode_val;`, and the corresponding port of module B. After the assignment is completed, the test case releases and resets or starts the input stimulus, and the algorithm functional module begins to execute simulation verification according to the configured parameters. If you need to switch to a new parameter configuration after a frame ends, you can call reset() again before processing the next frame, re-specify some parameters and randomize() again, and then re-execute the above port assignment so that the driver module can process the new frame of data.

[0143] In this way, the final values ​​of the parameters, which have been randomized or forcibly determined, are output to the algorithm function module and drive it to perform simulation verification, completing a complete closed loop from parameter configuration to actual simulation verification. By supporting multiple output methods such as direct port assignment, bus register writing, backdoor access, or TLM transactions, it can adapt to verification environments with different abstraction levels and interface types, and has good versatility. This step tightly integrates parameter configuration with simulation execution, eliminating the need for users to manually pass parameter values ​​and reducing the probability of errors. At the same time, because it supports dynamic reconfiguration, it is easy to switch parameter modes between multiple frames or multiple scenarios, improving the automation level and scenario coverage efficiency of the verification process.

[0144] As another embodiment of this disclosure, a parameter configuration method for chip verification may further include: responding to a chip design verification environment including at least two levels of algorithm functional modules, identifying each parameter to be configured in the at least two levels of algorithm functional modules, and determining parameter pairs to be linked, wherein the parameter pairs to be linked include output parameters of the preceding module and input parameters of the following module, or parameters with the same function in different modules; obtaining preset linkage constraints for the parameter pairs to be linked, wherein the preset linkage constraints are preset based on the data transmission relationship between the algorithm functional modules, and adding the preset linkage constraints to a random constraint set of the chip design verification environment so that the random values ​​obtained by randomizing the parameters to be configured satisfy the preset linkage constraints and the preset random constraints, wherein the random constraint set includes the preset random constraints.

[0145] Specifically, this embodiment, based on the aforementioned embodiments, further introduces a cross-module linkage constraint mechanism to solve the problem of parameter correlation constraints in pipeline architectures or multi-module systems. When the chip design verification environment contains at least two levels of algorithm functional modules (e.g., a front-end filtering module and a back-end encoding module in a video processing pipeline, or a convolutional layer and a pooling layer in an AI accelerator), it automatically identifies the parameters to be configured in these modules, determines the parameter pairs that need to establish linkage constraints between modules (including but not limited to the output parameters of the front-end module and the corresponding input parameters of the back-end module, parameters with the same function in different modules, etc.), obtains the linkage constraint conditions pre-set according to the data transmission relationship between modules, and adds these linkage constraint conditions to the random constraint set of the verification environment. This ensures that when the parameters to be configured are randomized (i.e., the randomization generation process in step 132 above is executed), the generated random values ​​simultaneously satisfy the preset random constraint conditions (such as the parameter's own value range, value set, etc.) and the above linkage constraint conditions, thereby guaranteeing the consistency of parameters and the legality of data transmission between multi-level modules.

[0146] In practice, the pipeline topology in the verification environment can be identified first to determine the modules involved in the linkage and their parameter correspondences. Then, linkage constraints for these parameter pairs can be extracted from a preset constraint library or configuration file (e.g., requiring the input width of the subsequent module to be equal to the output width of the preceding module, or requiring the mode selection parameter values ​​of the two modules to be the same). Finally, these constraints are added to the constraint set of the randomized solver in the form of constraint statements. When the randomized solver runs, it satisfies both the value range constraints of each parameter and the linkage constraints between modules while solving for the random values ​​of all parameters. If a parameter has been explicitly specified by the user (its current value is not equal to the preset flag value), the linkage constraint will still apply to it. That is, if the value specified by the user conflicts with the linkage constraint, the randomized solver will report a constraint solution failure, thus promptly detecting configuration errors.

[0147] By automatically identifying linkage parameters and applying preset linkage constraints, the system ensures that parameter configurations at all levels of modules in a pipeline or multi-module system remain consistent and valid, avoiding invalid verification scenarios caused by parameter mismatches. The addition of linkage constraints does not change the original parameter configuration process; users can still partially specify parameters, and unspecified parameters are automatically randomized, but the randomized result must satisfy the linkage relationship. This reduces the burden on users to manually maintain parameter consistency between modules and is suitable for algorithm verification projects with a large number of parameters and complex inter-module dependencies, further improving the intelligence level and scenario coverage efficiency of the verification environment.

[0148] As another embodiment of this disclosure, a parameter configuration method for chip verification may further include: in response to a received reset command, restoring the current value of the parameter of each parameter object to a preset flag value, so that the parameter to be configured of each parameter object is restored to a state to be randomized.

[0149] Specifically, the embodiments of this disclosure can further implement a parameter reset mechanism to support rapid reset of parameter configuration states and flexible switching of inter-frame configuration modes. When the verification environment receives a reset command (e.g., explicitly calling a reset function in a test case, or automatically triggering a reset after each frame of image processing), it iterates through all created parameter objects and restores the current value of each parameter object to a preset flag value, thereby returning each parameter to be configured to its initial unrandomized state.

[0150] In this reset state, the current values ​​of all parameters are equal to the preset flag values. Therefore, in subsequent randomization processing, each parameter will be considered as unspecified by the user, and all will enter the random generation path. However, the reset operation itself does not require the next randomization to be entirely random. Instead, the user can, after the reset and before the next randomization call, re-specify the current values ​​of some parameters through a preset unified configuration interface (command line, configuration file, or in-code assignment). Therefore, this reset mechanism provides an efficient state reset method for multi-frame, multi-scenario verification processes.

[0151] The specific implementation of the parameter reset mechanism can be based on the built-in `reset()` method of the parameter object. For example, each parameter object can implement a reset function that assigns its current value to a preset flag value. The verification environment further provides a global reset function (e.g., `cfg_reset()`), which calls the `reset()` method of each parameter object in sequence. The reset command can be implicit (e.g., automatically called after each frame is processed) or explicit (e.g., manually called in the test code).

[0152] Thus, the reset command can restore all parameters to the state to be randomized, eliminating the need for manual assignment of each parameter, reducing the amount of code and the probability of errors during configuration switching. Secondly, after resetting, users can re-specify some parameters, enabling flexible switching between specified configurations in the previous frame and partially specified or fully randomized configurations in the next frame, supporting inter-frame mode changes in verification scenarios. Furthermore, the reset mechanism works in conjunction with the unified configuration interface, allowing users to complete continuous verification of multiple parameter combinations within a single test case through a cycle of reset → reconfiguration → randomization, improving the reusability and regression efficiency of verification test cases. Finally, a clear parameter state management model is provided for the verification environment, standardizing and automating the parameter configuration setting-clearing-resetting process, further enhancing the practicality and convenience of this embodiment in chip design verification.

[0153] The parameter configuration method for chip verification in this disclosure can be deployed in electronic design automation tools, chip simulation verification platforms, or cloud verification services. As a core configuration management component of the verification environment, it is called by test cases or verification scripts to complete the flexible parameter configuration and randomized verification tasks of pipeline architecture algorithm functional modules.

[0154] In some implementations, the parameter configuration method for chip verification in this disclosure can receive parameter configuration information (e.g., "image input width = 1920", "working mode = 0", etc.) assigned from command line, configuration file, or code. After parameter object encapsulation, unified configuration interface parsing, priority rules, and comparison with preset flag values, it outputs the final values ​​of each parameter to be configured that meet user-specified or random constraints, and drives the algorithm function modules in the chip design (such as the transform / quantization unit in a video codec, the denoising / sharpening module in an image signal processor, the convolution / pooling / activation unit in an AI accelerator, etc.) to perform simulation verification.

[0155] Specifically, for image signal processing pipeline verification scenarios, the parameter configuration method for chip verification in this embodiment of the present disclosure can receive some parameters specified in the test cases (such as "denoising intensity level = 3", "sharpening gain = 128"), while unspecified parameters (such as "black level correction value", "white balance gain coefficient", "color interpolation mode") are automatically generated randomly within their legal range. Simultaneously, preset linkage constraints ensure that the output image size of the front-end module is strictly equal to the input image size of the back-end module, and guarantee the consistency of color space conversion parameters. This method outputs the configuration parameter values ​​of each module, drives an RTL-level hardware model or a behavioral-level reference model to process a set of test images, and outputs the processed image data and comparison information with the standard reference results, allowing verification engineers to determine whether the design function is correct and meets the expected technical specifications.

[0156] For example, in the verification task of an AI accelerator, the parameter configuration method for chip verification in this embodiment can receive convolutional layer parameters (such as "kernel size = 3", "stride = 1", "fill mode = same") and pooling layer parameters (such as "pooling window = 2", "pooling type = max pooling") set in batches from a configuration file. Unspecified activation function thresholds, batch normalization parameters, etc., are automatically generated randomly and output to the accelerator's configuration bus or register model to drive the hardware model to perform inference operations and output inference results and intermediate feature maps for functional coverage analysis and performance evaluation. This method can also be deployed on a cloud simulation server cluster, automatically switching between different verification scenarios through scripts, dynamically adjusting parameter combinations in large-scale regression testing, and outputting verification logs, waveform files, and coverage reports, significantly improving the automation and efficiency of regression verification.

[0157] In the above tasks, the input data types accepted by this method include, but are not limited to: string key-value pairs from the command line (data type is string), text line sequences from the configuration file (data type is text), and primitive type values ​​assigned in the code (such as integer, floating-point, enumeration, and string). Input data may also include preset random constraints (such as value range, value set, and equality or inequality relationships across parameters), linkage constraints (such as the output of the preceding stage equals the input of the following stage, and the same functional parameters between modules have consistent values), and reset instructions (used to restore the current value to a preset flag value). The data types output by this method include, but are not limited to: the final values ​​of each parameter to be configured (data type corresponds to the input parameter type, such as integer, floating-point, and string), and configuration signal waveforms, log information, and functional coverage data that drive the algorithm's functional modules to perform simulation. The verification environment configured using this method reduces the workload of manually writing configuration code while ensuring sufficient scenario coverage. It is especially suitable for chip design projects with a large number of parameters, complex inter-module relationships, and frequent switching between multiple verification modes. It improves verification efficiency and the reusability of verification test cases, shortens the chip verification cycle, and improves hardware resource utilization and the maintainability of the verification environment.

[0158] In summary, through the embodiments of this disclosure, each configurable parameter is instantiated as an independent parameter object, and a preset flag value is set for it to indicate the initial state of the current value. Combined with a unified configuration interface supporting multiple configuration methods and a randomization mechanism that determines the final parameter value based on the comparison between the current value and the preset flag value, users can arbitrarily specify the values ​​of one or more configurable parameters through the unified configuration interface. The current value of the specified parameter is updated to the specified value, and during randomization, the specified value is forced to be used because the current value is not equal to the preset flag value. Unspecified parameters retain their current value as the preset flag value and are automatically randomly generated. This achieves parameter setting results where some parameter values ​​are specified and the rest are randomized, improving the flexibility of parameter configuration. Users only need to change the specified values ​​of a small number of parameters to switch the entire configuration. This system employs a set of working modes to address the technical challenges of batch modification of a set of parameters for different working modes, cumbersome and error-prone configuration, and the need to write multiple sets of test cases with poor reusability for multi-mode configuration. This improves the reusability and regression efficiency of verification test cases. Simultaneously, it pre-sets a unified configuration interface with at least two configuration methods. Regardless of the user's chosen method, configuration information is received and the current value of the corresponding parameter object is updated through the same interface, resolving the technical issues of multiple configuration methods being independent, non-universal, and inconsistent. Finally, the final parameter values ​​of each configurable parameter are used as configuration parameters for the algorithm functional modules in the chip design to drive their simulation verification. This allows the verification environment to automatically generate a large number of random combination scenarios within the same test process while allowing users to perform targeted control of key parameters, thereby improving the efficiency and scenario coverage sufficiency of chip design verification while ensuring coverage.

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

[0160] Figure 4 This is a structural block diagram of a parameter configuration apparatus for chip verification, as an exemplary embodiment of this disclosure. Figure 4 The present disclosure provides a parameter configuration device for chip verification, applied in a chip design verification environment, wherein the chip design verification environment includes at least one parameter to be configured, and the device includes: The parameter instantiation module 410 is used to instantiate each of the parameters to be configured into a parameter object. The parameter object includes a parameter name and a current parameter value. The initial state value of the current parameter value is a preset flag value, which is used to indicate that the parameter value is randomly generated. The parameter update module 420 is used to update the current value of the corresponding parameter object according to the parameter configuration information received through the preset unified configuration interface in response to receiving parameter configuration information through the preset unified configuration interface. The preset unified configuration interface supports at least two preset configuration methods. The final value determination module 430 is used to determine the parameter value of the corresponding parameter to be configured for each parameter object based on the comparison result between its current parameter value and the preset flag value during the randomization of parameters in the chip design verification environment, so as to use the parameter value of each parameter to be configured as the configuration parameter of the algorithm function module in the chip design, so as to drive the algorithm function module to perform simulation verification.

[0161] As an optional embodiment, the parameter update module 420 includes: The information receiving unit is used to receive parameter configuration information through the preset unified configuration interface, wherein the preset unified configuration interface supports at least two configuration methods among command line assignment, batch assignment of configuration files and assignment in code, to configure the parameter configuration information; A priority processing unit is used to determine target configuration information from the parameter configuration information received from two or more configuration methods in response to receiving parameter configuration information from two or more configuration methods, according to a preset priority rule. The parameter update unit is used to update the current value of the parameter of the corresponding parameter object according to the target configuration information.

[0162] As an optional embodiment, the priority processing unit includes: The priority comparison subunit is used to obtain the priority of each configuration method, compare the priorities of the two or more configuration methods, and obtain the comparison result. The configuration information determination subunit is used to determine the parameter configuration information of the configuration method with the highest priority among the two or more configuration methods as the target configuration information based on the comparison result.

[0163] As an optional embodiment, the format of the command line assignment includes a preset prefix symbol, a parameter name, and a parameter value, wherein the preset prefix symbol is used as the starting point, followed by the parameter name and the parameter value, and the parameter name and the parameter value are connected by a first preset separator. The format for batch assignment of configuration files includes a preset prefix symbol, a preset configuration keyword, a configuration file path, and assignment statements within the configuration file, wherein: it begins with the preset prefix symbol, followed by the preset configuration keyword and a second preset separator, and then the configuration file path; each line of assignment statements within the configuration file includes the preset prefix symbol, a parameter name, and a parameter value, and the parameter name and the parameter value are connected by the second preset separator; The format for assigning values ​​within the code is as follows: In the test code of the verification environment, the current value of the parameter object corresponding to the parameter to be configured is assigned using an assignment statement.

[0164] As an optional embodiment, the final value determination module 430 includes: The comparison unit is used to compare the current value of the parameter in each parameter object with the preset flag value. A random unit is used to perform randomization processing on the parameter to be configured corresponding to the parameter object in response to the current value of the parameter being equal to the preset flag value, and generate a random value so as to use the random value as the parameter value of the parameter to be configured. The parameter value determination unit is used to directly use the current value of the parameter as the parameter value of the parameter to be configured in response to the current value of the parameter not being equal to the preset flag value. The verification unit is used to output the parameter values ​​of each parameter to be configured to the algorithm function module in the chip design, as the configuration parameters of the algorithm function module, so as to drive the algorithm function module to perform simulation verification according to the configuration parameters.

[0165] As an optional embodiment, the random unit includes: The constraint condition acquisition subunit is used to acquire a preset random constraint condition for any of the parameters to be configured in response to the current value of the parameter being equal to the preset flag value. The random solver subunit is used to call the randomized solver in the chip design verification environment to generate a random value that satisfies the randomized constraints, which is then used as the parameter value of the parameter to be configured.

[0166] As an optional embodiment, the device further includes: The linkage parameter determination module is used to respond to the chip design verification environment, which includes at least two levels of algorithm function modules, to identify each configurable parameter in the at least two levels of algorithm function modules, and to determine the parameter pair to be linked. The parameter pair to be linked includes the output parameters of the front-end module and the input parameters of the back-end module, or parameters with the same function in different modules. The linkage constraint condition acquisition module is used to acquire the preset linkage constraint conditions of the parameter pair to be linked. The preset linkage constraint conditions are preset according to the data transmission relationship between the algorithm functional modules. The condition addition module is used to add the preset linkage constraint conditions to the random constraint set of the chip design verification environment, so that the random value obtained by randomizing the parameter to be configured satisfies the preset linkage constraint conditions and the preset random constraint conditions. The random constraint set includes the preset random constraint conditions.

[0167] As an optional embodiment, the device further includes: The parameter reset module is used to respond to the received reset command and restore the current value of the parameter of each parameter object to the preset flag value, so that the parameter to be configured of each parameter object is restored to the state to be randomized.

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

[0169] Below, for reference Figure 5 This 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.

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

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

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

[0173] 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 parameter configuration methods for chip verification and / or other desired functions described in the various embodiments of this disclosure above.

[0174] 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).

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

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

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

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

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

[0180] 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 parameter configuration method for chip verification according to various embodiments of this disclosure as described in the foregoing portion of this specification.

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

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

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

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

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

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

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

[0188] 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.< / t>

Claims

1. A parameter configuration method for chip verification, characterized in that, The method is applied in a chip design verification environment, wherein the chip design verification environment includes at least one configurable parameter, and includes: Each of the parameters to be configured is instantiated into a parameter object, the parameter object including a parameter name and a current parameter value, wherein the initial state value of the current parameter value is a preset flag value, the preset flag value is used to indicate that the parameter value is randomly generated; In response to receiving parameter configuration information through a preset unified configuration interface, the current value of the parameter of the corresponding parameter object is updated according to the parameter configuration information. The preset unified configuration interface supports at least two preset configuration methods. During the randomization of parameters in the chip design verification environment, for each parameter object, the parameter value of the corresponding parameter to be configured is determined based on the comparison result between its current parameter value and the preset flag value. The parameter value of each parameter to be configured is used as the configuration parameter of the algorithm function module in the chip design to drive the algorithm function module to perform simulation verification.

2. The method according to claim 1, characterized in that, The step of responding to receiving parameter configuration information through a preset unified configuration interface and updating the current value of the corresponding parameter object according to the parameter configuration information includes: The parameter configuration information is received through the preset unified configuration interface, wherein the preset unified configuration interface supports at least two of the following configuration methods: command line assignment, batch assignment of configuration files, and assignment within code, in order to configure the parameter configuration information; In response to receiving parameter configuration information from two or more configuration methods, the target configuration information is determined from the parameter configuration information received from the multiple configuration methods according to a preset priority rule; Update the current value of the parameter of the corresponding parameter object according to the target configuration information.

3. The method according to claim 2, characterized in that, The step of responding to receiving parameter configuration information from two or more configuration methods, and determining target configuration information from the parameter configuration information received from the multiple configuration methods according to a preset priority rule, includes: Obtain the priority of each configuration method, compare the priorities of the two or more configuration methods, and obtain the comparison result; Based on the comparison results, the parameter configuration information of the configuration method with the highest priority among the two or more configuration methods is determined as the target configuration information.

4. The method according to claim 2 or 3, characterized in that, The format of the command line assignment includes a preset prefix symbol, a parameter name, and a parameter value, wherein the preset prefix symbol is used as the starting point, followed by the parameter name and the parameter value, and the parameter name and the parameter value are connected by a first preset separator. The format for batch assignment of configuration files includes a preset prefix symbol, a preset configuration keyword, a configuration file path, and assignment statements within the configuration file, wherein: it begins with the preset prefix symbol, followed by the preset configuration keyword and a second preset separator, and then the configuration file path; each line of assignment statements within the configuration file includes the preset prefix symbol, a parameter name, and a parameter value, and the parameter name and the parameter value are connected by the second preset separator; The format for assigning values ​​within the code is as follows: In the test code of the verification environment, the current value of the parameter object corresponding to the parameter to be configured is assigned using an assignment statement.

5. The method according to any one of claims 1 to 3, characterized in that, During the randomization of parameters in the chip design verification environment, for each parameter object, the parameter value of the corresponding parameter to be configured is determined based on the comparison result between its current parameter value and the preset flag value. The parameter values ​​of each parameter to be configured are then used as configuration parameters for the algorithm function module in the chip design to drive the algorithm function module to perform simulation verification. This includes: For each parameter object, the current value of the parameter in the parameter object is compared with the preset flag value; In response to the current value of the parameter being equal to the preset flag value, randomization processing is performed on the parameter to be configured corresponding to the parameter object to generate a random value, which is then used as the parameter value of the parameter to be configured. In response to the fact that the current value of the parameter is not equal to the preset flag value, the current value of the parameter is directly used as the parameter value of the parameter to be configured; The parameter values ​​of each parameter to be configured are output to the algorithm function module in the chip design as configuration parameters for the algorithm function module, so as to drive the algorithm function module to perform simulation verification according to the configuration parameters.

6. The method according to claim 5, characterized in that, In response to the current value of the parameter being equal to the preset flag value, randomization processing is performed on the parameter to be configured corresponding to the parameter object to generate a random value, which is then used as the parameter value of the parameter to be configured, including: In response to the current value of the parameter being equal to the preset flag value, a preset random constraint condition is obtained for any of the parameters to be configured. The randomized solver in the chip design verification environment is invoked to generate a random value that satisfies the randomized constraints, which is then used as the parameter value for the parameter to be configured.

7. The method according to claim 6, characterized in that, The method further includes: In response to the chip design verification environment including at least two levels of algorithm function modules, each configurable parameter in the at least two levels of algorithm function modules is identified, and the parameter pair to be linked is determined. The parameter pair to be linked includes the output parameters of the front-end module and the input parameters of the back-end module, or parameters with the same function in different modules. Obtain the preset linkage constraints of the parameter pair to be linked, wherein the preset linkage constraints are preset based on the data transmission relationship between the algorithm functional modules; The preset linkage constraint is added to the random constraint set of the chip design verification environment so that the random value obtained by randomizing the parameter to be configured satisfies the preset linkage constraint and the preset random constraint. The random constraint set includes the preset random constraint.

8. The method according to any one of claims 1 to 3, characterized in that, The method further includes: In response to the received reset command, the current value of the parameter of each parameter object is restored to the preset flag value, so that the configuration parameter of each parameter object is restored to the random state.

9. A parameter configuration device for chip verification, characterized in that, Applied in a chip design verification environment, the chip design verification environment includes at least one configurable parameter, and the device includes: The parameter instantiation module is used to instantiate each of the parameters to be configured into a parameter object. The parameter object includes a parameter name and a current parameter value. The initial state value of the current parameter value is a preset flag value, which is used to indicate that the parameter value is randomly generated. The parameter update module is used to respond to receiving parameter configuration information through a preset unified configuration interface, and update the current value of the parameter of the corresponding parameter object according to the parameter configuration information. The preset unified configuration interface supports at least two preset configuration methods. The final value determination module is used to determine the parameter value of the corresponding parameter to be configured for each parameter object based on the comparison result between its current parameter value and the preset flag value during the randomization of parameters in the chip design verification environment. The parameter value of each parameter to be configured is used as the configuration parameter of the algorithm function module in the chip design to drive the algorithm function module to perform simulation verification.

10. 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-8.

11. A computer-readable storage medium storing computer program instructions 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-8.

12. 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-8.

Images