Verifying Architecture

download Verifying Architecture

of 21

  • date post

  • Category


  • view

  • download


Embed Size (px)


This presentation will probably involve audience discussion, which will create action items. Use PowerPoint to keep track of these action items during your presentation In Slide Show, click on the right mouse button Select “Meeting Minder” Select the “Action Items” tab - PowerPoint PPT Presentation

Transcript of Verifying Architecture

  • Verifying ArchitectureJaein JeongJohnathon Jamison

    This presentation will probably involve audience discussion, which will create action items. Use PowerPoint to keep track of these action items during your presentation

    In Slide Show, click on the right mouse buttonSelect Meeting MinderSelect the Action Items tabType in action items as they come upClick OK to dismiss this box

    This will automatically create an Action Item slide at the end of your presentation with your points entered.

  • IntroductionProcessors are more vulnerable to transient errors due to small feature size. Can detect transient errors with more stable processors and execute instructions again if an error occurs.Overhead won't be high for errors occurring rarely.

  • Introduction (Cont.)DIVA: verifies execution each individual instruction with a second, slower.Our idea: a dual-processor verification system.Proof-carrying code: A proof of safety accompanies executable code. Our idea: executable code is annotated with invariants.

  • AssumptionsWe assume there are no permanent errors.Thus we need not worry about invariants failing always.So, processor can work correctly if it is verified by a more stable processor.

  • Assumptions (Cont.)We assume the processor operates correctly most of the time.Therefore it is reasonable to check for errors rarely.The overhead is not problematic, for errors occur rarely.

  • System StructureImplemented as two communicating processors.The main processor executes instructions and sends the verifier all its registers.If the verifier confirms the execution, the main continues to execute instructions.Otherwise, the main processor loads the old register values and re-executes its instructions.

  • System Structure (Cont.)

  • Programming for SimpleScalarSince gcc can not handle everything, we intervene at the assembly code level.After changing the assembly code, we compile it to object code. The message passing system calls qread and qwrite are not implemented in gcc.So, we insert the syscall instruction and pass arguments by explicitly filling registers.

  • Programming for SimpleScalar (Cont.) addiu $2,$0,258 la $4,MQO subu $5,$16,4 move $6,$0 syscall Writing a message to a queue$L2: addiu $2,$0,259 la $4,MQI addu $5,$sp,16 move $6,$0 syscall bne $7,$0,$L2 Reading a message from a queue.

  • Programming interface for CAssembly language programming is error prone and unproductive.We wrote a interface for C with macros and inline assembly.Since syscall is not accessible in C, we generate a jal syscall in assembly.A Perl script replaces it with syscall.Now we can compile the assembly code without further modification.

  • Multiprocessor Program Examplelong regs[32]; char msg[]="\006\000\000\000cool\n"; long nullmsg[]={0}; char MQI[]="\003min"; char MQO[]="\004mout"; qwrite(MQO,msg,0,error); do { qread(length,MQI,regs,0,error); } while(error);

  • Passing Invariants (1st method)The main program sends the invariant instructions as a message.We enclosed the invariant instructions with .rdata and .text directives and insert the length of the message after .rdata.Then the main can send the instructions as a message.The verifying processor then can load its registers with it, and do a jal to the message that was sent.

  • Passing Invariants (2nd method)Generate a verifying program specific to the main program.When running the main program, just send the the contents of registers and the invariant number.The verifying processor takes the invariant number, calculates the value of the invariant, and replies.

  • Passing Invariants (Cont.)A bit of a problem for the first method.The verifying program receives invariant instructions as data.Execution of those instructions would bring up the same issues as self-modifying code.Due to pitfalls of first method, we chose the second method.

  • Using InvariantsWe maintain two sets of registers in the verifier for roll back purposes.Not all registers must be sent to the verifier, just those needed for the invariant or possible rollback.Currently, creating the verifier requires careful inspection of the main programWe hope to automate some of this.

  • PerformanceFor best performance, the main processor should not check for the invariant reply immediately.Rather, check when the next invariant is reached, so to give time for verification.Then the read is done, and execution is rolled back or continued as appropriate.

  • TidbitsThe message passing mechanism took time to understand.We found we could use the asm directive in gcc so hand modification of assembly was minimized.We encountered a couple bugs in SimpleScalar.

  • Future WorkAdditional logic for floating point registers, easily extended from what we have now.Memory rollback logic; this is more substantial, for we need to retire memory writes only on invariant confirmation.A program to generate the verifying program automatically.

  • ThoughtsSeems like this is an energy intensive method of verification.Invariants are not easy to generate, and must be done by hand.There is a large amount of processing overhead.

  • SummaryDecreasing feature size makes verification necessary.DIVA is on attempt to address the problem.We wrote programs for SimpleScalar.This showed that we can have one processor verify another with invariants.

  • AcknowledgementMark Whitney:Our work is based on the SimpleScalar multiprocessing extension, written by him.He also helped us configure SimpleScalar and fixed bugs.