1. Formalizing Hardware/Software Interface Specifications
Juncao Li
Microsoft Corporation
Joint work with
Fei Xie
Dept. of Computer Science, Portland State University
Thomas Ball, Vladimir Levin and Con McGarvey

2. 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

3. Design Stage Development Stage Post-release Stage Issues detected
HW/SW Interface
protocol
Manual proof
reading
Draft English
Document
Design
Stage
Passed
Devices or drivers
Develop devices
or drivers
Published English
Document
Failed
In-house testing
Development
Stage
Passed
Here is an example how HW/SW systems are designed, the English document is used in every stage.
Stage 1. when the HW/SW interface protocols are designed, English document is used between different initiator companies. They have to proof-read the document to check the correctness of it. There is no automatic tools can be applied.
Stage 2. During the development stage, HW/SW systems in various companies are developed based on the same English document. We can imagine one document issues can cause how much confusions and bugs.
Stage 3. During the certification stage, the certification testing cases are developed based on the same English document.
Released products
Failed
Certification:
Conformance testing
Post-release
Stage
Ship the product

4. Long product cycle! Software to Hardware Dependency English Document
Device
Prototype
Device Driver
Bugs, interface inconsistencies …
Long product cycle!

5. Our Solution Synthesize 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
modelC Language is actually …

6. Introduction Preliminaries Specification Where are we … Application
Evaluation
Conclusion
Next, we would like to introduce the preliminaries of our work.

7. Büchi Automaton (BA) A BA, Acceptance condition on an input string
, 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
WRITE_REGISTER_UCHAR(foo, 32)
B accepts an infinite input string if and only if it has a run over the string that visits at least one of the final states infinitely often.
The alphabet of BA is defined as a power set of the set of propositions that may hold on the states of LPDS

8. Labeled Pushdown System (LPDS)
A LPDS,
, the input alphabet
, the finite set of states
, the finite stack alphabet
, set of transition rules
, the initial configuration
Say what global state is …
y and w is not the same, …
What a transition rule does is to modify the global states and replace the top of the stack with a string a symbols from the stack alphabet

9. Device/Driver Stack Function driver (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 (Interrupt Service Routine)
DDI (Device Driver Interface)
Interrupt
Signal
Function driver (e.g., mouse, network card)
(Read through the text on the slide would be fine.)
Function device (e.g., mouse, network card)

10. Introduction Preliminaries Specification Where are we … Application
Evaluation
Conclusion
Next, we would like to introduce the preliminaries of our work.

11. Specifying HW/SW Interface Protocols
Software Model
Dispatch Routines
Hardware
Model
HW/SW Interface
ISR BA
I did some thing similar to DSF, I use the actual driver instead of a model of the driver.
We apply our approach to the co-verification of device driver implementations with their device models
I will give the definition of synchronous and asynchronous transition later
LPDS
Software model is composed of
Low-priority dispatch routines
High-priority Interrupt Service Routines (ISRs)

12. Two Key Concepts for Hardware Modeling
Hardware Transaction
Relative Atomicity

13. Hardware Transaction Transaction-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-cycles
Hardware 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
Hardware transaction function: because we want to specify the hardware transaction using some programming language we are familiar with.

14. Relative Atomicity Model the concurrencies Two key ideas
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

15. Hardware (Formal) Model
Software Model
Dispatch Routines
Hardware
Model
HW/SW Interface
ISR BA
A transaction-level model
Describes the desired hardware behavior
When hardware and software are asynchronous

16. A Hardware Model The hardware model has Concurrency inside HW
states as global variables
Initial states given by the initialization function
State transitions by the transaction functions
Concurrency inside HW
Non-deterministic interleaving
// 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; …… }

17. 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 ……
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;

18. Software (Formal) Model
Software Model
Dispatch Routines
Hardware
Model
HW/SW Interface
ISR
LPDS
Specify the desired operation sequences for software to control hardware

19. 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); }

20. HW/SW Interface
WRITE_REGISTER_UCHAR(foo, 32)
Software Model
foo = 32;
Dispatch Routines
Hardware
Model
HW/SW Interface
ISR
Response the interrupt in a timely fashion
Interrupts
In this use of our BPDS, interactions between hardware and software interface transitions are synchonous

21. BA consists of Part of the HW/SW Interface
Driver
Dispatch Routines
HW Formal
Model
HW/SW Interface
ISR BA
I did some thing similar to DSF, I use the actual driver instead of a model of the driver.
We apply our approach to the co-verification of device driver implementations with their device models
I will give the definition of synchronous and asynchronous transition later
We need to describe the HW/SW interface portion for BA

22. LPDS Consists of Another Part of the HW/SW Interface
Driver
Dispatch Routines
HW Formal
Model
HW/SW Interface
ISR BA
I did some thing similar to DSF, I use the actual driver instead of a model of the driver.
We apply our approach to the co-verification of device driver implementations with their device models
I will give the definition of synchronous and asynchronous transition later
LPDS
We need to describe the HW/SW interface portion for LPDS

23. Software to Hardware Interaction
// Intermediate code that connects the read/write register function calls
// with the hardware interface registers
VOID 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; }

24. Software Event Triggering a Hardware Transaction Function
__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; }
Now we are at the Hardware side!

25. Hardware Event Triggering Software Transitions
// Invoked the ISR if an interrupt has been fired
VOID RunIsr ( ) {
__atomic {
// check/prepare the precondition before invoking the ISR
if ( (IsrRunning == TRUE) || (InterruptPending == FALSE) )
return;
IsrRunning = TRUE; }
DioIsr(); // Invoke the ISR
// set both the hardware and software to proper status after ISR.
IsrRunning = FALSE;
InterruptPending = FALSE;

26. Execution Semantics of Relative Atomicity
// 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(); }

27. Introduction Preliminaries Specification Application Where are we …
Evaluation
Conclusion
Next, we would like to introduce the preliminaries of our work.

28. Stage Development Post-release Design HW/SW Interface protocol
Draft English
Document
Manual proof
reading
Issues detected
Stage
Development
Published English
In-house testing
Develop devices
or drivers
Devices or drivers
Failed
Post-release
Released products
Certification:
Conformance testing
Passed
Ship the product
Automatic tool
Formal Specification
Formal Specification
Co-verification
tool
Here is an example how HW/SW systems are designed, the English document is used in every stage.
Stage 1. when the HW/SW interface protocols are designed, English document is used between different initiator companies. They have to proof-read the document to check the correctness of it. There is no automatic tools can be applied.
Stage 2. During the development stage, HW/SW systems in various companies are developed based on the same English document. We can imagine one document issues can cause how much confusions and bugs.
Stage 3. During the certification stage, the certification testing cases are developed based on the same English document.

29. Introduction Preliminaries Specification Application Evaluation
Where are we …
Introduction
Preliminaries
Specification
Application
Evaluation
Conclusion
Next, we would like to introduce the preliminaries of our work.

30. Summary of Formal Specification
Specified 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

31. Co-verification: Use Formal Models as the Harness
Applied 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.

32. Bug Summary All bugs One bug happens Three bugs happen
involve interactions between driver and device
One 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 device
Four bugs happen
when driver mishandles device failures

33. Introduction Preliminaries Specification Application Evaluation
Where are we …
Introduction
Preliminaries
Specification
Application
Evaluation
Conclusion
Next, we would like to introduce the preliminaries of our work.

34. Conclusion and Future Work
We have
Presented an approach to formally specify HW/SW interface protocols
Applied our approach to industry practice
Evaluation result is promising
Discovered many specification issues
Discovered many driver bugs
Future work
Co-simulation
Conformance testing

35. Thanks!

36. Compatibility/sustainability issues!
Hardware to Software Dependency
English
Document
New Device
Prototype
Existing
Device Driver Stack
Imagine we already have a software product existing in the market, e.g., Windows 7. Then, some hardware company wants to design a new hardware prototype that utilizes existing HW/SW interfaces, e.g., USB 2.0. If the device driver stack is 100% percent confirm to the English specification, then no problem. However, there are often deviations …
Incompatibilities
Compatibility/sustainability issues!