English
Design with Verification: Not an Oxymoron
By Thomas L. Anderson, Cadence Design Systems, Inc.
November 05, 2007 -- edadesignline.com
Logic Designers and Verification
Corporate efficiency consultants love to talk about "the dead moose on the table"—the important topic that everyone knows about but no one wants to bring up. In system-on-chip (SoC) verification, there is just such a dead moose: logic designer involvement in verification. All the clichs about designers not wanting to do verification and verification engineers not trusting them to verify don't matter anymore. While a dedicated verification team is essential at the cluster (multi-block) and chip levels, effective, efficient verification of large, complex chips must also involve the designers.
The most compelling reason for this is simply that bugs must be found as early in the development process as possible, when diagnosing and fixing them is fast and inexpensive. Recognizing this, many projects are placing quality requirements on the designers mandating that fewer bugs escape to be found by the verification team. Bugs resolved at the block level involve only the logic designer, minimizing engineering resources and preventing iterations through multiple team members.
In contrast, feeding a bug found in cluster-level simulation back to designers for debug and resolution can take days, stretching into weeks for problems found in chip-level or system-level simulation, acceleration, and emulation. Inevitably, this process takes a lot of time for the designers as well as the verification engineers. Chip-level and system-level verification should be used to find high-level issues, especially those related to hardware-software interaction, not basic RTL bugs.
November 05, 2007 -- edadesignline.com
Logic Designers and Verification
Corporate efficiency consultants love to talk about "the dead moose on the table"—the important topic that everyone knows about but no one wants to bring up. In system-on-chip (SoC) verification, there is just such a dead moose: logic designer involvement in verification. All the clichs about designers not wanting to do verification and verification engineers not trusting them to verify don't matter anymore. While a dedicated verification team is essential at the cluster (multi-block) and chip levels, effective, efficient verification of large, complex chips must also involve the designers.
The most compelling reason for this is simply that bugs must be found as early in the development process as possible, when diagnosing and fixing them is fast and inexpensive. Recognizing this, many projects are placing quality requirements on the designers mandating that fewer bugs escape to be found by the verification team. Bugs resolved at the block level involve only the logic designer, minimizing engineering resources and preventing iterations through multiple team members.
In contrast, feeding a bug found in cluster-level simulation back to designers for debug and resolution can take days, stretching into weeks for problems found in chip-level or system-level simulation, acceleration, and emulation. Inevitably, this process takes a lot of time for the designers as well as the verification engineers. Chip-level and system-level verification should be used to find high-level issues, especially those related to hardware-software interaction, not basic RTL bugs.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Cadence Design Systems, Inc. Hot IP
Related Articles
- When Traceability Catches What Verification Does Not
- It's Not My Fault! How to Run a Better Fault Campaign Using Formal
- Learning Not to Fear PCI Express Compliance Using a Predictable, Metrics Based Verification Closure Methodology
- Certifying RISC-V: Industry Moves to Achieve RISC-V Core Quality
- Why verification matters in network-on-chip (NoC) design
New Articles
Most Popular
- Streamlining SoC Design with IDS-Integrate™
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- PCIe error logging and handling on a typical SoC