Download presentation

Presentation is loading. Please wait.

Published byPaola Meller Modified about 1 year ago

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

2
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

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

4
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)

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

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

7
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

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

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

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

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

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

13
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

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

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

16
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

17
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

18
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

19
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

20
Refinement of iADD

21
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))

22
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

23
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

24
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

25
A Correspondence

26
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

27
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)

28
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))))

29
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)

30
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

31
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

32
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

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google