Me3D: A Model-driven Methodology Expediting Embedded Device Driver Development

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



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



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)


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


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


Various and interrelated sources of information

Device driver generation is intrinsically complex

OutlineOutline


oo Device driver overviewDevice driver overview

Related workRelated 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


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


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


OutlineOutline




D i d i ti i tD i d i ti i tDevice driver generation environmentDevice driver generation environment





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


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)


( 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


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


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


Device driver generation (step by step)Device driver generation (step by step)Device driver generation environmentDevice driver generation environment

Step 3: Driver source & Makefilegeneration


OutlineOutline





EvaluationEvaluationEvaluationEvaluation




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


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


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


Driver configuration parameters: synchronizationmechanism, …

ConversionConversionEvaluationEvaluation

Conversion step 2:MCI device featuresgeneration

Conversion step 1:Macros & inline functionsgeneration generationgeneration


Conversion (cont.)Conversion (cont.)EvaluationEvaluation

Conversion step 3.1: Synthesize EFSM & derive driverfunctionalities

C i t 3 2 G t M k fil


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


0

w/o Me3D w/ Me3D2200

SLOC

OutlineOutline










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


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

Me3D: A Model-driven Methodology Expediting Embedded Device Driver Development

Technology

Transcript of Me3D: A Model-driven Methodology Expediting Embedded Device Driver Development