Chip design verification method and system, electronic device and storage medium

Abstract

The application provides a chip design verification method, system, electronic equipment and storage medium. The chip design verification method comprises: obtaining a design file of a chip and a design stage corresponding to the design file; selecting a target collaborative verification mode matched with the design stage from multiple collaborative verification modes; wherein the collaborative verification mode comprises a mode of verifying the design file by cooperation between logic simulation verification and formal verification; the collaborative verification modes corresponding to different design stages are different, and the cooperation modes between logic simulation verification and formal verification in different collaborative verification modes are different; and verifying the design file based on the target collaborative verification mode. The method makes logic simulation verification and formal verification work collaboratively, combines their respective advantages for complementation, so as to improve the efficiency and effectiveness of chip design and verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of integrated circuit design, in particular, a chip design verification method and system, an electronic device and a storage medium are provided. BACKGROUND

[0002] The design file verification of a chip includes two ways of logic simulation verification and formal verification, the verification principles of the two ways are different, and each has its own advantages and disadvantages. For example, logic simulation verification simulates the behavior of a system in actual operation by applying excitation and observing response in a controlled environment, to check whether its function is correct, and verification is performed by random testing and directional testing. This way needs to be constructed to be suitable for use in some large scenarios, and some details in depth may not be verified.

[0003] Formal verification uses formal methods to exhaust all possible behaviors to ensure the logical correctness of the module. It is suitable for verifying some specific function points, but for some scenarios with large amount of calculation, it may exceed the calculation capacity of the formal verification tool.

[0004] At present, when verifying the design file of a chip, a more suitable verification method is usually selected according to different stages or different modules. Due to the existence of respective defects, the verification effect and efficiency need to be further improved. SUMMARY

[0005] Therefore, the present application aims to provide a chip design verification method and system, an electronic device and a storage medium to improve the accuracy and efficiency of chip design verification.

[0006] Firstly, the embodiment of the present application provides a chip design verification method, comprising: obtaining a design file of a chip and a design stage corresponding to the design file; selecting a target collaborative verification mode matched with the design stage from a plurality of collaborative verification modes; wherein the collaborative verification mode includes a mode of verifying the design file by cooperation between logic simulation verification and formal verification; the collaborative verification mode corresponding to different design stages is different, and the cooperation mode between logic simulation verification and formal verification in different collaborative verification modes is different; verifying the design file based on the target collaborative verification mode.

[0007] The logic simulation verification and the formal verification each have advantages and disadvantages. In the embodiment of the present application, when the design file of the chip is verified, the logic simulation verification and the formal verification can be used to work cooperatively to combine the advantages of each other, to use the formal verification to solve the points that the logic simulation is not good at, to use the logic simulation to process the scenes that the formal verification cannot verify, to use the formal verification to provide the test cases in depth for the logic simulation, to use the logic simulation to provide the test scenes in breadth for the formal verification, and to work cooperatively to improve the efficiency and accuracy of the verification of the design file of the chip. Wherein, the problems existing in different stages of the chip design are different, and the present application provides different cooperative verification manners in different stages to meet the verification requirements in different stages to improve the verification efficiency and accuracy of different solutions respectively.

[0008] In an embodiment, the logic simulation verification is a verification manner of verifying the design file based on a simulation test platform; the design stage includes a first stage, the first stage is a stage in which the simulation test platform is not constructed completely; a target cooperative verification manner corresponding to the first stage is a first cooperative verification manner; in a case where it is determined that the target cooperative verification manner is the first cooperative verification manner, verifying the design file based on the target cooperative verification manner includes: obtaining a first assertion of a preset functional module in the design file; the design file includes different functional modules, and the first assertion is used to describe the attributes of the preset functional module; performing formal verification on the preset functional module based on the first assertion; and after the simulation test platform is constructed completely and supports the logic simulation verification, performing the logic simulation verification on the preset functional module based on the first assertion.

[0009] The first stage corresponds to an early stage of a chip design project. In the first stage, a test platform for logic simulation verification has not been built, and logic simulation verification cannot be performed. If some key functional modules are tested after the test platform is built, the design progress will be greatly affected. If the key functional modules are not verified in time, but subsequent design and development is performed on the basis of problems in the key functional modules, subsequent chip design may be abnormal. Therefore, formal verification does not require the construction of a test platform. In the embodiments of the present application, formal verification can be performed on the chip design in the first stage to verify some key preset functional modules in advance. Therefore, the principles of formal verification and logic simulation verification are different. In order to make the subsequent logic simulation verification match the results of formal verification as much as possible, an assertion can be written for formal verification. The assertion is a property that needs to be proved and is used to define the functions that need to be implemented by the chip design and what needs to be done. Therefore, the chip design can be verified in advance without waiting for the test platform, the design efficiency is improved, and the design period is shortened on the basis of ensuring the correctness of the chip design. At the same time, after the test platform is built, the first assertion can also be used for logic simulation verification to verify from different angles to ensure the correctness of the chip design.

[0010] In an embodiment, the design stage includes a second stage, the second stage is a stage in which the design file includes complete functions of a chip and supports logic simulation verification; the target collaborative verification mode corresponding to the second stage is a second collaborative verification mode; and when it is determined that the target collaborative verification mode is the second collaborative verification mode, verifying the design file based on the target collaborative verification mode includes: performing logic simulation verification on the design file to obtain vulnerability information determined by the logic simulation verification; configuring a first to-be-verified property of formal verification based on the vulnerability information; and performing formal verification on the first to-be-verified property.

[0011] The second stage corresponds to a middle stage of a chip design project. In the second stage, the basic functions of the chip design are basically completed, and the test stimulus and the test platform can start stable testing. In the embodiments of the present application, the properties extracted from the vulnerabilities found by the logic simulation verification can be used for formal verification to increase the breadth of formal verification, reduce the difficulty of constraint writing, improve the correctness of constraint writing, thereby improving the efficiency and accuracy of formal verification, and further reducing the time required in the entire cycle of chip design and improving the efficiency of chip design.

[0012] In an embodiment, the design stage includes a third stage, the third stage being a stage of performing coverage detection on the design file, wherein the coverage detection includes simulation coverage detection performed on the design file after logic simulation verification and formal coverage detection performed after formal verification; the target collaborative verification mode corresponding to the third stage is a third collaborative verification mode; in a case where it is determined that the target collaborative verification mode is the third collaborative verification mode, the verification of the design file based on the target collaborative verification mode includes: performing the simulation coverage detection on the design file to obtain a simulation coverage detection result, the simulation coverage detection result including uncovered functions; configuring corresponding second to-be-verified attributes for the uncovered functions; performing formal verification on the uncovered functions based on the second to-be-verified attributes; performing the formal coverage detection on the uncovered functions after the formal verification to obtain a formal coverage detection result; determining coverability of the uncovered functions based on the simulation coverage detection result and the formal coverage detection result; and adjusting execution of next logic simulation verification based on the coverability.

[0013] The third stage corresponds to a late stage of a chip design project. In the late stage of the chip design project, coverage detection is performed. The coverage detection is used to detect whether each function and code in the chip design is covered by a test case, so as to determine whether each function and code is correctly executed. However, the logic simulation verification may also have some problems that cannot be detected or have low detection efficiency, so that the coverage rate is difficult to be quickly reduced, and the verification efficiency is affected. Therefore, in the embodiments of the present application, in the third stage, a second to-be-verified attribute can be configured for an uncovered function based on the logic simulation verification, and the formal verification is performed on the second to-be-verified attribute in a manner of formal verification, so as to determine whether the uncovered function can be covered. In this way, the formal verification verifies the function that cannot be verified by the logic simulation verification in a short time from another angle, so that the logic simulation no longer verifies the uncovered function or provides some help for the verification of the uncovered function by the logic simulation. Therefore, the efficiency of the logic simulation is improved.

[0014] In an embodiment, before the corresponding second to-be-verified attribute is configured for the uncovered function, the method further includes: determining that a change rate of simulation coverage is lower than a preset threshold, wherein the change rate of simulation coverage is determined based on a plurality of historical simulation coverages obtained through a plurality of historical simulation coverage detections.

[0015] In the stage of low simulation coverage, problems can be quickly determined and solved to quickly improve the simulation coverage, and therefore, in the embodiment of the present application, the second to-be-verified data of the second to-be-verified property of the logic simulation can be configured by using the second to-be-verified property after the coverage reaches a platform stage (i.e., the change rate of the simulation coverage is lower than a preset threshold), so as to avoid the situation that the efficiency of the logic simulation verification is reduced due to the extra work caused by the formal verification.

[0016] In an embodiment, the logic simulation verification includes directional testing of verifying the design file based on a directional test case; and the adjusting the execution of the next logic simulation verification based on the coverability includes: in a case that the coverability indicates that the uncovered function is coverable, modifying an assertion of the uncovered function to an opposite assertion; performing formal verification on the uncovered function based on the opposite assertion; in a case that the formal verification fails, obtaining a first counterexample generated after the formal verification on the uncovered function based on the opposite assertion; and generating a directional test case based on the first counterexample, so that the next logic simulation verification performs directional testing on the uncovered function based on the directional test case.

[0017] In the embodiment of the present application, the formal verification is performed on the uncovered function, if the formal verification determines that the uncovered function is coverable, the assertion of the uncovered function can be modified to an opposite assertion for verification, if the formal verification of the opposite assertion fails, it is proved that the uncovered function is coverable, further, the first counterexample generated by the opposite assertion can be used to configure a directional test case, so that the uncovered function can be covered in the next coverage detection. This method can reduce the time consumed by the logic simulation when different test cases are enumerated for verification, thereby improving the efficiency of the logic simulation verification.

[0018] In an embodiment, the adjusting the execution of the next logic simulation verification based on the coverability includes: in a case that the coverability indicates that the uncovered function is not coverable, excluding the uncovered function from the simulation coverage detection, and then performing the next logic simulation verification and the simulation coverage detection on the design file.

[0019] In the embodiment of the present application, in a case that the uncovered function is not coverable, the design or constraint representing the uncovered function itself has a problem, or the uncovered function itself does not need to be covered, therefore, the uncovered function can be excluded from the simulation coverage detection, so as to avoid the uncovered function participating in the coverage detection, thereby improving the progress of the coverage detection, shortening the time consumed by the chip design in the coverage detection stage, and improving the design efficiency.

[0020] In one embodiment, after performing simulation coverage detection on the design document, the method further includes: configuring random test cases based on the simulation coverage detection results; the logic simulation verification includes random testing to verify the design document based on the random test cases; and random testing to perform the next logic simulation verification on the design document based on the random test cases.

[0021] Logic simulation verifies whether various functions are covered through random and targeted testing. Targeted testing generally has predetermined constraints, while random testing randomly selects values ​​from a given range of constraints. Therefore, the results of random testing are affected by the constraints. If the constraints are too strong, the testing scope of random testing may be affected, resulting in some functions and code not being verified or covered. Therefore, in this embodiment, the simulation coverage rate can be used to determine whether constraints need to be adjusted, so that random testing can perform more effective verification, covering more functions and code, thereby improving testing efficiency and accuracy.

[0022] In one embodiment, after performing random testing on the design document for the next logic simulation verification based on the random test cases, the method further includes: determining whether the random test result of the random test satisfies a preset constraint over-strength condition; if it is determined that the random test result satisfies the preset constraint over-strength condition, adjusting the random test cases based on the simulation coverage detection result and the random test result; and performing random testing on the design document based on the adjusted random test cases.

[0023] In this embodiment, it can be determined whether the current constraint is too strong by judging whether the random test result meets the preset constraint too strong condition. If the constraint is too strong, the random test cases can be adjusted based on the simulation coverage detection results and the random test results. The constraint can be adjusted through the feedback of the simulation coverage. This method helps to improve the rationality and accuracy of the constraint. At the same time, it reduces the workload and time required for engineers to analyze the constraint, which helps to improve the verification efficiency.

[0024] In one embodiment, the method further includes: after any formal verification of the design document, obtaining the current formal verification result; if the current formal verification result determines that there is a state space explosion, dividing the functional modules in the design document to obtain multiple functional modules to be verified; performing formal verification on each of the functional modules to be verified to obtain their respective sub-formal verification results; and determining a new formal verification result based on the formal verification sub-results of each functional module to be verified.

[0025] The main challenge of formal verification lies in state space explosion. Formal verification exhaustively verifies a large number of input sequences and initial states. In complex designs, the number of input sequences and initial states increases exponentially, causing the state space to grow beyond the computational capabilities of formal verification tools. This leads to a significant increase in time consumption or termination due to insufficient tool memory. Therefore, state space explosion significantly impacts the efficiency of formal verification. In this embodiment, when state space explosion is detected, the chip design file can be divided into modules, and formal verification can be performed on each module separately. This allows formal verification to focus on simpler functional modules, reducing the complexity of a single verification, minimizing the risk of state space explosion, and improving verification efficiency and accuracy.

[0026] In one embodiment, the step of dividing the functional modules in the design file includes: detecting target design elements that cause the state space to explode; for each target design element, determining the complete function of the target design element based on its context in the design file, wherein the target design element with complete function represents a functional module to be verified; the step of performing formal verification on each functional module to be verified to obtain sub-formal verification results includes: constructing equivalent models corresponding to each target design element with complete function; performing formal verification on each equivalent model to obtain sub-formal verification results corresponding to each functional module to be verified; the step of determining a new formal verification result based on the formal verification sub-results of each functional module to be verified includes: mapping the sub-formal verification results back to the current formal verification result to obtain the new formal verification result.

[0027] In this embodiment, for complex chip designs, the design elements that lead to state space explosion can be identified, and equivalent models can be constructed for formal verification. This allows the complex model to be broken down into multiple simpler models for separate formal verification, reducing model complexity and thus decreasing the likelihood of state space explosion. Finally, the verification results of each equivalent model are mapped back to the current formal verification result to obtain the new formal verification result. This method effectively reduces the possibility of state space explosion and helps improve the verification efficiency of formal verification.

[0028] In one embodiment, the method further includes: after any formal verification of the design document, obtaining the current formal verification result of that formal verification; if it is determined through the current formal verification result that there is a state space explosion, performing logical simulation verification on the current constraints and attributes used in that formal verification, wherein the current constraints and data are the custom constraints and attributes used in that formal verification.

[0029] Some state space explosions may be caused by incorrect definition of constraints or attributes. Therefore, in this embodiment, constraints and attributes can be cross-validated by combining logic simulation verification to identify the constraints and attributes that cause state space explosions. Cross-validation by logic simulation verification can effectively reduce the workload required for engineers to analyze problems and reduce the time spent to speed up the verification process.

[0030] In one embodiment, the method further includes: after any logic simulation verification of the design document, obtaining the current logic simulation verification result of that logic simulation verification; generating a second assertion based on the signal relationships in the current logic simulation verification result; and performing formal verification on the design document based on the second assertion.

[0031] In this embodiment, a second assertion can be generated based on the signal relationships in the logic simulation results, reducing the workload of engineers in analyzing the logic simulation results and thus improving verification efficiency. Simultaneously, generating assertions based on the logic simulation results for formal verification allows for cross-verification of logic simulation and formal verification, which helps improve the accuracy of verifying chip design documents.

[0032] In one embodiment, the method further includes: after any formal verification of the design document, obtaining a second counterexample obtained through formal verification; generating test cases based on the second counterexample; and performing logical simulation verification on the design document based on the test cases.

[0033] In this embodiment, test cases for logic simulation can be generated based on the second counterexample of formal verification, reducing the workload of engineers in analyzing the second counterexample and thus improving verification efficiency. Furthermore, generating test cases based on the second counterexample of formal verification allows for cross-verification of logic simulation and formal verification, which helps improve the accuracy of verifying the chip's design documents.

[0034] Based on the same inventive concept, this application also provides a chip design verification system, including: an input module for acquiring chip design files and the design stage corresponding to the design files; a decision module for selecting a target collaborative verification method matching the design stage from multiple collaborative verification methods; wherein, the collaborative verification method includes a method of verifying the design files through collaboration between logic simulation verification and formal verification; different collaborative verification methods correspond to different design stages, and the collaboration method between logic simulation verification and formal verification differs in different collaborative verification methods; and a verification module for verifying the design files based on the target collaborative verification method.

[0035] Thirdly, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor causes the processor to perform the chip design verification method as described in any of the first aspects.

[0036] Fourthly, embodiments of this application also provide a readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the chip design verification method as described in any of the first aspects. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A flowchart illustrating a chip design verification method provided in one embodiment of this application;

[0039] Figure 2 A schematic diagram illustrating the collaborative verification relationship between logic simulation and formal verification, provided as an embodiment of this application;

[0040] Figure 3 This is a schematic diagram of a chip design verification system provided in an embodiment of this application.

[0041] Icons: Chip Design Verification System 300; Input Module 310; Decision Module 320; Verification Module 330. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0043] In the embodiments of this application, logic simulation verification and formal verification are involved. The specific principles, implementation methods and details of logic simulation verification and formal verification can be referred to the prior art. In order to facilitate the understanding of the embodiments of this application, the principles, processes and defects of logic simulation verification and collaborative verification will be briefly explained first.

[0044] First, logic simulation verification is a dynamic, test case-based verification method. The verification principle includes: in a controlled environment, by applying stimuli and observing the response, simulating the behavior of the system in actual operation, thereby checking whether the chip design functions correctly.

[0045] The basic process of logic simulation verification can be divided into the following five steps: setting up a test platform, generating stimuli, running the simulation, checking the response, and comparing the results. Setting up a test platform involves creating a simulated environment, also known as a "testbench," which contains the design to be verified. Generating stimuli involves the test platform generating a series of input signals, also called stimuli, which are applied to the chip design to be verified. These stimuli need to be carefully designed to cover various normal, boundary, and abnormal scenarios. Running the simulation involves using simulation tools to execute the dynamic process of verification, simulating the design's behavior changes over time. Checking the response involves observing the simulation tool's output signals, internal states, or log files related to the chip design. Comparing the results involves comparing the observed results with the expected correct results to determine whether the test passed.

[0046] The above describes the basic process of logic simulation verification. Logic simulation suffers from problems such as inexhaustibility, complex test platform construction, slow simulation speed, and potential hidden vulnerabilities. While logic simulation uses targeted and random testing to measure as many scenarios as possible, it cannot test all scenarios and all input combinations, leading to inexhaustibility and hidden vulnerabilities. Furthermore, testing requires building a test platform and specifying fine-grained test stimuli based on the chip being verified, impacting verification efficiency. In addition, simulation platforms require significant time for some large-scale chip designs, also affecting efficiency.

[0047] Formal verification is a rigorous, mathematics-based technique used to verify whether a hardware or software system satisfies certain specific formal specifications or properties. Formal verification is a mathematical proof process designed to prove that a system's design is "correct" relative to its expected behavior. It is static analysis, exhaustively analyzing all possible inputs and system states through mathematical reasoning and algorithms.

[0048] Formal verification requires exhaustively analyzing all possible inputs and system states through mathematical reasoning and algorithms. This can lead to state space explosion; as design complexity increases, the state space grows exponentially, exceeding the computational capabilities of formal verification tools. These tools may fail to complete the proof within a reasonable timeframe or terminate due to memory shortages. Furthermore, formal verification requires defining constraints to define the input space. Overly restrictive constraints may miss reasonable scenarios, while overly broad constraints may verify meaningless cases. Additionally, formal verification is typically only applicable to RTL (Register Transfer Level) or other abstract models, making it difficult to apply directly to large-scale designs. Moreover, when a formal verification property fails, the tool provides a counterexample waveform, requiring engineers to backtrack the problem and determine completeness limits to avoid non-compliant situations.

[0049] Based on the principles and limitations of formal verification and logic simulation, this application provides a chip design verification method that combines the advantages of both formal verification and logic simulation to improve verification efficiency and accuracy.

[0050] In the embodiments of this application, the chip design verification method can be implemented by an engineer using relevant verification tools, or the chip design verification method can be configured as a program to implement the chip design verification method provided in this application on electronic devices such as computers and servers. For example, a corresponding chip design verification system can be configured on the electronic device. This chip design verification system connects to logic simulation test tools and test platforms, simulation verification tools, and can receive input design files and call logic simulation and formal verification tools for verification to execute the corresponding verification process. The following description will use an electronic device to execute the chip design verification method provided in this application.

[0051] Please see Figure 1 , Figure 1 This is a flowchart illustrating a chip design verification method provided in one embodiment of this application. The chip design verification method includes:

[0052] S110: Obtain the chip's design file and the corresponding design stage.

[0053] In the embodiments of this application, corresponding verification methods are provided for different design stages of the chip. Therefore, in the embodiments of this application, the design file can be the file corresponding to each design stage of the chip, and it may not include the file for the full functionality of the chip, but may be the design file corresponding to some functional modules. The design file may be an RTL file.

[0054] In embodiments of this application, the design phase is matched with the chip design cycle, including but not limited to the early, middle, and late stages of chip design. In some embodiments of this application, when the method of this application is applied to an electronic device, the design phase can be input by an engineer into the electronic device based on the actual working conditions of the project, or it can be determined by a program on the electronic device through testing the design documents and other verification environments.

[0055] S120: Select the target collaborative verification method that matches the design phase from multiple collaborative verification methods.

[0056] In the embodiments of this application, the collaborative verification method includes a method of verifying design documents through collaboration between logic simulation verification and formal verification. Collaborative work refers to the simultaneous participation of logic simulation and formal verification when verifying the same design document or a functional module within a design document. A scenario where one functional module uses formal verification while another uses logic simulation is not within the scope of the collaborative work described in this application.

[0057] In the embodiments of this application, the collaborative verification methods are different for different design stages, and the collaborative methods between logic simulation verification and formal verification are different in different collaborative verification methods.

[0058] For chip design, the correctness and timeliness of chip functionality need to be verified at different design stages. However, the design completion level and workload vary at different stages, leading to differences in verification methods and objectives. For example, in the early stages of a chip design project, when the design is not yet complete, only some key functional modules may need verification. In the middle stages, when the chip design is largely complete, the main task is vulnerability detection; vulnerabilities are identified through verification and corresponding adjustments are made. Therefore, in the embodiments of this application, corresponding collaborative verification methods are provided for different design stages. The specific collaborative verification methods will be elaborated upon later and will not be discussed further here.

[0059] S130 verifies the design documents based on the target collaborative verification method.

[0060] In the embodiments of this application, after determining the target collaborative verification method, the design documents can be verified based on the target collaborative verification method.

[0061] In this application embodiment, when verifying chip design documents, logic simulation verification and formal verification can work together to combine their respective advantages. Formal verification can address the limitations of logic simulation. For example, for some complex functions where formal verification is prone to state space explosion, logic simulation can handle scenarios that formal verification struggles with, thus compensating for the lack of verification depth in formal verification. Conversely, for components such as arithmetic units and arbitrators, where there are numerous possible scenarios, formal verification provides as many possible scenarios as possible, thereby compensating for the lack of verification breadth in logic simulation. The two work together to improve the efficiency and accuracy of chip design document verification. Furthermore, different problems exist at different stages of chip design. This application provides different collaborative verification methods at different stages to meet the verification needs of different stages, thereby improving the verification efficiency and accuracy of different solutions.

[0062] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the relationship between logic simulation verification and formal verification collaborative verification provided in an embodiment of this application. Next, we will combine... Figure 2 The following describes some embodiments of the methods provided in this application.

[0063] In some embodiments of this application, the design phase may include a first phase, a second phase, and a third phase. The first phase, the second phase, and the third phase respectively address the early, middle, and late stages of chip design. A first collaborative verification method, a second collaborative verification method, and a third collaborative verification method are provided for the first phase, the second phase, and the third phase, respectively.

[0064] Logic simulation requires the construction of a complete test platform to test and verify the design documents. The first stage corresponds to the early stage of the project. At this stage, because the chip is still in the design stage and the chip function is not yet complete, the test platform has not been built and logic simulation verification cannot be performed.

[0065] The design documents include different functional modules, such as logic operation units, arbitrators, interrupt controllers, and state machines. Some critical functional modules need to be verified in a timely manner. Waiting for the test platform to be built will seriously affect the design schedule. However, proceeding with the design without verification may result in chip design anomalies early in the project, affecting the correctness of subsequent functional development.

[0066] Therefore, in the first stage, it is necessary to verify some key functional modules in a timely manner. Among them, the functional modules that need to be verified in the first stage are mainly some pure logic operation units. Different types of chip designs have different functional modules that need to be verified in the first stage, which will not be discussed in detail here.

[0067] Formal verification does not require the construction of a corresponding test platform; therefore, verification can begin early in the project. Accordingly, if the design phase is the first phase, the corresponding target collaborative verification method is the first collaborative verification method. When the target collaborative verification method is determined to be the first collaborative verification method, verifying the design documents based on this method can include: obtaining first assertions for preset functional modules in the design documents; performing formal verification on the preset functional modules based on the first assertions; and, after the simulation test platform is built and supports logic simulation verification, performing logic simulation verification on the preset functional modules based on the first assertions. This process also constitutes the process of the first collaborative verification method.

[0068] An assertion is a unique and crucial contract shared by formal verification and logic simulation. It's information used by both to define the attributes or functions of a functional module. In other words, an assertion is an attribute that needs to be proven, defining the functions the chip design needs to implement and what it needs to do. Assertions can be placed in RTL design or verification platforms for easy monitoring of anomalies during simulation. They primarily check the relationships between critical control signals to ensure they are generated according to design requirements. For more details, please refer to existing definitions; further elaboration is omitted here.

[0069] Both logic simulation and collaborative verification need to meet certain requirements. Therefore, in the embodiments of this application, a first assertion can be based on the functional configuration of a preset functional module, and formal verification can be performed using the first assertion. This allows verification to begin early in the project, reducing delays to subsequent work. Furthermore, after the simulation test platform is built and supports logic simulation verification, the first assertion can be used again for verification to ensure its correctness. Even if problems are not identified during formal verification, they can be promptly discovered and adjusted through logic simulation. Thus, both efficiency and accuracy in verifying chip designs can be guaranteed.

[0070] The first assertion can be input by the engineer or derived from the electronic device based on predefined module functions; no restrictions are placed here. Furthermore, the actual functions of assertions differ between logic simulation and formal verification. In logic simulation, assertions act as "monitors," checking design behavior in real time. If a violation occurs, an error is immediately reported, and waveforms can be generated, greatly accelerating debugging. In formal verification, however, assertions are properties that need to be proven. Formal verification tools attempt to prove that the property is satisfied and never violated under all possible input sequences. For details, please refer to existing technologies; further elaboration is omitted here.

[0071] The second phase involves the design documents containing the complete functionality of the chip and supporting logic simulation verification; this phase corresponds to the mid-project stage. In the mid-project stage, the basic functions of the chip design are complete, the test platform, test stimuli, and the design are basically stable. Regression testing using logic simulation can be conducted daily to promptly identify new defects introduced by design modifications that day.

[0072] If the design phase is the second phase, then the target collaborative verification method corresponding to the second phase is the second collaborative verification method. When the target collaborative verification method is determined to be the second collaborative verification method, verifying the design document based on the target collaborative verification method may include: performing logic simulation verification on the design document to obtain vulnerability information determined by the logic simulation verification; configuring a first attribute to be verified based on the vulnerability information; and performing formal verification on the first attribute to be verified. The above method is also the second collaborative verification method.

[0073] Logic simulation verification primarily determines whether a function passes by testing different combinations of input signals. The number of input signal combinations in a chip design is matched to the chip's bit width. A 32-bit chip has 2 to the power of 32 possible input signal combinations. In logic simulation, it is generally impossible to test all input signal combinations. Therefore, regression simulation testing for logic simulation verification typically includes random testing and targeted testing. Random testing is used to test different combinations of input signals, while targeted testing is used to test specific types of input signal combinations.

[0074] In the embodiments of this application, vulnerabilities identified by logic simulation verification can be generalized to a unified attribute for inspection, or a corner case that is less likely to be encountered. That is, based on the vulnerability information, a first attribute to be verified is configured for formal verification, and then formal verification is performed on the first attribute to be verified. In this way, verification is performed from the perspective of formal verification to achieve specific verification of vulnerabilities, achieving an effect similar to targeted testing. On the other hand, it can also increase the breadth of formal verification, reduce the difficulty of writing formal verification constraints, and improve the correctness of constraint writing. This improves the efficiency and accuracy of formal verification, thereby reducing the time required for the entire chip design cycle and improving the efficiency of chip design.

[0075] Next is the third stage, which corresponds to the later stage of the project. The third stage is the stage of coverage testing of the design documents. The coverage testing includes simulation coverage testing of the design documents after logic simulation verification and formal coverage testing after formal verification.

[0076] Coverage serves as a bridge in a feedback loop. During the verification process, code coverage and functional coverage are collected. Functional coverage indicates whether the functional scenarios have been tested, while code coverage indicates which lines of code have been executed.

[0077] Coverage testing can use existing tools, which will not be elaborated here. In the embodiments of this application, coverage is functional coverage or code coverage. Code coverage includes Line Coverage, Branch Coverage, Condition Coverage, Expression Coverage, Toggle Coverage, FSM Coverage, Path Coverage, etc. Line coverage, also known as Statement Coverage, measures whether each executable statement in the code has been executed. Branch coverage measures whether each branch in a conditional statement (e.g., if-else, case) has been executed. Condition coverage measures whether the truth value of each sub-condition (a condition consists of multiple sub-conditions) in a Boolean expression has been tested. Expression coverage, sometimes also called condition combination coverage, requires that all possible combinations of each Boolean expression be tested. Toggle coverage measures whether each bit (signal) in the code toggles from 0 to 1 and from 1 to 0. Finite state machine coverage: measures whether all states in a state machine have been visited and whether transitions between states have been triggered. Path coverage: measures whether all possible execution paths in the code have been executed. For details on these, please refer to existing technologies; further elaboration is not provided here.

[0078] In the embodiments of this application, the specific methods of coverage detection can be the same. The difference between simulation coverage detection and formal coverage detection lies in the different verification methods they target.

[0079] When the design phase is determined to be the third phase, the corresponding target collaborative verification method is determined to be the third collaborative verification method. Accordingly, when the target collaborative verification method is determined to be the third collaborative verification method, the design document is verified based on the target collaborative verification method, including: performing simulation coverage detection on the design document to obtain simulation coverage detection results, the simulation coverage detection results including uncovered functions; configuring corresponding second verification attributes for uncovered functions; performing formal verification on uncovered functions based on the second verification attributes; performing formal coverage detection on uncovered functions after formal verification to obtain formal coverage detection results; determining the coverability of uncovered functions based on simulation coverage detection results and formal coverage detection results; and adjusting the execution of the next logic simulation verification based on the coverability.

[0080] Coverage testing checks whether all functions of the chip design have been tested. Therefore, after simulation coverage testing, the uncovered functions can be analyzed through the test results. If a function is not covered, test stimuli can be configured based on the uncovered function to perform logic simulation. This process can be repeated to achieve 100% coverage.

[0081] Logic simulation requires a considerable amount of time to exhaustively enumerate all possible combinations of input signals to verify uncovered functional points, which is time-consuming. Therefore, in the embodiments of this application, a second attribute to be verified can be configured based on the uncovered functions determined by simulation coverage detection, and formal verification can be performed on the second attribute to be verified. From the perspective of formal verification, it can be determined whether the uncovered function can be covered, thus shortening the verification time. This method helps to improve the efficiency of the coverage detection stage.

[0082] When simulation coverage is low, logic simulation can quickly verify and improve coverage. However, when simulation coverage is low, some special cases are difficult to test, resulting in insufficient functional coverage. Based on this, in some embodiments of this application, before configuring the corresponding second attribute to be verified for the uncovered function, it can be determined that the rate of change of simulation coverage is lower than a preset threshold.

[0083] The rate of change of simulation coverage is determined based on multiple historical simulation coverage measurements. A rate of change of simulation coverage below a preset threshold indicates that the change in simulation coverage is small, reaching a plateau and making further improvement difficult.

[0084] Before reaching a plateau, logic simulation can be used for rapid verification, eliminating the need for formal verification and avoiding its increased complexity and time consumption. However, once the plateau is reached, logic simulation becomes insufficient to improve coverage. At this point, formal verification is used to verify from a different perspective. Formal verification can exhaustively test more scenarios, increasing the depth of verification. Thus, when logic simulation fails to improve coverage, formal verification can quickly enhance coverage.

[0085] In the embodiments of this application, the coverability of uncovered functions is determined based on the simulation coverage detection results and the formal coverage detection results. This can be done by checking whether the uncovered function points in the simulation coverage detection results appear in the formal coverage detection results. If they do not appear, they are considered coverable; if they do appear, they are considered uncoverable.

[0086] The methods for logic simulation verification differ depending on whether the logic is coverable or not.

[0087] In some embodiments of this application, when the coverability characterization shows that the uncovered function is coverable, the assertion of the uncovered function can be modified to the opposite assertion; formal verification is performed on the uncovered function based on the opposite assertion; if the formal verification fails, a first counterexample generated after formal verification of the uncovered function based on the opposite assertion is obtained; and targeted test cases are generated based on the first counterexample so that the next logic simulation verification is performed on the uncovered function based on the targeted test cases.

[0088] In cases where coverage is possible, the simulation of the representation logic may not use the stimulus that triggers the function during testing. Based on this, the assertion of the uncovered function can be modified into a negative assertion. The negative assertion is then used to perform formal verification on the uncovered function to prove the assertion by contradiction. If the formal verification of the negative assertion passes, it is reasonable that the uncovered function cannot be covered. If the formal verification of the negative assertion fails, it indicates that the prior assertion was not triggered. Based on this, the first counterexample generated by the formal verification of the negative assertion can be used to prove the uncovered function, so that the function can be covered in the next verification.

[0089] For example, if simulation coverage identifies an uncovered function: "A equals B", then the assertion can be changed to "A does not equal B" and formal verification can be performed. If the formal verification proves it, it means that the original "A equals B" was never true and does not need to be covered. If the formal verification proves it, it will provide a counterexample to prove "A equals B", and adding this counterexample to the simulation will cover "A equals B".

[0090] Compared to random testing, targeted testing is more likely to trigger this function, but it requires reasonable stimulus settings. Test counterexamples of uncovered functions obtained from formal verification can extract patterns in these uncovered functions to guide stimulus settings, thereby enabling more precise targeted testing. This can reduce the time required for logic simulation and improve verification efficiency.

[0091] Among them, a test counterexample can be a specific test sequence / waveform. Test counterexamples can be obtained directly from the output of the existing formal verification. The specific acquisition method will not be elaborated here.

[0092] In some embodiments of this application, the method of generating random test cases based on test counterexamples may include a direct conversion method, a scenario generalization method, and a method of minimizing reproducible scenarios.

[0093] Direct conversion methods may include: directly converting the input signal sequence in the counterexample into a simulation test vector, extracting the values ​​of all major input ports periodically, keeping the original timing relationship unchanged, setting the same initial state at the start of the test, and reproducing the exact same signal excitation sequence.

[0094] Scenario generalization methods may include: generating more general tests based on the essential features of counterexamples, identifying core patterns that lead to failure rather than specific values, generating multiple variations of the same scenario, extending the time window to capture more relevant behaviors, and adding random perturbations to explore boundary cases.

[0095] The method of minimizing reproducible scenarios includes: extracting the most concise reproducible conditions, removing redundant signal changes that do not affect the failure result, determining the minimum input sequence length, identifying key signals and their timing of change, and constructing the simplest reproducible test cases.

[0096] In some embodiments of this application, when the uncovered function is not covered in the coverage characterization, the uncovered function is excluded from the simulation coverage detection, and then the design document is subjected to the next logic simulation verification and simulation coverage detection.

[0097] For functions that cannot be covered, it indicates that there are problems with the design or constraints of the function, or that the uncovered function is redundant and does not need to be covered. Therefore, the uncovered function can be excluded from the simulation coverage test, thus avoiding the participation of the uncovered function in the coverage test. This can improve the progress of coverage testing, shorten the time spent in the coverage testing stage of chip design, and improve design efficiency.

[0098] In some embodiments of this application, after performing simulation coverage detection on the design document, random test cases can be configured based on the simulation coverage detection results; and random tests can be performed on the design document for the next logic simulation verification based on the random test cases.

[0099] Logic simulation verification includes random testing, which verifies design documents based on randomized test cases. Random Constraint-Based Testing (Random Testing) is a widely used technique in modern verification methodologies. It utilizes randomization to generate test vectors and uses constraints to guide the randomization process to cover specific functionalities. For details, please refer to existing technologies; further elaboration is not provided here.

[0100] Coverage reflects the rationality of constraints used in logic simulation. Overly strong or overly loose constraints in random testing can negatively impact the accuracy and efficiency of logic simulation tests. For example, overly strong constraints typically refer to overly strict conditions or aggressive stimulus generation in random testing, potentially leading to: excessively long simulation times, constraint conflicts, coverage gaps, reduced verification efficiency, and difficulty in achieving coverage targets. Excessively long simulation times are caused by overly strong constraints making it difficult for the randomized solver to find solutions that meet the conditions within a reasonable timeframe. Constraint conflicts arise because too many constraints may conflict with each other, causing randomization to fail and preventing the generation of effective stimuli. Coverage gaps occur because overly strong constraints may limit the diversity of randomized stimuli, resulting in some boundary cases or functionalities not being covered. Reduced verification efficiency arises because overly specific generated stimuli may lead to repeated testing of the same or similar scenarios, neglecting other scenarios that need testing. Finally, achieving coverage targets is difficult because limited stimulus diversity may prevent coverage (including code coverage and functional coverage) from meeting expectations. Conversely, with overly loose constraints, logic simulation may verify meaningless or illegal states, wasting time and resources. Therefore, it is necessary to set constraints appropriately.

[0101] In the embodiments of this application, simulation coverage can be used to guide the setting of constraints in order to obtain better random test cases, perform more effective verification, improve the coverage of logic simulation efficiency, improve simulation coverage, and thus improve test efficiency and accuracy.

[0102] In some embodiments of this application, after performing random testing on the design document for the next logic simulation verification based on random test cases, it can be determined whether the random test result of the random test meets the preset constraint over-strength condition; if it is determined that the random test result meets the preset constraint over-strength condition, the random test cases are adjusted based on the simulation coverage detection result and the random test result, and then the design document is randomly tested based on the adjusted random test cases.

[0103] As mentioned earlier, excessively strong constraints may affect the verification effect and efficiency. Accordingly, in the embodiments of this application, in addition to judging whether the constraints are too strong based on the coverage rate, the effect of random testing can also be used to judge whether the preset excessively strong constraint conditions are met. The preset excessively strong constraint conditions include, but are not limited to, the simulation time being too long, constraint conflicts, coverage loopholes, low verification efficiency, and difficulty in achieving the coverage target mentioned in the foregoing embodiments. These conditions can be configured according to actual verification needs and will not be elaborated here.

[0104] In the embodiments of this application, random test cases are adjusted based on simulation coverage detection results and random test results, including but not limited to moderate use of constraints, use of soft constraints, hierarchical constraints, coverage feedback, and periodic constraint review. Moderate use of constraints includes adding only necessary constraints to ensure that the basic rules of the design are followed, but without over-constraining. Use of soft constraints includes soft constraints that can be rewritten when needed to adjust constraint conditions in specific tests. Hierarchical constraints include dividing constraints into multiple levels, such as basic constraints and test-specific constraints, which allows for flexible adjustment in different tests. Coverage feedback includes using coverage data to dynamically adjust constraints, guiding random stimuli to be generated towards uncovered areas. Periodic constraint review includes periodically checking constraint conditions to ensure that they are not too strict and do not conflict with each other. In some verification tools, the strength of constraints can also be adjusted by the on / off state and weight distribution of constraints, thereby avoiding the problem of over-constraint.

[0105] Therefore, by judging whether the random test results meet the preset condition of excessively strong constraints, it can be determined whether the current constraints are too strong. If the constraints are too strong, the random test cases can be adjusted based on the simulation coverage test results and the random test results. The constraints can be adjusted through the feedback of the simulation coverage. This method helps to improve the rationality and accuracy of the constraints. At the same time, it reduces the workload and time required for engineers to analyze the constraints, which helps to improve the verification efficiency.

[0106] The main problem with formal constraints is the explosion of state space. This application also provides some methods to address this issue. The explosion of state space can occur in any formal verification, and is not limited to a specific design stage.

[0107] State space explosion refers to the phenomenon where the number of design states that formal verification tools need to analyze grows exponentially with the design size (such as the number of variables, register bits, and state machine states), leading to insufficient computational resources (such as memory and time) and making verification impossible. State space explosion can cause a sharp increase in memory usage, excessively long verification times, tool errors or crashes, and failure to converge.

[0108] To address this issue, in one embodiment of this application, after any formal verification of the design document, the current formal verification result is obtained; if the current formal verification result indicates the existence of state space explosion, the various functional modules in the design document can be divided to obtain multiple functional modules to be verified; formal verification is performed on each functional module to be verified to obtain their respective sub-formal verification results; and a new formal verification result is determined based on the formal verification sub-results of each functional module to be verified.

[0109] In this embodiment, the chip design can be divided into multiple functional modules, and these modules can be formally verified separately to simplify the complexity of a single model that needs to be verified, avoid too many combinations of input signals, and thus reduce the possibility of state space explosion.

[0110] In one embodiment of this application, the functional modules in the design document are divided, including: detecting target design elements that cause state space explosion; for each target design element, determining the complete function of the target design element based on its context in the design document; and performing formal verification on each functional module to be verified to obtain sub-formal verification results, including: constructing equivalent models corresponding to each target design element with complete function; and performing formal verification on each equivalent model to obtain sub-formal verification results corresponding to each functional module to be verified. Accordingly, determining a new formal verification result based on the formal verification sub-results of each functional module to be verified may include: mapping the sub-formal verification results back to the current formal verification result to obtain a new formal verification result.

[0111] State space explosion usually occurs when a module is too complex and its input signal combinations become too numerous when it is used in conjunction with other components. Therefore, by identifying the target design component in the chip design file that causes state space explosion, it can be extracted and formally verified separately to avoid the situation where the design component has too many input signal combinations when it is used in conjunction with other modules.

[0112] Accordingly, in the embodiments of this application, a target design element with complete functionality represents a functional module to be verified. When extracting the target design file, it is necessary to extract it according to the context of its attributes. By abstracting and retaining relevant logic, the corresponding equivalent model is determined. The state space of the equivalent module will be smaller, so that the possibility of state space explosion can be effectively reduced when performing formal verification.

[0113] Finally, formal verification is performed on each equivalent model to obtain the sub-formal verification results corresponding to each functional module to be verified. The sub-formal verification results are then mapped back to the current formal verification result (or the original formal verification result, the initial formal verification result) to obtain a new formal verification result.

[0114] In some other embodiments of this application, after any formal verification of the design document, the current formal verification result of that formal verification is obtained; if it is determined through the current formal verification result that there is a state space explosion, logical simulation verification can also be performed on the current constraints and attributes used in that formal verification.

[0115] The current constraints and data are custom constraints and attributes used in this formal verification. These manually defined constraints and attributes may contain errors, leading to state space explosion. Therefore, in the embodiments of this application, the constraints and attributes can also be cross-validated by logic simulation verification to identify the constraints and attributes that cause state space explosion. Through the cross-validation of logic simulation verification, the workload required for engineers to analyze problems can be effectively reduced, and the time spent can be reduced to speed up the verification efficiency.

[0116] The above-described method of abstracting equivalent models can also be applied to formal verification in other scenarios. For example, when both the RTL file and its abstract equivalent model, model A, fail formal verification, we can further abstract a model B that is more abstract than model A. Then, we can perform formal verification on the RTL and model B, and then perform formal verification on model B and model A. If both formal verifications pass, it can be concluded that the RTL and model A are equivalent.

[0117] In addition to solving the problem of state space explosion, the above-mentioned cross-verification method of logic simulation verification and formal verification can be applied to all stages of chip design document verification.

[0118] For example, in one embodiment, after any logic simulation verification of the design document, the current logic simulation verification result of that logic simulation verification is obtained; a second assertion is generated based on the signal relationships in the current logic simulation verification result; and the design document is formally verified based on the second assertion.

[0119] In this embodiment, formal verification can be used for cross-verification after logic simulation verification. This approach helps improve the accuracy of verifying chip design documents. Specifically, in this cross-verification, a second assertion is generated based on the signal relationships in the logic simulation results, reducing the workload for engineers analyzing the logic simulation results and thus improving verification efficiency.

[0120] Among them, signal relationships include, but are not limited to, logical relationships, timing relationships, implication relationships, repetition relationships, and sequence relationships. At least one of these relationships can be selected for use according to the actual needs of chip design.

[0121] For example, after any formal verification of the design document, obtain a second counterexample that passes the formal verification; generate test cases based on the second counterexample; and perform logical simulation verification on the design document based on the test cases.

[0122] Correspondingly, logic simulation verification can be used after formal verification to achieve cross-validation, improving the accuracy of verifying the chip design documents. Specifically, after formal verification, test cases for logic simulation can be generated based on the second counterexample produced by formal verification. These test cases include, but are not limited to, directed test cases and random test cases.

[0123] The first and second counterexamples are both counterexamples generated by formal verification. The difference is that the first counterexample was obtained by formal verification after writing the assertion in reverse, while the second counterexample is obtained by formal verification because the design itself has a defect, and the assertion is correct.

[0124] In the embodiments of this application, one or a combination of logic simulation and formal simulation may be selected according to various scenarios.

[0125] For example, suitable scenarios for formal verification include: logic units that cannot fully traverse input combinations, control logic-intensive designs (such as arbitrators and interrupt controllers), glue logic in data paths (glue logic refers to relatively simple combinational or sequential logic in data paths used to connect large functional modules and adapt their interfaces), modules requiring high security guarantees (such as state machines in encryption algorithms), and providing proofs for "dead zone" code that is difficult to cover in logic simulation (such as complex if-else or case branches).

[0126] Suitable scenarios for logic simulation verification include: designs with complex data paths and calculations, scenarios requiring verification in conjunction with software, integration verification involving analog circuits or third-party IP, performance verification, and power consumption verification.

[0127] Therefore, in the embodiments of this application, when performing chip design verification, it is not limited to using two verification methods simultaneously to verify the same functional module. Instead, a more suitable verification method can be selected based on the scenario. Furthermore, when cross-verification is required, another verification method can be used for cross-verification. Cross-verification can occur at any stage of chip design.

[0128] Based on the same inventive concept, this application also provides a chip design verification system. Please refer to [link to relevant documentation].Figure 3 , Figure 3 This is a schematic diagram of a chip design verification system provided in an embodiment of this application. The chip design verification system 300 includes: an input module 310, a decision module 320, and a verification module 330.

[0129] Input module 310 is used to obtain the chip's design file and the corresponding design stage.

[0130] The decision module 320 is used to select a target collaborative verification method that matches the design stage from multiple collaborative verification methods; wherein, the collaborative verification method includes a method of verifying the design document in collaboration between logic simulation verification and formal verification; different collaborative verification methods correspond to different design stages, and the collaboration method between logic simulation verification and formal verification is different in different collaborative verification methods.

[0131] Verification module 330 is used to verify the design document based on the target collaborative verification method. This verification module can connect to existing formal verification and logic simulation verification tools, as well as access the logic simulation test platform corresponding to the chip design, to invoke these tools to verify the design document based on the target collaborative verification method.

[0132] In one embodiment, the design phase includes a first phase, which is the phase before the simulation test platform is fully constructed. The target collaborative verification method corresponding to the first phase is a first collaborative verification method. Verification module 330 can be used to verify the design document based on the first collaborative verification method, including: obtaining a first assertion for a preset functional module in the design document; the design document includes different functional modules, and the first assertion is used to describe the attributes of the preset functional module; performing formal verification on the preset functional module based on the first assertion; and, after the simulation test platform is fully constructed and supports logical simulation verification, performing logical simulation verification on the preset functional module based on the first assertion.

[0133] In one embodiment, the design phase includes a second phase, where the design document includes the complete functionality of the chip and supports logic simulation verification; the target collaborative verification method corresponding to the second phase is a second collaborative verification method. Verification module 330 can be used to verify the design document based on the second collaborative verification method, including: performing logic simulation verification on the design document to obtain vulnerability information determined by the logic simulation verification; configuring a first attribute to be verified based on the vulnerability information; and performing formal verification on the first attribute to be verified.

[0134] The design phase includes a third phase, which is a coverage detection phase for the design document. This coverage detection includes simulation coverage detection after logic simulation verification and formal coverage detection after formal verification. The target collaborative verification method corresponding to this third phase is the third collaborative verification method. Verification module 330 can be used to verify the design document based on the third collaborative verification method, including: performing the simulation coverage detection on the design document to obtain simulation coverage detection results, the simulation coverage detection results including uncovered functions; configuring corresponding second verification attributes for the uncovered functions; performing formal verification on the uncovered functions based on the second verification attributes; performing formal coverage detection on the uncovered functions after formal verification to obtain formal coverage detection results; determining the coverability of the uncovered functions based on the simulation coverage detection results and the formal coverage detection results; and adjusting the execution of the next logic simulation verification based on the coverability.

[0135] The verification module 330 is further configured to determine, before configuring the corresponding second attribute to be verified for the uncovered function, that the rate of change of the simulation coverage is lower than a preset threshold, wherein the rate of change of the simulation coverage is determined based on multiple historical simulation coverages obtained from multiple historical simulation coverage detections.

[0136] The verification module 330 adjusts the execution of the next logic simulation verification based on the coverage, including: when the coverage characterizes that the uncovered function is coverable, obtaining test counterexamples of the uncovered function generated by formal verification; generating targeted test cases based on the test counterexamples, so that the next logic simulation verification performs targeted testing on the uncovered function based on the targeted test cases.

[0137] The verification module 330 adjusts the execution of the next logic simulation verification based on the coverage, including: when the coverage indicates that the uncovered function is not coverable, after excluding the uncovered function from the simulation coverage detection, performing the next logic simulation verification and simulation coverage detection on the design file.

[0138] The verification module 330 can perform simulation coverage detection on the design file and configure random test cases based on the simulation coverage detection results; the logic simulation verification includes random testing of the design file based on random test cases; and random testing of the design file for the next logic simulation verification based on the random test cases.

[0139] After performing random testing on the design file for the next logic simulation verification based on the random test cases, the verification module 330 can also determine whether the random test results meet the preset constraint over-strength condition; if it is determined that the random test results meet the preset constraint over-strength condition, the random test cases are adjusted based on the simulation coverage detection results and the random test results; and the design file is randomly tested based on the adjusted random test cases.

[0140] The verification module 330 is further configured to: obtain the current formal verification result of the formal verification after any formal verification of the design document; if the current formal verification result determines that there is a state space explosion, divide the functional modules in the design document to obtain multiple functional modules to be verified; perform formal verification on each of the functional modules to be verified to obtain their respective sub-formal verification results; and determine a new formal verification result based on the formal verification sub-results of each of the functional modules to be verified.

[0141] The verification module 330 is further configured to detect target design elements that cause the state space to explode; for each target design element, based on the context of the target design element in the design file, the complete function of the target design element is determined, and the target design element with complete function represents a functional module to be verified; the formal verification of each functional module to be verified to obtain sub-formal verification results includes: constructing equivalent models corresponding to each target design element with complete function; performing formal verification on each equivalent model to obtain sub-formal verification results corresponding to each functional module to be verified; and mapping the sub-formal verification results back to the current formal verification result to obtain the new formal verification result.

[0142] The verification module 330 is further configured to obtain the current formal verification result after any formal verification of the design document; and to perform logical simulation verification on the current constraints and attributes used in the formal verification if the current formal verification result determines that there is a state space explosion, wherein the current constraints and data are the custom constraints and attributes used in the formal verification.

[0143] The verification module 330 is further configured to obtain the current logic simulation verification result after any logic simulation verification of the design file; generate a second assertion based on the signal relationship in the current logic simulation verification result; and perform formal verification of the design file based on the second assertion.

[0144] The verification module 330 is further configured to, after any formal verification of the design document, obtain a second counterexample obtained through formal verification; generate test cases based on the second counterexample; and perform logical simulation verification on the design document based on the test cases.

[0145] Based on the same inventive concept, embodiments of this application also provide an electronic device, which includes a memory and a processor. The memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor performs the chip design verification method as provided in any of the foregoing embodiments.

[0146] In the embodiments of this application, electronic devices include, but are not limited to, computers, server machines, test machines, etc.

[0147] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when run on a computer, causes the computer to perform the methods provided in the above embodiments.

[0148] The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs (digital video discs)), or semiconductor media (e.g., SSDs (Solid State Disks)).

[0149] If the method is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, external hard drives, ROM, RAM, magnetic disks, or optical disks.

[0150] In the embodiments provided in this application, it should be understood that the disclosed methods and apparatus can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. The functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0151] The above embodiments can be freely combined without conflict, and the resulting embodiments are covered within the protection scope of this application.

[0152] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0153] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A chip design verification method, characterized in that, include: Obtain the chip's design documents and the corresponding design stage; Select a target collaborative verification method that matches the design stage from multiple collaborative verification methods; wherein, the collaborative verification method includes a method of verifying the design document in collaboration between logic simulation verification and formal verification; different collaborative verification methods correspond to different design stages, and the collaboration between logic simulation verification and formal verification is different in different collaborative verification methods; The design document is validated based on the aforementioned collaborative validation method. The logic simulation verification is a verification method based on a simulation test platform to verify the design file; the design stage includes at least one of a first stage, a second stage, and a third stage; The first stage is the stage in which the simulation test platform has not been fully constructed; The second stage is when the design documents include the complete functionality of the chip and support logic simulation verification; The third stage is the stage of performing coverage testing on the design documents, wherein the coverage testing includes simulation coverage testing performed on the design documents after logic simulation verification and formal coverage testing performed after formal verification. The target collaborative verification method corresponding to the first stage is the first collaborative verification method; when the target collaborative verification method is determined to be the first collaborative verification method, the verification of the design document based on the target collaborative verification method includes: obtaining a first assertion for a preset functional module in the design document; the design document includes different functional modules, and the first assertion is used to describe the attributes of the preset functional module; performing formal verification on the preset functional module based on the first assertion; and, after the simulation test platform is built and supports logic simulation verification, performing logic simulation verification on the preset functional module based on the first assertion. The target collaborative verification method corresponding to the second stage is the second collaborative verification method; when the target collaborative verification method is determined to be the second collaborative verification method, the verification of the design document based on the target collaborative verification method includes: performing logic simulation verification on the design document to obtain vulnerability information determined by the logic simulation verification; configuring a first attribute to be verified based on the vulnerability information; and performing formal verification on the first attribute to be verified. The target collaborative verification method corresponding to the third stage is the third collaborative verification method. When the target collaborative verification method is determined to be the third collaborative verification method, the verification of the design document based on the target collaborative verification method includes: performing simulation coverage detection on the design document to obtain simulation coverage detection results, the simulation coverage detection results including uncovered functions; configuring corresponding second verification attributes for the uncovered functions; performing formal verification on the uncovered functions based on the second verification attributes; performing formal coverage detection on the uncovered functions after formal verification to obtain formal coverage detection results; determining the coverability of the uncovered functions based on the simulation coverage detection results and the formal coverage detection results; and adjusting the execution of the next logic simulation verification based on the coverability.

2. The chip design verification method according to claim 1, characterized in that, Before configuring the corresponding second attribute to be verified for the uncovered functionality, the method further includes: The rate of change of simulation coverage is determined to be lower than a preset threshold, wherein the rate of change of simulation coverage is determined based on multiple historical simulation coverage values ​​obtained from multiple historical simulation coverage detections.

3. The chip design verification method according to claim 1, characterized in that, The logic simulation verification includes targeted testing that verifies the design documents based on targeted test cases; The adjustment of the execution of the next logic simulation verification based on the coverage includes: If the coverability characterizes that the uncovered function is coverable, the assertion of the uncovered function is modified to the opposite assertion; Formal verification of the uncovered functionality is performed based on the contrary assertion. If the formal verification fails, obtain the first counterexample generated after performing formal verification on the uncovered function based on the opposite assertion; Based on the first counterexample, targeted test cases are generated so that the next logic simulation verification can perform targeted testing on the uncovered functions based on the targeted test cases.

4. The chip design verification method according to claim 1, characterized in that, The adjustment of the execution of the next logic simulation verification based on the coverage includes: If the uncovered function is not covered as indicated by the coverage characteristic, the uncovered function is excluded from the simulation coverage test, and then the design file is subjected to the next logic simulation verification and simulation coverage test.

5. The chip design verification method according to claim 1, characterized in that, After performing simulation coverage testing on the design file, the method further includes: Random test cases are configured based on the simulation coverage detection results; the logic simulation verification includes random testing of the design documents based on the random test cases. The design document is subjected to random testing for the next logic simulation verification based on the random test cases.

6. The chip design verification method according to claim 5, characterized in that, After performing random testing on the design document for the next logic simulation verification based on the random test cases, the method further includes: Determine whether the random test result of the random test meets the preset constraint overly strong condition; If it is determined that the random test results meet the preset constraint overly strong condition, the random test cases are adjusted based on the simulation coverage detection results and the random test results. The design document is randomly tested based on the adjusted random test cases.

7. The chip design verification method according to any one of claims 1-6, characterized in that, The method further includes: After any formal verification of the design document, obtain the current formal verification result. If the current form verification results confirm the existence of state space explosion, the functional modules in the design file are divided to obtain multiple functional modules to be verified. Each of the functional modules to be verified is formally verified to obtain its corresponding sub-formal verification results. New formal verification results are determined based on the formal verification sub-results of each of the aforementioned functional modules to be verified.

8. The chip design verification method according to claim 7, characterized in that, The division of the functional modules in the design file includes: Detect the target design element that causes the state space to explode; For each target design element, the complete functionality of the target design element is determined based on its context in the design document. The target design element with complete functionality represents a functional module to be verified. The step of performing formal verification on each of the functional modules to be verified to obtain sub-formal verification results includes: constructing equivalent models corresponding to the target design elements of each complete function; performing formal verification on each equivalent model to obtain sub-formal verification results corresponding to each of the functional modules to be verified. The process of determining a new formal verification result based on the formal verification sub-results of each of the aforementioned functional modules to be verified includes: The sub-formal verification result is mapped back to the current formal verification result to obtain the new formal verification result.

9. The chip design verification method according to any one of claims 1-6, characterized in that, The method further includes: After any formal verification of the design document, obtain the current formal verification result of that formal verification. If the current formal verification result confirms the existence of state space explosion, a logic simulation verification is performed on the current constraints and attributes used in this formal verification. The current constraints and data are the custom constraints and attributes used in this formal verification.

10. The chip design verification method according to any one of claims 1-6, characterized in that, The method further includes: After any logic simulation verification of the design file, obtain the current logic simulation verification result for that logic simulation verification. A second assertion is generated based on the signal relationships in the current logic simulation verification results; The design document is formally validated based on the second assertion.

11. The chip design verification method according to any one of claims 1-6, characterized in that, The method further includes: After any formal verification of the design document, obtain a second counterexample that passes the formal verification; Test cases are generated based on the second counterexample; The design document is logically simulated and verified based on the test cases.

12. A chip design verification system, characterized in that, include: The input module is used to obtain the chip's design file and the corresponding design stage. The decision module is used to select a target collaborative verification method that matches the design stage from multiple collaborative verification methods; wherein, the collaborative verification method includes a method of verifying the design document in collaboration between logic simulation verification and formal verification; different collaborative verification methods correspond to different design stages, and the collaboration method between logic simulation verification and formal verification is different in different collaborative verification methods; The verification module is used to verify the design document based on the target collaborative verification method; The logic simulation verification is a verification method based on a simulation test platform to verify the design file; the design stage includes at least one of a first stage, a second stage, and a third stage; The first stage is the stage in which the simulation test platform has not been fully constructed; The second stage is when the design documents include the complete functionality of the chip and support logic simulation verification; The third stage is the stage of performing coverage testing on the design documents, wherein the coverage testing includes simulation coverage testing performed on the design documents after logic simulation verification and formal coverage testing performed after formal verification. The target collaborative verification method corresponding to the first stage is the first collaborative verification method; when the target collaborative verification method is determined to be the first collaborative verification method, the verification module is used to: obtain a first assertion on a preset functional module in the design file; the design file includes different functional modules, and the first assertion is used to describe the attributes of the preset functional module; perform formal verification on the preset functional module based on the first assertion; and, after the simulation test platform is built and supports logic simulation verification, perform logic simulation verification on the preset functional module based on the first assertion; The target collaborative verification method corresponding to the second stage is the second collaborative verification method; when the target collaborative verification method is determined to be the second collaborative verification method, the verification module is used to: perform logical simulation verification on the design document to obtain vulnerability information determined by the logical simulation verification; configure a first attribute to be verified based on the vulnerability information; and perform formal verification on the first attribute to be verified. The target collaborative verification method corresponding to the third stage is the third collaborative verification method. When the target collaborative verification method is determined to be the third collaborative verification method, the verification module is used to: perform simulation coverage detection on the design file to obtain simulation coverage detection results, the simulation coverage detection results including uncovered functions; configure corresponding second attributes to be verified for the uncovered functions; perform formal verification on the uncovered functions based on the second attributes to be verified; perform formal coverage detection on the uncovered functions after formal verification to obtain formal coverage detection results; determine the coverability of the uncovered functions based on the simulation coverage detection results and the formal coverage detection results; and adjust the execution of the next logic simulation verification based on the coverability.

13. An electronic device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the chip design verification method as described in any one of claims 1-11.

14. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the chip design verification method as described in any one of claims 1-11.

Images