Device ofa hardware board. Such a documentation is intended

Device drivers such as upper-level driver stacks in cascadeddrivers may not have direct access to underlying hardware.In the remainder of this paper, it is assumed that a driver isdirectly above the HAL. Device driver in binary format is validated on a realMPSoC or virtual platforms. During the validation phase, performanceresults could be extracted as shown in the referencedpaper 14, for tuning driver configuration parameters. Withmodified parameters, a new version of the driver is generatedagain.A. Basic and HAL librariesThe basic library contains an abstract layer for usual datamanipulation methods (Fig. 4). For instance, the StrCpy (Fig.4) primitive may be linked to the strcpy function of a standardC library implementation, such as Newlib 15 or uClibc 16,or the dna strcpy function of an ad-hoc C library. Introducingthese primitives allows the exploration of memory footprintsand performances through the selection of different C libraryimplementations. The basic library could contain source and/orobject files.The HAL library contains the implementation of low-levelhardware access primitives (e.g., primitive to read from orwrite to registers), with which it allows the development andthe integration of support for new hardware architectures tobe executed separately from the generation tools, thereby increasingthe flexibility of the environment and the re-usabilityof the components. It may include source and/or object files.B. In-kernel interface specificationIn order to reflect the in-kernel interface changes duringkernel evolution, and to differentiate kernel-driver interactionamong differing device classes, we propose an in-kernel interfacespecification dedicated to a certain device class for agiven kernel.The in-kernel interface specification contains mainly kerneldata structures (if any) to be used, software events, andtransitions. The latter defines the driver’s desired reactions torequests, concerning hardware events that must happen beforethe driver sends a notification of completion to the kernel.C. Device and platform specificationsHardware vendors often release user manuals that describethe interface and operations of a device and the architecture ofa hardware board. Such a documentation is intended to providesufficient information for driver developers. However, it is usuallyinformal, and written in a natural language. To automatethe driver development, we require device and hardware boardspecifications, which provide not only structural information,but also some contents like a register map. Specifications ina format such as IP-XACT and UML MARTE are availablefrom some hardware vendors or can be obtained from informaldevice or board documentations.A device specification describes the following driver-relatedproperties of a device: i) device name and ID, ii) register fileinformation (e.g., register widths and offsets, bit field widthsand masks, register/bit field accessibilities, reset value, etc.),and iii) port information.A platform specification provides some driver-related informationas well, i.e. i) device instantiations, ii) I/O offsets,iii) interrupt connections (which indicate whether the interruptpin of the target device is used or not), iv) bus (e.g., bus clock,bus type, data bus width, data transfer type, device access type,transport mode), and v) processor (e.g., byte ordering, clockfrequency, name, word length).In general, IP-XACT includes most of the features mentionedabove, although, to the best of our knowledge, it stilllacks some information such as data transfer type (e.g., x8,x16).D. Device features modelReading from or writing to a certain register may cause aside effect. For instance, writing a value to the length registerof a given direct memory access (DMA) controller may startthe DMA transfer. Often, it necessitates programming someother registers before a side effect takes place. For instance,before writing the length register of this DMA controller, thesource address register and the destination address registershall be set with desired values so as to achieve successfulDMA operations. Such a register programming sequence needsto be modeled to ensure correct device operations. Hence, weare introducing a device features model to capture the way ofinteracting with the device.The device features model contains a set of predefineddevice features, such as init, read, write, etc. This model canbe translated to C functions. The translation process will beexplained in more detail in the following section.E. Driver generationThe driver generation flow is broken down into four steps.This section explains each step of the driver generation.Step 1: Parsing and inline functions generation. Thedevice features model along with the hardware specificationsand the HAL library, are mainly used to generate bit field