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

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

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

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

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

• 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

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

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

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

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

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

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

CombLogic2

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

SPECIFICATION

Example: 3-bit Counter

Model• State transition graph

defined by

X0 = NOT( x0)

X1 = XOR( x1, x0)

X2 = XOR( x2, x0. x1)

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

2 = {000,010, 011, 001} can be represented by S ( x0, x1, x2) = S( x) = 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))

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

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

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

• 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

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

A[f U g]: In all paths from S0, g holdsfinally, and f holds until then

Computation tree

of states

Functional Verification of System on Chip

Documents

Transcript of Functional Verification of System on Chip

Formal Verification for ASIC & System-On-Chip Designs

New Approach For Full Chip Electrical Reliability Verification

Industry Pulse: Trends in Functional Verification

Automated functional program verification using fixpoint fusion

Trends in Functional Verification · Trends in Functional Verification Delivering Tailored Solutions for ... Ericsson TLM in verification ... Outsourcing Jerome Bombal, TI HW-SW Co-Verification

ISO 26262 compliant verification of functional ... · ISO 26262 compliant verification of functional requirements in the MBD process - 3 - 2 ISO 26262 Software Testing and Verification

Functional Verification - Cornell University

FPGA-Centric Functional Verification - Verification … · Scotland & Ireland Designers Forum 2002 22-May-2002 FPGA-Centric Functional Verification Mark Litterick Senior Consultant,

Functional Verification of RSA Algorithm

Formal Verification of Systems-on-Chip€¦ · Formal Verification of Systems-on-Chip Slide 10 Control 1 Control 2 RT-level module verification: operation by operation n cycles Typical

Writing Testbenches: Functional Verification of HDL Modelsread.pudn.com/downloads110/ebook/455273/Writing_Test... · 2008-05-05 · x Writing Testbenches: Functional Verification

FUNCTIONAL VERIFICATION AND PROGRAMMING MODEL OF …

MODELING AND VERIFICATION OF ERP FUNCTIONAL …

[Andrew Piziali] Functional Verification Coverage (BookFi.org) 2

Automatic Verification of Higher-Order Functional Programs ...

Assertion Based Functional Verification of March Algorithm ...

Verification of Functional Programs in Scala

Reining in the Functional Verification of Complex ...

4 VERIFICATION PLAN - SystemVerilog1 Writing testbenches, Functional verification of HDL models, Janick Bergeron, Kluwer Academic Publishers 2000 2 Reuse Methodology Manual for System-on-a-Chip,

Simulation & TestBenchmtv.ece.ucsb.edu/courses/ece156A_14/lecture04-Simulation.pdf · Verification relies on simulation Full-chip functional verification relies on vector simulation