English
EDA needs functional qualification
Mark Hampton, Certess, Inc.
EE Times (10/07/2008 8:47 AM EDT)
Verification is a very expensive activity in integrated circuit (IC) development. It is also a difficult activity to complete efficiently. Coverage-driven verification (CDV) has been widely adopted in the industry, but is also widely accepted as being an incomplete measurement of verification.
To find a design bug, three things must occur during the execution of the verification environment:
The verification environment must exercise a path through the design (from inputs to checkers) and these temporal inter-process relationships are not present in code coverage information. It is quite possible that code will be covered only as an unintended side effect of a test case. Code coverage can indicate that code has been exercised during simulation, but this does not tell the user if a bug in the same code would propagate to a checker and cause a test case to fail. Furthermore, code coverage does not indicate if the output behavior is being checked correctly.
EE Times (10/07/2008 8:47 AM EDT)
Verification is a very expensive activity in integrated circuit (IC) development. It is also a difficult activity to complete efficiently. Coverage-driven verification (CDV) has been widely adopted in the industry, but is also widely accepted as being an incomplete measurement of verification.
To find a design bug, three things must occur during the execution of the verification environment:
- The bug must be activated, i.e., the code containing the bug must be exercised.
- The bug must be propagated to an observable point, e.g., the outputs of the design.
- The bug must be detected, i.e., behavior checked and a failure indicated.
The verification environment must exercise a path through the design (from inputs to checkers) and these temporal inter-process relationships are not present in code coverage information. It is quite possible that code will be covered only as an unintended side effect of a test case. Code coverage can indicate that code has been exercised during simulation, but this does not tell the user if a bug in the same code would propagate to a checker and cause a test case to fail. Furthermore, code coverage does not indicate if the output behavior is being checked correctly.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Related Articles
- Functional qualification: a technical brief
- Functional Qualification - An Automated and Objective Measure of Functional Verification Quality
- Discover new Tessent UltraSight-V from Siemens EDA, and accelerate your RISC-V development.
- Revolutionizing Chip Design with AI-Driven EDA
- AI-driven SRAM demand needs integrated repair and security
New Articles
- Discover new Tessent UltraSight-V from Siemens EDA, and accelerate your RISC-V development.
- The Critical Factors of a High-performance Audio Codec - What Chip Designers Need to Know
- Density Management in Analog Layout Design: Addressing Issues and Ensuring Consistency
- Nexus: A Lightweight and Scalable Multi-Agent Framework for Complex Tasks Automation
- How the Ability to Manage Register Specifications Helps You Create More Competitive Products
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Synthesis Methodology & Netlist Qualification
- Discover new Tessent UltraSight-V from Siemens EDA, and accelerate your RISC-V development.
- Understanding Logic Equivalence Check (LEC) Flow and Its Challenges and Proposed Solution