1. Me3D: A Model-driven Methodology
Model-
Expediting Embedded Device
Driver Development
Hui Chen, Guillaume Godet-Bar, Frédéric Rousseau, Frédéric Pétrot
TIMA Laboratory (CNRS – Grenoble INP – UJF) - France
{FirstName.LastName}@imag.fr
22nd IEEE International Symposium on Rapid System Prototyping
27/05/2011

2. Device driver context
Considerable time & effort for the SW development in a
typical MPSoC project
o Device driver development: a serious bottleneck
Interdisciplinary knowledge required
Laborious to write
• 19.6 person-years of effort in developing device drivers for the
LH7A404 SoC
Unreliable
• 85% of unexpected Windows stops caused by device drivers
A new methodology to address reliability for device
driver generation
TIMA Laboratory RSP 2011 2

3. Outline
Device driver context
Device driver overview
Related work
Device driver generation environment
D i d i ti i t
Evaluation
Conclusion and future work
TIMA Laboratory RSP 2011 3

4. Outline
o Device driver context
Device driver overview
o Related work
o Device driver generation environment
D i d i ti i t
o Evaluation
o Conclusion and future work
TIMA Laboratory RSP 2011 4

5. Device driver interaction in low-level SW
low-
Device driver: a low-level component in the OS, which
allows upper-level SW to interact with the device
Device/hardware device: a specific HW resource for a
dedicated task
APPLICATION
Interactions:
APPLICATION PROGRMMING INTERFACE a) Kernel
LIBRARIES
b)
b) User
KERNEL DRIVER
OS
a) DRIVER
DRIVER
c) c) Libraries
L
d) d) HAL (Hardware
HAL INTERFACE
abstraction
HARDWARE ABSTRACTION LAYER layer) I/F
HARDWARE
TIMA Laboratory RSP 2011 5

6. Device driver role
Implements an interface to the kernel for an underlying
device
Requires kernel services, and often also offers services to
other kernel components
Provides a l
P id lower-level communication channel t th
l l i ti h l to the
device
Acts as a translator from the kernel to the HW interface
TIMA Laboratory RSP 2011 6

7. Device driver complexity
Device driver entry points
static inline uint32_t registerA_bitfieldX_rd() {
return_type entry_a_name(…) { return <read primitive> (IO_BASE
… 1 4 + REGISTER_A_OFFSET) &
REGISTER A OFFSET) &
<kernel memory allocation> BIT_FIELD_X_MASK;} 5
… 2
access_hardware(…);
access_hardware(…); void access_hardware(…) { 6
… registerB_bitfieldY_wr($VAL);
i B bi fi ldY ($VAL)
} …
$VAL2 = registerA_bitfieldX_rd();
return_type entry_b_name(…) { } 3
…
strcpy(…); 7 1 Kernel‐driver interface 5 Platform‐related
… 2 Kernel service 6 Device‐related
<create MMC card>
… 3 De ice feat res
Device‐features 7 C library related
C library‐related
8
} 4 HAL‐related 8 Device class‐related
Various and interrelated sources of information
Device driver generation is intrinsically complex
TIMA Laboratory RSP 2011 7

8. Outline
o Device driver context
o Device driver overview
Related work
o Device driver generation environment
D i d i ti i t
o Evaluation
o Conclusion and future work
TIMA Laboratory RSP 2011 8

9. Device driver synthesis methodologies
Tool for synthesizing Device driver synthesis
embedded device drivers with Termite (NICTA /
(Princeton U )
U.) U.
U of New South Wales)
cation
Core Device
vice
Gen specification
specific
Dev
Virtual .c
Core functions (.c) Device-class
environment Termite
specification
Device
uration
Target
Mapper environment OS driver
iver
(
(library etc.)
y ) specification
configu
Dri
.c Device
driver
TIMA Laboratory RSP 2011 9

10. Device driver generation methodology
Device driver generation based on the RTL test bench of
an IP (Polytechnic U. of Turin & U. of Verona)
Device Test bench
cardinality (RTL)
CPU model
Device driver .c
generation
I/O memory Device
specification drivers
TIMA Laboratory RSP 2011 10

11. Other related work
Device interface languages: offer some constructs to
describe device interface
o Laddie: generates register access functions
o NDL: a new way to write the device drivers, but not for
legacy ones
Hardware specification languages: able to describe
some parts of electronic components & designs
o UML MARTE: widely used
o IP-XACT: IEEE standard describes …
IP XACT: standard,
structural information about HW devices & designs
some contents, e.g., a register map
TIMA Laboratory RSP 2011 11

12. Outline
o Device driver context
o Device driver overview
o Related work
Device driver generation environment
D i d i ti i t
o Evaluation
o Conclusion and future work
TIMA Laboratory RSP 2011 12

13. Device driver generation environment
Specification of device driver generation
Objective: to help device driver development
p
Inputs
o Hardware specifications
o Device features model
o In-kernel interface specification
o Libraries
o Driver configuration parameters
Output: device driver in C
Validation by execution
TIMA Laboratory RSP 2011 13

14. Device driver generation environment
Methodology and inputs
Abstract view of the Me3D methodology
Hardware Device Features In-Kernel Interface
Specifications Model Specification
Driver Configuration
Device Driver Generation Libraries
Parameters
P t
Is used by
Validation Device driver Produces
HW specifications (e.g., in IP-XACT, UML MARTE)
o D i specification(s)
Device ifi i ( )
o Platform specification
Processor (e.g., byte ordering)
( g, y g)
Device instantiations, I/O offsets, …
TIMA Laboratory RSP 2011 14

15. Device driver generation environment
Inputs
Device features model
o Captures a sequence of
interactions with the HW
o A set of predefined
device features:
init, read, etc.
In-kernel interface specification
p
o Contains mainly kernel data structures (if any) to be
used, software events, & transitions
o S f
Software events: messages f
from/to the kernel
/ h k l
o Transitions: define the driver's desired reactions to requests
TIMA Laboratory RSP 2011 15

16. Device driver generation environment
Inputs (cont.)
Libraries
o HAL library: low-level
HW access primitives
o Basic library: an Basic Library
StrCpy = (Newlib) “strcpy” + “…”
abstract layer for usual
y Lib X
Lib X
data manipulation Lib Y
StrCpy = (uClibc) “strcpy” + “…”
methods Lib Z StrCpy = “dna_strcpy” + “…”
Driver configuration
parameters
o D i driver development: d i i
Device d i d l t decision-making processes
ki
o High-level configuration parameters: to efficiently &
effectively explore the device driver design space
TIMA Laboratory RSP 2011 16

17. Device driver generation environment
Device driver generation (step by step)
Step 1: Parsing & inline
functions generation
Step 2: Device features generation
TIMA Laboratory RSP 2011 17

18. Device driver generation environment
Device driver generation (step by step)
Step 3: Driver source & Makefile
generation
TIMA Laboratory RSP 2011 18

19. Outline
o Device driver context
o Device driver overview
o Related work
o Device driver generation environment
D i d i ti i t
Evaluation
o Conclusion and future work
TIMA Laboratory RSP 2011 19

20. Evaluation
Evaluation points
1. Feasibility of describing device features & in-kernel I/F
2. Hardware Device Features In-Kernel Interface
Specifications Model Specification
Driver Configuration
Parameters
?
Device Driver Generation Libraries
Device driver
o To evaluate point 1: specified HW devices & platform in
IP-XACT, in-kernel interfaces with in-house IISL, device
features with DFDL
o To evaluate point 2: manual conversion according to the
proposed methodology
TIMA Laboratory RSP 2011 20

21. Evaluation
Case study and inputs
Case study: MCI device driver for the ATMEL D940 MPSoC
o MCI device and its neighborhood:
Hardware specifications
o Device specifications for MCI PMC & PIO
MCI, PMC,
o Platform specification: only necessary parts modeled
TIMA Laboratory RSP 2011 21

22. Evaluation
Inputs
MCI device features model: in DFDL, which has some
constructs tailored for modeling device features
In-kernel interface specification: with our in-house
language IISL
o In-kernel interfaces for the MCI driver
In kernel
Driver configuration parameters: synchronization
mechanism, …
TIMA Laboratory RSP 2011 22

23. Evaluation
Conversion
Conversion step 1: Conversion step 2:
Macros & inline functions MCI device features
generation generation
TIMA Laboratory RSP 2011 23

24. Evaluation
Conversion (cont.)
Conversion step 3.1: Synthesize EFSM & derive driver
functionalities
Conversion step 3 2 G
C i t 3.2: Generate M k fil
t Makefile
TIMA Laboratory RSP 2011 24

25. Evaluation
Conversion results
Source lines of code, binary sizes of the native &
generated MCI drivers w/o and w/ Me3D
Efforts for MCI driver development w/o and w/ Me3D
Person‐days
P d
Device features model
30 3200
In‐kernel interface specification 3000
20
Platform specification 2800
10 2600
Device specifications
2400
0 2200
w/o Me3D w/ Me3D SLOC
TIMA Laboratory RSP 2011 25

26. Outline
o Device driver context
o Device driver overview
o Related work
o Device driver generation environment
D i d i ti i t
o Evaluation
Conclusion and future work
TIMA Laboratory RSP 2011 26

27. Conclusion and future work
Conclusion
o Advanced device driver generation environment
Inputs: specifications/model (hardware, device features, in-
kernel interface), libraries, & driver configuration parameters
Output: C file of the device driver
Validation by execution
Future work
o Evaluate the methodology on several OSes
o Introduce an intermediate format for driver generation &
validation
ld
o Develop a tool for fully automatic device driver generation
o Verify device drivers by symbolic execution (in cooperation
with NICTA)
TIMA Laboratory RSP 2011 27

28. Thank you
for your attention!
Me3D: A Model-driven Methodology Expediting
Model driven
Embedded Device Driver Development
Hui Ch
H i Chen, G ill
Guillaume Godet-Bar, F édé i R
G d B Frédéric Rousseau, F édé i Pé
Frédéric Pétrot
TIMA Laboratory (CNRS – Grenoble INP – UJF) - France
22nd IEEE International Symposium on Rapid System Prototyping
27/05/2011