Download presentation

Presentation is loading. Please wait.

Published byPaola Meller Modified over 2 years 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

OK

Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.

Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google

Ppt on immunisation schedule Ppt on nokia company profile Ppt on principles of object-oriented programming language Ppt on leadership Ppt on email etiquettes presentation church Ppt on bluetooth hacking working Ppt on biodegradable and non biodegradable bins Ppt on history of atoms Ppt on total internal reflection animation Ppt on red fort delhi