ASPDAC/VLSI 2002 Tutorial

1
ASPDAC/VLSI 2002 Tutorial Functional
Verification of System on Chip -
Practices, Issues and Challenges
2
Presenters Subir K. Roy (Co-ordinator),
Synplicity Inc.,
935 Stewart Drive,
Sunnyvale CA 94085, USA
Tel. [phone]
Fax. [phone]
Email subir_at_synplicity.com
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_at_cse.iitb.ac.in
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_at_cse.iitb.ac.in
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_at_flab.fujitsu.co.jp
6
Presenters Sreeranga P. Rajan,
Fujitsu Labs. Of America,
595 Lawrence Expressway,
Sunnyvale CA 94086-3922,
USA Tel. [phone]
Fax. [phone]
Email sree_at_fla.fujitsu.com
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
Tutorial Outline (contd.)

• Commercial Tools
• Issues and Challenges / Future Research Topics
• Summary Conclusions
• Bibliography
• Appendix

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
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
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
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
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
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
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
Tutorial Outline (contd.)

• Bibliography
• Papers, Books, Important Web Sites, Conferences,
  Journals/Magazines.
• Appendix
• Linear Temporal Logic, w-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
SoC Design Re-use (Subir K. Roy)
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
Verification Hierarchy
Higher-Order Theorem Proving
First-Order Theorem Proving
Coverage/ Expressive Power
Temporal Logic Based Model Checking
Assume-Guarantee based symbolic simulation/Model
Checking
Equivalence Checking
Equivalence Checking of structurally similar
circuits
Simulation
Degree of Automation
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
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
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
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
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
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
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
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
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
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
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
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
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
System Verification (S. P. Rajan)
34
Current Design Cycle

RTL Description (from Spec/Doc)
Simulation Formal Verification
Modify RTL Source
RTL/logic Synthesis
Modify Script
Timing Analysis
NOT OK
OK
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
Design Cycle with System Verification

Cycle Accurate Behavior
Validate
Generic Parameters
Instantiation
Cycle Accurate Behavior
Cycle Accurate Behavior
Fixed Parameters
Fixed Parameters
High/RT-Level Synthesis
Gate-Level (Large Design)
Gate-Level (Small)
Validate
Logic Synthesis
Chip
Chip
Validate Formally Verify Simulate
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
Techniques for Module Verification
39
Formal Verification (S. Ramesh)
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
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
Three-step process (contd.)

• Verification
• Checking that model satisfies specification
• Static and exhaustive checking
• Automatic or semi-automatic

43
Formal verification

• Major techniques
• Equivalence checking
• Model checking
• Language containment
• Theorem proving

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
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
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
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
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
State of the art

• FSM based methods 500 registers
• STE 10 - 20k registers
• Equivalence checking million gates designs
• Simulation million gates capacity

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
Formal Modeling (S. Ramesh)
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
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
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
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
Models of Hardware

• Hardware blocks are reactive systems
• Reactive systems exhibit infinite behavior
• Termination is a bad behavior
• Timing/Causality information important

57
Finite State Machines

• Well-known model for describing control or
  sequential circuits
• An example (3-bit counter)
• State labels describe bit status

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

• A concurrent (and hierarchical) description of
  Counter

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
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
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
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
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
Live lock/Divergence

• An example
• Formal Verification generalizes early approaches
  to detection of such errors!

70
Formal Specification (S. Ramesh)
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
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
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
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
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
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
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
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
Examples

• AG (farm_go Ù high_go_B)
• AGAF (farm_car AF(farm_go))
• AG (mem_wr U mem_ack)
• EF (req0 U grant0 )

80
Model Checking (S. Ramesh)
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
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
EXAMPLE

• Which of the following hold ?
• AG p, EFq, AX p, AG q, EG q, AX(p Ú q)

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

• To compute EF p which is
• EF p p Ú EX(p) Ú EX(EX(p)) Ú . . .

87
Illustration contd.

• Iterative computation
• I step

88
Illustration contd.

• II step
• III step

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
2. Compute EG p in

• EG p p Ù EX p Ù EX(EX p) Ù . . .

91
Illustration contd.

• Start with
• I iteration

92
Illustration contd.

• II iteration
• III iteration

Iteration terminates
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
Verification by Theorem Proving (S. Ramesh)
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
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
Proof

• Syntactic object
• A1, A2, . . . , An
• A1 axiom instance
• An theorem
• Ai1 - Syntactically obtainable from
• A1, . . . , Ai using inference rules.

98
Examples

• Propositional logic and its natural deduction
  system
• Prove SNi1 i N(N 1)/2, using Peano's axioms
  and mathematical induction

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
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
Binary Decision Diagrams (S. Chakraborty)
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 2n for n-arguments
• Operations (e.g. AND, NOT) inefficient
• Inappropriate for practical applications
• E.g., representing carry-out function of 64-bit
  adder

103
Binary Decision Diagrams (BDDs)

• A graphical representation Bryant 96
• Allows efficient representation manipulation of
  Boolean functions
• Worst-case behavior still exponential
• Example f x1.x2 x3
• Represent as binary tree
• Evaluating f
• Start from root
• For each vertex xi
• left branch if xi 0
• else right branch

104
BDDs

• Underlying principle Shannon decomposition
• f(x1, x2, x3) x1.f(1, x2, x3) x1.f(0, x2,
  x3)
• x1. (x2 x3) x1. (x3)
• Apply recursively to
• f(1, x2, x3) and f(0, x2, x3)
• Extend to n arguments
• Number of nodes can be
• exponential in number of
• arguments

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

x1
x2
x3
x3
x2
x3
x2
1
0
1
1
1
0
1
0
f x1.x2 x1.x2 x1.x3
106
ROBDDs
x1
x2
f x1.x2 x3

• 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 !

x3
0
1
x1
x2
x2
x3
x3
x3
1
0
1
1
1
0
1
0
107
Variable Ordering Problem
f x1.x2 x3.x4 x5.x6

Order 1,3,5,2,4,6
Order 1,2,3,4,5,6
108
Variable Ordering Problem

• ROBDD size extremely sensitive to variable
  ordering
• f x1.x2 x3.x4 x2n-1.x2n
• 2n2 vertices for order 1, 2, 3, 42n-1, 2n
• 2n1 vertices for order 1, n1, 2, n2,n, 2n
• f x1.x2.x3.xn
• n2 vertices for all orderings
• Output functions of integer multipliers
• Exponential size for all orderings Bryant 91

109
Variable Ordering Problem

• 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

110
Operations on BDDs

• Operation Complexity
• Reduce O(G)
• G reduced to canonical form
  
• Apply O(G1G2)
• Any binary Boolean op AND, XOR
• Compose O(G12G2)
• g1(x1, x2, x5) composed with g2(x3, x4)
• at position of x2 g1(x1, g2(x3,x4), x5)

111
Operations on BDDs (Contd.)

• Operation Complexity
• Satisfy-one O(n)
• Assignment of x1, xn
• for which f(x1, xn) 1
• Restrict O(G)
• ROBDD for f(x1, x2, ,1, ... xn)
• or f (x1, x2, 0 xn)

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
• x1. f(x1, x2, x3) f(0, x2, x3)
  f(1, x2, x3)
• x1. f(x1, x2, x3) f(0, x2, x3) .
  f(1, x2, x3)
• Useful in Symbolic Model Checking

113
BDD Packages/Libraries Out There

• CUDD package (Colorado University)
• http//vlsi.colorado.edu/fabio/CUDD/cuddIntro.htm
  l
• 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
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
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
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
Combinational Equivalence Checking (S.
Chakraborty)
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 1
Design 2
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
F
Designs functionally equivalent if and only if F
is identical to 0 (0 for all inputs)
Design 2
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
ROBDDs in Equivalence Checking

• Something smarter needed
• Worst case must still be exponential complexity
• Unsatisfiability co-NP complete!

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

A1
B1
A2
B2
A1
B1
A2
B2
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

F
Design 1
Internal signals
Design 2
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
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
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
An Efficient Equivalence Checker

• Finds pairs of equivalent signals in two designs
  Matsunaga 96

CEP Candidate equivalent
pairs
Start
Random simulation ? CEP list
NO
VEP Verified equivalent
pairs
More pairs to verify?
YES
Verify pair, update VEP list and CEP list,
Restructure circuit
Check if primary output pair is in VEP list
End
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
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
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
Comb Logic2
FF
FF
Given Equivalence
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
Equivalence Checkers Out There

• Commercial equivalence checkers in market
• Abstract,
• Avant!,
• Cadence,
• Synopsys,
• Verplex,
• Veritas (IBM internal) ...

133
Symbolic Model Checking (S. Chakraborty)
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
Example 3-bit Counter

Model State transition graph defined by X0
NOT(x0) X1 XOR(x1, x0) X2 XOR(x2, x0. x1)
x2
X2
x1
X1
Property State x0, x1, x2 111 is reached
infinitely often starting from state 000
x0
X0
Clk
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
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
Symbolic Model Checking

• For 3-bit counter, set of states x0, x1, x2
  000, 010, 011, 001 can be represented by S
  (x0, x1, x2) S(x) x0.
• BDD
• Set of state transitions can be represented
• by N (x0, x1, x2, X0, X1, X2) N (x, X)
• (X0 x0) (X1 x1 x0)
• (X2 x2 (x1. x0))
  BDD

x0
0
1
x0
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 (x0, x1, x2),
• S1 (X0, X1, X2) S0 (X0, X1, X2)
• x0, x1, x2 .
  S0 (x0, x1, x2)
• N(x0, x1, x2, X0, X1, X2)
• Given BDDs for S0 and N, BDD for S1 can be
  obtained

S0
S1
140
Forward Reachability

• Compute S1 from S0, S2 from S1, S3 from S2,
• Predicate transformer F Si1 F (Si)
• Continue until Sk1 F (Sk) Sk
• Least fixed point of F
• Sk Set of all states reachable from S0
• Computed symbolically -- using BDDs
• Very large state sets can be represented
  compactly

S0
Reachable states
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
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
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
S0
B
R
Z
Z
Forward Reachability
Backward Reachability
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 x1 x2 x3 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
• Af U g In all paths from S0, g holds
• finally, and f holds until then

S0
Computation tree of states
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 (x1 x2)
• x1 or x2 is satisfied infinitely often in the
  future
• Recall 3-bit counter example
• The state x0, x1, x2 111 is reached
  infinitely
• often starting from 000
• x0 x1 x2 AG AF (x0 x1 x2)

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
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, Ep U q
• CHECK(g) returns set of states satisfying g
• If g atomic proposition (e.g., x1. x2 x3),
  CHECK returns BDD for g
• If g EX p, EG p, Ep U q, CHECK uses
  reachability analysis to return BDD for set of
  states
• Worst-case exponential complexity
• Finally, determine if S0 CHECK(g)

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
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
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
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
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
Related techniques

• Approximate Model Checking
• Representing exact state sets may involve
  large BDDs
• Compute approximations to reachable states
• Potentially smaller representation
• Over-approximation
• No bug