Design For VerificationSynopsys Inc, April 2003
Agenda Overview The Bottleneck- Today’s Verifications Why do chips crash? What is DFV? Assertion-Based-Verification Multi-Level Interface Design Dynamic Verification flow Formal Analysis Flow Verification Intellectual Property United design and verification
language
Overview Notation- DFV Design & verification technologies
A great promise Lack of efficient methodology
DFV methodology- Covering multiple levels of abstraction Combining simulation and formal analysis Unified language- consistent specification,
design, and verification descriptions Intellectual property to accelerate the
design and verification of today’s chips
Many different verification technologies
New languages (Vera & e) C/C++ based Random stimulus-generation Transaction-level modeling Coverage metrics Formal analysis Temporal assertions
But still first-pass silicon successes are fewer from year to year
The Bottleneck- Today’s Verifications
The (bad) Numbers
first-pass silicon successes: On 2000 – 50% On 2002 – 39%
Re-spin costs: 100000$ Months of additional development
time Benefits of first-pass:
Money Market time
Why do chips crash?
Why do chips crash? Physical effects Mixed-signal issues Power issues logic/functional flaws– more than
60% “Band–Aid” approach does not help Does not keep up with Moor’s law Bad focal
We must have a new comprehensive verification methodology
logic/functional flaws What types of logic/functional flaws
make it all the way to tapeout? Re-used modules and imported IP – 14% Specification error – 47% Design errors – 82%
Complicated modules - multiple-state machines
assumptions on the interface
We must improve specification, design, and verification in a concerted manner
The DFV Methodology
Finding design errors through: Constrained-random stimulus
generation Advanced tools for formal state-
space analysis Eliminate ambiguity in
specifications Improved conformance checking
capabilities
DFV for SoC Leverage a designer’s intent and
knowledge to strengthen the verification effort
Supports multiple levels of abstraction
Maximize correctness of functionality of individual modules
Ensure the correctness of integration of these modules
DFV Scope Diagram
Functional/transaction-level (TL) Synthesizable RTL Gate and transistor-level
Requirements
Creating Design artifacts on all three levels
Maintaining Relationships between levels
Propagating assumptions
Examples: Assumption transferring from TL to RTL Assumption between two RTL blocks
and their communication protocols
Use of design assertions Dynamic checking during simulations- immediate
notification of violations Proving certain properties in RTL given a set of
interface constraints Describing environment constraints for automatic
stimulus generation Creating coverage metrics that are directly linked
back to the specification
Use of multi-level interface design Consistency between TL,
specification/assumptions and RT-level implementations
Integration on TL, RTL and gate-level models
DFV cornerstones
Assertion-Based-Verification
Assertions enables DFV simulation, coverage, advanced constrained-random test generation, and formal analysis
Assertions in DFV Continuously checked during
simulation Analyzed jointly with the RTL Expressing designer’s assumptions continuously monitored We can have hundreds of them- (we
must have an automated tool). assertions embedded in the RTL carry
forward to the full-chip RTL verification
Aspects for successful assertions Native execution of assertions by the
simulation engine (many assertions) Synthesizability of assertions Debug of assertions Assertions mapping
Assertions summary: simulation and formal analysis tools
dramatically increase the verification effectiveness
support project management by enabling extensive coverage metrics for these specifications
Multi-Level Interface DesignMost of the bugs are hidden between blocks In traditional HDL:
We can check interface only when all blocks are connected (“top”)
Checking correctness and connectivity together on the entire subsystem
DFV: Defines the interface as a standalone
component The protocol can be checked separately Guarantees that blocks that use the
interface are connected correctly
Improve Divide and conquer flaw results
Block-level: complete testing of all detailed functionality
Top-level: testing the functionality of the overall system No need to check the wiring
between blocks, because the interconnect is now correct by construction
Assertions role Encapsulates the protocol
definitions Any block that connects to the
interface will automatically be checked for protocol compliance
The same assertions can be used also for simulation and for formal analysis
Can monitor qualities about the transactions, such as cycle latency, address/data relationships etc
Smooth moving from TL to RTL The transaction-level behaviors
remain consistent with the more detailed behaviors of the RTL
Multi-Level Interface summary More complicated chips Verification of chip infrastructure
is essential portion of chip-level. A set of interfaces that can be
verified represents this infrastructure
the complexities of chip-level verification decreases dramatically
Formal analysis flow
Interface constrains define a set of behaviors
The effectiveness is determined by: Completeness and correctness of
the interface constraints Formal engines underneath the
analysis Capacity and performance
Formal Analysis Flow The balance moving from simulation-
dominated flow to a specification and analysis-based flow
specification driven- doesn’t rely on testbenches, increasing productivity
Can be the key to break the verification barrier of tomorrow’s SoCs
Going from “design first, then verify” into the “specify first, then design and verify”
Verification Intellectual Property Designers must support standard
protocol – (USB, PCI) Using verification IP
Standard Common language Supporting simulation tools Effective stimulus environment Increasing productivity
United design and verification language
Schematic to synthesis gap- solved by HDLs
Verification productivity gap- can be solved in same way
HDLs allowed the specification of both stimulus and design in the same language
System Verilog
Supports design, testbench Includes the syntax and
semantics to support assertions Supports multi-level interface
design Unifies design and verification as
a foundation for the DFV methodology
Enables random-data generation Describe more complex
synthesizabledesigns
data structures enumerated types multi-dimensional arrays
Object-oriented features for testbench
DFV Summary
A solution comprising methodology, language, and technology to systematically prevent bugs from entering the design flow
Specify constraints, assumptions and properties unambiguously
multi-level interface design smooth flow from transaction-
level down to RTL
Single language System Verilog has the right
ingredients to support this flow System Verilog describe more
complex designs and design assertions, both at the transaction-level and in RTL
The motivation behind the DFV methodology: enabling design teams to create increasingly complex chips in less time, with first-pass silicon success
Top Related