RaceCheck Logic Analyzer for IC Design Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current HDL design verification tools are unable to effectively detect race logic errors in integrated circuit designs, leading to unpredictable behavior in IC chips due to their inability to handle concurrent operations and timing dependencies, resulting in false test coverage confidence and costly manufacturing and field operation issues.
Innovation Solution
The RaceCheck program, utilizing both static and dynamic race logic analysis, identifies and reports race logic errors by modeling IC designs as directed graphs, simulating event-driven logic, and employing ATPG and BDD methods to filter out false violations, ensuring comprehensive and accurate detection of concurrent assignment, reference, and invocation races.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If HDL design verification tools execute concurrent operations in tool-specific predetermined orders or ignore timing dependencies, then verification speed is improved, but race logic errors are missed leading to false test coverage confidence
Solution Approach 1:
The system performs preliminary identification of side-effecting HDL constructs and their triggering conditions before execution, building a dependency map that predicts potential race conditions. This preliminary analysis enables the system to set up monitoring points and evaluation criteria in advance, allowing fast execution while maintaining detection accuracy.
Solution Approach 2:
The system introduces an intermediary analysis layer between the HDL verification tools and the design under test. This intermediary component translates concurrent operations into an ordered sequence for evaluation, mediates timing dependencies, and reconciles differences between tool-specific execution orders, enabling both speed and accuracy.
2Adaptability or versatility
If HDL verification tools evaluate IC chip circuit operations in different orders, then tool versatility is improved, but consistent race logic detection cannot be achieved
Solution Approach 1:
Instead of adapting the detection methodology to match different tool execution orders, the system inverts the approach by imposing a canonical evaluation order on the HDL constructs. It translates concurrent operations into a standardized sequence based on triggering conditions and side effects, ensuring consistent race logic detection across all tool vendors while maintaining adaptability to different HDL syntaxes.
3Reliability
If static and dynamic race logic analysis is performed on all HDL constructs, then detection completeness is improved, but verification time and computational resources increase
Solution Approach 1:
The system applies different analysis depths to different HDL constructs based on their potential to cause race conditions. It identifies side-effecting constructs (like $display, $random, task invocations) as high-risk and applies comprehensive static and dynamic analysis only to these, while using lighter analysis for routine operations. This localized quality approach ensures detection completeness for critical areas without uniformly increasing verification time across all constructs.
Solution Approach 2:
The system performs partial analysis by focusing computational resources on identifying and analyzing only those HDL constructs that have side effects and triggering conditions that could lead to race logic. Rather than exhaustive analysis of all constructs, it applies analysis selectively to the subset of constructs that matter, achieving sufficient detection completeness with reduced time and resource overhead.
Data Source
AI summary
Techniques a race logic analysis on an integrated circuit (IC) design are described herein. In one embodiment, all hardware description language (HDL) defined system functions and/or tasks that have one or more side-effects when invoked in a first HDL language, but not when the same HDL-defined system functions/tasks are invoked in a second HDL language are identified. For all processing blocks that invoke the HDL-defined system functions/tasks that have side-effects, one or more triggering conditions of the processing blocks and HDL languages in which the processing blocks are coded are collected. When detecting a concurrent invocation race of the HDL-defined system functions/tasks statically or dynamically, checking is performed only the processing blocks that are coded in one or more HDL languages which render the HDL-defined system functions/tasks to manifest the one or more side-effects. Other methods and apparatuses are also described.