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

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

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