Runtime Information for Formal Verification Quality Metrics
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current formal verification techniques lack the ability to measure the quality of verification, leading to uncertainties in ensuring complete design coverage and potential bugs due to over-constraining or insufficient assertions, with no quantitative metrics available to assess progress or sign-off confidence.
Innovation Solution
The use of runtime information from formal verification engines to identify verification holes and compute metrics by determining which registers, inputs, and constraints were used during proof, allowing for the identification of missing or unnecessary assertions and constraints, and providing visual indicators for progress tracking.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If formal verification is performed without coverage metrics, then verification completeness cannot be measured, but computational resources are wasted on exhaustive checking of already-verified aspects
Solution Approach 1:
The patent implements feedback mechanisms by collecting runtime information from the formal verification engine about which design elements were actually examined during proof attempts. This feedback is then processed to generate coverage metrics that indicate what portions of the design have been verified and what remains unverified, enabling continuous improvement of verification completeness without redundant checking.
Solution Approach 2:
The patent replaces traditional simulation-based coverage measurement mechanisms with a formal verification-specific approach. Instead of using test vectors and simulation runs, the system directly extracts runtime information from the formal verification engine's proof processes, substituting the mechanical simulation approach with a mathematically rigorous information extraction method tailored to formal verification.
2Measurement precision
If design mutations are introduced to generate coverage metrics, then verification coverage can be measured, but computational cost increases significantly
Solution Approach 1:
The patent performs preliminary action by collecting runtime information during the normal formal verification proof process itself, before any additional coverage analysis is performed. The system captures which registers, inputs, and constraints were used during the proof attempts, and then uses this pre-collected information to generate coverage metrics without requiring separate mutation-based verification runs.
Solution Approach 2:
The patent extracts coverage information directly from the runtime data produced during formal verification proofs. Instead of introducing design mutations to generate coverage metrics, the system takes out and analyzes the existing runtime information about which design elements were examined during the proof process, separating coverage measurement from the verification proof generation.
3Reliability
If exhaustive simulation is performed to verify IC design, then complete coverage can be achieved, but computational feasibility is lost
Solution Approach 1:
The patent introduces coverage metrics as an intermediary between formal verification and design validation. These metrics provide a quantitative measure of verification completeness that does not require exhaustive simulation, serving as a mediator that bridges the gap between the mathematical rigor of formal verification and the need for practical verification assurance in complex IC designs.
Data Source
AI summary
Systems and techniques are described for using runtime information to identify a verification hole and/or compute a verification metric. Runtime information (RI) for a set of proven assertions can be determined, wherein the RI includes a first set of registers, a first set of inputs, and a first set of constraints that were used by a formal verification engine during runtime to prove one or more assertions for a design under verification (DUV). Next, a second set of registers, a second set of inputs, and a second set of constraints that are not present in the RI can be determined. The second set of registers, the second set of inputs, and/or the second set of constraints can then be used to (1) identify a verification hole and/or (2) compute a verification metric.