soc verification ( 晶片系統驗證 )

SoC Verification (晶片系統驗證 )

Pao-Ann Hsiung (熊博安 )[email protected] http://www.cs.ccu.

edu.tw/~pahsiung/嵌入式系統實驗室

國立中正大學資訊工程學系

Pao-Ann Hsiung, CSIE, National Chung Cheng University2

Contents Introduction 3 ~ 26 Formal Verification 27 ~ 38

Model Checking 39 ~ 73 Equivalence Checking 74 ~ 83

Verification Tools 84 ~ 86 Verification Example:

Industrial Embedded SoC 87 ~ 98 Conclusion & Future Work 99 ~ 100


Introduction

M O O R E’ S L A W

Process Technology 0.25 um 0.18 um 0.15 um

1998 1999 2001

Silicon Complexity 1 M Gates 2~5 M Gates 5~10 M Gates

Deep Sub-Micron (DSM) Technology


IntroductionChallenges in DSM technology for SoC: Timing Closure

Sensitive to interconnect delays Large Capacity

Hierarchical design and design reuse Physical Properties

Signal integrity (crosstalk, IR drop, power/ground bounce)

Design integrity (electron migration, hot electron, wire self-heating)


Introduction

Design Productivity

Gap

Gates / Chip

Gates / Hour

1990

1995

2000


Introduction

Time-to-Market (TTM) Trends


IntroductionMultiple Design

Disciplines: Digital HW

Embedded SW

Analog/Mixed Signal (AMS) Blocks

Bus Architectures

Clock / Power Distributions

Test Structures


Introduction

SoC Verification v/s Design Gap


Verification Options

Simulation Technologies

Static Technologies

Formal Technologies

Physical Verification and Analysis


Simulation Technologies Event-based Simulators Cycle-based Simulators Transaction-based Simulators Code Coverage HW/SW Co-verification Emulation Systems Rapid Prototyping Systems Hardware Accelerators AMS Simulation


Static Technologies

Lint Checking Syntactical correctness Identifies simple errors

Static Timing Verification Setup, hold, delay timing

requirements Challenging: multiple sources


Formal Techniques Theorem Proving Techniques

Proof-based Not fully automatic

Formal Model Checking Model-based Automatic

Formal Equivalence Checking Reference design modified design RTL-RTL, RTL-Gate, Gate-Gate

implementations No timing verification


Physical Verification & AnalysisIssues for physical verification: Timing Signal Integrity Crosstalk IR drop Electro-migration Power analysis Process antenna effects Phase shift mask Optical proximity correction


Comparing Verification Options


Comparing HW/SW Coverification Options


Which is the fastest option? Event-based simulation

Best for asynchronous small designs Cycle-based simulation

Best for medium-sized designs Formal verification

Best for control-oriented designs Emulation

Best for large capacity designs Rapid Prototype

Best for software development


SoC Verification Methodology

System-Level Verification SoC Hardware RTL Verification SoC Software Verification Netlist Verification Physical Verification Device Test


SoC Verification Methodology


Verification Approaches

Top-Down Verification

Bottom-Up Verification

Platform-Based Verification

System Interface-Driven Verification


Top-Down SoC Verificationverifi

catio

n


Bottom-Up SoC Verification

verifi

catio

n

Components, blocks, units

Memory map, internal interconnectBasic functionality, external interconnectSystem level


Platform Based SoC Verification

Derivative Design

Interconnect Verification between:

SoC Platform Newly added I

Ps


System Interface-driven SoC Verification

Besides Design-Under-Test, all others are interface

models


Device Test

To check if devices are manufactured defect-free

Focus on structure of chip Wire connections Gate truth tables Not functionality


Device Test

Challenges in SoC device test: Test Vectors: Enormous! Core Forms: soft, firm, hard, diff tests Cores: logic, mem, AMS, … Accessibility: very difficult / expensive!


Device Test Strategies Logic BIST (Built-In-Self-Test)

Stimulus generators embedded Response verifiers embedded

Memory BIST On-chip address generator Data generator Read/write controller (mem test algorithm)

Mixed-Signal BIST For AMS cores: ADC, DAC, PLL

Scan Chain Timing and Structural compliance ATPG tools generate manufacturing tests automatically

Formal Verification


What is Formal Verification?

An analytic way of proving a system correct no simulation triggers, stimuli, inputs no test-benches, test-vectors, test-cases

Deductive Reasoning (theorem proving)

Model Checking Equivalence Checking

Formal Verification Methods


Theorem Proving

Uses axioms, rules to prove system correctness

No guarantee that it will terminate Difficult, time consuming: for critical a

pplications only


Model Checking

Automatic technique to prove correctness of concurrent systems: Digital circuits Communication protocols Real-time systems Embedded systems Control-oriented systems

Explicit algorithms for verification


Equivalence Checking

Checks if two circuits are equivalent Register-Transfer Level (RTL) Gate Level

Reports differences between the two Used after:

clock tree synthesis scan chain insertion manual modifications


Why Formal Verification? Simulation and test cannot handle all

possible cases (only some possible ones) Simulation and test can prove the

presence of bugs, rather than their absence

Formal verification conducts exhaustive exploration of all possible behaviors If verified correct, all behaviors are verified If verified incorrect, a counter-example

(proof) is presented


Why Formal Verification Now?

SoC has a high system complexity Simulation and test are taking

unacceptable amounts of time More time and efforts devoted to

verification (40% ~ 70%) than design Need automated verification methods

for integration into design process


Increased Simulation Loads


Why Formal Verification Now?

Examples of undetected errors Ariane 5 rocket explosion, 1996

Exception occurred when converting 64-bit floating number to a 16-bit integer!

Pentium FDIV bug Multiplier table not fully verified!


Verification Tasks for SoC


Property Checking v/s Equivalence Checking


Model (Property) Checking

Algorithmic method of verifying correctness

of (finite state) concurrent systems

against temporal logic specifications

A practical approach to formal verification


Model Checking

What is necessary for Model Checking?

A mathematically precise model of the system

A language to state system properties

A method to check if the system satisfies the given properties


Model Checking

Formal model of the system Finite State Machine (FSM)

Desired behavior expressed as a set of properties (specifications) Computation Tree Logic (CTL)

Method to check properties against system Efficient FSM traversals


Formal Models of System

Any mathematically precise model that can be represented as a state transition system Finite State Machines Petri Nets (Timed) Automata Statecharts


State Transition System

a

b ac

s1

s2 s3

M(S, R, L)

S = {s1, s2, s3}

R = transition relation

L = {a, b, c}

Kripke Structure


表達能力 v/s 驗證複雜度找平衡點 !

表達能力簡單

PTIME

PSPACEEXPTIME

EXPSPACE

Undecidablenonelementary

NP

表達能力豐富

驗證問題複雜度

語言的表達能力

Formal Model v/s Verification


Property Specification Languages

Linear Temporal Logic (LTL)

Computation Tree Logic (CTL) Timed Computation Tree Logic

(TCTL) 7 ms


CTL – Computation Tree Logic Path quantifiers

A (for all computation paths) E (for some computation path)

Temporal operators X (next time, next state) F (eventually, finally) G (always, globally) U (until) R (release, dual of U)


CTL Formulas

Temporal logic formulas are evaluated with respect to a state in the model

State Formulas Apply to a specific state

Path Formulas Apply to all states along a specific path


Basic CTL Formulas M, s |= E X (f )

Exists a next state of s, for which f holds

M, s |= A X (f ) For all next states of s, f is true

s

f

s

f f


Basic CTL Formulas

M, s |= E G (f ) Exists a path from s, along which f holds i

n every state

M, s |= A G (f ) For all paths from s, f holds in every state,

i.e., globallys

f f

f

s

f

f


Basic CTL Formulas

M, s |= E F (f ) Exists a path from s, which eventually co

ntains a state in which f holds

M, s |= A F (f ) For all paths from s, eventually there is a

state in which f holds

s

f

s

f

f


Basic CTL Formulas

M, s |= f U g Exists a path from s, which contains a

state in which g holds and in all previous states f holds

E F (f ) = E (true U f ) A F (f ) = A (true U f )

s

g

f

f


Basic CTL Formulas

Full set of operators Boolean: , , , Temporal: E, A, X, F, G, U, R

Minimal set of operators (to express any CTL formula) Boolean: , Temporal: E, X, U


Typical CTL Formulas E F ( start ready )

Eventually a state is reached where start holds and ready does not hold

A G ( req A F ack ) Any time request occurs, it will be eventu

ally acknowledged A G ( E F restart )

From any state it is possible to get to the restart state


TCTL (Timed CTL)

A G ( req A F 7 ack )

Time Constraint: Subscript “~ c ” is added to CTL formul

as ~ {<, , =, , >} c is an integer


TCTL Example

命中z=50ms

z:=0; 修正

監控x<500msz50ms

x:=0; z:=0 x 、 z 是實數值系統時鐘。

x、 z在系統開始時，被設為零。

z 在每次監控週期，被設為零。

M, 監控 |= E F<300 ( 命中 )


Model Checking – Problem

Given: a structure M (S, R, L) and a temporal logic formula f,

find a set of states that satisfy f .

{s S : M, s |= f }


Model Checking – Explicit Algorithm Label each state s with the set label(s )

= { sub-formulas of f, which hold in s } i = 0; label(s ) = L (s ) i = i + 1; process formulas with (i -1) nes

ted CTL operators. Add processed formulas to label(s ).

Continue until closure. Result: M, s |= f iff f label(s )


Explicit Model Checking

E F (g h)

T1 = states in which g & h are true

T2 = complement of T1

T3 = predecessor states of T2


Traffic Light Controller

S

S

Farm Road

City Road

T

T

S = Sensor

T = Timer

G1 R2

R1 Y2 Y1 R2

R1 G2

C’ + T’

C T

C’ + T

C T’

Kripke Structure


Traffic Light ControllerG1 R2

G1 R2 Y1 R2

R1 G2

State Graph

G1 R2 Y1 R2

R1 G2R1 Y2

G1 R2

R1 G2Y1 R2

R1 Y2 R1 G2


Traffic Light Controller

Model Checking Tasks Safety Condition

No green lights on both roads at the same time

A G (G1 G2) Fairness Condition

Eventually one road has green light

E F (G1 G2)


Traffic Light Controller – Checking Safety Condition

A G (G1 G2) E F ( G1 G2)

S(G1 G2) = S(G1) S(G2) = {1} {3} =

S(EF(G1 G2) = S(EF(G1 G2) =

= {1, 2, 3, 4} Safety condition is

true!

G1 R2

R1 Y2 Y1 R2

R1 G2

C’ + T’

C T

C’ + T

C T’Kripke Structure

1

2

3

4


Traffic Light Controller –Checking Fairness Condition

E F (G1 G2) E(true U (G1 G2))

S(G1 G2) = S(G1) S(G2) = {1} {3} = {1, 3}

S(EF(G1 G2)) = {1, 2, 3, 4}(going backward from {1, 3}, find predecessors)

Fairness condition satisfied!

3

4

1

1

2

3


Symbolic Model Checking

Symbolic Operates on “sets of states” rather tha

n individual states Use BDD for efficient representation

Represent Kripke structures Manipulate Boolean formulas


Binary Decision Diagram (BDD) BDD: A canonical form of

representation for Boolean formulas. Motivation:

Too much space redundancy in traditional representations

BDD is more compact than truth tables, conjunctive normal form, disjunctive normal form, binary decision trees, etc.

Ordered BDD has a canonical form BDD operations are efficient


BDD v/s Binary Decision Trees

Binary Decision TreeBDD

Order: a1 < b1 < a2 < b2

2-bit Comparator


Ordered BDD (OBDD) Since OBDDs are canonical, it is easy to:

check equivalence = check BDD isomorphism check satisfiability = check BDD isomorphism

with OBDD(0) Size of OBDD depends critically on

VARIABLE ORDERING !!! 2-bit comparator example:

Change variable order to: a1 < a2 < b1 < b2

11 vertices instead of 8 for a1 < b1 < a2 < b2


OBDD (Variable Ordering)

a1 < a2 < b1 < b2

In general, for n-bit comparator:

a1 < b1 < …< an < bn

gives 3n + 2 vertices

a1 < …< an < b1<…< bn

gives 3 2n 1 vertices


BDD: Application to Verification

Equivalence of combinational circuits Canonicity property of BDDs:

If F and G are equivalent, their BDDs are identical (for the same variable ordering)

a

bc

0 1

F=a’bc + abc + ab’c

a

bc

0 1G=ac + bc

?


BDD: Application to Verification

Functional Test Generation SAT, Boolean satisfiability an

alysis Test for H=1 (0):

find a path in BDD to terminal 1 (0)

The path, expressed in function variables, gives a satisfying solution (test vector)

a

b

c

0 1

abab’c


Model Checking Issues

Completeness Model checking is effective for a

given property Impossible to guarantee that the

specification covers all properties the system should satisfy

Writing the specification – responsibility of the user



Negative Results

Incorrect model

Incorrect specification (false negative)

Failure to complete the check (too large)



Capacity State-space explosion occurs for

complex systems So, what is the use of Model

Checking for SoC? Use model checking as a

complementary technique, in addition to simulation, testing, emulation, etc.


Equivalence Checking Compares an implementation to an

existing RTL or gate-level description for functional equivalence RTL vs. synthesized gate-level implementation Gate-level design vs. revised gate-level design

Uses BDDs, a canonical representation of logic functions BDDs can grow exponentially with number of

inputs Depends on variable ordering



Features: No vectors or testbench required Capacity to handle large design Eliminates gate-level simulation Reduce time-to-market



Equivalence Checkers were used in: RTL-to-RTL RTL-to-Netlist Netlist-Netlist: some optimizations in Net

list like: CTS-inserted netlist Scan-chain-inserted netlist Post-layout netlist …….


Equivalence Checking Two circuits are functionally

equivalent if they exhibit the same behavior

Combinational Circuits For all possible input values

Sequential Circuits For all possible input

sequences

CL

Pi

CL

R

Po

Ps Ns


Combinational Equivalence Checking

Functional Approach Transform output functions into BDD 2 circuits are equivalent if their BDDs are i

dentical Structural Approach

Identify structurally similar internal points Prove internal points (cut-points) equivale

nt


Functional Equivalence

BDDs of output functions must be identical (using the same variable ordering) for functional equivalence

If BDDs are too large Cannot construct BDD, memory problem Use partitioned BDD method

Decompose circuit into smaller pieces Represent each piece as a BDD Check equivalence of internal points


Functional Decomposition

Decompose each function into functional blocks Represent each block as a

BDD Define cut-points (z) Verify equivalence of blocks

at cut-points starting at primary inputs

f2

f1

x y

z

F

g2

g1

x y

z

G


Cut-Points Resolution

All pairs of cut-points are equivalent F G

If intermediate functions f2, g2 are not equivalent, functions F and G may still be equivalent (FALSE NEGATIVE)

How to check False Negative? XOR (F, G) BDD for F G


Structural Equivalence Given 2 circuits, each with its own struct

ure Identify “similar” internal points, cut sets Exploit internal equivalences

False negative problem may arise F G, but differ structurally Verification algorithm declares F, G differ’

nt Implication Techniques Learning Techniques


Sequential Equivalence Checking

Represent each sequential circuit as an FSM Verify if two FSMs are equivalent

Approaches: Reduction to combinational circuit Isomorphism of state graphs Symbolic FSM traversal of product machi

ne


Formal Verification Tools

Model Checkers Equivalence Checkers

Academic Research Tools Commercial Verification Tools

Formal Tools Semi-Formal Tools


Academic ToolsTools Institutes

SMV CMU

MOCHA, VIS, HyTech UC Berkeley

STeP Stanford

SGM CCU & SinicaRED Academia SinicaUPPAAL Uppsala & Aalborg Univ

sKRONOS Verimag


Commercial Tools

Tools Companies

Formal Check Cadence

Formal Model Checker Avant!Formality SynopsysFormal Pro Mentor Graphics

Black Tie, Conformal LEC

Verplex Systems


Example:Formal Verification of SoC

Industrial Embedded SoC Product Korea Samsung Electronics S3C2400X ARM920T processor 16 function modules (IPs)

Reused IPs: UART, I2S, … Newly Designed IPs: bus controllers, DMA,... Newly Bought IPs: USB host controller


S3C2400X SoC


Formal Verification Methodology for SoC


Model CheckerCadence SMV (Symbolic Model Verifier) Many success stories!!! Supports SMVL and Verilog (with vl2smv) Problem size reduction:

scalarset data type for symmetric reduction ordset data type for induction subclass structure for case-splitting layer structure for compositional assume-gu

arantee verification


Modeling Problems

SMV supports only 1 implicit clock Issues in modeling in SMVL:

Multiple clocks Gated clocks Unsynchronized clocks Synchronization logic


General Strategy forModule Verification

1) Define what to verify for a module.

2) Construct the environment required for verifying each property.

3) Transform each property to CTL.

4) Check coverage of CTL properties over RTL code


Vacuous Property Checking

A G ( p A X (q) ) If p does not occur, we cannot check A

X(q) at all. Model Checker says it is verified as tru

e. We should check if p occurs at least o

nce, i.e., A G (~p) is false!


Fairness Constraint

The correctness of a module depends not only on environment, but also some specific behavior of the environment

This specific behavior is modeled as fairness constraints (input restrictions)

Also called assumptions in assume-guarantee reasoning


Reduction of Address Bus and Data Bus

Traditional approach: Abstraction:

32-bit wide bus 1-bit or 2-bits wide

Not used in SoC, because full data bus and partial address bus are used to access CRs (configuration registers)


Reduction of Address Bus and Data Bus

Different approach: Divide verification task into 2 parts:

CR accessing logic Normal operation logic

2 different environments 2 different property groups


Modules Verified

Modules CTL properties

State variables

Time (min)

AHB arbiter

27, 38 90, 80 50

Bridge 61 50 5

DMA 67 100 440

USB (mw)Host (mr)

102+4+536+4+2

N/A 9h, 43h2h, 6h


Discussions on Example

Incremental design and verification

Early stage of design: helps find real design errors

Later stage of design: helps find model and property errors

Design and verification time reduced


Conclusions Formal verification of SoC is

definitely required! But, it should be used in conjunction

with other verification techniques. Capacity of formal verification must

be enlarged for its wide-spread adoption

Techniques required: Design abstraction Verification partitioning


Future Work

Automatic abstraction & partitioning Assume-Guarantee Reasoning (AGR)

Incorporation of assertion languages: Verplex’s OVL Intel’s ForSpec etc.

IP = Verilog + OVL + AGR Hierarchical verification of SoC based

on OVL + AGR

Language Wars!!!

soc verification ( 晶片系統驗證 )

Documents