Presentation is loading. Please wait.

Presentation is loading. Please wait.

ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 1 ASPDAC/VLSI 2002 Tutorial Functional Verification of System on Chip - Practices, Issues.

Similar presentations


Presentation on theme: "ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 1 ASPDAC/VLSI 2002 Tutorial Functional Verification of System on Chip - Practices, Issues."— Presentation transcript:

1 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 1 ASPDAC/VLSI 2002 Tutorial Functional Verification of System on Chip - Practices, Issues and Challenges

2 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 2 Presenters: Subir K. Roy (Co-ordinator), Synplicity Inc., 935 Stewart Drive, Sunnyvale CA 94085, USA Tel. : 408-215-6049 Fax. : 408-990-0296 Email: subir@synplicity.com

3 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 3 Presenters: S.Ramesh Dept. of Computer Sc. & Engg., IIT-Bombay, Powai, Mumbai 400 076 Tel. : +91-22-576-7722 Fax. : +91-22-572-0290 Email: ramesh@cse.iitb.ac.in

4 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 4 Presenters: Supratik Chakraborty, Dept. of Computer Sc. & Engg., IIT-Bombay, Powai, Mumbai 400 076 Tel. : +91-22-576-7721 Fax. : +91-22-572-0290 Email: supratik@cse.iitb.ac.in

5 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 5 Presenters: Tsuneo Nakata, Fujitsu Laboratories Limited, 1-1, Kamikodanaka, 4-Chome, Nakahara-ku, Kawasaki, 211-8588, Japan Tel. : +81-44-754-2663 Fax. :+81-44-754-2664 Email: nakata@flab.fujitsu.co.jp

6 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 6 Presenters: Sreeranga P. Rajan, Fujitsu Labs. Of America, 595 Lawrence Expressway, Sunnyvale CA 94086-3922, USA Tel. : 408-530-4519 Fax. : 408-530-4515 Email: sree@fla.fujitsu.com

7 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 7 Tutorial Outline Motivation & Introduction to SoC Design & Re-use. System Verification Techniques for Module Verification : Formal, Semi- Formal Techniques for System Verification : Simulation, Hybrid, Emulation Quality of Functional Verification : Coverage Issues Academic & Research Lab Verification Tools Case Studies

8 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 8 Tutorial Outline (contd.) Commercial Tools Issues and Challenges / Future Research Topics Summary & Conclusions Bibliography Appendix

9 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 9 Tutorial Outline (Contd.) Motivation & Introduction to SoC Design & Re-use (Subir K. Roy) Motivation, Verification Heirarchy, System Level Design Flow, SoC Design, SoC Core Types, SoC Design Flow, Implications on Verification. System Verification (S. P. Rajan) Current Design Cycle, Design Cycle with System Verification.

10 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 10 Tutorial Outline (Contd.) Techniques for Module Verification Formal Approaches (S. Ramesh) Introduction to Formal Verification Formal Models, Modeling Languages, Formal Methods, Formal Specification, Temporal Logics, CTL, Automatic Verification, Theorem Proving.

11 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 11 Tutorial Outline (Contd.) Implementation of Formal Approaches (S. Chakraborty) Binary Decision Diagrams, Combinational Equivalence Checking, Sequential Equivalence Checking, Commercial Equivalence Checkers, Symbolic CTL Model Checking of Sequential Circuits, Forward & Backward Reachability, State of the Art, Related Techniques.

12 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 12 Tutorial Outline (Contd.) Techniques for Module Verification(contd.) Semi-Formal Approaches Semi-Formal Verification (S. Chakraborty) Interface Specification for Divide & Conquer Verification (T. Nakata) Techniques for System Verification Symbolic Simulation & Symbolic Trajectory Evaluation (S. Chakraborty) Hybrid Verification (S. P. Rajan) Emulation (Subir K. Roy)

13 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 13 Tutorial Outline (Contd.) Quality of Functional Verification (Subir K. Roy) Coverage Metrics – Informal, Semi-Formal, Formal. Academic & Research Lab Verification Tools Verification Tools – 1 (S. Ramesh) VIS, SMC, FC2toolset, STeP Verification Tools – 2 (S. P. Rajan) Fujitsu High Level Model Checking Tool, VeriSoft.

14 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 14 Tutorial Outline (Contd.) Case Studies Case Study – 1 (S. P. Rajan) ATM Switch Verification Case Study – 2 (T. Nakata) Semi-Formal Verification of Media Instruction Unit Commercial Tools (Subir K. Roy) FormalCheck, Specman Elite, ZeroIn-Search, BlackTie

15 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 15 Tutorial Outline (contd.) Issues and Challenges / Future Research Topics High Level Specification & Modeling using UML (T. Nakata) Research Issues ( S. Chakraborty) Future Research Directions (S. P. Rajan) Summary & Conclusions Summary ( S. Chakraborty) Conclusions (Subir K. Roy)

16 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 16 Tutorial Outline (contd.) Bibliography Papers, Books, Important Web Sites, Conferences, Journals/Magazines. Appendix Linear Temporal Logic, -Automata based Formal Verification (S. Ramesh) Neat Tricks in BDD Packages (S. Chakraborty) More Research Tools – SPIN, FormalCheck (S. Ramesh) More on UML (T. Nakata)

17 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 17 SoC Design & Re-use (Subir K. Roy)

18 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 18 Motivation Pentium SRT Division Bug : $0.5 billion loss to Intel Mercury Space Probe : Veered off course due to a failure to implement distance measurement in correct units. Ariane-5 Flight 501 failure : Internal sw exception during data conversion from 64 bit floating point to 16 bit signed integer value led to mission failure. The corresponding exception handling mechanism contributed to the processor being shutdown (This was part of the system specification).

19 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 19 Verification Hierarchy Degree of Automation Coverage/ Expressive Power Simulation Equivalence Checking of structurally similar circuits Equivalence Checking Assume-Guarantee based symbolic simulation/Model Checking Temporal Logic Based Model Checking First-Order Theorem Proving Higher-Order Theorem Proving

20 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 20 System Level Design Flow Interface Definition Component Selection ASIC & Software Implementation Glue Logic Implementation PCB Layout Implementation Integration & Validation of Software into System Debugging Board - Manufacturing & Test

21 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 21 SoC Design Core based design approach Design Complexity Time To Market Core : A pre-designed, pre-verified Silicon circuit block. Eg. Microprocessor, VPU, Bus Interface, BIST Logic, SRAM, Memory. Core Integration Re-usable cores : different types, different vendors User defined logic

22 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 22 SoC Design Designing Cores for integration Parameterization Customizable soft cores. Core provider supp- lies essential set of pre-verified parameters. Functionality Single core - preferable Multiple core - Needs good partitioning Interface Support std. buses to ease integration.

23 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 23 SoC Core Types [ Anderson, 2001] Cell/Macro Library elements DSPs, Microcontrollers Implementation of Standards Function (MPEG, JPEG, CRC, PicoJava,…) Interconnects (PCI, SCSI, USB, 1394, IrDA, Bus Bridges) Networking (10/100 ethernet, ATM etc.)

24 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 24 SoC Core Types Soft Cores : Technology Independent Synthesizable Description. White Box Implementation - Visible & Modifiable. Core can be extended functionally. Firm Cores : Technology Dependent Gate Level Netlist. Internal implementation of core cannot be modified. User can parameterize I/O to remove unwanted functionality. Hard Cores : Layout & Timing Information provided. Cannot be re-synthesized. Integration is simple & can result in highly predictable performance.

25 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 25 SoC Design Flow Co-design approach : Software + Hardware Design exploration at behavioral level (C, C++, etc.) by system architects Creation of Architecture Specification RTL Implementation (Verilog/VHDL) by hardware designers

26 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 26 SoC Design Flow Drawbacks Specification Errors - susceptible to late detection Correlating validations at Behavioral & RTL level difficult Common interface between system & hw designers based on natural language

27 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 27 SoC Implementation Approaches Vendor Based Approach : ASIC Vendor/Design service group carries out implementation Partial Integration : System Designer implements proprietary & application specific logic. ASIC Vendor integrates above with their cores In house : ASIC Vendor designs specialized cores. System Designer implements proprietary & appli- cation specific logic, integrates cores & verifies integrated design

28 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 28 Multiple Sources for IP Reuse Semiconductor houses I/O Pad, Processor Core, Custom Logic, Memory, Peripheral Interface IP/Core Suppliers Processor Core, Peripheral Interface, Analog /Mixed Signal blocks (DAC, ADC, PLL) System Designer Controller, Custom Logic, AMS blocks

29 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 29 Advantages of Core/IP based approach Short Time To Market (pre-designed) Less Expensive (reuse) Faster Performance (optimized algorithms and implementation) Lesser Area (optimized algorithms and implementation)

30 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 30 Implications on Verification [Mosensoson, DesignCon 2000] Verification Focus Integration Verification & Complexity. Bug Classes Interactions between IP/Core/VC blocks Conflicts in accessing shared resources Deadlocks & Arbitration Priority conflicts in exception handling Unexpected HW/SW sequencing

31 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 31 Implications on Verification Need to capture complexity of an SoC into an executable verification environment Automation of all verification activities Reusability of verification components of unit Cores/IPs/VCs Abstraction of verification goals (Eg., Signals to Transcations, End to End Transactions) Checkers for internal properties Interface Monitors (BFM, Integration Monitors) Coverage monitors

32 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 32 Implications on Verification Implication Rigorous verification of each individual SoC component seperately Extensive verification of full system Requirements Efficient Verification Methodologies Efficient Tools High Level of Automation

33 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 33 System Verification (S. P. Rajan)

34 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 34 Current Design Cycle OK Modify RTL Source Simulation + Formal Verification RTL/logic Synthesis Timing Analysis Modify Script RTL Description (from Spec/Doc) NOT OK

35 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 35 Current Design Cycle Methodology fixed parameter modeling large-scale simulation (expensive) synthesis large-scale validation (expensive) Design cycle iteration expensive for changes in design parameters Does RTL Description satisfy Specification?

36 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 36 Design Cycle with System Verification Validate = Formally Verify + Simulate Validate Cycle Accurate Behavior Generic Parameters Cycle Accurate Behavior Fixed Parameters Gate-Level (Large Design) Gate-Level (Small) Validate Chip Instantiation High/RT-Level Synthesis Logic Synthesis

37 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 37 Design Cycle with System Verification Parametric Design Methodology: -- Higher abstraction level -- Reusable generic parametric model -- small-scale simulation (low cost) -- formal verification viable -- Automatic high-level synthesis -- validation on a small scale (low cost) Formal verification early in design cycle Drastic reduction in design cost, time-to-market

38 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 38 Techniques for Module Verification

39 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 39 Formal Verification (S. Ramesh)

40 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 40 Formal Methods Functional verification SOC context: block level verification, IP Blocks and bus protocols Formally check a formal model of a block against its formal specification Formal - Mathematical, precise, unambiguous, rigorous Static analysis No test vectors Exhaustive verification Prove absence of bugs rather than their presence Subtle bugs lying deep inside caught

41 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 41 Three-step process Formal specification Precise statement of properties System requirements and environmental constraints Logic - PL, FOL, temporal logic Automata, labeled transition systems Models Flexible to model general to specific designs Non-determinism, concurrency, fairness, Transition systems, automata

42 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 42 Three-step process (contd.) Verification Checking that model satisfies specification Static and exhaustive checking Automatic or semi-automatic

43 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 43 Formal verification Major techniques Equivalence checking Model checking Language containment Theorem proving Lang. Containment Obs. Equivalence Automata/ Tr. Systems Th. Proving Eq. Checking Model CheckingLogic Tr. Systems/ Automata Model Spec

44 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 44 EQUIVALENCE CHECKING Checking equivalence of two similar circuits Comparison of two boolean expressions - BDDs Highly automatic and efficient Useful for validating optimizations, scan chain insertions Works well for combinational circuits Limited extension to sequential circuits Most widely used formal verification technique. Many commercial tools: Design VERIFYer (Chrysalis), Formality (Synopsis), FormalPro (Mentor Graphics), Vformal(Compass), Conformal (Verplex), etc.

45 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 45 Model checking/Language Containment Another promising automatic technique Checking design models against specifications Specifications are temporal properties and environment constraints Design models are automata or HDL subsets Checking is automatic and bug traces Very effective for control-intensive designs Commercial and Academic tools: FormalCheck (Cadence), BlackTie (Verplex), VIS (UCB), SMV(CMU, Cadence), Spin (Bell labs.), etc. In-house tools: IBM (Rulebase), Intel, SUN, Fujitsu (Bingo), etc.

46 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 46 Theorem proving Theoretically most powerful technique Specification and design are logical formulae Checking involves proving a theorem Semi-automatic High degree of human expertise required Mainly confined to academics Number of public domain tools ACL2 (Nqthm), PVS, STeP, HOL ACL2 used in proving correctness of floating point algorithms

47 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 47 Formal verification (experiences) Very effective for small control-intensive designs-blocks of hundreds of latches Many subtle bugs have been caught in designs cleared by simulation Strong theoretical foundation High degree of confidence Hold a lot of promise Require a lot more effort and expertise Large designs need abstraction Many efforts are underway to improve

48 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 48 Systems verified Various microprocessors (instruction level verification): DLX pipelined architectures, AAMP5 (avionics applications), FM9001 (32 bit processor), PowerPC Floating point units: SRT division (Pentium), recent Intel ex-fpu, ADK IEEE multiplier, AMD division Multiprocessor coherence protocols SGI, sun S3.Mp architectures, Gigamax, futurebus+ Memory subsystems of PowerPC Fairisle ATM switch core

49 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 49 State of the art FSM based methods : ~ 500 registers STE: ~ 10 - 20k registers Equivalence checking : ~ million gates designs Simulation : million gates capacity

50 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 50 Challenges of formal verification Complexity of verification Automatic for finite state systems (HW, protocols) Semi-automatic in the general case of infinite state systems (software) State explosion problem Symbolic model checking Homomorphism reduction Compositional reasoning Partial-order reduction

51 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 51 Formal Modeling (S. Ramesh)

52 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 52 Models High level abstractions of real systems Contain details of relevance Full Systems detailed and complex Physical components and external components e.g. buses, schedulers, OS/network support software Modeling Modeling is a (pre-) design activity Models relatively easier to build Higher level than behavioral models (C models) early detection of bugs, design space exploration and verification, prototypes and synthesis

53 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 53 Formal Models Mathematical description of models Precise and unambiguous Consistent and complete Formal Verification Applies to mathematical models and not to real objects (hence called Design Verification) Faithful models essential False negatives (Spurious Errors) False positives (Models pass but System fails) Simulation/Testing cannot be dispensed with!

54 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 54 Formal Modeling Languages Enable abstract and high level descriptions Real languages often ambiguous Variation in HDL semantics Real languages require more details and effort Features Limited and High Level Data Types Nondeterminism (arising out of abstractions) Concurrency (to structure large systems) Communication (for internal and external interaction) Fairness (abstraction of real concurrency and schedulers)

55 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 55 Example Modeling Languages Finite State Machines CSP, CCS, SDL, Promela (for Asynchronous Systems and Protocols) Esterel, CFSM (Embedded Controllers) Statecharts, UM L (System level models)

56 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 56 Models of Hardware Hardware blocks are reactive systems: Reactive systems exhibit infinite behavior Termination is a bad behavior Timing/Causality information important

57 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 57 Finite State Machines Well-known model for describing control or sequential circuits An example (3-bit counter) State labels describe bit status

58 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 58 Another Example A Traffic Light Controller States HG - Highway green, FY – Farm road Yellow C - Car in Farm road, S,L - Short and long timer signal TGR - reset timer, set highway green and farm road red

59 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 59 States and Transitions States are abstract description of actual machine states decided by the states of latches and registers Finite no. of States No final state - reactive systems not supposed to terminate Edge labels - input/condition and output/action

60 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 60 States and Transitions Many Flavors of State Machines edge labeled - Mealy machines state labeled - Kripke structures state and edge labeled - Moore machines Labels Boolean combination of input signals and outputs communication events (CSP, Promela)

61 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 61 Semantics of Finite State Systems The above description is syntactic Semantics associates behaviors Branching Time semantics the tree of states obtained by unwinding the state machine graph possible choices are explicitly represented Linear Time Semantics the set of all possible `runs' in the system the set of all infinite paths in the state machine

62 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 62 Non-determinism 2-master arbiter, reqi - request from Master i This machine is nondeterministic In Idle state when req1 and req2 arrive. Non-determinism due to abstraction More than one behaviour for a given input

63 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 63 Concurrency A concurrent (and hierarchical) description of Counter

64 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 64 Concurrent Descriptions Compact and easy to understand Natural model for hardware and complex systems Clear semantics required Interleaved model and synchronous models Appropriate communication primitives Concurrent machines composed to a single global machine Global machine captures all possible executions Exponential blow-up

65 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 65 Fairness Constraints In general, not every run in a state machine is a valid behavior Arbiter example the run in which master 2 is never granted the resource But all runs are included in transition systems Fairness constraints rule out certain runs Modeling abstraction of real-time or schedulers Example Every request eventually considered The clock tick arrives infinitely often

66 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 66 Fairness Constraints Not required with a more concrete description But concrete description too complex to verify A given property may not require concrete details For verification, abstract designs are preferable. proof is simpler proof is robust under alternate implementations.

67 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 67 Generating Formal Models Pre-design activity Automatic Translation from circuits/HDL designs States decided by the latches/registers in the ckt. Exponential blow-up in the size (State-explosion problem) Usually abstractions required

68 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 68 Design errors Deadlock Look at state (1,1) Unspecified Receptions State (1,1) P1 can send message 2 P2 cannot receive this Non executable interaction - 'Dead code State 3 of P1 cannot be reached at all

69 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 69 Live lock/Divergence An example: Formal Verification generalizes early approaches to detection of such errors!

70 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 70 Formal Specification (S. Ramesh)

71 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 71 Formal Specifications Verification involves checking that a design model meets its specification. Specification states what the system is supposed to do Design describes how this is done Specification Describes unambiguously and precisely the expected behavior of a design. In general, a list of properties. Includes environment constraints. Symbolic logic or automata formalisms Consistency and Completeness

72 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 72 Specification of Hardware blocks Properties and Constraints specify possible states and transitions They state set of possible valid `runs' Valid runs are infinite sequences (or trees) of states and transitions Formal specifications are finitistic and precise descriptions Classification of Properties: Safety properties "undesirable states are never reached", "desirable things always happen". Progress or Liveness Properties "desirable state repeatedly reached" "desirable state eventually reached"

73 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 73 Examples Safety Properties A bus arbiter never grants the requests to two masters Message received is the message sent Elevator does not reach a floor unless it is requested At any time traffic is let either in the farm road or on the highway every received message was sent Liveness Properties car on the farm road is eventually allowed to pass Elevator attends to every request eventually every bus request is eventually granted every sent message was received

74 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 74 Specification Formalisms Properties and Constraints specify permissible behaviours Behaviours are infinite runs (reactive systems) They are infinite objects, in general. We need finitistic representation of such infinite objects for precision Two Major formalisms: Symbolic Logics: Linear and Branching Temporal Logics, Automata

75 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 75 Temporal Logics Logics well-known for precise specification, amenable to symbolic manipulations. used in a variety of contexts: Propositional Logic/Boolean algebra for combinational HW Predicate logics for software Higher order logics for language semantics. Temporal logic for hardware and protocols. Qualitative temporal statements Examples: If it is cloudy, eventually it will rain It never rains here

76 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 76 Properties of Hardware blocks Temporal in nature At any time only one units is accessing the bus every request to access the bus is granted ultimately. Two Kinds of TL Linear Temporal Logic (LTL): Time is a linear sequence of events Branching time temporal logic (CTL, CTL*): Time is a tree of events

77 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 77 Computational Tree Logic (CTL) CTL formulae describe properties of Computation Trees Computation Trees are obtained by unwinding the transition system model of blocks Branching structure due to nondeterminism CTL is the simplest branching temporal logic CTL* is more powerful, includes CTL and LTL

78 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 78 Syntax of CTL Every atomic proposition is a CTL formula If f and g are formulae then so are f, (f g), (f g), (f g), (f g) AG f - in all paths, in all state f (in all future, f) EG f - in some path, in all states f AF f - in all paths, in some state f (in every future f) EF f - in some future f A(f U g) - in all paths, f holds until g E(f U g) - in some path, f holds until g AX f - in every next state, f holds EX f - in some next state f holds

79 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 79 Examples AG ¬ (farm_go high_go_B) AGAF (farm_car AF(farm_go)) AG (mem_wr U mem_ack) EF (req 0 U grant 0 )

80 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 80 Model Checking (S. Ramesh)

81 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 81 Automatic Verification Model Checking and Language Containment For finite state systems like Hardware blocks, protocols and controllers. Systems modeled as transition systems or automata Specifications temporal formulae (LTL, CTL) or automata Verification: Model Checking: A finite state system or automaton satisfies a temporal logic specification iff it is a model of the formula. Language Containment: An automaton model (M) of the system satisfies an automaton specification (S) if the language of M is contained in that of S.

82 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 82 CTL model checking (Clarke and Emerson, Quielle and Sifakis) M F M Transition System and F, CTL formulae M defines a tree (unwind the Transition System) F specifies existence of one or all paths satisfying some conditions. Verification involves checking whether these conditions hold for the tree defined by M.

83 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 83 EXAMPLE Which of the following hold ? AG p, EF¬q, AX p, AG ¬q, EG ¬q, AX(p q)

84 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 84 CTL Verification by Explicit Enumeration Iterative labeling algorithm that labels all the states with sub formulae. Start from the initial labels of atomic propositions Iteratively add sub formulae as labels with each state based on the following equations: EF p = p EX p EX(EX p) EG p = p EX p EX(EX p) E (q U p) = p (q EX p) (q EX(q EX p))

85 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 85 CTL Verification Iteration terminates since states and subformulae are finite. If initial states are labeled with the given formula then the model checking succeeds if it fails, counterexample can be generated

86 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 86 Illustration To compute EF p which is: EF p = p EX(p) EX(EX(p))...

87 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 87 Illustration contd. Iterative computation I step :

88 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 88 Illustration contd. II step : III step :

89 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 89 Illustration contd. Computation terminates EF p Holds in all striped states Computation involves backward breadth first traversal and calculation of Strongly Connected Subgraphs (cycles)

90 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 90 2. Compute EG p in EG p = p EX p EX(EX p)...

91 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 91 Illustration contd. Start with I iteration

92 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 92 Illustration contd. II iteration III iteration Iteration terminates

93 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 93 Complexity of CTL model checking Algorithm involves backward traversal Linear on the sizes of both formulae and model Size of the model exponential in size of latches Reduction Techniques: Symbolic Model checking Techniques Compositional Verification Symmetry based reduction

94 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 94 Verification by Theorem Proving (S. Ramesh)

95 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 95 Theorem Proving Classical technique Most general and powerful non-automatic (in general) Idea Properties specified in a Logical Language (SPEC) System behavior also in the same language (DES) Establish (DES SPEC) as a theorem.

96 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 96 A Logical System A language defining constants, functions and predicates A no. of axioms expressing properties of the constants, function, types, etc. Inference Rules A Theorem `follows' from axioms by application of inference rules has a proof

97 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 97 Proof Syntactic object A 1, A 2,..., A n A 1 : axiom instance A n : theorem A i+1 - Syntactically obtainable from A 1,..., A i using inference rules.

98 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 98 Examples Propositional logic and its natural deduction system Prove i=1 i = N(N + 1)/2, using Peano's axioms and mathematical induction

99 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 99 Full Adder sum := (x y) cin cout := (x y) ((x y) cin) Theorem: sum = x + y + cin – 2 * cout Proof : Use properties of boolean and arithmetic operators.

100 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 100 Problems with the approach Verification is a laborious process Manual proofs could contain error If proof exists, system is correct otherwise, no conclusion. Interactive Theorem Provers Ease the process of theorem proving Proof-Checking Decision Procedures Proof Strategies Theory building Many systems are available: Nqthm, PVS, HOL, Isabelle, etc.

101 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 101 Binary Decision Diagrams (S. Chakraborty)

102 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 102 Boolean Function Representation Boolean logic: Foundation of digital design Need to represent and manipulate Boolean functions efficiently Common representations: Truth table, Karnaugh map, Canonical sum- of-products Size always 2 n for n-arguments Operations (e.g. AND, NOT) inefficient Inappropriate for practical applications E.g., representing carry-out function of 64-bit adder

103 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 103 Binary Decision Diagrams (BDDs) A graphical representation [Bryant 96] Allows efficient representation & manipulation of Boolean functions Worst-case behavior still exponential Example: f = x 1.x 2 + x 3 Represent as binary tree Evaluating f: Start from root For each vertex x i left branch if x i = 0 else right branch x3x3 x1x1 x2x2 x3x3 x3x3 1011 1010 x3x3 x2x2 0 1

104 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 104 BDDs Underlying principle: Shannon decomposition f(x 1, x 2, x 3 ) = x 1.f(1, x 2, x 3 ) + x 1.f(0, x 2, x 3 ) = x 1. (x 2 + x 3 ) + x 1. (x 3 ) Apply recursively to f(1, x 2, x 3 ) and f(0, x 2, x 3 ) Extend to n arguments Number of nodes can be exponential in number of arguments f = x 1.x 2 + x 3 x1x1 x2x2 x3x3 x3x3 1011 1010 x3x3 x2x2 x3x3

105 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 105 Restrictions on BDDs Ordering of variables In all paths from root to leaf, variable labels of nodes must appear in specified order Reduced graphs No two distinct vertices represent same function Each non-leaf vertex has distinct children REDUCED ORDERED BDDs (ROBDDs): DAG x1x1 x2x2 x3x3 x2x2 1011 1010 x2x2 x3x3 x3x3 f = x 1.x 2 + x 1.x 2 + x 1.x 3

106 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 106 ROBDDs Example: Properties Unique representation of f for given variable ordering Checking f1 = f2: ROBDD isomorphism Shared subgraphs: size reduction Every path might not have all labels Every non-leaf vertex has path(s) to 0 and 1 So far good ! f = x 1.x 2 + x 3 1 0 x1x1 x2x2 x3x3 x1x1 x2x2 x3x3 x3x3 1011 1010 x3x3 x2x2

107 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 107 Variable Ordering Problem 1 01 3 3 5555 2 2 2 2 4 4 6 10 3 5 2 4 6 1 f = x 1.x 2 + x 3.x 4 + x 5.x 6 Order 1,3,5,2,4,6 Order 1,2,3,4,5,6

108 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 108 Variable Ordering Problem ROBDD size extremely sensitive to variable ordering f = x 1.x 2 + x 3.x 4 + … + x 2n-1.x 2n 2n+2 vertices for order 1, 2, 3, 4…2n-1, 2n 2 n+1 vertices for order 1, n+1, 2, n+2,…n, 2n f = x 1.x 2.x 3 ….x n n+2 vertices for all orderings Output functions of integer multipliers Exponential size for all orderings [Bryant 91]

109 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 109 Determining best variable order to minimize BDD size NP-complete [Bollig, Wegener 96] Heuristics: Static and dynamic ordering [Fujita et al 92, Rudell 93] Sampling based schemes [Jain et al98] Variable Ordering Problem

110 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 110 Operations on BDDs Operation Complexity Reduce O(|G|) G reduced to canonical form Apply O(|G 1 ||G 2 |) Any binary Boolean op: AND, XOR … Compose O(|G 1 | 2 |G 2 |) g 1 (x 1, x 2, x 5 ) composed with g 2 (x 3, x 4 ) at position of x2: g 1 (x 1, g 2 (x 3,x 4 ), x 5 )

111 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 111 Operations on BDDs (Contd.) Operation Complexity Satisfy-one O(n) Assignment of x 1, … x n for which f(x 1,… x n ) = 1 Restrict O(|G|) ROBDD for f(x 1, x 2, …,1,... x n ) or f (x 1, x 2, … 0 … x n )

112 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 112 Operations on BDDs Operators: Take ROBDD arguments, return ROBDD result. Complexity polynomial in BDD size BDD size limiting factor in most applications Ongoing research on avoiding BDD blowup Variable ordering, Partitioned BDDs, Implicitly conjoined BDDs etc. Quantification with BDDs x 1. f(x 1, x 2, x 3 ) = f(0, x 2, x 3 ) + f(1, x 2, x 3 ) x 1. f(x 1, x 2, x 3 ) = f(0, x 2, x 3 ). f(1, x 2, x 3 ) Useful in Symbolic Model Checking

113 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 113 BDD Packages/Libraries Out There CUDD package (Colorado University) http://vlsi.colorado.edu/~fabio/CUDD/cuddIntro.html Carnegie Mellon BDD package http://www-2.cs.cmu.edu/ afs/cs/project/modck/pub/www/bdd.html TiGeR BDD library (commercial package) CAL (University of California, Berkeley) http://www-cad.eecs.berkeley.edu/ Respep/Research/bdd/cal_bdd/ BuDDy http://www.itu.dk/research/buddy

114 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 114 BDD Packages/Libraries Out There ABCD http://i10www.ira.uka.de/armin/abcd/index.html BDDNOW http://www.diku.dk/students/lordtime/bddnow.tar.gz PPBF http://www-2.cs.cmu.edu/~bwolen/software/ppbf/...

115 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 115 Applications of BDDs Extensively used in CAD for digital hardware Some applications (partial listing) Combinational logic verification through equivalence checking Sequential machine equivalence Using combinational equivalence of next- state logic Symbolic model checking Automatic test pattern generation (ATPG)

116 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 116 Applications of BDDs Timing verification Representing false paths in circuits Representing discrete time encoded in binary Symbolic simulation Assigning symbolic values to circuit inputs and determining symbolic output values Symbolic trajectory evaluation Checking temporal properties over sequences of symbolic values Logic synthesis and optimization

117 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 117 Combinational Equivalence Checking (S. Chakraborty)

118 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 118 Combinational Equivalence Checking Given two combinational designs Same number of inputs and outputs Determine if each output of Design 1 is functionally equivalent to corresponding output of Design 2 Design 1 could be a set of logic equations/RTL Design 2 could be a gate level/transistor level circuit Design 1Design 2

119 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 119 Right Fit for ROBDDs ROBDD for every function is canonical Construct ROBDDs for each output in terms of inputs Use same variable order Check if the graphs are isomorphic ROBDD isomorphism is simple Alternatively Design 1 Design 2 F Designs functionally equivalent if and only if F is identical to 0 (0 for all inputs)

120 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 120 ROBDDs in Equivalence Checking Problem reduces to checking F for unsatisfiability If ROBDD has a non-leaf vertex or a 1 leaf, F is satisfiable But there are problems … For 32 bit multiplier, there are 64 inputs and BDD blows up Same is true for other real-life circuits Interestingly, several of these are actually easy to check for equivalence

121 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 121 ROBDDs in Equivalence Checking Something smarter needed … Worst case must still be exponential complexity Unsatisfiability: co-NP complete!

122 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 122 Using Structural Information Structural similarities between designs help If A1 equivalent to A2 & B1 equivalent to B2, Design1 equivalent to Design2 Simplifies equivalence checking But consider B1 not equiv to B2, but Design 1 equiv to Design 2 A1B1A2B2 A1B1A2B2

123 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 123 Using Structural Information False negative Analysis indicates designs may not be equivalent, but designs are actually equivalent Use logical implication to reduce false negatives If out1 is not equivalent to out2, out1 out2 is satisfiable Express out1 out2 in terms of internal signals in design1 and design2 Design 1 Design 2 F Internal signals

124 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 124 Method of Implication Derive set of internal signals that must be not equivalent if out1 out2 is satisfiable Propagate implications back towards inputs Stop when Primary inputs reached Two primary inputs never equivalent So, out1 out2 is satisfiable

125 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 125 Method of Implication Stop when Internal signals reached are known to be equivalent Conclude out1 out2 is unsatisfiable So, out1 is equivalent to out2 Some pairs of signals can be quickly identified as not equivalent by random simulation

126 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 126 Structural Simplifications Once two internal signals are found equivalent, the circuit can be simplified Suppose outputs of corresponding AND gates are equivalent Helps reduce size of circuit to deal with later

127 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 127 An Efficient Equivalence Checker Finds pairs of equivalent signals in two designs [Matsunaga 96] CEP: Candidate equivalent pairs VEP: Verified equivalent pairs Start Random simulation CEP list More pairs to verify? Verify pair, update VEP list and CEP list, Restructure circuit Check if primary output pair is in VEP list End NO YES

128 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 128 Some Observations Most non-equivalent pairs filtered by random simulation Equivalent pairs identified early by proper choice of internal variables when propagating implications backwards If pair under investigation is expressed in terms of already known equivalent pairs, we are done! Leverage Automatic Test Pattern Generation (ATPG) techniques to detect when a pair is not equivalent Targets implementation error, error due to translation or incremental modification, NOT design error

129 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 129 Checking Arithmetic Circuits Equivalence checking of multipliers acknowledged to be hard ROBDD blowup for bit-level representation Multiplicative Binary Moment Diagrams (*BMDs) [Bryant, Chen 95] Boolean assignment of variables maps to a number (integer, rational) Canonical representation of linear functions, e.g. integer multiplication Word level representation of function Allows efficient verification of multipliers and other arithmetic circuits

130 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 130 Sequential Machine Equivalence Restricted case: Reduces to combinational equivalence Given machines M1 and M2 with correspondence between state and output variables Checking equivalence of M1 and M2 reduces to equivalence checking of next-state and output logic Comb Logic1 FF Comb Logic2 FF Given Equivalence

131 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 131 Equivalence Checking - Extensions For best results, knowledge about structure crucial Divide and conquer Learning techniques useful for determining implication State of the art tools claim to infer information about circuit structure automatically Potentially pattern matching for known subcircuits -- Wallace Tree multipliers, Manchester Carry Adders

132 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 132 Equivalence Checkers Out There Commercial equivalence checkers in market Abstract, Avant!, Cadence, Synopsys, Verplex, Veritas (IBM internal)...

133 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 133 Symbolic Model Checking (S. Chakraborty)

134 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 134 Model Checking Sequential Circuits Given: A sequential circuit Finite state transition graph Flip-flops with next-state logic Transition relation between present and next states A property in specialized logic Prove that MODEL satisfies SPECIFICATION In case of failure, counterexample desirable MODEL SPECIFICATION

135 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 135 Example: 3-bit Counter x2x2 x1x1 x0x0 X0 X1 X2 Clk Model State transition graph defined by X0 = NOT( x 0) X1 = XOR( x 1, x 0) X2 = XOR( x 2, x 0. x 1) Property State x 0, x 1, x 2 = 111 is reached infinitely often starting from state 000

136 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 136 Basic Approaches Explicit state model checking Requires explicit enumeration of states Impractical for circuits with large state spaces Useful tools exist: EMC, Murphi, SPIN, SMC … Symbolic model checking Represent transition relations and sets of states implicitly (symbolically) BDDs used to manipulate implicit representations Scales well to large state spaces (few 100 flip flops) Fairly mature tools exist: SMV, VIS, FormalCheck...

137 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 137 Model Checking Reachability analysis Find all states reachable from an initial set S0 of states Check if a safety condition is violated in any reachable state CTL property checking Express property as formula in Computation Tree Logic (CTL) Check if formula is satisfied by initial state in state transition graph

138 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 138 Symbolic Model Checking For 3-bit counter, set of states x 0, x 1, x 2 = {000, 010, 011, 001} can be represented by S ( x 0, x 1, x 2) = S( x ) = x 0. BDD: Set of state transitions can be represented by N ( x 0, x 1, x 2, X0, X1, X2) = N ( x, X) = (X0 x 0 ) (X1 x 1 x 0) (X2 x 2 ( x 1. x 0)) BDD: 1 0 x0x0 x0 1 0

139 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 139 Forward Reachability Start from set S0 of states Set of states reachable in at most 1 step: S1 = S0 { X | x in S0 N( x, X) = 1} Expressed as Boolean functions: Given S0 ( x 0, x 1, x 2), S1 (X0, X1, X2) = S0 (X0, X1, X2) x 0, x 1, x 2. [S0 ( x 0, x 1, x 2) N( x 0, x 1, x 2, X0, X1, X2)] Given BDDs for S0 and N, BDD for S1 can be obtained S0 S1

140 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 140 Forward Reachability Compute S1 from S0, S2 from S1, S3 from S2, … Predicate transformer F: S i+1 = F (S i ) Continue until S k+1 = F (S k ) = S k Least fixed point of F S k = Set of all states reachable from S0 Computed symbolically -- using BDDs Very large state sets can be represented compactly S0 Reachable states

141 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 141 Backward Reachability Give a set Z0 of states Compute set of states from which some state in Z0 can be reached. Analogous to forward reachability with minor modifications Z0

142 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 142 Checking Safety Conditions Safety condition must ALWAYS hold E.g. Two bits in one-hot encoded state cannot be 1 Z = set of states violating safety condition Given S0 = set of initial states of circuit, Compute R = set of all reachable states Determine if Z intersects R, i.e. (Z R) 0 If YES, safety condition violated Satisfying assignment of (Z R): counterexample If NO, circuit satisfies safety condition All computations in terms of BDDs

143 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 143 Checking Safety Conditions Start from Z = set of bad states Find by backward reachability set of states B that can lead to a state in Z Determine if S0 intersects B S0 R Z Z B Forward ReachabilityBackward Reachability

144 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 144 CTL Properties Once req goes high, grant eventually goes high Not expressible as safety property Use formulae in Computation Tree Logic (CTL) CTL formulae at state S0 Atomic proposition: x 1 = x 2 = x 3 = 0 AG f: In all paths from S0, f holds globally AF f: In all paths from S0, f holds finally AX f: In all paths from S0, f holds in next state A[f U g]: In all paths from S0, g holds finally, and f holds until then S0 Computation tree of states

145 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 145 More on CTL EG f, EF f, EX f, E [f U g] defined similarly There exists a path from current state … f and g can themselves be CTL formulae E.g., AG AF ( x 1 x 2) x 1 or x 2 is satisfied infinitely often in the future Recall 3-bit counter example: The state x 0, x 1, x 2 = 111 is reached infinitely often starting from 000 x 0 x 1 x 2 AG AF ( x 0 x 1 x 2)

146 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 146 CTL Model Checking Clarke, Emerson, Sistla proposed algorithm for CTL model checking on explicit state graph representation [Clarke et al 86] Linear in graph size and formula length Burch, Clarke, Long, McMillan, Dill gave algorithm for CTL model checking with BDDs [Burch et al94] Suffices to have algorithms for checking EG f, EX f, and E [f U G] Other formulae expressed in terms of these EF f = E [true U f] AF f = (EG ( f))

147 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 147 Symbolic CTL Model Checking Given a model with set S0 of initial states and a CTL formula f To determine if f is satisfied by all states in S0 Convert f to g that uses only EX, EG, E[p U q] CHECK(g) returns set of states satisfying g If g = atomic proposition (e.g., x 1. x 2 + x 3), CHECK returns BDD for g If g = EX p, EG p, E[p U q], CHECK uses reachability analysis to return BDD for set of states Worst-case exponential complexity Finally, determine if S0 CHECK(g)

148 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 148 State of the Art Techniques to address memory/runtime bottlenecks Partitioned transition relations Addresses BDD blowup in representing transitions Early quantification of variables Addresses BDD blowup during image computation Iterative squaring Exponential reduction in number of steps to fixed point

149 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 149 State of the Art Techniques to address memory/runtime bottlenecks (contd.) Use domain knowledge to order BDD variables and order quantified variables Modified breadth first search To explore state space of loosely coupled systems Active ongoing research …

150 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 150 State of the Art Symbolic model checkers can analyze sequential circuits with ~ 200 flip flops For specific circuit types, larger state spaces have been analyzed Frontier constantly being pushed Abstract, Avant!, IBM, Cadence, Intel & Motorola (internal)...

151 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 151 State of the Art Specifying properties in specialized logic often daunts engineers Better interfaces needed for property specification Monitor-based model checking Monitor observes system states and flags when something bad happens Property to check: Does monitor ever raise flag?

152 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 152 Related techniques Model checking for bugs Prioritize state space search to direct it towards bugs Start from error state and current state Compute pre-image of error states & image of current state Choose states for further expansion in order of their proximity to pre-image of error states Proximity metrics: Hamming distance, tracks, guideposts [Yang, Dill 98] Helps find bugs in erroneous circuits quickly No advantages if circuit is bug-free

153 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 153 Related techniques Approximate Model Checking Representing exact state sets may involve large BDDs Compute approximations to reachable states Potentially smaller representation Over-approximation : No bugs found Circuit verified correct Bugs found may be real or false Under-approximation : Bug found Real bug No bugs found Circuit may still contain bugs Reachable states Buggy states

154 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 154 Related techniques Bounded model checking Check property within k steps from given set S 0 of states S 0 F(S 0 ) F 2 (S 0 ) … F k (S 0 ) Unroll sequential machine for k time steps To check property Z, test satisfiability of (S 0 Z) (S 0 Z) (S1 Z) … (S k Z) Leverages work done on SAT solvers PI PO NSPS PI 0 S0S0 PI 1 S1S1 S2S2 PI 2 S3S3

155 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 155 Semi-formal Methods (S. Chakraborty)

156 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 156 Semi-formal Verification Formal verification still a bottleneck Simulation and emulation not keeping up with design complexity Designs with bugs being produced FV methods havent yet been able to scale to all types of industry designs Fundamental complexity limits restrict how much FV can do Need some viable alternative Use a hybrid of testing, simulation and formal methods to fill the gap

157 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 157 Semi-formal Verification Simulation Driver Simulation Engine Simulation Monitor Symbolic Simulation Coverage Analysis Diagnosis of Unverified Portions Guided vector generation Conventional Extension Devadas and Keutzers proposal: A pragmatic suggestion for SOC verification

158 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 158 Semi-formal Verification Smart simulation: Maximize chances of detecting bugs at small cost Coverage metrics crucial Code based (conditionals/assignments in HDL) Circuit-structure based (node toggle) State-space based (states reached) Functionality based (user defined event sequences) More to come... Use metrics to determine Unexercised parts of design: Guide vector generation Adequacy of verification: When to stop?

159 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 159 Semi-formal Verification Metric Coverage Measure of how adequately design is exercised A measure of controllability Observability is another major issue Must propagate a mismatch in an internal signal value (which can cause problems later on) to the observable outputs White Box techniques help Assertion checkers [0-In] Techniques from testing can be borrowed

160 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 160 Semi-formal Verification Coverage + observability can be used to direct simulation Test generation Model design errors by fault model (e.g. stuck- at) Generate tests automatically that maximize coverage metric per test simulation cycle Sequential ATPG methods can be used But hard problem in general!

161 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 161 Semi-formal Verification Test generation (contd.) Generate tests for FSMs (deep inside design) using model checking techniques Map test inputs of FSM deep inside design to design inputs User guided Automatic using sequential ATPG

162 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 162 Semi-formal Verification Test Amplification Make use of interesting test cases already generated by ATPG or user Explore behavior near tested region of state space Rationale: Generated tests may take the design into an error-prone corner but may not detect any/all errors there. Goal : Detect as many near-miss bugs as possible by looking around paths taken by known tests

163 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 163 Semi-formal Verification Partial model checking When BDDs start to blow up, delete part of state space from consideration Choose parts to delete such that maximum number of states can be explored with given resources Hash tables in explicit model checking to prevent blow-up of state space Aliasing problem Suitable choice of hashing function gives very low alias prob

164 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 164 Interface Specification for Divide & Conquer Verification (T. Nakata)

165 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 165 Verification engine Constraints in Module Verification Constraints problem in a case study Not specified by the designers Defined by verification team through verification process Result: # of constraints=1818, # of properties=118 (# of constraints < 50 if correctly specified) Module under verification Properties Input constraints

166 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 166 Two Ways to Define Constraints Module under verification Add pseudo module to inputs Module under verification // PSE_BGN // PSE_ERR [ data == CLD ] [ data != CB ]{,1} [ data == CB ] // PSE_END Specify constraints by a certain language Interface specification language

167 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 167 Category of I/F Spec. Languages Verification languages e, VERA, TestBuilder, … Special syntax in HDLs or system description languages SystemC, SpecC, VHDL+, … Dedicated languages for I/F specification OwL, CWL, …

168 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 168 Design supportVerification support Design and Verification Support I/F specification Sim. pattern generation Checker generation Coverage criteria I/F Synthesis Spec. sheet generator

169 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 169 Verification Support (1) Checker generation Input constraint checker that rules out invalid transactions Output checker that checks consistency to specification Module Error

170 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 170 Verification Support (2) Simulation pattern generation Random pattern generator in conformance with input constraints Module Good pattern

171 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 171 Verification Support (3) Abstraction level converter for verification scenarios Conversion between transaction-level and signal-level scenarios* * e.g. TestBuilder TVM generator Comparison do { wait(); } while (!grant); m1.write(d); Scenario Module Level converter

172 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 172 Example of I/F Specification Language CWL (Component Wrapper Language) Jointly developed by Hitachi and Fujitsu Hierarchical description aimed at abstraction level conversion Support for split transactions Support for useful interface patterns Arrays FIFOs Priority queues

173 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 173 Hierarchical Description: Base signalset all = {clk,rst, en, ad,wait,dt}; N : { R, 1, 1, x, 1, x}; I : { R, 0, x, x, 1, x}; Q(a): { R, 1, 0, a, 1, x}; W : { R, 1, 1, x, 0, x}; S(d): { R, 1, 1, x, 1, d}; endsignalset signalset all = {clk,rst, en, ad,wait,dt}; N : { R, 1, 1, x, 1, x}; I : { R, 0, x, x, 1, x}; Q(a): { R, 1, 0, a, 1, x}; W : { R, 1, 1, x, 0, x}; S(d): { R, 1, 1, x, 1, d}; endsignalset clk rst en ad[9:0] wait dt[7:0] I I N N Q(a) W W W W S(d) a d N N

174 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 174 Hierarchical Description: Transaction word; nop : N ; reset : I ; read(a,d) : Q(a) W* S(d) ; endword word; nop : N ; reset : I ; read(a,d) : Q(a) W* S(d) ; endword reset clk rst en ad[9:0] wait dt[7:0] nop read(a,d) nop INQ(a)WWS(d)N a d

175 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 175 Hierarchical Description: Sentence sentence; reset [ nop | read ]+ ; endsentence sentence; reset [ nop | read ]+ ; endsentence clk rst en ad[9:0] wait dt[7:0] sentence resetnop read(a,d) nop INQ(a)WWS(d)N a d

176 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 176 Split Transactions sentence; INITIAL: reset; FOREGROUND: read; BACKGROUND: nop; endsentence sentence; INITIAL: reset; FOREGROUND: read; BACKGROUND: nop; endsentence INNQ1Q1 Q2Q2 S1S1 Q3Q3 S2S2 S3S3 reset nop read 1 read 2 read 3

177 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 177 Summary Interface specification is crucial in module verification Design and verification support from I/F spec. Activities in I/F specification languages

178 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 178 Techniques for System Verification

179 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 179 Symbolic Simulation and Symbolic Trajectory Evaluation (S. Chakraborty)

180 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 180 Symbolic Simulation Conventional simulation Combinational circuits: Output for a given set of inputs Sequential circuits: Output for a given initial state and sequence of inputs Inputs and initial state are specified constants Output is also a constant # Constant input combinations too large! Alternative approach Allow symbolic variables as inputs and initial state Compute outputs & states as symbolic expressions

181 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 181 Symbolic Simulation A symbolic expression represents a set of values Inputs: x = a, y = b, c = b Output: f(x,y,z) = a + b represents set of values at output on applying 001, 010, 101 and 110 to inputs Result of multiple simulations in one pass Examine expression for outputs to see if desired property is satisfied a, 1, a a, b, a + b Sequential Circuit F1(a,S), F2(a,b,S), F3(a,b,S) Initial state S Primary outputs G1(a,S), G2(a,b,S), G3(a,b,S) Next states

182 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 182 Low-level Symbolic Simulation Symbolic simulation at gate and MOS transistor level Variables can take value {0, 1, X} X represents an unknown state of the signal Boolean functions extended to operate on {0, 1, X} AND(0, {0,1,X}) = {0} AND(1, {1,X}) = {1,X} AND(X, {X}) = {X} Common use of X: Representing uninitialized state variables Outputs can be checked to see if desired value appears Simulators: COSMOS, Voss, Innologic, Intel Labs

183 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 183 Low-level Symbolic Simulation {0, 1, X} encoded in binary Two binary variables used to represent each symbolic variable Extend operations to pairs of binary variables AND( (a,b), (c,d) ) = (AND(a,c), AND(b,d)) Each signal value now represented using two BDDs Generalizing, a vector of BDDs encodes a symbolic expression Operation on symbolic expressions = Operation on BDD vectors 0: 00 1: 11 X: 01

184 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 184 High-level Symbolic Simulation Variables: boolean, bitvectors, int, reals, arrays … Operations: Arithmetic, logical, bitvector operations Uninterpretted functions, equality, disequality Final expression contains variables and operators Decision procedures needed to check whether final expression is as desired Final expressions can also be manually checked for unexpected terms/variables, flagging errors -- e.g. in JEM1 verification [Greve 98]

185 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 185 High-level Symbolic Simulation Manipulation of symbolic expressions done with Rewrite systems like in PVS Boolean and algebraic simplifiers along with theories of linear inequalities, equalities and uninterpretted functions Extensively used along with decision procedures in microprocessor verification Pipelined processors: DLX Superscalar processors: Torch (Stanford) Retirement logic of Pentium Pro Processors with out of order executions JEM1 (no decision procedures used)...

186 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 186 Symbolic Trajectory Evaluation (STE) Trajectory : Sequence of values of system variables c = AND (a, b) and delay is 1 A possible trajectory : (a,b,c) = (0, 1, X), (1, 1, 0), (1, 0, 1), (X, X, 0), (X, X, X) and so on Express behavior of system model as a set of trajectories I and express desired property as a set of trajectories S Determine if I is inconsistent with S Inconsistent: I says 0 but S says 1 for a signal at time t Consistent: I says 0 but S says X or 0 for a signal at time t

187 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 187 STE Several success stories with STE Verification of memories, TLBs in Power PC Verification of instruction length decoder in Intel x86 architecture Verification of Intel FP adder Microprocessor verification,... Enables efficient analysis of much larger state spaces than symbolic model checking However, properties that can be checked are restricted compared to CTL

188 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 188 Hybrid Verification (S. P. Rajan)

189 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 189 Hybrid Verification Formal Verification using Theorem Proving + Model Checking (PVS) PVS = Prototype Verification System (SRI International) Tight integration of theorem prover and model checker

190 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 190 Hybrid Verification Model Checker BDD Arith Rewriter Hardware Specification Properties to be Verified Decision Procedures data-structures Model-Check Simplify Rewrite Assert Basic Decision Procedures

191 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 191 PVS System Overview Powerful specification language Based on typed-higher-order logic Can express VHDL/verilog specifications Parametric specifications Combines theorem proving and model checking (using BDDs) Currently, there is no tool that can match PVS in the combined features of specification & verification

192 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 192 PVS System Overview Decision procedures including BDDs and model- checking in PVS Support for verification strategies and quick proof prototyping Support for quick debugging: theory extensions on the fly PVS used to verify commercial designs (AAMP-5, Rockwell Collins)

193 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 193 PVS Drawbacks Developing semi-automatic proof strategies difficult Large designs might challenge PVS resource usage VHDL/verilog to PVS translators yet to be developed (significant effort needed)

194 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 194 Emulation (Subir K. Roy)

195 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 195 Emulation Systems Systems using hardware emulators to do physical prototyping. Hardware emulators : Specially designed h/w & s/w systems using reconfigurable h/w such as FPGAs. Implements a design by mapping it to these FPGAs, which are mounted in fixed arrays on PCBs in a dedicated piece of equipment that communicates with the design environment. Prototype Design – Checked for functional correction In Circuit Emulation - Emulator can also be connected to target system.

196 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 196 Emulation Systems Emulation justified when Absolute real time performances not required Simulation is extremely slow Design complexity significant Few bugs related to system integration remain Though accelerates simulation runs, debug and design iterations can be long due to setup costs. Usually follows static functional verification of modules. Emulation requires an additional design flow

197 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 197 FPGAs as logic emulators ~ Several trillion gate evaluations/sec. Efficient high end synthesis tools available. Multiple FPGA board architectures give >5 million gates (can be extended to 10 –15 million gates) – Can target entire SoC designs. Same architecture can be re-used for other designs. Programmable interconnect makes it possible to achieve optimal mapping of partitioned RTL behaviors to different FPGAs. Can be tested by ICE or by test vectors.

198 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 198 Import Netlist Generate Memory Clock Analysis Constraint Design Partition System Setup Vector Translation Vector Debugging ICE Setup Target Interface Logic Analyzer Setup Verilog RTL Code Behavioral Simulation Netlist Synthesis Gate Level Simulation Emulator Environment In Circuit Emulation Error Emulation Flow

199 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 199 Total Emulation System PC Target Board Clock Source Power Host Target Interface Module ViewStore WorkStation Emulation Hardware Target System LAN

200 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 200 Emulation Systems - Major components Hardware in emulation box Multiple PCBs & specialized parallel architecture around FPGAs/board. 1 CPU/board : Hyb. Emln, Behav. Test Bench Interconnect : Programmable Crossbars, Nearest Neighbor Time Multiplexing I/Os. Memories : SRAMs, DRAMs, SDRAMs Target Interface h/w : ICE cable & interface. Logic Analyzer or specialized h/w to capture o/p response.

201 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 201 Emulation Systems - Major components Software Specialized compiler/synthesizer for mapping flattened RTL/gate netlists to emulation hardware. Mapper uses Multiway, Multilevel partitioning s/w to Multi-FPGA, Multi-Board emulator target architecture. Specialized timing analysis for clocking issues related to Multi-FPGA mapping. Execution software.

202 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 202 Emulation Systems - Drawbacks Expensive & Proprietary hardware. Additional Design flow High designer skill in vendor specific tools. Design iterations can be time consuming. Requires high performance workstations On board memories require logic wrappers. DRAMs & SDRAMs impose proper refresh strategies at lower emulation speeds Needs careful attention to setup & hold times when exercising test vectors.

203 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 203 Emulation Systems - Drawbacks (contd.) Data buffers susceptible to overruns & underruns. Debugging difficult as errors can also arise due to data interfaces to emulation model. Proprietary simulator ICE can impose target h/w to be slowed down. Inflexible due to interconnect architecture. SoCs will be limited by interconnect capacity. Facing competition : Simulation farms, Cheaper Rapid Prototyping Systems.

204 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 204 Commercial Emulators [Butts & Keutzer,99] Cadence/Quickturn Mercury : 10M gates, Xilinx FPGA, Two level time multi-plexed crossbar interconnect, PowerPC/board (Verilog h/w accelerator). IKOS VirtualLogic : 5M gates, Xilinx FPGAs, Nearest neighbor time multiplexed interconnect (Virtual Wires), Compiler analyzes clock trees to synchronize time multiplexing. Axis Excite : FPGAs on PCI cards, Tightly coupled to proprietary Verilog simulator.

205 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 205 Quality of Verification (Subir K. Roy)

206 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 206 Quality of Verification Motivation Has verification been done comprehensively? All expected behavior excited & observed? Compare runs based on different approaches. Semi-Formal (Simulation + Model Checking) Stopping criteria (Intelligent Simulation) Formal (Model Checking) Adequacy of set of properties?

207 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 207 Coverage Metric - Informal Coverage Metric helpful in detecting Useful structures in a design Useful classes of behavior Classification : Based on abstraction and level of design representation [Dill, Tesiran, ICCAD 99]. Code (HDL code) Circuit structure (Netlist) State space (STG) Functional (User defined tasks) Specification (Executable)

208 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 208 Coverage Metric - Informal Different Coverage Metrics : Branch Expression FSM Arc Functional Hardware Code Path Signal Statement Toggle Triggering

209 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 209 Coverage Metric - Informal Desirable Qualities [Dill, Tesiran, ICCAD 99]. Direct correspondence between metric & design errors or bugs. Tolerable computational overhead to measure coverage Reasonable analysis overhead Data interpretation High Coverage Stimuli generation

210 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 210 Coverage Metric - Semi-formal Informal Coverage Metrics – Ad-hoc. Is it possible to formalize metrics for certain classes of designs? Semi-formal [Gupta et. al. DAC 97] Mixes formal verification and simulation approaches. Generate : Test model - Simple ( Formal Ver- ification). Implementation model - Complex (Simulation) Use FV to drive test set (test vector seqs.) Coverage : Defined on Test model.

211 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 211 Coverage Metric - Semi-formal Can coverage on test model be translated into good coverage on implementation model? Coverage of design behavior Coverage of design errors Guarantees w.r.t. completeness of validation. Test model derived from Implementation model through abstraction of data path & control part. Can this be made more precise? Gupta et. al. show under a reasonable set of assumptions one can define metrics formally.

212 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 212 Coverage Metric - Semi-formal New Coverage Metric(TTM) : Based on Transition Tour on test model Transition Tour : A test set that covers each transition in a FSM. Transition tours can catch all errors if there exists an input which produces a unique output in each state, & causes the FSM to stay in the same state. Test model based on Mealy machine. Test generator – Uses FV techniques to traverse reachable state space for desired target coverage.

213 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 213 Coverage Metric - Semi-formal Limitation : Does not cover all sequences (path coverage). Not all errors exposed. Transition tour metric can excite errors, but may not expose errors. Complete test set generation rules Application TTM used in processor verification General Purpose Processors Digital Signal Processors Case Study - DLX RISC Processor.

214 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 214 Coverage Metric - Formal Formal Verification : Is system correct with respect to a specification? How complete is the set of specification? Coverage Metric captures relevance of different parts of the system for the verification process when modifications are effected in the System Under Verification (SUV) What does it mean for a specification Φ to cover a system/circuit S? Does Φ describes S exhaustively?

215 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 215 Coverage Metric - Formal Intuitively, uncovered part of S amenable to modification without falsifying Φ in S. Different definitions of coverage implies different ways in which parts of S can be modified. Captures errors in the modeling of a system Vacuous satisfaction of specification Captures errors in validity of specification Sanity checks for constraint validation (Eg. Enabling conditions, Variable values & usage).

216 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 216 Coverage Metric - Formal Completeness of Specifications Erroneous behavior not caught if no spec captures this behavior Fully describe all possible behavior of system Check if system contains redundancies Simplify system Analyzing coverage in MC can find portion of design not relevant for verification to succeed. Coverage check – Feedback mechanism.

217 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 217 Coverage Metric - Formal Approaches in Temporal Logic MC [Katz et. al., 99] Compare SUV with Tableau of spec Φ [An abs- tract system satisfying Φ and subsuming all behavior allowed by Φ.] Detects portions irrelevant to satisfaction of Φ : Behaviors indistinguishable by Φ & those allowed by Φ but not generated by SUV Drawbacks : Imposes severe restriction on system & its tableau, Supports only ACTL

218 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 218 Coverage Metric - Formal [Hoskote et. al., DAC 99] Coverage : Effect of modi- fications in system on satisfaction of the specs. Given, System : Modeled by a Kripke Structure, K; Spec, Φ : A formula satisfied in K; q : Signal; w : A state in K. Defn. : w in K is q-covered by Φ if K' derived from K by flipping value of q in w no longer satisfies Φ. q-cover(K, Φ) : Set of states q-covered by Φ in K. CM Computation : Naïve – Perform model checking of Φ in K' for each state w of K. {Acceptable ACTL }.

219 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 219 Coverage Metric - Formal [Chockler et. al., CHARME 2000]: Distinction bet- ween ways to model a system. State based : Design Level (Hoskote et. al.)-System modeled as a circuit with state space. Logic based : Implementation Level - Signal value fixed to 0, 1, or X everywhere, then model check for satisfaction of Φ. Closed system : No env. inputs (Kripke Structure). Open System : Inputs from environment + Outputs supplied by system to environment; Modeled by sequential machines; Coverage metric w.r.t. o/ps.

220 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 220 Coverage Metric - Formal Coverage Metric Computation Naïve approach : Find set of covered states (state based approach), or set of covered signals (logic based approach) by model checking every modified system. Alternative approaches Find uncovered parts of system Utilize overlaps among modified systems: Each modification involves small change in system.

221 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 221 Coverage Metric - Formal Presentation of Output : What do we do after we detect portions of system (or circuit) S that are not covered w.r.t. a signal x? Compute : X = {x-cover(S, Φ) / for several x in O}; Coverage = | x-cover(S, Φ) | / |States in S|. Analysis : Is x-cover(S, Φ) empty? - Implies vacuity (X can be used for generating uncovered computa- tions). s in S not in x-cover(S, Φ)?- Implies Φ fails to distinguish between S & S; Implies errors arising out of erroneous values of signal x in s are not captured by spec.

222 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 222 Coverage Metric - Formal Advantages Applicable to full CTL. CM not sensitive to abstraction. CM is compositional Drawbacks Complexity of computing CM much greater than that of model checking.

223 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 223 Academic & Research Lab Verification Tools

224 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 224 Verification Tools – 1 (S. Ramesh)

225 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 225 Verification tools A large number of tools exist Exhaustive review impossible For a comprehensive list and details: Formal Methods Home Page: http://www.comlab.ox.ac.uk/archive/formal- methods.html Centre for Formal Design and Verification of Software (CFDVS) at IIT Bombay http://www.cfdvs.iitb.ac.in BRIEF review of a VERY FEW model-checking tools in order now!

226 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 226 VIS VIS Home page: http:// www-cad.eecs.berkeley.edu/ Respep/Research/vis/ Verification Interacting with Synthesis. A research prototype tool (Proof of Concept) U. California, Berkeley (Brayton et. al.) U.Texas, Austin, U.Colorado, Boulder VIS integrates verification, simulation and synthesis of finite state HW system.

227 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 227 Modeling Language A subset of Verilog VHDL and Esterel planned The back-end language is BLIFF-MV Specification Language CTL, CTL* and Automata

228 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 228 Verification Symbolic Model Checking Language Emptiness Check Equivalence Checking of Combinational designs Speciality: Simulation and Synthesis Various representations of Boolean functions (BDD, MDD, etc.) variable ordering heuristics

229 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 229 Specification Examples AG ((bit[0] = 1) AX (bit[0] = 0)) Flipping of the zeroth bit in a counter. AG ((Req = 1) AF (Ack = 1) ) Every Req is greeted with an Ack eventually AG (EX:5 (State = TRST)) Always state TRST is reached in 5 steps.

230 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 230 SMV Home page: http://www-cad.eecs.berkeley.edu/ kenmcmil/smv/ Experimental Research tool from Cadence Berkeley Labs. (McMillan) Originally from CMU (McMillan's Ph.D.thesis) Modelling Language: Interacting State Machines, Synchronous Verilog Specification Language: CTL, LTL Verification Approach: Symbolic Model Checking Compositional and Symmetry-based Verification Strategy

231 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 231 Modeling language Interacting state machines synchronous and asynchronous concurrency allow modular and hierarchical description of finite state systems finite data types: Booleans, scalars, fixed arrays

232 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 232 Examples: 1. MODULE MAIN VAR request : boolean; state : {ready, busy} ASSIGN init(state):=ready; next(state):=case state=ready&request: busy 1 : {ready,busy } ; esac; SPEC AG (request ® AF state = busy)

233 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 233 Examples: 1. Old Syntax `request' unconstrained (input) non-deterministic assignment OBDD representation of tr. reln. constructed and SMC performed.

234 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 234 Example - 3bit counter MODULE main VAR bit0 : counter cell(1); bit1 : counter cell(bit0, carry-out); bit2 : counter cell(bit0, carry-out); SPEC AG AG bit2. carry-out MODULE counter cell(carry-in) VAR value : boolean; ASSIGN init(value) :=0; next(value) := value+carry-in mod 2; DEFINE carry-out : = value & carry- in

235 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 235 Example - 3bit counter Assign sections of bit0, bit1 and bit2 execute in parallel Data dependence respected

236 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 236 FC2toolset Home page: http://www-sop.inria.fr/meije/verification/ Automatic Verification of Finite State Communicating systems Form the basis for Esterel verification Developed at INRIA and Ecole de Mines, Sophia Antipolis Based upon process algebra notation Modeling Language: CSP/CCS, Esterel (Xeve tool) Specification language: abstract state machines

237 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 237 Verification Approach Comparison of specification machine with the model after abstraction: use of Observational Equivalence, Symbolic Bisimulation Compositional Minimization and Abstraction A very powerful notion of abstraction (re-labeling complex sequence into a single label) Explicit and BDD representation of state machines

238 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 238 Example DLX Controller An Esterel model 100s of states abstracted using FC2tools:

239 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 239 STeP Homepage : http://rodin.stanford.edu/ Stanford Temporal Prover Interactive theorem proving tool for verification of concurrent and reactive systems Combines model-checking and deductive approaches and verifies parameterized(N-component) circuit designs parameterized(N-process) programs and programs with infinite data-domains

240 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 240 STeP Modeling Language: SPL and fair Transition Systems Specification Language: LTL and First Order Logic Verification Approach: Theorem Proving and Model-checking

241 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 241 STeP overview Temporal Logic Formula Reactive System (SPL) Program Hardware Description Model Checker Fair Transition System Automatic Prover Verification Rules Bottom-up Invarient Generator Strengthening of Invariants Propagation First-order Prover Simplification Decision procedures P- validCounter example P- validDebugging Guidance Interactive Prover User

242 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 242 Verification in STeP Very powerful theorem prover Automatic Invariant Generation, Collection of Simplification rules Decision procedures for linear arithmetic, arrays, bit vectors, etc. Generation of Verification Conditions BDD simplification Rich set of tactics and tacticals

243 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 243 An example SPL Program main :: [ in a : int where ((a 127) ^ (a > - 128)) in b : int where ((b - 128)) out c, d : int if (a > 0 ^ b > 0) then [ if (a > b) then [ 12 : skip;c:= a-b] else [ 13 : skip;c:=b-a] ] else if (a < 0 ^ b <0) then [ 14:skip;c:= -(b + 1)] else [15: skip; c:=a + b ] ]

244 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 244 Specification file SPEC PROPERTY P1 : l2 ((a – b) 127 ) ((a – b) - 128) PROPERTY P2 : l3 ((b – a) 127 ) ((b – a) - 128) PROPERTY P3 : l4 (-(b + 1) 127 ) (-(b + 1) - 128) PROPERTY P4 : l5 ((a + b) 127 ) ((a + b) - 128)

245 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 245 Examples Leader-Election algorithms Needham-Schroeder Security protocol Ricart and Agrawala's mutual exclusion algorithm Bus scheduler verification http://rodin.stanford.edu/case-studies/index.html

246 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 246 Verification Tools – 2 (S. P. Rajan)

247 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 247 Fujitsus High-Level Model Checking Tool A high-level symbolic safety property checker based on Stanford Validity Checker (SVC) decision procedures Has a state-transition input language that extends SVC expression syntax Provides code to translate XE VHDL synthesis tool's ADDs into HMC input HMC has been applied for verification of portions of Fujitsu ATM switch specified in VHDL

248 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 248 HMC Basics: Pre- and Back-Image Representing sets and relations with their characteristic functions: PreImage[Q] = s. s. R(s,s') And Q(s') PreImage corresp. to EX Q in CTL. BackImage [Q] = s. s. R(s,s') => Q(s') BackImage (aka. Weakest Precondition) corresp. to AX Q in CTL.

249 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 249 Basics: Fixpoints and Safety Properties Z 0 = Q Z i+1 = Q And BackImage [Z i ] If [ k. Z k = Z k+1 ] then [Z k = Z. (Q And BackImage [Z])] This fixpoint corresp. to AG Q If initial states Q 0 is a subset of Z k, then Q is a safety property. Otherwise, a counterexample trace exists, starting in Q 0 \ Z j, where Z j is the first Z i s.t. Q 0 is not a subset of Z i

250 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 250 HMC: Data-Type and Expression Support Quantifier-free first order logic with linear arithmetic and uninterpreted functions Built-in theories in SVC: uninterpretted functions under equality, linear arithmetic, stores, records, bitvectors. Approach equally applicable to other decision procedures.

251 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 251 VeriSoft from Lucent Bell Labs A New Model Checking approach. A New Approach to Communication Software Analysis What is VeriSoft? How does it work? Industrial applications. Related work and discussion. Project status and conclusions.

252 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 252 What is VeriSoft? Concurrent Reactive System Analysis Each component is viewed as a ``reactive'' system, i.e., a system that continuously interacts with its environment. Precisely, we assume: finite set of processes executing aribitrary code (e.g., C, C++, Java, Tcl,...); finite set of communication objects (e.g., message queues, semaphores, shared memory,...).

253 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 253 What is VeriSoft? (contd.) Problem: Developing concurrent reactive systems is hard! (many possible interactions); Traditional testing is of limited help! (poor coverage); Scenarios leading to errors are hard to reproduce! Alternative: Systematic State­Space Exploration

254 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 254 How does VeriSoft work? VeriSoft looks simple! Why did we have to wait for so long (15 years) to have it? Existing state­space exploration tools are restricted to the analysis of models (i.e., abstract descriptions) of software systems. Each state is represented by a unique identifier.

255 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 255 How does VeriSoft work?(contd.) During state­space exploration, visited states are saved in memory (hash­table, BDD,...). With programming languages, states are much more complex! Computing and storing a ``unique identifier' for each state is unrealisitc!

256 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 256 State­Less Search Idea: perform a state­less search! still terminate when state space is acyclic Equivalent to ``state­space caching'' with an empty cache: this search technique is terribly inefficient! [H85,JJ91]

257 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 257 An Efficient State­Less Search [GHP92]: Redundant explorations due to state­ space caching can be strongly reduced by using Sleep Sets [G90], and ``partial­order methods'' in general [G96]. VeriSoft: original algorithm combining state­less search, sleep sets [G90,GW93], conditional stubborn sets [V90,GP93,G96].

258 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 258 An Efficient State­Less Search(contd.) Theorem : For finite acyclic state spaces, the above algorithm can be used for the detection of deadlocks and assertion violations without incurring the risk of any incompleteness in the verification results. Observation : When using this algorithm, most of the states are visited only once during the search. Not necessary to store them!

259 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 259 VeriSoft -- Summary VeriSoft is the first tool for systematically exploring the state spaces of systems Composed of several concurrent processes executing arbitrary (e.g., C or C++) code. Originality: Framework, Search, Tool [POPL'97]. The key to make this approach tractable is to use smart state­space exploration algorithms! In practice, the search is typically incomplete. From a given initial state, VeriSoft can always guarantee a complete coverage of the state space up to some depth.

260 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 260 Industrial Applications Examples of Applications: (within Lucent Technologies) 4ESS Heart­Beat Monitor analysis (debugging, reverse­engineering). Wavestar 40G integration testing (testing). Automatic Protection Switching analysis (interoperability protocol testing).

261 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 261 Conclusion VeriSoft (tool + approach) can find bugs in nontrivial concurrent/reactive software system. 1. Concurrent/reactive/real­time software is hard to design and test. 2. Traditional testing techniques are not adequate (poor coverage, lack of observability and controllability). 3. Systematic testing using an approach specially developed for detecting race conditions and timing issues can rather easily expose previously unknown bugs.

262 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 262 Case Studies

263 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 263 Case Study 1 (S. P. Rajan)

264 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 264 Motivation: Real Buggy Chip Bug identified in a real chip design ATM Switch: 156 MHz, 111000 gates. (B. Chen, M. Yamazaki, and M. Fujita) Field test showed abnormal behavior after several seconds Data disappeared/duplicated Simulation prohibitively expensive (100 million cycles required)

265 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 265 Motivation: State Explosion Formal Verification to find bugs Symbolic Model Checking using SMV for control- block verification State-space explosion (large datapath) Abstraction to reduce state-space

266 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 266 Motivation: Abstraction Expensive Too much abstraction revealed no bugs - 8 bit to 1 bit; Single module verification Trial-and-error method to come up with right abstraction: 8 bits to 2 bits Bug revealed: Reset incomplete! Coming up with right abstraction: Tedious

267 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 267 Motivation: Design Change Changes in design require revalidation Revalidation expensive TAT too long Design cycle cost expensive

268 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 268 Typical ATM Switch Fabric 2 x 2 Switch

269 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 269 ATM Switch Architecture HW_clk|SW_clk: Multiple Clocks Cell FIFORAF0 RAF1WAF S/P P/S Write Control (WC) Read Control (RC) Cell Counter (wBC) Copy Cell Flag ccf iHW0/1 oHW0/1

270 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 270 ATM Switch Highlights 2 X 2 switch multiple clocks: faster external HW_clk; slower internal SW_clk 1 cell-buffer shared by 2 ports address-FIFO for supplying cell addresses addresses recycled

271 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 271 ATM Switch: Generic Parametric description Modification of existing fixed parameter high- level description in VHDL Parametrized the external/internal clock ratio: synthesized designs with specific ratios by simple instantiation

272 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 272 ATM Switch Generic Parametric Description Parametrized the number of switch input/output ports: synthesized designs with specific number of ports by simple instantiation Parametrization of cell-buffer size also possible Reusable generic model

273 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 273 Complexity of Design Spec ~ 20 Communicating Processes ~1500 lines of VHDL code at high-level ~20000 lines of VHDL at gate-level after synthesis

274 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 274 Behavior Partitioning Partitioning based on clock: Faster HW_clk; slower SW_clk functionality: Serial/Parallel (S/P); Write Control (WC); Read Control (RC) throuput requirement: pipeline latency Modeling: VHDL process for partition wait until clk = 1 for control step Define interface between partitions eg: clk conversion in S/P & P/S

275 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 275 Generic ATM VHDL Model entity: atm_sw is begin generic ( n: integer, -- ext/int clk ratio m: integer -- number of input/out ports ); port (... ); end atm_sw

276 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 276 SP conversion module 1: VHDL iHW_sp1: process begin for i in 1 to n loop iHW_bword(1)(i) <= iHW_cell_word; if i = 1 then... elsif i = n then iHW_cycle_counter <= iHW_cycle_counter (n downto 2) & '1';... endif; wait until (HW_clk'event and HW_clk = '1'); end loop; end process iHW_sp1; Stores the incoming word and updates cycle counter

277 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 277 SP Conversion Module 2: VHDL iHW_sp2: process begin for i in 2 to n loop... iHW_bpc(i) <= iHW_bpc(i-1); for j in 1 to n loop iHW_bword(i)(j) <= iHW_bword(i-1)(j); end loop; wait until (HW_clk'event and HW_clk='1'); end loop; end process iHW_sp2; Shifts contents of registers by one place

278 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 278 SP conversion module: VHDL model to_FIFO: process begin... for j in 1 to n loop iHW_word(j) <= iHW_bword(index-1)(j); header_parity_check := bit_or(iHW_bpc(j)); end loop; wait until (sw_clk'event and sw_clk='1'); end process; The proper word is fetched to the FIFO from the shift-register

279 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 279 Synthesis: Generic Clock Ratio Clk Ratio Ports Nets Cells Area (bc) delay (ns) 3 4 5 6 118 59362 52243 93580 223 62578 55259 97506 223 66245 58688 102208 223 69203 61376 107484 223 u Area and delay of synthesized ATM switches different clock ratios u Fujitsu CS35R technology u Number of ATM input ports = 2 and ouput ports = 2

280 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 280 Synthesis: Generic Clock Ratio Clk Ratio Ports Nets Cells Area (bc) delay (ns) 3 4 5 6 118 59362 52243 93580 223 62578 55259 97506 223 66245 58688 102208 223 69203 61376 107484 223

281 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 281 Synthesis: Generic number of in/out ports u Area and Delay of Synthesized ATM Switches u Varying number of input/output ports u Fujitsu CS35 technology u Clock ratio = 3

282 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 282 Formal Verification u Overall correctness property - Input cells switched to proper output ports,- The order of input cells is maintained at the output. u ATM is a complex design:-- Compositional verification technique: verify ATM modules separately and compose u Verification of the generic parametric model automatically implies the verification of a family of ATM designs

283 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 283 Formal Verification : Bugs found u Address pointers to WAF not initialized to 0 u Analysis by model checking in PVS u Mistake due to hidden assumptions in synthesis u Counter-example generated u Combined with other verified modules

284 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 284 SP conversion: PVS Spec sp_conversion_theory[n: posnat]: THEORY BEGIN IMPORTING signal,signal[n], bitvectors@bv_extractors,... register_array: TYPE = ARRAY... iHW0_bword: [nat -> register_array] iHW0_cell_word: signal[16] forloop0(t,i,n): bool = % i indexes rows ….

285 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 285 SP conversion: PVS Spec …... iHW0_bword(t)(0,i) = iHW0_cell_word(t) AND IF n > 1 THEN (i = n-1 IMPLIES iHW0_cycle_counter(t+1) = iHW0_cycle_counter(t)^(n-1,1) o b1) ELSE iHW0_cycle_counter(t+1) = b1 ENDIF END sp_conversion_theory

286 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 286 SP Conversion: PVS Spec loop0(t,i,m): RECURSIVE bool = IF i = n THEN TRUE ELSE iHW0_cycle_counter(t) = bvec0 AND (forloop0(t,i,n) AND loop0(t+1,i+1,n)) ENDIF MEASURE n-i sp(0,n) =... to_fifo(n,n) =... VHDL to PVS translation non-trivial

287 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 287 SP Conversion:Formal Verification theorem2: THEOREM % When clk rising edges are synchronized FORALL (n:posnat):FORALL (i:nat|i { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.com/1458021/4/slides/slide_286.jpg", "name": "ASPDAC / VLSI 2002 - Tutorial on Functional Verification of SoCs 287 SP Conversion:Formal Verification theorem2: THEOREM % When clk rising edges are synchronized FORALL (n:posnat):FORALL (i:nat|i

288 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 288 SP Conversion:Formal Verification Finaltheorem: THEOREM % When clk rising edges need not be synchronized FORALL (n:posnat): FORALL (i:nat|i { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.com/1458021/4/slides/slide_287.jpg", "name": "ASPDAC / VLSI 2002 - Tutorial on Functional Verification of SoCs 288 SP Conversion:Formal Verification Finaltheorem: THEOREM % When clk rising edges need not be synchronized FORALL (n:posnat): FORALL (i:nat|i

289 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 289 Address Recycle Verification Theorem : FORALL (t: time), (ptr: {ptr: address_type | RAF0_tptr(t) <= ptr AND ptr <= RAF0_hptr(t)}): whileloop(t) AND more(t) AND RAF0_hptr_tptr_update(t) AND RAF1_hptr_tptr_update(t) IMPLIES iHW0_write_addr(t) /= MEM(t)(ptr)

290 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 290 Address Recycle Verification Symbolic Model-Check proof strategy in PVS used Theorem not proved Counter-example evident from the proof script 19 Seconds cpu time on Sparc-20 / 32 Meg

291 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 291 Address Recycling: Bug Found WAF_hptr and WAF_tpr not initialized to 0 Bug found easily by model checking original VHDL description in an integrated theorem proving and model checking framework Another error suspected in cell buffer update

292 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 292 Conclusions Introduced formal verification early in the design cycle to remove bugs Serious bugs found in initialization related to address recycling High-level parametric validation reduces cost of formal verification: small-scale gate-level validation suffices for sign-off Drastic reduction in cost and time-to- market

293 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 293 Case Study 2 [Formal meets semi-formal ] ( T. Nakata)

294 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 294 Outline Target design: media instruction unit (MU) of a VLIW multimedia processor core Verification strategy: divide-and-conquer Right tool in the right place Specification language Formal verifier Semi-formal verifier Logic simulator

295 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 295 I/F specification Pattern/property gen. Checker DRAMI/O GDC MPU ROM DSP Divide-and-Conquer Verification Isolate a module using formal I/F specification Verify a module by integrated verification tools Module I/F Integrated verification engine Module

296 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 296 Verification Tools Interface specification toolkit (in-house) Language based on regular expression Pattern/property/checker generator Formal verifier (in-house) Model checker Automatic/semi-automatic design abstraction tool Semi-formal verifier 0-In Search & Checkerware Logic simulator

297 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 297 Verification Flow Scenarios Design model Integrated verification engine Design under verification Properties Input constraints Black-box spec. White-box spec. Verification scenario I/F spec. I/F specification language

298 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 298 Verification of MU MU Pipeline for media instruction RTL model: 14,000 lines in Verilog 2,000 registers in total Basic strategy As formal as possible* Semi-formal verification for the whole unit Formal verification for an important unit: instruction decoder * Simulation completed before this attempt

299 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 299 Test pattern Verification of MU (1 st ) MU I/F spec. HDL 41 constraints 4 properties Test patterns augmented by 0-In Search Many design errors detected, but all from input patterns that do not satisfy input constraints Result: Insufficient constraints

300 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 300 Test pattern Verification of MU (2 nd ) MU I/F spec. HDL Test patterns augmented by 0-In Search Pseudo models (I/F spec. lang. and HDL) A known error in interlock logic and an unknown error in decoder detected Result:

301 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 301 Indicator of no hazards e-wait may be asserted under a certain hazard condition Length of augmented* patterns: 7 cycles Detected Error 0x0 xxx 0x0 xxx0xf clock m0_valid m1_valid i0_valid m0_rd m0_rs1 m1_rd i0_rd e_wait 0x0 * By 0-In Search

302 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 302 Summary of MU Verification Flow M-Unit (HDL) M-Unit (HDL) Design database Converter Constraints (I/F spec) Constraints (I/F spec) Properties (I/F spec) Properties (I/F spec) Properties/constraints (HDL+0-In Check) Properties/constraints (HDL+0-In Check) Pseudo (HDL) Pseudo (HDL) 0-In compile Test vectors 0-In Search

303 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 303 Verification of Instruction Decoder Instruction decoder Complete verification required 200 registers Property and constraints Property: detection of unsupported instructions Constraints: valid instructions Described in I/F spec. language (460 lines) Results Two errors detected Correctness proven after revision Model checker

304 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 304 Decoder Verification Flow M-Unit decoder (HDL) M-Unit decoder (HDL) Constraints (I/F spec) Constraints (I/F spec) Properties (I/F spec) Properties (I/F spec) Model checker Note: No abstraction/ reduction required in this example

305 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 305 Statistics Verification team: 3 people Term: 4 months Build specification: 2 months Apply semi-formal verification: 3 months Apply model checker: 2 months Sources for verification Properties (I/F spec. lang.)118 1,818Constraints (I/F spec. lang.) 1,518Pseudo (HDL) 14,320MU (HDL) Lines

306 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 306 Conclusions Interface specification essential For module isolation For a single source for verification tools Formal/semi-formal verification mandatory Serious bugs may leak from simulation Earlier collaboration among designers and verification team will produce better results For extracting good constraints/properties

307 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 307 Commercial Tools (Subir K. Roy)

308 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 308 Commercial Tools Several tools available as commercial offerings. Different approaches taken. Most are based on Simulation Formal Verification Semi-Formal Verification Most support IP-verification re-use (intuitive, but can be formally related to compositional techniques).

309 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 309 Assume & Guarantee - Basic Idea Global Property defined on o2 PQ i1 o2 o1 i2 Decompose PQ o1 i2 o1 i2 AssumptionGuarantee Assumption

310 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 310 Smarter Simulation [Gupta, Malik & Ashar, DAC 97] Test Set Generator Behavioral simulator RTL simulator Test Model Design Implmt (RTL Level Description) Design Spec (Behav Level Description) Function Test Set =? Validation

311 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 311 FormalCheck Model Checking based on COSPAN from Bell Labs Integrated debug environment with back references to HDL source codes Property specification (Queries) based on template approach with user guidance Two reduction technologies for large designs Supports hierarchical + IP + Re-use verification Assumptions stated as constraints on environment using same format as behaviors or properties

312 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 312 FormalCheck Target Blocks System Blocks Interface = = System Properties System Constraints Block Properties Block Constraints

313 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 313 FormalCheck Architecture Gates Query Template Library Query Capture Formal Model Query-Specific Reduction RTL Autorestrict Probabilistic Large Model Early Model Results & Error Traces InputsOutputs Template-Based Query Inputs Chip, Blocks, IP Models In Verilog or VHDL Results Display

314 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 314 Specman Elite - Verisity Simulation & Spec-Based Verification (executable) White Box – Drive & Test Internal Signals On the Fly Test Generation Test Checking is automatic : On the Fly Supports metrics to track progress of verification effort & measure coverage of functional test plan To verify temporal behavior & protocols - Cons- tantly monitors design by sensing for triggers signaling beginning of a sequence and follow it to verify conformance to temporal/protocol rules.

315 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 315 Specman Elite - Verisity New & Powerful temporal constructs to easily specify complex checkers – Less Time Consuming Supports data checks &coverage based feedback mechanism. Allows executable checkers around boundary of IP. Allows checks for arbitrarily complex, mode inde- pendent, multi-cycle scenarios that IP vendor specifies. Allows boundary checks to ensure correctness of integration process.

316 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 316 Specman Elite - Verisity Allows Internal Checks - Provides a handle to the IP integrator to analyze failures in IP after integration. SPEC CONSTRAINTS TEST CONSTRAINTS CONSTRAINT SOLVER HDL SIMULATION Next Cycles Stimulus Protocols I/O Relationships Context Dependencies Input Definition Target Areas Weights/Probabilities Corner Case Tests Structured Sequences Signal & Register Values Current Cycles HDL

317 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 317 Specman Elite - Verisity Bus Functional Model BLOCK Bus Functional Model Monitor & Protocol Checker Monitor & Protocol Checker Monitor & Protocol Checker Coverage Collector Coverage Collector Coverage Collector e-language Verilog

318 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 318 ZeroIn-Search Semiformal verification based on formal techni- ques & simulation -- Sweeps formal techniques through a larger state space by extensively explo- ring around each state in a seed trace. Seed comes from functional simulation test. Two step process Embedded Checkers - written in HDL (No sepe- rate property or assertion language needed) Protocol Checkers - provides verification enviro- nment (reports errors by models stimulating IP)

319 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 319 ZeroIn-Search 0_In Check Tool Instruments the Core/IP/VC with embedded chec- kers automatically based upon comments in RTL code (increases observability & detects bugs at source). 0_In provides CheckerWare Library of checkers for internal design structures & interfaces + pre- verified protocol monitors for standard buses - PCI, PCI-X, Utopia. (Formal techniques try to find new ways to fire embedded checkers.)

320 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 320 ZeroIn-Search More than 50 embedded checkers Checkers for datapath elements, FSMs & other control flow elements, buses and interfaces. Approach finds bugs, not just new coverage. If a checker fires in simulation, then a bug is present. If amplification finds a new way to fire a checker, it detects a bug. Stress tests interface to design interactions. Checkers & monitors track coverage statistics & corner cases.

321 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 321 0_inSearch Verification Flow Verilog RTL with Directives Checker Generator Checker Library Simulation Files with Checkers Verilog Simulator Captured Seed Values Verilog Tests & Test Benches Verilog RTL with Checkers Firing Messages in Verilog o/p Semiformal Amplification Tool Information on New Firings

322 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 322 BlackTie - Verplex Based on Formal Verification Allows full system level integration verification (Multimillion gate capacity tool) Free open source assertion monitor library (Verilog) Simulation (through any Verilog simulator) & For- mal Verification (BlackTie) can operate seamlessly With BlackTie no test vectors, exhaustive coverage, automatic diagnosis.

323 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 323 BlackTie - Verplex Automates checking of global & common place errors. Automatic generation of checkers for, Contention Problems. Asynchronous Clock Domain Crossings Dead-End States Conflicting values loaded to Multi-Port Registers Simultaneous Set & Reset conditions Mutual Exclusivity Checks Tri-state stuck in a particular state.

324 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 324 Issues & Challenges & Future Research Topics

325 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 325 High Level Specification and Modeling (T.Nakata)

326 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 326 Why Specification? Specification errors/misunderstandings take 50% of SoC design man-power. Verification tools cant handle such errors enough. Design man-power for SoCs OthersVerification 70% Simple mistakes Misunderstanding Of Spec. Wrong Spec. Verif. tools Spec. design support

327 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 327 Wrong specification Misunderstanding of specification Issues in Specification and Verification We need: Methodology for specification analysis Standard language with formal semantics Idea and/or requirement SpecificationDesign dataSoC Validation Does specification match requirement? Formalization Is specification defined clearly?

328 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 328 UML UML is: Standard in object-oriented software design Devised and designed under the object-oriented analysis theory A set of diagrams that represent components of a system and relationships among them Modeling a system from multiple angles with use-case/class/object/state/sequence/ activity/collaboration/component/deployment

329 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 329 Object-Oriented Analysis For system architect to understand WHAT to design not HOW Analysis Requirement Interview with customers Docs on existing systems Use-case Scenario Structure Behavior

330 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 330 Analysis Requirement Interview with customers Docs on existing systems Use-case Scenario Structure Behavior UML and Object-Oriented Analysis Use-case Scenario Structure Behaviour Use-case diagram Sequence diagram Class diagram State diagram

331 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 331 Case Study Objectives --- getting answers to: Is object-oriented analysis by UML effective? Is there a way from UML to implementation? Example: error correction with two code types Bit-wise error correction: Code A Word-wise error correction: Code B Claims before analysis Two code types are similar HW implementation cannot be shared though

332 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 332 Error Correction Encoder Decoder Message Systematic code Channel Sent wordReceived word Errors Noise

333 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 333 Analysis and Design Flow Step 1Extract concepts Step 2Build structure Step 3Enumerate scenarios Step 4Identify hardware modules

334 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 334 Analysis and Design Flow Step 1Extract functions Inputs: requirement from users Flow: Find actors that cause stimulus Define use-cases from viewpoints of actors Relate use-cases and actors Output: use-case diagram Step 2Build structure Step 3Enumerate scenarios Step 4Identify hardware modules

335 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 335 Use-Case Diagram of Error Correction Receiver Sender Channel Encode Decode Send Receive Encode B Encode A > Decode B Decode A >

336 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 336 Analysis and Design Flow Step 1Extract functions Step 2Build structure Input: use-case diagram Flow: Refine use-cases Extracting concepts --- candidates of classes Define and relate classes Output: class diagram Step 3Enumerate scenarios Step 4Identify hardware modules

337 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 337 Use-case Refinement Example: decoding code A Refine a use-case with natural language Extract important nouns 1.Calculate syndrome from received word and received code polynomial 2.Judge as no errors detected if syndrome is 0 3.Calculate coefficients of error location polynomial 4.Calculate roots as many as degrees of error location polynomial 5.Correct word by flipping bits designated by roots 1.Calculate syndrome from received word and received code polynomial 2.Judge as no errors detected if syndrome is 0 3.Calculate coefficients of error location polynomial 4.Calculate roots as many as degrees of error location polynomial 5.Correct word by flipping bits designated by roots

338 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 338 Concept Extraction Classifying classes and properties Received word Error location polynomial Coefficient DegreeRoot Decoded wordCode word Message length Syndrome polynomial SyndromeGenerator polynomial Code ParityBlock code LFSR Generator matrixError Galois fieldCode lengthElement Message length Code length Properties rather than classes

339 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 339 Relationships among Classes Code word Code A Code B {Bit-wise} {Word-wise} Code A is a special case of Code B. Data structure is deduced from relationships. Vector Message word Systematic code Code word

340 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 340 Class Diagram Decode Coefficient Root Received word Syndrome Received code polynomial Polynomial Error location polynomial Galois field * * Input

341 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 341 Analysis and Design Flow Step 1Extract functions Step 2Build structure Step 3Enumerate scenarios Inputs: use-case sentences, class diagram Flow: Describe sequence diagrams corresponding to refined use-cases Define methods and properties from sequence diagrams Outputs: sequence diagram, class diagram with methods Step 4Identify hardware modules

342 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 342 Sequence Diagram for Decode r1:received word Input :received polynomial:error location polynomial Generate() IsZero() Calc_coef(s[]) Calc_loc(coef) Correct (location, value) Calc_error(root) Receive Assign(r1) s1: syndrome

343 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 343 Complete Class Diagram Decode Coefficient Root -Code length -Corrections +Correct(loc, val) Received word Polynomial +Assign(val) Galois field +sum() +multiply() +divide() +exp(power) +IsZero() +Order * * Syndrome -Index -Value * Error location polynomial +Calc_coef(syndrome) -Calc_loc(coef) Error loc. poly. for A -Calc_error(root) Error loc. poly. for B -Calc_error(root) Input +Receive() Input for A +Receive() Input for B +Receive() Received code polynomial

344 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 344 Analysis and Design Flow Step 1Extract functions Step 2Build structure Step 3Enumerate scenarios Step 4Identify hardware modules Input: class diagram Flow Correspond methods to hardware modules Define messages from relationships among modules Define interfaces from messages Outputs: class diagram, block diagram (in hardware design context)

345 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 345 Methods to Hardware Modules Disband classes Map each methods to modules Re-bundle modules if possible Galois field +sum()... +IsZero() +Order Error loc. poly. +Calc_coef(syndrome) -Calc_loc(coef) Error loc. calculator Coefficient calculator Galois adder Galois 0 checker

346 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 346 Decode Correction module Assignment module for received poly. Error calculator for Code A Error calculator for Code B Receiver Receiver for Code B Receiver for Code A Coefficient calculator Location calculator Error calculator Syndrome -Index -Value Coefficient Root Error info -Location -Value Received word -Code length -Corrections Galois adder Initial Block Diagram

347 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 347 +received word: input +syndrome: output +clock: input +reset: input +enable: input +received word: input +syndrome: output From Messages to Interface Assignment module for received polynomial Syndrome - Index - Value Received word - Code length - Corrections C++ / HDL HW design

348 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 348 Block Diagram of Decoder Assignment Coefficient calculation Location calculation Correction Code A receiver Code B receiver Error location calculation for Code A enable Error location calculation for Code B

349 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 349 Conclusions Is object-oriented analysis by UML effective? For common understandings For validation For analyses of specification changes Is there a way from UML to HW implementation? For design optimization For verification Already proven in software designs Proven this time (partially)

350 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 350 Verification Issues For simulation-based verification Develop a systematic way to co-verification models Generate corner case scenarios from existing use-cases and scenarios Prioritize verification scenarios for efficient verification For formal verification Build up mathematical model Define important properties for system level designs

351 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 351 Issues & Challenges (S. Chakraborty) (S. P. Rajan)

352 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 352 Where do we stand? Scale (gates) CoverageCoverage 1 FSM 50K 250K 2M Model checking Random simulation Manual test w/ coverage FSM-based generation Symbolic simulation Based on Dill and Tesiran99

353 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 353 Research Issues Fundamental complexity hurdles in scaling formal verification methods with design sizes Approximate verification methods, semi-formal methods will be important tools in future Approximate methods: Model approximations should be driven by property being checked Available computing resources can be used to guide nature of approximation Verification should give some coverage metric on termination Out of memory after 48 hours not of any use!

354 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 354 Research Issues Abstraction of system behavior crucial for analyzing large designs Must employ right degree of abstraction automatically or semi-automatically More research needed Different degrees of abstraction at different levels of hierarchical designs Can this be done automatically? Approximate and semi-formal methods Test of the pudding is on large real examples Most published examples are small A lot of ideas -- no clear winners so far An active area of research

355 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 355 Research Issues With IP based designs, supplier of IP must provide hints on how to verify IP core RTL with assertion checks Hints on exercising combinations of inputs IP verification test suite with coverage metric Formal verification of IP-based SOCs will be challenging Success constrained by verifiability, controllability and observability of IP-core

356 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 356 Research Issues Runtime/memory bottlenecks of existing formal verification methodologies must be addressed to scale them to larger designs Active field of ongoing research Suitable combination of techniques (random simulation, model checking, theorem-proving …) to be selected for each verification task Understanding which techniques work well under what circumstances Can this be automated?

357 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 357 Research Issues Sequential verification still very limited to under 500 latches Concurrent system verification very difficult without abstraction Real-time systems verification not yet practical Formal verification at RTL and above not in the main stream

358 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 358 Future Research Directions How to come up with a verification framework which involves different verification methods cooperating in a single environment? What should be the data structure? Design for Verifiability -- is it viable and practical? How do we integrate formal verification with conventional simulation and testing? How do we integrate verification tools with synthesis tools? How do we generate counter-examples for sequential, concurrent, and real-time systems verifiers?

359 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 359 Summary & Conclusions (S. Chakraborty) (Subir K. Roy)

360 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 360 Summary Formal verification of SOCs has brought hard- core engineers and theoreticians on a common platform Model checking most successful so far Equivalence checking successful in restricted cases, catching up fast The gap between VLSI advancements and advancements in FV techinques can be filled to some extent by semi-formal methods Hard to measure success for such techniques? I might not have detected one out of 100000 bugs, but this might be the killer bug

361 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 361 Summary SOC verification will be an important area in future Simulation and emulation still predominant techniques used in industry and justifiably so However, formal methods ARE NEEDED when applicable and when one cant afford to miss a bug Success stories: Protocols, FSMs, specific processors, floating point arithmetic etc.

362 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 362 Conclusions Functional verification of SoCs critically dependent on verification re-use of Cores/IPs/VCs. Semi-Formal approach based on application of diff- erent combinations of verification technologies seem important. No single approach will suffice. Formal & executable specifications have to be used at all levels of design hierarchy. High degree of automation will be needed to over- come complexities inherent in SoCs. Exciting Area for Research.

363 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 363 Bibliography

364 VLSI/ASPDAC : Tutorial on Functional Verification of SoCs 364 Papers S. Owre and S. Rajan and J.M. Rushby and N. Shankar and M.K. Srivas, PVS: Combining Specification, Proof Checking, and Model Checking, 411-414, CAV96. C.-J. H. Seger, "An Introduction to Formal Verification", Technical Report 92-13, UBC, Department of Computer Science, Vancouver, B.C., Canada, June 1992. Aarti Gupta, "Formal Hardware Verification Methods: A Survey", Formal Methods in System Design, Vol. 1, pp. 151-238, 1992. E. Clarke and J. Wing, Formal Methods: State of the Art and Future Directions, CMU Computer Science Technical Report CMU-CS-96-178, August 1996. A. U. Shankar, "An Introduction to Assertional Reasoning for Concurrent Systems", ACM Computing Surveys, Sept. 1993, Vol 25, No. 3, pp. 225-262. D. Dill, "What's Between Simulation and Formal Verification?", slides from a presentation by Prof. Dill, Stanford University at DAC'98. D. Dill, "Alternative Approaches to Formal Verification (Symbolic Simulation)", slides from a presentation at CAV 1999. M.C. McFarland, "Formal Verification of Sequential Hardware: A Tutorial", IEEE Trans Comput.-Aided Des. Integr. Circuits Syst, Vol 12, No 5, pp. 633-54, May 1993. S. Owre and S. Rajan and J.M. Rushby and N. Shankar and M.K. Srivas, PVS: Combining Specification, Proof Checking, and Model Checking, 411-414, CAV96. D. L. Dill, The Mur Verification System, 390-393, CAV96. T. L. Anderson, Accelerating Bug Discovery with White-Box Verification, Proc. Of DAC 2000.

365 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 365 Papers C. Kern and M. Greenstreet, "Formal Verification in Hardware Design: A Survey", ACM Transactions on Design Automation of E. Systems, Vol. 4, April 1999, pp. 123-193. H. Iwashita and T. Nakata, `` Forward Model Checking Techniques Oriented to Buggy Designs'', Proceedings of ICCAD, pp. 400-404, 1997. K. Takayama, T. Satoh, T. Nakata, and F. Hirose, ``An approach to Verify a Large Scale System-on-a-chip Using Symbolic Model Checking'', Proceedings of ICCD, 1998. S. K. Roy, H. Iwashita and T. Nakata, ``Data Flow Analysis for Resource Contention and Register Leakage Properties'', Proceedings of the 13th International Conference on VLSI Design, January 2000. S. Berezin, S. Campos and E. M. Clarke, ``Compositional Reasoning in Model Checking'', Technical Report - CMU-CS-98-106, School of Computer Science, Carnegie Mellon University, February, 1998. T. Schlipf, T. Buechner, R. Fritz, M. Helms and J. Koehl,``Formal Verification Made Easy'', IBM Journal of Research and Development, Vol. 41, No. 4/5, pp. 567-576, July/September 1997. D. D. Gajski, ``IP-Based Design Methodology'', Proc. of the 36th Design Automation Conference, pp. 43, New Orleans, June 1999. M. Kaufmann, A. Martin, and C. Pixley, "Design Constraints in Symbolic Model Checking", Proc. CAV-98, pp. 477-487, 1998. K. L. McMillan, "Fitting formal methods into the design cycle", Proceedings of the 31st Design Automation Conference, pp. 314-19, 1994.

366 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 366 Papers A. Gupta, S. Malik and P. Ashar, Toward Formalizing a Validation Methodology Using Simulation Coverage, Proceedings of DAC, 1997. S. Devadas, A. Ghosh and K. Keutzer, " An Observability-Based Code Coverage Metric for Functional Simulation, Proceedings of ICCAD, 1996. H. Chockler, O. Kupferman, and M. Y. Vardi, "Coverage Metrics for Temporal Logic Model Checking", TACAS 2001, LNCS 2031, Springer-Verlag, pp. 528-542. Y. Hoskote, T. Kam, P. Ho and X. Zhao, ``Coverage Estimation for Symbolic Model Checking'', Proc. of the 36th Design Automation Conference, New Orleans, June 1999. S. Katz, O. Grumberg and D. Geist, ``Have I written enough properties? - A method of comparison between specification and implementation'', Technical Report, IBM Haifa Research Laboratory, Haifa, Israel, 1999. S. Campos, E. Clarke, W. Marrero and M. Minea, ``Verifying the Performance of the PCI Local Bus using Symbolic Techniques'', Technical Report - CMU-CS-96-147, School of Computer Science, Carnegie Mellon University, June, 1996. S. Chakraborty, D. L. Dill and K. Y. Yun, "Min-max Timing Analysis and an Application to Asynchronous Circuits", Proc. of the IEEE, Vol. 87, No. 2, pp. 332-346, Feb 1999. R. Hersemeule, B. Clement, E. Lantreibecq, P. Coulomb, B. Ramanadin, and F. Pogodalla, Fast Prototyping : A System Design Flow applied to a complex System- On-Chip Multiprocessor Design", DAC 1999. A. J. Hu, Formal Hardware Verification with BDDs : An Introduction, ACM Transactions on Programming Languages and Systems, 1997.

367 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 367 Papers K. L. McMillan, "A compositional rule for hardware design refinement", Computer Aided Verification (CAV97), O. Grumberg (Ed.), Haifa, Israel, pp. 24-35, 1997. T.A.Henzinger, S. Qadeer, and S.K.Rajamani, "You assume, We guarantee : Methodology and Case Studies" CAV98: Computer Aided Verification, Lecture Notes in Computer Science, Springer-Verlag, pp. 440-451, 1998. M. C. Browne, E. M. Clarke and D. L. Dill and B. Mishra, ``Automatic Verification of Sequential Circuits using Temporal Logic'', IEEE Transactions on Computers, Vol. C- 35, No. 12, pp 1035-1043, Dec. 1986. E. M. Clarke, E. A. Emerson and A. P. Sistla, ``Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications'', ACM Trans. on Programming Language and Systems, Vol.8, No.2, pp 244-263, April 1986. G. Mosensoson, Practical Approaches to SoC Verification, DATE 2000. J. L. Nielsen, H. R. Andersen, G. Behrmann, H. Hulgaard, K. Kristoffersen and K. G. Larsen, Verification of Large State/Event Systems using Compositionality and Dependency Analysis, Proceedings of TACAS 1998, LNCS 1384, April 1998. S. Bose and A. Fisher, Verifying Pipelined hardware using symbolic logic simulation, ICCD 1989. D. Geist, G. Biran, T. Arons, M. Slavkin, Y. Nustov, M. Farkas, and K. Holtz, A Methodology for the verification of a System on Chip, Proc. Of DAC 1999, pp. 574- 579. A. Evans, A. Silburt, G. Vrckovnik, T. Brown, M. Dufresne, G. Hall, T. Ho and Y. Liu, Functional Verification of Large ASICs, Proc. Of DAC, 1998.

368 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 368 Papers S. Taylor, M. Quinn, D. Brown, N. Dohm, S. Hildebrandt, J. Higgins and C. Ramey, Functional Verification of a Multiple-issue, Out-of-Order, Superscalar Alpha Processor – the DEC Alpha 21264 Microprocessor, Proc. Of DAC, 1998. S. Ramesh and P. Bhaduri, Validation of Pipelined Processor Designs using Esterel Tools: A Case Study, Proc. of CAV '99, LNCS Vol. 1633, 1999. J. R. Burch, E. M. Clarke, D. Long, K. L. McMillan, D. L. Dill, Symbolic Model Checking for Sequential Circuit Verification, IEEE Trans. Computer Aided Design, 13, 1994, 401-424. E. M. Clarke, R. P. Kurshan, Computer Aided Verification, IEEE Spectrum, June 1996, 61-67. D. Cyrluk, S. Rajan, N. Shankar and M. K. Srivas, Effective Theorem Proving for Hardware Verification, pp. 287-305, TPCD94. S. J. Garland and J. V. Guttag, An Overview of LP: the Larch Prover, Proceedings of the Third International Conference on Rewriting Techniques and Applications, 1989, Springer-Verlag. J. Staunstrup and M. Greenstreet, Synchronized Transitions, Formal Methods for VLSI Design, 1990, IFIP, North-Holland. R. Vemuri, How to Prove the Completeness of a Set of Register Level Design Transformations, Proceedings of the 27th ACM/IEEE Design Automation Conference, 1990, 207212.

369 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 369 Papers Jeffrey J. Joyce and Carl-Johan H. Seger, Linking Bdd Based Symbolic Evaluation to Interactive Theorem Proving, Proceedings of the 30th Design Automation Conference, 1993. S. P. Rajan, N. Shankar and M. Srivas, An Integration of Model-Checking with Automated Proof Checking, 7th Conference on Computer-Aided Verification, July, 1995. R. E. Bryant, Graph Based Algorithms for Boolean Function Manipulation, IEEE Transactions on Computers, Vol. C-35-8, pp. 677- 691, August 1986 R. E. Bryant, On the Complexity of VLSI Implementations and Graph Representations of Boolean Functions with Application to Integer Multiplication, IEEE Transactions on Computers, Vol. 40, No. 2, pp, 205-213, February 1991 B. Bollig and I. Wegener, Improving the variable ordering for OBDDs is NP- complete, IEEE Transactions on Computers, Vol. 45, No. 9, pp. 993-1002, September 1996 M. Fujita, H. Fujitsawa and Y. Matsunaga, Variable Ordering Algorithms for Ordered Binary Decision Diagrams and their Evaluation, IEEE Transactions on Computer- Aided Design of Integrated Circuits and Systems, Vol. 12, No. 1, pp. 6- 12, January 1993 R. Rudell, Dynamic Variable Ordering for Ordered Binary Decision Diagrams, Proceedings of ICCAD 1993, pp. 42- 45

370 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 370 Papers J. Jain, W. Adams and M.Fujita, Sampling Schemes for Computing OBDD Variable Orderings, Proceedings of ICCAD 1998, pp. 331-338 J. Jain, R. Mukherjee and M. Fujita, Advanced Verification Technique Based on Learning, Proceedings of DAC 1995, pp. 420-426 Y. Matsunaga, An Efficient Equivalence Checker for Combinational Circuits, Proceedings of DAC 1996, pp. 629-634 A. Kuehlmann and F. Krohm, Equivalence Checking using Cuts and Heaps, Proceedings of DAC 1997, pp. 263-268 C. H. Yang and D. L. Dill, Validation with Guided Search of the State Space, Proceedings of DAC 1998 R. E. Bryant, Symbolic Simulation -- Techniques and Applications, Proceedings of DAC 1990 A. Jain, Formal Hardware Verification by Symbolic Trajectory Evaluation, Ph.D. Thesis, Dept. of Electrical and Computer Engineering, Carnegie Mellon University, August 1997 C.-J.H. Seger and R.E. Bryant, Formal Verification by Symbolic Evaluation of Partially Ordered Trajectories, Formal Methods in System Design, Vol. 6, No. 2, pp. 147-190, 1995 R. E. Bryant, D. L. Beatty and C.-J.H. Seger, Formal Hardware Verification by Symbolic Trajectory Evaluation, Proceedings of DAC 1991

371 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 371 Papers D. Greve, Symbolic Simulation of the JEM1 Microprocessor, Proceedings of FMCAD 1998, pp. 321-333 D.L. Dill and S. Tesiran, Simulation meets Formal Verification, Embedded Tutorial at ICCAD 1999 R.B. Jones, M.D. Aagard and C.-J.H. Seger, Formal Verification using Parametric Representations of Boolean Constraints, Proceedings of DAC 1999, pp. 402-407 R.B. Jones, Applications of Symbolic Simulation to the Formal Verification of Microprocessors, Ph.D. Thesis, Computer Systems Laboratory, Stanford University, August 1999 J.U. Skakkebaek, R.B. Jones and D.L. Dill, Formal Verification of Out-of-Order Execution using Incremental Flushing, Proceedings of CAV 1998, pp. 98-109 R.B. Jones, C.-J.H. Seger and D.L. Dill, Self Consistency Checking, Proceedings of FMCAD 1996, pp. 159-171 M.D. Aagard, R.B. Jones and C.-J.H. Seger, Combining Theorem Proving and Trajectory Evaluation in an Industrial Environment, Proceedings of DAC 1998, pp. 538-541 C.W. Barrett, D.L. Dill and J.R. Levitt, A Decision Procedure for Bit-Vector Arithmetic, Proceedings of DAC 1998 J.R. Burch and D.L. Dill, Automatic Verification of Pipelined Microprocessor Control, Proceedings of CAV 1994

372 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 372 Papers M.N. Velev, Automatic Abstraction of Memories in the Formal Verification of Superscalar Microprocessors, Proceedings of Tools and Algorithms for the Construction and Analysis of Systems (TACAS) 2001, pp. 252-267 M.N. Velev, Formal Verification of VLIW Microprocessors with Speculative Execution, Proceedings of CAV 2000, pp. 296-311 M. Pandey, Formal Verification of Memory Arrays, Ph.D. Thesis, School of Computer Science, Carnegie Mellon University, May 1997 J.X. Su, D.L. Dill and C.W. Barrett, Automatic Generation of Invariants in Processor Verification, Proceedings of FMCAD 1996

373 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 373 Books K. L. McMillan, ``Symbolic Model Checking'', Kluwer Academic Publishers, 1993. Z. Manna and A. Pnueli, Temporal Specification and Verification of Reactive Systems Vol. I and II, Springer 1995. Ching-Tsun Chou, "The Mathematical Foundation of Symbolic Trajectory Evaluation", Springer-Verlag 1999. Thomas Kropf: "Introduction to Formal Hardware Verification", (Springer Verlag; ISBN: 3540654453, 299 pages, January 2000) E. M. Clarke, O. Grumberg and D. Peled, "Model Checking", (MIT Press; ISBN: 0262032708; 330 pages; January 2000) L. Bening and H. Foster, Principles of Verifiable RTL Design: Functional Coding Style Supporting Verification Processes in Verilog, published by Kluwer Academic Publishers, 2000. M. Yoeli, "Formal Verification of Hardware Design", IEEE Computer Society Press, 1991. (Book containing a collection of papers) R. P. Kurshan, Computer Aided Verification of Coordinating Processes, Princeton University Press, 1994.

374 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 374 Books G. J. Holzmann, Design and Validation of Computer Protocols, Prentice Hall, 1991. M. P. Fourman, Formal System Design, Formal Methods for VLSI Design, IFIP, 1990, North-Holland. C. Meinel and T. Theobald, Algorithms and Data Structures in VLSI Design, Springer- Verlag, 1998. M. Kaufmann, P. Manolios, and J S. Moore, "Computer-Aided Reasoning: An Approach", (Kluwer Academic Publishers, June 2000; ISBN 0792377443)

375 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 375 Important web-sites: http://www.comlab.ox.ac.uk/archive/formal-methods.html http://www.csl.sri.com http://dimacs.rutgers.edu/Workshops/SYLA-Tutorials/program.html http://www-cad.eecs.Berkeley.edu/ vis http://godel.ece.utexas.edu/texas97-benchmarks/ http://citeseer.nj.nec.com/ http://www.rational.com/uml (Universal Modelling Language HOME-PAGE)

376 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 376 Conference Proceedings Computer Aided Verification (CAV) Formal Methods in Computer Aided Design (FMCAD) International Conference on Computer-Aided Design (ICCAD) International Conference on Computer Design (ICCD) Design Automation Conference (DAC) Asia South Pacific Design Automation Conference (ASPDAC) International Conference on VLSI Design (VLSI) Advanced Research Working Conference on Correct Hardware Design and Verification Methods (CHARME)

377 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 377 Journals/Magazines IEEE Design and Test of Computers IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems IEEE Transactions on Computers IEEE Transactions on VLSI Systems ACM Transactions on Design Automation of ELectronic Systems Formal Methods in System Design Formal Aspects of Computing

378 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 378 Appendix

379 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 379 Formal Modeling (S. Ramesh)

380 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 380 Non-determinism (another example) 3- floor elevator controller, S i - in floor i ri - request from floor i This machine is also nondeterministic In S2 state when r1 and r3 arrive.

381 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 381 Formal Specification (S. Ramesh)

382 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 382 Linear Temporal Logic Syntax Atomic propositions are formulae If f, g are formulae then so are ¬f, f g, f g, f g, f g f - Henceforth f f - Eventually f f U g - f until g f W g - f unless g f - next f state formulae - no temporal operators

383 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 383 Semantics Formulae interpreted over infinite sequences of states States evaluate state formulae Let = q 0, q 1, … be a sequence Each q i assigns truth values to atomic propositions Semantic definition defines when a formula satisfies a sequence

384 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 384 Semantic Definition Notation: A stands for A holds in. A iff (,0) A (, j) A - defined inductively Base case: (, j) f for any state formula f iff f holds in the state [j]

385 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 385 Semantics of Temporal Operators (, j) f iff k j, (, k) f

386 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 386 Semantics Contd. (, j) f iff k, (,k) f

387 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 387 Semantics Contd. (, j) f U g iff k j : (, k) g and i s.t. j i k, (, i) f

388 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 388 Semantics Contd. (, j) f W g iff (, j) f U g or (, j) f (, j) Ο f iff (, j + 1) f

389 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 389 Examples p q If p holds in the beginning then q holds always (p q) Whenever p holds there is a future instant in which q holds p p holds infinitely often p p holds at all but finitely many positions

390 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 390 Examples - Properties ¬(farm_go high_go) (farm_car farm_go) (mem_rd mem_ack) (mem_rd mem_rd W mem_ack)

391 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 391 - Automata An alternate formalism for specifying infinite objects Extension of Finite Automata to specify properties about infinite runs The simplest kind is Büchi automaton: Q - finite no. of states - Edge labels q 0 - initial state Q x x Q A Q, Accepting (not final) states

392 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 392 Behavior of - Automata starts from the initial state, `runs forever' accepts infinite sequences over label alphabet s = l0, l1, l2,... is accepted by the automaton, provided there exists q 0, q 1,… s.t. (q i, l i, q i+1 ) Є for i = 0, 1, … there is an accepting state that occurs infinitely often in s.

393 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 393 Examples All sequences containing only 1. An infinite set of infinite sequences! But finite description

394 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 394 Examples contd. All sequences that has at least one occurrence of 1

395 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 395 Examples contd. Sequences containing all but finitely many occurrences of 1s

396 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 396 Examples contd. All sequences containing infinitely many 1s

397 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 397 Features of - automata useful for specifying properties and constraints precise and unambiguous consistency can be checked (Emptiness of automata) has many properties useful for verification: - languages closed under union, intersection and complementation

398 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 398 Model Checking (S. Ramesh)

399 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 399 LTL Model Checking (Pnueli, Lichtenstein, Vardi, Wolper) M F Read: M `contains' only models of F M a finite state system or an automaton F a linear TL formula M defines a set of infinite state sequences L M and F another set of sequences L F. Checking M F amounts to checking L M L F Hence referred to as language containment problem

400 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 400 Illustration Which of the following hold for all the sequences generated by the above p, ¬q, p, (p q) (p q), (p q), (p q), p, (p q).

401 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 401 LTL Verification Method Two related Methods: Tableau – based Automata – based

402 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 402 Automata based Method Obtain an -automaton for the negation of the formula Take the product of system model and - Automaton Check whether the resulting automaton accepts any string at all (Emptiness Check). Existence of an accepting cycle in the product graph If no cycle then original property holds. A cycle gives a counterexample - an execution trace that violates the formula; useful for debugging

403 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 403 Example 1. To check whether this is a model for P, construct first a - Automata for ¬p

404 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 404 Example contd. Construct the product of the two automata: No reachable accepting cycle It is a model of p.

405 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 405 Another Example Check whether the following automaton satisfies ¬p - Automata for : ¬( ¬p)

406 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 406 Product Automata There is a cycle and hence the automaton is not a model If state 4 is the only accepting state then the formula holds

407 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 407 Complexity of LTL model-checking Linear on model size and exp. on formula size Formulae are generally small! Model size exponential on block size (no. of storage elements). State Explosion Problem Various Reduction Techniques: Nested depth first search for cycles On the fly checking Partial order reduction Clever hashing techniques OBDD based Symbolic techniques Compositional Verification

408 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 408 Binary Decision Diagrams (S. Chakraborty)

409 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 409 Neat Tricks in BDD Packages Shared BDDs (SBDDs) Multiple functions represented simultaneously as a multi-rooted DAG. Each root and descendants form an ROBDD Different roots can share subgraphs Representing functions using ITE operator if-then-else (x, y, z) = x.y + x z Natural implementation using BDDs Can express any binary Boolean operation : NAND(x, y) = ITE(x, y, 0); NOT(x) = ITE(x, 0, 1) Efficient algorithm for computing ITE with BDDs exists

410 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 410 Neat Tricks in BDD Packages Complement edges If a vertex is reached by a complement edge, take the complement of the function represented by the vertex Simplifies complementation Saves duplication of computation Hash Tables and Caches Facilitates identifying ROBDD node for an already computed function Avoids computation duplication f = x 1.x 2 + x 3 f = (x 1.x 2 x 3 + x 1 x 3 ) 10 x1x1 x2x2 x3x3 x1x1 x2x2 x3x3 01

411 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 411 Academic & Research Lab Verification Tools (S. Ramesh)

412 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 412 Spin Home page: http://netlib.bell-labs.com/netlib/spin/whatispin.html Bell Labs. (G. Holzmann) Verification of asynchronous protocol descriptions Modeling Language: PROMELA Specification Language: LTL Verification Approach: Automata Containment (Explicit Model Checking) Symbolic verification (recent addition) Promela (Protocol Modeling Language) Concurrent and nondeterministic processes Process communication: messages via buffered and non buffered channels

413 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 413 An Example Promela Program chan in = [size] of {short} chan out1 = [16] of {short} chan out2 = [16] of {short} proctype split() {short x do :: in?x ® if :: (x>=100) ® out1!x :: (x<=100) ® out2!x fi od }

414 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 414 An Example Promela Program proctype merge() { short y do :: if :: out1?y :: out2?y fi; out!y od } init {run split(); run merge() }

415 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 415 Spin Features Random Simulation Deadlock detection and Formal verification A clever implementation of on-the- fly model checking algorithm A number of powerful reduction techniques: Supertrace algorithm: bit state hashing Partial order reduction Symbolic techniques Many telecommunication protocols have been verified

416 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 416 More on FormalCheck Home page: http://www.cadence.com/datasheets/formalcheck.html Commercial model-checking tool (Cadence) Originated from COSPAN (Bell Labs.) Modeling languages: synthesizable subsets of Verilog and VHDL Specification Language: FQL – FormalCheck Query language (A variant of LTL, Syntax same as HDL) Verification Approach: Automata Containment Powerful compositional reduction strategies Clever representation for specifications

417 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 417 Example Specifications after { Req == 1 } eventually { Ack == 1 } after { Timer.Start == 1 } always { Timer.counting == 1 } unless { Timer.Restart == 1 } After timer starts, counting is on unless it is restarted

418 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 418 Example contd. never { TAP.State == TRST } within -delay 0 -duration 6 { Clock.rising } States that it is not possible to reach the TRST state in 5 steps. after { Counter.bit[0] == 1 } eventually { Counter.bit[0] == 0 } within -delay 0 -duration 2 {Clock.rising }

419 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 419 FQL Formulae after( ) always/never( ) [unless[ after]( )] [within(m,n)] always/never( ) [unless[ after]( )] after( ) eventually( ) [unless( )] [within(m,n)] eventually( ) [unless( )] after( ) eventually always( ) [unless( )] [within(m,n)] eventually always( ) [unless( )] if repeatedly( ) eventually always( )

420 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 420 Appendix High Level Specification and Modeling ( T. Nakata)

421 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 421 UML : Use-Case Diagram Define system functions from users view Vending machine Buy a juice Actor Use-case Customer Refill products Gather changes Supplier Services

422 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 422 UML : Sequence Diagram Describe a scenario --- an instance of a use-case Specify interactions among objects in order of time Scenario: buy juice :Panel:Container:Emitter Inject a coin Choose juice Send Emit a can of juice Equal to price

423 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 423 UML : Class Diagram Describe static aspects of a system by relationships among classes A class represents a concept in a system EmployeePC Name: string ID: integer Name: string CPU: string uses 0..11..*

424 ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 424 UML : State Diagram Describe states and their transitions of objects Almost the same as hierarchical FSMs Ground floor Ascend to floor fl Up(fl) Stop timer=0 inc timer Arrived Up(fl) Descend to floor fl Arrived Down(fl) [timer=time_out]/Down(0)


Download ppt "ASPDAC / VLSI 2002 - Tutorial on "Functional Verification of SoCs" 1 ASPDAC/VLSI 2002 Tutorial Functional Verification of System on Chip - Practices, Issues."

Similar presentations


Ads by Google