Correct-by-construction generation of device drivers based on RTL testbenches

Abstract

The generation of device drivers is a very time consuming and error prone activity. All the strategies proposed up to now to simplify this operation require a manual, even formal, specification of the device driver functionalities. In the systemlevel design, IP functionalities are tested by using testbenches, implemented to contain the communication protocols to correctly interact with the device. The aim of this paper is to present a methodology to automatically generate device drivers from the testbench of any RTL IP. The only manual step required is to tag the states corresponding to the different device functionalities. The Extended Finite State Machines (EFSMs) are then used to create a correct-by-construction two-level device driver: the lower level deals with architectural choices, while the higher one is derived from the EFSMs and it implements the communication protocols. The effectiveness of this methodology has been proved by applying it to a platform provided by STMicroelectronics.

Device driver generation targeting multiple operating systems using a model-driven methodology

“…Bombieri et al [24] propose a device driver generation methodology based on the register transfer level (RTL) test bench of an intellectual property (IP). However, device drivers can not be generated unless the code of the RTL test bench is available.…”

The strange pair: IP-XACT and univerCM to integrate heterogeneous embedded systems

“…[4] allows to gain automatic transactor specification, by identifying the sets of states that correspond to a read or a write operation in an EFSM representation of the communication protocol that is automatically extracted from a testbench of the component. Similarly, [5] allows device driver generation provided a target architecture configuration and the partitioning of the EFSM representing the device communication protocol into a set of functionalities. Finally, [8] requires only the target platform configuration to gain automatic generation of transducers.…”

“…Table 6 shows the main characteristics of such components. The ADC and DAC are implemented by using custom library components, while the device driver has been generated by using D2Gen [5]. Also transducers and transactors have been implemented automatically by using the semi-automatic tools listed in Table 1.…”

“…On the other hand, IPXACT2HIF builds only the interface of the device driver, i.e., the ioctl that must be provided to the application SW. The device driver code has been implemented by exploiting the semi-automatic tool D2Gen [5].…”

“…Furthermore, if components belong to different domains (e.g., HW and SW), it becomes necessary to build co-simulation frameworks or to create connecting components that allow communication despite of the heterogeneity. Some works in literature target the generation of connecting components, such as transactors and device drivers [4,5]. Unfortunately, there is no comprehensive methodology to analyze what components are necessary and to support the designer while generating them and integrating the system.…”