Incremental formal verification of hardware

18
Incremental formal verification of hardware Hana Chockler Alexander Ivrii Arie Matsliah Shiri Moran Ziv Nevo IBM Research - Haifa

description

Hana Chockler Alexander Ivrii Arie Matsliah Shiri Moran Ziv Nevo IBM Research - Haifa. Incremental formal verification of hardware. Formal verification (hardware). Effective, but computationally expensive In many scenarios, similar verification tasks are performed repetitively : - PowerPoint PPT Presentation

Transcript of Incremental formal verification of hardware

Page 1: Incremental formal verification  of hardware

Incremental formal verification of hardware

Hana ChocklerAlexander IvriiArie MatsliahShiri MoranZiv Nevo

IBM Research - Haifa

Page 2: Incremental formal verification  of hardware

Formal verification (hardware)

Design Spec

Verification tool

Pass / Fail

• Effective, but computationally expensive

• In many scenarios, similar verification tasks are performed repetitively:

• Regression verification

• Update to design

• Update to specifications

• Coverage verification

• Can we store and reuse information to reduce amount of redundant computation?

Page 3: Incremental formal verification  of hardware

Incremental formal verification

Design Spec

Verification tool

Pass / Fail

DB

hardwaresafety

properties

ic3

extract relevant part of

previously saved information

store reusable

information

Page 4: Incremental formal verification  of hardware

● inductive proofs and inductive strengthening

● saving information

– ic3 overview

– what is saved?

● reusing saved information

– extracting relevant parts (w.r.t. new design/spec)

– checking if verification can be concluded

– injecting into ic3

● conclusion and experimental results

Outline

Page 5: Incremental formal verification  of hardware

● x1,x2,…,xn – state variables (latches)

● I – initial states

● T – transition relation

● R – all reachable states

● Ri – states reachable within i steps from I

● P – (safety) property

FSMs and safety properties

I

R2

R1

R

All states

…Rk-1

┐P

T(s,t)

Page 6: Incremental formal verification  of hardware

Inductive proofs (for R P)

● Simple induction:

– I P, P ^ T P‘

Sufficient but not necessary. Almost never holds in practice..

● Solution: find G such that:

– I G

– G ^ T G‘

– G P

G is over-approximation of R

I R G All

states

┐P

!

Page 7: Incremental formal verification  of hardware

ic3 - basic properties

● Complete – always terminates with correct result

● SAT based, no unrolling

● If P is invariant, produces a CNF formula G, s.t.:

– I G

– G ^ T G’

– G P

● If not, produces a (generalized) CEX α0, α1,…, αk s.t.:

– all α0 states belong to I

– all αi states lead to some αi+1 state

– αk is in ┐P I a0 a1 ┐P ak

I R G All

states

┐P

Page 8: Incremental formal verification  of hardware

● Clause sets/CNF formulas F1,...,Fk

● Initially: k=1, F1 = P (assume I P and Img(I) P)

● Invariants:

– I F1 ... Fk P (furthermore, for all i, Fi+1 is a subset of Fi)

– Img(Fi) Fi+1

– Ri Fi

(bounded) inductive invariants in ic3

F0=I

F1

Fk-1

P

…Img(F0)Img(Fk-2) Img(Fk-1)

Fk

● If Fi = Fi+1 for some i<k, then Fi is an inductive strengthening that proves

R P

Page 9: Incremental formal verification  of hardware

ic3 progress and termination● Inductive clauses that block “bad state predecessors” are

added to the sets Fi, in a way that maintains the containment invariants

● Once in a while, clauses are “pushed” to higher Fi’s

● ic3 terminates when either:

– Fi=Fi+1 for some i we save the inductive invariant Fi

– it finds a CEX: chain of bad state predecessors that starts at I

we generalize and save the CEX

+ we save the absolute invariants

* Absolute inductive invariants are those clauses that were “pushed” beyond Fk

Page 10: Incremental formal verification  of hardware

How to reuse saved invariants?

Finding maximal inductive invariant

● Input:

I, T, P and C = {c1,…,cm} - candidate invariant clauses

● Output:

PASS or maximum subset Q of C such that I Q and Q ^ T Q‘

* Note: if Q1 ^ T Q’1 and Q2 ^ T Q‘2 then (Q1 U Q2) ^ T (Q’1 U Q’2)

• Once such Q is found, we can “inject” it into ic3 by conjoining Q with all sets Fi

• This saves ic3 the effort of “rediscovering” the invariants from Q

Page 11: Incremental formal verification  of hardware

Finding Q using a SAT solver* that supports SolveWithAssumptions(a1,...,ak)

1. cnfize T and I, set Q:=C

2. remove from Q all clauses that are not implied by I

3. for every ci in Q, introduce two auxiliary vars: xi and y’i

4. for every i, cnfize xi ci and y’i ┐c’i

5. SolveWithAssumptions(x1, ..., x|Q|, (y’1 v ... v y’|Q|))

6. if unsat:

Q is invariantif sat:

remove from Q each ci with assign(y’i)=1 and goto 5

7. if Q P output PASS, ow return Q

Page 12: Incremental formal verification  of hardware

Overall approach

Design Spec

Verification tool

Pass / Fail

DB

inductive invariants / generalized CEXes

inject maximal inductive-invariant

into ic3

save inductive invariant / CEX

maximal invariant/ CEX extraction

Page 13: Incremental formal verification  of hardware

Experimental results(accumulated runtimes in seconds)

From scratch After original After mutated

Original 30,597 402 10,070

Mutated 50,294 37,348 2,091

From scratch After original After mutated

Original 36,605 1,238 11,710

Mutated 54,160 24,447 883

758 designs from HWMCC’10

17 IBM designs

Page 14: Incremental formal verification  of hardware

Concluding remarks● ic3 can be used to save small inductive proofs, and

generalized CEXes

● the technique is robust since ic3 invariants and CEXes involve only state variables

● makes coverage and regression verification almost immediate

● parts from inductive proofs can be used even if design/spec has significantly changed

● saved information is reusable even when verification result changes

Page 15: Incremental formal verification  of hardware

The End

Page 16: Incremental formal verification  of hardware

Generalizing assignments● Input:

circuit C and assignment a such that C(a)=y

● Output:

partial assignment a’ such that

C(b)=y for all extensions b of a’

* a’ is obtained by subst. some of the 0,1 values in a with x (don’t cares)

Standard algs:

• start from root and propagate “cares”

• start from leaves and propagate “don’t cares”

Page 17: Incremental formal verification  of hardware

Generalizing assigns. with solver

● Input:

circuit C and assignment a such that C(a)=y

● Output:

partial assignment a’ such that

C(b)=y for all extensions b of a’

1. cnfize C

2. SolveWithAssumptions(┐(C(a)=y), a1, ..., an)

* must return unsat (BCP)

3. if ai participates in the conflict set a’i = ai

else set a’i = x

Page 18: Incremental formal verification  of hardware

Generalizing assigns. with solver

1. cnfize C

2. SolveWithAssumptions(┐(C(a)=y), a1, ..., an)

* must return unsat (BCP)

3. if ai participates in the conflict set a’i = ai

else set a’i = x

Advantages:

1. easy to enforce additional constraints (e.g. learnt clauses and invars)

2. can order the variables in the assumptions acc. to some priority

3. can run after standard algs

4. no real solving – just BCP

5. shrinks by additional 30-40% after ternary simulation (like in PDR)