formalizing hardware/software interface specifications juncao li microsoft corporation joint work...

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