281
1 Formal verification of SoC Formal verification of SoC designs designs (targeting logic verification only) (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center VLSI Design and Education Center (VDEC) (VDEC) University of Tokyo University of Tokyo [email protected] [email protected] Lectures Lectures

1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo [email protected]

Embed Size (px)

Citation preview

Page 1: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

1

Formal verification of SoC designsFormal verification of SoC designs(targeting logic verification only)(targeting logic verification only)

Masahiro FujitaVLSI Design and Education Center (VDEC)VLSI Design and Education Center (VDEC)

University of TokyoUniversity of Tokyo

[email protected]@ee.t.u-tokyo.ac.jp

LecturesLectures

Page 2: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

2

Table of contentsTable of contents Introduction to SoC verification Introduction to SoC verification (Lecture 1)(Lecture 1) Backgrounds technology in formal verification: Methods for reasoning about mathematical Backgrounds technology in formal verification: Methods for reasoning about mathematical

models models (Lecture 2)(Lecture 2) Boolean function (Propositional logic)Boolean function (Propositional logic)

SAT (Satisfiability checker)SAT (Satisfiability checker) BDD (Binary Decision Diagrams)BDD (Binary Decision Diagrams)

Use of first-order and higher-order logicUse of first-order and higher-order logic Logic of uninterpreted functions with equalityLogic of uninterpreted functions with equality Theorem proving methodsTheorem proving methods

Basic formal verification techniquesBasic formal verification techniques Equivalence checking Equivalence checking (Lecture 3)(Lecture 3)

CombinationalCombinational SequentialSequential

Model (property) checking Model (property) checking (Lecture 4)(Lecture 4) Explicit/implicit state basedExplicit/implicit state based Bounded model checkingBounded model checking

Real formal verification toolsReal formal verification tools Enhancing Formal Verification Capacity Enhancing Formal Verification Capacity (Lecture 5)(Lecture 5)

Abstraction-refinementAbstraction-refinement Assume guarantee/Compositional ReasoningAssume guarantee/Compositional Reasoning ApproximationApproximation Symmetry reductionSymmetry reduction Partial Order ReductionPartial Order Reduction

Industrial and Research Tool OfferingsIndustrial and Research Tool Offerings Semi-formal verification techniques Semi-formal verification techniques (Lecture 6)(Lecture 6)

Advanced topicsAdvanced topics System level formal verification System level formal verification (Lecture 7)(Lecture 7)

Synchronization verificationSynchronization verification Equivalence checking for C programsEquivalence checking for C programs

Page 3: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

3

System levelSystem levelSystem levelSystem level

Lecture 1: Introduction to SoC verificationLecture 1: Introduction to SoC verification

System-on-Chip (SOC) designSystem-on-Chip (SOC) design Increase of design complexityIncrease of design complexity Move to higher levels of abstractionMove to higher levels of abstraction

1E0

1E1

1E2

1E3

1E4

1E5

1E6

1E7

Number of componentsLevel

Gate

RTL

Algorithm

Transistor

Ab

stra

ctio

n

Acc

ura

cy

Page 4: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

4

System-on-Chip (SoC) designSystem-on-Chip (SoC) design

Specification to architecture and down to Specification to architecture and down to implementationimplementation

Behavior (functional) to structureBehavior (functional) to structure System level: system specification to system System level: system specification to system

architecturearchitecture RT/IS level: component behavior to component RT/IS level: component behavior to component

micro-architecturemicro-architecture

Specification+ constraints

Memory

Memory

µProcessor

Interface

Comp.IP

Bus

Interface

Interface

Interface

Custom HW

System architecture+ estimates

ProcessorsIPs

MemoriesBusses

RTL/IS Implementation+ results

RegistersALUs/FUsMemories

Gates

Mem RFState

Control

ALU

Datapath

PC

Control Pipeline

State

IF FSM

State

IF FSMIP Netlist

RAM

IR

Memory

Page 5: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

5

13%

15%

16%

17%

17%

17%

26%

32%

32%

51%

0% 10% 20% 30% 40% 50% 60%

Delay Calculation

Synthesis

Static Timing Analysis

Design Rule Checking

System on Chip

Parasitic Extraction

Post Layout Optimization

Place & Route

Design Creation

Simulation/Design Verification

Bottlenecks in Design Cycles: Survey of 545 engineers by EETIMES 2000

Verification challengeVerification challenge

Page 6: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

6

System-level design & verificationSystem-level design & verification

Remove as many bugs as possible in the earlier stagesDo not introduce new design errors when refining designs

Formal verification in system-level designs:Property checking and equivalence checking

System-level

RTL

Transistor level

Bugs fix timeCost due to the delay/late time-to-marketrevenue loss

3 minutesdelay

3 daysdelay

3 weeksdelay

Page 7: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

7

Design representation in higher levelDesign representation in higher level Super state: Need multiple cycles for executionsSuper state: Need multiple cycles for executions Variables, functions: Boolean Integer, Term rewriting⇒Variables, functions: Boolean Integer, Term rewriting⇒

Op2 Op3

Op4

Op6

Op1

Op5PS3

PS1 PS2PS2

PS3

PS1

a = 42;while (a<100) { b = b + a; if (b > 50) c = c + d; a = a + c; }

SFSMD model

S1 S2

S3

Op2 Op3

Op4

Op6

Op1

Op5

FSMD modelDatapathcircuits

Controlcircuits

Establishmapping

Page 8: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

8

Verification methods: simulation/emulationVerification methods: simulation/emulation

SimulationSimulation Traditional, basic, and flexible techniqueTraditional, basic, and flexible technique Applicable at any design levelsApplicable at any design levels Difficulties in preparing “good” simulation Difficulties in preparing “good” simulation

patternspatterns Getting harder to cover corner casesGetting harder to cover corner cases

EmulationEmulation Can handle software simultaneouslyCan handle software simultaneously Cost and time for preparation: not ignorableCost and time for preparation: not ignorable Corner case problems still remainCorner case problems still remain

Page 9: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

9

Why formal verification?Why formal verification?

Traditional method Traditional method (testing & (testing & simulation)simulation)

Formal VerificationFormal Verification

Design UnderTest

Test vectors

Patterned vectors

SystemModel

Test properties

Testresults

Deadlock...

Trueor

False

Findcounter-example

Cannot cover all possible cases

Possibility of surviving subtle (corner case) bugs

Equivalent to simulating all cases in simulation

No bug (according to the property)

Property (model) checking and Equivalence checking

Page 10: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

10

Spec

Formal verificationFormal verification

““Prove” the correctness of designsProve” the correctness of designs Both design and spec must be represented with Both design and spec must be represented with

mathematical modelsmathematical models Mathematical reasoningMathematical reasoning Equivalent to “all cases” simulationsEquivalent to “all cases” simulations

Possible mathematical modelsPossible mathematical models Boolean function (Propositional logic)Boolean function (Propositional logic)

How to represent and manipulate on How to represent and manipulate on computerscomputers

First-order logicFirst-order logic Need to represent “high level” designsNeed to represent “high level” designs

Higher-order logicHigher-order logic Theorem proving = Interactive methodTheorem proving = Interactive method

Front-end is also very importantFront-end is also very important Often, it determines the total performance of the Often, it determines the total performance of the

toolstools

Mathematicalmodels

Design

Front-endtool

Verificationengines

Page 11: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

11

Formal vs simulation based verificationFormal vs simulation based verification

Example:Example: Verification of Exclusive-OR circuits: Verification of Exclusive-OR circuits: z = ~x&y + x&~y ( ‘~’ means compliment)z = ~x&y + x&~y ( ‘~’ means compliment)

G1

G2

G3

G4

x

y

a

b

c

z

Page 12: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

12

Example: Formal vs simulation (Cont.)Example: Formal vs simulation (Cont.)

Verification of Exclusive-OR circuit with Verification of Exclusive-OR circuit with “simulation”“simulation” z and ~x&y+x&~y are equal for all four casesz and ~x&y+x&~y are equal for all four cases Need to simulate 2**N cases where N is #insNeed to simulate 2**N cases where N is #ins

x

y

a

b

c

z

00001111

11110011

11111100

00000000x y z ~x&y+x&~y

Page 13: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

13

Verification of Exclusive-OR circuit with Verification of Exclusive-OR circuit with “formal verification”“formal verification” z = ~b + ~cz = ~b + ~c b = ~x + ~ab = ~x + ~a c = ~a + ~yc = ~a + ~y a = ~x + ~y a = ~x + ~y z = ~b + ~cz = ~b + ~c = ~(~x + ~a) + ~(~a + ~y)= ~(~x + ~a) + ~(~a + ~y) = a&x + a&y= a&x + a&y = (~x + ~y)&x + (~x + ~y)&y= (~x + ~y)&x + (~x + ~y)&y = x&~y + ~x&y= x&~y + ~x&y Axiomatic and mathematical transformation of Axiomatic and mathematical transformation of

expressions to reach the specificationexpressions to reach the specification This is a mathematical proof !This is a mathematical proof !

x

y

a

b

c

z

Example: Formal vs simulation (Cont.)Example: Formal vs simulation (Cont.)

Page 14: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

RTL Simulation SemanticsRTL Simulation Semantics delay modeldelay model

each operation takes negligible timeeach operation takes negligible time operations are scheduled in terms of clock boundariesoperations are scheduled in terms of clock boundaries explicitly specified delay may be usedexplicitly specified delay may be used functional simulation may be different from later stage timing functional simulation may be different from later stage timing

simulationsimulation 4 valued logic is usually used (0, 1, X, Z)4 valued logic is usually used (0, 1, X, Z)

more complex logic possible e.g. more complex logic possible e.g. std_logic_vectorstd_logic_vector in VHDL in VHDL Blocking and Non-blocking assignments using syntaxBlocking and Non-blocking assignments using syntax

blocking assignments are sequentially executedblocking assignments are sequentially executed non blocking assignments are executed in parallel at end of a clock non blocking assignments are executed in parallel at end of a clock

boundaryboundary Value Change Dump (Value Change Dump (VCDVCD) file captures changes in values of ) file captures changes in values of

variables with timevariables with time

Page 15: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

Event-driven SimulationEvent-driven Simulation

Event: change in logic value at a node, at Event: change in logic value at a node, at a certain instant of time a certain instant of time (V,T) (V,T)

Event-driven: only considers active nodesEvent-driven: only considers active nodes EfficientEfficient

Performs both timing and functional Performs both timing and functional verificationverification All nodes are visibleAll nodes are visible Glitches are detectedGlitches are detected

Most heavily used and well-suited for all Most heavily used and well-suited for all types of designstypes of designs

Page 16: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

Event-driven SimulationEvent-driven Simulation

D=1

10

1

0

1

D=2a

b

c

d

50

1

e

0

1

30

1

4 6

b(1)=1d(5)=1

d(5)=1 c(3)=0d(5)=1

d(5)=1

e(4)=0 e(6)=1

Page 17: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

Cycle-based SimulationCycle-based Simulation Take advantage of the fact that most digital Take advantage of the fact that most digital

designs are largely synchronousdesigns are largely synchronous

Synchronous circuit: state elements change value on active Synchronous circuit: state elements change value on active edge of clockedge of clock

Only boundary nodes are evaluatedOnly boundary nodes are evaluated Compute steady-state response of the circuit Compute steady-state response of the circuit

at each clock cycle at each boundary nodeat each clock cycle at each boundary node

Internal Node

Boundary NodeLatches

Latches

Page 18: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

Simulation CAD ToolsSimulation CAD Tools

Event-driven simulatorsEvent-driven simulators Synopsys Synopsys VCS, SiroccoVCS, Sirocco

VCS is a fast Verilog simulatorVCS is a fast Verilog simulator Sirocco is a VHDL simulatorSirocco is a VHDL simulator

Cadence Cadence NCSim NCSim (VHDL, Verilog, mixed)(VHDL, Verilog, mixed) Model Tech. Model Tech. Modelsim Modelsim (VHDL, Verilog, mixed)(VHDL, Verilog, mixed)

Cycle-based simulatorsCycle-based simulators Quickturn Quickturn SpeedSimSpeedSim (VHDL) (VHDL) Synopsys Synopsys PureSpeedPureSpeed (Verilog) (Verilog) Cadence Cadence CobraCobra

Page 19: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

VCD dump viewerVCD dump viewer e.g. Cadence e.g. Cadence SignalscanSignalscan

Integrated debugging environmentIntegrated debugging environment more sophisticated toolmore sophisticated tool cross references code, VCD waveform viewer, coverage analysis cross references code, VCD waveform viewer, coverage analysis

etc.etc. integrates software debug features and hardware debug featuresintegrates software debug features and hardware debug features e.g. Novas Software e.g. Novas Software DebussyDebussy

Debugging ToolsDebugging Tools

clk

ab

bus[0:3] xxxx 5H 3H

time 0 10 20 30 40 50

Page 20: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

20

Spec

Lecture 2: Backgrounds technology in formal Lecture 2: Backgrounds technology in formal verificationverification

Methods for reasoning about Methods for reasoning about mathematical modelsmathematical models Boolean function (Propositional Boolean function (Propositional

logic)logic) SAT (Satisfiability checker)SAT (Satisfiability checker) BDD (Binary Decision Diagrams)BDD (Binary Decision Diagrams)

First-order logicFirst-order logic Logic of uninterpreted functions Logic of uninterpreted functions

with equalitywith equality Higher-order logicHigher-order logic Theorem proving = Interactive Theorem proving = Interactive

method (skipped in this tutorial)method (skipped in this tutorial)

Mathematicalmodels

Design

Front-endtool

Verificationengines

Page 21: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

21

SAT Problem definitionSAT Problem definition

Given a CNF formula, f :Given a CNF formula, f :

(C(C11,C,C22,C,C33)) Conjunction of clausesConjunction of clauses

(a,b,c)(a,b,c) A set of variables, A set of variables, VV

Each clause: disjunction of literals over Each clause: disjunction of literals over VV

C1 C2 C3

a = b = c = 1a = b = c = 1))()(( cbacacba Example :Example :

Does there exist an assignment of Boolean values to the variables, V which sets at least one literal in each

clause to ‘1’ ?

Page 22: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

22

CC11

CONFLICTCONFLICT!!

DPLL algorithm for SATDPLL algorithm for SAT

Given :Given : CNF formula f(vCNF formula f(v11,v,v22,..,v,..,vkk) , and an ) , and an

ordering functionordering function Next_VariableNext_Variable

))()(( bacaba

Example :Example :

C1 C2 C3

11

CC33

CC22

SATSAT!!

11c

11

00b

00

a0

[Davis, Putnam, Logemann, Loveland 1960,62][Davis, Putnam, Logemann, Loveland 1960,62]

Page 23: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

23

DPLL algorithm: Unit clause ruleDPLL algorithm: Unit clause rule

Rule:Rule: Assign toAssign to truetrue any single literal clauses.any single literal clauses.

)( cba =

0

=

0c = 1

))()()()()(( edcedeccbacbcaa

))()()(( edcedeccbc

)( ede

Apply Iteratively: Apply Iteratively: Boolean Constraint Propagation (BCP)Boolean Constraint Propagation (BCP)

Page 24: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

24

Anatomy of a modern SAT solverAnatomy of a modern SAT solver

SAT Solver

Search RestartsTo correct for bad To correct for bad choices in variable choices in variable orderingorderingRestart algorithm Restart algorithm “periodically”“periodically”Retain some/all Retain some/all recorded clausesrecorded clauses

Clause database managementDiscard useless clauses (e.g. inactive or large clauses)

Efficient garbage collection

Conflict-driven learning

DPLL Algorithm Efficient BCP

Page 25: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

25

Conflict driven search pruning Conflict driven search pruning (GRASP)(GRASP)

SATSAT

Non-chronological backtrackingNon-chronological backtracking

Conflict-clause recording Conflict-clause recording

xxk-1k-1xxk-1k-1

xxkkxxkk

xx22xx22

xx11xx11

xxjjxxjj

11

22

Silva & Sakallah ‘95

Page 26: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

26

Conflict analysis: An exampleConflict analysis: An example

)( 21 xx

)( 9312 xxx

)( 4323 xxx

)( 10544 xxx

)( 11645 xxx )( 656 xx

)( 818 xx )( 12717 xxx

)( 13879 xxx

}6@1{ 1xDecision Assignment:Decision Assignment:

}2@1,2@1,3@0,3@0,1@0{ 131211109 xxxxx

Current Assignment:Current Assignment:

Page 27: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

27

Example continued: Implication graphExample continued: Implication graph

)(( 111091 xxxxc

xx22= 1@6= 1@6

xx1111= 0@3= 0@3

xx66= 1@6= 1@6

xx55= 1@6= 1@6

xx11= 1@6= 1@6

xx99= 0@1= 0@1

xx44= 1@6= 1@6

xx33= 1@6= 1@6

xx1010= 0@3= 0@3

33

33

11

22

22

44

44

55

55

66

66

Page 28: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

28

Example continued….Example continued….

x1

55

33

66

Decision Decision LevelLevel

xx77= 1@6= 1@6

xx1313= 1@2= 1@2

xx1212= 1@2= 1@2

xx88= 1@6= 1@6

`̀`̀ 99

99

99

77

77

88

xx11= 0@6= 0@6

xx99= 0@1= 0@1

xx1010= 0@3= 0@3

xx1111= 0@3= 0@3

Page 29: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

29

Variable orderingVariable ordering

Significantly impacts size of search Significantly impacts size of search treetree

Ordering schemes can be Ordering schemes can be static static or or dymamicdymamic

Conventional wisdom (pre-chaff):Conventional wisdom (pre-chaff): Satisfy most number of clauses ORSatisfy most number of clauses OR Maximize BCP Maximize BCP e.g.e.g. DLIS, MOMs, BOHMs DLIS, MOMs, BOHMs etc.etc.

Page 30: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

30

Variable ordering: New ideasVariable ordering: New ideas

New wisdom:New wisdom: Recorded clauses key in Recorded clauses key in guiding searchguiding search

Conflict-driven variable ordering:Conflict-driven variable ordering: Chaff (DAC’01): Pick var. appearing in Chaff (DAC’01): Pick var. appearing in mostmost

number of number of recentrecent conflict clausesconflict clauses BerkMin (DATE’02): Pick var. BerkMin (DATE’02): Pick var. involvedinvolved in most in most

number of number of recentrecent conflicts conflicts

Semi-static in nature, for efficiencySemi-static in nature, for efficiency Statistics updated on each conflictStatistics updated on each conflict

Side-effect:Side-effect: Better cache behavior Better cache behavior

Page 31: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

31

Efficient Boolean Constraint PropagationEfficient Boolean Constraint Propagation

Observation:Observation: BCP almost 80% of compute time, BCP almost 80% of compute time, under clause recordingunder clause recording

Traditional implementation:Traditional implementation: Each clause: Counter for #literals set to falseEach clause: Counter for #literals set to false Assgn. to variable ‘x’: Update all clauses having x, xAssgn. to variable ‘x’: Update all clauses having x, x

New Idea:New Idea: Only need to monitor event when # free Only need to monitor event when # free literals in a clause goes from 2 to 1literals in a clause goes from 2 to 1 Need to Need to watchwatch only 2 literals per clause : only 2 literals per clause : SATOSATO

(Zhang’97),(Zhang’97),ChaffChaff (DAC’01) (DAC’01)

…… …x1 w1w2 xk

Page 32: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

32

SAT solvers todaySAT solvers today Capacity:Capacity:

Formulas upto a Formulas upto a million variablesmillion variables and and 3-4 million3-4 million clausesclauses can be solved in can be solved in few hoursfew hours

Only for Only for structured instancesstructured instances e.g.e.g. derived from derived from real-world circuits & systemsreal-world circuits & systems

Tool offerings:Tool offerings: Public domainPublic domain

GRASP : Univ. of MichiganGRASP : Univ. of Michigan SATO: Univ. of IowaSATO: Univ. of Iowa zChaff: Princeton UniversityzChaff: Princeton University BerkMin: Cadence Berkeley Labs.BerkMin: Cadence Berkeley Labs.

CommercialCommercial PROVER: Prover TechnologiesPROVER: Prover Technologies

Page 33: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

33

Binary Decision Diagram: Decision structuresBinary Decision Diagram: Decision structures

Vertex represents decisionVertex represents decision Follow green (dashed) line for value 0Follow green (dashed) line for value 0 Follow red (solid) line for value 1Follow red (solid) line for value 1 Function value determined by leaf valueFunction value determined by leaf value

Truth Table Decision Tree

0 0

x3

0 1

x3

x2

0 1

x3

0 1

x3

x2

x1

00001111

00110011

01010101

00010101

x1 x2 x3 f

Source: Prof. Randal Bryant

Page 34: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

34

Variable orderingVariable ordering

Assign arbitrary total ordering to variablesAssign arbitrary total ordering to variables e.g.e.g. x x11 < x < x22 < x < x33

Variables must appear in ascending order along all Variables must appear in ascending order along all pathspaths

PropertiesProperties No conflicting variable assignments along path Simplifies manipulation

x1

x2

x3

x1

x3

x3

x2

x1

x1

x1

OK Not OK

Page 35: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

35

Reducing OBDDs: Rule #1Reducing OBDDs: Rule #1

11 1

Eliminate duplicate terminals

0 0

x3

0 1

x3

x2

0 1

x3

0 1

x3

x2

x1

x3 x3

x2

x3

0 1

x3

x2

x1

Page 36: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

36

Reducing OBDDs: Rule #2Reducing OBDDs: Rule #2

x3 x3

x2

x3

0 1

x3

x2

x1

x3

x2

0 1

x3

x2

x1

a

b

a

c

a

b c

01 0

1 0 1

Merge isomorphic nodes, i.e. nodes that reference the same variable and point to the same successors

Page 37: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

37

Reducing OBDDs: Rule #3Reducing OBDDs: Rule #3

Eliminate a node if its 0 and 1 edges lead to the same node

x3

x2

0 1

x3

x2

x1

x2

0 1

x3

x1

a

b

b0 1

0 1

0 1

Page 38: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

38

Example OBDDExample OBDD

Canonical representation of Boolean functionCanonical representation of Boolean function For given variable orderingFor given variable ordering Two functions equivalent if and only if graphs Two functions equivalent if and only if graphs

isomorphicisomorphic Can be tested in linear timeCan be tested in linear time

Desirable property: Desirable property: simplest form is canonicalsimplest form is canonical..

0 0

x3

0 1

x3

x2

0 1

x3

0 1

x3

x2

x1

x2

0 1

x3

x1

Initial Graph Reduced Graph

(x 1+x 2)· x 3

Page 39: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

39

From circuits to BDDFrom circuits to BDD

X1

X2 X2

10

1 100

0 1X1

X2

10

1

0

0

1X1

X2

10

0

1

1

0X1

X2

10

0

0

1

1

X2

10

10

X1

10

10

X1

X2

G1

G2

G3

G4

Page 40: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

40

Effect of variable orderingEffect of variable ordering

Good Ordering

Linear Growth

0

b3

a3

b2

a2

1

b1

a1

Bad Ordering

Exponential Growth

a3 a3

a2

b1 b1

a3

b2

b1

0

b3

b2

1

b1

a3

a2

a1

)()()( 332211 bababa

Page 41: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

41

ROBDD sizes & variable orderingROBDD sizes & variable ordering

Bad News Bad News Finding optimal variable ordering NP-HardFinding optimal variable ordering NP-Hard Some functions have exponential BDD size for all Some functions have exponential BDD size for all

orders orders e.g.e.g. multiplier multiplier Good News Good News

Many functions/tasks have reasonable size ROBDDsMany functions/tasks have reasonable size ROBDDs Algorithms remain practical up to 500,000 node OBDDsAlgorithms remain practical up to 500,000 node OBDDs Heuristic ordering methods generally satisfactoryHeuristic ordering methods generally satisfactory

What works in Practice What works in Practice Application-specific heuristics e.g. DFS-based ordering Application-specific heuristics e.g. DFS-based ordering

for combinational circuitsfor combinational circuits Dynamic ordering based on variable sifting Dynamic ordering based on variable sifting (R. Rudell)(R. Rudell)

Page 42: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

42

Variants of decision diagramsVariants of decision diagrams

Multiterminal BDDs (MTBDD)Multiterminal BDDs (MTBDD) – Pseudo Boolean functions B – Pseudo Boolean functions Bn n

N, terminal nodes are integersN, terminal nodes are integers Ordered Kronecker FunctionalDecision Diagrams (OKFDD)Ordered Kronecker FunctionalDecision Diagrams (OKFDD) – –

uses XOR in OBDDsuses XOR in OBDDs Binary Moment Diagrams (BMD)Binary Moment Diagrams (BMD) – good for arithmetic – good for arithmetic

operations and word-level representationoperations and word-level representation Zero-suppressed BDD (ZDD)Zero-suppressed BDD (ZDD) – good for representing sparse – good for representing sparse

setssets Partitioned OBDDs (POBDD)Partitioned OBDDs (POBDD) – highly compact representation – highly compact representation

which retains most of the features of ROBDDswhich retains most of the features of ROBDDs BDD packagesBDD packages – –

CUDD from Univ. of Colorado, Boulder,CUDD from Univ. of Colorado, Boulder, CMU BDD package from Carnegie Mellon Univ.CMU BDD package from Carnegie Mellon Univ. In addition, companies like Intel, Fujitsu, Motorola etc. In addition, companies like Intel, Fujitsu, Motorola etc.

have their own internal BDD packageshave their own internal BDD packages

Page 43: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

43

Symbolic logicSymbolic logic

Symbolic logic deals with the structure of Symbolic logic deals with the structure of reasoningreasoning

It defines ways to deal with relationships It defines ways to deal with relationships between conceptsbetween concepts

Provides ways to compose proofs of Provides ways to compose proofs of statementsstatements

Provides ways to express statements in a Provides ways to express statements in a precise, compact and symbolic mannerprecise, compact and symbolic manner

More precisely, a formal symbolic logic More precisely, a formal symbolic logic consists of consists of A notation (symbols and syntax)A notation (symbols and syntax) A set of axioms (facts)A set of axioms (facts) A set of inference rules (deduction scheme)A set of inference rules (deduction scheme)

Page 44: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

44

Types of symbolic logicTypes of symbolic logic

Propositional Logic – commonly known as Propositional Logic – commonly known as Boolean algebraBoolean algebra Variables in this algebra Variables in this algebra {0,1} {0,1}

First Order LogicFirst Order Logic Existential (Existential () and Universal () and Universal () quantifiers over ) quantifiers over

variables variables

Higher Order LogicHigher Order Logic Existential and Universal quantification over sets Existential and Universal quantification over sets

and functionsand functions

Page 45: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

45

Key features of a theoryKey features of a theory

Expressiveness Expressiveness What kind of statements can be written in the theoryWhat kind of statements can be written in the theory

Completeness Completeness All valid formulas are provableAll valid formulas are provable

DecidabilityDecidability There exists an algorithm to deduce the truth of any There exists an algorithm to deduce the truth of any

formula in the theoryformula in the theory Comparison of types of logicComparison of types of logic

PropositionalPropositional Least expressive, decidable, completeLeast expressive, decidable, complete

First Order LogicFirst Order Logic More expressive, decidable, not completeMore expressive, decidable, not complete

Higher Order LogicHigher Order Logic Most expressive, not decidable, not completeMost expressive, not decidable, not complete

Page 46: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

46

First-order logicFirst-order logic

First-Order Logic First-Order Logic theory in symbolic logic theory in symbolic logic formalizes quantified statements formalizes quantified statements

E.g: “there exists an object such that…” or “for all objects, it is E.g: “there exists an object such that…” or “for all objects, it is the case that…”the case that…”

Statements in first-order logic built using:Statements in first-order logic built using: VariablesVariables x, yx, y ConstantsConstants 0, C, 0, C, FunctionsFunctions f (x ), x + yf (x ), x + y PredicatesPredicates p (x ), x > y, x = yp (x ), x > y, x = y Boolean connectivesBoolean connectives , , , , , , QuantifiersQuantifiers , ,

Page 47: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

47

First-order theoriesFirst-order theories A first-order theory A first-order theory

a set of first-order statements about a related set of a set of first-order statements about a related set of constants, functions, and predicates.constants, functions, and predicates.

Example:Example: A theory of arithmetic might include the following A theory of arithmetic might include the following

statements about statements about 00 and and ++::

x. ( x + 0 = x )x. ( x + 0 = x )

x,y. (x + y = y + x )x,y. (x + y = y + x )

Page 48: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

48

Validity of an expression in a theoryValidity of an expression in a theory

Given Given A theory and an expression A theory and an expression

Using Using Building blocks of that theoryBuilding blocks of that theory If expression evaluates to true for every If expression evaluates to true for every

evaluation, then it is valid in the theoryevaluation, then it is valid in the theory Example: Example:

X >= 0 is a valid expression in positive real X >= 0 is a valid expression in positive real arithmeticarithmetic

Page 49: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

49

Validity checking & undecidabilityValidity checking & undecidability

Given a theory Given a theory in first-order logic and an expression in first-order logic and an expression we wish to prove that we wish to prove that is valid in is valid in Validity of Validity of in in is written as is written as |= |= Undecidability of FOLUndecidability of FOL

A well-known result states that in general it is undecidable A well-known result states that in general it is undecidable whether a FOL formula is valid in a given first-order theorywhether a FOL formula is valid in a given first-order theory

However with appropriate restrictions on However with appropriate restrictions on and and the theory the theory can be made decidable and practical programs can be built can be made decidable and practical programs can be built aroundaround

Many practical problems can be posed as formulas in Many practical problems can be posed as formulas in a certain theory or a combination of theoriesa certain theory or a combination of theories

A proof of validity of this formula results in a solution A proof of validity of this formula results in a solution to the problemto the problem ExampleExample

Scheduling of complex operations in a manufacturing plantScheduling of complex operations in a manufacturing plant

Page 50: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

50

Proof systemProof system

A formal proof in a theory A formal proof in a theory A set of steps of statements A set of steps of statements A statement is derived from a previous statement using A statement is derived from a previous statement using

a set of defined inference rulesa set of defined inference rules Rewrite rulesRewrite rules

Deal with mechanical massaging of statements Deal with mechanical massaging of statements irrespective of the meaning of the statementsirrespective of the meaning of the statements

Key requirement of a proof system Key requirement of a proof system Soundness : All provable formulas are logically true!Soundness : All provable formulas are logically true!

A proof system need not be complete or decidable A proof system need not be complete or decidable in order to be useful!in order to be useful!

Page 51: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

51

Automated vs. interactive theorem provingAutomated vs. interactive theorem proving John Rushby, SRI, asserts “John Rushby, SRI, asserts “There are no There are no

fully automatic theorem proversfully automatic theorem provers”.”. For best performance most theorem provers For best performance most theorem provers

require user guidancerequire user guidance Variable ordering, weighting of literals, function Variable ordering, weighting of literals, function

symbols, strategy selection, orientation of symbols, strategy selection, orientation of equations, invention of ordering lemmas, equations, invention of ordering lemmas, induction hintsinduction hints

Automation in certain domainsAutomation in certain domains Propositional logic using SAT solvers, BDDsPropositional logic using SAT solvers, BDDs Linear arithmetic – integer/linear programmingLinear arithmetic – integer/linear programming Temporal logic – model checkingTemporal logic – model checking Induction (Boyer-Moore heuristics)Induction (Boyer-Moore heuristics)

Page 52: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

52

Example theorem prover: PVSExample theorem prover: PVS

A

PVS File

System model

FormulaeTo be proved

Proofs

• Owre et al., 1992 at SRIOwre et al., 1992 at SRI

• System model is translated either automatically or manuallySystem model is translated either automatically or manually• Formulae to be proved are also translated from their native formsFormulae to be proved are also translated from their native forms• Proofs are usually carried out interactivelyProofs are usually carried out interactively

Page 53: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

53

PVS MethodologyPVS Methodology

Automate everything that is decidableAutomate everything that is decidable Propositional calculus, linear arithmetic, finite-state Propositional calculus, linear arithmetic, finite-state

model checkingmodel checking Heuristic automation for obvious cases for other Heuristic automation for obvious cases for other

problemsproblems Hashing conditional rewriter integrated with decision Hashing conditional rewriter integrated with decision

proceduresprocedures Instantiation, inductionInstantiation, induction

Human control for things difficult to automateHuman control for things difficult to automate Sequent calculus presentationSequent calculus presentation Tactic language for defining higher-level proof strategiesTactic language for defining higher-level proof strategies

Page 54: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

54

Stanford validity checker (SVC)Stanford validity checker (SVC)

Started with applications to processor Started with applications to processor verificationverification [Burch and Dill ‘94][Burch and Dill ‘94] [Jones et al. ‘95][Jones et al. ‘95]

Applications since releaseApplications since release Symbolic simulation Symbolic simulation [Su et al. ‘98][Su et al. ‘98] Software specification checking Software specification checking [Park et al. ‘98][Park et al. ‘98] Infinite-state model checking Infinite-state model checking [Das and Dill ‘01][Das and Dill ‘01] Theorem prover proof assistance Theorem prover proof assistance [Heilmann ‘99][Heilmann ‘99] Integration into programming languages Integration into programming languages [Day et [Day et

al. ‘99]al. ‘99]

Page 55: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

55

Overall flow of SVCOverall flow of SVC Given an expression whose validity has to be Given an expression whose validity has to be

checkedchecked Choose an atomic formula Choose an atomic formula ƒ ƒ in the expressionin the expression Case split on the atomic formulaCase split on the atomic formula

Create two subformulas, for Create two subformulas, for ƒƒ = 0, and = 0, and ƒ = ƒ = 11 Simplify the two subformulasSimplify the two subformulas Iteratively check the validity of the two subformulasIteratively check the validity of the two subformulas

Example: Example: ( ( x x << y ) y ) ( y ( y < < x ) x ) ( x ( x == y ) y ) Choose Choose f = ( x < y )f = ( x < y ) Case split on f to get two subformulasCase split on f to get two subformulas

Simplify

Simplify

( true ) ( y < x )

true

( false ) ( y < x ) ( x = y ) ( y < x ) ( x = y )

Page 56: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

56

Example (continued)Example (continued) ( y ( y < < x ) x ) ( x ( x == y ) y ) Choose Choose f = ( y f = ( y < < x ) x ) Case splitting gives two subformulasCase splitting gives two subformulas

true true ( x ( x == y ) true y ) true

false false ( x ( x == y ) ( x y ) ( x == y ) y )

Case splitting onCase splitting on f = ( x = y ) f = ( x = y ) gives two subformulasgives two subformulas

true and falsetrue and false The only false node is formula:The only false node is formula: ( x y ) ( y x ) ( x y )

Simplify

Simplify

If this formula can be proved unsatisfiable by theory then formula is a tautologyIf this formula can be proved unsatisfiable by theory then formula is a tautology

Page 57: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

57Decision procedure for higher level designs: Decision procedure for higher level designs: Uninterpreted functions with equalityUninterpreted functions with equality Ignore each functionality in the functionsIgnore each functionality in the functions

It is called LIt is called Logic of Uninterpreted Functionogic of Uninterpreted Functionss Arithmetic operations are handled as symbolsArithmetic operations are handled as symbols

Fucntion returns a valueFucntion returns a value If the arguments are the same, it returns the same valueIf the arguments are the same, it returns the same value (a=b)(a=b)(x=y) (x=y) [f(a,x)=f(b,y)] [f(a,x)=f(b,y)]

Very useful for analysis of symbolic simulation resultsVery useful for analysis of symbolic simulation results Equivalence checking: Both send f(b) to xEquivalence checking: Both send f(b) to x

Design1: if a=b then x <- f(a) else x <- f(b)Design1: if a=b then x <- f(a) else x <- f(b) Design2: x<- f(b)Design2: x<- f(b)

Transform into formulaeTransform into formulae Design1: ((a=b)->(x’=f(a)))&((~(a=b)->(x’=f(b)))Design1: ((a=b)->(x’=f(a)))&((~(a=b)->(x’=f(b))) Design2: x’=f(b)Design2: x’=f(b)

Decision procedure similar to SAT confirms Design1=Design2Decision procedure similar to SAT confirms Design1=Design2

f Yx

y

c

Y:= if c then x else f(x,y)1

0

Page 58: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

58

How is validity checking done?How is validity checking done?

The validity checker is built on top of a core The validity checker is built on top of a core decision procedure for decision procedure for satisfiabilitysatisfiability in a theory in a theory of a set of literals in the theory of a set of literals in the theory A literal is an atomic formula or its negationA literal is an atomic formula or its negation The core decision procedure depends on the The core decision procedure depends on the

theorytheory e.g. a Satisfiability Solver can be used for Propositional e.g. a Satisfiability Solver can be used for Propositional

LogicLogic

SVC proposesSVC proposes use of several decision theories targeted to use of several decision theories targeted to

several theories several theories gives the strongest decision proceduregives the strongest decision procedure

Page 59: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

59

Need for Multiple TheoriesNeed for Multiple Theories

Why are multiple theories needed?Why are multiple theories needed? Most real-life problems when cast into a problem Most real-life problems when cast into a problem

of proving validity of a formula span a set of of proving validity of a formula span a set of theoriestheories Propositional logicPropositional logic Bit-vectors and arraysBit-vectors and arrays Real, linear arithmeticReal, linear arithmetic Uninterpreted functions & predicatesUninterpreted functions & predicates

A decision procedure isA decision procedure is a combination of theories must be able to a combination of theories must be able to

combine decision procedures that reason in combine decision procedures that reason in each of these theories!each of these theories!

Page 60: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

60

Basic formal verification techniquesBasic formal verification techniques

Equivalence checking: Basics and real tools Equivalence checking: Basics and real tools (Lecture 3)(Lecture 3) CombinationalCombinational SequentialSequential

Model (property) checking: Basics Model (property) checking: Basics (Lecture 4)(Lecture 4) Explicit/implicit state basedExplicit/implicit state based Bounded model checkingBounded model checking

Page 61: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

61

Formal Equivalence CheckingFormal Equivalence Checking

Given two designs, prove that for all possible input stimuli their corresponding outputs are equivalent

Design A

Design B

=?Input Yes/No

Product Machine

Page 62: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

62

Formal equivalence checking: The targetsFormal equivalence checking: The targets

Equivalence checking can be applied at or Equivalence checking can be applied at or across various levelsacross various levels

RTL

Gate Level

System Level

Device Level

Page 63: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

63

Combinational Equivalence Checking (CEC)Combinational Equivalence Checking (CEC)

Currently most practical and pervasive Currently most practical and pervasive equivalence checking technologyequivalence checking technology

Nearly full automation possibleNearly full automation possible Designs of up to several million gates Designs of up to several million gates

verified in a few hours or minutesverified in a few hours or minutes Hierarchical verification deployedHierarchical verification deployed Full chip verification possibleFull chip verification possible Key methodology:Key methodology: Convert sequential Convert sequential

equivalence checking to a CEC problem!equivalence checking to a CEC problem! Match Latches & extract comb. portions for ECMatch Latches & extract comb. portions for EC

Page 64: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

64

CEC in Today’s ASIC Design FlowCEC in Today’s ASIC Design Flow

RTL Design

Synthesis & optimization

DFT insertion

IO Insertion

Placement

Clock tree synthesis

Routing

ECO

CEC

CEC

CEC

CEC

CECCEC

Page 65: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

65

Solving Seq. EC as Comb. ECSolving Seq. EC as Comb. EC

LATCHES

NS1

PI

PO

PS1

Comb.Logic

PI

PO

NS2PS2

Comb.Logic

CIR

CU

IT 1

CIR

CU

IT 2

MATCH PI

PS

PO

NS

Comb. Logic 1

Comb. Logic 2

=?

PO

NS

Combinational Combinational Equiv. CheckingEquiv. Checking

Page 66: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

66

Combinational EC with BDD and SATCombinational EC with BDD and SAT

LATCHES

NS1

PI

PO

PS1

Comb.Logic

PI

PO

NS2PS2

Comb.Logic

CIR

CU

IT 1

CIR

CU

IT 2

MATCH PI

PS

PO

NS

Comb. Logic 1

Comb. Logic 2

=?

PO

NS

Combinational Combinational Equiv. CheckingEquiv. Checking

Represent logic functions for this entire circuit with BDD or SAT

Page 67: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

67

Methods for Latch MappingMethods for Latch Mapping

Incomplete MethodsIncomplete Methods Regular expression-based using latch namesRegular expression-based using latch names Using simulation (Cho & Pixley ‘97): Using simulation (Cho & Pixley ‘97):

Group latches with identical simulation signaturesGroup latches with identical simulation signatures Group based on structural considerations e.g. Group based on structural considerations e.g.

cone of influencecone of influence Incomplete run of complete method below Incomplete run of complete method below

(Anastasakis et al DAC ‘02)(Anastasakis et al DAC ‘02)

Complete MethodsComplete Methods Functional fixed-point iteration based on Van Functional fixed-point iteration based on Van

Eijk’s algorithm (van Eijk ’95)Eijk’s algorithm (van Eijk ’95)

Page 68: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

68

Van Eijk’s Method for Latch MappingVan Eijk’s Method for Latch Mapping

PI

PS

Comb. Logic 1

Comb. Logic 2

NS

NS=?

Apply Latch Mapping

Assumptions

Initial Latch Mapping

Approximation

Verify Latch Mapping

Assumptions

Fixed-point ?

Iterate

Done !!

Yes

No

Page 69: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

69

Arguments Arguments II, , TT, , EE Functions over variables X Represented as OBDDs

ResultResultOBDD representing

composite function (I T) (I E)

MUX1

0

I T, E 

X

I  

If-Then-Else operationIf-Then-Else operation

ConceptConcept Basic technique for building OBDD from logic Basic technique for building OBDD from logic

network or formula.network or formula.

Page 70: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

70

0 1

d

c

a

B3 B4

B2

B5

B1

Argument I

1

Argument T Argument E

A4,B3 A5,B4

A3,B2

A6,B2

A2,B2

A3,B4A5,B2

A6,B5

A1,B1

Recursive Calls

b

0

d

1

c

a

A4 A5

A3

A2

A6

A1

If-Then-Else execution exampleIf-Then-Else execution example

OptimizationsOptimizations Dynamic programmingDynamic programming Early termination rulesEarly termination rules Apply reduction rules bottom-up as return from recursive callsApply reduction rules bottom-up as return from recursive calls

(Recursive calling structure implicitly defines unreduced BDD)(Recursive calling structure implicitly defines unreduced BDD)

Page 71: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

71

Derived algebraic operationsDerived algebraic operations

Other operations can be expressed in Other operations can be expressed in terms of If-Then-Elseterms of If-Then-Else

MUX1

0

F G, 0 

X

F  

G

0

MUX1

0

F 1, G 

X

G

1

XF 

G

XF 

G

And(F, G)

Or(F, G)

If-Then-Else(F, G, 0)

If-Then-Else(F, 1, G)

Page 72: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

72

Generating OBDD from networkGenerating OBDD from networkTask: Represent output functions of gate network as OBDDs.

Network

Evaluation

A

B

C

T1

T2

Out

Resulting Graphs

A B CT1 T2

Out

0 1

a

0 1

c

0 1

b

0 1

b

a

0 1

c

b

c

b

0 1

b

a

A A new_var ("a");new_var ("a");BB new_var ("b");new_var ("b");C C new_var ("c");new_var ("c");T1 T1 And (A, 0, B);And (A, 0, B);         If-Then-Else(A, B, 0)If-Then-Else(A, B, 0)T2 T2 And (B, C); And (B, C); If-Then-Else(B,C, 0)If-Then-Else(B,C, 0)OutOut Or (T1, T2);Or (T1, T2); If-Then-Else(A, 1, B)If-Then-Else(A, 1, B)

Page 73: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

73

Solving circuit problems as SATSolving circuit problems as SAT

a

b

c

d

e

f

g

h

i

Primary Output ‘i’ toPrimary Output ‘i’ to 1 1 ??Input Vector AssignmentInput Vector Assignment ??

Page 74: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

74

SAT formulas for simple gatesSAT formulas for simple gates

ab

c

))(( baba

a b

))()(( bacbcac

a

bc

))()(( bacbcac

a

bc

Page 75: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

75

Solving circuit problems as SATSolving circuit problems as SAT

Set of clauses representing function of each gateSet of clauses representing function of each gate

))()(( fcbfcfb

))()(( hfahfha

))()(( gedgegd

)(i))()(( ighigih

a

b

c

d

e

f

g

h

i

Unit literal clause asserting output to Unit literal clause asserting output to ‘1’‘1’

Page 76: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

76

CEC in PracticeCEC in Practice

Key Observation:Key Observation: The circuits being verified usually The circuits being verified usually have a number of internal equivalent functionshave a number of internal equivalent functions

To proveTo prove f (f (i1, i2,…in) = f’ () = f’ (i1, i2,…in))

x1(i1, i2,…in) = x1’(i1, i2,…in)

x2(i1, i2,…in) = x2’(i1, i2,…in)

xk(i1, i2,…in) = xk’(i1, i2,…in)

f(x1, x2,…xk) = f’(x1’, x2’,…xk’) i2i1

f

in

f’

xkx2x1

x1’x2’xk’

Check

Page 77: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

77

Internal Equiv. Based CEC AlgorithmInternal Equiv. Based CEC Algorithm

Random Simulation

Gather PENs

Is x=y?

Refine PEN sets using counter-

example

Is there an unjustified PEN

pair x,y ?

Structurally merge x,y

Done!

PI

PS

PONS

Comb. Logic 1

Comb. Logic

2

=?PO

NS

Combinational miter after latch mapping

Yes

Yes

No

NoPENs: Potentially equivalent nodes, i.e. nodes with identical simulation signature

BDD/ATPG/SAT

Page 78: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

78

Anatomy of Typical CEC ToolsAnatomy of Typical CEC Tools

Circuit A

Circuit B

BDDSAT

ATPG

Multi-engine solver

Structural methods

Learning

Quick Synthesis

Latch Mapper

Counter-example

viewer

Error Diagnosis

Engine

Page 79: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

79

Major Industrial Offerings of CECMajor Industrial Offerings of CEC

Formality Formality (Synopsys)(Synopsys) Conformal Suite Conformal Suite (Verplex, now Cadence)(Verplex, now Cadence) FormalPro FormalPro (Mentor Graphics)(Mentor Graphics) Typical capabilities of these tools:Typical capabilities of these tools:

Can handle circuits of up to Can handle circuits of up to several million gates flatseveral million gates flat in up in up to a few hours of runtimeto a few hours of runtime

Comprehensive Comprehensive debug tooldebug tool to pinpoint error-sources to pinpoint error-sources Counter-example displayCounter-example display && cross-linkcross-link of RTL and gate-level of RTL and gate-level

netlists for easier debuggingnetlists for easier debugging Ability to Ability to checkpointcheckpoint verification process and restart from verification process and restart from

same point latersame point later What ifWhat if capability (unique to FormalPro) capability (unique to FormalPro)

Page 80: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

80

Reachability-based Equivalence CheckingReachability-based Equivalence Checking

Build product machine of MBuild product machine of M11 and M and M22

Traverse state-space of product Traverse state-space of product machine starting from reset states machine starting from reset states SS00, S, S11

Test equivalence of outputs in each Test equivalence of outputs in each statestate

Can use any state-space traversal Can use any state-space traversal techniquetechnique

M1

M2

=?

OutputsInputs

S0

S1Product Machine

S0

S1

Page 81: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

81

Move to System-Level DesignMove to System-Level Design

System-level design

Manual effort

RTL

Gate-level design

Architecture exploration

Current design iterations

Barrier to adoption of System-level design

Methodology!Errors

!

Page 82: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

82

System-Level VerificationSystem-Level Verification

Manual effort

RTL

Gate-level design

Property & Model

Checking

Equivalence

Checking

Page 83: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

83

System-level SynthesisSystem-level Synthesis

System-level design

Manual effort

RTL

Gate-level design

Automatic Synthesis

Page 84: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

84

Scope of Today’s EC Technology Scope of Today’s EC Technology

Seq

uen

tial

diff

ere

nces

Data representation differences

Bit-accurate

Identical data typesComposite data types

Precision/roundingdifferences

FFs match

pipelining

scheduling

Serial vs parallel interfaces

Re-encoding of state

CombinationalEC

Page 85: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

85

Upcoming: Transaction-Based ECUpcoming: Transaction-Based EC

The states in RTL that correspond to states The states in RTL that correspond to states in system-level model (SLM), are referred in system-level model (SLM), are referred to as to as synchronizingsynchronizing states states

SLM

RTL

Refinement mapping

Transient states

Complete Verification

or

Sequentialcounterexample

Page 86: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

86

Transactions : State ViewTransactions : State View

Encapsulates one or more units of computation Encapsulates one or more units of computation for the design being verifiedfor the design being verified

Self-contained since it brings the machine back Self-contained since it brings the machine back to a synchronizing stateto a synchronizing state

Some EDA vendor is about to offer a formal Some EDA vendor is about to offer a formal verification tools that can deal with SLM, such verification tools that can deal with SLM, such as Calyptoas Calypto

Refinement mapping

SLM

RTLRTL transaction

SL transaction

Page 87: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

87

Equivalence Checking: ConclusionsEquivalence Checking: Conclusions

Currently equivalence checking based on Currently equivalence checking based on latch mapping+CEClatch mapping+CEC Methodology premised on structural similarity Methodology premised on structural similarity

of designs under comparisonof designs under comparison Efficient & scalableEfficient & scalable Maybe applicable to system-level problemsMaybe applicable to system-level problems

More general sequential EC somewhat More general sequential EC somewhat less exploredless explored

Might be needed for system level Might be needed for system level equivalence checkingequivalence checking

Page 88: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

88

Model (property) checking: Basics Model (property) checking: Basics (Lecture 4)(Lecture 4)

Basic model checking algorthmBasic model checking algorthm States are explicitly representedStates are explicitly represented

States are “implicitly” representedStates are “implicitly” represented Symbolic model checking with BDDsSymbolic model checking with BDDs Model checking using SAT Model checking using SAT

Page 89: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

89

Sequential logic circuitSequential logic circuit

AND OR

NOT XOR

Logic Gates

c

a

b

y

Y = c ( a b )

Combinational Circuit

Present

states

INPUTS

OUTPUTS

LATCHES

Next States

CombLogi

c

a

b

DQ

c

np

o

Sequential Circuit

Page 90: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

90

Temporal logic model checkingTemporal logic model checkingVerify Reactive SystemsVerify Reactive Systems

Construct state machine representation of reactive systemConstruct state machine representation of reactive system Nondeterminism expresses range of possible behaviorsNondeterminism expresses range of possible behaviors ““Product” of component state machinesProduct” of component state machines

Express desired behavior as formula in temporal logic (TL)Express desired behavior as formula in temporal logic (TL) Determine whether or not property holdsDetermine whether or not property holds

Traffic LightController

Design

“It is never possible to

have a green light for both

N-S and E-W.”

ModelChecker

True

False+ Counterexample

FSM rep.

Property in some TL e.g.

CTL, LTL

Page 91: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

91

MoC: Finite State Machine (FSM)MoC: Finite State Machine (FSM)

I: input alphabet S: finite, non-empty set of states : S I S, next-state function S0 S : set of initial (reset) states O: output alphabet : S I O , output function

S3 S2

S1

0/0

1/1

0/0 1/0

0/0

1/1

S1

S2

S3

x = 0 x = 1

S1,0 S2,1

S1,0

S3,0

S2,0

S1,1

State Transition Table

State Transition GraphMealy FSM: I, S, , S0, O, )

INPUTS OUTPUTS

LATCHES

Next States

Present states

CombLogic

Page 92: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

92

Classification of propertiesClassification of properties

Safety propertiesSafety properties ““undesirable things never happen”undesirable things never happen” ““desirable things always happen”desirable things always happen” Examples:Examples:

A bus arbiter never grants the requests to two mastersA bus arbiter never grants the requests to two masters Elevator does not reach a floor unless it is requestedElevator does not reach a floor unless it is requested Message received is the message sentMessage received is the message sent

Liveness (progress) propertiesLiveness (progress) properties ““desirable state repeatedly reached”desirable state repeatedly reached” ““desirable state eventually reached”desirable state eventually reached” Examples:Examples:

Every bus request is eventually grantedEvery bus request is eventually granted A car at a traffic light is eventually allowed to passA car at a traffic light is eventually allowed to pass

Page 93: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

93

Fairness constraintsFairness constraints

In general, not every run in a state machine is a In general, not every run in a state machine is a valid behaviorvalid behavior

But all runs are included in transition systemsBut all runs are included in transition systems Fairness constraints rule out certain runsFairness constraints rule out certain runs

Properties only checked for fair paths !!Properties only checked for fair paths !!

Fairness constraints can be expressed as CTL Fairness constraints can be expressed as CTL formulasformulas A fair path must satisfy each formula infinitely oftenA fair path must satisfy each formula infinitely often Path quantifiers are restricted to only the fair paths Path quantifiers are restricted to only the fair paths

Fairness examplesFairness examples An arbiter arbitrates each requestor infinitely oftenAn arbiter arbitrates each requestor infinitely often In a communication channel a continuously transmitted In a communication channel a continuously transmitted

message is received infinitely oftenmessage is received infinitely often

Page 94: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

94

Temporal logicsTemporal logics Precise specificationPrecise specification Amenable to symbolic manipulationAmenable to symbolic manipulation Two kinds of temporal logics (TL)Two kinds of temporal logics (TL)

Linear Temporal Logic (LTL):Linear Temporal Logic (LTL): Time is a linear sequence of eventsTime is a linear sequence of events

Branching time temporal logic (CTL, CTL*):Branching time temporal logic (CTL, CTL*): Time is a tree of eventsTime is a tree of events

CTLCTL Formulae describe properties of computation treesFormulae describe properties of computation trees Computation Trees are obtained by unwinding the Computation Trees are obtained by unwinding the

transition system model transition system model Branching structure due to nondeterminismBranching structure due to nondeterminism CTL* is more powerful, includes CTL and LTLCTL* is more powerful, includes CTL and LTL

Page 95: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

95

Syntax of CTLSyntax of CTL Every atomic proposition is a CTL formulaEvery atomic proposition is a CTL formula If If ff and and gg are formulae then so are are formulae then so are

f, (f f, (f g), (f g), (f g), (f g), (f g), (f g), (f g) g) AG fAG f - in all paths, in all state - in all paths, in all state f f (in all future, (in all future, ff)) EG fEG f - in some path, in all states - in some path, in all states ff AF fAF f - in all paths, in some state - in all paths, in some state f f (in every future (in every future ff)) EF fEF f - in some future - in some future ff A(f U g)A(f U g) - in all paths, - in all paths, ff holds until holds until gg E(f U g)E(f U g) - in some path, f holds until - in some path, f holds until gg AX fAX f - in every next state, - in every next state, f f holds holds EX fEX f - in some next state - in some next state ff holds holds

ExamplesExamples AG ¬ (EW_light_go AG ¬ (EW_light_go NS_light_go) NS_light_go) AG (car_at_intersection AG (car_at_intersection AF(light_green)) AF(light_green)) AG (EF Restart)AG (EF Restart) EF (Start EF (Start ¬Ready)¬Ready)

Page 96: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

96

CTL model checkingCTL model checking

MM:: Transition System, Transition System, FF:: CTL formulae CTL formulae MM defines a tree (unwind the transition system) defines a tree (unwind the transition system) FF specifies existence of one or all paths satisfying specifies existence of one or all paths satisfying

some conditionssome conditions Verification checks whether these conditions hold Verification checks whether these conditions hold

for the tree defined by for the tree defined by MM Specifically:Specifically:

Compute the set of states of Compute the set of states of MM satisfying satisfying FF MM ╞ F╞ F iffiff initial states of initial states of MM are in this set are in this set

(Clarke and Emerson, Quielle and Sifakis)(Clarke and Emerson, Quielle and Sifakis)

M╞ FM╞ F

Page 97: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

97

CTL Model checking example 1CTL Model checking example 1

P Compute Compute EFpEFp

EF p = p EX(p) EX(EX(p)) . . .

P

P PSTEP 1

STEP 3

STEP 2

Fixed Point !! Computation terminates Computation terminates EFEF p Holds in all dark states p Holds in all dark states Computation involves Computation involves

backward breadth first traversal backward breadth first traversal Calculation of Strongly Calculation of Strongly

Connected Subgraphs (cycles)Connected Subgraphs (cycles)

Page 98: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

98

CTL Model checking example 2CTL Model checking example 2PP P

EG p = p EX p EX(EX p) . . .

ComputeCompute EG p EG p

PP PPP P

PP P PP PInitial:STEP 1 STEP 2

STEP 3 TERMINATION

Page 99: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

99

Checking safety conditionsChecking safety conditions

Start from SStart from S00 (Z)(Z) = set of initial = set of initial (bad)(bad) states states

Perform forward Perform forward (backward)(backward) reachability analysis reachability analysis to compute a reached state set R to compute a reached state set R (B)(B)

Determine if R Determine if R (B)(B) intersects Z intersects Z (S(S00))

S0

R

Z Z

B

Forward Reachability Backward Reachability

S0

S0: Initial states Z : Bad states

Page 100: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

100

Model checking approachesModel checking approaches

Explicit state model checkingExplicit state model checking Requires explicit enumeration of statesRequires explicit enumeration of states Impractical for circuits with large state spaces Impractical for circuits with large state spaces Useful tools exist: Murphi, SPIN, …Useful tools exist: Murphi, SPIN, …

Symbolic model checkingSymbolic model checking Representation & manipulation in terms of ROBDDs Representation & manipulation in terms of ROBDDs

or SAT solversor SAT solvers Core tasks:Core tasks:

Represent state machine (transition relation) and sets of Represent state machine (transition relation) and sets of states states

Forward/backward reachability analysisForward/backward reachability analysis Based on computing image/pre-image of set of statesBased on computing image/pre-image of set of states Fixed-point detectionFixed-point detection

Page 101: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

101

Symbolic manipulation with OBDDsSymbolic manipulation with OBDDs

StrategyStrategy Represent data as set of OBDDsRepresent data as set of OBDDs

Identical variable orderingsIdentical variable orderings Express solution method as sequence of symbolic Express solution method as sequence of symbolic

operationsoperations Implement each operation by OBDD manipulationImplement each operation by OBDD manipulation

Key Algorithmic PropertiesKey Algorithmic Properties Arguments: OBDDs with identical variable ordersArguments: OBDDs with identical variable orders Result is OBDD with same orderingResult is OBDD with same ordering Each step polynomial complexityEach step polynomial complexity

Page 102: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

102

Arguments Arguments II, , TT, , EE Functions over variables X Represented as OBDDs

ResultResultOBDD representing

composite function (I T) (I E)

MUX1

0

I T, E 

X

I  

If-Then-Else operationIf-Then-Else operation

ConceptConcept Basic technique for building OBDD from logic Basic technique for building OBDD from logic

network or formula.network or formula.

Page 103: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

103

0 1

d

c

a

B3 B4

B2

B5

B1

Argument I

1

Argument T Argument E

A4,B3 A5,B4

A3,B2

A6,B2

A2,B2

A3,B4A5,B2

A6,B5

A1,B1

Recursive Calls

b

0

d

1

c

a

A4 A5

A3

A2

A6

A1

If-Then-Else execution exampleIf-Then-Else execution example

OptimizationsOptimizations Dynamic programmingDynamic programming Early termination rulesEarly termination rules Apply reduction rules bottom-up as return from recursive callsApply reduction rules bottom-up as return from recursive calls

(Recursive calling structure implicitly defines unreduced BDD)(Recursive calling structure implicitly defines unreduced BDD)

Page 104: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

104

Derived algebraic operationsDerived algebraic operations

Other operations can be expressed in Other operations can be expressed in terms of If-Then-Elseterms of If-Then-Else

MUX1

0

F G, 0 

X

F  

G

0

MUX1

0

F 1, G 

X

G

1

XF 

G

XF 

G

And(F, G)

Or(F, G)

If-Then-Else(F, G, 0)

If-Then-Else(F, 1, G)

Page 105: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

105

Generating OBDD from networkGenerating OBDD from network

Task: Represent output functions of gate network as OBDDs.

Network

Evaluation

A

B

C

T1

T2

Out

Resulting Graphs

A B CT1 T2

Out

0 1

a

0 1

c

0 1

b

0 1

b

a

0 1

c

b

c

b

0 1

b

a

A A new_var ("a");new_var ("a");BB new_var ("b");new_var ("b");C C new_var ("c");new_var ("c");T1 T1 And (A, 0, B);And (A, 0, B);T2 T2 And (B, C); And (B, C);OutOut Or (T1, T2);Or (T1, T2);

Page 106: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

106

A0 /1

Set Operations

A

B

UnionA

B

Intersection

Characteristic functionsCharacteristic functions

ConceptConcept AA {0,1} {0,1}nn

Set of bit vectors of length Set of bit vectors of length nn Represent set Represent set AA as Boolean as Boolean

function function AA of of nn variables variables XX AA if and only if A( if and only if A(XX ) = 1 ) = 1

Page 107: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

107

Nondeterministic FSM Symbolic Representation

o1,o2 encodedold state

n1, n2 encodednew state

00

10

01

11 o2

o1

1

n2

0

n1

o2

Symbolic FSM representationSymbolic FSM representation

Represent set of transitions as function Represent set of transitions as function ((OldOld, , NewNew)) Yields 1 if can have transition from state Yields 1 if can have transition from state OldOld to state to state NewNew

Represent as Boolean functionRepresent as Boolean function Over variables encoding statesOver variables encoding states

Page 108: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

108

Reachability analysisReachability analysis

TaskTask Compute set of states reachable from initial state Compute set of states reachable from initial state QQ00

Represent as Boolean function Represent as Boolean function R(R(SS)) Never enumerate states explicitlyNever enumerate states explicitly

Rstate 0/1old state

new state0/1

Given Compute

InitialR0

=

Q0

Page 109: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

109

R0

00

Breadth-First reachability analysisBreadth-First reachability analysis

RRii – set of states that can be reached in– set of states that can be reached in ii transitionstransitions

Reach fixed point when Reach fixed point when RRn n = R= Rnn+1+1 Guaranteed since finite stateGuaranteed since finite state

00

10

01

11

R1R0

00 01

R2R1R0

00 01 10

R3R2R1R0

00 01 10

Page 110: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

110

Iterative computationIterative computation

Ri

Ri

Ri +1

old

new

)],'()'([)()( '1 sssRsRsR isii

1 ii

1 ii RR

00 QR do

until ALGORITHM

Page 111: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

111

BDD-based MC: Current statusBDD-based MC: Current status

Symbolic model checkers can analyze Symbolic model checkers can analyze sequential circuits with ~200- 400 flip flopssequential circuits with ~200- 400 flip flops For specific circuit types, larger state spaces have For specific circuit types, larger state spaces have

been analyzedbeen analyzed ChallengesChallenges

Memory/runtime bottlenecksMemory/runtime bottlenecks Adoption of TLs for property specificationAdoption of TLs for property specification

Frontier constantly being pushedFrontier constantly being pushed Abstraction & approximation techniquesAbstraction & approximation techniques Symmetry reductionSymmetry reduction Compositional reasoningCompositional reasoning Advances in BDD technology …Advances in BDD technology …

Page 112: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

112

Solving circuit problems as SATSolving circuit problems as SAT

a

b

c

d

e

f

g

h

i

Primary Output ‘i’ toPrimary Output ‘i’ to 1 1 ??Input Vector AssignmentInput Vector Assignment ??

Page 113: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

113

SAT formulas for simple gatesSAT formulas for simple gates

ab

c

))(( baba

a b

))()(( bacbcac

a

bc

))()(( bacbcac

a

bc

Page 114: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

114

Solving circuit problems as SATSolving circuit problems as SAT

Set of clauses representing function of each gateSet of clauses representing function of each gate

))()(( fcbfcfb

))()(( hfahfha

))()(( gedgegd

)(i))()(( ighigih

a

b

c

d

e

f

g

h

i

Unit literal clause asserting output to Unit literal clause asserting output to ‘1’‘1’

Page 115: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

115

SAT-based unbounded MCSAT-based unbounded MC SAT-based Inductive reasoningSAT-based Inductive reasoning Exact image computationExact image computation

Use SAT solver just for fixed-point detectionUse SAT solver just for fixed-point detection Image computation using SAT solverImage computation using SAT solver

McMillan CAV’02, Kang & Park DAC’02McMillan CAV’02, Kang & Park DAC’02

Approximate image computationApproximate image computation Using Craig Interpolants Using Craig Interpolants (McMillan CAV’03)(McMillan CAV’03)

Abstraction refinementAbstraction refinement Discussed later in the tutorialDiscussed later in the tutorial

Page 116: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

116

SAT-based reasoning on ILAsSAT-based reasoning on ILAs

PI PO

LATCHES

NSPS

CL

CL1 CL2 CLk NSk

PI2

POk

PI1 PIk

PO1 PO2

PS3PS2 PSk

NS1 NS2 NSk-1PS1

Unroll k-Steps

Popularized by the BMC work (Biere et al)

Current SAT solvers have shown good results

Page 117: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

117

SAT-based inductive reasoningSAT-based inductive reasoning

P

I0

‘1’

Base

Case

P

CLk+1 P ‘1’

‘1’

‘1’

Ind

ucti

on

S

tep

Simple Induction

UNSAT

UNSAT

AG P is TRUE+

II00 never satisfies ~ P never satisfies ~ P

If Ii never satisfies ~ P, then Ii+1 never satisfies ~P It is never the case that (I0 satisfies P) and (Ii+1 satisfies ~P)

Page 118: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

118

SAT-based inductive reasoningSAT-based inductive reasoning

P

P

CL1 CL2 CLkI0 P

P‘1’

Base

Case

P

P

CL1 CLk

P

CLk+1 P ‘1’

‘1’

‘1’

‘1’

Ind

ucti

on

S

tep

Induction with depth ‘k’(Sheeran et al, Bjesse et al FMCAD 2000)

Page 119: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

119

SAT-based inductionSAT-based induction

Can prove or disprove propertiesCan prove or disprove properties k-depth induction:k-depth induction:

Can check more properties for larger kCan check more properties for larger k Base case is simply k-length BMCBase case is simply k-length BMC But But notnot complete ! complete !

Not k - depth inductive for

any k !P P

Unreachable state-space

Example:

Page 120: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

120

Complete!

SAT-based inductive reasoningSAT-based inductive reasoning

Unique paths Induction:Unique paths Induction: Restrict unrolled ILA to be loop-freeRestrict unrolled ILA to be loop-free Sheeran et al, Bjesse et al FMCAD’00Sheeran et al, Bjesse et al FMCAD’00 Unrolling upto Unrolling upto recurrence diameterrecurrence diameter i.e. length of longest loop-free pathi.e. length of longest loop-free path

Stronger induction methods can be expensiveStronger induction methods can be expensive But,But, some properties very easy to prove by some properties very easy to prove by

induction, very hard by state-space traversalinduction, very hard by state-space traversal Simple induction can be cheap, first step in Simple induction can be cheap, first step in

verification flowverification flow

Page 121: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

121

SAT-based image computationSAT-based image computation

InitsR )(0

))()',(.(toProp)'(1 sRssTrssR ii

i

k

i

k

kk sRsR0

1

0

)()(

)()( sPsRi

do

until or

1ii

Bug found ! Fixed-point

0i

SATSolver

Issues: Function representation Quantification

Page 122: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

122

Function RepresentationFunction Representation

Representation of: Representation of: Init, RInit, Rii(s), P(s), Tr(s,s’)(s), P(s), Tr(s,s’)

Converted to CNF for SAT solvingConverted to CNF for SAT solving

x z y

Reduced Boolean Circuit (RBC)

b

b a

0 1

Boolean Expression Diagram (BED)Abdulla et al, TACAS 2000 Williams et al, CAV 2000

Page 123: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

123

QuantificationQuantification

Apply definition of existential quantification:Apply definition of existential quantification:

Mitigate formula blow-up by:Mitigate formula blow-up by: Inherent reduction rules of function rep.Inherent reduction rules of function rep. Special case quantification rules:Special case quantification rules:

Limitation:Limitation: Suitable only when small number Suitable only when small number of variables to be quantified of variables to be quantified

)1()0()(. xxxx

Inlining: )()().( xxx )(Vars xwhere

))(.()(. xxxx

))(.())(.()()(. xxxxxxx

Scope Reduction:)(Vars xwhere

Page 124: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

124

Exact image computation using SATExact image computation using SAT

procedure AG(p)procedure AG(p)

Let Z = Q = pLet Z = Q = p

while Z while Z 1 1

let Z = (let Z = (W · pW · pii/s/sii))QQ

let Q = Q let Q = Q Z Zreturn Qreturn Q

SolveSolve W · fW · f

Solution: Express f in CNF: fCNF

Drop all wi literals from fCNF

Core problem: Express a given formula f in CNF

McMillan, CAV 2002CTL Model CTL Model CheckingChecking

Page 125: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

125

Computing a CNF representation for fComputing a CNF representation for f

Basic AlgorithmBasic Algorithm Create CNF(f)Create CNF(f) Solve Solve SAT(CNF(f) SAT(CNF(f) vf) Compute Compute blocking clauseblocking clause

for each satisfying for each satisfying assignmentassignment

Collect all blocking Collect all blocking clauses clauses f fCNFCNF

e.g. f = (ab)c

a

b

cvf

vab

CNF(f)

fCNF= (bc) (ac)

: (b: (bc) ) , (a(ac))Blocking Blocking ClausesClauses

Blocking Clauses Must:Blocking Clauses Must: Contain only original vars. of Contain only original vars. of ff Be false under some sat. assgn. Be false under some sat. assgn.

of CNF(f) of CNF(f) vf

Be implied by CNF(f) CNF(f) vf

Page 126: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

126

Some issuesSome issues

Issues:Issues: Blocking clauses expressed in terms of original Blocking clauses expressed in terms of original

variables of variables of ff Extracted from a separate implication graphExtracted from a separate implication graph

Quantification of Quantification of WW vars. can be performed on vars. can be performed on each generated blocking clause: each generated blocking clause: Combine both Combine both steps into one!! steps into one!!

Conclusions:Conclusions: Technique promising where BDDs blow upTechnique promising where BDDs blow up BDDs superior as a general purpose techniqueBDDs superior as a general purpose technique Proposed technique needs more polishingProposed technique needs more polishing

Page 127: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

127

Lecture 5Lecture 5

Enhancing formal verification capacityEnhancing formal verification capacity Abstraction-refinementAbstraction-refinement Assume guarantee/Compositional Assume guarantee/Compositional

ReasoningReasoning ApproximationApproximation Symmetry reductionSymmetry reduction Partial Order ReductionPartial Order Reduction

Industrial and research tool offeringsIndustrial and research tool offerings

Page 128: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

128

AbstractionAbstraction

Limitations of symbolic model checkingLimitations of symbolic model checking Suffers from state explosionSuffers from state explosion

ConcurrencyConcurrency Data domainsData domains

Abstraction of state spaceAbstraction of state space Represent the state space using a smaller modelRepresent the state space using a smaller model Pay attention to preserving the checked properties.Pay attention to preserving the checked properties. Do not affect the flow of controlDo not affect the flow of control..

Page 129: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

129

ExampleExample

Use smaller data objectsUse smaller data objects HDL Code:HDL Code:

X:= f(m);X:= f(m);

Y:=g(n);Y:=g(n);

if (X*Y>0) if (X*Y>0)

then …then …

else …else …

X, Y never X, Y never

used again.used again.

Assign values {-1, 0, 1} to X and Y.Assign values {-1, 0, 1} to X and Y. Based on the following connection:Based on the following connection:

sgn(X) = 1 if X>0,sgn(X) = 1 if X>0, 0 if X=0, and 0 if X=0, and -1 if X<0. -1 if X<0.sgn(X)*sgn(Y)=sgn(X*Y).sgn(X)*sgn(Y)=sgn(X*Y).

Change f and g to produce abstract Change f and g to produce abstract values for X and Yvalues for X and Y

Page 130: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

130

Abstraction vs. simplificationAbstraction vs. simplification Not every simplified system is an Not every simplified system is an

abstractionabstraction The key question is:The key question is:

If we prove or disprove a property of the If we prove or disprove a property of the simplified system, what have we learned simplified system, what have we learned about the original system?about the original system?

Page 131: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

131

Abstraction (Cont)Abstraction (Cont)

Abstract transition relation is conservativeAbstract transition relation is conservative Abstract next states Abstract next states mustmust contain all concrete successors contain all concrete successors And possibly more statesAnd possibly more states

RA

Abstract

Concrete

RC

s

t

x y

Page 132: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

132

Abstract counter-exampleAbstract counter-example

If model checking fails an abstract counter-example is If model checking fails an abstract counter-example is producedproduced

Concrete transitions are present for each pair of Concrete transitions are present for each pair of consecutive abstract statesconsecutive abstract states But concrete counter-example may not be present!But concrete counter-example may not be present!

x

y’

zy’’

Abstract

ConcreteReal Trace

Spurious Trace

Page 133: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

133

Abstraction refinedAbstraction refined

Abstraction is refined by adding more statesAbstraction is refined by adding more states prevents previous spurious counter exampleprevents previous spurious counter example

Model checking is repeated on new abstractionModel checking is repeated on new abstraction iterateiterate

x

y1

z

y’’

Abstract

ConcreteReal Trace

New Trace

Page 134: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

134

Abstraction refinement algorithmAbstraction refinement algorithm

Build abstract model

Model check

abstractmodel

Check abstract

counterexampleon concrete

model

abstractcounterexample

True on concrete model

true

Infeasible

abort

False on concrete model

real counterexample

Refinement

spuriouscounterexample

Page 135: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

135

Assume-Guarantee ReasoningAssume-Guarantee Reasoning

R <S

Sender Receiver Property|| has

S and R are just too large to be verified at the S and R are just too large to be verified at the same timesame time

Like to verify S and R separately !Like to verify S and R separately !

Page 136: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

136

Assume-Guarantee ReasoningAssume-Guarantee Reasoning

R R’< <S S’

First try to find something intermediate, S’ and First try to find something intermediate, S’ and R’ between the designs and the specification, R’ between the designs and the specification, such that it is easy to verify that S’ and R’ such that it is easy to verify that S’ and R’ satisfy the propertysatisfy the property

Page 137: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

137

Assume-Guarantee ReasoningAssume-Guarantee Reasoning

R R’< <S

R

S

S’

S’

R’<

<

If we can verify individual cases separately, we If we can verify individual cases separately, we are done !are done !

Page 138: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

138

Assume-Guarantee ReasoningAssume-Guarantee Reasoning

R R< <S

R

S

S

S’

R’<

<

But normally we cannot due to unconstrained But normally we cannot due to unconstrained inputsinputs

Inputs are unconstrained

Inputs are unconstrained

Page 139: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

139

Assume-Guarantee ReasoningAssume-Guarantee Reasoning

R R’< <S

R

S

S’

R’ S’

R’S’ <

<

Use S’ and R’ to constrain inputs !Use S’ and R’ to constrain inputs !

Page 140: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

140

Assume-Guarantee ReasoningAssume-Guarantee Reasoning

R R->S

R

S

S

R S

RS ->

->

&

&

&

&

This is a theorem !This is a theorem !AG reasoning: ExampleAG reasoning: Example

Page 141: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

141

Symmetry reductionsSymmetry reductions

Idea: If state space is symmetric, explore only a symmetric “quotient” of the state space

A permutation function f : S A permutation function f : S S S is an automorphism if:is an automorphism if:

( x, z) ( x, z) ( f(x), f(z))( f(x), f(z))

0,0

1,1

0,1

1,0

f: f(0,0) = 1,1 f(1,1) = 0,0f: f(0,0) = 1,1 f(1,1) = 0,0

f(0,1) = 0,1 f(1,0) = 1,0f(0,1) = 0,1 f(1,0) = 1,0

e.g.

The set of all automorphisms forms a The set of all automorphisms forms a group!group!

Automorphism groups induce Automorphism groups induce equivalence classes (orbits) over the equivalence classes (orbits) over the state spacestate space [ (0,1), (1,0) ][ (0,1), (1,0) ]

[ (0,0), [ (0,0), (1,1) ](1,1) ]

e.g.

Page 142: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

142

Quotient machineQuotient machine

Map each state to its representative in Map each state to its representative in the orbitthe orbit

Do model checking analysis on the Do model checking analysis on the quotient machinequotient machine

0,0

1,1

0,1

1,0

[ (0,0),(1,1) ]

[ (0,1), (1,0) ]

Quotient machine

Page 143: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

143

Symmetry reductionsSymmetry reductions

DifficultyDifficulty Identifying symmetry groupsIdentifying symmetry groups Computing function mapping states to Computing function mapping states to

representativesrepresentatives

SolutionsSolutions Ask user to tell you where the symmetries are Be satisfied with multiple representatives for

each orbit

Tools: Mur, Nitpick, RuleBase

Page 144: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

144

Over-approximate reachabilityOver-approximate reachability

Exact reachability captures the exact reachable Exact reachability captures the exact reachable state-spacestate-space Problem: BDD-blowup in many real designsProblem: BDD-blowup in many real designs

Solution: Compute over-approximation of the Solution: Compute over-approximation of the reachable statesreachable states

R1

R2+R1

+

R2R

I0

R+ Often sufficient to prove Often sufficient to prove properties correctproperties correct

Error could be a false Error could be a false negativenegative

Can trade off BDD-size Can trade off BDD-size and runtime with accuracy and runtime with accuracy of approximationof approximation

Page 145: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

145

Over-approx. reachability techniquesOver-approx. reachability techniques

Split FSM into sub-Split FSM into sub-machines by machines by partitioning state-partitioning state-varsvars

Perform (exact) Perform (exact) reachability on each reachability on each machinemachine

Cross-product of Cross-product of reached state reached state spaces gives over-spaces gives over-approx. for original approx. for original FSMFSM

LATCHES

PI PO

NSPS

CL

X X

Page 146: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

146

Over-approx: more issuesOver-approx: more issues

Communicate between sub-FSMs to tighten Communicate between sub-FSMs to tighten approximationapproximation After each time-frameAfter each time-frame After least fixpoint computation for a sub-FSMAfter least fixpoint computation for a sub-FSM

Computing partitionsComputing partitions Heuristic and/or manualHeuristic and/or manual Disjoint partitions Disjoint partitions (Cho et al)(Cho et al) Overlapping partitions Overlapping partitions (Govindaraju et al)(Govindaraju et al)

Can capture limited interaction among sub FSMsCan capture limited interaction among sub FSMs Tighter approximationTighter approximation May not increase BDD sizes muchMay not increase BDD sizes much

Page 147: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

147

Partial Partial oorder rder rreductioneduction

Factor out independent state transitions!Factor out independent state transitions!(typical for asynchronous communication (typical for asynchronous communication as in Software- and Protocol-Checking)as in Software- and Protocol-Checking)

May result in exponential reductionMay result in exponential reductionin the number of statesin the number of states

Synchronization

Irrele

vant

StatesOne Relevant Trace of States

Process B

transition

Process Atransition

Page 148: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

148

Model Checkers - Research ToolsModel Checkers - Research Tools

SMV (CMU, Cadence)SMV (CMU, Cadence) VIS (UC Berkeley)VIS (UC Berkeley) Mocha (UC Berkeley, compositional Mocha (UC Berkeley, compositional

reasoning) reasoning) Verisoft (AT&T, C-model checker)Verisoft (AT&T, C-model checker) Bandera (Java model checker)Bandera (Java model checker)

Page 149: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

149

Industrial Model CheckersIndustrial Model Checkers FormalCheckFormalCheck (Cadence) (Cadence)

COSPANCOSPAN (from Bell Labs) under the hood (from Bell Labs) under the hood Support for arbitrary precision arithmeticSupport for arbitrary precision arithmetic Automatic bus-contention, multi-driver violation, tri-Automatic bus-contention, multi-driver violation, tri-

state support fir high-impedance checkstate support fir high-impedance check Powerful design reduction techniquesPowerful design reduction techniques

Removal of portions of design that do not affect the Removal of portions of design that do not affect the property being provenproperty being proven

Constant & constraint propagationConstant & constraint propagation Iterative reduction guarantees that queries proven on the Iterative reduction guarantees that queries proven on the

reduced design hold on the entire designreduced design hold on the entire design

Page 150: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

150

EDA Vendor Tool OfferingsEDA Vendor Tool Offerings

Verplex (Cadence) Verplex (Cadence) BlacktieBlacktie IBM IBM RuleBaseRuleBase @HDL - @HDL - @Verifier@Verifier

works on Verilog RTLworks on Verilog RTL static assertion checksstatic assertion checks automatic property extractionautomatic property extraction clock domain synchronization errorsclock domain synchronization errors

Real Intent Real Intent VerixVerix slimilar to @Verifierslimilar to @Verifier

Averant Averant Solidify Solidify Jasper design automation Jasper design automation Jasper GoldJasper Gold

Page 151: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

151

Lecture 6: Semi-formal verificationLecture 6: Semi-formal verification

Coverage

2K 20K 200K 2M

Existing

Formal

Verification

Random simulation

Manual testw/ coverage

FV Augmented Simulation

(Falsification)

GATES

FV + Complete coverage - Limited capacity

Simulation +Unlimited capacity - Poor coverage

FV Augmented Simulation+ Good coverage+ Good capacity

Page 152: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

152

Section outlineSection outline

Symbolic simulationSymbolic simulation Symbolic trajectory evaluation (STE)Symbolic trajectory evaluation (STE) SAT-based bounded model checkingSAT-based bounded model checking Sequential ATPG-based model Sequential ATPG-based model

checkingchecking Guided searchGuided search Smart simulationSmart simulation

Page 153: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

153

Symbolic simulationSymbolic simulation

Symbolic simulation:Symbolic simulation: Symbolic expressions used for inputsSymbolic expressions used for inputs Expressions propagated to compute outputsExpressions propagated to compute outputs Equivalent to multiple constant simulations !!Equivalent to multiple constant simulations !!

a·b+b·c

a

b

c

1

1

0

1

Conventional simulation:Conventional simulation: Input & outputs are constants (0,1,X,…)Input & outputs are constants (0,1,X,…)

Problem: Too many constant

input combinations to simulate !!

Ref: Prof. David Dill, CAV ’99c

Page 154: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

154

Symbolic simulation (sequential case)Symbolic simulation (sequential case)

a0

b0

c

a0·b0 + b0 ·ca1

b1

a1·b1+b1·(a0·b0 + b0·c)

a0·b0 + b0·c

a0

b0

a1

b1

c

a1·b1+b1·(a0·b0 + b0·c)

Unrolled Circuit

Time frame 1

Time frame 2

Page 155: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

155

Symbolic simulationSymbolic simulation

a

b

c

a·b + b ·c

1

b

c

b + c

a+b

b

c

b + c

Inputs can be constants

Input expressions

can be related

Simulate certain set Simulate certain set of patterns of patterns

Model signal Model signal correlationscorrelations

Can result in simpler Can result in simpler output expressionsoutput expressions

Page 156: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

156

Symbolic simulationSymbolic simulation

Use BDDs as the symbolic representationUse BDDs as the symbolic representation Work at gate and MOS transistor levelWork at gate and MOS transistor level Can exploit abstraction capabilities of ’X’ Can exploit abstraction capabilities of ’X’

valuevalue Can be used to model unknown/don’t care Can be used to model unknown/don’t care

valuesvalues Common use in representing uninitialized state Common use in representing uninitialized state

variablesvariables Boolean functions extended to work with {0,1,X}Boolean functions extended to work with {0,1,X} Two BDD (binary) variables used to represent Two BDD (binary) variables used to represent

each symbolic variableeach symbolic variable

Page 157: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

157

Symbolic simulationSymbolic simulation

Advantages Advantages Can handle larger designs than model checkingCan handle larger designs than model checking Can use a large variety of circuit modelsCan use a large variety of circuit models Possibly more natural for non-formalists.Possibly more natural for non-formalists. Amenable to partial verification.Amenable to partial verification.

Disadvantages Disadvantages Not good with state machines (possibly better Not good with state machines (possibly better

with data paths).with data paths). Does not support temporal logicDoes not support temporal logic

Requires ingenuity to prove properties.Requires ingenuity to prove properties.

Page 158: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

158

Practical deploymentPractical deployment

Systems:Systems: COSMOS [bryant et al], Voss[Seger et al Intel]COSMOS [bryant et al], Voss[Seger et al Intel] Magellan [Synopsys]Magellan [Synopsys] InnologicInnologic

Exploiting hierarchyExploiting hierarchy Symbolically encode circuit structureSymbolically encode circuit structure

Based on hierarchy in circuit descriptionBased on hierarchy in circuit description Simulator operates directly on encoded circuitSimulator operates directly on encoded circuit

Use symbolic variables to encode both data values & Use symbolic variables to encode both data values & circuit structurecircuit structure

Implemented by Innologic, Synopsys (DAC ‘02)Implemented by Innologic, Synopsys (DAC ‘02) Greatest success in memory verification Greatest success in memory verification

(Innologic)(Innologic)

Page 159: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

159

High-level symbolic simulationHigh-level symbolic simulation

Data Types: Boolean, bitvectors, int, reals, arraysData Types: Boolean, bitvectors, int, reals, arrays Operations: logical, arithmetic, equality, Operations: logical, arithmetic, equality,

uninterpreted functionsuninterpreted functions Final expression contains variables and Final expression contains variables and

operatorsoperators Coupled with Decision procedures to check Coupled with Decision procedures to check

correctness of final expressioncorrectness of final expression Final expressions can also be manually checked Final expressions can also be manually checked

for unexpected terms/variables, flagging errors for unexpected terms/variables, flagging errors e.g. in JEM1 verification [Greve ‘98]e.g. in JEM1 verification [Greve ‘98]

Page 160: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

160

High-level symbolic simulationHigh-level symbolic simulation

Manipulation of symbolic expressions done Manipulation of symbolic expressions done withwith Rewrite systems like in PVSRewrite systems like in PVS Boolean and algebraic simplifiers along with Boolean and algebraic simplifiers along with

theories of linear inequalities, equalities and theories of linear inequalities, equalities and uninterpreted functionsuninterpreted functions

Extensively used along with decision Extensively used along with decision procedures in microprocessor verificationprocedures in microprocessor verification Pipelined processors: DLXPipelined processors: DLX Superscalar processors: Torch (Stanford)Superscalar processors: Torch (Stanford) Retirement logic of Pentium ProRetirement logic of Pentium Pro Processors with out of order executionsProcessors with out of order executions

Page 161: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

161

Symbolic trajectory evaluation (STE)Symbolic trajectory evaluation (STE)

Trajectory : Sequence of values of system Trajectory : Sequence of values of system variablesvariables Example: c = AND (a, b) and delay is 1Example: c = AND (a, b) and delay is 1 A possible trajectory : (a,b,c) = (0, 1, X), (1, 1, 0), (1, 0, A possible trajectory : (a,b,c) = (0, 1, X), (1, 1, 0), (1, 0,

1), (X, X, 0), (X, X, X),… 1), (X, X, 0), (X, X, X),… Express behavior of system model as a set of Express behavior of system model as a set of

trajectories trajectories II and desired property as a set of and desired property as a set of trajectories trajectories SS

Determine if Determine if II is inconsistent with is inconsistent with SS Inconsistent: Inconsistent: II says 0 but says 0 but SS says 1 for a signal at time t says 1 for a signal at time t Consistent: Consistent: II says 0 but says 0 but SS says X or 0 for a signal at says X or 0 for a signal at

time ttime t

Page 162: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

162

STE: An exampleSTE: An example

DinX

DoutX X X T = 0X

Dina

DoutX X X X T = 1X

DinX

DoutX a X X T = 2X

DinX

DoutX X a X T = 3X

DinX

DoutX X X a T = 4a

Din = a NNNN Dout = a

aAssert

Check

Din Dout

4-Bit Shift Register

Din = a NNNN Dout = a

Specification

If apply input a then 4 cycles later will get output a

Ref: Prof. Randal Bryant, 2002

Page 163: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

163

STE: Pros, cons & uSTE: Pros, cons & u

Advantage: Higher capacity than symbolic Advantage: Higher capacity than symbolic model checkingmodel checking

Disadvantage: Properties checkable not as Disadvantage: Properties checkable not as expressive as CTLexpressive as CTL

Practical success of STEPractical success of STE Verification of arrays (memories, TLBs etc.) in Verification of arrays (memories, TLBs etc.) in

Power PC architecturePower PC architecture x86 Instruction length decoder for Intel processorx86 Instruction length decoder for Intel processor Intel FP adderIntel FP adder Microprocessor verificationMicroprocessor verification

Page 164: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

164

SAT-based bounded model checkingSAT-based bounded model checking

PI PO

LATCHES

NSPS

CL

P ?

Example F: AG P

Question: Does M have a counter-example to F within k transitions ?

FSM M

Biere et al (TACAS’99, DAC’99)

Property F

Page 165: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

165

SAT-based bounded model checkingSAT-based bounded model checking

P

P

CL1 CL2 CLkI0 P

P‘1’

Unroll M for k time-frames

CNFSAT

Solver

Counter-example to AG

P

No Counter-example within k

steps

SAT

UNSAT

Page 166: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

166

Open problem!!

SAT-based BMCSAT-based BMC

Primarily used for finding bugs !Primarily used for finding bugs ! Verification complete if Verification complete if k > sequential k > sequential

depthdepth of M of M Sequential depth computation or tight Sequential depth computation or tight

estimation intractable in practice estimation intractable in practice

Can express both safety and liveness Can express both safety and liveness properties (bounded semantics)properties (bounded semantics) All LTL formulasAll LTL formulas Unbounded fairness by detecting loopsUnbounded fairness by detecting loops

Page 167: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

167

SAT-based BMC: Pros & consSAT-based BMC: Pros & cons Advantages:Advantages:

SAT-BMC good at producing counter-examples upto SAT-BMC good at producing counter-examples upto medium depths (upto 50-60)medium depths (upto 50-60)

SAT solvers less sensitive to size of design: SAT solvers less sensitive to size of design: SAT-SAT-BMC can handle larger designsBMC can handle larger designs

SAT solvers require less parameter tuning: SAT solvers require less parameter tuning: Productivity gainProductivity gain

Drawbacks:Drawbacks: Incomplete method: Cannot verify propertiesIncomplete method: Cannot verify properties Ineffective at larger depths: Slow, CNF blow-upIneffective at larger depths: Slow, CNF blow-up Cannot describe all CTL propertiesCannot describe all CTL properties

Page 168: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

168

Enhancements to basic SAT-BMCEnhancements to basic SAT-BMC

CNF generation for BMCCNF generation for BMC Bounded cone-of-influence: Biere Bounded cone-of-influence: Biere et alet al CAV’99 CAV’99 Circuit-graph compression: Ganai Circuit-graph compression: Ganai et alet al VLSID’02 VLSID’02 Binary time-frame expansion: Fallah ICCAD’02Binary time-frame expansion: Fallah ICCAD’02

Decision variable orderingDecision variable ordering BMC-specific static ordering: Strichman CAV’00BMC-specific static ordering: Strichman CAV’00 Tuning VSIDS for BMC: Shacham Tuning VSIDS for BMC: Shacham et alet al MTV’02 MTV’02

Addition of clauses/constraintsAddition of clauses/constraints Sharing clauses across BMC runs: Strichman CHARME’01Sharing clauses across BMC runs: Strichman CHARME’01 Learning clauses from BDDs: Gupta Learning clauses from BDDs: Gupta et alet al DAC’03 DAC’03 Using BDD reachability over-approx: Cabodi Using BDD reachability over-approx: Cabodi et alet al DATE’03 DATE’03

Page 169: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

169

Sequential ATPG for MCSequential ATPG for MC

CIRCUIT AUTOMATA

TEST NETWORK

from property

stuck-at fault

INPUT

CIRCUIT

s-a-0 fault

INPUT

p

AG p EF pe.g.

Proposed by Boppana, Rajan, Takayama & Fujita, CAV ‘99

Page 170: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

170

Advantages of sequential ATPG-based MCAdvantages of sequential ATPG-based MC

No explicit storage of No explicit storage of statesstates

No need to build No need to build transition relationtransition relation

Good balance of DFS Good balance of DFS and BFS traversal of and BFS traversal of state-spacestate-space

Can model real-world Can model real-world primitives, primitives, e.g.e.g. tri-state tri-state buses, high impedence buses, high impedence valuevalue

No explicit unrolling of No explicit unrolling of time-framestime-frames

Uses circuit-based Uses circuit-based heuristics to guide or heuristics to guide or speed-up searchspeed-up search

vs BDDs vs SAT-BMC

Page 171: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

171

Sequential ATPG for BMCSequential ATPG for BMC

Recent work Recent work by Abraham by Abraham et alet al (ITC’02, (ITC’02, VLSID’03)VLSID’03)

Model both Model both safety & safety & liveness liveness properties properties (bounded)(bounded)

ORIGINAL CIRCUIT

MONITOR

PROPERTY n

stuck-at faultTEST

NETWORK

start0 1 2 n-1 n

p

pp pp p

pp

pExample:

EG p

Page 172: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

172

ATPG-MC: Current statusATPG-MC: Current status Attempts to use simulation-based ATPG for Attempts to use simulation-based ATPG for

falsification (Hsiao falsification (Hsiao et alet al HLDVT’01, DAC’02) HLDVT’01, DAC’02) No research characterizing fragment of language No research characterizing fragment of language

(e.g. CTL, LTL) checkable through ATPG-based MC(e.g. CTL, LTL) checkable through ATPG-based MC Some works report dramatic improvements of seq. Some works report dramatic improvements of seq.

ATPG-BMC vs. SAT-BMCATPG-BMC vs. SAT-BMC Current efforts towards combining SAT solvers Current efforts towards combining SAT solvers

and sequential ATPG (SATORI ICCAD’03)and sequential ATPG (SATORI ICCAD’03)

Page 173: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

173

Guided searchGuided search

State-space search optimized for bug-State-space search optimized for bug-searching (Yang & Dill, DAC 98)searching (Yang & Dill, DAC 98)

Use prioritized searchUse prioritized search Cost function to pick next state to searchCost function to pick next state to search

Hamming distance to error statesHamming distance to error states

Breadth-first Search

Error State

Prioritized Search

Error State

Page 174: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

174

Improving guided searchImproving guided search

Target enlargementTarget enlargement

ErrorStates

Reset State

Without Target

Enlargement

Enlarged Error States

also Yuan et al CAV 97also Yuan et al CAV 97

Improved cost functionImproved cost function TracksTracks

Compute series of approximate preimages

Use the approximate pre-image to estimate distance to enlarged target

GuidepostsGuideposts Designer provided hints/necessary Designer provided hints/necessary

pre-conditions for assertion violationpre-conditions for assertion violation

Bias search to explore search with Bias search to explore search with those pre-conditionsthose pre-conditions

Page 175: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

175

Smart simulation I : SIVASmart simulation I : SIVA

Combines random simulation with BDDs and Combines random simulation with BDDs and combinational ATPGcombinational ATPG

Identify targetsIdentify targets Indicator variables, coverage goals, fail states etc.Indicator variables, coverage goals, fail states etc. Lighthouses: Lighthouses:

Several per targetSeveral per target ““Sub-targets” to guide SIVA to reach a targetSub-targets” to guide SIVA to reach a target

At each state identify targets with constant At each state identify targets with constant simulation signaturesimulation signature

Advance simulation by visiting states which causes Advance simulation by visiting states which causes such targets to toggle valuesuch targets to toggle value Search for such next state by ATPG/BDDsSearch for such next state by ATPG/BDDs

[Ganai, Aziz, Kuehlmann DAC ‘99]

Page 176: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

176

R1’R1’

R5000’R5000’

RANDOMRANDOM

INITIALINITIAL

BDDBDD

ATPGATPG

R1R1

R2R2

R5000R5000

D1D1

D2D2

D1’D1’

SIVA - a runSIVA - a run

Key:Key: Determination of appropriate targets, Determination of appropriate targets, lighthouses etc. to guide the searchlighthouses etc. to guide the search

Page 177: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

177

Smart simulation II: MagellanSmart simulation II: Magellan

Coverage-driven test generationCoverage-driven test generation Identify few interesting signals (typically <64): Identify few interesting signals (typically <64):

coverage signalscoverage signals Goal:Goal: Maximize Maximize state-coveragestate-coverage on coverage on coverage

signalssignals Test generationTest generation

Interleave random simulation with symbolic Interleave random simulation with symbolic simulation & SAT-BMCsimulation & SAT-BMC

Unreachability analysis Unreachability analysis (under-approx)(under-approx) Identify unreachable coverage states to reduce Identify unreachable coverage states to reduce

coverage target coverage target

[Ho et al, ICCAD 2000 (Synopsys)]

Page 178: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

178

Magellan methodologyMagellan methodology

Random simulation:Random simulation: Deep narrow search Deep narrow search SAT-BMC:SAT-BMC: Short-range exhaustive (wide) search (<10 steps) Short-range exhaustive (wide) search (<10 steps) Symbolic simulation:Symbolic simulation: Middle range exhaustive (wide) search Middle range exhaustive (wide) search

Initial state

Coverage state

Random simulation

Symbolic simulation / SAT-BMC

(10-50 steps)(10-50 steps)

Page 179: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

179

Smart simulation III: 0-in searchSmart simulation III: 0-in search

Approach:Approach: Test amplificationTest amplification Identify Identify “seed states”“seed states” reached through reached through

simulation simulation i.e.i.e. directed or random simulation directed or random simulation Explore exhaustively behavior around seed Explore exhaustively behavior around seed

states using formal methodsstates using formal methods SAT-BMC, BDDs, symbolic simulationSAT-BMC, BDDs, symbolic simulation

Formal

+ =

Simulation 0-In Search

Page 180: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

180

Methodology: Assertion-based VerificationMethodology: Assertion-based Verification

Use checkers (written in HDL) to:Use checkers (written in HDL) to: Specify targets for simulation/formal methods Specify targets for simulation/formal methods

Capturing buggy conditionsCapturing buggy conditions Specify environment of a module Specify environment of a module

Can be synthesized into constraintsCan be synthesized into constraints Specify interfaces between componentsSpecify interfaces between components

Inserting checkers:Inserting checkers: From 0-in From 0-in CheckerWareCheckerWare library (~60 checkers) library (~60 checkers) Specified by the user in VerilogSpecified by the user in Verilog Created automatically from RTL directives Created automatically from RTL directives

By By 0-in Check functional0-in Check functional tool tool Suggested by Suggested by 0-in Checklist0-in Checklist while analyzing RTL while analyzing RTL

A kind of sophisticated lint checkingA kind of sophisticated lint checking

Page 181: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

181

0-in search: Tool flow0-in search: Tool flow

Instrumented Verilog RTL

Verilog Tests and Testbench

Standard Verilog Simulator

No firings in Verilog output

Simulation Trace (Seed)

Firings Log 0-in View GUI Standard Waveform Tool

Checker Control File

Verilog simulator (Firing Replay)

0-in Search 0-in Confirm

Verilog Files with 0-in Checkers

Source: 0-in Design Automation Verification

White-paper

Page 182: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

182Lecture 7: Formal verification in C-based Lecture 7: Formal verification in C-based (SpecC/SystemC) based design methodology(SpecC/SystemC) based design methodology

C based design C based design descriptions from descriptions from specification (functional) specification (functional) level down to RTLlevel down to RTL

Incremental refinement on Incremental refinement on the C/C++ descriptionsthe C/C++ descriptions

Equivalence checking Equivalence checking between refinementsbetween refinements Between sequential and Between sequential and

parallel descriptions parallel descriptions Between two same control Between two same control

structuresstructures Property checking on each Property checking on each

refinementrefinement

Specificationin C

Refined description for hardware partsSoftware parts remain the same

Refined descriptionwith concurrency

Removal of pointer,recursive calling

Introduction ofconcurrency(SpecC or SystemCmay be used here) To RTL

design: Refinement step

Equivalence checking between two descriptions

Figure 1. C-based system design flow

Model checking on each description

Please note that in system level designs, both SpecC and SystemC have similar description mechanisms

Page 183: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

183

Execution semantics in SpecCExecution semantics in SpecC Sequentiality rule:Sequentiality rule:

Tstart(B1) <= Tstart(a) < Tend(a) <=Tstart(B1) <= Tstart(a) < Tend(a) <= Tstart(b) < Tend(b) <= Tstart(b) < Tend(b) <= Tstart(c) < Tend(c) <= Tend(B1) Tstart(c) < Tend(c) <= Tend(B1)

Sequential execution within a threadSequential execution within a thread

behavior B1{ void main(void) { a.main(); b.main(); c.main(); }};

B1

a b c

time

ExampleExample

Page 184: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

184

d

a b c

time

B

e f

Execution semantics in SpecC (cont.)Execution semantics in SpecC (cont.)

Possible Schedule

Sequentiality rule:Sequentiality rule:Tstart(B) <= Tstart(a) < Tend(a) <=Tstart(B) <= Tstart(a) < Tend(a) <=

Tstart(b) < Tend(b) <= Tstart(b) < Tend(b) <= Tstart(c) < Tend(c) <= Tend(B) Tstart(c) < Tend(c) <= Tend(B)

Tstart(B) <= Tstart(d) < Tend(d) <=Tstart(B) <= Tstart(d) < Tend(d) <= Tstart(e) < Tend(e) <= Tstart(e) < Tend(e) <= Tstart(f) < Tend(f) <= Tend(B) Tstart(f) < Tend(f) <= Tend(B)

behavior B2{ void main(void) { d.main(); e.main(); f.main();} };

behavior B1{ void main(void) { a.main(); b.main(); c.main();} };

behavior B{ void main(void) { par { b1.main(); b2.main();} }};

Example: concurrency/pallalelismExample: concurrency/pallalelism

Page 185: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

185

Synchronization semanticsSynchronization semantics

wait/notify rule in time-interval formalism:wait/notify rule in time-interval formalism: waitwait cannot proceed until it receives a notified cannot proceed until it receives a notified

eventevent notified event is validnotified event is valid

until a until a waitwait or or waitforwaitfor statement is reached statement is reached

Example:Example: Notify-wait rule derives: Tend(w) >= Tend(n)Notify-wait rule derives: Tend(w) >= Tend(n)

wait cannot proceed until it receives notified eventwait cannot proceed until it receives notified event

a w b

c n d

A

B

thread

time

‘wait e1’ starts

‘notify e1’ done

‘wait e1’ succeeds

this order is guaranteed!

behavior A: a.main(); wait e1; b.main();behavior B: c.main(); notify e1; d.main();

Page 186: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

186

void A() {

}void B() {

}

void main() { A(); B(); C();}

void C() {

}

Incremental refinement stepsIncremental refinement steps

A

B

C

Starting with a functional model, make each part more Starting with a functional model, make each part more detaileddetailed A1, B1, and C1 are refinement of A, B, and C respectivelyA1, B1, and C1 are refinement of A, B, and C respectively

void A1() {

}void B1() {

}

void main() { A1(); B1(); C1();}

void C1() {

}

A1

B1

C1

Page 187: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

187

Incremental refinement stepsIncremental refinement steps

A1 B1

void A1() {

}void B1() {

}

void main() { par{ A1.main(); B1.main(); } C1.main();}

void C1() {

}

C1

Change of control structuresChange of control structures IF-THEN-ELSEIF-THEN-ELSE Sequential to parallelSequential to parallel

void A1() {

}void B1() {

}

void main() { A1(); B1(); C1();}

void C1() {

}

A1

B1

C1

notify wait

Page 188: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

188

Incremental refinement stepsIncremental refinement steps

A2 B2

void A1() {

}void B1() {

}

void main() { par{ A1.main(); B1.main(); } C1.main();}

void C1() {

}

C2

Again make each part more detailedAgain make each part more detailed A2, B2, and C2 are refinement of A1, B1, and C1 A2, B2, and C2 are refinement of A1, B1, and C1

respectivelyrespectively

A1 B1

void A1() {

}void B1() {

}

void main() { par{ A1.main(); B1.main(); } C1.main();}

void C1() {

}

C1

notify wait

notify wait

Page 189: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

189Equivalence checking of two Equivalence checking of two descriptions with same controldescriptions with same control

A1 B1

void A1() {

}void B1() {

}

void main() { par{ A1.main(); B1.main(); } C1.main();}

void C1() {

}

C1

If A and A1, B and B1, C and C1 are equivalent, then entire If A and A1, B and B1, C and C1 are equivalent, then entire descriptions are equivalentdescriptions are equivalent Comparison of two “similar” descriptionsComparison of two “similar” descriptions

A B

void A() {

}void B() {

}

void main() { par{ A.main(); B.main(); } C.main();}

void C() {

}

C

notify wait

notify wait

Page 190: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

190

void A() {

}void B() {

}

void main() { A(); B(); C();}

void C() {

}

Equivalence checking between Equivalence checking between sequential and parallel versionssequential and parallel versions

A

A B

B

C

void A() {

}void B() {

}

void main() { par{ A.main(); B.main(); } C.main();}

void C() {

}

C

Based on synchronization verification, prove equivalenceBased on synchronization verification, prove equivalence Extraction of synchronizationExtraction of synchronization and dependency analysis and dependency analysis

notify-wait pairare supposed to communicate !

notify wait

Page 191: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

191Symbolic simulation in higher-level Symbolic simulation in higher-level designsdesigns

Symbolic execution of designsSymbolic execution of designs All variables and operations are expressed All variables and operations are expressed

as symbolsas symbols Expressions among them are also symbolsExpressions among them are also symbols

Efficient simulation for all possible input Efficient simulation for all possible input patternspatterns A symbol expression (a + b) requires many A symbol expression (a + b) requires many

patterns in conventional Boolean level patterns in conventional Boolean level symbolic simulationsymbolic simulation 256 * 256 patterns when a, b are 8-bit variables256 * 256 patterns when a, b are 8-bit variables

Page 192: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

192

a = v1;b = v2;add1 = a + b;

Description 1

add2 = v1 + v2;

Description 2

EqvClass

Symbolic simulation

We are going to check the equivalencebetween add1 and add2

Symbolic simulation exampleSymbolic simulation example

Example of equivalence checking based on Example of equivalence checking based on symbolic simulationsymbolic simulation Checking (add1 == add2) , when v1, v2 are Checking (add1 == add2) , when v1, v2 are

equivalent in both designsequivalent in both designs Equivalent variables are collected intoEquivalent variables are collected into EqvClassEqvClass

Page 193: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

193

a = v1;b = v2;add1 = a + b;

Description 1

add2 = v1 + v2;

Description 2

EqvClass

Symbolic simulation

E1 (a, v1)E2 (b, v2)E3 (add1, a+b)

Description1 is simulated

Symbolic simulation exampleSymbolic simulation example

Example of equivalence checking based on Example of equivalence checking based on symbolic simulationsymbolic simulation Checking (add1 == add2) , when v1, v2 are Checking (add1 == add2) , when v1, v2 are

equivalent in both designsequivalent in both designs Equivalent variables are collected into EqvClassEquivalent variables are collected into EqvClass

Page 194: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

194

a = v1;b = v2;add1 = a + b;

Description 1

add2 = v1 + v2;

Description 2

EqvClass

Symbolic simulation

E1 (a, v1)E2 (b, v2)E3 (add1, a+b)E4 (add2, v1+v2)

Description2 is simulated

Example of equivalence checking based on Example of equivalence checking based on symbolic simulationsymbolic simulation Checking (add1 == add2) , when v1, v2 are Checking (add1 == add2) , when v1, v2 are

equivalent in both designsequivalent in both designs Equivalent variables are collected into EqvClassEquivalent variables are collected into EqvClass

Symbolic simulation exampleSymbolic simulation example

Page 195: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

195

a = v1;b = v2;add1 = a + b;

Description 1

add2 = v1 + v2;

Description 2

EqvClass

Symbolic simulation

E1 (a, v1)E2 (b, v2)E3 (add1, a+b)E4 (add2, v1+v2)

Due to the equivalencesin E1, E2

Example of equivalence checking based on Example of equivalence checking based on symbolic simulationsymbolic simulation Checking (add1 == add2) , when v1, v2 are Checking (add1 == add2) , when v1, v2 are

equivalent in both designsequivalent in both designs Equivalent variables are collected into EqvClassEquivalent variables are collected into EqvClass

Symbolic simulation exampleSymbolic simulation example

Page 196: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

196

a = v1;b = v2;add1 = a + b;

Description 1

add2 = v1 + v2;

Description 2

EqvClass

Symbolic simulation

E1 (a, v1)E2 (b, v2)E3’ (add1, a+b, add2, v1+v2)

E3 & E4 are mergedinto E3’

Symbolic simulation exampleSymbolic simulation example

Example of equivalence checking based on Example of equivalence checking based on symbolic simulationsymbolic simulation Checking (add1 == add2) , when v1, v2 are Checking (add1 == add2) , when v1, v2 are

equivalent in both designsequivalent in both designs Equivalent variables are collected into EqvClassEquivalent variables are collected into EqvClass

Page 197: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

197

Program slicing for SpecC/C++Program slicing for SpecC/C++

Program slicingProgram slicing Can extract a portion of a program based on Can extract a portion of a program based on

dependence analysisdependence analysis Can be applied to formal methods, since it can Can be applied to formal methods, since it can

reduce problems to be analyzedreduce problems to be analyzed Two types of slicingTwo types of slicing

Backward slicing … extracting the portion that can Backward slicing … extracting the portion that can affect a variable at a certain line of codesaffect a variable at a certain line of codes

Forward slicing … extracting the portion that can be Forward slicing … extracting the portion that can be affected by a variable at a certain line of codesaffected by a variable at a certain line of codes

Based on C/C++ slicer, SpecC/SystemC/VHDL Based on C/C++ slicer, SpecC/SystemC/VHDL slicer can be developed [Shankar et al.]slicer can be developed [Shankar et al.] Since they are similar to C/C++, a little bit of Since they are similar to C/C++, a little bit of

extension is sufficientextension is sufficient

Page 198: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

198

Backward slicing for a variable Backward slicing for a variable vv extracts all extracts all codes that affect the variable codes that affect the variable vv

a = 2;

b = 3;

c = 5;

a = a + 10;

b = a * c; /start/

c = c + a;

a = a * b;

a = 2;

b = 3;

c = 5;

a = a + 10;

b = a * c; /start/

c = c + a;

a = a * b;

Backward slicing

Backward slicingBackward slicing

Page 199: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

199

Forward slicing for a variable Forward slicing for a variable v v extracts all extracts all codes that are affected by the variable codes that are affected by the variable vv

a = 2;

b = 3;

c = 5;

a = a + 10;

b = a * c; /start/

c = c + a;

a = a * b;

Forward slicinga = 2;

b = 3;

c = 5;

a = a + 10;

b = a * c; /start/

c = c + a;

a = a * b;

Forward slicingForward slicing

Page 200: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

200Example : Interprocedural slicing Example : Interprocedural slicing with summary edgewith summary edge

int sq(int x){ return(x*x);}void main(void){ int a,b,c,d; a=1; b=sq(a); c=3; d=sq(c); write(d);}

Source code Dependence graph

a=1

b=sq$result

call sq()

write(d)

sq()

main()

ControlDependence

DataDependence

F_In x

x*x

F_Outsq$result

c=1

d=sq$result

call sq()

A_In x

A_Outsq$result

A_In x

A_Outsq$result

SummaryEdge

param in/ out

Call Edge

Page 201: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

201Example : Interprocedural slicing Example : Interprocedural slicing with summary edgewith summary edge

Source code Dependence graph

a=1

b=sq$result

call sq()

write(d)

sq()

main()

ControlDependence

DataDependence

F_In x

x*x

F_Outsq$result

c=1

d=sq$result

call sq()

A_In x

A_Outsq$result

A_In x

A_Outsq$result

SummaryEdge

param in/ out

Call Edge

1st stageint sq(int x){ return(x*x);}void main(void){ int a,b,c,d; a=1; b=sq(a); c=3; d=sq(c); write(d);}

Page 202: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

202Example : Interprocedural slicing Example : Interprocedural slicing with summary edgewith summary edge

Source code Dependence graph

a=1

b=sq$result

call sq()

write(d)

sq()

main()

ControlDependence

DataDependence

F_In x

x*x

F_Outsq$result

c=1

d=sq$result

call sq()

A_In x

A_Outsq$result

A_In x

A_Outsq$result

SummaryEdge

param in/ out

Call Edge

int sq(int x){ return(x*x);}void main(void){ int a,b,c,d; a=1; b=sq(a); c=3; d=sq(c); write(d);}

2nd stage

Dependence graph gives all dependency Dependence graph gives all dependency informations on the programs and is used hereinformations on the programs and is used here

Page 203: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

203Equivalence checking of C descriptions Equivalence checking of C descriptions based on symbolic simulationbased on symbolic simulation

ProblemProblem Symbolic simulation of a whole design takes Symbolic simulation of a whole design takes

a very long time, when the design is largea very long time, when the design is large Computational efforts exponentially increase with Computational efforts exponentially increase with

the numbers of conditional branchesthe numbers of conditional branches

SolutionSolution Reducing areas to be simulated symbolicallyReducing areas to be simulated symbolically Based on difference between descriptionsBased on difference between descriptions See the following slide for intuitive explanationSee the following slide for intuitive explanation

Textual differences may become a good hint Textual differences may become a good hint to identify which portions of programs are to identify which portions of programs are differentdifferent

Page 204: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

204

Efficient equivalence checking in SpecC/C++Efficient equivalence checking in SpecC/C++

Comparison of two similar design descriptionsComparison of two similar design descriptions Extract textual differencesExtract textual differences Dependence analysis by program slicing type Dependence analysis by program slicing type

techniquestechniques Symbolically simulate the real difference and analyze Symbolically simulate the real difference and analyze

the resultsthe results

Description1 Description2

return a; return a; return a; return a;

: textual differences

Description1 Description2

Page 205: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

205

Verification flowVerification flow

Desc. 1Desc. 1 Desc. 2Desc. 2

Identification of the Textual DifferencesIdentification of the Textual Differences & Extracting Functions to be Checked & Extracting Functions to be Checked

Symbolic SimulationSymbolic Simulation

Definition of Input/Output VariablesDefinition of Input/Output Variablesand Program Slicingand Program Slicing

Report of ResultsReport of Results

A Naïve way is to simulate both A Naïve way is to simulate both descriptions separately. descriptions separately. Following slide introduces a Following slide introduces a more efficient simulation methodmore efficient simulation method

Page 206: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

206

More efficient simulation methodMore efficient simulation method

A lot of A lot of internalinternal equivalence checking are equivalence checking are carried out during verificationcarried out during verification Most of them do not directly contribute to Most of them do not directly contribute to

prove output equivalenceprove output equivalence More efficient simulation methodMore efficient simulation method

Do not simulate the descriptions separatelyDo not simulate the descriptions separately Both descriptions are simulated in parallelBoth descriptions are simulated in parallel

Utilizing textual correspondenceUtilizing textual correspondence Only checking equivalence of corresponding Only checking equivalence of corresponding

statementsstatements Utilizing textual differenceUtilizing textual difference Equivalence checking can be skipped if two Equivalence checking can be skipped if two

statements are obviously equivalentstatements are obviously equivalent

Page 207: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

207

An example of verificationAn example of verification

11stst line: textually different line: textually different Create 2 EqvClasses separatelyCreate 2 EqvClasses separately

E1 (a_1, 3 * in2_1)E1 (a_1, 3 * in2_1)E2 (a_2, in1_2 * in2_2)E2 (a_2, in1_2 * in2_2)

Check their equivalence … nonequivalentCheck their equivalence … nonequivalent Identify the statements affected by a_1 or a_2Identify the statements affected by a_1 or a_2

55thth line is identified line is identified

a_2 = in1_2 * in2_2;b_2 = 360 + in1_2;c_2 = 2408 * (in1_2 + in2_2);d_2 = c_2 – 4017 * b_2;e_2 = 1108 * (a_2 + b_2);out_2 = (d_2 + e_2) >> 8;

a_1 = 3 * in2_1;b_1 = 360 + in1_1;c_1 = 2408 * (in1_1 + in2_1);d_1 = c_1 – 4017 * b_1;e_1 = 1108 * (a_1 + b_1);out_1 = (d_1 + e_1) >> 8;

DEEEEE

Note:Note: Input: in1, in2 Input: in1, in2 Output: out Output: out

Page 208: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

208

An example of verificationAn example of verification

22ndnd, 3, 3rdrd, 4, 4thth line: textually equivalent and not line: textually equivalent and not affected by nonequivalent variablesaffected by nonequivalent variables These pairs are clearly equivalent These pairs are clearly equivalent can skip can skip

checkingchecking Simply create an EqvClass for each pairSimply create an EqvClass for each pair

E3 (b_1, b_2, 360 + in1_1, 360 + in1_2)E3 (b_1, b_2, 360 + in1_1, 360 + in1_2)E4 (c_1, c_2, 2408 * (in1_1 + in2_1),E4 (c_1, c_2, 2408 * (in1_1 + in2_1), 2408 * (in2_1 + in2_2)) 2408 * (in2_1 + in2_2))E5 (d_1, d_2, c_1 – 4017 * b_1, c_2 – 4017 * b_2)E5 (d_1, d_2, c_1 – 4017 * b_1, c_2 – 4017 * b_2)

a_2 = in1_2 * in2_2;b_2 = 360 + in1_2;c_2 = 2408 * (in1_2 + in2_2);d_2 = c_2 – 4017 * b_2;e_2 = 1108 * (a_2 + b_2);out_2 = (d_2 + e_2) >> 8;

a_1 = 3 * in2_1;b_1 = 360 + in1_1;c_1 = 2408 * (in1_1 + in2_1);d_1 = c_1 – 4017 * b_1;e_1 = 1108 * (a_1 + b_1);out_1 = (d_1 + e_1) >> 8;

DEEEEE

Page 209: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

209

An example of verificationAn example of verification

55thth line: affected by nonequivalent variable a_1 line: affected by nonequivalent variable a_1 and a_2and a_2 Create 2 EqvClasses separatelyCreate 2 EqvClasses separately

E6 (e_1, 1108 * (a_1 + b_1))E6 (e_1, 1108 * (a_1 + b_1))E7 (e_2, 1108 * (a_2 + b_2))E7 (e_2, 1108 * (a_2 + b_2))

Check their equivalence … nonequivalentCheck their equivalence … nonequivalent Identify the statements affected by e_1 or e_2Identify the statements affected by e_1 or e_2

66thth line is identified line is identified

a_2 = in1_2 * in2_2;b_2 = 360 + in1_2;c_2 = 2408 * (in1_2 + in2_2);d_2 = c_2 – 4017 * b_2;e_2 = 1108 * (a_2 + b_2);out_2 = (d_2 + e_2) >> 8;

a_1 = 3 * in2_1;b_1 = 360 + in1_1;c_1 = 2408 * (in1_1 + in2_1);d_1 = c_1 – 4017 * b_1;e_1 = 1108 * (a_1 + b_1);out_1 = (d_1 + e_1) >> 8;

DEEEEE

Page 210: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

210

An example of verificationAn example of verification

66thth line: textually equivalent, but affected by line: textually equivalent, but affected by nonequivalent variables e_1 and e_2nonequivalent variables e_1 and e_2 Create 2 EqvClasses separatelyCreate 2 EqvClasses separately

E8 (out_1, (d_1 + e_1) >> 8)E8 (out_1, (d_1 + e_1) >> 8)E9 (out_2, (d_2 + e_2) >> 8)E9 (out_2, (d_2 + e_2) >> 8)

Check their equivalence … nonequivalentCheck their equivalence … nonequivalent Terminate with the results “nonequivalent”Terminate with the results “nonequivalent”

a_2 = in1_2 * in2_2;b_2 = 360 + in1_2;c_2 = 2408 * (in1_2 + in2_2);d_2 = c_2 – 4017 * b_2;e_2 = 1108 * (a_2 + b_2);out_2 = (d_2 + e_2) >> 8;

a_1 = 3 * in2_1;b_1 = 360 + in1_1;c_1 = 2408 * (in1_1 + in2_1);d_1 = c_1 – 4017 * b_1;e_1 = 1108 * (a_1 + b_1);out_1 = (d_1 + e_1) >> 8;

DEEEEE

Page 211: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

211

Experiments (MPEG4)Experiments (MPEG4)

Optimization of IDCT functions (idct_row Optimization of IDCT functions (idct_row & idct_col) in MPEG4& idct_col) in MPEG4 SizesSizes Whole MPEG4 program … more than 17k linesWhole MPEG4 program … more than 17k lines Target IDCT functions … about 50 linesTarget IDCT functions … about 50 lines

NoteNote 9 lines are different between descriptions (of 9 lines are different between descriptions (of

each function)each function) Each function has 8 conditional branches (i.e. 256 Each function has 8 conditional branches (i.e. 256

execution paths have to be proved)execution paths have to be proved) functions were unrolled 8 times functions were unrolled 8 times

Page 212: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

212

Experiments (MPEG4)Experiments (MPEG4) An example of different parts (below)An example of different parts (below) ResultsResults Each pair of functions was proved to be Each pair of functions was proved to be

equivalentequivalent idct_row … 680 secidct_row … 680 sec idct_col … 2190 secidct_col … 2190 sec

x8 = W3 * (x6 + x7);x6 = x8 – (W3 – W5) * x6;x7 = x8 – (W3 + W5) * x7;x8 = x0 + x1;

tmp = x6;x6 = W3 * x7 + W5 * tmp;x7 = W3 * tmp – W5 * x7;x8 = x0 + x1;

Description 1 Desciption 2Optimization

Page 213: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

213

Experiments (AES)Experiments (AES)

Changes in AES (American Encryption Changes in AES (American Encryption Standard)Standard) Target: Encryption function in RijndaelTarget: Encryption function in Rijndael

Rijndael is an implementation of AESRijndael is an implementation of AES Size: 120 linesSize: 120 lines Case 1 (equivalent changes)Case 1 (equivalent changes)

4 different parts were inserted4 different parts were inserted Result … equivalent, Verification time … 6 secResult … equivalent, Verification time … 6 sec

Case 2 (not equivalent changes)Case 2 (not equivalent changes) 8 different parts were inserted8 different parts were inserted Result … not equivalent, Verification time … 344 secResult … not equivalent, Verification time … 344 sec

Case 2 took longer time because many statements Case 2 took longer time because many statements were affected by nonequivalent variableswere affected by nonequivalent variables

Page 214: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

214

Synchronization verification: OverviewSynchronization verification: Overview

In system-level design…In system-level design… Communication among parallel processes is Communication among parallel processes is

necessarynecessary To operate properly, those parallel processes must To operate properly, those parallel processes must

be correctly scheduled/synchronizedbe correctly scheduled/synchronized

Synchronization verificationSynchronization verification Guarantee the order of execution of statements as Guarantee the order of execution of statements as

designers’ intendeddesigners’ intended Problem size can be significantly reduced (focus on Problem size can be significantly reduced (focus on

some, not all, parts of the design)some, not all, parts of the design) More confident when “SV” and “property checking” More confident when “SV” and “property checking”

than “property checking” alonethan “property checking” alone

Page 215: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

215

void A() {

}void B() {

}

void main() { A(); B(); C();}

void C() {

}

Par statement in SpecCPar statement in SpecC

A

A B

C Language SpecC Language

B

C

void A() {

}void B() {

}

void main() { par{ A.main(); B.main(); } C.main();}

void C() {

}

C

Page 216: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

216

Synchronization in SpecCSynchronization in SpecC

Add notify/wait of event e for sync.Add notify/wait of event e for sync. ‘‘wait’ will stop process until it is ‘notify’ wait’ will stop process until it is ‘notify’

A B

void A() {

}void B() {

}

void main() { par { A.main(); B.main(); }}

notify e1;wait e2;

wait e1;notify e2; wait e1

Process B stopsand wait untile1 is notified

notify e1

B resumeswait e2

Process A stopsand wait untile2 is notified

notify e2

A resumes

Page 217: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

217

main() { par{ a.main(); b.main(); }} behavior a { main() { x=10; /*st1*/ y=x+10; /*st2*/ }} behavior b { main() { x=20; /*st3*/ }}

time

a.main()

b.main()

St1 St2

St3

Tas T1s T1e T2s T2e Tae

Tbs T3s T3e Tbe

main() { par{ a.main(); b.main(); }} behavior a { main() { x=10; /*st1*/ y=x+10; /*st2*/ notify e; /*New*/}} behavior b { main() { wait e; /*New*/ x=20; /*st3*/ }}

time

a.main()

b.main()

St1 St2

St3

Tas T1s T1e T2s T2e Tae

Tbs T3s T3e Tbe

Synchronization by Notify/wait

Synchronization in SpecCSynchronization in SpecC

Ambiguous results on y causing from x = 10; /*st1*/x = 20; /*st3*/

y = 20 (always)

Page 218: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

218

Synchronization in SpecC (cont.)Synchronization in SpecC (cont.) main() { par{ a.main(); b.main(); }} behavior a { main() { x=10; /*st1*/ y=x+10; /*st2*/ notify e; /*New*/}} behavior b { main() { wait e; /*New*/ x=20; /*st3*/ }}

time

a.main()

b.main()

St1 St2

St3

Tas T1s T1e T2s T2e Tae

Tbs T3s T3e Tbe

Synchronization by Notify/wait

y = 20 (always)

Tas=Tbs, Tae=TbeTas=Tbs, Tae=Tbe Tas<=T1s<T1e<=T2s<T2e<=TasTas<=T1s<T1e<=T2s<T2e<=Tas Tbs<=T3s<T3e<=TbeTbs<=T3s<T3e<=Tbe T2e<=T3sT2e<=T3s

Page 219: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

219Synchronization verification for two Synchronization verification for two concurrent processes (1)concurrent processes (1) Check if wait/notify can acutually Check if wait/notify can acutually

communicate in while loopscommunicate in while loops (or nested loops)(or nested loops) First approach: Delete while loopFirst approach: Delete while loop

In each iteration notify/wait must communicateIn each iteration notify/wait must communicate

while (1) { while (1) {

} }

notify e1

notify e2

wait e1

wait e2

if stmntswitch stmnt

if stmntswitch stmnt

while (1) { while (1) {

} }

notify e1

notify e2

wait e1

wait e2

if stmntswitch stmnt

if stmntswitch stmnt

Page 220: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

220Synchronization verification for two Synchronization verification for two concurrent processes (2)concurrent processes (2)

Unfold by N and M timesUnfold by N and M times N is 1 to n, M is 1 to m, any combinationsN is 1 to n, M is 1 to m, any combinations

while (1) { while (1) {

} }

notify e1

notify e2

wait e1

wait e2

if stmntswitch stmnt

if stmntswitch stmnt

while (1) {

}

notify e1

wait e2

if stmntswitch stmnt

while (1) {

}

notify e2

wait e1

if stmntswitch stmnt

while (1) {

}

notify e2

wait e1

if stmntswitch stmnt

while (1) {

}

notify e2

wait e1

if stmntswitch stmnt

while (1) {

}

notify e1

wait e2

if stmntswitch stmnt

Page 221: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

221Synchronization verification for two Synchronization verification for two concurrent processes (3)concurrent processes (3)

WhileWhile loops are converted into FSM (nested loops are converted into FSM (nested loops can be treated in the same way)loops can be treated in the same way) Basically need regular model checkingBasically need regular model checking

while (1) { while (1) {

} }

notify e1

notify e2

wait e1

wait e2

if stmntswitch stmnt

if stmntswitch stmnt

notify e1

notify e2

wait e1

wait e2

switch stmnt

if stmnt

if stmnt

switch stmnt

Page 222: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

222

Example(1)Example(1)

Par Par behavior1 {notify e1; a; wait e2; b}behavior1 {notify e1; a; wait e2; b}

Behavior2 {wait e1; c; notify e2; d}Behavior2 {wait e1; c; notify e2; d} e1 < a, a < e2, e2 < b, e1 < c, c < e2, e2 < de1 < a, a < e2, e2 < b, e1 < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ?a, b, c, d, e1, e2 > 0 are satisfied ? → Yes, so the → Yes, so the

description is correctdescription is correct

Par Par behavior1 {wait e2; a; notify e1; b}behavior1 {wait e2; a; notify e1; b}

Behavior2 {wait e1; c; notify e2; d}Behavior2 {wait e1; c; notify e2; d} e2 < a, a < e1, e1e2 < a, a < e1, e1 < b, e1 < c, c < e2, e2 < d< b, e1 < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ? → No, since a < c a, b, c, d, e1, e2 > 0 are satisfied ? → No, since a < c

and c < a. This means a deadlock !and c < a. This means a deadlock !

notify e1 a wait e2 b

wait e1 c notify e2 d

wait e2 a notify e1 b

wait e1 c notify e2 d

Page 223: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

223

Example(2)Example(2)

Par Par behavior1 {notify e1; a; waitfor(10); wait e2; b}behavior1 {notify e1; a; waitfor(10); wait e2; b}Behavior2 {wait e1; waitfor(10); c; notify e2; d}Behavior2 {wait e1; waitfor(10); c; notify e2; d} e1 < a, a + 10 < e2, e2 < b, e1 + 10 < c, c < e2, e2 < de1 < a, a + 10 < e2, e2 < b, e1 + 10 < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ? → Yes, the design is correcta, b, c, d, e1, e2 > 0 are satisfied ? → Yes, the design is correct Moreover, b<c is satisfied ? → No, the result says c<bMoreover, b<c is satisfied ? → No, the result says c<b

Par Par behavior1 {notify e1; a; wait e2; waitfor(10); b}behavior1 {notify e1; a; wait e2; waitfor(10); b}Behavior2 {wait e1; waitfor(10); c; notify e2; d}Behavior2 {wait e1; waitfor(10); c; notify e2; d} e1 < a, a < e2, e2 + 10 < b, e1 + 10 < c, c < e2, e2 < de1 < a, a < e2, e2 + 10 < b, e1 + 10 < c, c < e2, e2 < d a, b, c, d, e1, e2 > 0 are satisfied ? → Yes, the design is correcta, b, c, d, e1, e2 > 0 are satisfied ? → Yes, the design is correct Moreover, b – e1 < 20 is satisfied ? → No, this is not satisfied Moreover, b – e1 < 20 is satisfied ? → No, this is not satisfied

notify e1 a wait e2 b

wait e1 c notify e2 d

 w aitfor(10)

 w aitfor(10)

notify e1 a wait e2 b

wait e1 c notify e2 d

 w aitfor(10)

 w aitfor(10)

Page 224: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

224

Verification flowsVerification flows Goals:Goals:

Check whether given SpecC codes (with Check whether given SpecC codes (with ‘par’, ‘notify/wait’) are properly synchronized‘par’, ‘notify/wait’) are properly synchronized

If checking fails, counter-examples should If checking fails, counter-examples should be generated (trace to source of errors)be generated (trace to source of errors)

Based on:Based on: Boolean SpecC, a little theorem prover, Boolean SpecC, a little theorem prover,

SVC/CVC, Program Slicing, ... SVC/CVC, Program Slicing, ...

Page 225: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

225

Verification FlowsVerification Flows

behavior A(out event e, inout int x, inout int y) { void main(){ if (x > 1) { notify e; y = x - 1; } if (y > 3) { . .

SpecC

Verifywith a theorem

prover

Correct

Error-trace

Boolean SpecCbehavior A() { void main(){ if (C0) { notify e ... } if (C1) { . .

Refining

Abstraction refinement

Abstraction

Page 226: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

226

Boolean ProgramBoolean Program

Proposed by Ball and Rajamani under Proposed by Ball and Rajamani under SLAM project at Microsoft ResearchSLAM project at Microsoft Research

Think of SW like a model (like FSM in Think of SW like a model (like FSM in HW) and verify it by first abstracting HW) and verify it by first abstracting away unnecessary statements with user-away unnecessary statements with user-defined predicatesdefined predicates

BP abstracts the original program:BP abstracts the original program:

if properties on BP hold, so as original if properties on BP hold, so as original oneone

Page 227: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

227

Our Boolean SpecCOur Boolean SpecC is a subset of original SpecC programis a subset of original SpecC program ‘‘if-else’ conditions are replaced by if-else’ conditions are replaced by

propositional vars. e.g. if(x<y) -> if(c0)propositional vars. e.g. if(x<y) -> if(c0) Statements other than ‘notify/wait’ and Statements other than ‘notify/wait’ and

‘if’, (ones that don’t effect the sync.) are ‘if’, (ones that don’t effect the sync.) are abstracted away (abstract unnecessary abstracted away (abstract unnecessary info.) info.)

Only for verification of synchronizationOnly for verification of synchronization

Page 228: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

228

Abstraction refinementAbstraction refinement

behavior A(out event e, inout int x, inout int y) { void main(){ if (x > 1) { notify e; y = x - 1; } if (y > 3) { . .

SpecC

Verifywith a theorem

prover

Correct

Error-trace

Boolean SpecCbehavior A() { void main(){ if (C0) { notify e ... } if (C1) { . .

Abstraction refinement

Abstraction

Entry barber

while numCustomer chairOccupied call

if numCustomer = 0

DayDreaming

if numCustomer != 0

if chairOccupied = T if chairOccupied = F

KeepCutting chairOccupied = F notify call chairOccupied = T

Constructing Control Flow Graph (CFG)

Check validitySymbolic sim

& theorem prover

Find & ModifyPredicates

Refining

Page 229: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

229

Abstraction refinementAbstraction refinement

1.1. SpecC => boolean SpecC & build SpecC => boolean SpecC & build Control Flow Graph (CFG)Control Flow Graph (CFG)

2.2. Verify with theorem provers. If result is Verify with theorem provers. If result is satisfied, terminate, else go to next stepsatisfied, terminate, else go to next step

3.3. Use CFG to find related path and Use CFG to find related path and symbolically simulate along the pathsymbolically simulate along the path

Use theorem provers on the validity of the pathUse theorem provers on the validity of the path If not a feasible path, analyze and generate If not a feasible path, analyze and generate

conditions on Boolean program variables using conditions on Boolean program variables using SpecC program slicingSpecC program slicing

4.4. Use those conditions and modify boolean Use those conditions and modify boolean SpecCSpecC

5.5. Go to 2Go to 2

Page 230: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

230

Example: Sleeping barber problemExample: Sleeping barber problem

if no-customer

Day dreaming Cutting

if finish cut

T F

T

‘Call’ next customer

F

Customer leave

if no-customer

Go back Enter barber

F T

Sit & had a hair cut

Leave

Wait for ‘Call’

barber customer

par statement

barbercustomerempty chair

barber chair

• barber: finished cutting->call customer• barber: no customer->wait• customer: barber wait->has hair cut• customer: chairs occupied->come again• customer: a chair empty->wait

Page 231: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

231

ExampleExample

behavior barber (inout event call, inout bool chairOccupied,

inout bool waitCustomer) {

void main() {

while(1) {

if (waitCustomer == false)

DayDreaming();

else {

if (chairOccupied == true) {

KeepCutting();

chairOccupied = false;

}

else {

notify call;

chairOccupied = true;

};

behavior customer (inout event call, inout bool chairOccupied,

inout bool waitCustomer) {

void main() {

while(1) {

if (waitCustomer == false)

waitCustomer = true;

else {

waitCustomer = false

if (chairOccupied == false)

wait call;

}

}

}

};

behavior Main () {

void main() {

par {

barber.main();

customer.main();

}

}

};

Page 232: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

232

/* Barber */

void main() {

while(1) {

if (!waitCustomer)

DayDreaming(); (A1)

else {

if (chairOccupied) {

KeepCutting(); (A2)

chairOccupied = false; (A3)

}

else {

notify call; (A4)

chairOccupied = true; (A5)

}

};

/* Customer */

void main() {

while(1) {

if (!waitCustomer)

waitCustomer = true; (B1)

else {

waitCustomer = false; (B2)

if (!chairOccupied)

wait call; (B3)

}

};

/* Barber */

void main() {

while(a0) {

if (a1)

...

else {

if (a2) {

...

...

}

else {

notify call;

...

}

};

/* Customer */

void main() {

while(b0) {

if (b1)

...

else {

...

if (b2)

wait call;

}

};

Construct model + Verify

Property to be verified:‘notify’ is not reached,‘wait’ is reached, then Synchronization error!

A4 is not reached

and B3 is reached

Error!!! (Deadlock)

Abstract

Page 233: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

233a1

waitCustomer==false

a2

chairOccupied==true

/* Barber */

void main() {

while(1) {

if (!waitCustomer)

DayDreaming();

else {

if (chairOccupied) {

KeepCutting();

chairOccupied = false;

}

else {

notify call;

chairOccupied = true;

}

};

/* Customer */

void main() {

while(1) {

if (!waitCustomer)

waitCustomer = true;

else {

waitCustomer = false;

if (!chairOccupied)

wait call;

}

};

/* Barber */

void main() {

while(1) {

if (a1)

...

else {

if (a2) {

...

...

}

else {

notify call;

...

}

};

/* Customer */

void main() {

while(1) {

if (b1)

...

else {

...

if (b2)

wait call;

}

};

/* Barber */

void main() {

while(1) {

if (a1)

...

else {

if (a2) {

...

!a2

}

else {

notify call;

a2

}

};

/* Customer */

void main() {

while(1) {

if (b1)

...

else {

...

if (!a2)

wait call;

}

};

/* Barber */

void main() {

while(1) {

if (a1)

...

else {

if (a2) {

...

!a2

}

else {

notify call;

a2

}

};

/* Customer */

void main() {

while(1) {

if (a1)

!a1

else {

a1

if (!a2)

wait call;

}

};

Page 234: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

234Evaluation of the synchronization Evaluation of the synchronization verification methods(1)verification methods(1)

We injected ‘wait’ statements into the We injected ‘wait’ statements into the original SpecC descriptions (to cause original SpecC descriptions (to cause deadlock, and verify it)deadlock, and verify it)

Focusing only synchronization Focusing only synchronization (notify/wait under par{ }), problem size (notify/wait under par{ }), problem size can be significantly reducedcan be significantly reduced

Running on Linux machine, P3 1.1GHz & Running on Linux machine, P3 1.1GHz & 2GB RAM, deadlock can be detected 2GB RAM, deadlock can be detected within few minuteswithin few minutes

Page 235: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

235

Loops that create numbers of ‘notify/wait’ have Loops that create numbers of ‘notify/wait’ have to be unwound to get the equal numbers of to be unwound to get the equal numbers of notify and wait (analysis on loops of notify and wait (analysis on loops of ‘notify/wait’ can be considered as another ‘notify/wait’ can be considered as another interesting research topic)interesting research topic)

behavior gen_clk16() { void main() { while(1) { waitfor(10); notify(clk16); } }};

behavior tx_clk() { void main() { while(1) { for(i = 0; i < 16; i++) wait(clk16); notify(bit_event); } }};

This loop creates infinite numbers of notify(clk16)This loop creates infinite numbers of wait(clk16)With multiple of 16 ‘wait(clk16)’ each time

How to deal with loops ?How to deal with loops ?

Page 236: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

236

Experimental resultsExperimental results

FIFO exampleFIFO example ~260 lines~260 lines 3 behaviors and 2 interfaces3 behaviors and 2 interfaces

Point-to-point protocolPoint-to-point protocol ~850 lines~850 lines 5 behaviors have sync. semantic, 12 behaviors total5 behaviors have sync. semantic, 12 behaviors total

Elevator control systemElevator control system ~2000 lines~2000 lines 3 behaviors have sync. semantic, 13 behaviors total3 behaviors have sync. semantic, 13 behaviors total

MPEG4MPEG4 ~48,000 lines~48,000 lines 3 behaviors have sync. semantic, XX behaviors total3 behaviors have sync. semantic, XX behaviors total

Page 237: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

237

Experimental resultsExperimental results

When consider only parallel behaviorsProblem size (# of lines) can be reduced

Properties: checking for deadlock

Original Sync. Ver. Property1 Property2 Property3

FIFO 260 240 3.83 3.89 3.85

Point- to-Point Protocol 850 500 12.34 12.42 13.2

Elevator Control System 2000 800 30.67 29.82 29.9

MPEG4 48000 800 27.79 27.66 28.11

# of lines Verification Time (seconds)

Page 238: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

238

C Bounded Model CheckingC Bounded Model Checking

CBMCCBMC Developed at CMU, 2003Developed at CMU, 2003 [1] Hardware Verification using ANSI-C Programs as a Reference[1] Hardware Verification using ANSI-C Programs as a Reference

(Proc. of ASPDAC’03)(Proc. of ASPDAC’03)

CharacteristicsCharacteristics Modeling … C program -> Bit vector equationModeling … C program -> Bit vector equation Specifying properties … inserting assertions in C Specifying properties … inserting assertions in C

programsprograms Verification … using SAT solverVerification … using SAT solver

C program

Bit Vector Equation

Modeling

Verification    using SAT solver

Result

Specifying properties

Page 239: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

239

What does CBMC do?What does CBMC do?

CBMC checks if or not C programs satisfy the CBMC checks if or not C programs satisfy the properties the user specifyproperties the user specify Input … C Program with assertions as propertiesInput … C Program with assertions as properties Output … Result (Success/Fail). If fails, a counter Output … Result (Success/Fail). If fails, a counter

example is reportedexample is reportedchar a, b;int c;if (a < b) c = b – a;else c = a – b;assert (c >= 0);

Success

char a, b;int c;if (a < b) c = b – a;else c = a – b;assert (c != 0);

FailCounter example (a = 39, b = 39)

Page 240: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

240

Bounded Model Checking (BMC)Bounded Model Checking (BMC)

A kind of Model Checking techniquesA kind of Model Checking techniques Checking whether the design satisfies the property Checking whether the design satisfies the property

up to certain finite numbers of execution cycles up to certain finite numbers of execution cycles (bound) on the system(bound) on the system

Correctness of the design is guaranteed only up to Correctness of the design is guaranteed only up to the boundthe bound

BMC is useful when the design is too large to BMC is useful when the design is too large to handle for other formal methodshandle for other formal methods BMC can detect many bugsBMC can detect many bugs although it only although it only

guarantees that there is no counter examples up to guarantees that there is no counter examples up to the bound number of execution cyclesthe bound number of execution cycles

Page 241: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

241

BMC for C ProgramsBMC for C Programs

What does “bound” mean in C program?What does “bound” mean in C program? In C programs, cycle is not explicitIn C programs, cycle is not explicit ““bound” means the number of loop unwindingbound” means the number of loop unwinding

Combinati-onal circuit

BMC in RTL (behavior ofonly 3 cycles are verified)

Combinati-onal circuit

Combinati-onal circuitInput Output Satisfies given

properties?

Loop Unwinding Loop Loop

BMC of a loop in C program

Loop

Page 242: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

242

Process of CBMCProcess of CBMC

);3(

;

;2)1!(

;

xassert

xelse

xxif

yxx

Given C program& properties

3:

):1?)1(((

)):2?)1(((

)(:

3

2213

112

001

xP

xxxx

xxx

yxxC

Modeling

Bit vector equation

Generating SAT formula

SAT solver(Chaff)

Result (success/fail)counter example

Page 243: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

243

Transforming ANSI-C (1)Transforming ANSI-C (1)

RenamingRenaming After renaming, each variable appears only once in After renaming, each variable appears only once in

the left hand side of assignmentsthe left hand side of assignments α is the number of assignments made to variable α is the number of assignments made to variable vv

vv

);3(

;

;2)1!(

;

xassert

xelse

xxif

yxx

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx

Page 244: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

244

RenamingRenaming

;; 001 yxxyxx x, y in right hand are not assigned yetx in left hand is assigned at the 1st time

)1!()1!( 1 xifxifThis x is equivalent tothe x after the 1st assignment

・・

;2;2 2 xxThis x is assigned at the 2nd time

);3(

;

;2)1!(

;

xassert

xelse

xxif

yxx

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx

Page 245: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

245

Transforming ANSI-C (2)Transforming ANSI-C (2)

Transformation into bit vector equationTransformation into bit vector equation Formula C describes the Constraint of the Formula C describes the Constraint of the

verificationverification Formula P describes the Property to be verifiedFormula P describes the Property to be verified Checking if or not “C -> P” is always trueChecking if or not “C -> P” is always true

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx

3:

):1?)1(((

)):2?)1(((

)(:

3

2213

112

001

xP

xxxx

xxx

yxxC

Page 246: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

246Formal definition of transformation from Formal definition of transformation from C into bit vector equationC into bit vector equation

C(p, g) and P(p, g)C(p, g) and P(p, g) C(p,g)C(p,g) computes the assignments computes the assignments P(p,g)P(p,g) computes the properties computes the properties p … program blockp … program block g … guard (condition that p is operated)g … guard (condition that p is operated)

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx

3:

):1?)1(((

)):2?)1(((

)(:

3

2213

112

001

xP

xxxx

xxx

yxxC

Page 247: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

247

Example of transformationExample of transformation

),'(),(),';( trueSCtrueSCtrueSSCC

If the program is a sequentialcomposition, C (p, g) is split byusing ∧ operator

※At the start of the program, “ guard” is always “true”

Apply this rule

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx S … assignment

S’ … conditional branch

Page 248: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

248

Example of transformationExample of transformation

If program is an assignment v = e,C (p, g) is generally described as

1:?:),( vegvgevC

),()(

),'(),(

001 trueICyxx

trueSCtrueSCC

Apply this rule

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx S … assignment

S’ … conditional branch

Page 249: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

249

S’ … conditional branch

Example of transformationExample of transformation

If program is a conditional branch if(c) I; else I’;,C (p, g) is generally described as

):1?)1(():2?)1(()(

)1,1()1,2()(

),'()(

2213112001

12312001

001

xxxxxxxyxx

xxxCxxCyxx

trueSCyxxC

Apply this rule

),(),(:),)(( cgICcgICgIelseIcifC

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx S … assignment

Page 250: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

250

Example of transformationExample of transformation

);3(

;1

;2)1!(

;

3

23

21

001

xassert

xxelse

xxif

yxx

Computation of P formula from assertions

aggaassertP :)),((

Assertion

Apply this rule

)3( 3 xP ※ In this case, guard is true

Page 251: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

251

Loop unwindingLoop unwinding

CBMC makes loops unwind finite timesCBMC makes loops unwind finite times Because “Bounded” Model CheckingBecause “Bounded” Model Checking

Only the finite number of statements are verifiedOnly the finite number of statements are verified The number of unwinding can be determined by the userThe number of unwinding can be determined by the user

Unwinding processUnwinding process Do loop unwinding Do loop unwinding nn times by the following times by the following

transformationtransformation

The last while loop is replaced by The last while loop is replaced by assert(!e);assert(!e); (“(“unwinding assertionunwinding assertion”)”)

If “unwinding assertion” is satisfied, the number of If “unwinding assertion” is satisfied, the number of unwinding is sufficientunwinding is sufficient

while (e) inst; → if (e) { inst; while (e) inst; }

Page 252: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

252

Unwinding assertionUnwinding assertion

Original loop

while (e) inst;

Unwindingn times if (e) {

inst; if (e) { inst; if (e) { inst; assert(!e); } }}

Unwound loop

unwindingassertion

Verification

Is “unwindingassertion” violated?yes no

Need to unwindmore

Unwinding issufficient

Page 253: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

253

Removing pointersRemoving pointers

Pointer dereferences are removed in the Pointer dereferences are removed in the process of transformationprocess of transformation

Example.Example.

if (x) p = &a;else p = &b;*p =1;

x = true -> *p = ax = false -> *p = b

How do we remove pointers automatically?

Introducing the φ functionto analyze pointer dereferences

What does this pointer dereference?

Page 254: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

254Removing pointers by using the φ Removing pointers by using the φ functionfunction

DefinitionDefinition

e … sub-expression to be dereferencede … sub-expression to be dereferenced g … guard (condition that the dereference is g … guard (condition that the dereference is

operated)operated) o … offseto … offset

),,(][)0,,(* ogeoegee

;1*

;&

;&)(

p

bpelse

apxif

Renaming;1*

;&

;&)(

2

02

010

p

bpelse

apxif

00022 :?)......()0,,(* baxprocessesmanytruepp

Page 255: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

255

Verification with SAT SolverVerification with SAT Solver

Satisfiability Problem (SAT Problem)Satisfiability Problem (SAT Problem) Formula Formula FF is satisfiable if there is more than one is satisfiable if there is more than one

input pattern that makes input pattern that makes FF true true Ex. F1 = a b … satisfiable (when a = true, b = true)∧Ex. F1 = a b … satisfiable (when a = true, b = true)∧ Ex. F2 = a ∧Ex. F2 = a ∧ ¬¬ a … not satisfiablea … not satisfiable

3:

):1?)1((

):2?)1((

)(:

3

2201

3

112

001

xP

xxzx

x

xxx

yxxCIf (C -> P) is always true,¬( C -> P ) is not satisfiable

Verification with SAT solver(Chaff)Bit vector equation from

C program

Page 256: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

256

Checking over bound access to arrayChecking over bound access to array

CBMC can detect the over bound access to CBMC can detect the over bound access to array indicesarray indices This program is faulty since array[3] is accessed This program is faulty since array[3] is accessed

when i = 3when i = 3 If (i <= 3) is replaced by (i < 3), this program If (i <= 3) is replaced by (i < 3), this program

becomes correctbecomes correct

int exam () { int array[3], i, sum=0; for (i=0; i<=3; i++) { array[i] = input(); sum = sum + array[i];} return sum;}

This means the valueis input at this point

Page 257: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

257

Assertion checkingAssertion checking

CBMC can verify data-CBMC can verify data-dominant propertiesdominant properties <-> control-dominant <-> control-dominant

properties as “safety properties as “safety properties”properties”

int main () {unsigned char a, b;unsigned char ai, bi;unsigned int result = 0, i;

a = input;b = input;for (i = 0; i < 8; i++) { bi = (b>>i); ai = (a<<i); if ( bi & 1) result += ai;}assert (result == a * b);}

101 (a)× 1010 (b)

Suppose i=1

bi = 1ai = 10100

This corresponds tothe sub-product of(a) * (2nd digit of b)

Page 258: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

258

Using CBMC, the behavioral consistency of C Using CBMC, the behavioral consistency of C and Verilog programs can be checkedand Verilog programs can be checked

Some experimental results are reported below*Some experimental results are reported below* PS/2 interfacePS/2 interface

700 lines of Verilog, unwinding bound 48, run time 51 sec.700 lines of Verilog, unwinding bound 48, run time 51 sec. DLX processorDLX processor

Verilog design with 1219 latches, 550 lines of C, run time 97 Verilog design with 1219 latches, 550 lines of C, run time 97 sec., detected a counter example of length 5 cyclessec., detected a counter example of length 5 cycles

Experimental resultsExperimental results

Verilog C

Behavioral consistent?

*: Behavioral Consistency of C and VerilogUsing Bounded Model Checking (Proc. of DAC’03)

Page 259: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

259

Final remarks: Verification directionsFinal remarks: Verification directions

Driven by design flowDriven by design flow Higher levels of abstractionHigher levels of abstraction

Formal specification languagesFormal specification languages Mapping verification problems to lower level enginesMapping verification problems to lower level engines

Design reuseDesign reuse Interface verificationInterface verification System level verificationSystem level verification

Tackling larger designs in formal verificationTackling larger designs in formal verification Efficient formal enginesEfficient formal engines Sequential equivalence checkersSequential equivalence checkers Filter based techniquesFilter based techniques

Using multiple enginesUsing multiple engines Hybrid enginesHybrid engines

E.g. BDD/SAT/ATPG combinationE.g. BDD/SAT/ATPG combination Higher level reasoning Higher level reasoning

Need to automateNeed to automate

Page 260: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

260

Final remarks: Research issuesFinal remarks: Research issues Design and verification at high levels of abstractionDesign and verification at high levels of abstraction

New modeling issuesNew modeling issues Eg: what if Spec is in UMLEg: what if Spec is in UML

How to generate problem, map problemHow to generate problem, map problem

Faster enginesFaster engines More efficient BDDsMore efficient BDDs

Efficient and automatic abstraction-refinementEfficient and automatic abstraction-refinement Faster SAT solversFaster SAT solvers

Better learning and pruning techniquesBetter learning and pruning techniques Combining enginesCombining engines

ATPG/SAT combinationATPG/SAT combination BDD/SAT combinationBDD/SAT combination

Use of higher level information to guide searchUse of higher level information to guide search Methodology issuesMethodology issues

Interface specification and verificationInterface specification and verification Automatic static checks Automatic static checks

Page 261: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

261

Bibliography on verificationBibliography on verification

Page 262: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

262

BooksBooks B. Berard et. al., “Systems and Software Verification: Model Checking Techniques and Tools”, Springer

Verlag, 2001. J. Bergeron, “Writing Testbenches: Functional Verification of HDL Models”, Kluwer Academic

Publishers, Boston, 2000. D.D. Gajski et. al., “SpecC: Specification Language and Methodology”, Kluwer Academic Publishers,

Boston, 2000. J. Bhasker, “ A SystemC Primer ”, Star Galaxy Press, Allentown, 2002. M. Suart and D. Dempster, “ Verification Methodology Manual for Code Coverage in HDL Designs”,

Teamwork International, Hampshire, UK, 2000. 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) 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. Hassan Gomaa, “Designing Concurrent, Distributed and Real-Time Applications with UML”, Addison-

Wesley, July 2000.

Page 263: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

263

BooksBooks L. Bening and H. Foster, “Principles of Verifiable RTL Design: Functional Coding Style Supporting

Verification Processes in Verilog”, published by Kluwer Academic Publishers, 2000. R. P. Kurshan, “Computer Aided Verification of Coordinating Processes”, Princeton University Press,

1994. Robert B. Jones, “Symbolic Simulation Methods for Industrial Formal Verification”, Kluwer Academic

Publishers, Boston, 2002. 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. 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) Robert B. Jones, Symbolic Simulation Methods for Industrial Formal Verification, Kluwer Academic

Publishers, Boston, 2002. M. Yoeli, "Formal Verification of Hardware Design", IEEE Computer Society Press, 1991. (Book

containing a collection of papers) M. Kaufmann, P. Manolios, and J S. Moore, "Computer-Aided Reasoning: An Approach", (Kluwer

Academic Publishers, June 2000; ISBN 0792377443) M. Keating and P. Bricaud “Reuse Methodology Manual for System-On-A-Chip Designs,” Kluwer

Academic Publishers, June 1998.

Page 264: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

264

PapersPapersHigh Level Design and Verification Modeling D. D. Gajski, ``IP-Based Design Methodology'', Proc. of the 36th Design Automation Conference, pp.

43, New Orleans, June 1999. D. Kroening and E. Clarke, “Behavioral consistency of C and Verilog programs using bounded model

checking,” in Proc. DAC, June 2003. T. Sakunkonchak and M. Fujita, “Verification of synchronization in SpecC description with the use of

difference decision diagram,” IEICE Trans. Fundamentals, Vol. E85-A, Jan 2002. T. Matsumoto and M. Fujita, “Equivalence checking of C-based hardware descriptions by using

symbolic simulation and program slicer,” in Proc. IWLS, May 2003. T. Ball and S. Rajamani, “Checking Temporal Properties of Software with Boolean Programs”, in

Proc. Computer Aided Verification 2000, [Microsoft SLAM project] R. Bryant et . al. “Processor Verification Using Efficient Reductions of the Logic of Uninterpreted

Functions to Propositional Logic” in ACM Trans. on Computational Logic, Vol 2., 2001.

S. Singh, “Design and Verification of CoreConnectTM IP using Esterel,” in Proc CHARME 2003

S. Sutherland, “System Verilog 3.1 Its what the DAVEs in you company asked for”. in Proc. DVCON 2003

S. Abdi, D. Shin and D. Gajski, "Automatic Communication Refinement for System Level Design,” Proceedings of Design Automation Conference, Anaheim, CA, June 2003.

W. Mueller, R. Dömer, A. Gerstlauer, "The Formal Execution Semantics of SpecC,"in Proceedings of International Symposium on System Synthesis, October 2002.

Page 265: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

265

PapersPapersTheorem Proving & Decision Procedures 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. 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. 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.

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.

C. M. Angelo, “Formal Hardware Verification ina Silicon Compilation Environment by means of Theorem Proving”, Ph.D. Dissertation, Katholieke Universiteit Leuven (February, 1994).

Page 266: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

266

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

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.

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

J.X. Su, D.L. Dill and C.W. Barrett, “Automatic Generation of Invariants in Processor Verification”, Proceedings of FMCAD 1996

M. Aagaard, M. E. Leeser, and P. J. Windley, “Toward a Super Duper Hardware Tactic”, in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August 11-13 1993: Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp. 399-412.

F. Andersen, K. D. Petersen, and J. S. Pettersson, `A Graphical Tool for Proving UNITY Progress', in Higher Order Logic Theorem Proving and Its Applications: 7th International Workshop, Valletta, Malta, September 1994: Proceedings, edited by T. F. Melham and J. Camilleri, Lecture Notes in Computer Science, Volume 859 (Springer-Verlag, 1994), pp. 17-32.

Page 267: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

267

PapersPapers S. Agerholm, `Domain Theory in HOL', in Higher Order Logic Theorem Proving and its

Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August 11-13 1993: Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp. 295-310.

S. Agerholm, `Formalising a Model of the lambda-calculus in HOL-ST' Technical Report Number 354, University of Cambridge Computer Laboratory (1994).

S. Agerholm, “A HOL Basis for Reasoning about Functional Programs”, Ph.D. Dissertation, BRICS Technical Report RS-94-44, Department of Computer Science, University of Aarhus (December 1994).

S. Agerholm, “LCF Examples in HOL”, The Computer Journal, vol. 38, no. 2 (July 1995), pp. 121-130.

S. Agerholm, `Mechanizing Program Verification in HOL', in Proceedings of the 1991 International Workshop on the HOL Theorem Proving System and its Applications, Davis, August 1991, edited by M. Archer, J. J. Joyce, K. N. Levitt, and P. J. Windley (IEEE Computer Society Press, 1992), pp. 208-222.

S. Agerholm, `Mechanizing Program Verification in HOL', M.Sc. Dissertation, DAIMI Report Number IR-111, Department of Computer Science, University of Aarhus (April 1992).

S. Agerholm “Non-Primitive Recursion Function Definition”, in Higher Order Logic Theorem Proving and Its Applications: 8th International Workshop, Aspen Grove, Utah, September 1995: Proceedings, edited by E. T. Schubert, P. J. Windley, and J. Alves-Foss, Lecture Notes in Computer Science, Volume 971 (Springer-Verlag, 1995), pp. 17-31.

F. Andersen and K. D. Petersen, `Recursive Boolean Functions in HOL', in Proceedings of the 1991 International Workshop on the HOL Theorem Proving System and its Applications, Davis, August 1991, edited by M. Archer, J. J. Joyce, K. N. Levitt, and P. J. Windley (IEEE Computer Society Press, 1992), pp. 367-377.

Page 268: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

268

PapersPapers C. M. Angelo, L. Claesen, and H. De Man, “Degrees of Formality in Shallow Embedding

Hardware Description Languages in HOL”, in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August 11-13 1993: Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp. 89-100.

C. M. Angelo, L. Claesen, and H. De Man, `The Formal Semantics Definition of a Multi-Rate DSP Specification Language in HOL', in Higher Order Logic Theorem Proving and its Applications: Proceedings of the IFIP TC10/WG10.2 International Workshop, Leuven, September 1992, edited by L. J. M. Claesen and M. J. C. Gordon, IFIP Transactions A-20 (North-Holland, 1993), pp. 375-394.

C. M. Angelo, L. Claesen, and H. De Man, “Modeling Multi-rate DSP Specifiction Semantics for Formal Transformational Design in HOL”, Formal Methods in System Design, vol. 5, nos. 1/2 (July 1994), pp. 61-94.

R. J. R. Back and J. von Wright, `Predicate Transformers and Higher Order Logic', in Semantics: Foundations and Applications: REX Workshop, Beekbergen, June 1992, edited by J. W. de Bakker, W.-P. de Roever, and G. Rozenberg, Lecture Notes in Computer Science, Volume 666 (Springer-Verlag, 1993), pp. 1-20.

R. J. R. Back and J. von Wright, `Refinement Concepts Formalised in Higher Order Logic', Formal Aspects of Computing, Vol. 2, No. 3 (July-September 1990), pp. 247-272.

S. Bainbridge, A. Camilleri, and R. Fleming, `Industrial Application of Theorem Proving to System Level Design', in Proceedings of the 1991 International Workshop on the HOL Theorem Proving System and its Applications, Davis, August 1991, edited by M. Archer, J. J. Joyce, K. N. Levitt, and P. J. Windley (IEEE Computer Society Press, 1992), pp. 130-142.

F. Andersen, K. D. Petersen, and J. S. Pettersson, `Program Verification using HOL-UNITY', in Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93, Vancouver, B.C., August 11-13 1993: Proceedings, edited by J. J. Joyce and C.-J. H. Seger, Lecture Notes in Computer Science, vol. 780 (Springer-Verlag, 1994), pp. 1-15.

Page 269: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

269

PapersPapers R. H. Beers and P. J. Windley, `Abstracting Signals: The waveform Library', in

Supplementary Proceedings of the 9th International Conference on Theorem Proving in Higher Order LogicsL TPHOLs ’96, edited by J. von Wright, J. Grundy, and J. Harrison, TUCS General Publication No 1, Turku Centre for Computer Science (August, 1996), pp. 1-13.

G. Birtwistle and B. Graham, `Verifying SECD in HOL', in Formal Methods for VLSI Design: IFIP WG 10.2 Lecture Notes, edited by J. Staunstrup (North-Holland, 1990), pp. 129-177.

G. Birtwistle, B. Graham, and S.-K. Chin, “New theory HOL: An Introduction to Hardware Verification in Higher Order Logic”, (August 1994). [Published electronically.]

R. Boulton, `Boyer-Moore Automation for the HOL System', in Higher Order Logic Theorem Proving and its Applications: Proceedings of the IFIP TC10/WG10.2 International Workshop, Leuven, September 1992, edited by L. J. M. Claesen and M. J. C. Gordon, IFIP Transactions A-20 (North-Holland, 1993), pp. 133-142.

R. Boulton, “Combining Decision Procedures in the HOL System”, in Higher Order Logic Theorem Proving and Its Applications: 8th International Workshop, Aspen Grove, Utah, September 1995: Proceedings, edited by E. T. Schubert, P. J. Windley, and J. Alves-Foss, Lecture Notes in Computer Science, Volume 971 (Springer-Verlag, 1995), pp. 75-89.

R. J. Boulton, “Efficiency in a Fully-Expansive Theorem Prover”, Ph.D. Dissertation, Technical Report Number 337, University of Cambridge Computer Laboratory (May 1994).

Page 270: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

270

PapersPapersFormal Verification: SAT Solvers J. Marques-Silva and K. Sakallah, “GRASP: A Search Algorithm for Propositional

Satisfiability”, IEEE Transactions on Computers, 48(5):506-521, May 1999 M. Sheeran and G. Stalmarck, “A tutorial on Stalmarck’s proof procedure for propositional

logic”, Formal Methods in System Design, 16(1):23-58, January 2000 M.H. Moskewicz et. al., “Chaff: engineering an efficient SAT solver,” in Proc. Design

Automation Conf., June 2001. E. Goldberg and Y. Novikov, “BerkMin: a Fast and Robust Sat-Solver”, Proceedings of Design

Automation and Test in Europe, pp.142-149, March 2002.

Formal Verification: BDDs R. E. Bryant, “Graph Based Algorithms for Boolean Function Manipulation”, IEEE

Transactions on Computers, Vol. C-35-8, pp. 677- 691, August 1986 R. Rudell, “Dynamic Variable Ordering for Ordered Binary Decision Diagrams”, Proceedings

of ICCAD 1993, pp. 42- 45 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. Bryant, “Symbolic Boolean Manipulation with Ordered Binary Decision Diagrams”, slides from a presentation by Prof. Bryant in August 1999

Page 271: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

271

PapersPapersFormal Verification: Symbolic Model Checking (BDDs) D. L. Dill, “The Mur Verification System”, 390-393, CAV96. R. Bryant, E. Clarke, K. McMillan and A. Emerson, “Binary Decision Diagrams and

Symbolic Model Checking”, slides from a presentation at Symposium on Algorithms in the Real World, May, 2000

E. M. Clarke, E. A. Emerson and A. P. Sistla, ``Automatic 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.

J. Burch, E. Clarke, D. Long, K. McMillan, D. Dill, “Symbolic Model Checking for Sequential Circuit Verification”, IEEE Trans. Computer Aided Design, 13, 1994, 401-424.

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, ``An approach to Verify a Large Scale System-on-a-chip Using Symbolic Model Checking'', Proceedings of ICCD, 1998.

A. J. Hu, “Formal Hardware Verification with BDDs : An Introduction”, ACM Transactions on Programming Languages and Systems, 1997.

M. Kaufmann, A. Martin, and C. Pixley, "Design Constraints in Symbolic Model M. Kaufmann, A. Martin, and C. Pixley, "Design Constraints in Symbolic Model Checking", Proc. CAV-98, pp. 477-487, 1998.Checking", Proc. CAV-98, pp. 477-487, 1998.

K. L. McMillan, "Fitting formal methods into the design cycle", Proceedings of the 31st K. L. McMillan, "Fitting formal methods into the design cycle", Proceedings of the 31st Design Automation Conference, pp. 314-19, 1994Design Automation Conference, pp. 314-19, 1994

Page 272: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

272

PapersPapers

Formal Verification with SAT solvers P. Abdulla, P. Bjesse and N. Een, “Symbolic Reachability Analysis Based on SAT

Solvers”, Proceedings of Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pp. 41-425, March 2000

P. Williams et al, “Combining Decision Diagrams and SAT Procedures for Efficient Symbolic Model Checking”, Proc. of the 12th CAV, pp. 124-138, July 2000

M. Sheeran, S. Singh and G. Stalmarck, “Checking Safety Properties Using Induction and a SAT Solver”, Proc. of the 3rd Intl. Conference on Formal Methods in CAD (FMCAD), pp. 208-125, Nov. 2000

P. Bjesse and K. Claessen, “SAT-based Verification without State Space Traversal”, Proc. of the 3rd FMCAD, pp. 372-389, Nov. 2000

K.L. McMillan, “Applying SAT Methods in Unbounded Model Checking”, Proc. of the 14th CAV, pp. 250-264, July 2002

K.L. McMillan, “Interpolation and SAT-based Model Checking”, Proc. of the 15 th CAV, July 2003

I. Park and H. Kang, “SAT-based unbounded symbolic model checking”, Proceedings of DAC, pp. 840-843, June 2003

Page 273: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

273

PapersPapersEquivalence Checking D. Brand, “Verification of Large Synthesized Designs”, Proceedings of ICCAD,

November 1993, pp. 534-537 A. Kuehlmann and F. Krohm, “Equivalence Checking using Cuts and Heaps”,

Proceedings of DAC 1997, pp. 263-268 Y. Matsunaga, “An Efficient Equivalence Checker for Combinational Circuits”,

Proceedings of DAC 1996, pp. 629-634 R. Mukherjee, J. Jain, K. Takayama, M. Fujita, J. Abraham and D. Fussell, “An Efficient

Filter Based Approach for Combinational Verification”, in IEEE Transactions on CAD, 18:1542-1557, Nov. 1999

H. Cho and C. Pixley, “Apparatus and Method for deriving correspondences between storage elements of a first circuit model and storage elements of a second circuit model”, U.S. Patent 5,638,381, June 1997

K. Ng, M. Prasad, R. Mukherjee and J. Jain, “Solving the Latch Mapping Problem in an Industrial Setting”, Proceedings of DAC 2003, pp. 442-447

C.A.J. van Eijk, “Sequential Equivalence Checking Based on Structural Similarities”, IEEE Transactions on CAD, 19(7):814-819, July 2000

S.-Y. Huang, K.-T. Cheng, K.-C. Chen and F. Brewer, “AQUILA: An Equivalence Checking System for Large Sequential Circuits”, IEEE Transactions on Computers, 49(5), May 2000

Page 274: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

274

PapersPapersSemi-Formal Verification R. E. Bryant, “Symbolic Simulation -- Techniques and Applications”, Proceedings of

DAC 1990 R.B. Jones, “Applications of Symbolic Simulation to the Formal Verification of

Microprocessors”, Ph.D. Thesis, Computer Systems Laboratory, Stanford University, August 1999

R.E. Bryant and C.J.H. Seger, “Formal hardware verification by symbolic trajectory evaluation,” in Proc. Design Automation Conf., June 1991.

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

E. Clarke, A Biere, R. Raimi and Y. Zhu, “Bounded Model Checking Using Satisfiability Solving”, in Formal Methods in System Design, 19(1): 7-34, July 2001, Kluwer Academic Publishers

O. Shtrichman, “Tuning SAT Checkers for bounded model checking,” in Proc. Int. Conf. on Computer-Aided Verification, July 2000.

F. Fallah, “Binary Time-Frame Expansion”, Proc. of ICCAD, pp. 458-464, Nov. 2002 A. Gupta et al, “Learning from BDDs in SAT-based bounded model checking,” in

Proc. Design Automation Conf., June 2003. V. Boppana, S. Rajan, K. Takayama and M. Fujita, “Model Checking Based on

Sequential ATPG”, Proceedings of CAV, pp. 418-430, July 1999. J. Abraham, V. Vedula and D. Saab, “Verifying Properties Using Sequential ATPG”,

Proceedings of International Test Conference, October 2002

Page 275: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

275

PapersPapers D. Dill and S. Tasiran, "Simulation meets Formal Verification?", slides from a

presentation at ICCAD'99. D. Dill, "Alternative Approaches to Formal Verification (Symbolic Simulation)", slides

from a presentation at CAV 1999. C. H. Yang and D. L. Dill, “Validation with Guided Search of the State Space”,

Proceedings of DAC 1998 M. Ganai et al, “SIVA: A System for Coverage Directed State Space Search”, In

Journal of Electronic Testing: Theory and Applications (JETTA), February 2001 P.-H. Ho et al, “Smart Simulation Using Collaborative Formal and Simulation

Engines”, Proceedings of ICCAD, pp. 120-126, November 2000 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.

Model Checking in Practice 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.

Page 276: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

276

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

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.

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.

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.

T. Henzinger, X. Liu, S. Qadeer and S. Rajamani, “Formal Specification and Verification of a Dataflow Processor Array,”Proceedings of ICCAD 1999

D. Wang, “SAT based Abstraction Refinement for Hardware Verification”, Ph.D. thesis, ECE Dept., Carnegie Mellon University, May 2003

Shankar G. Govindaraju, David L. Dill, Alan J. Hu, and Mark A. Horowitz. "Approximate Reachability with BDDs using Overlapping Projections,” in Proc. DAC 1998

Gaurishankar Govindaraju, "Approximate Symbolic Model Checking using Overlapping Projections" Ph.D. thesis, Stanford University, August 2000.

Page 277: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

277

PapersPapersSimulation Based Verification I. Ghosh and M. Fujita, ``Automatic test pattern generation for functional register-transferlevel circuits using

assignment decision diagrams,'' IEEE. Trans. on Computer-Aided Design, Vol. 20, No. 3, pp. 402-415, March 2001.

F. Fallah, S. Devadas, and K. Keutzer, ``OCCOM: Efficient computation of observability-based code coverage metrics for functional verification,'' IEEE. Trans. on Computer-Aided Design, Vol. 20, No. 8, pp. 1003-1015, Aug. 1998.

F. Fallah, S. Devadas, and K. Keutzer, ``Functional vector generation for HDL models using linear programming and 3-satisfiability,”{\em IEEE. Trans. on Computer-Aided Design}, Vol. 20, No. 8, pp. 994-1002, Aug. 1998.

S. Ravi, G. Lakshminarayana, and N.K. Jha, ``TAO: Regular expression based high-level testability analysis and optimization,'' in Int. Test Conf., pp. 331-340, Oct. 1998.

I. Ghosh and S. Ravi, “On automatic generation of RTL validation test benches using circuit testing techniques,” in Proc. Great Lakes Symposium on VLSI, April 2003.

L. Zhang, I. Ghosh and M. Hsiao, “Efficient sequential ATPG for functional RTL circuits,” in Proc. International Test Conference, Oct. 2003.

L. Zhang, I. Ghosh and M. Hsiao, “Automatic design validation framework for HDL descriptions via RTL ATPG,” in Proc. Asian Test Symposium, Nov. 2003

F. Fallah, I. Ghosh, and M. Fujita, “Event driven observability enhanced coverage analysis of C programs for functional validation,” in {\em Proc. Asia and South Pacific Design Automation Conference}, Jan. 2003.

K. Ara and K. Suzuki, “A proposal for transaction level verification with component wrapper language,” Proc. Design Automation and Test in Europe, March 2003.

A. U. Shankar, "An Introduction to Assertional Reasoning for Concurrent Systems", ACM Computing Surveys, Sept. 1993, Vol 25, No. 3, pp. 225-262

Page 278: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

278

PapersPapers S. Ramesh and P. Bhaduri, “Validation of Pipelined Processor Designs using Esterel

Tools: A Case Study”, Proc. of CAV '99, LNCS Vol. 1633, 1999. C. Eisner et. al. “The Temporal Logic Sugar” in Proc. Int Conf. on Computer-aided

Verification 2001.

Miscellaneous 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 C. H. Yang and D. L. Dill, “Validation with Guided Search of the State Space”,

Proceedings of DAC 1998 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

Page 279: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

279

Important web-sitesImportant web-sites

http://www.comlab.ox.ac.uk/archive/formal-methods.html

http://www.csl.sri.com

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)

http://www-sop.inria.fr/meije/verification/esterel

http://www.accellera.org

http://www.systemC.org

http://www.specC.org

Page 280: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

280

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

Page 281: 1 Formal verification of SoC designs (targeting logic verification only) Masahiro Fujita VLSI Design and Education Center (VDEC) University of Tokyo fujita@ee.t.u-tokyo.ac.jp

281

Journals/MagazinesJournals/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