1 / 424

ASPDAC/VLSI 2002 Tutorial Functional

Verification of System on Chip -

Practices, Issues and Challenges

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

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

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

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

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_at_fla.fujitsu.com

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

Tutorial Outline (contd.)

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

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.

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.

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.

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)

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.

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

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)

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)

SoC Design Re-use (Subir K. Roy)

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

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

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

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

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.

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

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.

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

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

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

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

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)

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

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

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

System Verification (S. P. Rajan)

Current Design Cycle

RTL Description (from Spec/Doc)

Simulation Formal Verification

Modify RTL Source

RTL/logic Synthesis

Modify Script

Timing Analysis

NOT OK

OK

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?

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

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

Techniques for Module Verification

Formal Verification (S. Ramesh)

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

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

Three-step process (contd.)

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

Formal verification

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

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.

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.

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

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

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

State of the art

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

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

Formal Modeling (S. Ramesh)

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

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!

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)

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)

Models of Hardware

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

Finite State Machines

- Well-known model for describing control or

sequential circuits - An example (3-bit counter)
- State labels describe bit status

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

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

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)

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

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

Concurrency

- A concurrent (and hierarchical) description of

Counter

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

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

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.

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

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

Live lock/Divergence

- An example
- Formal Verification generalizes early approaches

to detection of such errors!

Formal Specification (S. Ramesh)

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

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"

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

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

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

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

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

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

Examples

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

Model Checking (S. Ramesh)

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.

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.

EXAMPLE

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

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

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

Illustration

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

Illustration contd.

- Iterative computation
- I step

Illustration contd.

- II step
- III step

Illustration contd.

- Computation terminates
- EF p Holds in all striped states
- Computation involves backward breadth first

traversal and calculation of Strongly Connected

Subgraphs (cycles)

2. Compute EG p in

- EG p p Ù EX p Ù EX(EX p) Ù . . .

Illustration contd.

- Start with
- I iteration

Illustration contd.

- II iteration
- III iteration

Iteration terminates

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

Verification by Theorem Proving (S. Ramesh)

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.

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

Proof

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

Examples

- Propositional logic and its natural deduction

system - Prove SNi1 i N(N 1)/2, using Peano's axioms

and mathematical induction

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.

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.

Binary Decision Diagrams (S. Chakraborty)

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

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

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

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

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

Variable Ordering Problem

f x1.x2 x3.x4 x5.x6

Order 1,3,5,2,4,6

Order 1,2,3,4,5,6

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

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

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)

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)

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

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

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

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)

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

Combinational Equivalence Checking (S.

Chakraborty)

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

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

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

ROBDDs in Equivalence Checking

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

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

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

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

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

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

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

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

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

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

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

Equivalence Checkers Out There

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

Symbolic Model Checking (S. Chakraborty)

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

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

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

...

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

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

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

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

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

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

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

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

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)

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

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)

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

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

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

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?

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

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