Functional Decompositions for Hardware Verification With a few

Functional Decompositions for Hardware Verification With a few speculations on formal methods for embedded systems Ken Mc. Millan

Verification approaches • Informal verification (testing) – risk of “escapes” • Partial formal verification – prove, for example, no arithmetic overflow – can use very coarse abstractions • Formal functional verification – verify against functional spec

Outline • Formal functional verification for hardware – combined theorem proving/ model checking – proof decomposition strategies that allow coarse abstractions • Prospects of application to embedded systems – how are embedded systems different p. o. v. formal verification? – how might we apply formal hardware verification methods to embedded systems?

Mixed approach • Model checking – automated verification of finite state systems – limited in scale by “state explosion problem” • Theorem provers – in principle can “scale up” – in practice require substantial manual guidance • Mixed approach – use theorem prover to break large problems into small, model-checkable problems

Proof decomposition: Proof goal Undecidable/ intractable proof assistant sub sub Decidable/ tractable • reduction to decidable/tractable problems • do it in as few (and as simple) steps as possible. . . but how?

Structural decompositions {p} M 1 {q} M 2 {r} {p} M 1||M 2 {r} • intermediate assertions must be temporal • q captures everything M 2 must know about M 1 • intermediate assertions can be quite complex

Functional decompositions • Divide by “units of work” and not by syntax – instructions – packets – etc. • Much simpler intermediate assertions – interaction between “units of work” is simpler than between system components • Abstraction to finite state – if each “unit of work” uses finite resources – temporal assertions become model-checkable

Example : packet router input buffers output buffers Switch fabric • Unit of work is a packet • Packets don’t interact • Each packet uses finite resources – specializing the property allows a much coarser abstraction

Refinement framework Reference model refinement relations System • Refinement relations – Specify intermediate results with respect to reference model – Each intermediate result uses finite • operations • storage locations – Thus, can reduce local verification problems to finite state – Use circular proof!

“Circular” proofs Reference model f 1 up to t -1 implies f 2 up to t -1 implies f 1 up to t always f 1 and f 2 or, in temporal logic. . . Ø(f 2 U f 1) Ø(f 1 U f 2) G(f 1 Ù f 2) O. K. , but how do we break into “units of work”?

Temporal case splitting p 1 p 2 p 3 p 4 p 5 . . . v 1 Idea: parameterize on most recent writer w at time t. f: I'm O. K. at time t. "i: pi Þ G((w=i) Þ f) (Ùi pi) Þ Gf Rule can be used to decompose large arrays

Combine with “circular” reasoning p 1 p 2 p 3 p 4 p 5 . . . v 1 f: I'm O. K. at time t. To prove case w=i at time t, assume general case up to t-1: "i: pi Þ f ® 1 ((w=i) Þ f) (Ùi pi) Þ Gf still have unbounded cases to prove. . .

Freeing processes p 1 p 2 p 3 p 4 p 5 v 1 f: I'm O. K. at time t. "i: pi Þ f ® 1 ((w=i) Þ f) (Ùi pi) Þ Gf . . .

Abstract interpretation • Problem: variables range over unbounded set U • Solution: reduce U to finite set Û by a parameterized abstraction, e. g. , Û = {{i}, Ui} where Ui represents all the values in U except i. • Need a sound abstract interpretation, s. t. : if f is valid in the abstraction, then, for all parameter valuations, f is valid in the original.

Data type abstractions in SMV • Abstract values represent sets of concrete values Û = {{i}, Ui} • For sound abstraction of operator f, we need: • Examples: – Equality f(ax) £ a(fx) = {i} Ui {i} 1 0 Ui 0 ^

Abstraction, continued. . . – Arrays and function symbols x {i} Ui f(x) f(i) ^ Unbounded array reduced to one fixed element! – Other operators. . . • • boolean operators temporal operators quantifiers arithmetic/inequalities

Illustration: Tomasulo’s algorithm • Execute instructions in data flow order REG FILE VAL/TAG TAGGED RESULTS OP, DST EU opra oprb INSTRUCTIONS OP, DST opra oprb OPS EU EU

Functional decomposition • “Unit of work” is the instruction REG FILE VAL/TAG TAGGED RESULTS OP, DST EU EU opra oprb INSTRUCTIONS OP, DST opra oprb OPS EU EU

Functional decomposition • Break instruction into operand fetch and op REG FILE VAL/TAG TAGGED RESULTS OP, DST EU opra oprb INSTRUCTIONS OP, DST opra oprb OPS EU EU

Intermediate assertion • All previous instructions produce correct res REG FILE VAL/TAG TAGGED RESULTS OP, DST EU opra oprb INSTRUCTIONS OP, DST opra oprb OPS EU EU

Points about this proof • Three simple intermediate assertions – operands of instruction are correct – results of instruction are correct – one non-interference property • No invariants about control state • No syntactic decomposition – Abstract interpretation reduces model to finite • Much simpler than proof by invariant is there a useful structural decomposition?

A more complex example REG VAL/TAG FILE VAL/TAG RETIRED RESULTS VAL/TAG PM PC pc branch predictor d e c OP, DST INSTRUCTIONS OP, DST opraoprb branch results LSQ • Unit of work = instruction BUF EU opraoprb OPS EU EU RES BUF DM

Scaling problem • Must consider up to three instructions: – instruction we want to verify – up to two previous instructions ==> too much state for model checker • Soln: break instruction up into parts – write intermediate assertions

Memory operation REG VAL/TAG FILE VAL/TAG RETIRED RESULTS VAL/TAG PM d e c OP, DST INSTRUCTIONS OP, DST opraoprb OP, DST PC branch predictor specify LSQ data OPS EU EU opraoprb branch results BUF EU opraoprb LSQ • Abstract out unneeded components RES BUF DM

Points about this proof • No interface specifications – specify internal data structures of units • No invariants on control state • First decomposition is functional – then abstract out structural components • Compared to similar proof using invariants. . . – invariant proof approx. 2 MB (!) – this proof approx. 20 KB

FLASH cache protocol • Distributed protocol • Maintains consistency of N processor caches home P C P C P C dir mem • Reference model is “programmer’s model” of memory • Unit of work = read/write

Proof decomposition fwd P home C P writer C interference ack get put P C Abstracted nodes reader • Unit of work = read/write • Non-interference lemmas – No two exclusive copies in network – No unexpected invalidate acks

Lamport's Bakery algorithm p 1(t 1) p 2(t 2) p 3(t 3) p 4(t 4) non-critical section read all tickets choose one larger wait for all processes with smaller ticket critical section . . .

Liveness proof (Qadeer and Saxe) • Unit of work = ticket number – Split cases on process pj that process pi is waiting for. . . pj(tj) . . . pi(ti) . . . – Assume by induction that j terminates if tj

Points about this proof • No invariants used • Two liveness lemmas: – one for termination of each loop – these reference specific code lines, but. . . • No syntactic decomposition used

Overview of approach • Specify by temporal refinement relations – “circular” temporal argument • Specialize properties by restricting to a single “unit of work” – temporal “case splitting” • Abstract to finite-state – specialization allows a coarser abstract interpretation This approach is supported by a special purpose proof assistant, built on the SMV model checker

Application to embedded systems • Generic software issues • Issues specific to embedded systems

Why is HW easier than SW? • Finite-state is not the issue – Proofs above did not depend on bounded state • “Bad” aspects of software – global store (hardware term: bottleneck) • any component can “interfere” with any other • we can expect an explosion of non-interference lemmas • pointers are a chief culprit – inductive data structures • requires complex invariants for recursive functions – arithmetic? – real time?

Can we make SW more HW-like? • More structured communication – allows coarser abstractions for verification without introducing interference – good examples: Esterel, Polis, etc. • Increase grain of atomicity – analog of clock cycle • Separate timing from functionality – as in synchronous hardware Trends are in these directions, although languages are problematic (esp. C++)

Embedded systems issues • How do embedded systems differ from other systems, from an FV point of view? – hardware differences • processors tend to be simpler (good) • many and heterogeneous processors – hard real time (see above) – greater software/hardware interaction • more precisely: interaction at less abstract level

Abstracting hardware arch. software model HW reference model refinement relation hardware implementation • Use FV to construct abstract reference models of custom hardware

Abstracting HW/SW comps software driver reference model refinement relation software driver • Next layer up is provided by driver HW reference model

“Platform” based design • Build an abstract layer using synthesis tools • Formal framework for integrating models constraint syntax compilation/ synthesis syntax refinement relations intf

Conclusions • Functional approach to proof decomposition – – divide problem into “units of work” allows coarse abstractions for model checking proof effort appears to scale well with system size supported by special-purpose proof assistant • Issues for application to embedded systems – Needs more structured communication – Needs separation of timing and function – Can provide reference models to abstract hardware/software interface – Can support platform-based design