Upload
gitano
View
47
Download
0
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
An Automata-Theoretic Approach to Hardware/Software Co-verification
Thomas BallMicrosoft Research
Joint work withJuncao Li and Fei XieDept. of Computer Science, Portland State UniversityVladimir Levin and Con McGarveyMicrosoft Corporation
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)
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 …
ChallengesEffective formal specification
frameworkDescribe the HW/SW system Easy to understand
Unifying formal model for co-verificationHardware and software are
differentUse different formal
representations
The Plan (I)
Co-specification
Model Checking
Formal ModelBüchi Pushdown System
Specify HW/SW system
Co-specification for Driver/Device
Driver implementation• to be verified• Low-priority dispatch
routines• High-priority Interrupt
Service Routines (ISR)
A Hardware ModelSpecified using Verilog semantics
Popular to hardware engineersNon-blocking assignment
Atomicity in register state changes
A hardware model hasStates described by registers Initial states given by the initialization taskState transitions specified in Transaction
Level Modeling (TLM)
10
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
HW/SW Interface
WRITE_REGISTER_UCHAR(foo, 32)
Software to Hardware Interaction
// Intermediate code that relates the read/write register function calls // to hardware state transitionsUCHAR 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; }}
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;}
The Plan (II)
Co-specification
Model Checking
Formal ModelBüchi Pushdown System
BPDS = BA ˣ LPDS• Represent concurrent
executions • Allow both HW and
SW models to be• Asynchronous• Synchronous
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 generator of inputs to the BA
),,,,( 0 FqQΒ Q
0qF
WRITE_REGISTER_UCHAR(foo, 32)
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
…
),,,,( 00 gGPG
*)()( GG
00 ,g
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
),,,,,( 00 gGIP
*)()( GIG
Labeling Functions
The Plan (III)
Co-specification
Model Checking
Formal modelBüchi Pushdown System
Verify BPDS model using existing model checker
Yes/No
Co-verification Tool (CoVer)
Hardware Interface
ModelDriver Code
Abstraction
Tool
BPDS Model
BPDS2PDS
PDS Model
MopedModel
Checker
EvaluationApplied 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
ConclusionOur 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