Verification method, computing device and verification system

Abstract

The embodiment of the invention provides a verification method, computing equipment and a verification system. The verification method comprises the following steps: acquiring operation information of a to-be-verified processing unit; carrying out convergence anomaly analysis on the operation information, and determining a convergence anomaly operator in the to-be-verified processing unit; based on the operator type of the convergence anomaly operator, a target verification tool corresponding to the operator type is called to verify the convergence anomaly operator, a verification result is obtained, the target verification tool is constructed based on a convergence constraint corresponding to the operator type, and the convergence constraint is used for constraining the complexity of verifying the convergence anomaly operator. The verification quality is effectively improved, and the convergence speed of the verification process can be accelerated by optimizing the verification complexity of the convergence anomaly operator, so that the verification period is shortened, and the verification efficiency is improved. In addition, the innovation scheme provided by the embodiment of the invention can be used for the RISC-V processor.

Description

Technical Field

[0001] The embodiments of this specification relate to the technical field of hardware design and development, and more particularly to a verification method, a computing device, and a verification system. Background Art

[0002] With the development of hardware design and development technology, in the process of hardware design and development, the processing unit to be verified needs to undergo data path validation (DPV), that is, first use a high-level programming language, such as C or C++, to model the processing unit to obtain a modeling code such as Cmodel, and then use logic design tools such as Verilog and other development tools to obtain logic codes such as register transfer level (RTL) code.

[0003] At present, in order to ensure that the behavior of the logic code is consistent with the modeling code, it is necessary to use the modeling code as a reference, perform data path verification on the processing unit to be verified, write verification cases to provide stimulus input and environment construction, and then verify the processing unit to be verified. This verification process is imperfect and the verification efficiency is low. Formal verification improves the quality and efficiency of data path verification through exhaustive stimulus input and rapid environment construction.

[0004] However, the processing units to be verified are composed of more and more complex processing operators. How to specifically determine the convergence exception operators to complete the verification convergence optimization and thus improve the verification quality and efficiency is an urgent problem to be solved. Summary of the invention

[0005] In view of this, an embodiment of this specification provides a verification method. One or more embodiments of this specification also relate to a verification device, a computing device, a verification system, a computer-readable storage medium and a computer program product to solve the technical defects existing in the prior art.

[0006] According to a first aspect of an embodiment of this specification, a verification method is provided, including:

[0007] Obtaining operation information of the processing unit to be verified;

[0008] Perform convergence anomaly analysis on the operation information to determine the convergence anomaly operator in the processing unit to be verified;

[0009] Based on the operator type of the convergence exception operator, a target verification tool corresponding to the operator type is called to verify the convergence exception operator to obtain a verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence exception operator.

[0010] According to a second aspect of the embodiments of this specification, a verification device is provided, including:

[0011] An acquisition module, configured to acquire operation information of the processing unit to be verified;

[0012] An analysis module is configured to perform convergence anomaly analysis on the operation information and determine convergence anomaly operators in the processing unit to be verified;

[0013] The verification module is configured to call the target verification tool corresponding to the operator type to verify the convergence exception operator based on the operator type of the convergence exception operator to obtain the verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence exception operator.

[0014] According to a third aspect of an embodiment of this specification, there is provided a computing device, including a processor;

[0015] The processor is verified according to the above verification method.

[0016] According to a fourth aspect of the embodiments of this specification, there is provided a verification system, including a memory, a processor, and a verification terminal;

[0017] The memory is used to store computer programs / instructions, and the verification end is used to execute the computer programs / instructions. When the computer program / instructions are executed by the verification end, the above verification method is implemented to verify the processor.

[0018] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores a computer program / instruction, and the computer program / instruction implements the steps of the above-mentioned verification method when executed by a processor.

[0019] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which implements the steps of the above-mentioned verification method when executed by a processor.

[0020] In one embodiment of the present specification, the operation information of the processing unit to be verified is obtained; the convergence abnormality analysis is performed on the operation information to determine the convergence abnormal operator in the processing unit to be verified. By deeply analyzing the operation information of the processing unit to be verified, the convergence abnormal operator that appears in the verification process can be accurately identified, which is the basis for subsequent targeted verification, ensuring the efficient allocation of verification resources, avoiding indiscriminate verification of all operators, and thus significantly reducing unnecessary verification workload. Based on the operator type of the convergence abnormal operator, the target verification tool corresponding to the operator type is called to verify the convergence abnormal operator to obtain the verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence abnormal operator. Targeted verification based on operator type is realized, and each type of convergence abnormal operator will be verified using the corresponding target verification tool, effectively avoiding the use of general verification tools for verification during the verification process, improving the quality of verification, and accelerating the convergence speed of the verification process by optimizing the verification complexity of the convergence abnormal operator, thereby shortening the verification cycle and improving the verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a flow chart of a verification method provided by an embodiment of this specification;

[0022] Figure 2 is a schematic diagram of a verification method applied to a compressor provided by an embodiment of this specification;

[0023] Figure 3 is a schematic diagram of a verification method applied to a product multiplier provided by an embodiment of this specification;

[0024] Figure 4 It is a code principle diagram for verifying convergence difficulties of a floating-point multiplication and accumulation operator provided by an embodiment of this specification;

[0025] Figure 5 is a schematic diagram of a verification method applied to a repeated instantiation processing operator provided by an embodiment of this specification;

[0026] Figure 6 It is a schematic diagram of a verification method for ensuring convergence constraints provided by an embodiment of this specification;

[0027] Figure 7 It is a structural schematic diagram of a verification device provided by an embodiment of this specification;

[0028] Figure 8 is a structural block diagram of a computing device provided by one embodiment of this specification;

[0029] Fig. 9It is a structural diagram of a verification system provided by an embodiment of this specification. DETAILED DESCRIPTION

[0030] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0031] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0032] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0033] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0034] First, the terms involved in one or more embodiments of this specification are explained.

[0035] Reduced Instruction Set Computer (RISC): A reduced instruction set computer is a computer architecture that improves the performance and efficiency of a computer by simplifying the instruction set. The core of the RISC design concept is to have a smaller number of simple instructions, each of which takes a short time to execute and is usually completed within one clock cycle. This design reduces the complexity of instruction decoding, allowing the processor to run at a higher frequency, while also simplifying the processor design, helping to reduce power consumption and improve reliability. The RISC architecture also emphasizes the concepts of register windows and load / store instructions, with most operations performed between registers, while data access is done through specialized load and store instructions. This reduces the frequency of memory accesses and further improves performance. For example, the fifth-generation reduced instruction set (Reduced Instruction Set Computer-Fifth Version, RISC-V).

[0036] High Level Equivalence C / C++toRTL (HECTOR for short) from C language modeling or C++ language modeling to RTL code.

[0037] Tool Command Language (TCL), a scripting language, is widely used in the automation process of Electronic Design Automation (EDA) tools.

[0038] Application Specific Integrated Circuit (ASIC): An integrated circuit designed specifically for a specific application or function. Compared to general-purpose processors, ASICs usually have higher performance and lower power consumption when performing specific tasks, but they are less flexible and cannot be modified once they are produced.

[0039] Field-Programmable Gate Array (FPGA): A semi-custom circuit that contains configurable logic components and programmable interconnect resources. These resources can be reconfigured by software to implement different digital logic functions. This makes FPGAs very useful in design verification, prototyping, and applications that require highly customized logic functions.

[0040] Central Processing Unit (CPU): It is the main computing component of the computer and is responsible for executing instructions defined by the Instruction Set Architecture (ISA). It usually contains a Control Unit (CU) and an Arithmetic Logic Unit (ALU) for processing data and performing calculations. Modern CPUs may also contain features such as cache and multi-core processors to improve performance.

[0041] Graphics Processing Unit (GPU): A graphics processing unit designed to accelerate graphics rendering and video processing. In recent years, it has also been widely used for general computing, especially in parallel computing-intensive tasks such as machine learning and scientific computing. GPU has a large number of simple computing units, can process multiple data streams simultaneously, and provide high floating-point computing capabilities.

[0042] RISC-V processor (Reduced Instruction Set Computing-FifthVersion, referred to as RISC-V, the fifth generation of reduced instruction set): an open instruction set architecture (ISA) designed to promote processor innovation. Unlike proprietary ISAs, RISC-V is designed to allow anyone to design, manufacture and sell RISC-V compatible chips and software. Its design goal is to achieve small, fast, low-power processors while also supporting complex systems.

[0043] Lemma checking: In formal verification, lemma checking refers to verifying the correctness of an intermediate step that is used as a basis for verifying a more complex property or theorem. Lemma checking typically involves using formal logic and automated reasoning tools to ensure the validity of the lemma.

[0044] Convergence constraints (assume): In formal verification, it usually refers to the prerequisite constraints on certain processing operators in the system. When we verify the correctness of certain processing operators in an algorithm system, we may "assume" that certain prerequisites are met, and then verify other properties of the processing operators based on the prerequisites. If it is found that the prerequisites are not met during the verification process, it means that some processing operators may have errors or need to be corrected. "Convergence constraints" specifically refer to those assumptions used to guide the verification process to converge to the expected results.

[0045] At present, in order to ensure that the behavior of the logic code is consistent with the modeling code, it is necessary to use the logic code as a reference, perform data path verification on the processing unit to be verified, write verification cases to provide stimulus input and environment construction, and then verify the processing unit to be verified. This verification process is imperfect and the verification efficiency is low. Formal verification improves the quality and efficiency of data path verification through exhaustive stimulus input and rapid environment construction.

[0046] However, the processing units to be verified are composed of increasingly complex processing operators. Generally speaking, processing and solving convergence problems will occupy more than 50% of the overall verification time of data path verification. For example, in RISC-V processors, there are many complex operator operations: a large number of floating-point operation instructions in the vector 1.0 extension, supported Matrix extension instructions and other complex computing units. How to specifically determine the convergence exception operators to complete the verification, and then improve the verification quality and efficiency, has always been the focus and difficulty of the data path verification process, and is also a key link in the data path verification process.

[0047] In this specification, a verification method is provided. This specification also relates to a verification device, a computing device, a verification system, a computer-readable storage medium and a computer program product, which are described in detail one by one in the following embodiments.

[0048] See also Figure 1 , Figure 1 A flowchart of a verification method provided by an embodiment of this specification is shown, including the following specific steps:

[0049] Step 102: Obtain operation information of the processing unit to be verified.

[0050] The embodiments of this specification are applied to a verification environment generated by a data path verification tool (e.g., the dpv_gen tool) (e.g., generating a cmodel hectorwrapper, an instantiation program of cmodel code, and an instantiation program of RTL code), and a tool command language for related scenarios to run verification cases (TCLtest) to implement data path verification of the processing unit to be verified.

[0051] The processing unit to be verified is an integrated circuit that needs to be verified for data path during the hardware design and development process, including but not limited to: dedicated integrated circuits, field programmable gate arrays, central processing units, graphics processing units, RISC-V processors or more complex custom circuit modules. The processing unit to be verified implements the functions of specific logic through circuits of specific structures, including multiple processing operators, for example, a dedicated integrated circuit designed for high-speed data packet processing, which contains a complex network protocol parsing engine; or a design on a field programmable gate array, which is used to perform matrix multiplication and convolution operations. Convolver, commonly used in artificial intelligence accelerators; or a floating-point processing operator in a central processing unit, used to perform high-precision mathematical calculations; another example is the register unit in a graphics processing unit, which is used to store pixel data; another example is a vector adder of a RISC-V processor, which supports vectorized single instruction multiple data (SIMD) operations to accelerate the processing of vector data.

[0052] In an optional embodiment of the present specification, the processing unit to be verified is a RISC-V processor.

[0053] The operation information of the processing unit to be verified is the information used to describe the processing unit to be verified during the hardware design and development process, which specifically describes the physical layout, logical functions and operating behaviors of multiple processing operators, and then describes the overall structure and function of the processing unit to be verified. The operation information includes, but is not limited to: the structural information (circuit information) and functional information (logical information) of the processing unit to be verified. The operation information is generally in the form of a code file, wherein the structural information (circuit information) is described in a hardware description language (Hardware Description Language, HDL for short), which describes the circuit connection method, signal path and timing relationship of the processing operators in the processing unit to be verified, such as Verilog code or VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language) code, and the functional information is described in a high-level programming language, which describes the functional role and execution logic of each processing operator of the processing unit to be verified, such as C language and C++ language.

[0054] An optional way to obtain the operation information of the processing unit to be verified is to directly obtain the operation information of the processing unit to be verified whose design has been completed from the processing unit database. For example, the hardware description language code and high-level program language code of the processing unit to be verified whose design has been completed are directly obtained from the processing unit database. These codes are usually stored in a version control system, and a specific version of the code is automatically pulled into the verification environment through a specific script or tool. Another optional way is to use an automated tool to obtain the operation information of the processing unit to be verified from multiple design tools. For example, an automated script is used to extract the hardware description language code of the processing unit to be verified from the output of each tool in the design stage (such as Synopsys Design Compiler or CadenceGenus), and to extract the high-level program language code of the processing unit to be verified from the output of a behavioral simulation tool (such as ModelSim or NCVerilog). Another optional way is to use an integrated tool to integrate the operation information of the processing units to be verified in multiple design stages. For example, a data conversion and integration tool in an EDA tool chain (such as Mentor Graphics' QUESTA or Synopsys' Verdi), which integrates the hardware description language code and high-level program language code of the processing units to be verified from different design stages into a unified verification environment, which is not limited here.

[0055] Exemplarily, during the design and development process of a RISC-V processor, an integrated tool is used to integrate the hardware description language RTL code and the high-level programming language Cmodel of the RISC-V processor from different design stages.

[0056] Obtaining the operation information of the processing unit to be verified provides information basis for subsequent convergence anomaly analysis and provides a basis for the processing unit for subsequent verification.

[0057] Step 104: Perform convergence anomaly analysis on the operation information to determine convergence anomaly operators in the processing unit to be verified.

[0058] Convergence anomaly analysis is an analysis operation during the hardware design and development process when the data path verification process cannot converge as expected (i.e. reach a stable state or verification endpoint). Convergence anomaly analysis is used to identify processing operators that exhibit unexpected behavior or have difficulty meeting verification goals during the verification process, in order to find verification bottlenecks or design defects.

[0059] Convergence exception operators are processing operators that exhibit unexpected behaviors or are difficult to meet verification targets in the processing units to be verified during the hardware design and development process. Convergence exception operators are due to heterogeneous problems or repeated instantiations caused by excessive complexity, which result in the inability to converge to a stable state or verification endpoint as expected during the verification process. In hardware verification, convergence exception operators are the focus of convergence exception analysis. Identifying these operators helps locate potential problems in the design and complete hardware design and development optimization. For example, in the design of a RISC-V processor, there is a floating-point processing operator that cannot achieve the preset verification target under specific input conditions. This floating-point processing operator can be identified as a convergence exception operator.

[0060] Perform convergence exception analysis on the operation information to determine the convergence exception operator in the processing unit to be verified. An optional method is to perform convergence exception analysis on the operation information from the architecture level to determine the convergence exception operator in the processing unit to be verified. For example, the RISC-V processor relies on the output of the floating-point processing operator as input, but in some verification use cases, the response time of the floating-point processing operator is abnormally prolonged, resulting in overall vector operation delays, which may indicate that the floating-point processing operator has a convergence exception. At this time, by analyzing the architectural design of the floating-point processing operator, such as the pipeline depth and the complexity of the register transfer logic (RTL), the convergence exception operator can be located. Another optional method is: performing convergence exception analysis on multiple processing operators in the operation information one by one, and determining the convergence exception operator in the processing unit to be verified. For example, the graphics processing unit includes multiple sequentially connected convolution operators. The assume_guarantee tool is used to perform convergence exception analysis on multiple sequentially connected convolution operators to determine a certain abnormal convolution operator with convergence exception in the graphics processing unit. Another optional method is: using a machine learning algorithm to perform convergence exception analysis on the operation information to determine the convergence exception operator in the processing unit to be verified. For example, a field programmable gate array contains multiple operators of the same type. The input and output of each operator are subjected to convergence exception analysis through a pre-trained machine learning model to determine the convergence exception operator in the field programmable gate array. This is not limited here.

[0061] Exemplarily, the hardware description language RTL code and high-level programming language Cmodel of the RISC-V processor are analyzed for convergence exceptions from the architecture level to determine the convergence exception operators in the RISC-V processor: a 4-2 compressor, a 3-2 compressor, a product multiplier, a floating-point multiplication and accumulation operator, and 4 repeated instantiation processing operators. If it is not possible to find a relatively obvious heterogeneous point at the architecture level, the assume_guarantee tool in the data path verification tool is used to perform convergence exception analysis on multiple processing operators in the operation information one by one to determine the convergence exception operators in the processing unit to be verified: 8 floating-point multiplication and accumulation operators.

[0062] Perform convergence anomaly analysis on the operation information to determine the convergence anomaly operators in the processing unit to be verified. By deeply analyzing the operation information of the processing unit to be verified, it is possible to accurately identify the convergence anomaly operators that appear during the verification process. This is the basis for subsequent targeted verification, ensuring the efficient allocation of verification resources and avoiding indiscriminate verification of all operators, thereby significantly reducing unnecessary verification workload.

[0063] Step 106: Based on the operator type of the convergence exception operator, call the target verification tool corresponding to the operator type to verify the convergence exception operator to obtain a verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence exception operator.

[0064] The operator type of convergence exception operator is the operator classification of convergence exception operators that exhibit unexpected behaviors or are difficult to meet verification goals during hardware design and development. The operator types of convergence exception operators include, but are not limited to, heterogeneous types and repeated instantiation types, where heterogeneous types include, but are not limited to, hardware acceleration structures such as compressors, product multipliers, and floating-point processing operators.

[0065] The verification tool is a formal verification tool used for data path verification. The verification tool is used to verify whether a processing operator in the processing unit to be verified meets the expected functions and performance indicators.

[0066] The target verification tool corresponding to the operator type is a formal verification tool for the operator type of convergence exception operators, which is used to improve the verification quality and efficiency of data path verification for convergence exception operators. The target verification tool is constructed based on the convergence constraints corresponding to the operator type, including but not limited to: target verification tools corresponding to heterogeneous types and target verification tools corresponding to repeated instantiation types, wherein the target verification tools corresponding to heterogeneous types include but are not limited to: target verification tools corresponding to hardware acceleration structures such as compressors, target verification tools corresponding to product multipliers, and target verification tools corresponding to floating-point processing operators. For example, the target verification tool corresponding to hardware acceleration structures such as compressors is a tool specially designed to verify such operators. It has advanced parallel processing capabilities and can effectively process large-scale parallel data streams. Such tools usually use specific algorithms, such as fast Fourier transforms or other parallel algorithms, to accelerate the verification process. For another example, product multipliers are often used to implement large integer multiplication, and the verification tool needs to be able to handle high-precision numerical calculations to ensure the accuracy of multiplication operations. Such tools have built-in high-precision mathematical libraries that can handle integer operations of any length and support fast convergence algorithms to improve verification efficiency. For example, verification tools for floating-point processing operators need to take into account the IEEE 754 floating-point standard and accurately simulate the addition, subtraction, multiplication, division and carry rules of floating-point numbers. Such tools include floating-point operation simulators that can accurately track the operation of each bit to ensure that the results meet the standard.

[0067] The convergence constraints corresponding to the operator type are the prerequisite constraints added to the processing operator during the data path verification process to ensure that the data path verification can be carried out efficiently and achieve the expected results. For example, the carry logic of the floating-point processing operator is carried from high to low, that is, 1.1*2.2=11*22*10 -2 , instead of 0.11*0.22*10 4 For another example, the addition operation of 17 operands is gradually completed in the form of partial sum for the structure information of the compressor, that is, a3=a1+a2, a5=a3+a4, ..., out=a16+a17. The addition operation of 17 operands is directly completed for the function information of the compressor, that is, out=a1+a2+a4...+a17.

[0068] The verification result is the verification result of the data path verification of the convergence exception operator during the hardware design and development process, including data path consistency and data path inconsistency. In the case where the convergence exception operator is the same stimulus input for the structural information and functional information of the processing unit to be verified, if the structural information and functional information respond consistently, the verification result is data path consistency; if the structural information and functional information respond inconsistently, the verification result is data path inconsistency. For example, when performing data path verification on the convergence exception operator, if the Cmodel and RTL model produce exactly the same results under the same stimulus input, then the verification result is data path consistency, indicating that the operator is functionally correct. If there is a difference in the output of the Cmodel and RTL model under the same stimulus input, then the verification result is data path inconsistency.

[0069] Based on the operator type of the convergence exception operator, call the target verification tool corresponding to the operator type to verify the convergence exception operator and obtain the verification result. One optional way is: for the verification of heterogeneous types of convergence exception operators, add a lemma check to the convergence exception operator and then verify it. Another optional way is: for the verification of repeated instantiation processing operators, select an operator as the target processing operator for detailed white box verification, and perform black box processing on the remaining operators. Another optional way is: for the verification of multiple sequentially connected processing operators, add a lemma check to the output of each operator to complete the cascade verification, which is not limited here.

[0070] Among them, data path verification is mainly carried out by building verification cases and running verification cases to obtain verification results. Among them, verification configuration files can be pre-configured for verification cases. The verification configuration files may include Yaml cfg and Excel cfg files. Of course, the verification configuration files may also include other files. The file list and compilation parameters required for functional information (logic information) and structural information (circuit information) are parsed from the Yaml cfg file. The operator mapping relationship between functional information (logic information) and structural information (circuit information) is parsed from Excel cfg. Based on the parsed information, a verification environment is built, which usually includes generating a test platform, such as a generator for test stimuli and a checker for responses, as well as interfaces for logic code (such as Cmodel) and modeling code (such as RTL model). All source codes, including Cmodel and RTL code, are compiled using the compilation parameters extracted from the Yaml cfg file to ensure that they can run correctly in the verification environment. Pre-built verification cases are run, which cover various stimulus inputs and convergence constraints to comprehensively test the performance and functions of the processing unit to be verified.

[0071] Exemplarily, a 4-2 compressor, a 3-2 compressor, a product multiplier, and a floating-point multiplication and accumulation operator are verified after adding a lemma check, and one of the four repeated instantiation processing operators is selected as the target processing operator for detailed white-box verification, while the remaining operators are processed in black boxes. If no obvious heterogeneous points can be found from the architectural level, the assume_guarantee tool in the data path verification tool is used to add a lemma check to the output of the eight floating-point multiplication and accumulation operators to complete the cascade verification. The verification result is: the hardware description language RTL code of the RISC-V processor is consistent with the high-level programming language Cmodel data path, and enters the subsequent approval (Signoff) process.

[0072] In the embodiment of this specification, the operation information of the processing unit to be verified is obtained; the convergence abnormality analysis is performed on the operation information to determine the convergence abnormal operator in the processing unit to be verified. By deeply analyzing the operation information of the processing unit to be verified, the convergence abnormal operator that appears in the verification process can be accurately identified, which is the basis for subsequent targeted verification, ensuring the efficient allocation of verification resources, avoiding indiscriminate verification of all operators, thereby significantly reducing unnecessary verification workload. Based on the operator type of the convergence abnormal operator, the target verification tool corresponding to the operator type is called to verify the convergence abnormal operator to obtain the verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence abnormal operator. Targeted verification based on operator type is realized, and each type of convergence abnormal operator will be verified using the corresponding target verification tool, effectively avoiding the use of general verification tools for verification during the verification process, improving the quality of verification, and accelerating the convergence speed of the verification process by optimizing the verification complexity of the convergence abnormal operator, thereby shortening the verification cycle and improving the verification efficiency.

[0073] Generally speaking, one of the main reasons for complex operator convergence anomalies is that there are architectural differences in the structural information (circuit information) and functional information (logic information) of the processing unit to be verified, resulting in heterogeneous processing units. Therefore, it is necessary to analyze the convergence anomaly of the computing architecture, locate the heterogeneous operators with convergence anomalies in the processing unit to be verified, and conduct targeted data path verification on the heterogeneous operators, which can optimize the verification efficiency while ensuring the verification quality.

[0074] In an optional embodiment of this specification, the computing information includes a computing architecture;

[0075] Correspondingly, step 104 includes the following specific steps:

[0076] Perform convergence anomaly analysis on the computing architecture to determine the heterogeneous operators with convergence anomalies in the processing unit to be verified.

[0077] The computing architecture is a blueprint that describes the circuit structure and logical functions of the processing unit to be verified during the hardware design and development process. It covers the layout of each operator in the processing unit, the logical function of each operator, the signal path between each operator, the data flow direction between each operator, and the timing relationship between each operator. The computing architecture is a bridge between abstract functional information (logical information) and specific structural information (circuit information). For example, in a RISC-V processor, the computing architecture will describe in detail the stages of the instruction pipeline, the data path (such as ALU, shifter, multiplier), the organization of the register file, and the control logic (such as branch predictor). For another example, in a graphics processing unit, multiple parallel vector operation units are included to perform pixel value calculations.

[0078] Heterogeneous operators are processing operators that exhibit unexpected behaviors or are difficult to meet verification targets due to heterogeneity issues in the processing units to be verified during the hardware design and development process. They include but are not limited to hardware acceleration structures such as compressors, product multipliers, and floating-point processing operators.

[0079] Exemplarily, a convergence exception analysis is performed on the RTL code of the RISC-V processor and the computing architecture of the Cmodel to determine the convergence exception operators in the RISC-V processor: a 4-2 compressor, a 3-2 compressor, a product multiplier, and a floating-point multiplication and accumulation operator.

[0080] In the embodiments of the present specification, convergence exception analysis is performed on the operation information from the operation architecture level to determine the convergence exception operators in the processing unit to be verified. By deeply analyzing the operation architecture of the processing unit to be verified, heterogeneous operators with convergence exceptions during the verification process can be accurately identified, which is the basis for subsequent targeted verification, ensures efficient allocation of verification resources, avoids indiscriminate verification of all operators, and thus significantly reduces unnecessary verification workload.

[0081] In an optional embodiment of the present specification, performing convergence anomaly analysis on the computing architecture to determine heterogeneous operators with convergence anomalies in the processing unit to be verified includes the following specific steps:

[0082] Perform convergence anomaly analysis on the computing architecture and determine that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a compressor;

[0083] Correspondingly, step 106 includes the following specific steps:

[0084] Add lemma checks on compressor input structure information and output structure information;

[0085] Add lemma checks on input structure information and output structure information of intermediate compressors;

[0086] Taking each lemma check as convergence constraint, the compressor is verified and the verification results are obtained.

[0087] A compressor is a processing operator in an integrated circuit that is used to perform partial summation or reduce the number of signal paths in multiple input signals. It is usually used to accelerate addition or subtraction operations, especially in large-scale parallel operations. The compressor reduces the bus width by combining input signals, thereby increasing the operation speed and reducing power consumption. Common compressors include 4-2 compressors and 3-2 compressors. The former compresses four inputs into two outputs, and the latter compresses three inputs into two outputs. For example, in graphics processing units, compressors are used in matrix multiplication operations. Specifically, the principle of the 4-2 compressor is a+b+c+d=sum+carry, and similarly, the 3-2 compressor is a+b+c=sum+carry.

[0088] The structural information of the compressor describes the specific layout of the compressor circuit, the signal path, and the connection of the logic gates. This includes the type, number, and location of the logic gates inside the compressor, as well as the direction of the signal lines, which are defined by a hardware description language (such as Verilog or VHDL). For example, for a 4-2 compressor, its structural information describes how the four input signals are combined into two output signals through half adders and full adders.

[0089] The input structure information of the compressor specifically describes the way and format of the input signal received by the compressor. This includes the bit width, data type, timing requirements, etc. of the input signal, as well as how the input signal is mapped to the internal logic of the compressor. For example, a 4-2 compressor has four binary input signals, each with a bit width of 1 bit, which need to arrive at the input port of the compressor at a specific time point.

[0090] The output structure information of the compressor specifically describes the way and format in which the compressor receives the output signal. This includes the bit width, data type, timing requirements, etc. of the output signal, as well as how the internal logic of the compressor is mapped to the output signal. For example, a 4-2 compressor has 2 binary output signals, each with a bit width of 1 bit, which need to arrive at the output port of the compressor at a specific point in time.

[0091] Lemma checking is an operation that checks the data path verification of intermediate processing operators in formal verification. It is used to check the structure and logic of complex processing operators. Lemma checking usually involves the use of verification tools to ensure the effectiveness of lemma checking, which is the basis for verifying complex processing operators.

[0092] Convergence constraints are operations that perform convergence constraints on the data path verification of intermediate processing operators in formal verification, and are used to constrain the complexity of verifying convergence exception operators. Convergence constraints usually involve the use of verification tools to ensure the efficiency of data path verification, and are the basis for improving the verification efficiency of data path verification.

[0093] Optionally, Figure 2 A schematic diagram of a verification method applied to a compressor provided by an embodiment of this specification is shown, Figure 2 As shown:

[0094] Figure 2 The RTL architecture in the example uses eight 4-2 compressors and one 3-2 compressor to connect and complete the addition operation of 17 operands, which may be in the form of result = element0 + ... + element16, resulting in a relatively long section of heterogeneous logic.

[0095] Add lemma check for compressor input structure information and output structure information: lemmaimpl.a+impl.b+impl.c+impl.d=impl.sum+impl.carry.

[0096] Add lemma check to the input structure information and output structure information of the intermediate compressor of the compressor: lemma4_2_compress_result_check=impl.sum+impl.carry==spec.element0+spec.element1.

[0097] The compressor is verified with each lemma check as a convergence constraint to obtain a verification result: after the verification of the above lemma check lemma is passed, the above two added lemma checks lemma are converted into convergence constraints assume to obtain a verification result.

[0098] Among them, "result" is the final sum of 17 operands after a series of compressors. "element0" to "element16" represent 17 input operands, which will be added by the compressor network. "impl.a", "impl.b", "impl.c" and "impl.d" are four input signals to a single 4-2 compressor. "impl.sum" is an output signal of the 4-2 compressor, representing the output result of the partial sum (sum). "impl.carry" is an output signal of the 4-2 compressor, representing the output result of the carry (carry). "lemmaimpl.a+impl.b+impl.c+impl.d=impl.s+impl.c" is a lemma check used to verify whether the sum of the four signals input to the 4-2 compressor is equal to the output of the compressor. "lemma4_2_compress_result_check" is a lemma check used to verify whether the outputs of the 4-2 compressor "impl.sum" and "impl.carry" are equal to the expected input.

[0099] In the embodiments of this specification, the method of performing targeted verification on the compressor, a heterogeneous operator, effectively avoids the use of general verification tools for verification during the verification process, effectively improves the quality of verification, and can also optimize the verification complexity for the compressor and accelerate the convergence speed of the verification process, thereby shortening the verification cycle and effectively improving the verification efficiency.

[0100] In an optional embodiment of the present specification, performing convergence anomaly analysis on the computing architecture to determine heterogeneous operators with convergence anomalies in the processing unit to be verified includes the following specific steps:

[0101] Perform convergence anomaly analysis on the computing architecture and determine that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a product multiplier;

[0102] Correspondingly, step 106 includes the following specific steps:

[0103] Added lemma checks on the input structure information and output structure information of the product multiplier;

[0104] Taking the lemma check as the convergence constraint, the product multiplier is verified and the verification result is obtained.

[0105] A product multiplier is a processing operator in an integrated circuit that is used to perform product-multiplication operations. In many computationally intensive applications, such as digital signal processing (DSP), image processing, and neural network accelerators, the product multiplier is a core component because it can efficiently perform product-multiplication operations, i.e., A*B.

[0106] The structural information of the multiplication multiplier describes the specific layout of the multiplication multiplier circuit, the signal path, and the connection method of the logic gates. This includes the type, quantity, location of the logic gates inside the multiplication multiplier, and the direction of the signal lines, which are defined by a hardware description language (such as Verilog or VHDL). For example, for a 53-bit * 26-bit multiplication multiplier, its structural information includes: Input buffer: receives 53-bit and 26-bit input signals. Multiplication array: consists of multiple AND gates, performs bit-level multiplication operations, and generates partial product multiplication. Adder tree: adds the partial products generated by the multiplication array to form the final multiplication result. Carry logic: handles the carry generated during the multiplication process to ensure that it is correctly transmitted between different bits. Output buffer: receives the maximum result output signal of 79 bits.

[0107] The input structure information of the multiplication multiplier specifically describes the way and format of the multiplication multiplier receiving the input signal. This includes the bit width, data type, timing requirements, etc. of the input signal, as well as how the input signal is mapped to the internal logic of the multiplication multiplier. For example, for a 53-bit*26-bit multiplication multiplier, its input structure information includes: Input buffer: receives 53-bit and 26-bit input signals.

[0108] The output structure information of the product multiplier specifically describes the way and format of the product multiplier receiving the output signal. This includes the bit width, data type, timing requirements, etc. of the output signal, as well as how the internal logic of the product multiplier is mapped to the output signal. For example, for a 53-bit * 26-bit product multiplier, its output structure information includes: Output buffer: Receives a maximum result output signal of 79 bits.

[0109] Lemma checking is an operation that checks the data path verification of intermediate processing operators in formal verification. It is used to check the structure and logic of complex processing operators. Lemma checking usually involves the use of verification tools to ensure the effectiveness of lemma checking, which is the basis for verifying complex processing operators.

[0110] Convergence constraints are operations that perform convergence constraints on the data path verification of intermediate processing operators in formal verification, and are used to constrain the complexity of verifying convergence exception operators. Convergence constraints usually involve the use of verification tools to ensure the efficiency of data path verification, and are the basis for improving the verification efficiency of data path verification.

[0111] Optionally, Figure 3 FIG. 1 is a schematic diagram showing a verification method applied to a product multiplier provided by an embodiment of the present specification, such as Figure 3 As shown:

[0112] Figure 3The bit width of the medium product multiplier is 53*26. The input of the multiplier of the RTL architecture is a and b, and the output is the sum (sum) and carry (carry). The input of the multiplier of the C architecture is a and b, and the output is the product (result).

[0113] It is found that the final result of directly verifying the C and RTL architectures, "impl.sum+impl.carry==spec.result", is very difficult to converge, resulting in abnormal convergence of the verification results of the operators with this situation.

[0114] Add lemma checks on the input structure information and output structure information of the product multiplier:

[0115] spec.a == impl.a;

[0116] spec.b == impl.b;

[0117] impl.a*impl.b==impl.sum+impl.carry;

[0118] (spec.a*spec.b==spec.result)==impl.sum+impl.carry.

[0119] Using the lemma check as the convergence constraint, the product multiplier is verified to obtain the verification result: through logical equivalence and RTL logic verification, the verification result of "impl.s+impl.c==spec.result" is achieved and used as the convergence constraint of the next level.

[0120] Among them, "result" is the product result obtained by product multiplication of two inputs. "spec.a" is, "impl.a" is, "spec.b" is, "impl.b" is, "impl.a*impl.b" is, "impl.sum" is an output signal of the product multiplier, representing the output result of the partial sum (sum), "impl.carry" is an output signal of the product multiplier, representing the output result of the carry (carry), "spec.a==impl.a; spec.b==impl.b; impl.a*impl.b==impl.sum+impl.carry; (spec.a*spec.b==spec.result)==impl.sum+impl.carry" is a lemma check, used to verify the correctness of the product multiplication operation.

[0121] In the embodiments of this specification, a method for performing targeted verification on a heterogeneous operator such as a product multiplier effectively avoids the use of general verification tools for verification during the verification process, effectively improves the quality of verification, and can also optimize the verification complexity of convergence exception operators for the product multiplier, accelerate the convergence speed of the verification process, thereby shortening the verification cycle and effectively improving the verification efficiency.

[0122] In an optional embodiment of the present specification, performing convergence anomaly analysis on the computing architecture to determine heterogeneous operators with convergence anomalies in the processing unit to be verified includes the following specific steps:

[0123] Perform convergence anomaly analysis on the computing architecture and determine that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a floating-point multiplication and accumulation operator;

[0124] Correspondingly, step 106 includes the following specific steps:

[0125] Based on the carry structure information of the floating-point multiplication and accumulation operator, adjust the carry function information of the floating-point multiplication and accumulation operator;

[0126] The adjusted carry function information of the floating-point multiplication and accumulation operator is used as a convergence constraint to verify the floating-point multiplication and accumulation operator and obtain a verification result.

[0127] It should be noted that in the process of floating-point multiplication and accumulation, heterogeneous problems may be encountered due to different calculation ideas, such as:

[0128] Floating-point multiplication and accumulation operator (result = src0*src1+src2), in order to simplify the order shift operation of addition, the RTL architecture adopts the strategy of shifting only the accumulated number src2, while the Cmodel judges based on the relationship between the exponent of the product result and the exponent of the accumulated number, and shifts according to the principle of smaller exponent. Therefore, this heterogeneous behavior leads to a large difference between the two operands in the addition operation, resulting in convergence abnormality problems.

[0129] Alternatively, the RTL and C architectures of the widen multiplication and accumulation instructions also have heterogeneity problems. This heterogeneity problem mainly exists in the processing of denormal data. This instruction mainly completes the precision extension multiplication and accumulation operation of f16*f16+f32=f32. The main heterogeneity points are as follows: Cmodel side: First, the data is precision extended by executing f16_to_f32, and then the f32mul_add function is used for operation. However, in the precision conversion process of f16_to_f32, the leading zero prediction and exponent mantissa adjustment of the denormal data are performed, such as Figure 4 As shown in FIG. 1 , after the adjustment of the scheme, the data of the exponent and mantissa on the multiplication and accumulation side will be completely heterogeneous.

[0130] Figure 4 A code schematic diagram for verifying convergence difficulties of a floating-point multiplication and accumulation operator provided by an embodiment of this specification is shown:

[0131] if(exp){

[0132] if(!frac){

[0133] uiZ=packToF32UI(sign,0,0);

[0134] goto normExpSig;

[0135] }

[0136] }

[0137] normExpSig:

[0138] normExpSig=softfloat_normSubnormalF16Sig(frac);

[0139] exp = normExpSig.exp;

[0140] frac = normExpSig.sig;

[0141] Specifically, it checks the values ​​of the exp and frac variables and performs different operations based on these values. If exp is true and frac is false, it packs a specific 32-bit unsigned integer value into uiZ and jumps to the label normExpSig. Otherwise, it executes the code under the normExpSig label, which normalizes frac and updates the values ​​of exp and frac.

[0142] RTL side: Low-precision computing resources are directly used in the RTL implementation process, and the accuracy is retained. The exponent and mantissa are adjusted through bias during the multiplication and accumulation process to finally complete the overall operation.

[0143] Floating-point multiplication and accumulation operators are processing operators in integrated circuits that are used to perform floating-point multiplication and accumulation operations. They are particularly important in high-performance computing, scientific computing, machine learning, and other fields because they can complete compound operations of multiplication and addition within one clock cycle, greatly accelerating the execution speed of computationally intensive tasks. Floating-point multiplication and accumulation operators usually follow the IEEE754 floating-point standard and support single-precision (32-bit) or double-precision (64-bit) floating-point operations. It combines the functions of a floating-point multiplier and a floating-point adder, and can perform multiplication of two floating-point numbers and accumulation of one floating-point number at the same time, that is, the calculation formula is: C = A*B+C.

[0144] The structural information of the floating-point multiplication and accumulation operator describes the specific layout, signal path and connection mode of the floating-point multiplication and accumulation operator circuit. This includes the type, number, location and direction of the logic gates inside the floating-point multiplication and accumulation operator, which is defined by a hardware description language (such as Verilog or VHDL). For example, in a double-precision floating-point multiplication and accumulation operator, its structural information may include the layout and signal path of a 53-bit multiplier, a 53-bit adder, carry propagation logic, normalization circuit, overflow and underflow detection circuit, etc.

[0145] The carry structure information of the floating-point multiply-accumulate operator specifically describes the way and format in which the floating-point multiply-accumulate operator receives the output carry signal. Special attention is paid to how the carries generated during the multiplication and addition process are managed and processed to ensure the correctness and accuracy of the calculation. This includes the bit width, data type, timing requirements, etc. of the output carry signal, and how the internal logic of the floating-point multiply-accumulate operator is mapped to the output carry signal. For example, in the floating-point multiply-accumulate operator, the carry structure information may include circuit designs such as the carry-lookahead adder (CLA) and the carry-save adder (CSA), as well as how to coordinate the transmission and processing of the carry signal between the multiplier and the adder.

[0146] Convergence constraints are operations that perform convergence constraints on the data path verification of intermediate processing operators in formal verification, and are used to constrain the complexity of verifying convergence exception operators. Convergence constraints usually involve the use of verification tools to ensure the efficiency of data path verification, and are the basis for improving the verification efficiency of data path verification.

[0147] The heterogeneous situations caused by different calculation ideas need to be solved by reconstructing the Cmodel: in the embodiment of this specification, based on the carry structure information of the floating-point multiplication and addition operator, the carry function information of the floating-point multiplication and addition operator is adjusted, and the adjusted carry function information of the floating-point multiplication and addition operator is used as the convergence constraint to verify the floating-point multiplication and addition operator to obtain the verification result.

[0148] In the embodiments of this specification, a method for performing targeted verification on a heterogeneous operator such as a floating-point multiplication and addition operator effectively avoids the use of general verification tools for verification during the verification process, effectively improves the quality of verification, and can also optimize the verification complexity of convergence exception operators for the floating-point multiplication and addition operator, accelerate the convergence speed of the verification process, thereby shortening the verification cycle and effectively improving the verification efficiency.

[0149] In complex processing processes such as matrix / vector operations, there is often a problem of long processing result pipelines caused by repeated instantiation of repeated processing operators. However, in order to ensure the correctness of data allocation of processing operators and the correctness of final write-back data, complete operator verification is usually performed, which increases the verification workload and time cost and reduces verification efficiency. This is because the verification of repeated instantiation of processing operators requires not only separate verification of each instance, but also ensuring that the data flow and control flow between all instances are correct. Especially in large-scale parallel processing systems, the complexity and time-consumingness of this verification will increase exponentially.

[0150] In an optional embodiment of the present specification, the operation information includes a plurality of processing operators;

[0151] Correspondingly, step 104 includes the following specific steps:

[0152] Performing convergence anomaly analysis on multiple processing operators to determine at least two repeated instantiation processing operators with convergence anomalies in the processing unit to be verified;

[0153] Correspondingly, step 106 includes the following specific steps:

[0154] Adding a lemma check to input structure information of at least two repeated instantiation processing operators, and adding a convergence constraint to output structure information of at least two repeated instantiation processing operators;

[0155] Performing black box processing on the repeated instantiation processing operators except the target processing operator, wherein the target processing operator is any one of the at least two repeated instantiation processing operators;

[0156] Verify at least two repeated instantiation processing operators to obtain verification results.

[0157] The processing operator is the basic functional unit of the processing unit to be verified during the hardware design and development process, which is used to perform specific computing tasks such as addition, multiplication, logical operations, etc.

[0158] Repeatedly instantiated processing operators are processing operators that perform the same or similar functions multiple times during the hardware design and development process. This type of repeated instantiation is common in loop structures, array processing, or matrix operations. For example, in vector multiplication, if a vector A is multiplied by another vector B to obtain a result matrix C of the same length, then for each element in the matrix A and B, a multiplication operation needs to be performed, and then the result is stored in the corresponding position of the result matrix C. In this process, the multiplication operator will be repeatedly instantiated, that is, multiple identical multiplier instances are created, each instance is responsible for processing a pair of elements in the matrix.

[0159] The input structure information of the repeated instantiation processing operator specifically describes the way and format of the repeated instantiation processing operator receiving the input signal. This includes the bit width, data type, timing requirements, etc. of the input signal, as well as how the input signal is mapped to the internal logic of the repeated instantiation processing operator. For example, in a vector addition operation, if the vector consists of multiple integer elements, the input structure information of the repeated instantiation processing operator will describe that each adder instance receives two integer input signals of the same bit width. The bit width, data type (such as 32-bit signed integer), timing requirements (such as valid within a specific clock cycle) of these signals, and how the input signals are connected to the internal logic of the adder (such as carry chain, full adder, etc.) all belong to the input structure information.

[0160] Lemma checking is an operation that checks the data path verification of intermediate processing operators in formal verification. It is used to check the structure and logic of complex processing operators. Lemma checking usually involves the use of verification tools to ensure the effectiveness of lemma checking, which is the basis for verifying complex processing operators.

[0161] Convergence constraints are operations that perform convergence constraints on the data path verification of intermediate processing operators in formal verification, and are used to constrain the complexity of verifying convergence exception operators. Convergence constraints usually involve the use of verification tools to ensure the efficiency of data path verification, and are the basis for improving the verification efficiency of data path verification.

[0162] The target processing operator is any one of at least two repeated instantiation processing operators. In the embodiment of this specification, white-box verification of the target processing operator requires not only data path verification but also identification of specific implementation details inside the operator.

[0163] Black-box processing is a verification strategy in which any of at least two repeated instantiation processing operators except the target processing operator is regarded as an opaque unit and only needs to perform data path verification, that is, whether the output of the repeated instantiation processing operator is consistent under the convergence constraint, without indicating the specific implementation details inside the operator.

[0164] Optionally, Figure 5 A schematic diagram of a verification method for a repeated instantiation processing operator provided by an embodiment of the present specification is shown, Figure 5 As shown:

[0165] Figure 5 The diagram below shows the structure of the matrix operation process. Each mma_tree is responsible for the dot multiplication of a fixed row of input matrix 1 and a fixed row of input matrix 2.

[0166] Input matrix 1: [0, 1, …, R];

[0167] Input matrix 2: [0, 1, …, R, R+1, R+2, …, 2R];

[0168] Input matrix 3: [0, 1, …, R];

[0169] Output matrix: [0, 1, …, R].

[0170] Repeat the instantiation of operator 1 to perform point multiplication and addition operations on all elements "0", "1", ..., "R" in input matrix 1 and the first element "0" in input matrix 2;

[0171] Repeat the instantiation of operator 2 to perform point multiplication and addition operations on all elements "0", "1", ..., "R" in input matrix 1 and the second element "1" in input matrix 2;

[0172] …

[0173] The repeated instantiation processing operator 1 is the target processing operator. By adding lemma checks to the input of each repeated instantiation processing operator, adding convergence constraints to the output of each repeated instantiation processing operator, and performing black-box processing on the repeated instantiation processing operators except the target processing operator, and finally verifying at least two repeated instantiation processing operators to obtain verification results, repeated instantiation can be effectively avoided and the complexity of data path verification in this case is reduced.

[0174] In the embodiments of this specification, a targeted verification method is implemented to address the problem of a long pipeline caused by the need to repeatedly instantiate operators for repeated instantiation, thereby effectively avoiding the use of general verification tools for verification during the verification process, effectively improving the quality of verification, and optimizing the verification complexity of convergence exception operators for repeatedly instantiated operators, thereby accelerating the convergence speed of the verification process, thereby shortening the verification cycle and effectively improving the verification efficiency.

[0175] The method of the embodiment of the above specification improves the verification efficiency from the perspective of the architecture level and pipeline verification (repeated instantiation). However, it is not possible to accurately determine the more obvious convergence exception operators from the perspective of the architecture level and pipeline verification (repeated instantiation). The convergence exception operators in the approximate interval of convergence difficulty can be determined by step-by-step positioning.

[0176] In an optional embodiment of the present specification, the operation information includes a plurality of sequentially connected processing operators;

[0177] Correspondingly, step 104 includes the following specific steps:

[0178] Added lemma checks on output structure information of multiple processing operators;

[0179] Taking each lemma check as the convergence constraint, the convergence anomaly analysis is performed on each processing operator to determine the convergence anomaly operators in the processing unit to be verified.

[0180] Multiple sequentially connected processing operators are basic functional units that are arranged in a specific order and interconnected in the processing unit to be verified during the hardware design and development process, where the output of each operator is directly used as the input of the next operator. This connection method forms a data processing pipeline, allowing data to be processed through each operator in turn. Sequentially connected processing operators are common in fields such as data stream processing, signal processing, and image processing. Each operator can focus on a specific processing task, such as data conversion, filtering, encoding, etc., while the entire pipeline is responsible for the complete processing flow from input data to output results.

[0181] The output structure information of multiple processing operators specifically describes the way and format of the output signals received by each sequentially connected processing operator. This includes the bit width, data type, timing requirements, etc. of the output signal, as well as how the internal logic of each processing operator is mapped to the output signal. For example, a complex floating-point operator includes sequentially connected adders, multiplier-accumulators, shifters, and multipliers.

[0182] Lemma checking is an operation that checks the data path verification of intermediate processing operators in formal verification. It is used to check the structure and logic of complex processing operators. Lemma checking usually involves the use of verification tools to ensure the effectiveness of lemma checking, which is the basis for verifying complex processing operators.

[0183] Convergence constraints are operations that perform convergence constraints on the data path verification of intermediate processing operators in formal verification, and are used to constrain the complexity of verifying convergence exception operators. Convergence constraints usually involve the use of verification tools to ensure the efficiency of data path verification, and are the basis for improving the verification efficiency of data path verification.

[0184] Taking each lemma check as a convergence constraint, performing convergence exception analysis on each processing operator, and determining the convergence exception operator in the processing unit to be verified. An optional method is: taking each lemma check as a convergence constraint, performing cascaded convergence exception analysis on each processing operator, and determining the convergence exception operator in the processing unit to be verified.

[0185] Exemplarily, the assume_guarantee tool in the data path verification tool is used to perform cascade convergence exception analysis on multiple sequentially connected processing operators in the operation information, and the convergence exception operators in the processing unit to be verified are determined: 8 floating-point multiplication and accumulation operators.

[0186] In the embodiments of the present specification, a lemma check is added to the output structure information of multiple sequentially connected processing operators, and each lemma check is used as a convergence constraint. Convergence exception analysis is performed on each processing operator to determine the convergence exception operator in the processing unit to be verified. By analyzing the operation information of the processing unit to be verified in a step-by-step manner, it is possible to accurately identify the convergence exception operators that appear in the verification process, which is the basis for subsequent targeted verification, ensures the efficient allocation of verification resources, avoids indiscriminate verification of all operators, and thus significantly reduces unnecessary verification workload.

[0187] In an optional embodiment of the present specification, each lemma check is used as a convergence constraint, a convergence exception analysis is performed on each convergence exception analysis interval, and a convergence exception operator in a processing unit to be verified is determined, including the following specific steps:

[0188] Perform convergence anomaly analysis on the first processing operator. If there is no convergence anomaly in the first processing operator, use the lemma check of the first processing operator as the convergence constraint to perform convergence anomaly analysis on the second processing operator until the convergence anomaly analysis of each processing operator is completed to determine the convergence anomaly operator in the processing unit to be verified.

[0189] Optionally, Figure 6 A schematic diagram of a verification method for ensuring convergence constraints provided by an embodiment of this specification is shown, such as Figure 6 As shown:

[0190] A complex floating-point operator includes sequentially connected adders, multiplier-accumulators, shifters, and multipliers. The C architecture is different from the RTL architecture. It is difficult to complete verification convergence by directly adding lemma checks to the first and last processing operators. The long verification path can be interrupted to obtain multiple sequentially connected processing operators, and then lemma checks are added to the output structure information of multiple processing operators. For example:

[0191] lemma add_result_check=impl.c(5)==spec.c(1);

[0192] lemma muladd_result_check=impl.f(10)==spec.f(1);

[0193] lemma shift_result_check=impl.g(15)==spec.g(1);

[0194] lemma final_check=impl.out(20)==spec.out(1).

[0195] Then open the assume_guarantee configuration in the verification case (TCLtest) to automatically convert the lemma checks written in the previous step into the subsequent convergence constraints:

[0196] Lemma check 2 is verified based on Lemma check 1 as a convergence constraint, Lemma check 3 is verified based on Lemma check 1 + Lemma check 2 as a convergence constraint, and Lemma check 4 is verified based on Lemma check 1 + Lemma check 2 + Lemma check 3 as a convergence constraint.

[0197] If it is found that Lemma Check 1, Lemma Check 3, and Lemma Check 4 can be verified, but Lemma Check 2 cannot converge, it can be said that the main verification difficulty exists in the multiplier-accumulator. If this part can be verified, the final result will be easier to converge, and the goal can be set on studying the heterogeneous problem of the multiplier-accumulator.

[0198] In the embodiments of the present specification, a lemma check is added to the output structure information of multiple sequentially connected processing operators, and the previous lemma check is converted into a subsequent convergence constraint. By analyzing the operation information of the processing unit to be verified in a step-by-step manner, it is possible to more accurately identify operators with convergence exceptions during the verification process, which is the basis for subsequent targeted verification, ensures efficient allocation of verification resources, avoids indiscriminate verification of all operators, and thus significantly reduces unnecessary verification workload.

[0199] In an optional embodiment of the present specification, before step 104, the following specific steps are also included:

[0200] Sampling the operation information according to the preset information range to obtain sampled operation information;

[0201] Perform convergence time analysis on the sampling operation information to obtain the estimated convergence time;

[0202] When the estimated convergence time exceeds a preset time threshold, determining that a convergence abnormality occurs;

[0203] Correspondingly, step 104 includes the following specific steps:

[0204] In the event of a convergence anomaly, a convergence anomaly analysis is performed on the operation information to determine the convergence anomaly operator in the processing unit to be verified.

[0205] The preset information range is the information sampling range set during the hardware design and development process to simplify verification. The preset information range is used to quickly estimate whether convergence anomalies in data path verification occur. For example, when verifying a matrix multiplication operator, the preset information range is limited to using only matrices of a specific size (such as 2x2 or 3x3 matrices), and the matrix elements are limited to a certain range of values ​​(such as integers between 0 and 10).

[0206] The sampled operation information is information extracted from the operation information of the processing unit to be verified according to a preset information range, and is used to quickly estimate whether a convergence anomaly of data path verification occurs. For example, taking the matrix multiplication operator as an example, the sampled operation information may include matrix samples of different sizes and types, such as symmetric matrices, unit matrices, zero matrices, and randomly generated matrices.

[0207] The estimated convergence time is the time required to reach a converged state by verifying the sampled operation information in the datapath verification. The estimated convergence time is based on the estimation of the design complexity, verification strategy and computing resources. For example, when formally verifying a floating-point multiplier, the estimated convergence time may be based on a comprehensive consideration of the design size (such as the number of logic gates), verification strategy (such as the level of abstraction) and the performance of the verification tool used.

[0208] The preset time threshold is a preset time threshold required for verifying the sampling operation information and reaching a convergence state. If the estimated convergence time exceeds the preset time threshold, it is considered that the verification has encountered a convergence anomaly problem. If the estimated convergence time does not exceed the preset time threshold, it is considered that the verification has not encountered a convergence anomaly problem.

[0209] Exemplarily, a rough sense of the convergence time is first obtained by over-constraining the operator input data: a matrix multiplication and accumulation operator samples the operation information according to the preset information range to obtain the sampled operation information: first constrain the first row and the first column of the two matrices to be fixed values, and the other rows and columns are all 0. Perform convergence time analysis on the sampled operation information to obtain the estimated convergence time: perform formal verification on the two matrices to obtain the estimated convergence time, and at the same time, basic environmental problems and Cmodel problems can be checked. If the estimated convergence time obtained by the verification of a single row and a single column exceeds the preset time threshold, such as greater than 5 minutes, then the complete verification of multiple rows and columns is bound to have convergence anomalies. In this case, a convergence anomaly analysis is performed on the operation information to determine the convergence anomaly operator in the processing unit to be verified.

[0210] In the embodiments of this specification, by presetting the information range and sampling the calculation information, the verification process can be completed within limited time and computing resources, thus avoiding the lengthy wait for full verification and improving the verification efficiency.

[0211] Corresponding to the above method embodiment, this specification also provides a verification device embodiment, Figure 7 FIG. 1 is a schematic diagram showing the structure of a verification device provided by an embodiment of this specification. Figure 7 As shown, the device comprises:

[0212] An acquisition module 702 is configured to acquire operation information of a processing unit to be verified;

[0213] The analysis module 704 is configured to perform convergence anomaly analysis on the operation information and determine convergence anomaly operators in the processing unit to be verified;

[0214] The verification module 706 is configured to call the target verification tool corresponding to the operator type to verify the convergence exception operator based on the operator type of the convergence exception operator to obtain a verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence exception operator.

[0215] Optionally, the computing information includes computing architecture;

[0216] Correspondingly, the analysis module 704 is further configured to:

[0217] Perform convergence anomaly analysis on the computing architecture to determine the heterogeneous operators with convergence anomalies in the processing unit to be verified.

[0218] Optionally, the analysis module 704 is further configured to:

[0219] Perform convergence anomaly analysis on the computing architecture and determine that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a compressor;

[0220] Correspondingly, the verification module 706 is further configured to:

[0221] Lemma checks are added to the input structure information and output structure information of the compressor; lemma checks are added to the input structure information and output structure information of the intermediate compressor of the compressor; the compressor is verified using each lemma check as a convergence constraint to obtain a verification result.

[0222] Optionally, the analysis module 704 is further configured to:

[0223] Perform convergence anomaly analysis on the computing architecture and determine that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a product multiplier;

[0224] Correspondingly, the verification module 706 is further configured to:

[0225] A lemma check is added to the input structure information and output structure information of the product multiplier; the product multiplier is verified using the lemma check as a convergence constraint to obtain a verification result.

[0226] Optionally, the analysis module 704 is further configured to:

[0227] Perform convergence anomaly analysis on the computing architecture and determine that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a floating-point multiplication and accumulation operator;

[0228] Correspondingly, the verification module 706 is further configured to:

[0229] Based on the carry structure information of the floating-point multiplication and accumulation operator, the carry function information of the floating-point multiplication and accumulation operator is adjusted; the floating-point multiplication and accumulation operator is verified by taking the adjusted carry function information of the floating-point multiplication and accumulation operator as a convergence constraint to obtain a verification result.

[0230] Optionally, the operation information includes a plurality of processing operators;

[0231] Correspondingly, the analysis module 704 is further configured to:

[0232] Performing convergence anomaly analysis on multiple processing operators to determine at least two repeated instantiation processing operators with convergence anomalies in the processing unit to be verified;

[0233] Correspondingly, the verification module 706 is further configured to:

[0234] Add a lemma check to the input structure information of at least two repeated instantiation processing operators, and add a convergence constraint to the output structure information of at least two repeated instantiation processing operators; perform black box processing on the repeated instantiation processing operators except the target processing operator, wherein the target processing operator is any one of the at least two repeated instantiation processing operators; verify the at least two repeated instantiation processing operators to obtain a verification result.

[0235] Optionally, the operation information includes a plurality of sequentially connected processing operators;

[0236] Correspondingly, the analysis module 704 is further configured to:

[0237] Lemma checks are added to the output structure information of multiple processing operators; each lemma check is used as a convergence constraint, and convergence anomaly analysis is performed on each processing operator to determine the convergence anomaly operator in the processing unit to be verified.

[0238] Optionally, the analysis module 704 is further configured to:

[0239] Perform convergence anomaly analysis on the first processing operator. If there is no convergence anomaly in the first processing operator, use the lemma check of the first processing operator as the convergence constraint to perform convergence anomaly analysis on the second processing operator until the convergence anomaly analysis of each processing operator is completed to determine the convergence anomaly operator in the processing unit to be verified.

[0240] Optionally, the device further comprises:

[0241] The perception module is configured to sample the operation information according to a preset information range to obtain sampled operation information; perform convergence time analysis on the sampled operation information to obtain an estimated convergence time; and determine that a convergence anomaly occurs when the estimated convergence time exceeds a preset time threshold;

[0242] Correspondingly, the analysis module 704 is further configured to:

[0243] In the event of a convergence anomaly, a convergence anomaly analysis is performed on the operation information to determine the convergence anomaly operator in the processing unit to be verified.

[0244] In the embodiments of this specification, the acquisition module is configured to acquire the operation information of the processing unit to be verified; the analysis module is configured to perform convergence anomaly analysis on the operation information and determine the convergence anomaly operator in the processing unit to be verified; by deeply analyzing the operation information of the processing unit to be verified, it is possible to accurately identify the convergence anomaly operator that appears in the verification process, which is the basis for subsequent targeted verification, ensuring the efficient allocation of verification resources, avoiding indiscriminate verification of all operators, and thus significantly reducing unnecessary verification workload. The verification module is configured to call the target verification tool corresponding to the operator type based on the operator type of the convergence anomaly operator to verify the convergence anomaly operator and obtain the verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence anomaly operator. Targeted verification based on operator type is implemented. Each type of convergence exception operator will be verified using the corresponding target verification tool, which effectively avoids the use of general verification tools during the verification process, improves the quality of verification, and accelerates the convergence speed of the verification process by optimizing the verification complexity of convergence exception operators, thereby shortening the verification cycle and improving verification efficiency.

[0245] The above is a schematic scheme of a verification device of this embodiment. It should be noted that the technical scheme of the verification device and the technical scheme of the verification method described above are of the same concept, and the details of the technical scheme of the verification device not described in detail can be found in the description of the technical scheme of the verification method described above.

[0246] Figure 8 The structure block diagram of a computing device provided by an embodiment of the present specification is shown. The components of the computing device 800 include but are not limited to a processor 810, and the processor 810 passes the verification according to the above verification method.

[0247] Optionally, the computing device further includes a memory 820, the processor 810 is connected to the memory 820 via a bus 830, and the database 850 is used to store data.

[0248] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 840 may include one or more of any type of network interface (e.g., a network interface card (NIC)) of wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, and a Near Field Communication (NFC).

[0249] In one embodiment of the present specification, the above components of the computing device 800 and Figure 8 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 8 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0250] The computing device 800 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or a personal computer (PC). The computing device 800 may also be a mobile or stationary server.

[0251] In an optional embodiment of the present specification, the processor 810 is a RISC-V processor.

[0252] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the above verification method belong to the same concept, and the details not described in detail in the technical scheme of the computing device can be referred to the description of the technical scheme of the above verification method.

[0253] Fig. 9 The schematic diagram of the structure of a verification system provided by an embodiment of the present specification is shown. The verification system 900 includes but is not limited to: a memory 910, a processor 920 and a verification terminal 930;

[0254] The memory 910 is used to store computer programs / instructions, and the verification terminal 930 is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the verification terminal 930, the above verification method is implemented to verify the processor 920.

[0255] In an optional embodiment of the present specification, processor 920 is a RISC-V processor.

[0256] The above is a schematic scheme of a verification system of this embodiment. It should be noted that the technical scheme of the verification system and the technical scheme of the verification method described above are of the same concept, and the details of the technical scheme of the verification system not described in detail can be found in the description of the technical scheme of the verification method described above.

[0257] An embodiment of the present specification also provides a computer-readable storage medium storing a computer program / instruction, which implements the steps of the above verification method when executed by a processor.

[0258] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the above verification method belong to the same concept, and the details not described in detail in the technical scheme of the storage medium can be referred to the description of the technical scheme of the above verification method.

[0259] An embodiment of the present specification also provides a computer program product, including a computer program / instruction, which implements the steps of the above verification method when executed by a processor.

[0260] The above is a schematic solution of a computer program product of this embodiment. It should be noted that the technical solution of the computer program product and the technical solution of the above verification method belong to the same concept, and the details not described in detail in the technical solution of the computer program product can be referred to the description of the technical solution of the above verification method.

[0261] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0262] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the contents contained in the computer readable medium may be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, computer readable media do not include electric carrier signals and telecommunication signals.

[0263] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0264] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0265] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A verification method, comprising: Obtaining operation information of the processing unit to be verified; Performing convergence anomaly analysis on the operation information to determine convergence anomaly operators in the processing unit to be verified; Based on the operator type of the convergence exception operator, a target verification tool corresponding to the operator type is called to verify the convergence exception operator to obtain a verification result, wherein the target verification tool is constructed based on the convergence constraint corresponding to the operator type, and the convergence constraint is used to constrain the complexity of verifying the convergence exception operator.

2. The method according to claim 1, wherein the computing information comprises a computing architecture; The performing convergence anomaly analysis on the operation information to determine the convergence anomaly operator in the processing unit to be verified includes: A convergence anomaly analysis is performed on the computing architecture to determine heterogeneous operators with convergence anomalies in the processing unit to be verified.

3. The method according to claim 2, wherein the performing convergence anomaly analysis on the computing architecture to determine the heterogeneous operators with convergence anomalies in the processing unit to be verified comprises: Performing convergence anomaly analysis on the computing architecture, and determining that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a compressor; The method of calling a target verification tool corresponding to the operator type based on the convergence exception operator to verify the convergence exception operator and obtaining a verification result includes: Adding lemma checks to input structure information and output structure information of the compressor; adding lemma checks to input structure information and output structure information of an intermediate compressor of the compressor; The compressor is verified by taking each lemma check as a convergence constraint to obtain a verification result.

4. The method according to claim 2, wherein the performing convergence anomaly analysis on the computing architecture to determine the heterogeneous operators with convergence anomalies in the processing unit to be verified comprises: Performing convergence anomaly analysis on the computing architecture, and determining that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a product multiplier; The method of calling a target verification tool corresponding to the operator type based on the convergence exception operator to verify the convergence exception operator and obtaining a verification result includes: adding a lemma check to the input structure information and the output structure information of the product multiplier; The product multiplier is verified using the lemma check as a convergence constraint to obtain a verification result.

5. The method according to claim 2, wherein the performing convergence anomaly analysis on the computing architecture to determine the heterogeneous operators with convergence anomalies in the processing unit to be verified comprises: Performing convergence anomaly analysis on the computing architecture, and determining that the heterogeneous operator with convergence anomaly in the processing unit to be verified is a floating-point multiplication and accumulation operator; The method of calling a target verification tool corresponding to the operator type based on the convergence exception operator to verify the convergence exception operator and obtaining a verification result includes: Adjusting the carry function information of the floating-point multiplication and accumulation operator based on the carry structure information of the floating-point multiplication and accumulation operator; The adjusted carry function information of the floating-point multiplication and accumulation operator is used as a convergence constraint to verify the floating-point multiplication and accumulation operator to obtain a verification result.

6. The method according to claim 1, wherein the operation information comprises a plurality of processing operators; The performing convergence anomaly analysis on the operation information to determine the convergence anomaly operator in the processing unit to be verified includes: Performing convergence anomaly analysis on the multiple processing operators to determine at least two repeated instantiation processing operators with convergence anomalies in the processing unit to be verified; The method of calling a target verification tool corresponding to the operator type based on the convergence exception operator to verify the convergence exception operator and obtaining a verification result includes: Adding a lemma check to input structure information of the at least two repeated instantiation processing operators, and adding a convergence constraint to output structure information of the at least two repeated instantiation processing operators; Performing black box processing on the repeated instantiation processing operators except the target processing operator, wherein the target processing operator is any one of the at least two repeated instantiation processing operators; The at least two repeated instantiation processing operators are verified to obtain a verification result.

7. The method according to claim 1, wherein the operation information comprises a plurality of sequentially connected processing operators; The performing convergence anomaly analysis on the operation information to determine the convergence anomaly operator in the processing unit to be verified includes: Added lemma checks on output structure information of multiple processing operators; Taking each lemma check as a convergence constraint, a convergence exception analysis is performed on each processing operator to determine the convergence exception operator in the processing unit to be verified.

8. The method according to claim 7, wherein the step of taking each lemma check as a convergence constraint, performing convergence anomaly analysis on each convergence anomaly analysis interval, and determining the convergence anomaly operator in the processing unit to be verified comprises: Perform convergence exception analysis on the first processing operator. When there is no convergence exception in the first processing operator, perform convergence exception analysis on the second processing operator with the lemma check of the first processing operator as the convergence constraint, until the convergence exception analysis of each processing operator is completed, and determine the convergence exception operator in the processing unit to be verified.

9. The method according to any one of claims 1 to 8, before performing convergence abnormality analysis on the operation information to determine the convergence abnormal operator in the processing unit to be verified, further comprising: Sampling the operation information according to a preset information range to obtain sampled operation information; Performing convergence time analysis on the sampling operation information to obtain an estimated convergence time; When the estimated convergence time exceeds a preset time threshold, determining that a convergence abnormality occurs; The performing convergence anomaly analysis on the operation information to determine the convergence anomaly operator in the processing unit to be verified includes: In the event of a convergence anomaly, a convergence anomaly analysis is performed on the operation information to determine the convergence anomaly operator in the processing unit to be verified.

10. The method according to claim 1, wherein: The processing unit to be verified is a RISC-V processor.

11. A computing device comprising a processor; The processor is verified according to the method according to any one of claims 1-9.

12. The computing device of claim 11, wherein: The processor is a RISC-V processor.

13. A verification system, comprising a memory, a processor and a verification terminal; The memory is used to store computer programs / instructions, and the verification end is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the verification end, the method according to any one of claims 1 to 9 is implemented to verify the processor.

14. The system according to claim 13, wherein: The processor is a RISC-V processor.

Images