Functional Verification of System on Chip

8/10/2019 Functional Verification of System on Chip

http://slidepdf.com/reader/full/functional-verification-of-system-on-chip 1/73

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

Degree of Automation

Coverage/

Expressive

Power

Simulation

Equivalence Checking of

structurally similar circuits

Equivalence Checking

Assume-Guarantee based

symbolic simulation/Model Checking

Temporal Logic Based

Model Checking

First-Order Theorem Proving

Higher-Order Theorem Proving



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

OK

Modify RTL Source

Simulation +

Formal Verification

RTL/logic Synthesis

Timing Analysis

Modify Script

RTL Description(from Spec/Doc)

NOT 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

Validate

Generic Parameters

Cycle Accurate Behavior Cycle Accurate Behavior

Fixed ParametersFixed Parameters

Gate-Level

(Large Design)

Gate-Level

(Small) Validate

Chip Chip

Instantiation

High/RT-Level Synthesis

Logic Synthesis

ValidateCycle Accurate Behavior

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



Formal Methods

– Functional verification

– SOC context: block level verification, IP Blocks andbus protocols

– Formally check a formal model of a block againstits 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

Lang. Containment

Obs. Equivalence

Automata/ Tr.

Systems

Th. ProvingEq. Checking

Model CheckingLogic

LogicTr. Systems/

Automata

Model

Spec



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.

M d l h ki /L



Model checking/Language

Containment•

Another promising automatic technique• Checking design models against specifications

• Specifications are temporal properties andenvironment 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 levelverification): – 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 andpredicates

• 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 SN i=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 * coutProof : Use properties of boolean and arithmeticoperators.



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

• Given two combinational designs

– Same number of inputs and outputs

–

Determine if each output of Design 1 is functionallyequivalent to corresponding output of Design 2

– Design 1 could be a set of logic equations/RTL

– Design 2 could be a gate level/transistor level circuit

Design 1 Design 2

Right Fit for REDUCED ORDERED Binary



• 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

Right Fit for REDUCED ORDERED Binary

Decision Diagrams(ROBDDs)

Design 1

Design 2

F

Designs functionally equivalentif and only if F is identical to 0

(0 for all inputs)



ROBDDs in Equivalence Checking

•

Problem reduces to checking F forunsatisfiability

– If ROBDD has a non-leaf vertex or a 1 leaf, F is

satisfiable

– But there are problems …

• For 32 bit multiplier, there are 64 inputs and BDD blows

up

•

Same is true for other real-life circuits• Interestingly, several of these are actually easy to check

for equivalence



ROBDDs in Equivalence Checking

• Something smarter needed … – Worst case must still be exponential complexity

• Unsatisfiability: co-NP complete!



Using Structural Information

•

Structural similarities between designs help

– If A1 equivalent to A2 & B1 equivalent to B2, Design1equivalent to Design2

– Simplifies equivalence checking

– But consider

B1 not equiv to B2, but Design 1 equiv to Design 2

A1 B1 A2 B2

A1 B1 A2 B2

U i St t l I f ti



Using Structural Information• False negative

Analysis indicates designs may not be equivalent, butdesigns are actually equivalent

• Use logical implication to reduce false

negatives – If out1 is not equivalent to out2, out1 out2 is satisfiable

– Express out1 out2 in terms of internal signals in design1 and

design2

Design 1

Design 2

FInternalsignals



Method of Implication•

Derive set of internal signals that must be notequivalent if out1 out2 is satisfiable

– Propagate implications back towards inputs

– Stop when

• Primary inputs reached

– Two primary inputs never equivalent

– So, out1 out2 is satisfiable



Method of Implication

– Stop when

• Internal signals reached are known to be equivalent

– Conclude out1 out2 is unsatisfiable

– So, out1 is equivalent to out2

– Some pairs of signals can be quickly identified as

not equivalent by random simulation



Structural Simplifications• Once two internal signals are found

equivalent, the circuit can be simplified – Suppose outputs of corresponding AND gates are

equivalent

Helps reduce size of circuit to deal with later



An Efficient Equivalence Checker• Finds pairs of equivalent signals in two designs

[Matsunaga ‘96+ CEP: Candidate

equivalentpairs

VEP: Verifiedequivalentpairs

Start

Random simulation CEP list

More pairsto verify?

Verify pair, update VEP list

and CEP list,Restructure circuit

Check if primary outputpair is in VEP list

End

NO

YES



Some Observations• Most non-equivalent pairs filtered by random

simulation

• Equivalent pairs identified early by proper choice ofinternal variables when propagating implicationsbackwards

– If pair under investigation is expressed in terms of alreadyknown 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 orincremental modification, NOT design error



Checking Arithmetic Circuits•

Equivalence checking of multipliersacknowledged 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 otherarithmetic circuits

l h l



Sequential Machine Equivalence• Restricted case: Reduces to combinational

equivalence• Given machines M1 and M2 with

correspondence between state and outputvariables

– Checking equivalence of M1 and M2 reduces toequivalence checking of next-state and output logic

CombLogic1

FF

CombLogic2

FF

Given Equivalence



Equivalence Checking - Extensions•

For best results, knowledge about structurecrucial

– 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

• Finite state transition graph

• Flip-flops with next-state logic

• Transition relation between present and next states

– A property in specialized logic

• Prove that MODEL satisfies SPECIFICATION

– In case of failure, counterexample desirable

MODEL

SPECIFICATION



Example: 3-bit Counter

Model• State transition graph

defined by

X0 = NOT( x0)

X1 = XOR( x1, x0)

X2 = XOR( x2, x0. x1)

x2

x1

x0X0

X1

X2

Property

• State x0, x1, x2 = 111is reached infinitely

often starting from

state 000

B i A h



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

M d l Ch ki



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 x

0, x

1, x

2 = {000,010, 011, 001} can be represented by S ( x0, x1, x2) = S( x) = x0’ .

BDD:

• Set of state transitions can be represented

by N ( x0, x1, x2, X0, X1, X2) = N ( x, X) =(X0 ↔ x0’ ) (X1 ↔ x1 x0)

(X2 ↔ x2 ( x1. x0))

1 0

x0

1 0

x0

F d R h bilit



Forward Reachability

• Start from set S0 of states

• Set of states reachable in at most 1 step:

S1 = S0 { X | x in S0 N( x, X) = 1}

Expressed as Boolean functions:Given S0 ( x0, x1, x2),

S1 (X0, X1, X2) = S0 (X0, X1, X2)

x0, x1, x2 . [S0 ( x0, x1, x2)

N( x0, x1, x2, X0, X1, X2)]

Given BDDs for S0 and N, BDD for S1 can be obtained

S1 S0



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

modificationsZ0



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

R

Z

S0

Z

B

Forward Reachability Backward Reachability

CTL Properties



CTL Properties• “Once req goes high, grant eventually goes high”

–Not expressible as safety property

• Use formulae in Computation Tree Logic (CTL)

• CTL formulae at state S0

Atomic proposition: x1 = x2 = x3 = 0AG 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 holdsfinally, and f holds until then

S0

Computation tree

of states

More on CTL



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 infinitelyoften 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 graphrepresentation *Clarke et al ‘86+

– Linear in graph size and formula length

•

Burch, Clarke, Long, McMillan, Dill gave algorithmfor CTL model checking with BDDs [Burch etal’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 squaringExponential 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 raiseflag?”

Related techniques



Related techniques

• Model checking for bugs

Prioritize state space search to direct ittowards bugs

• Start from error state and current state

•Compute pre-image of error states & image of currentstate

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

Compute approximations to reachable states

– Potentially smaller representation – Over-approximation :

• No bugs found Circuit verified correct

• Bugs found may be real or false

– Under-approximation :• Bug found Real bug

• No bugs found Circuit may still contain bugs

Reachable states

Buggy states



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

NSPS

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

– Designs with bugs being produced

–FV methods haven’t yet been able to scale to alltypes of industry designs

– Fundamental complexity limits restrict how muchFV can do

• Need some viable alternative• Use a hybrid of testing, simulation and formal

methods to fill the gap

Functional Verification of System on Chip

Documents

Transcript of Functional Verification of System on Chip