Circuit verification method and apparatus, and device, program and readable storage medium

By converting the statement of statement into a comprehensive assertion circuit, and configured it with the tested design to the FPGA, the FPGA simulation lacks the low -level visibility problem of design details, and improves verification efficiency and design details.

WO2025020690A1PCT designated stage expired Publication Date: 2025-01-30BEIJING INSTITUTE OF OPEN SOURCE CHIP

Patent Information

Application Number
PCT/CN2024/096489
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-07-27
Filing Date
2024-05-30
Publication Date
2025-01-30

AI Technical Summary

Technical Problem

FPGA simulation lacks low-level visibility of design details, and software simulation verification is inefficient.

Method used

Convert an assertive sentence to a comprehensive assertion circuit, and configure it with the test design to FPGA, and use the assertion circuit to reveal the internal state and potential problems of the test design.

Benefits of technology

Improved the verification efficiency of the tested design, provided higher design details, can quickly reach the time of the failure of the assertion, reducing resource overhead.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024096489_30012025_PF_FP_ABST
    Figure CN2024096489_30012025_PF_FP_ABST
Patent Text Reader

Abstract

The present application relates to the technical field of computers. Provided are a circuit verification method and apparatus, and a device, a program and a readable storage medium. The method comprises: acquiring a design file, which comprises a design under test and an assertion statement, wherein the assertion statement is used for verifying whether the design under test meets a test condition; converting the assertion statement into an assertion circuit, wherein the assertion circuit is a register-transfer level circuit; generating a target netlist on the basis of the design under test and the assertion circuit; according to the target netlist, configuring the design under test and the assertion circuit into an integrated circuit chip; running the integrated circuit chip, and monitoring an assertion result of the design under test; and when an assertion coverage rate of the design under test meets a preset condition, determining that the design under test passes verification. The embodiments of the present application may reveal an internal state and a potential problem of a design under test by using an assertion circuit, thereby solving the problem of low-level visibility of FPGA simulation lacking design details.
Need to check novelty before this filing date? Find Prior Art

Description

Circuit verification method, device, equipment, program and readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on July 27, 2023, with application number 202310934163.6 and application name “A circuit verification method, device, electronic device and readable storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of computer technology, and in particular to a circuit verification method, device, electronic device computer program, and computer-readable storage medium. Background Art

[0004] As computer architecture and hardware design become increasingly complex, functional verification has become a time-consuming process in chip development. Verification accounts for up to 70% of the development cycle. One of the bottlenecks in verification is software simulation of register-transfer level (RTL) circuits. While software simulation provides complete visibility into design details to aid debugging, RTL simulation can be extremely time-consuming for long simulations of complex designs, significantly reducing verification efficiency. Furthermore, software simulation still relies on manual judgment to examine waveforms and debug information to locate design issues.

[0005] Assertions are often used as an efficient verification method to reduce the debugging workload in the functional verification of digital circuits. More than 75% of ASIC designs and nearly 50% of FPGA designs use assertion-based verification (ABV). Compared with traditional debugging techniques using printf or display, ABV can perform automatic monitoring and checking at the same time to verify whether a given hardware design meets the expected behavior. Once an assertion is violated, the verification system automatically marks the problem. Engineers can use simulation software to investigate the cause of the assertion failure and trace it back to the root cause. In the industrial design process, design engineers often add assertions to prevent future unexpected behavior and identify potential errors. Assertions are very valuable when checking complex logical behavior with timing information.

[0006] FPGAs, as a standard approach and accelerator for pre-silicon verification, can significantly improve performance. However, debugging RTL designs using FPGAs is not straightforward. Current vendor-provided debugging tools, such as Signaltap and ILA, introduce significant area overhead and can only monitor a limited number of internal signals. Furthermore, existing hardware-based RTL testing solutions operate at the instruction set architecture (ISA) level, lacking low-level visibility into design details and unable to reveal internal errors and defects. Assertions are suitable for this purpose, but unfortunately, they contain a large number of non-synthesizable keywords and cannot be directly used for hardware testing.

[0007] Summary of the Invention

[0008] Embodiments of the present application provide a circuit verification method, apparatus, electronic device computer program, and computer-readable storage medium to address the problems of prior art FPGA simulation lacking design details, low visibility, and low verification efficiency of software simulation.

[0009] In a first aspect, an embodiment of the present application provides a circuit verification method, the method comprising:

[0010] Obtain a design file, wherein the design file includes a design under test and an assertion statement; the assertion statement is used to verify whether the design under test meets the test conditions;

[0011] converting the assertion statement into an assertion circuit, wherein the assertion circuit is a register conversion stage circuit;

[0012] generating a target netlist based on the design under test and the assertion circuit;

[0013] configuring the design under test and the assertion circuit into an integrated circuit chip according to the target netlist;

[0014] running the integrated circuit chip and monitoring assertion results of the design under test;

[0015] When the assertion coverage of the design under test meets a preset condition, it is determined that the design under test passes the verification.

[0016] In a second aspect, an embodiment of the present application provides a circuit verification device, the device comprising:

[0017] A file acquisition module is used to acquire a design file, wherein the design file includes a design under test and an assertion statement; the assertion statement is used to verify whether the design under test meets the test conditions;

[0018] An assertion conversion module, configured to convert the assertion statement into an assertion circuit, wherein the assertion circuit is a register conversion stage circuit;

[0019] A netlist generation module, configured to generate a target netlist based on the design under test and the assertion circuit;

[0020] A chip configuration module, configured to configure the design under test and the assertion circuit into an integrated circuit chip according to the target netlist;

[0021] an assertion monitoring module, configured to operate the integrated circuit chip and monitor assertion results of the design under test;

[0022] The result determination module is used to determine that the design under test has passed the verification if the assertion coverage of the design under test meets a preset condition.

[0023] In a third aspect, an embodiment of the present application provides an electronic device, including a processor;

[0024] a memory for storing instructions executable by the processor;

[0025] The processor is configured to execute the instructions to implement the method of the first aspect.

[0026] In a fourth aspect, an embodiment of the present application provides a computer program, comprising a computer-readable code, which, when executed on a computing and processing device, causes the computing and processing device to execute the method of the first aspect.

[0027] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program as described in the fourth aspect. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the method of the first aspect.

[0028] In summary, the circuit verification method provided by the embodiments of the present application converts assertion statements into an assertion circuit, a synthesizable register conversion-level circuit that can be directly used for hardware testing. A target netlist is generated based on the assertion circuit and the design under test, and then the assertion circuit and the design under test are configured into the FPGA based on the target netlist. The assertion circuit is used to reveal the internal state and potential problems of the design under test, thus resolving the problem of FPGA simulation's lack of low-level visibility into design details. Furthermore, hardware is used to accelerate debugging of the design under test, improving the verification efficiency of the design under test.

[0029] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0031] FIG1 is a flowchart of a circuit verification method embodiment of the present application;

[0032] FIG2 is a block diagram of a circuit verification device of the present application;

[0033] FIG3 schematically shows a block diagram of a computing and processing device for executing the method according to the present application;

[0034] FIG4 schematically shows a storage unit for holding or carrying program codes for implementing the method according to the present application;

[0035] FIG5 is a block diagram of an electronic device provided in an embodiment of the present application. Specific embodiments

[0036] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0037] The terms "first", "second", etc. in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0038] The circuit verification method provided in the embodiment of the present application can convert assertion statements into synthesizable assertion circuits, and use hardware assertion circuits to verify the design under test, thereby improving verification efficiency.

[0039] To facilitate understanding of the embodiments provided in this application, the following points are explained:

[0040] 1. SV language (SystemVerilog) and SV assertion (SystemVerilog Assertion, SVA)

[0041] SystemVerilog is a hardware description language (HDL) used to design and verify digital circuits. It extends Verilog HDL, providing many new features and capabilities, making it more suitable for complex hardware design and verification tasks.

[0042] SVA is a key feature of SystemVerilog, used to describe and verify the behavior and properties of a system during the design and verification process. SVA allows designers to insert assertions into the hardware description to express properties about the design's behavior and state. SVA uses a syntax similar to sequential logic, which has rich expressive capabilities and can describe properties such as time correlation, sequence, and concurrency. SVA statements can be used for design verification, formal verification, and error debugging. SVA statements typically include the following:

[0043] i. Property: describes an expected or specified system behavior.

[0044] ii. Sequence: describes a sequence of events or states.

[0045] iii. Assertion: Combine attributes and sequences and specify when they are true

[0046] iv. Clocking Block: defines the clock and sampling timing.

[0047] v. Coverage: Used to evaluate the property coverage of the design.

[0048] 2. Assertion-based Verification

[0049] Assertions are an effective hardware design verification method used to ensure that a design meets specific specifications and requirements. Assertions are statements that describe the behavior and properties of a design and are used to verify that the design meets these properties at runtime. Assertion-based verification uses assertions to verify that a design meets specific specifications and requirements. It can improve verification efficiency, reduce errors, and help design teams quickly identify and resolve design issues.

[0050] In assertion verification, the design is divided into two parts: the Design Under Test (DUT) and the test environment (Testbench). The test environment includes components such as test vector generators, clocks, monitors, and assertion checkers. The test vector generator generates input data, the clock provides timing information, the monitor is used to detect the output of the design, and the assertion checker is used to check whether the design meets the specified assertions. The basic principle of assertion verification is that when the test vector drives the design to run, the monitor monitors the output of the design and compares it with the expected results. At the same time, the assertion checker evaluates the assertion statement and issues a verification error if the assertion fails (that is, the assertion is false). This method can quickly discover errors in the design during the verification process and help developers confirm whether the design meets the specification requirements.

[0051] 3. Circuit synthesis

[0052] In hardware circuit design, "synthesize" is used to describe whether hardware description language code can be converted into properties of equivalent hardware circuits. This conversion process is usually completed by circuit synthesis tools (such as logic synthesizers).

[0053] Synthesizable code is code that can be converted into hardware circuits using a logic synthesizer. Logic synthesis is the process of converting high-level, abstract code written in a hardware description language (such as SystemVerilog) into low-level hardware elements such as basic logic gates and registers. Synthesizable code should be clearly structured and timed, using only hardware primitives and constructs supported by the synthesis tool.

[0054] Non-synthesizable code is code that cannot be directly converted into hardware using a logic synthesizer. It contains features that make sense at a high level of abstraction but cannot be mapped to hardware, such as delays, loops, and conditional branches. This code is often used for non-synthesizable purposes such as simulation, verification, and testing.

[0055] Some syntax and features in SVA are not synthesizable because they are mainly used to describe and verify the behavior and properties of the system rather than directly describe the hardware structure. For example:

[0056] i. Behaviors with delays. The delays cannot be directly mapped to the hardware's sequential logic during synthesis.

[0057] ii. Sampling functions, such as "$rose()," "$stable()," and "$past()," are typically used in simulation environments to verify and debug designs. However, these sampling functions are generally unsynthesizable during synthesis because they cannot be directly mapped to equivalent elements in hardware circuits. Synthesis tools cannot directly convert these functions into hardware logic.

[0058] iii. Sequence operation keywords, such as intersect and firstmatch, are often used in the verification phase to check whether the design meets specific timing properties. Synthesis tools cannot directly convert these operators into hardware logic.

[0059] Because these features cannot be directly mapped to hardware circuits, synthesis tools cannot convert SVA code containing non-synthesizable features into equivalent hardware circuits. In actual designs, SVA is typically used in the verification phase rather than for direct hardware generation. Synthesizable hardware description language code and non-synthesizable verification code are usually written and used separately.

[0060] 4. Register-Transfer Level (RTL) circuit

[0061] RTL circuits are a common type of hardware description-level circuit. RTL circuits describe the behavior and structure of digital circuits and are represented using the register transfer level (RTL). RTL circuit descriptions are typically written in a hardware description language (HDL), such as VHSIC Hardware Description Language (VHDL), Verilog HDL, and SystemVerilog HDL. Designers can use RTL-level descriptions to define and implement the desired digital circuit functionality, and then use synthesis tools to convert the RTL-level descriptions into physical implementations in field-programmable gate arrays (FPGAs). In the field of FPGA and chip design and verification, RTL-level descriptions are crucial for design, verification, and debugging. They provide a level of abstraction that enables designers to describe circuit behavior at a higher level of abstraction and use appropriate tools for simulation, verification, and synthesis, ultimately generating a bitstream file that can be configured into the FPGA chip to implement the specific digital circuit functionality.

[0062] 5. FPGA

[0063] FPGAs are reconfigurable integrated circuits with a wide range of applications. Unlike traditional fixed-function integrated circuits (ASICs), FPGAs can be flexibly reprogrammed and reconfigured according to user needs, adapting them to different applications and functions. FPGAs consist of a large number of programmable logic blocks and programmable interconnect resources. Programmable logic blocks typically consist of look-up tables (LUTs), registers, and other logic elements, and can perform various logic functions. Programmable interconnect resources are used to connect logic blocks to form the desired circuit structure. Using FPGAs, designers can describe the desired circuit functionality using a hardware description language (HDL) and, using programming tools, convert this into a bitstream compatible with the FPGA chip. The bitstream contains information for programming and configuring the FPGA's internal logic and interconnect resources. One of the main advantages of FPGAs is their programmability and flexibility. They allow designers to implement customized functions and algorithms at the hardware level without the traditional custom IC design and manufacturing process. This makes FPGAs crucial for prototyping and rapid design iteration.

[0064] 6. Dynamic Partial Reconfiguration (DPR)

[0065] Dynamic partial reconfiguration (DPR) of FPGAs refers to the ability to reconfigure portions of a circuit while the FPGA is running. In traditional FPGA designs, the entire circuit typically needs to be reprogrammed and reloaded into the FPGA to change its functionality. However, DPR technology allows only portions of the circuit to be reconfigured while the FPGA is running, without affecting other running circuits. The main advantages of dynamic partial reconfiguration lie in its flexibility and improved resource utilization. By using DPR, multiple functional modules can be implemented in the FPGA, each of which can be independently reconfigured as needed without reloading the entire design. This flexibility enables FPGAs to adapt to a variety of application requirements while reducing reprogramming and reloading time and accelerating design iterations.

[0066] 7. Abstract Syntax Tree

[0067] An Abstract Syntax Tree (AST) is a tree-like data structure used to represent the structure of program code. It is widely used in compilers and parsers to convert source code into a form that is easy to process and analyze. The AST reflects the grammatical structure of the code and discards unnecessary details such as whitespace, comments, and specific tags. It captures the logical structure and semantics of the code and provides a convenient way to analyze, transform, and optimize the code. In the AST, each code element (such as an expression, statement, function declaration, etc.) is represented as a node, and the nodes are connected through parent-child and sibling relationships. The root node of the tree represents the entire code, while the leaf nodes represent the most basic code units.

[0068] The advantages of AST include:

[0069] a. Structured representation: AST provides a structured way to represent code, making code parsing and analysis more intuitive and flexible.

[0070] b. Syntax independence: AST does not depend on the grammatical rules of a specific programming language, so it can be used to parse and process multiple programming languages.

[0071] c. Easy to analyze and transform: By traversing and manipulating AST nodes, static analysis, code optimization, refactoring, and other operations can be performed.

[0072] In short, an abstract syntax tree is a tree-shaped data structure used to represent the structure of program code. It provides a convenient way to analyze, transform, and optimize code.

[0073] Compared to running on hardware, software simulation is slower, and the design under test runs slower in software simulation. It often takes a very long time for the simulation to reach the point where the assertion fails, resulting in low verification efficiency. To address this, an embodiment of the present application provides a circuit verification method that converts assertion statements into a synthesizable assertion circuit, burns the assertion circuit and the design under test into an FPGA, and uses hardware (FPGA) to accelerate debugging of the design under test, quickly reaching the point where the assertion fails, thereby improving verification efficiency.

[0074] 1 , a flowchart of a circuit verification method embodiment of the present application is shown. The method may specifically include the following steps:

[0075] Step 101: Obtain a design file, wherein the design file includes a design under test and an assertion statement; the assertion statement is used to verify whether the design under test meets the test conditions;

[0076] Step 102: convert the assertion statement into an assertion circuit, wherein the assertion circuit is a register conversion stage circuit;

[0077] Step 103: Generate a target netlist based on the design under test and the assertion circuit;

[0078] Step 104: configuring the design under test and the assertion circuit into an integrated circuit chip according to the target netlist;

[0079] Step 105: running the integrated circuit chip and monitoring the assertion results of the design under test;

[0080] Step 106: If the assertion coverage of the design under test meets a preset condition, determine that the design under test passes verification.

[0081] The design file contains the design under test that can be synthesized and assertion statements that cannot be synthesized. Among them, the assertion statement is used to verify whether the design under test meets the test conditions. It can be understood that an assertion statement is a statement used to check whether a specific condition is met during the test process, and a test project is a series of test activities performed to verify the correctness of the software or system. A test project for the design under test can contain multiple assertion statements. Through these assertion statements, the test objectives and expected results can be defined, thereby guiding the design and execution of the test. Specifically, by inserting assertion statements in the test code, various conditions and constraints in the test process can be automatically verified to ensure the correctness of the test results. When problems or errors occur in the test project, the failure information of the assertion statement can be used to quickly identify the specific conditions that caused the problem, thereby speeding up the troubleshooting and repair of the problem.

[0082] Assertion statements are not synthesizable and cannot be directly configured in FPGA to realize hardware simulation of the design under test. Therefore, in an embodiment of the present application, the assertion statement can be converted into an assertion circuit according to the function realized by the assertion statement, and the assertion circuit is a register conversion level circuit (RTL circuit). The assertion circuit can realize the same function as the assertion statement. Exemplarily, the assertion statement can be parsed to identify the non-synthesizable keywords in the assertion statement, such as the behavior containing time delay, sampling function, sequence operation keywords, etc., and then according to the verification logic of these keywords, state transitions and other information, the equivalent circuits corresponding to these keywords are generated, and finally, according to the overall verification logic of the assertion statement, the equivalent circuits corresponding to these keywords are connected to obtain the assertion circuit corresponding to the assertion statement. It is understandable that the assertion circuit generated in the embodiment of the present application can be composed of logic devices such as logic registers, state machines, triggers, etc., for monitoring and reporting errors or abnormal conditions in the design under test.

[0083] Next, a target netlist is generated based on the design under test and the asserted circuits. It should be noted that in electronic design automation, a netlist refers to a method for describing the connections of digital circuits using basic logic gates. Because a logic gate array has a similar arrangement to a wirelist, it is called a "netlist." A netlist typically conveys information about circuit connections, such as module instances, nets, and related properties. If more hardware information is required, a hardware description language such as Verilog, VHDL, or other specialized languages ​​is typically used for description, verification, and simulation. High-level abstraction hardware descriptions (such as the register transfer level) can be converted into a low-level abstraction (logic gate level) circuit connection netlist through logic synthesis. This step can now be automated using tools, significantly reducing the complexity for designers working with very large-scale integrated circuits (VLSIs). Hardware manufacturers use this netlist to manufacture specific application-specific integrated circuits or other circuits. Some relatively small circuits can also be implemented on field-programmable gate arrays.

[0084] In an embodiment of the present application, the target netlist is used to describe the connection between the design under test and the assertion circuit using logic gates. Specifically, in the target netlist, the input end of the assertion circuit is connected to the output end of the signal to be monitored in the design under test.

[0085] Based on the target netlist, the design under test and the assertion circuit can be configured into an integrated circuit chip. The integrated circuit chip in the embodiment of the present application is an FPGA. It is understandable that to run a design on an FPGA, it is necessary to first generate a corresponding bitstream file using the software provided by the FPGA manufacturer, and then use the bitstream file to import the design into the FPGA. A bitstream file is a binary file used to store and transmit configuration information of a programmable logic device (such as an FPGA). It contains bit information that configures the FPGA to perform hardware verification of the design under test using the assertion circuit. Specifically, the target bitstream file contains the logic gate configuration, register settings, and connection information of the FPGA. Using the target bitstream file, the assertion circuit and the design under test can be burned into the FPGA board to realize the configuration of the FPGA. In the FPGA, the signal input terminal of the assertion circuit is connected to the output terminal of the signal to be monitored in the RTL circuit design of the design under test.

[0086] Run the PFGA and monitor the assertion results of the DUT. If a monitored signal in the DUT behaves in a manner that violates the assertion statement, the assertion circuit automatically flags the issue and outputs an assertion failure signal. Furthermore, the assertion circuit can pinpoint the moment of assertion failure and the associated signal. This failure information from the assertion circuit allows for quick identification of the specific conditions that caused the problem, accelerating troubleshooting and repair.

[0087] When the assertion coverage of the design under test meets the preset conditions, it can be determined that the design under test has passed the verification. Among them, the assertion coverage is a test metric indicator used to measure the extent to which assertion statements are executed during the test process. Assertion coverage is usually expressed as a percentage, specifically the ratio between the number of assertion statements that have been correctly executed and the total number of assertion statements. For example, if there are 100 assertion statements in the design file, and 80 assertion statements are correctly executed in the test, then the assertion coverage is 80%. A higher assertion coverage indicates that the test covers more assertion statements, thereby providing a more comprehensive test guarantee. In an embodiment of the present application, the preset conditions can be set according to specific verification requirements. For example, the preset condition can be that the assertion coverage of the design under test is greater than or equal to a preset threshold, and so on.

[0088] The circuit verification method provided in the embodiment of the present application converts an assertion statement into an assertion circuit, which is a synthesizable register conversion level circuit, and generates a target netlist based on the assertion circuit and the design under test. The assertion circuit and the design under test are then configured into the FPGA based on the target netlist, and the design under test is debugged and accelerated using hardware, thereby improving the verification efficiency of the design under test.

[0089] Furthermore, current vendor-provided FPGA debugging tools have significant overhead and can only monitor a limited number of internal signals. However, the present invention replaces FPGA debugging tools with assertion circuits, which have lower resource overhead and can monitor multiple groups of signals simultaneously.

[0090] During actual testing, the circuit verification method provided by the present invention was used to verify the design under test on an FPGA using assertion circuits, achieving a performance improvement of up to 40,989 times compared to software simulation. Compared to debugging tools provided by existing vendors, this application has minimal area overhead and has no impact on the timing behavior of the device under test.

[0091] In an optional embodiment of the present application, the step 102 of converting the assertion statement into an assertion circuit includes:

[0092] Step S11: Parse the design file to obtain an abstract syntax tree; the abstract syntax tree is used to reflect the logical structure and semantics of the design file;

[0093] Step S12: traverse the abstract syntax tree to obtain a sentence tree of the segmentation language in the abstract syntax tree;

[0094] Step S13: Perform circuit synthesis processing on the assertion sentence tree to obtain an assertion circuit, where the assertion circuit is a register conversion level circuit.

[0095] The design under test and assertion statements in the design file are usually described in a hardware description language (such as HDL), which is not easy to process and analyze. In an embodiment of the present application, the design file can be parsed first and converted into an abstract syntax tree that is easier to process and analyze. The abstract syntax tree can reflect the logical structure and semantics of the design file (including the design under test and assertion statements). In practical applications, an abstract syntax tree generation tool, such as a parser, etc., can be used.

[0096] Then, the abstract syntax tree obtained by the conversion is traversed to find the assertion sentence tree corresponding to the assertion statement, and the assertion sentence tree is subjected to circuit synthesis processing to obtain the assertion circuit. Specifically, each assertion sentence tree in the abstract syntax tree can be analyzed to identify keywords (such as clock signals, sampling functions, sequence operation keywords, etc.) and assertion statement expressions, wherein the assertion statement expression is used to reflect the assertion verification rules of the assertion statement, that is, the conditions that need to be met for the assertion to be correct. Using various logic devices in the RTL circuit, such as logic registers, state machines, triggers, etc., the functions implemented by each keyword are simulated in hardware, and the connection method between the equivalent logic devices corresponding to each keyword is determined based on the assertion statement expression. The equivalent logic devices are connected according to the determined connection method to obtain the assertion circuit.

[0097] Optionally, the step S13 of performing circuit synthesis processing on the assertion sentence tree to obtain an assertion circuit includes:

[0098] Sub-step S131: Analyze the assertion sentence tree in the abstract syntax tree to identify keywords and assertion statement expressions in the assertion sentence tree;

[0099] Sub-step S132: instantiating keywords in the sentence tree of the judgment language into basic circuit modules;

[0100] Sub-step S133: performing semantic analysis on the assertion statement expression to determine the connection mode between the basic circuit modules;

[0101] Sub-step S134 : connecting the basic circuit modules according to the connection method to obtain an assertion circuit.

[0102] In the embodiments of this application, assertion statements can be divided into six categories: immediate assertion, sequence sampling signal, sequence operator, signal detection (signal_check) operator, basic operator, and timing operator (delay and repeat). Each category contains several non-synthesizable keywords and operators. Based on the type of assertion statement, the basic circuit modules in this application can also be divided into the above six categories.

[0103] In the process of analyzing the assertion sentence tree, the keywords and assertion statement expressions of the assertion sentence tree can be determined based on the various leaf nodes in the assertion sentence tree and the connection relationship between the leaf nodes. Then, the assertion statement type is determined based on the keywords, and then it is instantiated into the corresponding basic circuit module. According to the assertion statement expression, the connection method between the basic circuit modules is determined.

[0104] Exemplarily, in an embodiment of the present application, the assertion statement expression can be divided into 7 nodes and 5 levels. Specifically, the nodes of the assertion statement expression may include: sequence, constant, signal, sample subroutine, operator, time delay operator, repetition operator. The levels of the assertion statement expression may include: sequence expression, unary operator, sample subroutine, time delay operator and repetition operator. Among them, the unary operator level includes the left operator (operator left) and the right operator (operator right), the sample subroutine level includes the argument (Argument), the time delay operator level includes the time delay expression (time delay expression), and the repetition operator level includes the repetition expression (repetition expression).

[0105] In the process of analyzing the sentence tree of the broken language, we can first determine what type of node the current expression tree is, and based on the current level of the expression tree and the information of the previous level, instantiate the identified keywords into basic circuit modules, and determine the connection method between each basic circuit module.

[0106] For example, for the assertion statement "SIG_IN1 ##2 SIG_IN2[*2]##1 SIG_IN3|=>SIG_IN4 ##2 SIG_IN5", the structure information of the assertion sentence tree corresponding to the assertion statement is as follows:

[0107] The tree structure of the above assertion statement is analyzed from top to bottom. The above assertion sentence tree includes the following four levels of analysis:

[0108] 1. The level identifier of this layer is "operator", and the level identifier of the previous layer is "sequence expression". "Operator" is parsed to be "nonoverlapped implication", and "nonoverlapped implication" is instantiated as a basic circuit module. Among them, "nonoverlapped implication" is used to implement the function of the nonoverlapping implication operator (|=>). The sequence on the left side of the nonoverlapping implication operator is called the cause sequence, and the sequence on the right side is called the result sequence. There are the following situations for assertion statements containing nonoverlapping implication operators:

[0109] If the cause sequence does not match (that is, there is a conflict, and the actual running logic of the cause sequence is inconsistent with the logic in the assertion statement), the assertion does not take effect; if the result sequence also matches in the next clock cycle after the cause sequence matches (that is, there is no conflict, and the actual running logic of the result sequence is consistent with the logic in the assertion statement), the assertion matches (that is, the assertion succeeds); if the result sequence conflicts in the next clock cycle after the cause sequence matches, the assertion fails.

[0110] Syntactically, the non-overlapping implication operator "|=>" divides the assertion statement into two left and right sequences, which correspond to "left" and "right" in the abstract syntax tree. The next step is to analyze "left" first.

[0111] 2. The level identifier of this layer becomes "operator left", and the level identifier of the previous layer becomes "operator". Parsing into left, there are three elements, and they contain delay. The first element is parsed and judged to be "signal", and is instantiated as a signal detection operator (signal_check) basic circuit module with a delay of 0. Among them, the signal detection operator is used to detect whether the input signal is true. The second element is parsed and judged to be "repetition operator", and the "repetition" basic circuit module is instantiated. Enter the recursion to complete the "repetition" basic circuit module and configure the repetition period to 2 clock cycles. After exiting the recursion, the delay is 2 clock cycles, and the first "time delay" basic circuit module is instantiated with a parameter of 2. Connect the "match" port of the first element to the input of the first "time delay" basic circuit module, and the output of the first "time delay" basic circuit module to the enable port (en) of the "repetition" basic circuit module. It should be noted that when the assertion is correct, the assertion circuit will output a high-level signal of "match", and when the assertion fails, the assertion circuit will output a high-level signal of "fail".

[0112] Connect the three elements in sequence, the level identifier of this layer becomes "operator right", and the level identifier of the previous layer becomes "operator", and enter the analysis of the right side of the operator.

[0113] 3. The level identifier of this layer is "operator right", and the level identifier of the previous layer is "operator". Parsing to right, there are two elements, and they are connected in the same way as on the left. This embodiment of the application will not be further described here. Next, the level identifier of this layer becomes "operator", and the level identifier of the previous layer becomes "operator right".

[0114] 4. This layer is labeled "operator," and the previous layer is labeled "operator right." Connect the match signal outputs of the last left and right modules to the two inputs of the "nonoverlapped implication" basic circuit module, respectively. Connect the match signal output of the "nonoverlapped implication" basic circuit module to the match signal output of the entire assertion circuit, serving as the output signal indicating a successful match for the current assertion circuit. Connect the fail signal output of the "nonoverlapped implication" basic circuit module to the fail signal output of the entire assertion circuit, serving as the output signal indicating a failure for the current assertion circuit.

[0115] After the above processing, the circuit comprehensive processing of the assertion statement "SIG_IN1 ##2 SIG_IN2[*2]##1 SIG_IN3|=>SIG_IN4 ##2 SIG_IN5" is realized, that is, the assertion circuit of the assertion statement is obtained.

[0116] In an optional embodiment of the present application, generating a target netlist based on the design under test and the assertion circuit in step 103 includes:

[0117] Step S21: parsing the assertion statement to obtain signal connection information between the design under test and the assertion circuit;

[0118] Step S22: Generate a target netlist based on the signal connection information, the design under test, and the assertion circuit; the target netlist is used to describe the connection between the design under test and the assertion circuit using logic gates.

[0119] The signal connection information between the design under test and the assertion circuit can be obtained by parsing the assertion statements in the design file. Assertion statements are used to monitor signals in the design under test. Therefore, by parsing the assertion statements, it is possible to determine which signal in the design under test the input signal of the assertion statement is connected to. For example, the design file can be converted into an abstract syntax tree, and the assertion sentence tree in the abstract syntax tree can be traversed. By parsing the assertion sentence tree, the signal connection information between the design under test and the assertion circuit can be determined.

[0120] The target netlist is used to describe the connection between the design under test and the assertion circuit using logic gates. In the target netlist, the input end of the assertion circuit is connected to the output end of the signal to be monitored in the design under test.

[0121] Optionally, the step S22 of generating a target netlist based on the signal connection information, the design under test, and the assertion circuit includes:

[0122] Sub-step S221, converting the design under test into a first netlist, and converting the assertion circuit into a second netlist;

[0123] Sub-step S222: stitching corresponding parts of the first netlist and the second netlist based on the signal connection information to obtain a target netlist.

[0124] In an embodiment of the present application, the design under test and the assertion circuit can be converted into corresponding netlists respectively, and then the corresponding parts of the two netlists can be stitched together according to the same signal name to obtain a target netlist. In the target netlist, the signal input end of the second netlist is connected to the output end of the signal to be monitored in the first netlist. As an example, the RTL code of the design under test can be converted into a first netlist, and the RTL code of the assertion circuit can be converted into a second netlist by using a synthesis tool provided by an FPGA manufacturer. Then, the two netlists are modified through Tool Command Language (TCL) instructions, that is, the corresponding parts of the two netlists are stitched together according to the same signal name to achieve the insertion of signal probes and obtain the target netlist. In an optional implementation of the present application, configuring the design under test and the assertion circuit into an integrated circuit chip according to the target netlist includes:

[0125] Step S31, generating a target bitstream file according to the target netlist;

[0126] Step S32: Based on the target bitstream file, burning the design under test into the static area of ​​the integrated circuit chip, and burning the assertion circuit into the dynamic partial reconfiguration area of ​​the integrated circuit chip.

[0127] Depending on whether or not the reconfiguration function is supported, the FPGA chip can be divided into a static area and a dynamic partial reconfiguration area. In the embodiment of the present application, a target bitstream file can be generated based on the target netlist. The target bitstream file can be used to burn the design under test into the static area of ​​the FPGA chip, and the assertion circuit can be burned into the dynamic partial reconfiguration area of ​​the FPGA chip. This allows for flexible and rapid batch updates of the assertion circuit without affecting the design under test, and allows for testing of different signals of the design under test.

[0128] Optionally, the method further includes: when the assertion coverage of the design under test meets a preset condition, replacing the assertion circuit in the dynamic partial reconfiguration region to perform a next round of assertion verification on the design under test.

[0129] If the assertion coverage of the design under test meets the preset conditions, it can be determined that the design under test has passed this verification. In this case, the assertion circuit in the dynamic partial reconfiguration area can be replaced to perform the next round of assertion verification on the design under test.

[0130] In an optional embodiment of the present application, a coverage monitor is further configured in the static region of the integrated circuit chip; and step 105 of running the integrated circuit chip and monitoring the assertion results of the design under test includes:

[0131] Step S41: running the integrated circuit chip and sampling the assertion results of the design under test through the coverage monitor to determine the number of correct assertions corresponding to the design under test;

[0132] In step 106, if the assertion coverage of the design under test meets a preset condition, determining that the design under test passes verification includes:

[0133] Step S42: If the number of correct assertions corresponding to the design under test is greater than or equal to a preset threshold, determine that the design under test passes verification.

[0134] The coverage monitor is used to sample the assertion results and count the number of correct assertions. When the number of correct assertions of the design under test is greater than or equal to a preset threshold, it can be determined that the design under test has passed this verification.

[0135] Conversely, if the number of correct assertions for the design under test is less than a preset threshold, it can be determined that the design under test has failed this verification. In this case, data simulation can be performed on the assertion failure to locate the cause of the assertion failure and perform error debugging and repair.

[0136] Optionally, after running the integrated circuit chip and monitoring the assertion result of the design under test in step 105, the method further includes:

[0137] Step S51: when the assertion result of the design under test is assertion failure, saving a snapshot of the data information of each register in the design under test;

[0138] Step S52: Perform data simulation based on the stored data information and the standard reference model corresponding to the design under test to locate the cause of assertion failure of the design under test and perform error debugging and repair.

[0139] If the assertion fails, the assertion circuit will output an assertion failure signal. In the case where the assertion result of the design under test is an assertion failure, that is, when the assertion failure signal is detected, the data information of each register in the FPGA chip can be snapshot saved based on the snapshot mechanism, and then the saved data information and the standard reference model corresponding to the design under test are used to perform data simulation to determine the specific cause of the assertion failure. For example, the saved data information can be transferred to the input stimulus and result part of the simulation software, and by observing the variable values, signal transmission paths and other information in the standard reference model during the simulation process, the design under test can be verified in a more fine-grained manner, and the problem can be located more accurately, thereby speeding up the troubleshooting and repair of the problem. After fixing the assertion failure problem, the simulation can be rerun to verify the effectiveness of the repair and ensure that the assertion no longer fails.

[0140] In summary, the present embodiment provides a circuit verification method that converts assertion statements into an assertion circuit, a synthesizable register conversion-level circuit that can be directly used for hardware testing. A target netlist is generated based on the assertion circuit and the design under test, and then the assertion circuit and the design under test are configured into an FPGA based on the target netlist. The assertion circuit is used to reveal the internal state and potential problems of the design under test, thus resolving the problem of FPGA simulation lacking low-level visibility into design details. Furthermore, hardware is used to accelerate debugging of the design under test, improving the verification efficiency of the design under test.

[0141] It should be noted that for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present application are not limited by the order of the actions described, because according to the embodiments of the present application, certain 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 involved are not necessarily required by the embodiments of the present application.

[0142] Device embodiment

[0143] 2 , a block diagram of a circuit verification device of the present application is shown. The device may include:

[0144] The file acquisition module 201 is used to acquire a design file, wherein the design file includes a design under test and an assertion statement; the assertion statement is used to verify whether the design under test meets the test conditions;

[0145] An assertion conversion module 202, configured to convert the assertion statement into an assertion circuit, wherein the assertion circuit is a register conversion stage circuit;

[0146] A netlist generation module 203 is configured to generate a target netlist based on the design under test and the assertion circuit;

[0147] A chip configuration module 204 is configured to configure the design under test and the assertion circuit into an integrated circuit chip according to the target netlist;

[0148] Assertion monitoring module 205, for running the integrated circuit chip and monitoring assertion results of the design under test;

[0149] The result determination module 206 is configured to determine that the design under test has passed verification if the assertion coverage of the design under test meets a preset condition.

[0150] Optionally, the assertion conversion module includes:

[0151] A file parsing submodule, configured to parse the design file to obtain an abstract syntax tree; the abstract syntax tree is configured to reflect the logical structure and semantics of the design file;

[0152] A traversal submodule, configured to traverse the abstract syntax tree to obtain a sentence tree of a segmentation language in the abstract syntax tree;

[0153] The synthesis submodule is used to perform circuit synthesis processing on the assertion language sentence tree to obtain an assertion circuit, where the assertion circuit is a register conversion level circuit.

[0154] Optionally, the comprehensive submodule includes:

[0155] An analysis unit, configured to analyze the assertion sentence tree in the abstract syntax tree and identify keywords and assertion statement expressions in the assertion sentence tree;

[0156] An instantiation unit, configured to instantiate keywords in the sentence tree of the said analysis language into a basic circuit module;

[0157] A parsing unit, configured to perform semantic parsing on the assertion statement expression to determine a connection mode between the basic circuit modules;

[0158] The connecting unit is used to connect the basic circuit modules according to the connection mode to obtain an assertion circuit.

[0159] Optionally, the netlist generation module includes:

[0160] an assertion parsing submodule, configured to parse the assertion statement to obtain signal connection information between the design under test and the assertion circuit;

[0161] The netlist generation submodule is used to generate a target netlist based on the signal connection information, the design under test and the assertion circuit; the target netlist is used to describe the connection between the design under test and the assertion circuit using logic gates.

[0162] Optionally, the netlist generation submodule includes:

[0163] a netlist generating unit, configured to convert the design under test into a first netlist and convert the assertion circuit into a second netlist;

[0164] A netlist stitching unit is used to stitch the first netlist and the corresponding parts of the second netlist based on the signal connection information to obtain a target netlist; in the target netlist, the signal input end of the second netlist is connected to the output end of the signal to be monitored in the first netlist.

[0165] Optionally, the chip configuration module includes:

[0166] A bitstream file generating submodule, configured to generate a target bitstream file according to the target netlist;

[0167] The circuit burning submodule is used to burn the design under test into the static area of ​​the integrated circuit chip based on the target bitstream file, and burn the assertion circuit into the dynamic partial reconfiguration area of ​​the integrated circuit chip.

[0168] Optionally, a coverage monitor is further configured in the static area of ​​the integrated circuit chip; the assertion monitoring module includes:

[0169] a sampling submodule, configured to operate the integrated circuit chip and sample assertion results of the design under test through the coverage monitor to determine the number of correct assertions corresponding to the design under test;

[0170] The result determination module includes:

[0171] The result determination submodule is used to determine that the design under test has passed the verification if the number of correct assertions corresponding to the design under test is greater than or equal to a preset threshold.

[0172] Optionally, the device further comprises:

[0173] The circuit replacement module is used to replace the assertion circuit in the dynamic partial reconfiguration area when the assertion coverage of the design under test meets a preset condition, so as to perform the next round of assertion verification on the design under test.

[0174] Optionally, the device further comprises:

[0175] A snapshot module, configured to save a snapshot of data information of each register in the design under test when an assertion result of the design under test is an assertion failure;

[0176] The simulation module is used to perform data simulation based on the stored data information and the standard reference model corresponding to the design under test, so as to locate the cause of the assertion failure of the design under test and perform error debugging and repair.

[0177] Optionally, in the target netlist, an input terminal of the assertion circuit is connected to an output terminal of a signal to be monitored in the design under test.

[0178] Optionally, the device further comprises:

[0179] The failed checking module is used to determine that the design under test has failed verification when the number of correct assertions of the design under test is less than the preset threshold.

[0180] Optionally, the simulation module includes:

[0181] An input submodule, configured to transmit the stored data information to an input stimulus and result part of the simulation software;

[0182] The verification submodule is used to detect the variable values ​​and signal transmission paths in the standard reference model during the simulation process, verify the design under test, locate the cause of the assertion failure of the design under test, and perform error debugging and repair.

[0183] Optionally, the integrated circuit chip is a FPGA.

[0184] In summary, the embodiments of the present application provide a circuit verification device that converts assertion statements into an assertion circuit, a synthesizable register conversion-level circuit that can be directly used for hardware testing. A target netlist is generated based on the assertion circuit and the design under test, and then the assertion circuit and the design under test are configured into an FPGA based on the target netlist. The assertion circuit is used to reveal the internal state and potential problems of the design under test, thus resolving the problem of FPGA simulation's lack of low-level visibility into design details. Furthermore, hardware is used to accelerate debugging of the design under test, improving the verification efficiency of the design under test.

[0185] The various component embodiments of the present application can be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof. It will be appreciated by those skilled in the art that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components in the computing processing equipment according to the embodiment of the present application. The application can also be implemented as a device or apparatus program (for example, a computer program and a computer program product) for performing a part or all of the methods described herein. Such a program implementing the present application can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0186] For example, FIG3 illustrates a computing device that can implement the methods according to the present application. The computing device typically includes a processor 1010 and a computer program product or computer-readable medium in the form of a memory 1020. Memory 1020 can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, a hard disk, or ROM. Memory 1020 has storage space 1030 for program code 1031 for executing any of the method steps described above. For example, storage space 1030 for program code can include individual program codes 1031 for implementing various steps in the method described above. These program codes can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards, or floppy disks. Such computer program products are typically portable or fixed storage units, as described with reference to FIG4 . This storage unit can have storage segments, storage space, and the like arranged similarly to memory 1020 in the computing device of FIG3 . The program code can, for example, be compressed in a suitable form. Typically, the storage unit includes computer-readable codes 1031 ′, ie, codes that can be read by a processor such as 1010 , which, when executed by a computing device, cause the computing device to perform the steps of the method described above.

[0187] Figure 5 is a block diagram of an electronic device according to an embodiment of the present invention. As shown in Figure 5 , the electronic device includes a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other via the communication bus. The memory stores executable instructions that cause the processor to execute the circuit verification method according to the aforementioned embodiment.

[0188] The processor may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0189] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, for example. The communication bus may be categorized as an address bus, a data bus, a control bus, etc. For ease of illustration, FIG5 illustrates a single line, but this does not imply a single bus or a single type of bus.

[0190] The memory may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only), a CD-ROM (Compact Disa Read Only), a magnetic tape, a floppy disk, an optical data storage device, etc.

[0191] An embodiment of the present application also provides a computer program product, including a computer program, and a circuit verification method implemented when the computer program is executed by a processor.

[0192] References herein to "one embodiment," "an embodiment," or "one or more embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Furthermore, please note that instances of the phrase "in one embodiment" do not necessarily all refer to the same embodiment.

[0193] In the description provided herein, a large number of specific details are described. However, it is understood that the embodiments of the present application can be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this description.

[0194] In the claims, any reference signs placed between brackets shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present application may be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.

[0195] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0196] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0197] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

[0198] The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

[0199] The above is a detailed introduction to a circuit verification method, device, electronic device computer program and computer-readable storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A circuit verification method, wherein: The method comprises: Obtain a design file, wherein the design file includes a design under test and an assertion statement; the assertion statement is used to verify whether the design under test meets a test condition; converting the assertion statement into an assertion circuit, wherein the assertion circuit is a register conversion stage circuit; generating a target netlist based on the design under test and the assertion circuit; configuring the design under test and the assertion circuit into an integrated circuit chip according to the target netlist; Running the integrated circuit chip and monitoring the assertion results of the design under test; When the assertion coverage of the design under test meets a preset condition, it is determined that the design under test passes the verification.

2. The method according to claim 1, wherein: The step of converting the assertion statement into an assertion circuit comprises: Parsing the design file to obtain an abstract syntax tree; the abstract syntax tree is used to reflect the logical structure and semantics of the design file; Traversing the abstract syntax tree to obtain a sentence tree of the break words in the abstract syntax tree; The assertion sentence tree is subjected to circuit synthesis processing to obtain an assertion circuit, wherein the assertion circuit is a register conversion stage circuit.

3. The method according to claim 2, wherein: The circuit synthesis processing of the assertion sentence tree to obtain the assertion circuit includes: Analyze the assertion sentence tree in the abstract syntax tree to identify keywords and assertion statement expressions in the assertion sentence tree; Instantiate the keywords in the sentence tree of the judgment language into a basic circuit module; Performing semantic analysis on the assertion statement expression to determine the connection mode between the basic circuit modules; The basic circuit modules are connected according to the connection mode to obtain an assertion circuit.

4. The method according to claim 1, wherein: The generating a target netlist based on the design under test and the assertion circuit comprises: Parsing the assertion statement to obtain signal connection information between the design under test and the assertion circuit; A target netlist is generated based on the signal connection information, the design under test and the assertion circuit; the target netlist is used to describe the connection between the design under test and the assertion circuit by using logic gates.

5. The method according to claim 4, wherein: The generating a target netlist based on the signal connection information, the design under test and the assertion circuit comprises: converting the design under test into a first netlist and converting the assertion circuit into a second netlist; Based on the signal connection information, the first netlist and the corresponding parts in the second netlist are stitched to obtain a target netlist; in the target netlist, the signal input end of the second netlist is connected to the output end of the signal to be monitored in the first netlist.

6. The method according to claim 1, wherein: The configuring the design under test and the assertion circuit into the integrated circuit chip according to the target netlist comprises: Generate a target bitstream file according to the target netlist; Based on the target bitstream file, the design under test is burned into a static area of ​​an integrated circuit chip, and the assertion circuit is burned into a dynamic partial reconfiguration area of ​​the integrated circuit chip.

7. The method according to claim 6, wherein: A coverage monitor is also configured in the static area of ​​the integrated circuit chip; and the step of running the integrated circuit chip and monitoring the assertion result of the design under test includes: Running the integrated circuit chip, and sampling the assertion results of the design under test through the coverage monitor to determine the number of correct assertions corresponding to the design under test; The step of determining that the design under test passes verification when the assertion coverage of the design under test meets a preset condition includes: When the number of correct assertions corresponding to the design under test is greater than or equal to a preset threshold, it is determined that the design under test passes the verification.

8. The method according to claim 6, wherein: The method further comprises: When the assertion coverage of the design under test meets a preset condition, the assertion circuit in the dynamic partial reconfiguration region is replaced to perform a next round of assertion verification on the design under test.

9. The method according to claim 1, wherein: After running the integrated circuit chip and monitoring the assertion result of the design under test, the method further includes: When the assertion result of the design under test is an assertion failure, a snapshot of data information of each register in the design under test is saved; Data simulation is performed based on the stored data information and the standard reference model corresponding to the design under test to locate the cause of assertion failure of the design under test and perform error debugging and repair.

10. The method according to claim 1, wherein: In the target netlist, an input terminal of the assertion circuit is connected to an output terminal of a signal to be monitored in the design under test.

11. The method according to claim 7, wherein: The method further comprises: When the number of correct assertions of the design under test is less than the preset threshold, it is determined that the design under test has failed verification.

12. The method according to claim 9, wherein: The data simulation is performed according to the stored data information and the standard reference model corresponding to the design under test to locate the assertion failure cause of the design under test and perform error debugging and repair, including: Transmitting the stored data information to the input stimulus and result part of the simulation software; Detect variable values ​​and signal transmission paths in the standard reference model during the simulation process, verify the design under test, locate the cause of assertion failure of the design under test, and perform error debugging and repair.

13. The method according to any one of claims 1 to 12, wherein: The integrated circuit chip is FPGA.

14. A circuit verification device, wherein: The device comprises: A file acquisition module, used to acquire a design file, wherein the design file includes a design under test and an assertion statement; the assertion statement is used to verify whether the design under test meets the test conditions; An assertion conversion module, used for converting the assertion statement into an assertion circuit, wherein the assertion circuit is a register conversion stage circuit; A netlist generation module, configured to generate a target netlist based on the design under test and the assertion circuit; A chip configuration module, configured to configure the design under test and the assertion circuit into an integrated circuit chip according to the target netlist; An assertion monitoring module, used for running the integrated circuit chip and monitoring the assertion results of the design under test; The result determination module is used to determine that the design under test has passed the verification if the assertion coverage of the design under test meets a preset condition.

15. The device according to claim 14, wherein: The assertion conversion module includes: A file parsing submodule, used to parse the design file to obtain an abstract syntax tree; the abstract syntax tree is used to reflect the logical structure and semantics of the design file; A traversal submodule, used for traversing the abstract syntax tree to obtain a sentence tree of the segmentation language in the abstract syntax tree; The synthesis submodule is used to perform circuit synthesis processing on the assertion language sentence tree to obtain an assertion circuit, wherein the assertion circuit is a register conversion level circuit.

16. The device according to claim 15, wherein: The comprehensive submodule includes: An analysis unit, configured to analyze the assertion sentence tree in the abstract syntax tree, and identify keywords and assertion statement expressions in the assertion sentence tree; An instantiation unit, used for instantiating keywords in the sentence tree of the judgment language into a basic circuit module; A parsing unit, used for performing semantic parsing on the assertion statement expression to determine the connection mode between the basic circuit modules; A connecting unit is used to connect the basic circuit modules according to the connecting mode to obtain an assertion circuit.

17. The device according to claim 14, wherein: The netlist generation module comprises: An assertion parsing submodule, used to parse the assertion statement to obtain signal connection information between the design under test and the assertion circuit; The netlist generation submodule is used to generate a target netlist based on the signal connection information, the design under test and the assertion circuit; the target netlist is used to describe the connection between the design under test and the assertion circuit using logic gates.

18. An electronic device, comprising: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 13.

19. A computer program comprising computer readable code which, when executed on a computing processing device, causes the computing processing device to execute the method according to any one of claims 1 to 13.

20. A computer-readable storage medium storing the computer program according to claim 19, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method according to any one of claims 1 to 13.

Citation Information

Patent Citations

  • Test coverage rate analysis method of circuit path

    CN105808839A

  • Chip research and development method, system and device and storage medium

    CN113850034A

  • FPGA circuit TILE hierarchy connection checking method and device, electronic equipment and storage medium

    CN114692537A

  • Circuit verification method and device, electronic equipment and readable storage medium

    CN116663463A

  • System and method for containing analog verification IP

    US9038008B1

Cited By

  • Hardware acceleration simulation offline debugging method, electronic equipment and medium

    CN120911372A

  • Verification method and device, electronic equipment and readable storage medium

    CN122347103A