Chip-Coordinate Error Persistence for IC Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The iterative process of resolving design rule violations in complex integrated circuit designs is inefficient due to the lack of persistence and sharing of error information among different design teams, leading to repetitive error triage and suboptimal design verification.
Innovation Solution
A verification tool that persists user-generated error information between verification checking runs by associating errors with chip coordinates, allowing for the annotation and sharing of error information across iterations, thereby reducing repetitive error triage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If error information is not persisted between verification runs, then each verification run starts fresh without historical context, but design teams must repeatedly analyze and triage the same errors, wasting time and reducing productivity
Solution Approach 1:
The system performs preliminary action by persisting error information from previous verification runs and making it available before subsequent verification runs begin. This allows design teams to review historical error data, annotations, and resolution status ahead of time, reducing the need for repetitive error analysis in each new verification run.
Solution Approach 2:
The system creates and maintains copies of error information across multiple verification runs. Instead of losing error data when each verification run completes, the system copies and preserves error entries, their annotations, and associated metadata so that this information can be reused in subsequent verification activities without re-analysis.
2Adaptability or versatility
If error information is shared among design teams, then collaboration and knowledge sharing improve, but the system complexity increases due to needing to manage and synchronize error data across multiple users and iterations
Solution Approach 1:
The verification tool is designed with multi-functionality to handle both verification checking and error information persistence/sharing within a single integrated system. This universal approach allows the same tool to perform verification, store error data, manage annotations, and facilitate sharing among design teams, reducing the need for separate systems and lowering overall complexity.
Solution Approach 2:
The system introduces an intermediary error information storage mechanism that mediates between multiple verification runs and design teams. This intermediary layer manages the persistence, retrieval, and sharing of error data, shielding users from the underlying complexity of data synchronization and management while enabling seamless collaboration.
3Reliability
If manual error annotation is required for each verification run, then users can provide detailed error context, but the repetitive nature of re-annotating errors across iterations reduces efficiency and increases labor requirements
Solution Approach 1:
The system enables self-service by automatically preserving error annotations from previous verification runs and making them available in subsequent runs. Design teams can review existing annotations and update them as needed without having to create annotations from scratch each time, allowing the system to serve itself by maintaining and reusing its own error information.
Solution Approach 2:
The system ensures continuity of useful action by maintaining error annotations across verification runs rather than allowing them to be lost or reset. This continuous preservation of annotation data allows the valuable work of analyzing and documenting errors to accumulate and build upon itself over time, rather than requiring repetitive re-annotation.
Data Source
AI summary
A technique of verification for an integrated circuit design under test includes performing a first verification checking run on an integrated circuit design under test (IC DUT) and generating an error report including an error entry for an error detected in the first verification checking run. The error entry associates the error with chip coordinates within the IC DUT. Based on a user input, the error entry of the error report is annotated with user-generated error information. Following an update to the IC DUT, a second verification checking run on the IC DUT is thereafter performed. Following the second verification checking run, the error report is presented, with the user-generated error information persisted between verification checking runs based on the chip coordinates and/or the chip layer of the error.