Soc

ASPDAC/VLSI 2002 Tutorial
Functional Verification of System on Chip - Practices,

Issues and Challenges
ASPDAC / VLSI 2002 - Tutorial 1

on "Functional Verification of
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

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

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

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

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

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.

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

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

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

• 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

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

• 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 Temporal Logic Based
Model Checking
Power 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

• 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
• 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
Gate-Level
(Large Design) Validate
(Small)
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
Model Tr. Systems/ Logic
Spec Automata
Logic Model Checking Th. Proving
Eq. Checking
Automata/ Lang. Containment
Tr. Systems Obs. Equivalence
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, EF¬q, 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
• Ai+1 - Syntactically obtainable from
• A1, . . . , Ai using inference rules.

Examples
• Propositional logic and its natural deduction
system
• Prove SNi=1 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’
0 x 1
• Represent as binary tree 1
• Evaluating f: x2 x2
• Start from root
x3 x3 x3 x3
• For each vertex xi
left branch if xi = 0
1 0 1 0 1 0 1 1
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) x1
x x2
• Extend to n arguments 2
x3 x3 x3 x3
• Number of nodes can be
1 0 1 0 1 0 1 1
exponential in number of
arguments f = x1.x2 + x3’

Restrictions on BDDs
• Ordering of variables
• In all paths from root to leaf, variable labels of
nodes must appear in specified order
• Reduced graphs
x1
• No two distinct vertices x3 x2
represent same function x3
x2 x2 x3
• Each non-leaf vertex has
distinct children 1 0 1 0 1 0 1 1
f = x1’.x2’ + x1.x2 + x1.x3’
REDUCED ORDERED BDDs (ROBDDs): DAG

ROBDDs
x1
• Example: f = x1.x2 + x3’ x2
• Properties x3
• Unique representation of f for given 0 1
variable ordering
• Checking f1 = f2: ROBDD isomorphism
• Shared subgraphs: size reduction
• Every path might not have all labels
x1
• Every non-leaf vertex has x2 x2
path(s) to 0 and 1 x3 x3 x3
So far good ! 1 0 1 0 1 0 1 1

Variable Ordering Problem
f = x1.x2 + x3.x4 + x5.x6
1 Order 1,3,5,2,4,6 1
2
3 3 Order 1,2,3,4,5,6
3
5 5 5 5
4
2 2 2 2
4 5
4
6
6
0 1 0 1
• ROBDD size extremely sensitive to variable ordering
• f = x1.x2 + x3.x4 + … + x2n-1.x2n
• 2n+2 vertices for order 1, 2, 3, 4…2n-1, 2n
• 2n+1 vertices for order 1, n+1, 2, n+2,…n, 2n
• f = x1.x2.x3….xn
• n+2 vertices for all orderings
• Output functions of integer multipliers
Exponential size for all orderings [Bryant ‘91]

• 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 al‘98]

Operations on BDDs
Operation Complexity
• Reduce O(|G|)
• G reduced to canonical form
• Apply O(|G1||G2|)
• Any binary Boolean op: AND, XOR …
• Compose O(|G1|2|G2|)
• 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.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

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
• 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
Design 1 Design 2
• 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
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
Design 2
(0 for all inputs)

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
A1 B1 A2 B2
• If A1 equivalent to A2 & B1 equivalent to B2,

Design1 equivalent to Design2
• Simplifies equivalence checking
• But consider
A1 B1 A2 B2
B1 not equiv to B2, but Design 1 equiv to Design 2

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
F
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]
Start CEP: Candidate
equivalent
pairs
Random simulation  CEP list
NO VEP: Verified
More pairs
to verify? equivalent
YES pairs
Verify pair, update VEP list
and CEP list,
Restructure circuit
Check if primary output

End
pair is in VEP list

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 Comb
Logic1 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 MODEL
• Flip-flops with next-state logic
• Transition relation between present and
next states
• A property in specialized logic SPECIFICATION
• Prove that MODEL satisfies SPECIFICATION

• In case of failure, counterexample desirable
Example: 3-bit Counter
Model
State transition graph
x2
X2
defined by
X0 = NOT(x0)
x1 X1 = XOR(x1, x0)
X1
X2 = XOR(x2, x0. x1)
X0 x0 Property
State x0, x1, x2 = 111
is reached infinitely
often starting from
state 000
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 …
• 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’.
x0
BDD:
1 0
x0
• 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:
1 0

Forward Reachability
• Start from set S0 of states
• Set of states reachable in at most 1 step: S1 S0
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
Forward Reachability
• Compute S1 from S0, S2 from S1, S3 from S2, …
• Predicate transformer F: Si+1 = F (Si)
• Continue until Sk+1 = 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 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
Computation tree
A[f U g]: In all paths from S0, g holds of states
finally, and f holds until then
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 al’94]
• 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, E[p 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, 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)

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 : Buggy states
• No bugs found Circuit verified correct

• Bugs found may be real or false
Reachable states
• Under-approximation :
• Bug found  Real bug
• No bugs found Circuit may still contain bugs
Related techniques
• Bounded model checking
• Check property within k steps from given set S0 of
states
• S0 F(S0) F2(S0) … Fk(S0)
• Unroll sequential machine for k time steps
PI1 PI2
PI PO
PI0
PS NS
S0 S1 S2 S3
• To check property Z, test satisfiability of

(S0  Z)   (S0  Z)  (S1  Z)  … (Sk  Z)
• Leverages work done on SAT solvers
Semi-formal Methods
(S. Chakraborty)

Semi-formal Verification
• Formal verification still a bottleneck
• Simulation and emulation not keeping up with
design complexity
• Designs with bugs being produced
• FV methods haven’t 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
Simulation Simulation Simulation
Driver Engine Monitor
Symbolic
Conventional
Simulation
Diagnosis of
Guided vector Coverage Extension
Unverified
generation Analysis
Portions
Devadas and Keutzer’s proposal:

A pragmatic suggestion for SOC 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?
• 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
• 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!

• 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

• 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

• 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

Interface Specification
for
Divide & Conquer Verification
(T. Nakata)

Constraints in Module Verification
Properties
Input Module
constraints under
verification
Verification engine
• 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)

Two Ways to Define Constraints
Module Add pseudo module

under to inputs
verification
// PSE_BGN
Module
// PSE_ERR
[ data == ‘CLD ] Specify constraints by
[ data != ‘CB ]{,1} under
[ data == ‘CB ]
Interface a certain language
// PSE_END
verification
specification
language
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, …

Design and Verification Support
I/F
specification
Sim. pattern
generation Spec. sheet
generator
Checker I/F
Coverage generation Synthesis
criteria
Verification support Design support

Verification Support (1)
• Checker generation
• Input constraint checker that rules out invalid
transactions
• Output checker that checks consistency to
specification
Error
Module

• Simulation pattern generation
• Random pattern generator in conformance
with input constraints
Good
pattern
Module

• Abstraction level converter for verification scenarios
• Conversion between transaction-level and signal-level
scenarios*
* e.g. TestBuilder TVM generator
do {
Scenario Comparison
wait();
} while
(!grant);
m1.write(d);
Module Level
converter

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

Hierarchical Description: Base
clk
rst
en
ad[9:0] a
wait
dt[7:0] d
I N Q(a) W W S(d) N
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

Hierarchical Description: Transaction
clk
rst
en
ad[9:0] a
wait
dt[7:0] d
I N Q(a) W W S(d) N
reset nop read(a,d) nop
word;
nop : N ;
reset : I ;
read(a,d) : Q(a) W* S(d) ;
endword

Hierarchical Description: Sentence
clk
rst
en
ad[9:0] a
wait
dt[7:0] d
I N Q(a) W W S(d) N
reset nop read(a,d) nop
sentence
sentence;
reset [ nop | read ]+ ;
endsentence

Split Transactions
I N N Q1 Q2 S1 Q3 S2 S3
reset nop nop read1 read1
read2 read2
read3 read3
sentence;
INITIAL:
reset;
FOREGROUND:
read;
BACKGROUND:
nop;
endsentence

Summary
• Interface specification is crucial in module
verification
• Design and verification support from I/F spec.
• Activities in I/F specification languages

Techniques for
System Verification

Symbolic Simulation
and
Symbolic Trajectory Evaluation
(S. Chakraborty)

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

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 Primary outputs
a, 1, a F1(a,S), F2(a,b,S), F3(a,b,S)
Sequential
a’, b, a + b Circuit
Next states
Initial state S
G1(a,S), G2(a,b,S), G3(a,b,S)

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
Low-level Symbolic Simulation
• {0, 1, X} encoded in binary 0: 00 1: 11 X: 01
• 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
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]
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) ...

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
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
Hybrid Verification
(S. P. Rajan)

Hybrid Verification
• Formal Verification using

• Theorem Proving + Model Checking (PVS)
• PVS = Prototype Verification System (SRI

International)
• Tight integration of theorem prover and model
checker

Hybrid Verification
Basic
Model Checker Decision
Model-Check
Procedures
Simplify Hardware
Specification Decision BDD
Procedures
data-structures
Rewrite Arith
Properties
to be
Assert
Verified
Rewriter
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

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)

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)

Emulation
(Subir K. Roy)

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.
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
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.
Emulation Flow
Error
Verilog Gate
Behavioral Netlist
RTL Level
Simulation Synthesis
Code Simulation
•Clock Analysis •System Setup •ICE Setup

•Import Netlist
•Constraint •Vector Translation •Target Interface
•Generate Memory
•Design Partition •Vector Debugging •Logic Analyzer Setup
Emulator Environment In Circuit

Emulation

Total Emulation System
Host LAN
Emulation
Hardware
Target
Interface WorkStation
Module
Target ViewStore
PC
Board
Target
System
Clock
Power
Source

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

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

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.

Quality of Verification
(Subir K. Roy)

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?

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)
• Different Coverage Metrics :
• Branch
• Expression
• FSM Arc
• Functional
• Hardware Code
• Path
• Signal
• Statement
• Toggle
• Triggering
• 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

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.

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

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

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?

• 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
  AG(req  AF grant)
• Captures errors in validity of specification
• Sanity checks for constraint validation (Eg.
Enabling conditions, Variable values & usage).
• 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.
• 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

• [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 }.

• [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 2v .
• 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.
• 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.

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

Academic & Research Lab
Verification Tools

Verification Tools – 1
(S. Ramesh)

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

Modeling Language
• A subset of Verilog
• VHDL and Esterel planned
• The back-end language is BLIFF-MV
Specification Language
• CTL, CTL* and Automata

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

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.

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

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

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)

Examples:
1. Old Syntax
• `request' unconstrained (input)
• non-deterministic assignment
• OBDD representation of tr. reln. constructed and
SMC performed.

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

Example - 3bit counter
• Assign sections of bit0, bit1 and bit2 execute in

parallel
• Data dependence respected

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

Example
DLX Controller
• An Esterel model
• 100s of states
• abstracted using FC2tools:

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

STeP
• Modeling Language: SPL and fair Transition
Systems
• Specification Language: LTL and First Order
Logic
• Verification Approach: Theorem Proving and
Model-checking

STeP overview
Temporal Logic Reactive System Hardware
Formula (SPL) Program Description
Fair Transition System
User
Automatic Prover
Model Bottom-up Invarient

Verification Rules
Checker Generator
Interactive
Strengthening First-order Prover Prover
of Invariants
Simplification
Propagation
Decision procedures
P- valid Counter example P- valid Debugging Guidance

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

An example SPL Program
main ::
[
in a : int where ((a 127) ^ (a > - 128))
in b : int where ((b<127) ^ (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 ]
]

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

Verification Tools – 2
(S. P. Rajan)

Fujitsu’s 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

HMC Basics: Pre- and Back-Image
• Representing sets and relations with their

characteristic functions:
• PreImage[Q] = l s.  s’. R(s,s') And Q(s')
• PreImage corresp. to EX Q in CTL.
• BackImage [Q] = ls.s’. R(s,s') => Q(s')
• BackImage (aka. Weakest Precondition) corresp.
to AX Q in CTL.

Basics: Fixpoints and Safety Properties
• Z0 = Q
• Zi+1 = Q And BackImage [Zi]
• If [  k. Zk = Zk+1] then [Zk = nZ. (Q And
BackImage [Z])]
• This fixpoint corresp. to AG Q
• If initial states Q0 is a subset of Zk, then Q is a
safety property.
• Otherwise, a counterexample trace exists,
starting in Q0 \ Zj,
• where Zj is the first Zi s.t. Q0 is not a subset of
Zi
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.

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.

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

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 StateSpace
Exploration

How does VeriSoft work?
• VeriSoft looks simple! Why did we have to

• wait for so long (15 years) to have it?
• Existing statespace exploration tools are
restricted to the analysis of models (i.e., abstract
descriptions) of software systems.
• Each state is represented by a unique identifier.

How does VeriSoft work?(contd.)
• During statespace exploration, visited states are

saved in memory (hashtable, BDD,...).
• With programming languages, states are much
more complex!
• Computing and storing a `ùnique identifier'’ for
each state is unrealisitc!

StateLess Search
• Idea: perform a stateless search!

• still terminate when state space is acyclic
• Equivalent to ``statespace caching'' with an
empty cache: this search technique is terribly
inefficient! [H85,JJ91]

An Efficient StateLess Search
• [GHP92]: Redundant explorations due to state-

space caching can be strongly reduced by using
Sleep Sets [G90], and ``partialorder methods'' in
general [G96].
• VeriSoft: original algorithm combining stateless
search, sleep sets [G90,GW93], conditional
stubborn sets [V90,GP93,G96].

An Efficient StateLess 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!

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

Industrial Applications
• Examples of Applications: (within Lucent

Technologies)
• 4ESS HeartBeat Monitor analysis (debugging,
reverseengineering).
• Wavestar 40G integration testing (testing).
• Automatic Protection Switching analysis
(interoperability protocol testing).

Conclusion
• VeriSoft (tool + approach) can find bugs in
nontrivial concurrent/reactive software system.
• 1. Concurrent/reactive/realtime 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.

Case Studies

Case Study 1
(S. P. Rajan)

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)

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

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

Motivation: Design Change
• Changes in design require revalidation

• Revalidation expensive
• TAT too long
• Design cycle cost expensive

Typical ATM Switch Fabric
2 x 2 Switch 2 x 2 Switch
2 x 2 Switch 2 x 2 Switch

ATM Switch Architecture
HW_clk|SW_clk: Multiple Clocks
iHW0/1 oHW0/1
S/P Cell FIFO P/S
RAF0
Write Read
Control Control
(WC) RAF1 (RC)
WAF
Cell Counter
(wBC)
Copy Cell
Flag ccf

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

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

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

Complexity of Design Spec
• ~ 20 Communicating Processes
• ~1500 lines of VHDL code at high-level
• ~20000 lines of VHDL at gate-level after synthesis

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

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

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

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
Synthesis: Generic Clock Ratio
Clk Ratio Ports Nets Cells Area (bc) delay (ns)
3 118 59362 52243 93580 223

4 118 62578 55259 97506 223
5 66245 58688 102208 223
118
6 118 69203 61376 107484 223
 Area and delay of synthesized ATM switches different clock ratios

 Fujitsu CS35R technology
 Number of ATM input ports = 2 and ouput ports = 2
Synthesis: Generic Clock Ratio
Clk Ratio Ports Nets Cells Area (bc) delay (ns)
3 118 59362 52243 93580 223

4 118 62578 55259 97506 223
5 66245 58688 102208 223
118
6 118 69203 61376 107484 223

Synthesis: Generic number of in/out ports
 Area and Delay of Synthesized ATM Switches

 Varying number of input/output ports
 Fujitsu CS35 technology
 Clock ratio = 3

Formal Verification
 Overall correctness property - Input cells

switched to proper output ports,- The order of
input cells is maintained at the output.
 ATM is a complex design:-- Compositional
verification technique: verify ATM modules
separately and compose
 Verification of the generic parametric model
automatically implies the verification of a family
of ATM designs

Formal Verification : Bugs found
 Address pointers to WAF not initialized to 0

 Analysis by model checking in PVS
 Mistake due to hidden assumptions in synthesis
 Counter-example generated
 Combined with other verified modules

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

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

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

SP Conversion:Formal Verification
• theorem2: THEOREM % When clk rising edges

are synchronized
FORALL (n:posnat):FORALL (i:nat|i<n):
sp(0,n) AND to_fifo(n,n) IMPLIES
iHW0_word(n)(i) = iHW0_cell_word(i)

SP Conversion:Formal Verification
• Finaltheorem: THEOREM % When clk rising

edges need not be synchronized
FORALL (n:posnat): FORALL (i:nat|i<n):
sp(0,n) AND to_fifo(n,n) IMPLIES
EXISTS (t:time | n <= t AND t <= 2 * n)
iHW0_word(t)(i) = iHW0_cell_word(i)
• Proof by induction and rewriting:

14.8 Secs on Sparc-20, 64 Meg RAM

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

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

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

Case Study 2
[Formal meets semi-formal]
(T. Nakata)

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

Divide-and-Conquer Verification
• Isolate a module using formal I/F specification
• Verify a module by integrated verification tools
I/F specification
MPU DSP Module
I/F Pattern/property gen.
Integrated
ROM Module verification
DRAM I/O engine
GDC Checker

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

Verification Flow
Design Black-box
White-box Verification
under spec.
spec. scenario
verification I/F spec.
I/F specification language
Design Input
Properties Scenarios
model constraints
Integrated verification engine

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
Verification of MU (1st)
41 constraints
4 properties
I/F spec. HDL

Test
Testpatterns
pattern
augmented MU
by
Insufficient
0-In Search
constraints
Result: Many design errors detected, but all from input

patterns that do not satisfy input constraints
Verification of MU (2nd)
Pseudo models
(I/F spec. lang. and HDL)
Test
Testpatterns
pattern I/F spec. HDL
augmented
by
MU
0-In Search
Result: A known error in interlock logic and

an unknown error in decoder detected
Detected Error
• Indicator of no hazards “e-wait” may be asserted
under a certain hazard condition
• Length of augmented* patterns: 7 cycles
* By 0-In Search
clock
m0_valid
m1_valid
i0_valid
m0_rd xxx 0xf
m0_rs1 xxx 0x0
m1_rd 0x0
i0_rd xxx 0x0
e_wait

Summary of MU Verification Flow
M-Unit Properties Constraints Pseudo Test
(HDL) (I/F spec) (I/F spec) (HDL) vectors
Converter
Properties/constraints
(HDL+0-In Check)
0-In compile
Design 0-In Search

database

Verification of Instruction Decoder
• Instruction decoder
• Complete verification required
• 200 registers Model checker
• 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

Decoder Verification Flow
M-Unit Properties Constraints

decoder (I/F spec) (I/F spec)
(HDL)
Model checker
Note:
No abstraction/
reduction required
in this example

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
Lines
MU (HDL) 14,320
Pseudo (HDL) 1,518
Constraints (I/F spec. lang.) 1,818
Properties (I/F spec. lang.) 118
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

Commercial Tools
(Subir K. Roy)

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

Assume & Guarantee - Basic Idea
Global Property defined on o2
o1
i1 o2
P Q
i2
Decompose
Guarantee Assumption
o1 o1
P Q
i2 i2
Assumption Guarantee

Smarter Simulation
[Gupta, Malik & Ashar, DAC 97]
Design Spec
Behavioral (Behav Level
simulator Description)
Function Test Set =? Validation
RTL Design Implmt

Test simulator (RTL Level
Set Description)
Generator
Test Model

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

FormalCheck
Block System
Constraints
= Properties
Interface
Target System
Blocks Blocks
Block = System
Properties Constraints

FormalCheck Architecture
Chip, Blocks, IP Models
In Verilog or VHDL
Gates Autorestrict
Template-Based RTL Probabilistic
Query Inputs
Large Model
Query Formal Model Early Model
Capture
Query-Specific
Reduction Results &
Error Traces
Query
Template
Results Display
Library
Inputs Outputs

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.

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

• Allows Internal Checks - Provides a handle to the IP
integrator to analyze failures in IP after integration.
Protocols
SPEC I/O Relationships
CONSTRAINTS Context Dependencies
Input Definition
Next Cycle’s Stimulus

TEST CONSTRAINT
CONSTRAINTS SOLVER
HDL SIMULATION
Target Areas Current Cycle’s HDL
Weights/Probabilities
Corner Case Tests Signal & Register Values
Structured Sequences

e-language
e-language e-language
Bus Functional Model
Monitor
Coverage
&
Collector
Protocol Checker Verilog
e-language BLOCK e-language

Monitor
Coverage
& Verilog
Collector
Protocol Checker
BLOCK
e-language e-language
Monitor
Coverage
&
Collector
Protocol Checker
Bus Functional Model
e-language

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)

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

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.

0_inSearch Verification Flow
Verilog RTL Verilog RTL Verilog Tests

with with &
Directives Checkers Test Benches
Checker Checker Verilog Firing

Library Generator Simulator Messages
in
Verilog o/p
Captured
Simulation Files
Seed
with Checkers
Values
Information
Semiformal on
Amplification New Firings
Tool

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.

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.

Issues & Challenges
&
Future Research Topics

High Level Specification and Modeling
(T.Nakata)

Why Specification?
• Specification errors/misunderstandings take 50% of
SoC design man-power.
• Verification tools can’t handle such errors enough.
Design man-power for SoCs
Wrong Misunderstanding Simple
Verif. Verification 70% Others
Spec. Of Spec. mistakes
tools
Spec.
design
support

Issues in Specification and Verification
Idea and/or Specification Design data SoC

requirement
Validation
Wrong Misunderstanding
Formalization
Does specification
specification Isof
specification defined
specification
match requirement? clearly?
We need:
• Methodology for specification analysis
• Standard language with formal semantics
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

Object-Oriented Analysis
• For system architect to understand “WHAT” to
design not “HOW”
Requirement Use-case
Interview with Scenario

Analysis
customers Structure
Docs on existing
Behavior
systems

UML and Object-Oriented Analysis
Use-case Sequence
diagram diagram
Requirement Use-case Use-case
Interview with Scenario Scenario

Analysis
customers Structure
Structure State diagram
Class
Docs on diagram
existing
Behaviour Behavior
systems

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

Error Correction
Message
Sent word Received word
Channel
Encoder Noise Decoder
Systematic Errors
code

Analysis and Design Flow
• Step 1 Extract concepts
• Step 2 Build structure
• Step 3 Enumerate scenarios
• Step 4 Identify hardware modules

• Step 1 Extract 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

Use-Case Diagram of Error Correction
<<extend>>
Encode Encode A
Sender <<extend>>
Send Encode B
Receiver
Receive
Decode A <<extend>>
Decode
Channel
Decode B <<extend>>

• Input: use-case diagram
• Flow:
• Refine use-cases
• Extracting concepts --- candidates of
classes
• Define and relate classes
• Output: class diagram
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

Concept Extraction
• Classifying classes and properties
Received word Decoded word Code word

Message length Error location polynomial
Syndrome polynomial Code Degree Root
Syndrome Generator polynomial Coefficient
Properties
Generator matrix Parity Error Block code
rather than
Galoisclasses
field Element LFSR Code length

Relationships among Classes
Vector
{Word-wise} Code word

Code B
{Bit-wise}
Code word Code A
Message Systematic
word code
Code A is a special Data structure is deduced
case of Code B. from relationships.

Class Diagram
Decode
Coefficient * Polynomial
Root *
Received word
Input Received
code
polynomial
Galois field
Error location
polynomial
Syndrome

• 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
Sequence Diagram for Decode
r1:received word :received polynomial :error location polynomial
Input
Receive
Assign(r1)
Generate()
s1: syndrome
IsZero()
Calc_coef(s[])
Calc_loc(coef)
Correct (location, value)
Calc_error(root)
Complete Class Diagram
Decode
Input for A Input Coefficient * Polynomial
+Receive() +Receive()
Root * +Assign(val)
Input for B
Received word Received
+Receive()
-Code length code
-Corrections polynomial
Galois field +Correct(loc, val)
Error location polynomial
+Order
+Calc_coef(syndrome)
+sum() Syndrome * -Calc_loc(coef)
+multiply()
+divide() -Index
+exp(power) -Value
+IsZero() Error loc. poly. for A Error loc. poly. for B
-Calc_error(root) -Calc_error(root)
• 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)
Methods to Hardware Modules
• Disband classes
• Map each methods to modules
• Re-bundle modules if possible
Error loc. poly.
Coefficient calculator
+Calc_coef(syndrome)
-Calc_loc(coef) Error loc. calculator
Galois field
+Order Galois adder
+sum()
...
+IsZero()
Galois 0 checker

Initial Block Diagram
Decode
Assignment module Coefficient
Receiver
for received poly. calculator
Receiver Receiver Received

for Code A for Code B Syndrome
-Codeword
length -Index
Correction -Corrections -Value
module
Error Root
Error info Coefficient
calculator
-Location
-Value
Location
Galois adder Error calculator Error calculator calculator
Galois
Galois adder
Galoisadder
adder for Code A for Code B

From Messages to Interface
Assignment module for
received polynomial
+clock: input
+received word: input
Received word Syndrome
+syndrome:
+reset: inputoutput
- Code length +enable: input - Index
- Corrections +received word: input - Value
+syndrome: output
HW
design
C++ / HDL
Block Diagram of Decoder
Correction
Code A
receiver
Assignment
Code B
receiver
Error location
Coefficient calculation for
calculation Code A
Error location
Location calculation for
calculation Code B
enable
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)
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
Issues & Challenges
(S. Chakraborty)
(S. P. Rajan)

Where do we stand?
Model
checking Based on Dill and Tesiran’99
C FSM-based
o generation
v Symbolic
simulation
e
r
a
g
e Manual test
w/ coverage
Random
Scale (gates) simulation
1 FSM 50K 250K 2M

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

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

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?

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

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?
Summary & Conclusions
(S. Chakraborty)
(Subir K. Roy)

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
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 can’t afford to miss a
bug
• Success stories: Protocols, FSMs, specific
processors, floating point arithmetic etc.

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.

Bibliography

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.
VLSI/ASPDAC : Tutorial on 364
Functional Verification of SoCs
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, `Àn 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, `ÌP-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.

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.

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, `Àutomatic 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, `Àutomatic 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.

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, 207—212.

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

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

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

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

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.

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)

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)

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)

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

Appendix

Formal Modeling
(S. Ramesh)

Non-determinism (another example)
• 3- floor elevator controller, Si - in floor i

• ri - request from floor i
• This machine is also nondeterministic
• In S2 state when r1 and r3 arrive.
Formal Specification
(S. Ramesh)

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
• Of - next f
• state formulae - no temporal operators

Semantics
• Formulae interpreted over infinite sequences of

states
• States evaluate state formulae
• Let s = q0, q1 , … be a sequence
• Each qi assigns truth values to atomic
propositions
• Semantic definition defines when a formula
satisfies a sequence

Semantic Definition
• Notation: s ╞ A
stands for A holds in s.
• s ╞ A iff (s ,0) ╞ A
• (s , j) ╞ A - defined inductively
• Base case:
(s , j) ╞ f for any state formula f iff f holds in
the state s [j]

Semantics of Temporal Operators
• □(s , j) ╞ □f iff k j, (s, k) ╞ f

Semantics Contd.
• (s , j) ╞ ◊f iff k  , ( s ,k) ╞ f

Semantics Contd.
• (s , j) ╞ f U g iff k  j : (s, k)╞ g and

i s.t. j  i < k, (s, i)╞ f

Semantics Contd.
• (s , j) ╞ f W g iff (s , j) ╞ f U g or
(s , j) ╞ □ f
• (s , j) ╞ Ο f iff (s , j + 1) ╞ f

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

Examples - Properties
• □¬(farm_go high_go)
• □ (farm_car  ◊ farm_go)
• □ (mem_rd  ◊ mem_ack)
• □ (mem_rd  mem_rd W mem_ack)

w- 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, S, , q0 , A >
• Q - finite no. of states
• S - Edge labels
• q0 - initial state
•  Q x Sx Q
• A  Q, Accepting (not final) states

Behavior of w- 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 q0, q1,… s.t.
• (qi, li, qi+1) Є  for i = 0, 1, …
• there is an accepting state that occurs infinitely
often in s.

Examples
• All sequences containing only 1.

• An infinite set of infinite sequences!
• But finite description

Examples contd.
• All sequences that has at least one occurrence of

1

Examples contd.
• Sequences containing all but finitely many

occurrences of 1s

Examples contd.
• All sequences containing infinitely many 1s

Features of w- automata
• useful for specifying properties and constraints
• precise and unambiguous
• consistency can be checked (Emptiness of automata)
• has many properties useful for verification:
• w - languages closed under union, intersection
and complementation

Model Checking
(S. Ramesh)

LTL Model Checking
(Pnueli, Lichtenstein, Vardi, Wolper)
M╞ F
Read: M `contains' only models of F
• M a finite state system or an w-automaton
• F a linear TL formula
• M defines a set of infinite state sequences LM and
F another set of sequences LF .
• Checking M╞ F amounts to checking LM  LF
• Hence referred to as language containment
problem

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

LTL Verification Method
• Two related Methods:
• Tableau – based
• Automata – based

Automata based Method
• Obtain an w-automaton for the negation of the
formula
• Take the product of system model and w-
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

Example
1. To check whether this is a model for □ P,

construct first a w- Automata for ◊¬p

Example contd.
 Construct the product of the two automata:
• No reachable accepting cycle
• It is a model of □ p.
Another Example
 Check whether the following automaton satisfies □
◊¬p
w- Automata for : ¬( ◊ □ ¬p)

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
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
Binary Decision Diagrams
(S. Chakraborty)

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
Neat Tricks in BDD Packages
f = x1.x2 + x3’
• Complement edges x1
• If a vertex is reached by a x2
complement edge, take the x3
complement of the function
0 1
represented by the vertex
• Simplifies complementation f = (x1.x2’x3’ + x1’x3)’
• Saves duplication of computation
• Hash Tables and Caches x1
x2
• Facilitates identifying ROBDD node
x3
for an already computed function
0 1
• Avoids computation duplication
Academic & Research Lab
Verification Tools
(S. Ramesh)

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
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
}
An Example Promela Program
proctype merge()
{ short y
do :: if
:: out1?y
:: out2?y
fi;
out!y
od
}
init {run split(); run merge() }

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

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

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

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 }

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

Appendix
High Level Specification and Modeling
(T. Nakata)

UML : Use-Case Diagram
• Define system functions from users’ view
Use-case
Actor Vending machine
Buy a juice
Customer
Refill products
Supplier
Gather changes
Services

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
Send
Choose juice Equal to price
Emit a can of juice

UML : Class Diagram
• Describe static aspects of a system by
relationships among classes
• A class represents a “concept” in a system
Employee PC
uses
Name: string Name: string
ID: integer 0..1 1..* CPU: string

UML : State Diagram
• Describe states and their transitions of objects
• Almost the same as hierarchical FSMs
Ground Up(fl) Ascend
floor to floor fl
Arrived Up(fl)
Descend Arrived
to floor fl Stop
Down(fl) timer=0
inc timer
[timer=time_out]/Down(0)

Soc

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Soc

Caricato da

Copyright:

Formati disponibili

ASPDAC/VLSI 2002 Tutorial

Functional Verification of System on Chip - Practices,

ASPDAC / VLSI 2002 - Tutorial 1

ASPDAC / VLSI 2002 - Tutorial 2

ASPDAC / VLSI 2002 - Tutorial 3

ASPDAC / VLSI 2002 - Tutorial 4

ASPDAC / VLSI 2002 - Tutorial 5

ASPDAC / VLSI 2002 - Tutorial 6

ASPDAC / VLSI 2002 - Tutorial 7

ASPDAC / VLSI 2002 - Tutorial 8

• Motivation & Introduction to SoC Design & Re-use

ASPDAC / VLSI 2002 - Tutorial 9

• Techniques for Module Verification

ASPDAC / VLSI 2002 - Tutorial 10

• Implementation of Formal Approaches

ASPDAC / VLSI 2002 - Tutorial 11

• Quality of Functional Verification (Subir K. Roy)

ASPDAC / VLSI 2002 - Tutorial 13

ASPDAC / VLSI 2002 - Tutorial 14

• Issues and Challenges / Future Research Topics

ASPDAC / VLSI 2002 - Tutorial 15

ASPDAC / VLSI 2002 - Tutorial 17

Higher-Order Theorem Proving

First-Order Theorem Proving

ASPDAC / VLSI 2002 - Tutorial 19

ASPDAC / VLSI 2002 - Tutorial 20

ASPDAC / VLSI 2002 - Tutorial 21

ASPDAC / VLSI 2002 - Tutorial 22

ASPDAC / VLSI 2002 - Tutorial 23

ASPDAC / VLSI 2002 - Tutorial 24

• Co-design approach : Software + Hardware

ASPDAC / VLSI 2002 - Tutorial 25

ASPDAC / VLSI 2002 - Tutorial 26

• Vendor Based Approach : ASIC Vendor/Design

ASPDAC / VLSI 2002 - Tutorial 27

ASPDAC / VLSI 2002 - Tutorial 28

• Short Time To Market (pre-designed)

ASPDAC / VLSI 2002 - Tutorial 29

ASPDAC / VLSI 2002 - Tutorial 30

ASPDAC / VLSI 2002 - Tutorial 32

ASPDAC / VLSI 2002 - Tutorial 33

ASPDAC / VLSI 2002 - Tutorial 35

Fixed Parameters Fixed Parameters

• Parametric Design Methodology:

ASPDAC / VLSI 2002 - Tutorial 37

ASPDAC / VLSI 2002 - Tutorial 38

ASPDAC / VLSI 2002 - Tutorial 39

ASPDAC / VLSI 2002 - Tutorial 40

ASPDAC / VLSI 2002 - Tutorial 41

ASPDAC / VLSI 2002 - Tutorial 42

ASPDAC / VLSI 2002 - Tutorial 44

ASPDAC / VLSI 2002 - Tutorial 45

• Theoretically most powerful technique

ASPDAC / VLSI 2002 - Tutorial 46

ASPDAC / VLSI 2002 - Tutorial 47

• FSM based methods : ~ 500 registers

ASPDAC / VLSI 2002 - Tutorial 49

ASPDAC / VLSI 2002 - Tutorial 50

ASPDAC / VLSI 2002 - Tutorial 51

• Simulation/Testing cannot be dispensed with!

• Enable abstract and high level descriptions

• Finite State Machines

ASPDAC / VLSI 2002 - Tutorial 55