A method and apparatus for verifying an arithmetic module

Abstract

The embodiment of the application discloses a kind of verification method and device of operation module. By obtaining verification configuration information, verification configuration information includes one or more of reference model, RTL instance to be verified, tool configuration script and control script for starting verification task, tool configuration script includes one or more of input constraint, output assertion and verification flow script, in response to receiving starting instruction, running control script, to obtain verification result according to reference model, RTL instance to be verified, tool configuration script by control script, wherein, verification flow script includes one or more of compiling instruction, mapping instruction and solving instruction, and solving instruction is used to control solver to cover the whole set of input space using mathematical derivation algorithm to obtain verification result. Thus, all possible input combinations can be covered to verify the operation module, providing more reliable verification results to meet the verification needs of various scenarios.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for verifying a computing module. Background Technology

[0002] In the field of computer science, verifying the correctness of arithmetic modules is a core step in ensuring the reliability of chip functionality, especially crucial for high-reliability chip design. Existing verification methods mainly include simulation-based dynamic verification and formal verification. Dynamic verification constructs a reference model and compares the output of the register-transfer stage implementation with that of the reference model; while formal verification uses attribute assertions to deterministically verify all possible behaviors of the design.

[0003] However, these existing verification methods struggle to cover all input combinations when faced with high-dimensional inputs, offering only probabilistic guarantees of correctness, which is insufficient to meet verification requirements. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a verification method and apparatus for a computing module, which can cover all possible input combinations to verify the computing module, provide more reliable verification results, and meet the verification needs of various scenarios.

[0005] In a first aspect, embodiments of the present invention provide a method for verifying a computing module, the method comprising: Obtain verification configuration information, which includes one or more of the following: reference model, RTL instance to be verified, tool configuration script, and control script to start verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and verification process script. In response to receiving a start command, the control script is run to obtain the verification result based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of compilation instructions, mapping instructions, and solving instructions. The solving instructions are used to control the solver to use mathematical derivation algorithms to cover the entire set of the input space to obtain verification results.

[0006] In some embodiments, obtaining the verification configuration information includes: Obtain environment configuration information, which includes a directory structure, comprising a model directory, an RTL directory, a script directory, and a startup directory. The model directory is used to store the source files of the reference model, the RTL directory is used to store the code and file list of the RTL instance to be verified, the script directory is used to store the tool configuration script, and the startup directory is used to store the control script for starting the verification task. Obtain the source files of the reference model and store them in the model directory; Obtain the code and file list of the RTL instance to be verified, and store them in the RTL directory; Obtain the tool configuration script and store it in the script directory; Obtain the control script for the startup verification task and store it in the startup directory.

[0007] In some embodiments, the compilation instructions include a first compilation instruction and a second compilation instruction.

[0008] In some embodiments, the step of running the control script in response to receiving a startup command, to obtain verification results through the control script based on the reference model, the RTL instance to be verified, and the tool configuration script, includes: The first compilation instruction is invoked to compile the reference model into a first intermediate representation; The second compilation instruction is invoked to compile the RTL instance into a second intermediate representation; The mapping instruction is invoked to associate the first intermediate representation with the second intermediate representation via ports, thereby constructing a verification model; The solver instruction is invoked to perform an equivalence check on the verification model and obtain the verification result.

[0009] In some embodiments, the mapping instruction includes the correspondence between the reference model input / output ports and the RTL instance input / output ports, and the input constraints include input connection constraints; The step of invoking the mapping instruction to associate the first intermediate representation with the second intermediate representation via ports and constructing the verification model includes: According to the input connection constraints, the reference model input port in the first intermediate representation and the RTL instance input port in the second intermediate representation are bound to the same drive signal to establish an input excitation synchronization relationship. Based on the correspondence between the reference model input / output ports and the RTL instance input / output ports, the reference model output port in the first intermediate representation and the RTL instance output port in the second intermediate representation are connected to the input terminals of the comparison logic circuit. Comparison logic circuits are inserted into the first intermediate representation and the second intermediate representation after binding to generate the verification model. The comparison logic circuits are used to perform an XOR operation on the signal levels of the output port of the reference model and the output port of the RTL instance to generate a comparison result signal that characterizes the signal difference.

[0010] In some embodiments, invoking the solver instruction to perform an equivalence check on the verification model and obtaining the verification result includes: Within the input space, the completeness of the input combinations of the verification model is verified using a verification tool; In response to the verification tool outputting a verification success status that represents the logical equivalence of the verification model within the input space, a verification pass result is generated; In response to the verification tool outputting a verification failure state that characterizes a logical difference in the verification model within the input space, a verification failure result is generated.

[0011] In some embodiments, the method further includes: Receive algorithm configuration information, which includes the correspondence between algorithm rules and solution strategies. The algorithm rules are data operation types or data structure characteristics, and the solution strategies are optimization methods for processing the algorithm rules.

[0012] In some embodiments, invoking the solver instruction to perform an equivalence check on the verification model and obtaining the verification result includes: Determine the target solution strategy that matches the verification model based on the algorithm configuration information; The equivalence check is performed on the verification model based on the objective solution strategy.

[0013] In some embodiments, the method further includes: A predetermined fault verification strategy is executed to verify the verification model.

[0014] In some embodiments, the predetermined fault verification strategy includes at least one of the following: The internal XOR logic of the reference model or the RTL instance to be verified is randomly flipped by one bit; Modify the data processing order in the reference model or the RTL instance to be verified; The output of the reference model or the RTL instance to be verified is forcibly tampered with in a specific location; The specific input is processed by the reference model or the output of the RTL instance to be verified, and the specific location is tampered with.

[0015] Secondly, embodiments of the present invention provide a verification device for a computing module, the device comprising: The configuration information acquisition unit is used to acquire verification configuration information, which includes one or more of the following: reference model, RTL instance to be verified, tool configuration script, and control script to start verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and verification process script. The verification result acquisition unit is used to run the control script in response to receiving the start command, so as to obtain the verification result through the control script according to the reference model, the RTL instance to be verified, and the tool configuration script; The verification process script includes one or more of compilation instructions, mapping instructions, and solving instructions. The solving instructions are used to control the solver to use mathematical derivation algorithms to cover the entire set of the input space to obtain verification results.

[0016] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in the first aspect.

[0017] Fourthly, embodiments of the present invention provide a computer program product comprising a computer program, wherein when the computer program is run on a computer, the computer executes the method described in the first aspect above.

[0018] Fifthly, embodiments of the present invention provide a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the method described in the first aspect.

[0019] The technical solution of this invention obtains verification configuration information, which includes one or more of the following: a reference model, an RTL instance to be verified, a tool configuration script, and a control script for starting the verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and a verification process script. Upon receiving a start command, the control script is run to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results. Therefore, all possible input combinations can be covered to verify the computation module, providing more reliable verification results to meet the verification needs of various scenarios. Attached Figure Description

[0020] The above and other objects, features and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which: Figure 1 This is a flowchart of the verification method for the computing module in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the process of obtaining verification configuration information according to an embodiment of the present invention; Figure 3This is a flowchart of obtaining verification results according to an embodiment of the present invention; Figure 4 This is a flowchart of constructing a verification model according to an embodiment of the present invention; Figure 5 This is a flowchart of obtaining verification results according to an embodiment of the present invention; Figure 6 This is a flowchart of the fault verification process according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the verification system according to an embodiment of the present invention; Figure 8 This is a flowchart of the verification device for the computing module in an embodiment of the present invention; Figure 9 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0021] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the substance of the present application, well-known methods, processes, flows, elements, and circuits are not described in detail.

[0022] Furthermore, those skilled in the art should understand that the accompanying drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0023] Unless the context explicitly requires it, words such as "including" or "contains" throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, meaning "including but not limited to".

[0024] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0025] The solutions described in this specification and embodiments, if involving the processing of personal information, will be processed only on the premise of having a legal basis (such as obtaining the consent of the personal information subject, or being necessary for the performance of a contract), and will only be processed within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0026] With the development of chip technology, the computing module, as a core component of the chip's data path, directly determines the reliability and stability of the entire system through its functional correctness. Especially in critical areas such as deep learning inference, scientific computing, and encryption / decryption, even minute computational errors can trigger a chain reaction, leading to system-level failures. Therefore, performing high-coverage, high-deterministic functional verification of the computing module has become a crucial step in chip front-end design.

[0027] Currently, the mainstream verification methods are mainly implemented through simulation-based verification or formal property verification (FPV).

[0028] In dynamic simulations, designers implement the computational logic using hardware description languages ​​(such as Verilog), while verification engineers build high-precision reference models. By applying numerous random or directed stimuli, they compare the output of the Register Transfer Level (RTL) implementation with the computation results of the reference model to confirm functional consistency. However, with the continuous increase in computational bit width, such as 1280 bits or even wider data paths, the input space grows exponentially, making it impossible to exhaust all possible input combinations, especially boundary conditions, special numerical combinations, or rare carry propagation paths. This results in insufficient code coverage, making it impossible to rule out the possibility of logical errors under specific inputs. The verification results can only provide a guarantee of "probabilistic correctness" rather than "deterministic correctness."

[0029] Formal verification, based on mathematical reasoning, describes the properties that the design should satisfy by writing assertions, and tools automatically verify whether these properties hold true under all possible input sequences. Unlike simulation, FPV does not rely on test vectors, and its conclusions are deterministic, proving that a property will never be violated in the design, or locating the specific path leading to a violation. However, when FPV is applied to high-dimensional data path-type computation modules, its capabilities are significantly limited. Due to the complex nonlinear transformations of data paths, large-width logic operations, and deep combinational logic, the state space remains enormous, and formal verification tools face the "state explosion" problem, leading to convergence difficulties or even failure to complete verification. Furthermore, writing complete and provable assertions for such complex computational logic is challenging in itself, often requiring a very high level of abstraction, sacrificing verification accuracy.

[0030] Therefore, this embodiment of the invention provides a verification method for a computing module to solve the above problems.

[0031] The computation module is a collection of hardware logic circuits built based on specific algorithms, designed to efficiently execute predetermined mathematical transformations or logical processing tasks. This computation module may include a Cyclic Redundancy Check (CRC) module, an Error Checking and Correcting (ECC) module, a Forward Error Correction (FEC) module, a hash operation unit, or a symmetric / asymmetric encryption / decryption engine. These modules typically exhibit simple sequential logic but dense combinational logic, employing numerous standard units such as AND gates, OR gates, NOT gates, XOR gates, and adders in parallel construction to complete complex data throughput and processing within extremely short clock cycles. They are widely integrated into various processors, dedicated security chips, or network interface controllers, replacing software algorithms to perform data integrity checks, error correction, or information encryption / decryption operations through hardware acceleration. The computation module effectively reduces the computational load on the main processor, significantly improving the system's data processing speed, communication reliability, and information transmission security.

[0032] This embodiment of the invention uses a CRC module as an example for illustration. A CRC module is a hardware logic circuit unit based on a cyclic redundancy check algorithm. Its core function is to perform integrity verification on the data stream to detect bit errors during transmission or storage. The CRC module typically integrates a shift register, an XOR logic gate array, and a generator polynomial configuration register. Its circuit design is based on the principle of modulo-2 division. During operation, the CRC module treats the input binary data stream as a sequence of polynomial coefficients and performs division according to a preset generator polynomial. The remainder is a fixed-length checksum. The sending end appends this checksum to the original data for transmission, and the receiving end uses the same CRC module to perform the same modulo-2 division operation on the received complete data frame. If the result is zero, it is determined that no single-bit, double-bit, multi-bit, or burst errors occurred during data transmission, thereby ensuring the reliability and integrity of data communication.

[0033] Figure 1 This is a flowchart of the verification method for the computing module in an embodiment of the present invention. For example... Figure 1 As shown, the verification method for the computing module in this embodiment of the invention includes the following steps: Step S100: Obtain verification configuration information. The verification configuration information includes one or more of the following: reference model, RTL instance to be verified, tool configuration script, and control script to start verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and verification process script.

[0034] The reference model, a C++ reference model source file, is a collection of software code written in a high-level programming language to describe the intended functionality of the design. This reference model typically serves as a reference standard or functional benchmark in the verification environment. It does not contain hardware timing information and focuses on accurately describing the design's algorithmic behavior, data flow transformations, and input-output relationships. During formal or functional verification, verification tools perform equivalence checks or functional comparisons between the RTL (Register Transfer Level) instance to be verified and this reference model. The reference model, through clearly defined input / output interfaces, receives the same stimulus data as the RTL design and uses its computational results as expected values ​​to automatically compare and determine the functional correctness of the RTL design, thereby ensuring consistency between the hardware implementation and system specifications at the abstraction level.

[0035] RTL (Real-Time Description) is an abstract description of digital circuits written in a hardware description language, modeled at the register-transfer level. Using clock cycles as the basic unit, RTL descriptions explicitly define the data transfer paths between hardware registers and the combinational logic operations performed during transmission. Its core components include sequential logic units (such as flip-flops) for temporary data storage and combinational logic circuits (such as adders and multiplexers) for performing logic transformations. As a bridge connecting high-level algorithm design and low-level physical implementation, RTL descriptions possess sufficient abstraction for designers to perform functional verification and architecture exploration, while also possessing sufficient precision to support logic synthesis tools in automatically converting them into gate-level netlists. Through RTL design, engineers can efficiently build complex digital systems in code and achieve design reuse and portability without relying on specific technology libraries.

[0036] A verified RTL instance includes the RTL code to be verified and its file list. It is a collection of source code written in a hardware description language (HDL) and its organizational index, describing the structure and behavior of digital circuits. The RTL code typically uses languages ​​such as Verilog, SystemVerilog, or VHDL to abstractly define registers, combinational logic, data paths, and control signals in the circuit at the register-transfer level. The file list explicitly specifies the source file paths and compilation order of the top-level module and all its sub-modules and functional units, and is a necessary input for verification or synthesis tools to read design information. The RTL code to be verified is the core object of the verification activity. Its logical function, timing characteristics, and code quality will be rigorously checked through simulation, formal verification, or static timing analysis to ensure that it conforms to design specifications and can be correctly mapped to the target hardware process.

[0037] The tool configuration script is in TCL (Tool Command Language) format. TCL is a set of control instructions written in a tool command language to define verification environment parameters and execution flows. Leveraging the ease of learning, cross-platform compatibility, and extensibility of the TCL language, the tool configuration script automates the configuration of the verification tool's behavior. It includes one or more of input constraints, output assertions, and verification flow scripts. Input constraints ensure that the inputs of the RTL instance to be verified are consistent with the inputs of the reference model. In some scenarios, they can also limit the value range and timing relationships of design input port signals. Output assertions check that the outputs of the RTL instance to be verified are consistent with the outputs of the reference model, supporting timing comparisons. The verification flow script consists of verification flow control commands that specify the specific steps and strategies for the tool to perform formal verification, simulation, or coverage analysis. By executing this TCL script, verification engineers can automatically build the verification environment, load design files or design modules, apply stimuli and checkpoints, and drive the verification tool to complete predetermined verification tasks, thereby significantly improving verification efficiency and repeatability.

[0038] The control script for initiating the verification task is an executable program used to automatically trigger and manage the entire verification process. This control script typically exists in the form of a Shell script, Python script, or batch file. As the main entry point for the verification process, it coordinates and calls various underlying electronic design automation tools and auxiliary programs. Upon receiving a user instruction, the control script for initiating the verification task sequentially executes a series of operations, including environment initialization, variable setting, calling TCL-formatted tool configuration scripts, starting the formal verification or simulation engine, monitoring the task's running status, and collecting and organizing logs and waveform data. This encapsulates the complex and tedious manual verification steps into a single automated command, ensuring that the verification task can run stably in a unified and repeatable environment and facilitating integration into continuous integration and continuous deployment automated development and operations pipelines.

[0039] Figure 2 This is a flowchart illustrating the process of obtaining verification configuration information according to an embodiment of the present invention. For example... Figure 2 As shown, obtaining the verification configuration information includes the following steps: Step S110: Obtain environment configuration information. The environment configuration information includes a directory structure, which includes a model directory, an RTL directory, a script directory, and a startup directory. The model directory is used to store the source files of the reference model. The RTL directory is used to store the code and file list of the RTL instance to be verified. The script directory is used to store the tool configuration script. The startup directory is used to store the control script for starting the verification task.

[0040] In this embodiment, the computer acquires environment configuration information input by the user. Specifically, the user sets up the verification environment using the command-line tool or file manager built into the computer's operating system. The environment configuration information includes a directory structure, which comprises a model directory, an RTL directory, a script directory, and a startup directory.

[0041] The model directory stores the source files of the reference model. The RTL directory stores the code and file list of the RTL instances to be verified. The script directory stores the tool configuration scripts. The startup directory stores the control scripts for starting the verification task.

[0042] Step S120: Obtain the source file of the reference model and store it in the model directory.

[0043] In this embodiment, the CRC module with a 1280-bit input space is used as an example for illustration. A C++ reference model is developed, and a main function named crc_spec is implemented to receive 1280-bit input data data_in and output a 32-bit CRC check result data_out. The source files of the reference model are stored in the model directory.

[0044] The reference model registers input and output signals through the encapsulated interfaces `registerInput` and `registerOutput` provided by HECTOR, and uses the `beginCapture` and `endCapture` macros to define the sampling interval, ensuring temporal semantic alignment with RTL behavior. Specifically, in the verification environment, the verification tool determines the consistency between the input of the C++ reference model and the input of the RTL instance to be verified based on `registerInput(data_in)`, and determines the consistency between the output of the C++ reference model and the output of the RTL instance to be verified based on `registerOutput(data_out)`. Hector (High-level Equivalence C++ to RTL) is a dedicated formal verification solution from Synopsys VC Formal that supports automatic equivalence verification between C / C++ high-level language specification models and RTL implementations.

[0045] Furthermore, this embodiment of the invention uses the macro definitions `beginCapture` and `endCapture` as delimiters for the sampling interval to achieve timing semantic alignment between the verification reference model and the register-transfer-level (RTL) hardware description. Given that the reference model is typically based on just-in-time (JIT) execution mechanisms, while hardware RTL designs often include pipeline architectures, logic propagation delays, and cross-clock-cycle processing, there are objective differences in response latency between the two. Therefore, this embodiment of the invention introduces the delimiters to construct a timing-independent logic observation window in the verification environment. Thus, when performing the comparison, the verification tool ignores the specific execution timing differences within the macro-defined interval and only verifies the final value of the output variable `data_out` at the interval's termination time (i.e., when `endCapture` is triggered). This effectively avoids false alarms caused by the inconsistency between the reference model's computation speed and the RTL hardware execution clock, thereby improving the accuracy and robustness of functional verification.

[0046] Step S130: Obtain the code and file list of the RTL instance to be verified, and store them in the RTL directory.

[0047] In this embodiment, the code and file list of the RTL instance to be verified provided by the user are obtained and stored in the RTL directory rtl.

[0048] Step S140: Obtain the tool configuration script and store it in the script directory.

[0049] In this embodiment, the tool configuration script provided by the user is obtained and stored in the script directory.

[0050] Step S150: Obtain the control script for the startup verification task and store it in the startup directory sim.

[0051] In this embodiment, the control script for the user-provided startup verification task is obtained and stored in the startup directory sim.

[0052] In summary, first, a standardized directory structure is created, then the source code, configuration files, and startup scripts are placed in their respective directories, and finally, the verification is completed using a script-driven verification tool.

[0053] In this embodiment of the invention, the verification tool is Synopsys VC Formal. Synopsys VC Formal is a powerful formal verification platform that does not rely on traditional simulation stimuli but uses mathematical algorithms to exhaustively prove or disprove the correctness of chip designs.

[0054] Step S200: In response to receiving the start command, run the control script to obtain the verification result based on the reference model, the RTL instance to be verified, and the tool configuration script; wherein, the verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions.

[0055] In this embodiment, after obtaining the verification configuration information, the verification process can be initiated. Specifically, the user inputs a startup command to run the control script. The control script includes the command body, file path, specified mode, and startup interface command. For example, the control script could be `vcf -f .. / scripts / hector_common_cfg_script.tcl -fmode DPV -gui&`. Here, "vcf" is the command body, used to instruct the operating system to enable the vcf tool, that is, to start the Synopsys VC Formal tool. The "-f" parameter instructs the verification tool to read and execute a script file. "scripts / hector_common_cfg_script.tcl" is the file path, where `scripts` is the script directory and `hector_common_cfg_script.tcl` is the tool configuration script. "fmodeDPV" specifies the mode, where "fmode" specifies the front-end mode of the verification tool, and "DPV" specifies that the current task is Data Path Verification. "gui" is used to instruct the verification tool to launch a graphical user interface (GUI). "&" is a Linux / Unix shell operator that indicates that the program should run in the background. In other words, after launching the VC Formal graphical interface, the current command line window will not be blocked, and the user can continue to enter other commands in this window.

[0056] The user can input a startup command, such as a startup directory (sim). The user can edit a command to run the control script within that directory. After inputting the startup command, the control script for the startup verification task is executed. During this process, the control script launches the VC Formal verification tool, which reads the hector_common_cfg_script.tcl script in the script directory and completes the configuration of the verification environment (reading the design, setting constraints, etc.) according to its instructions. Then, based on the -fmode DPV setting, the verification tool enters the professional mode for data path verification, preparing for equivalence checks. Finally, the verification tool displays an interactive interface where the user can perform interactive verification operations, such as clicking the "Start Run" control to begin verification.

[0057] Furthermore, users can configure the solution strategy within the interactive interface. That is, the computer receives algorithm configuration information, which includes the correspondence between algorithm rules and solution strategies. The algorithm rules are data operation types or data structure characteristics, and the solution strategy is an optimization method for processing the algorithm rules. Specifically, in the `hector_multiple_solve_scripts_list` setting of the interactive interface, users can select the `orch_multipliers` option for operations such as multipliers and polynomials, the `orch_custom_decompose` option for ultra-wide data paths and modular structures, and the `orch_custom_bit_operations` option for bit operation logic. Here, multipliers, polynomials, ultra-wide data paths and modular structures, and bit operation logic are all algorithm rules, while `orch_multipliers`, `orch_custom_decompose`, and `orch_custom_bit_operations` are all solution strategies.

[0058] Among them, orch_multipliers is a strategy for multipliers and multinomials. It can use the logic of Booth encoding or lookup table (LUT) to simulate multiplication, or break down the multiplication operation into a series of shift and addition operations.

[0059] orch_custom_decompose is a dedicated strategy for ultrawide data and modularity. The verification tool will enable bit-slicing or modular decomposition strategies.

[0060] `orch_custom_bit_operations` is a dedicated strategy for bit manipulation logic. The verification tool will switch to a bit-precise processing mode, forcing the solver to focus on the flips and logical relationships of each bit, rather than treating it as a whole value.

[0061] After configuring the interface, users can click the "Start Run" control to trigger the execution of the verification process script in the tool's configuration script. This verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions.

[0062] Figure 3 This is a flowchart illustrating the process of obtaining verification results according to an embodiment of the present invention. For example... Figure 3 As shown, the step of responding to a startup command by running the control script to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script includes the following steps: Step S210: Invoke the first compilation instruction to compile the reference model into a first intermediate representation.

[0063] In this embodiment, the compilation instructions include a first compilation instruction and a second compilation instruction. The first compilation instruction is used to compile the reference model, and the second compilation instruction is used to compile the RTL instance to be verified. First, the first compilation instruction is invoked to compile the reference model into a first intermediate representation.

[0064] Specifically, the core of the verification tool is a mathematical solver, which cannot directly read C++ source code. The C++ language contains many complex features (such as dynamic memory allocation, complex class inheritance, and standard library functions), which are convenient for describing hardware algorithms but too complex and ambiguous for tools requiring mathematical proofs. The first compiler instruction is invoked to check the code's syntax and variable types, ensuring the code itself is valid. Then, the source code of the reference model is analyzed and transformed. The verification tool converts the C++ code into a subset of C / C++ it supports, typically containing only synthesizable, deterministic language features. After analysis and transformation, the verification tool generates an internal, hardware-independent intermediate representation (IR). This IR is a precise, mathematical functional description that strips away the C++ language shell, retaining only the core algorithmic logic.

[0065] Step S220: Invoke the second compilation instruction to compile the RTL instance into a second intermediate representation.

[0066] In this embodiment, the second compilation instruction is invoked to compile the RTL instance into a second intermediate representation. The method for obtaining the second intermediate representation is similar to the method for obtaining the first intermediate representation described above, and will not be repeated here.

[0067] It should be noted that the execution order of steps S210 and S220 is not distinguished; they can be executed sequentially or sequentially.

[0068] Step S230: Invoke the mapping instruction to associate the first intermediate representation with the second intermediate representation via ports, and construct a verification model.

[0069] In this embodiment, the mapping instruction includes the correspondence between the input / output ports of the reference model and the input / output ports of the RTL instance, and the input constraints include input connection constraints. By invoking the mapping instruction, and based on the correspondence and the input connection constraints, the first intermediate representation and the second intermediate representation are associated with ports to construct a verification model.

[0070] Figure 4 This is a flowchart illustrating the construction and verification model of an embodiment of the present invention. For example... Figure 4 As shown, the step of invoking the mapping instruction to associate the first intermediate representation with the second intermediate representation via ports and constructing the verification model includes the following steps: Step S231: According to the input connection constraints, bind the reference model input port in the first intermediate representation and the RTL instance input port in the second intermediate representation to the same drive signal to establish an input excitation synchronization relationship.

[0071] In this embodiment, the tool configuration script includes input constraints, including input connection constraints. The input connection constraint states that the input signal `spec.data_in` of the reference model is equal to the input signal `impl.data_in` of the RTL instance, i.e., `spec.data_in = impl.data_in`. Therefore, according to the input connection constraints, the input port of the reference model in the first intermediate representation and the input port of the RTL instance in the second intermediate representation are bound to the same drive signal to establish an input stimulus synchronization relationship, making the input signal `spec.data_in` of the reference model equal to the input signal `impl.data_in` of the RTL instance. This ensures that the first and second intermediate representations process the exact same data, and any differences in output can only be attributed to errors in the logic implementation, not to differences in the inputs.

[0072] Step S232: Based on the correspondence between the reference model input / output ports and the RTL instance input / output ports, connect the reference model output port in the first intermediate representation and the RTL instance output port in the second intermediate representation to the input terminal of the comparison logic circuit.

[0073] Step S233: Insert comparison logic circuits into the first intermediate representation and the second intermediate representation after binding to generate the verification model. The comparison logic circuits are used to perform an XOR operation on the signal levels of the output port of the reference model and the output port of the RTL instance to generate a comparison result signal that characterizes the signal difference.

[0074] In this embodiment, when generating mapping instructions, it is necessary to define the correspondence between the input / output ports of the reference model and the input / output ports of the RTL instance. Based on this correspondence, the output signal pairs to be compared are identified. For each output signal pair, a comparison logic circuit (e.g., an XOR gate) is instantiated. The two inputs of the comparison logic circuit are the outputs of the first intermediate representation and the second intermediate representation, respectively. The output of the comparison logic circuit is the comparison result signal. The constructed input driving network, the first intermediate representation, the second intermediate representation, and the comparison logic circuit are packaged into a single module, i.e., the verification model. The solver instructions are used to control the solver to use mathematical derivation algorithms to cover the entire input space to obtain the verification result.

[0075] Step S240: Call the solver instruction to perform an equivalence check on the verification model and obtain the verification result.

[0076] In this embodiment, the solver instruction is invoked to perform an equivalence check on the verification model and obtain the verification result. The solver instruction controls the solver to use mathematical derivation algorithms to cover the entire input space to obtain the verification result. The solver is a software engine within the verification tool; it uses mathematical derivation algorithms to transform the circuit design into a system of Boolean logic equations and automatically finds variable assignments that satisfy specific constraints (i.e., counterexamples) or proves that the system of equations has no solution (i.e., the design is correct).

[0077] Ideally, for any input signal, the first and second intermediate representations should produce the same result after processing. Therefore, the comparison logic circuit outputs 0 (invalid level) after the XOR operation. Thus, the solver attempts to search for an input signal that will cause the comparison logic circuit to output 1 (valid level).

[0078] Specifically, Figure 5 This is a flowchart illustrating the process of obtaining verification results according to an embodiment of the present invention. For example... Figure 5As shown, the process of calling the solver instruction to perform an equivalence check on the verification model and obtaining the verification result includes the following steps: Step S241: Within the input space, the completeness of the input combination of the verification model is verified using a verification tool.

[0079] In this embodiment, the completeness verification refers to transforming the logical relationships of the verification model into mathematical constraint equations and using a formal verification solver to perform full-space logic solving on the input space. Further, the completeness verification is used to mathematically prove whether the comparison result signal of the verification model is consistently at an invalid level under all input combinations within the input space.

[0080] Specifically, the solution objective is first to find a set of input variable values ​​(0 or 1) in the input space such that the logic equation of the entire circuit is true and the final comparison logic circuit outputs 1.

[0081] Then, the solver instantiates variables, translating the verification model (i.e., the complete circuit consisting of the first intermediate representation, the second intermediate representation, and the comparison logic circuit) into mathematical variables. For the 1280-bit input data_in, the solver does not treat it as a single number, but rather as 1280 independent Boolean variables X = {x0, x1, x2, ..., xn}. 1279}, where x i =0 or 1, i=1, 2, 3, ..., 1279. The output of each logic gate (AND gate, OR gate, NOT gate, adder) in the verification model is defined as an intermediate variable.

[0082] Next, constraint propagation and logical deduction are performed, filling in and eliminating blanks based on the circuit structure. For example, suppose there is a simple logic in the circuit: out = a AND b, and the goal is to make out = 1. The solver will determine that a must be 1 and b must be 1. It does not need to try the cases where a = 0 or b = 0, because that would lead to a contradiction. If, during the deduction process, the solver finds a signal that must be both 0 and 1, it will determine that the current path has no solution and immediately backtrack. Then, decision-making and backtracking are performed. When the logical deduction cannot determine the value of a variable (i.e., the variable is free), the solver will make a decision, select a variable (e.g., x0), and assume it is 1; continue the deduction, based on x0 = 1, and continue to deduce the subsequent logic. If a case is found where the comparison logic circuit outputs 1, it indicates that a counterexample has been found.

[0083] If a contradiction is found (e.g., leading to 0=1), backtrack, retract the previous assumption, and try x0=0. If x0=0 also leads to a contradiction, it means that a previous decision was wrong, and the backtracking continues upwards.

[0084] In some embodiments, the input constraints further include input range constraints, which are mathematical restrictions placed on the legal value space of the design input data during the verification process. These input range constraints allow the solver to consider only input values ​​that meet the constraints when searching all possible input states, ignoring values ​​that are impossible in actual hardware applications, thereby further improving verification efficiency.

[0085] Step S242: In response to the verification tool outputting a verification success state that characterizes the logical equivalence of the verification model within the input space, a verification pass result is generated.

[0086] Step S243: In response to the verification tool outputting a verification failure state that characterizes the logical difference between the verification model and the input space, a verification failure result is generated.

[0087] In this embodiment, in response to the comparison result signal being consistently at an invalid level (0) within the input space, the verification tool outputs a successful verification state characterizing the logical equivalence of the verification model within the input space, generating a verification pass result. In response to finding an input vector within the input space that makes the comparison result signal an effective level (1), the verification tool outputs a failed verification state characterizing the logical difference between the verification model and the input space, generating a verification failure result.

[0088] Furthermore, after the user configures the solution strategy, the step of calling the solution instruction to perform an equivalence check on the verification model and obtain the verification result includes: determining a target solution strategy that matches the verification model based on the algorithm configuration information; and performing an equivalence check on the verification model based on the target solution strategy.

[0089] Furthermore, the verification results are displayed through the interactive interface.

[0090] This invention, through the acquisition of verification configuration information, includes one or more of the following: a reference model, an RTL instance to be verified, a tool configuration script, and a control script for initiating the verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and a verification process script. Upon receiving a start command, the control script is run to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results. Therefore, all possible input combinations can be covered to verify the computation module, providing more reliable verification results to meet the verification needs of various scenarios.

[0091] In some embodiments, the verification method further includes: Step S300: Execute the predetermined fault verification strategy to verify the verification model.

[0092] In this embodiment, fault verification is performed by actively and in a controlled manner introducing errors into the system to verify the system's robustness and fault tolerance.

[0093] Specifically, Figure 6 This is a flowchart of fault verification according to an embodiment of the present invention. For example... Figure 6 As shown, executing a predetermined fault verification strategy to verify the verification model includes at least one of the following steps: Step S310: Randomly flip one bit of the internal XOR logic of the reference model or the RTL instance to be verified.

[0094] In this embodiment, randomly flipping one bit of the internal XOR logic of the reference model or the RTL instance to be verified can simulate a single-bit flip or soft error in the hardware.

[0095] Step S320: Modify the data processing order in the reference model or the RTL instance to be verified.

[0096] In this embodiment, modifying the data processing order in the reference model or the RTL instance to be verified can simulate systemic design flaws or control flow errors.

[0097] Step S330: Forcefully tamper with the specific location of the output of the reference model or the RTL instance to be verified.

[0098] In this embodiment, by forcibly altering the specific location of the output of the reference model or the RTL instance to be verified, it is possible to simulate a faulty module sending erroneous data to other parts of the system.

[0099] Step S340: Modify the specific location of the specific input after passing through the reference model or the RTL instance to be verified.

[0100] In this embodiment, by altering the output of a specific input through the reference model or the RTL instance to be verified, a communication error that would only occur under specific operating conditions can be simulated.

[0101] Furthermore, if the output assertion failure is successfully triggered after performing any of the above fault verification operations, it proves that the verification model of this embodiment of the invention has high sensitivity and strong error detection capability.

[0102] This invention, through the acquisition of verification configuration information, includes one or more of the following: a reference model, an RTL instance to be verified, a tool configuration script, and a control script for initiating the verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and a verification process script. Upon receiving a start command, the control script is run to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results. Therefore, all possible input combinations can be covered to verify the computation module, providing more reliable verification results to meet the verification needs of various scenarios.

[0103] Figure 7 This is a schematic diagram of the verification system according to an embodiment of the present invention. Figure 7 As shown, the verification system of this embodiment includes a first compilation module 11, a second compilation module 12, a mapping module 13, an input module 14, an output module 15, and a solution module 16.

[0104] The first compilation module 11 is used to compile the reference model into a first intermediate representation.

[0105] The second compilation module 12 is used to compile the RTL instance into a second intermediate representation.

[0106] The mapping module 13 is used to bind the reference model input port in the first intermediate representation and the RTL instance input port in the second intermediate representation to the same drive signal to establish an input excitation synchronization relationship. Based on the correspondence between the reference model input / output ports and the RTL instance input / output ports, the reference model output port in the first intermediate representation and the RTL instance output port in the second intermediate representation are connected to the input terminals of the comparison logic circuit. The comparison logic circuit is then inserted into the bound first and second intermediate representations to generate the verification model. The comparison logic circuit performs an XOR operation on the signal levels of the reference model output port and the RTL instance output port to generate a comparison result signal characterizing the signal difference.

[0107] Input module 14 is used to limit the input signal spec.data_in of the reference model to be equal to the input signal impl.data_in of the RTL instance.

[0108] Output module 15 is used to limit the output signal spec.data_out of the reference model to be equal to the output signal impl.data_out of the RTL instance.

[0109] The solver module 16 is used to perform equivalence checks on the verification model through the solver and obtain the verification results.

[0110] Furthermore, within the input space, the completeness of the input combinations of the verification model is verified; in response to the verification tool outputting a successful verification state indicating logical equivalence of the verification model within the input space, a verification pass result is generated; in response to the verification tool outputting a failed verification state indicating logical differences in the verification model within the input space, a verification failure result is generated.

[0111] This invention, through the acquisition of verification configuration information, includes one or more of the following: a reference model, an RTL instance to be verified, a tool configuration script, and a control script for initiating the verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and a verification process script. Upon receiving a start command, the control script is run to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results. Therefore, all possible input combinations can be covered to verify the computation module, providing more reliable verification results to meet the verification needs of various scenarios.

[0112] Figure 8 This is a flowchart of the verification device for the computing module in an embodiment of the present invention. Figure 8 As shown, the verification device of this embodiment includes a configuration information acquisition unit 81 and a verification result acquisition unit 82. The configuration information acquisition unit 81 acquires verification configuration information, which includes one or more of a reference model, an RTL instance to be verified, a tool configuration script, and a control script for starting the verification task. The tool configuration script includes one or more of input constraints, output assertions, and a verification process script. The verification result acquisition unit 82, in response to receiving a start command, runs the control script to acquire verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results.

[0113] This invention, through the acquisition of verification configuration information, includes one or more of the following: a reference model, an RTL instance to be verified, a tool configuration script, and a control script for initiating the verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and a verification process script. Upon receiving a start command, the control script is run to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results. Therefore, all possible input combinations can be covered to verify the computation module, providing more reliable verification results to meet the verification needs of various scenarios.

[0114] Figure 9 This is a schematic diagram of an electronic device according to an embodiment of the present invention. In this embodiment, the electronic device 9 includes a server, a terminal, etc. Figure 9 As shown, the electronic device 9 includes at least one processor 91; a memory 92 communicatively connected to at least one processor 91; and a communication component 93 communicatively connected to a scanning device, the communication component 93 receiving and transmitting data under the control of the processor 91; wherein the memory 92 stores instructions executable by at least one processor 91, the instructions being executed by at least one processor 91 to implement the above verification method.

[0115] Specifically, the electronic device includes: one or more processors 91 and a memory 92. Figure 9 Taking a processor 91 as an example, the processor 91 and the memory 92 can be connected via a bus or other means. Figure 9 Taking a bus connection as an example, memory 92, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Processor 91 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions, and modules stored in memory 92, thus implementing the aforementioned verification method.

[0116] The memory 92 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store an option list, etc. Furthermore, the memory 92 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 92 may optionally include memory remotely located relative to the processor 91, and these remote memories may be connected to external devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0117] One or more modules are stored in memory 92, and when executed by one or more processors 91, they perform the verification method in any of the above method embodiments.

[0118] The above-mentioned products can perform the methods provided in the embodiments of this application, and have the corresponding functional modules and beneficial effects of performing the methods. For technical details not described in detail in this embodiment, please refer to the methods provided in the embodiments of this application.

[0119] This invention, through the acquisition of verification configuration information, includes one or more of the following: a reference model, an RTL instance to be verified, a tool configuration script, and a control script for initiating the verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and a verification process script. Upon receiving a start command, the control script is run to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of the following: compilation instructions, mapping instructions, and solving instructions. The solving instructions control the solver to use mathematical derivation algorithms to cover the entire input space to obtain verification results. Therefore, all possible input combinations can be covered to verify the computation module, providing more reliable verification results to meet the verification needs of various scenarios.

[0120] Another embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program for use by a computer to execute some or all of the above-described method embodiments.

[0121] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0122] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A verification method for a computing module, characterized in that, The method includes: Obtain verification configuration information, which includes one or more of the following: reference model, RTL instance to be verified, tool configuration script, and control script to start verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and verification process script. In response to receiving a start command, the control script is run to obtain the verification result based on the reference model, the RTL instance to be verified, and the tool configuration script. The verification process script includes one or more of compilation instructions, mapping instructions, and solving instructions. The solving instructions are used to control the solver to use mathematical derivation algorithms to cover the entire set of the input space to obtain verification results.

2. The method according to claim 1, characterized in that, The process of obtaining the verification configuration information includes: Obtain environment configuration information, which includes a directory structure, comprising a model directory, an RTL directory, a script directory, and a startup directory. The model directory is used to store the source files of the reference model, the RTL directory is used to store the code and file list of the RTL instance to be verified, the script directory is used to store the tool configuration script, and the startup directory is used to store the control script for starting the verification task. Obtain the source files of the reference model and store them in the model directory; Obtain the code and file list of the RTL instance to be verified, and store them in the RTL directory; Obtain the tool configuration script and store it in the script directory; Obtain the control script for the startup verification task and store it in the startup directory.

3. The method according to claim 1, characterized in that, The compilation instructions include a first compilation instruction and a second compilation instruction.

4. The method according to claim 3, characterized in that, The step of responding to a startup command by running the control script to obtain verification results based on the reference model, the RTL instance to be verified, and the tool configuration script includes: The first compilation instruction is invoked to compile the reference model into a first intermediate representation; The second compilation instruction is invoked to compile the RTL instance into a second intermediate representation; The mapping instruction is invoked to associate the first intermediate representation with the second intermediate representation via ports, thereby constructing a verification model; The solver instruction is invoked to perform an equivalence check on the verification model and obtain the verification result.

5. The method according to claim 4, characterized in that, The mapping instructions include the correspondence between the input / output ports of the reference model and the input / output ports of the RTL instance, and the input constraints include input connection constraints; The step of invoking the mapping instruction to associate the first intermediate representation with the second intermediate representation via ports and constructing the verification model includes: According to the input connection constraints, the reference model input port in the first intermediate representation and the RTL instance input port in the second intermediate representation are bound to the same drive signal to establish an input excitation synchronization relationship. Based on the correspondence between the reference model input / output ports and the RTL instance input / output ports, the reference model output port in the first intermediate representation and the RTL instance output port in the second intermediate representation are connected to the input terminals of the comparison logic circuit. Comparison logic circuits are inserted into the first intermediate representation and the second intermediate representation after binding to generate the verification model. The comparison logic circuits are used to perform an XOR operation on the signal levels of the output port of the reference model and the output port of the RTL instance to generate a comparison result signal that characterizes the signal difference.

6. The method according to claim 4, characterized in that, The step of invoking the solver instruction to perform an equivalence check on the verification model and obtaining the verification result includes: Within the input space, the completeness of the input combinations of the verification model is verified using a verification tool; In response to the verification tool outputting a verification success status that represents the logical equivalence of the verification model within the input space, a verification pass result is generated; In response to the verification tool outputting a verification failure state that characterizes a logical difference in the verification model within the input space, a verification failure result is generated.

7. The method according to claim 4, characterized in that, The method further includes: Receive algorithm configuration information, which includes the correspondence between algorithm rules and solution strategies. The algorithm rules are data operation types or data structure characteristics, and the solution strategies are optimization methods for processing the algorithm rules.

8. The method according to claim 7, characterized in that, The step of invoking the solver instruction to perform an equivalence check on the verification model and obtaining the verification result includes: Determine the target solution strategy that matches the verification model based on the algorithm configuration information; The equivalence check is performed on the verification model based on the objective solution strategy.

9. The method according to claim 4, characterized in that, The method further includes: A predetermined fault verification strategy is executed to verify the verification model.

10. The method according to claim 9, characterized in that, The predetermined fault verification strategy includes at least one of the following: The internal XOR logic of the reference model or the RTL instance to be verified is randomly flipped by one bit; Modify the data processing order in the reference model or the RTL instance to be verified; The output of the reference model or the RTL instance to be verified is forcibly tampered with in a specific location; The specific input is processed by the reference model or the output of the RTL instance to be verified, and the specific location is tampered with.

11. A verification device for a computing module, characterized in that, The device includes: The configuration information acquisition unit is used to acquire verification configuration information, which includes one or more of the following: reference model, RTL instance to be verified, tool configuration script, and control script to start verification task. The tool configuration script includes one or more of the following: input constraints, output assertions, and verification process script. The verification result acquisition unit is used to run the control script in response to receiving the start command, so as to obtain the verification result through the control script according to the reference model, the RTL instance to be verified, and the tool configuration script; The verification process script includes one or more of compilation instructions, mapping instructions, and solving instructions. The solving instructions are used to control the solver to use mathematical derivation algorithms to cover the entire set of the input space to obtain verification results.

12. An electronic device comprising a memory and a processor, characterized in that, The memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in any one of claims 1-10.

13. A computer program product comprising a computer program, characterized in that, When the computer program is run on a computer, the computer performs the method according to any one of claims 1-10.

14. A computer-readable storage medium storing computer program instructions thereon, characterized in that, The computer program instructions, when executed by a processor, implement the method as described in any one of claims 1-10.

Images