formalizing hardware/software interface specifications juncao li microsoft corporation joint work...
TRANSCRIPT
Formalizing Formalizing Hardware/Software Hardware/Software Interface SpecificationsInterface Specifications
Juncao LiMicrosoft Corporation
Joint work with
Fei Xie
Dept. of Computer Science, Portland State University
Thomas Ball, Vladimir Levin and Con McGarvey
Microsoft Corporation
Why?Why?Computer systems are pervasive
◦ One billion PCs had been sold by 2002 (cf. Wikipedia)
Hardware (HW) and software (SW) are often manufactured separately◦ Intel, HP, Microsoft, …
Dependencies between HW and SW induce product risks ◦ Product quality affected by HW/SW interface issues◦ Long product cycle◦ Compatibility/sustainability issues
Design HW/SW Interface
protocol
Draft English Document
Manual proofreading
Issues detected
DesignStage
DevelopmentStage
Published English Document
In-house testing
Develop devicesor driversDevices or drivers
Failed
Post-releaseStage
Released products
Certification:Conformance testing
Passed
Passed
Failed
Ship the product
Device Prototype
Software to Hardware Software to Hardware DependencyDependency
English Document Device Driver
Bugs, interface inconsistencies …
Long product cycle!
Our SolutionOur SolutionSynthesize a unified formal representation
◦ Hardware formally as Büchi Automaton (BA)◦ Software formally as Labeled Pushdown System (LPDS)◦ HW/SW interface: formally as
Büchi Pushdown System (BPDS) = BA × LPDS
Specification of HW/SW interface protocols◦ In a C-like language (modelC)◦ Map such specification to BPDS
Validation techniques based on the specification
◦ Co-verification, co-simulation, conformance testing, etc.◦ Where the specification is used as test harnesses/golden
models
Where are we …Where are we …
IntroductionPreliminariesSpecificationApplicationEvaluationConclusion
Büchi Automaton (BA)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
Acceptance condition on an input string◦ Visits at least one of the final states infinitely
often The alphabet is defined on the states of
LPDS◦ LPDS is the generator of the inputs to BA
),,,,( 0 FqQΒ Q
0q
F
WRITE_REGISTER_UCHAR(foo, 32)
Labeled Pushdown System Labeled Pushdown System (LPDS)(LPDS)
A LPDS,◦ , the input alphabet ◦ , the finite set of states◦ , the finite stack alphabet◦ , set of
transition rules
◦ , the initial configuration
G
00 ,g
),,,,,( 00 gGIPI
*)()( GIG
Device/Driver StackDevice/Driver Stack
Function driver (e.g., mouse, network card)
Function device (e.g., mouse, network card)
ISR DDI
Software
Hardware
Bus driver (e.g., PCI, USB)
Bus device (e.g., PCI, USB)
Intermediate software layers
Intermediate hardware layers
ISR DDI
ISR (Interrupt Service Routine) DDI (Device Driver Interface)
Interrupt Signal
Interrupt Signal
Interrupt Signal
Where are we …Where are we …
IntroductionPreliminariesSpecificationApplicationEvaluationConclusion
Specifying HW/SW Interface Specifying HW/SW Interface Protocols Protocols
HardwareModel
Dispatch Routines
HW/SW Interface
ISR
Software Model
• Software model is composed of – Low-priority dispatch routines– High-priority Interrupt Service Routines (ISRs)
BA
LPDS
Two Key Concepts for Hardware Two Key Concepts for Hardware ModelingModeling
Hardware Transaction
Relative Atomicity
Hardware TransactionHardware TransactionTransaction-level Modeling (TLM)
◦ Implementation details are abstracted away into high-level designs
Hardware Transaction◦ A hardware state transition◦ Arbitrary long but finite sequence of clock-
cyclesHardware Transaction Function
◦ A C (modelC) function for a set of state transitions
◦ Current state: state at the function entry◦ Next state: state at the function exit
Relative AtomicityRelative AtomicityModel the concurrencies
◦inside hardware◦between hardware and software
Two key ideas◦Hardware transactions are atomic in
the view of software◦ISRs are atomic to other lower-
priority software routines
Hardware (Formal) ModelHardware (Formal) Model
HardwareModel
Dispatch Routines
HW/SW Interface
ISR
Software Model
• A transaction-level model• Describes the desired hardware behavior
– When hardware and software are asynchronous
BA
A Hardware ModelA Hardware Model// The transaction function of // the PIO-24 device model__atomic VOID atRun_DIO() { // non-deterministic choices switch ( choice() ) {
// Update the port output case 0: RunPorts(); break;
// Interrupt management case 1: RunInterrupt(); break;
…… }}
• The hardware model has– states as global variables – Initial states given by the
initialization function– State transitions by the
transaction functions
• Concurrency inside HW– Non-deterministic interleaving
VOID RunInterrupt( ) { // Interrupt management
if(g_DIORegs.IRQ.IRQENn == 0) { // if the interrupt is not enabled goto Exit; } if(g_DIORegs.CW.CWD4 != 1) { // If Port A is not configured as input goto Exit; } ……
if(g_DIORegs.IRQ.IRQCn == 0) { // Low level fires an interrupt if(g_DIORegs.A.D0 == 0) g_DIORegs.IRQST.IRQST1 = 1; } else { …… }
Exit: return;}
Software (Formal) ModelSoftware (Formal) Model
HardwareModel
Dispatch Routines
HW/SW Interface
ISR
Software Model
• Specify the desired operation sequences for software to control hardware
LPDS
Software Output to Port A Software Output to Port A // software operations on outputting to Port A VOID Output2PortA ( UCHAR data ) { // write to Port A WRITE_REGISTER_UCHAR(REG_PORTA, data);
// If Port A is configured as “input”, set it as “output” if ( g_SWState.CW.CWD4 == 1 ) { // software should maintain the I/O status of all ports g_SWState.CW.CWD4 == 0; WRITE_REGISTER_UCHAR(REG_CONFIG,
g_SWState.CW.WholeByte); }}
HW/SW InterfaceHW/SW InterfaceWRITE_REGISTER_UCHAR(foo, 32)
foo = 32;
Interrupts
HardwareModel
Dispatch Routines
HW/SW Interface
ISR
Software Model
• In this use of our BPDS, interactions between hardware and software interface transitions are synchonous
BA consists of Part of the BA consists of Part of the HW/SW InterfaceHW/SW Interface
HW FormalModel
Dispatch Routines
HW/SW Interface
ISR
Driver
BA
• We need to describe the HW/SW interface portion for BA
LPDS Consists of Another LPDS Consists of Another Part of the HW/SW InterfacePart of the HW/SW Interface
HW FormalModel
Dispatch Routines
HW/SW Interface
ISR
Driver
• We need to describe the HW/SW interface portion for LPDS
LPDS
BA
Software to Hardware Software to Hardware InteractionInteraction
// Intermediate code that connects the read/write register function calls // with the hardware interface registersVOID WRITE_REGISTER_UCHAR ( PUCHAR register, UCHAR data ) { switch ( register ) { case REG_PORTA: atWritePortA(data); return; case REG_PORTB: atWritePortB(data); return; case REG_PORTC: atWritePortC(data); return;
…… case REG_STATUS: atWriteStatus(); return; default: RegAddressMismatch(); return; }}
Software Event Triggering a Software Event Triggering a Hardware Transaction Hardware Transaction FunctionFunction
__atomic VOID atWritePortA( UCHAR ucRegData ) {
// If Port A is configured as an “input” port if (g_DIORegs.CW.CWD4 == 1) { // Write to the output register instead of the port g_DIOState.OutputRegA.ucValue = ucRegData;
} else { // Otherwise, configured as an “output” port // Update both the port and the output register g_DIORegs.A.ucValue = ucRegData; g_DIOState.OutputRegA.ucValue = ucRegData; }
}
Hardware Event Triggering Hardware Event Triggering Software TransitionsSoftware Transitions
// Invoked the ISR if an interrupt has been firedVOID RunIsr ( ) { __atomic { // check/prepare the precondition before invoking the ISR if ( (IsrRunning == TRUE) || (InterruptPending == FALSE) ) return; IsrRunning = TRUE; }
DioIsr(); // Invoke the ISR
__atomic { // set both the hardware and software to proper status after ISR. IsrRunning = FALSE; InterruptPending = FALSE; }}
Execution Semantics of Relative Execution Semantics of Relative AtomicityAtomicity
// software operations on outputting to Port A VOID Output2PortA ( UCHAR data ) { // write to Port A WRITE_REGISTER_UCHAR(REG_PORTA, data);
// If Port A is configured as “input”, set it as “output” if ( g_SWState.CW.CWD4 == 1 ) { // software should maintain the I/O status of all ports g_SWState.CW.CWD4 == 0; WRITE_REGISTER_UCHAR(REG_CONFIG,
g_SWState.CW.WholeByte); }}
while ( choice() ){ atRun_DIO(); RunIsr();}
Where are we …Where are we …
IntroductionPreliminariesSpecificationApplicationEvaluationConclusion
Design HW/SW Interface
protocol
Draft English Document
Manual proofreading
Issues detected
DesignStage
DevelopmentStage
Published English Document
In-house testing
Develop devicesor driversDevices or drivers
Failed
Post-releaseStage
Released products
Certification:Conformance testing
Passed
Passed
Failed
Ship the product
Where are we …Where are we …
IntroductionPreliminariesSpecificationApplicationEvaluationConclusion
Summary of Formal Summary of Formal SpecificationSpecificationSpecified four HW/SW interface
protocols◦ Formal Device Model and Formal Driver
Model
Discovered fifteen specification issues ◦ in English documents that have existed for
years
Some of the issues was even found in protocol pseudo code
Co-verification: Use Formal Co-verification: Use Formal Models as the HarnessModels as the HarnessApplied to five Windows drivers
◦ Open Systems Resources (OSR) drivers◦ Microsoft drivers
Proved twenty four properties
Discovered twelve unknown bugs◦ Bugs were found in every driver◦ Could cause data loss, interrupt storm, etc.
Bug SummaryBug SummaryAll bugs
◦ involve interactions between driver and deviceOne bug happens
◦ when driver does not initialize device correctly
Three bugs happen ◦ when device interrupts driver
Four bugs are due to ◦ the out-of-synchronization of driver and
deviceFour bugs happen
◦ when driver mishandles device failures
Where are we …Where are we …
IntroductionPreliminariesSpecificationApplicationEvaluationConclusion
Conclusion and Future Conclusion and Future WorkWorkWe have
Presented an approach to formally specify HW/SW interface protocols
Applied our approach to industry practice
Evaluation result is promisingDiscovered many specification issuesDiscovered many driver bugs
Future workCo-simulationConformance testing
Thanks!
New Device Prototype
Hardware to Software Hardware to Software DependencyDependency
English Document
Incompatibilities
Compatibility/sustainability issues!
ExistingDevice Driver Stack