Functional Verification of System on

Chip - Practices, Issues and

Challenges

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

Coverage/
Expressive
Power

First-Order Theorem Proving

Temporal Logic Based
Model Checking
Assume-Guarantee based
symbolic simulation/Model Checking
Equivalence Checking

Equivalence Checking of
structurally similar circuits
Simulation

Degree of Automation

System Level Design Flow

Interface Definition

Component Selection
ASIC & Software Implementation
Glue Logic Implementation
PCB Layout Implementation
Integration & Validation of Software into System
Debugging
Board - Manufacturing & Test

Advantages of Core/IP based approach

Short Time To Market (pre-designed)

Less Expensive (reuse)

Faster Performance (optimized algorithms and
implementation)
Lesser Area (optimized algorithms and
implementation)

Implications on Verification
[Mosensoson, DesignCon 2000]
Verification Focus
Integration Verification & Complexity.

Bug Classes
Interactions between IP/Core/VC blocks
Conflicts in accessing shared resources
Deadlocks & Arbitration
Priority conflicts in exception handling
Unexpected HW/SW sequencing

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

Implications on Verification
Implication
Rigorous verification of each individual SoC
component seperately
Extensive verification of full system

Requirements
Efficient Verification Methodologies

Efficient Tools
High Level of Automation

System Verification

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

Generic Parameters

Validate
Validate

Instantiation
Cycle Accurate Behavior

Fixed Parameters

Cycle Accurate Behavior

Fixed Parameters

High/RT-Level Synthesis
Gate-Level

Gate-Level
(Small)

(Large Design)

Chip

Logic Synthesis

Validate = Formally Verify + Simulate

Chip

Validate

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

Techniques for
Module Verification

Formal Verification

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

Tr. Systems/
Automata
Model Checking

Automata/ Tr.
Systems

Lang. Containment
Obs. Equivalence

Logic

Th. Proving
Eq. Checking

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

Verification
by
Theorem Proving

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.

Combinational Equivalence
Checking

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 REDUCED ORDERED Binary

Decision Diagrams(ROBDDs)
ROBDD for every function is canonical
Construct ROBDDs for each output in terms of inputs
Use same variable order

Check if the graphs are isomorphic

ROBDD isomorphism is simple

Alternatively
Design 1

Design 2

F
Designs functionally equivalent
if and only if F is identical to 0
(0 for all inputs)

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

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

Random simulation

More pairs
to verify?

CEP list
NO

YES
Verify pair, update VEP list
and CEP list,
Restructure circuit
End

Check if primary output

pair is in VEP list

CEP: Candidate
equivalent
pairs

VEP: Verified
equivalent
pairs

Some Observations
Most non-equivalent pairs filtered by random
simulation
Equivalent pairs identified early by proper choice of
internal variables when propagating implications
backwards
If pair under investigation is expressed in terms of already
known equivalent pairs, we are done!

Leverage Automatic Test Pattern Generation (ATPG)

techniques to detect when a pair is not equivalent

Targets implementation error, error due to translation or

incremental modification, NOT design error

Checking Arithmetic Circuits

Equivalence checking of multipliers
acknowledged to be hard
ROBDD blowup for bit-level representation

Multiplicative Binary Moment Diagrams (*BMDs)

*Bryant, Chen 95+
Boolean assignment of variables maps to a number
(integer, rational)
Canonical representation of linear functions, e.g.
integer multiplication
Word level representation of function
Allows efficient verification of multipliers and other
arithmetic circuits

Sequential Machine Equivalence

Restricted case: Reduces to combinational
equivalence
Given machines M1 and M2 with
correspondence between state and output
variables
Checking equivalence of M1 and M2 reduces to
equivalence checking of next-state and output logic
Comb
Logic1

Comb
Logic2

FF

FF

Given Equivalence

Equivalence Checking - Extensions

For best results, knowledge about structure
crucial
Divide and conquer
Learning techniques useful for determining
implication
State of the art tools claim to infer information
about circuit structure automatically
Potentially pattern matching for known subcircuits -Wallace Tree multipliers, Manchester Carry Adders

Equivalence Checkers Out There

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

Symbolic Model Checking

Model Checking Sequential Circuits

Given:
A sequential circuit
MODEL
Finite state transition graph
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

x2
X2
X1

x1

X0

x0

Model
State transition graph
defined by
X0 = NOT(x0)
X1 = XOR(x1, x0)
X2 = XOR(x2, x0. x1)

Property
State x0, x1, x2 = 111
is reached infinitely
often starting from
state 000

Basic Approaches
Explicit state model checking
Requires explicit enumeration of states
Impractical for circuits with large state spaces
Useful tools exist: EMC, Murphi, SPIN, SMC

Symbolic model checking

Represent transition relations and sets of states
implicitly (symbolically)
BDDs used to manipulate implicit representations
Scales well to large state spaces (few 100 flip
flops)
Fairly mature tools exist: SMV, VIS, FormalCheck ...

Model Checking
Reachability analysis
Find all states reachable from an initial set S0 of
states
Check if a safety condition is violated in any
reachable state

CTL property checking

Express property as formula in Computation Tree
Logic (CTL)
Check if formula is satisfied by initial state in state
transition graph

Symbolic Model Checking

For 3-bit counter, set of states x0, x1, x2 = {000,
010, 011, 001} can be represented by S (x0,
x1, x2) = S(x) = x0.
x0

BDD:
1

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

x0

Forward Reachability
Start from set S0 of states
Set of states reachable in at most 1 step:
S1 = S0 { X | x in S0 N(x, X) = 1}

S1

S0

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

R
Z
Forward Reachability

Z
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
A[f U g]: In all paths from S0, g holds
Computation tree
finally, and f holds until then
of states

More on CTL
EG f, EF f, EX f, E [f U g] defined similarly
There exists a path from current state
f and g can themselves be CTL formulae
E.g., AG AF (x1 x2)
x1 or x2 is satisfied infinitely often in the future

Recall 3-bit counter example:

The state x0, x1, x2 = 111 is reached infinitely
often starting from 000
x0 x1 x2
AG AF (x0 x1 x2)

CTL Model Checking

Clarke, Emerson, Sistla proposed algorithm for
CTL model checking on explicit state graph
representation *Clarke et al 86+
Linear in graph size and formula length

Burch, Clarke, Long, McMillan, Dill gave algorithm

for CTL model checking with BDDs [Burch et
al94+
Suffices to have algorithms for checking EG f, EX f,
and E [f U G]
Other formulae expressed in terms of these
EF f = E [true U f]
AF f = (EG ( f))

Symbolic CTL Model Checking

Given a model with set S0 of initial states and a
CTL formula f
To determine if f is satisfied by all states in S0

Convert f to g that uses only EX, EG, 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 :
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

Buggy states

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
PI

PO

PS

NS

PI0
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

Semi-formal Verification
Formal verification still a bottleneck
Simulation and emulation not keeping up with
design complexity
Designs with bugs being produced
FV methods havent yet been able to scale to all
types of industry designs
Fundamental complexity limits restrict how much
FV can do

Need some viable alternative

Use a hybrid of testing, simulation and formal
methods to fill the gap