1 / 28

An Automata-Theoretic Approach to Hardware/Software Co-verification

An Automata-Theoretic Approach to Hardware/Software Co-verification. Thomas Ball Microsoft Research Joint work with Juncao Li and Fei Xie Dept. of Computer Science, Portland State University Vladimir Levin and Con McGarvey Microsoft Corporation.

gitano
Download Presentation

An Automata-Theoretic Approach to Hardware/Software Co-verification

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. An Automata-Theoretic Approach to Hardware/Software Co-verification Thomas Ball Microsoft Research Joint work with Juncao Li and Fei Xie Dept. of Computer Science, Portland State University Vladimir Levin and Con McGarvey Microsoft Corporation

  2. Hardware/Software (HW/SW) Interfaces are Pervasive… • Windows XP • Over 35,000 drivers (over 100,000 versions) for different devices (Murphy and Garzia, 2004) • Linux • 70% of code for drivers that operate hardware (Chou, et al., 2001)

  3. And Unreliable… • In Windows • Drivers cause 85% reported failures • (Swift, 2005) • At least 52.6% of Windows crashes involve HW/SW interaction • (Sinha, 2005) • In Linux • Seven times more driver failures • (Chou, et al., 2001) • Lots of failures cannot be gathered …

  4. Challenges • Effective formal specification framework • Describe the HW/SW system • Easy to understand • Unifying formal model for co-verification • Hardware and software are different • Use different formal representations

  5. The Plan (I) Co-specification • Specify HW/SW system Formal Model • Büchi Pushdown System Model Checking

  6. Co-specification for Driver/Device • Driver implementation • to be verified • Low-priority dispatch routines • High-priority Interrupt Service Routines (ISR)

  7. A Hardware Model • Specified using Verilog semantics • Popular to hardware engineers • Non-blocking assignment • Atomicity in register state changes • A hardware model has • States described by registers • Initial states given by the initialization task • State transitions specified in Transaction Level Modeling (TLM)

  8. begin hardware model // declare registers for hardware states reg [7:0] PortA, IntConfg; …… initial random; // a task that assigns non-deterministic values to registers if ( rand(0,1) ) begin // model the hardware behavior // low level triggers the interrupt if( (IntConfg == 8’h04) && ((PortA & 8’h01)==0) ) begin IntStatus <= 1; // set the interrupt status register INTR <= 1; // set the interrupt pending status to notify software end …… end else begin // simulate inputs from the environment // non-deterministically input to PortA if ( rand(0,1) ) PortA <= rand(8’h0, 8’hFF); ........ end end hardware model

  9. HW/SW Interface WRITE_REGISTER_UCHAR(foo, 32)

  10. Software to Hardware Interaction // Intermediate code that relates the read/write register function calls // to hardware state transitions UCHAR READ_REGISTER_UCHAR( PUCHAR register ) { switch ( register ) { case REG_PORTA: return ReadPortA(); case REG_PORTB: return ReadPortB(); case REG_PORTC: return ReadPortC(); …… case REG_STATUS: return ReadIntStatus(); return; default: RegAddressMismatch(); return; } }

  11. Software Event Triggering Hardware State Transitions __atomic UCHAR ReadIntStatus( ) { // clear the interrupt status when read reg [7:0] retreg; retreg <= IntStatus; IntStatus <= 0; // return the register value to software return retreg; }

  12. The Plan (II) • BPDS = BA ˣ LPDS • Represent concurrent • executions • Allow both HW and • SW models to be • Asynchronous • Synchronous Co-specification Formal Model • Büchi Pushdown System Model Checking

  13. Büchi Automaton (BA) • A BA, • , the alphabet • , the finite set of states • , the set of state transitions • , the initial state • , the set of final states • The alphabet is defined on the states of PDS • PDS is the generatorof inputs to the BA WRITE_REGISTER_UCHAR(foo, 32)

  14. Pushdown System (PDS) • A PDS, • , finite set of global states • , finite stack alphabet • , • , initial configuration • PDS doesn’t take any inputs • need to synchronize the PDS and BA …

  15. Labeled PDS (LPDS) • We extend the PDS as • , the input alphabet • So the set of transition rules is • Now we can use our LPDS as a recognizer

  16. Labeling Functions

  17. The Plan (III) Co-specification Formal model • Büchi Pushdown System Model Checking • Verify BPDS model using • existing model checker

  18. Co-verification Tool (CoVer) Driver Code Hardware Interface Model Abstraction Tool BPDS Model BPDS2PDS PDS Model Moped Model Checker Yes/No

  19. Evaluation • Applied our approach to • an OSR Windows sample driver for a PCI device, and • the hardware interface model of the device • Found one previously undiscovered driver bug • A device driver architect has confirmed our finding • Designed a test benchmark for our model-checking algorithm

  20. Conclusion • Our approach to co-verification • Co-specification • Co-verification model, BPDS • Evaluation has shown that our approach • can detect sophisticated bugs • is promising in improving the reliability of HW/SW interface implementations

More Related