Towards the Formal Verification of a Java Processor in Event-B Neil Evans and Neil Grant AWE, Aldermaston

Motivation l The Scalable Core processor (Score) is a hardware implementation of a JVM l Instruction Set Architecture (ISA) level instructions are Java bytecodes l At the lower Microcode Architecture (MA) level, ISA-level programs are executed by an interpreter l Below lies the digital logic of the processor l We aim to prove a correspondence between ISA-level code and its MA-level interpretation

Microcoded Processor Operation DPRAM PROGRAM DATA HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU stackDataIn stackAddr stackDataOut MUX iADD

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU stackDataIn stackAddr stackDataOut MUX sp 0 0 sp-1 0 loadStackVarsAndDec(const 0)

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU sp 0 stackDataIn stackAddr stackDataOut MUX stackRead x

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU x sp 0 stackDataIn stackAddr stackDataOut MUX writeRegAndStackWrite x

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU x sp 0 stackDataIn stackAddr stackDataOut MUX sp-1 0 sp-2 0 loadStackVarsAndDec(const 0) sp-1

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU x sp-1 0 stackDataIn stackAddr stackDataOut MUX stackRead y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU y sp-1 0 stackDataIn stackAddr stackDataOut MUX writeRegAndStackWrite y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU stackDataIn stackAddr stackDataOut MUX xyxy dualLoadALU x y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU stackDataIn stackAddr stackDataOut MUX ALUAdd x y x+y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 stackDataIn stackAddr stackDataOut MUX writeALUResult x+y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU stackDataIn stackAddr stackDataOut MUX sp-2 x+y loadStackDataAndInc sp-1 x+y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU stackDataIn stackAddr stackDataOut MUX sp-1 loadStackAddr sp-1 x+y

Microcoded Processor Operation DPRAM iADD HEAP MICROCODED INSTRUCTION EXECUTION CONTROLLER +/- 1 ALU sp-1 x+y stackDataIn stackAddr stackDataOut MUX StackWrite

What we aim to do l Ultimately, we want to prove correctness of the Score processor l In other words, the behaviour dictated by the microcoded instruction execution controller should meet the specification of the JVM l However l Java bytecodes are specified as single-step instructions l The Score processor will execute multiple cycles to achieve the desired behaviour l So we need a formal approach to reconcile these

Possible Approaches l General purpose languages and tools l ACL2 uses Lisp and has theorem proving support l Tailor the tool (by constructing user-defined theories) to solve the problem l Dedicated languages and tools for refinement l The B Method and its tool support (in particular Event-B and the Rodin tool) l Tailor the problem to make it amenable to B refinement checking

Event-B l An Event-B model comprises l A static part containing sets, constants, properties l A dynamic part containing state variables, events and an invariant to specify behaviour An event E is of the form E = WHEN G(v) THEN S(v) END where G(v) is a guard S(v) is a substitution (ours will be deterministic) l Both of which refer to the state variables

Refinement in Event-B l The state can be refined by replacing abstract representations of objects with more concrete implementation-like representations l Existing events are refined accordingly, but new events can be introduced to give a more fine-grained specification of behaviour l A gluing invariant is defined in the refined model to formalise the relationship between the abstract and concrete representations l However, this relationship is only relevant in certain states

Refinement of iADD

An Abstract Model SETS Stack Bytecode Status = { ACTIVE, INACTIVE } CONSTANTS iADD  Bytecode null  Stack cons  N × Stack  (Stack – { null }) hd  (Stack – { null })  N tl  (Stack – { null })  Stack len  Stack  N PROPERTIES  n, s. (n  N  s  Stack  hd(cons(n, s)) = n)  n, s. (n  N  s  Stack  tl(cons(n, s)) = s) len(null) = 0  n, s. (n  N  s  Stack  len(cons(n, s)) = 1 + len(s))

An Abstract Model VARIABLES bytecode iadd_status stack INVARIANT bytecode  Bytecode iadd_status  Status stack  Stack iadd_status = ACTIVE  len(stack) > 1 EVENTS iADD_ini = iADD = WHEN WHEN iadd_status = INACTIVE  iadd_status = ACTIVE len(stack) > 1  THEN bytecode = iadd stack := cons(hd(stack) + hd(tl(stack)), tl(tl(stack))) || THEN iadd_status := INACTIVE iadd_status := ACTIVE END END

Concrete Variables bytecode1  Bytecode iadd_status1  Status stack1  N 1  N SP  N stackDataIn  N stackDataOut  N ALURegA  N ALURegB  N ALUOutReg  N stackDataInSet  BOOL stackDataOutSet  BOOL ALURegASet  BOOL ALURegBSet  BOOL ALUOutSet  BOOL

Refinement of Existing Events iADD_ini becomes the first step in the execution of the microcoded architecture, and iADD becomes the last l In addition to these, new events are introduced to model the intermediate steps in the execution of the microcoded architecture iADD_ini = iADD = WHEN iadd_status1 = INACTIVE  iadd_status1 = ACTIVE  SP > 1  stackDataOutSet = TRUE bytecode1 = iadd THEN THEN stack1(SP) := stackDataOut || iadd_status1 := ACTIVE iadd_status1 := INACTIVE || END stackDataOutSet := FALSE || ALURegASet := FALSE || ALURegBSet := FALSE || ALUOutSet := FALSE END

A Correspondence

l We add the invariant iadd_status1 = INACTIVE  eqv(SP, stack1, stack) where eqv(n, s, null) = n = 0 eqv(n, s, cons(h, t)) = n > 0  s(n) = h  eqv(n-1, s, t) The refined versions of iADD induces the proof obligation eqv(SP, stack1  { SP  stackDataOut }, cons(hd(stack) + hd(tl(stack)), tl(tl(stack)))) under the assumption stackDataOutSet = TRUE

A Correspondence iADD =iADD = WHEN WHEN iadd_status1 = ACTIVE iadd_status1 = ACTIVE  THEN stackDataOutSet = TRUE stack := cons(hd(stack) + hd(tl(stack)), tl(tl(stack))) || THEN iadd_status := INACTIVE stack1(SP) := stackDataOut || END iadd_status1 := INACTIVE || stackDataOutSet := FALSE || ALURegASet := FALSE || ALURegBSet := FALSE || ALUOutSet := FALSE END stackDataOutSet = TRUE  eqv(SP, stack1  { SP  stackDataOut }, cons(hd(stack) + hd(tl(stack)), tl(tl(stack)))) iadd_status1 = INACTIVE  eqv(SP, stack1, stack)

l The formula cannot be proven, so we add it to the invariant l This induces further proof obligations – in this case from an event introduced in the refinement A Correspondence loadStackDataAndInc = WHEN ALUOutSet = TRUE  stackDataOutSet = FALSE THEN SP := SP + 1 || stackDataOut := ALUOutReg || stackDataOutSet := TRUE || END stackDataOutSet = TRUE  eqv(SP, stack1  { SP  stackDataOut }, cons(hd(stack) + hd(tl(stack)), tl(tl(stack))))

A Correspondence We work our way backwards through the sequence of events that lead up to iADD, adding to the invariant along the way, until we reach iADD_ini (and an INACTIVE state) l We are left to prove l This can be derived from an assumption of eqv(SP - 1, stack1  { SP-1  stack1(SP) + stack1(SP - 1) }, cons(hd(stack) + hd(tl(stack)), tl(tl(stack)))) iadd_status1 = INACTIVE  eqv(SP, stack1, stack)

Pros l This approach of repeatedly generating proof obligations and adding them to the invariant until no further proof obligations are generated is an automatic process l As a consequence, the proof of correctness is almost entirely automated l Overall, the (unremarkable) nature of this result demonstrates that Event-B refinement is well-suited for this kind of application

Cons l One criticism of the concrete model is the implicit control (ordering of events) specified by the guards: l Constructing the guards in the refined model is quite tricky l The flow of control in the refined model is not obvious l Ideally the formal model should look like the informal thing that it claims to represent l A CSP representation of the control flow (i.e. by taking a CSP||B approach) could help

Conclusion l We have seen how an off-the-shelf approach can be used in the verification of an abstract processor with a microcoded architecture l The approach is typical of Event-B, which demonstrates its suitability l Most proof obligations were discharged automatically (223 out of 234 refinement po’s) l Further work is needed to verify all of the subtleties of the microcoded architecture of the Score processor, and to verify its correctness at the digital logic level