Verifying architecture
Sponsored Links
This presentation is the property of its rightful owner.
1 / 21

Verifying Architecture PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Verifying Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Verifying architecture

  • 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

  • Type in action items as they come up

  • Click OK to dismiss this box

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

Verifying Architecture

Jaein Jeong

Johnathon Jamison



  • Processors 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

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.



  • We 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

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 structure

System Structure

  • Implemented 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

System Structure (Cont.)

Programming for simplescalar

Programming for SimpleScalar

  • Since 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

Programming for SimpleScalar (Cont.)

  • addiu $2,$0,258 la $4,MQO subu $5,$16,4 move $6,$0 syscallWriting a message to a queue

  • $L2: addiu $2,$0,259 la $4,MQI addu $5,$sp,16 move $6,$0 syscall bne $7,$0,$L2Reading a message from a queue.

Programming interface for c

Programming interface for C

  • Assembly 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 example

Multiprocessor Program Example

long 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 1 st method

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 2 nd method

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

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 invariants

Using Invariants

  • We 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 program

  • We hope to automate some of this.



  • For 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.



  • The 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 work

Future Work

  • Additional 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.



  • Seems 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.



  • Decreasing 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.



  • Mark Whitney:

    • Our work is based on the SimpleScalar multiprocessing extension, written by him.

    • He also helped us configure SimpleScalar and fixed bugs.

  • Login