Design For Verification Synopsys 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: $ Months of additional development time Benefits of first-pass: Money Market time

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 Design Most 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 synthesizable designs 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