me3d: a model-driven methodology expediting embedded device driver development
TRANSCRIPT
Me3D: A ModelMe3D: A Model--driven Methodology driven Methodology Expediting Embedded Device Expediting Embedded Device Expediting Embedded Device Expediting Embedded Device
Driver DevelopmentDriver 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
Device driver contextDevice driver context
Considerable time & effort for the SW development in atypical 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 devicedriver generation
RSP 2011 2TIMA Laboratory
OutlineOutline
Device driver contextDevice driver context
Device driver overviewDevice driver overview
Related workRelated work
D i d i ti i tD i d i ti i tDevice driver generation environmentDevice driver generation environment
EvaluationEvaluationEvaluationEvaluation
Conclusion and future workConclusion and future work
RSP 2011 3TIMA Laboratory
Conclusion and future workConclusion and future work
OutlineOutline
oo Device driver contextDevice driver context
Device driver overviewDevice driver overview
oo Related workRelated work
D i d i ti i tD i d i ti i too Device driver generation environmentDevice driver generation environment
oo EvaluationEvaluationoo EvaluationEvaluation
oo Conclusion and future workConclusion and future work
RSP 2011 4TIMA Laboratory
oo Conclusion and future workConclusion and future work
Device driver interaction in lowDevice driver interaction in low--level SWlevel SW
Device driver: a low-level component in the OS, whichallows upper-level SW to interact with the device
Device/hardware device: a specific HW resource for a dedicated task
Interactions:
a) Kernel
APPLICATION
APPLICATION PROGRMMING INTERFACE a) Kernel
b) User
c) Libraries
LIBRARIE
S
c)KERNELDRIVER
DRIVER
DRIVER
b)
a)OS
d) HAL (Hardware abstraction layer) I/FHARDWARE ABSTRACTION LAYER
LHAL INTERFACE
d)
RSP 2011 5TIMA Laboratory
HARDWARE
Device driver roleDevice driver role
Implements an interface to the kernel for an underlying device
Requires kernel services, and often also offers services toother kernel components
P id l l l i ti h l t th Provides a lower-level communication channel to the device
Acts as a translator from the kernel to the HW interfaceActs as a translator from the kernel to the HW interface
RSP 2011 6TIMA Laboratory
Device driver complexityDevice driver complexity
Device driver entry pointsreturn_type entry_a_name(…) {
static inline uint32_t registerA_bitfieldX_rd() {return <read primitive> (IO_BASE REGISTER A OFFSET) &1 4…
<kernel memory allocation>…access_hardware(…); void access_hardware(…) {
i B bi fi ldY ($VAL)
+ REGISTER_A_OFFSET) &BIT_FIELD_X_MASK;}
62
15
access_hardware(…);
4
…}
return_type entry_b_name(…) {
registerB_bitfieldY_wr($VAL);…$VAL2 = registerA_bitfieldX_rd();
} 3…strcpy(…);…<create MMC card>
1
2
5
6
7
Device‐related
Platform‐relatedKernel‐driver interface
De ice feat res C library related3
7Kernel service
Various and interrelated sources of information
…} 4
7
8
Device‐features
HAL‐related
C library‐related3
Device class‐related8
RSP 2011 7TIMA Laboratory
Various and interrelated sources of information
Device driver generation is intrinsically complex
OutlineOutline
oo Device driver contextDevice driver context
oo Device driver overviewDevice driver overview
Related workRelated work
D i d i ti i tD i d i ti i too Device driver generation environmentDevice driver generation environment
oo EvaluationEvaluationoo EvaluationEvaluation
oo Conclusion and future workConclusion and future work
RSP 2011 8TIMA Laboratory
oo Conclusion and future workConclusion and future work
Device driver synthesis methodologiesDevice driver synthesis methodologies
Tool for synthesizingembedded device drivers(Princeton U )
Device driver synthesiswith Termite (NICTA /U of New South Wales)(Princeton U.) U. of New South Wales)
Devicespecification
Core Genvi
ce
cation
specification
Device-classspecification
Termite.c
Gen
Dev
spec
ific
Core functions (.c)Virtual
environment specification
OSspecification
Device driverMapper
Targetenvironment(library etc.)iv
erura
tion
specification( y )
Dri
configu
.c Device driver
RSP 2011 9TIMA Laboratory
Device driver generation methodologyDevice driver generation methodology
Device driver generation based on the RTL test bench ofan IP (Polytechnic U. of Turin & U. of Verona)
Devicecardinality
Test bench (RTL)
CPU modelCPU model
I/O memory
Device drivergeneration
Device drivers
.c
specification drivers
RSP 2011 10TIMA Laboratory
Other related workOther related work
Device interface languages: offer some constructs todescribe device interface
o Laddie: generates register access functions
o NDL: a new way to write the device drivers, but not for legacy oneslegacy ones
Hardware specification languages: able to describesome parts of electronic components & designssome parts of electronic components & designs
o UML MARTE: widely used
o IP-XACT: IEEE standard describes o IP XACT: IEEE standard, describes …
structural information about HW devices & designs
some contents, e.g., a register map
RSP 2011 11TIMA Laboratory
OutlineOutline
oo Device driver contextDevice driver context
oo Device driver overviewDevice driver overview
oo Related workRelated work
D i d i ti i tD i d i ti i tDevice driver generation environmentDevice driver generation environment
oo EvaluationEvaluationoo EvaluationEvaluation
oo Conclusion and future workConclusion and future work
RSP 2011 12TIMA Laboratory
oo Conclusion and future workConclusion and future work
Specification of device driver generationSpecification of device driver generationDevice driver generation environmentDevice driver generation environment
Objective: to help device driver development
Inputsp
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
RSP 2011 13TIMA Laboratory
Methodology and inputsMethodology and inputsDevice driver generation environmentDevice driver generation environment
Abstract view of the Me3D methodology
Device FeaturesHardware In-Kernel Interface ModelSpecifications Specification
Driver Configuration P t LibrariesDevice Driver GenerationParameters Libraries
Validation
Device Driver Generation
Is used byProducesDevice driver
HW specifications (e.g., in IP-XACT, UML MARTE)
D i ifi i ( )o Device specification(s)
o Platform specificationProcessor (e.g., byte ordering)
RSP 2011 14TIMA Laboratory
( g , y g)
Device instantiations, I/O offsets, …
InputsInputsDevice driver generation environmentDevice driver generation environment
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 specificationp
o Contains mainly kernel data structures (if any) to be used, software events, & transitions
S f f / h k lo Software events: messages from/to the kernel
o Transitions: define the driver's desired reactions to requests
RSP 2011 15TIMA Laboratory
Inputs (cont.)Inputs (cont.)Device driver generation environmentDevice driver generation environment
Libraries
o HAL library: low-level HW access primitives
o Basic library: an abstract layer for usual
Lib X
Basic LibraryStrCpy = (Newlib) “strcpy” + “…”y
data manipulationmethods
Lib XLib YLib Z
StrCpy = (uClibc) “strcpy” + “…”
StrCpy = “dna_strcpy” + “…”
Driver configurationparameters
D i d i d l t d i i ki o Device driver development: decision-making processes
o High-level configuration parameters: to efficiently & effectively explore the device driver design space
RSP 2011 16TIMA Laboratory
Device driver generation (step by step)Device driver generation (step by step)Device driver generation environmentDevice driver generation environment
Step 1: Parsing & inlinefunctions generation
Step 2: Device features generation
RSP 2011 17TIMA Laboratory
Device driver generation (step by step)Device driver generation (step by step)Device driver generation environmentDevice driver generation environment
Step 3: Driver source & Makefilegeneration
RSP 2011 18TIMA Laboratory
OutlineOutline
oo Device driver contextDevice driver context
oo Device driver overviewDevice driver overview
oo Related workRelated work
D i d i ti i tD i d i ti i too Device driver generation environmentDevice driver generation environment
EvaluationEvaluationEvaluationEvaluation
oo Conclusion and future workConclusion and future work
RSP 2011 19TIMA Laboratory
oo Conclusion and future workConclusion and future work
EvaluationEvaluation
Evaluation points
1. Feasibility of describing device features & in-kernel I/F
2. Device FeaturesModel
Hardware Specifications
In-Kernel Interface Specification
Driver Configuration Parameters LibrariesDevice Driver Generation?
Device driver
o To evaluate point 1: specified HW devices & platform ino To evaluate point 1: specified HW devices & platform inIP-XACT, in-kernel interfaces with in-house IISL, device features with DFDL
o To evaluate point 2: manual conversion according to the
RSP 2011 20TIMA Laboratory
o To evaluate point 2: manual conversion according to the proposed methodology
Case study and inputsCase study and inputsEvaluationEvaluation
Case study: MCI device driver for the ATMEL D940 MPSoC
o MCI device and its neighborhood:
Hardware specificationso Device specifications for MCI PMC & PIO
RSP 2011 21TIMA Laboratory
o Device specifications for MCI, PMC, & PIOo Platform specification: only necessary parts modeled
InputsInputsEvaluationEvaluation
MCI device features model: in DFDL, which has someconstructs tailored for modeling device features
In-kernel interface specification: with our in-houselanguage IISLo In-kernel interfaces for the MCI drivero In kernel interfaces for the MCI driver
Driver configuration parameters: synchronization
RSP 2011 22TIMA Laboratory
Driver configuration parameters: synchronizationmechanism, …
ConversionConversionEvaluationEvaluation
Conversion step 2:MCI device featuresgeneration
Conversion step 1:Macros & inline functionsgeneration generationgeneration
RSP 2011 23TIMA Laboratory
Conversion (cont.)Conversion (cont.)EvaluationEvaluation
Conversion step 3.1: Synthesize EFSM & derive driverfunctionalities
C i t 3 2 G t M k fil
RSP 2011 24TIMA Laboratory
Conversion step 3.2: Generate Makefile
Conversion resultsConversion resultsEvaluationEvaluation
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/ Me3DP d
20
30Device features model
In‐kernel interface specification
Person‐days
3000
3200
10
20Platform specification
Device specifications2400
2600
2800
RSP 2011 25TIMA Laboratory
0
w/o Me3D w/ Me3D2200
SLOC
OutlineOutline
oo Device driver contextDevice driver context
oo Device driver overviewDevice driver overview
oo Related workRelated work
D i d i ti i tD i d i ti i too Device driver generation environmentDevice driver generation environment
oo EvaluationEvaluationoo EvaluationEvaluation
Conclusion and future workConclusion and future work
RSP 2011 26TIMA Laboratory
Conclusion and future workConclusion and future work
Conclusion and future workConclusion 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 driverOutput: 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 & l dvalidation
o Develop a tool for fully automatic device driver generation
o Verify device drivers by symbolic execution (in cooperation
RSP 2011 27TIMA Laboratory
o Verify device drivers by symbolic execution (in cooperation with NICTA)
Thank youThank youThank youThank youfor your attention!for your attention!Me3D: A Model-driven Methodology Expediting
for your attention!for your attention!Me3D: A Model driven Methodology Expediting
Embedded Device Driver Development
H i Ch G ill G d B F édé i R F édé i PéHui Chen, Guillaume Godet-Bar, Frédéric Rousseau, Frédéric Pétrot
TIMA Laboratory (CNRS – Grenoble INP – UJF) - France
22nd IEEE International Symposium on Rapid System Prototyping
27/05/2011