Design For Verification

1. Design For Verification Synopsys Inc, April 2003

2. 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

3. 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

4. The Bottleneck- Today’s Verifications • 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

5. 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

6. Why do chips crash?

7. 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

8. 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

9. 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

10. 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

11. DFV Scope Diagram • Functional/transaction-level (TL) • Synthesizable RTL • Gate and transistor-level

12. 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

13. DFV cornerstones • 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

14. Assertion-Based-Verification • Assertions enables DFV simulation, coverage, advanced constrained-random test generation, and formal analysis

15. 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

16. 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

17. 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

18. 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

19. 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

20. Smooth moving from TL to RTL • The transaction-level behaviors remain consistent with the more detailed behaviors of the RTL

21. 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

22. 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

23. 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”

24. Verification Intellectual Property • Designers must support standard protocol – (USB, PCI) • Using verification IP • Standard • Common language • Supporting simulation tools • Effective stimulus environment • Increasing productivity

25. 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

26. 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

27. Enables random-data generation • Describe more complex synthesizable designs • data structures • enumerated types • multi-dimensional arrays • Object-oriented features for testbench

28. 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

29. 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

30. The motivation behind the DFV methodology: enabling design teams to create increasingly complex chips in less time, with first-pass silicon success