Page 1 of 6
`
`Modeling and Integration of Peripheral Devices in Embedded Systems
`
`Shaojie Wangm , Sharad Malikm, Reinaldo A. Bergamaschi [3]
`
`“J1 Electrical Engineering Department, Princeton University, Princeton, NJ, USA
`[3] IBM T. J. Watson Research Center, Yorktown Heights, NY, USA
`
`Abstract
`
`This paper describes automation methods for device driver
`development in 1P~lJased eniliedded systems in order to achieve
`high reliability, productivity, reusahility and fast time to market.
`We formally specifiz device behaviors using event driven finite
`state machines, canimimicotion rrhannels, declarativehi describea’
`rules, constraints and synthesis patterns. A driver is svnthesized
`from this specification for a virtual environment that is platform
`O
`J
`Jrocessor, 0 eratinv sistem and other hardware indeyendent.
`The virtual environment
`is may ed to a s eci ic
`lat orm to
`119
`.
`P .
`complete the driver implementation. The illustrative application of
`our approach for a USB device driver in Linux demonstrates
`improved productivity and reusability.
`
`1. Introduction
`
`Device drivers provide a bridge between a peripheral device
`and the upper layers of the operating system and the application
`software. They are critical software elements that significantly
`affect design quality and productivity. Given the typical lifecycle
`of chipsets being only 12 to 24 months, system designers have to
`redesign the hardware and software regularly to keep up with the
`pace of new product releases. This requires constant updates of
`the device drivers. Design and verification of device drivers is
`very complicated due to necessity of thorough knowledge about
`chips and boards, processors, peripherals, operating systems.
`compilers,
`logic and timing requirements; each of which is
`considered to be tedious. For example, Motorola MPC860
`PowerQUICC is an SoC micro-controller used in communications
`and networking applications.
`lts board support package (BSP)
`(essentially drivers) has 25000 lines of C code [6] e an indication
`of its complexity. With time—to—market requirements being pushed
`below one year, driver development
`is quickly becoming a
`bottleneck in ll’-based embedded system design. Automation
`methods, software reusability and other approaches are badly
`needed to improve productivity and are the subject ofthis paper.
`The design and implementation of reliable device drivers is
`notoriously difficult and constitutes the main portion of system
`failures. As an example, a recent report on Microsoft Windows
`XP crash data [7] shows that 61% of XP crashes are caused by
`driver problems. The proposed approach addresses reliability in
`two ways. Formal specification models provide for the ability to
`validate the specification using formal analysis techniques. For
`example,
`the evcnt—driven state machine models used in our
`approach are amenable to model checking techniques. Correct by
`construction synthesis attempts to eliminate implementation bugs.
`
`the formal specifications can be used as manuals for
`Further,
`this
`component,
`and
`inputs
`for
`automating
`the
`reusing
`composition with other components,
`is portability.
`Another key concern in driver development
`Device drivers are highly platform (processor, operating system
`and other hardware) dependent. This is especially a problem when
`design space
`exploration involves
`selecting from multiple
`platforms. Significant effort
`is required to port
`the drivers to
`different platforms. Universal specifications that can be rapidly
`mapped to a diverse range of platforms, such as provided by our
`approach, are required to shorten the design exploration time.
`the
`The
`approach presented in
`this paper
`addresses
`complexity and portability issues raised above by proposing a
`methodology
`and
`a
`tool
`for
`driver
`development. This
`methodology is based on a careful analysis of devices, device
`drivers and best practicesof expert device driver writers. Our
`approach codities these by clearly defining a device behavior
`specification, as well as a driver development
`flow with an
`associated tool. We
`formally specify device behaviors by
`describing clearly demarcated behavior components and their
`interactions. This enables a designer to easily specify the relevant
`aspects of the behavior in a clearly specified manner. A driver is
`synthesized fiom this specification for a virtual environment that
`is platform (processor, operating system and other hardware)
`independent. The virtual environment is then mapped to a specific
`platform to complete the driver implementation.
`The remainder ofthis paper is organized as follows: Section 2
`reviews related work; Section 3 describes the framework for our
`methodology; Section 4 presents the formal
`specification of
`device behavior using the Universal Serial Bus (USB) as an
`example; Section 5 discusses driver synthesis; Section 6 describes
`our case study; and finally Section 7 discusses future work and
`directions.
`
`2. Related Work
`
`Recent years have seen some attention devoted to this issue in
`both academia and industry. Devil
`[3] defines an interface
`definition language (IDL)
`to abstract device register accesses,
`including
`complex
`bit-level
`operations.
`From the
`IDL
`specification, it generates a library ofregistcr access functions and
`supports partial analysis for these functions. While Devil provides
`some abstraction for the developer by hiding the low—level details
`of bit-level programming,
`its approach is
`limited to register
`accesses and it does not address the other issues in device driver
`development outlined above.
`ln the context of co-design automation, O’Nils and Jantsch [4]
`propose
`a
`regular
`language
`called
`l’roGram to
`specify
`
`,
`Proceedings of the Design,/uitomation and Test in Europe Conference and Exhibition (DATE'O3)
`1530-1591/03 $17.00 © 2003 IEEE
`
`Exhibit 20l l
`
`ServiceNow v. HP
`
`lPR2015-00631
`
`ll"l'l7
`COMPUTER
`socrrjrv
`
`Page 1 of 6
`
`

`
`Page 2 of 6
`
`be
`communication protocols, which can
`hardware/software
`compiled to software code. While there are some interesting
`features,
`this does not completely address the device driver
`problems as described here, particularly due to its inability to
`include an external OS. Other efforts in the co-design area [1,2]
`are limited to the mapping of the cornmunications between
`hardware and software to iritemipt routines that are a small
`fraction of a real device driver.
`standard
`a
`defines
`[8]
`I2O (Intelligent
`Input Output)
`is independent of both the
`architecture for intelligent
`l/O that
`specific device being controlled and the host operating system.
`The device driver portability problem is handled by specifying a
`communication protocol between the host system and the device.
`Because of the large overhead of the impleineirtatiori of the
`communication protocol,
`this approach is
`limited to high-
`perfoiinanee markets. Like I20, UDI
`[9]
`(Uniform Driver
`Interface) is an attempt to address portability. It defines a set of
`Application Programming Interfaces (APIs) between the driver
`and the platform. Divers and operating systems are developed
`independently. UDI API’s are OS and platform neutral and thus
`source-code level reuse of driver code is achieved. Although UDI
`and our methodology share the common feature of platform and
`OS neutral service abstraction, our methodology is based on a
`formal model that enables verification and synthesis.
`
`3. Methodology Framework
`Devices are function extensions of processors. They exchange
`data with processors, respond to processor requests and actively
`interact with processors, typically through interrupts. Processors
`control and observe devices through the device»programrnmg
`intezjface, which defines I/O registers and mapped memories.
`
`Data
`
`througli memory mapped l/O,
`Processors access devices
`programmed I/O or DMA. A data path (or communication
`channel)
`is a specific path for exchanging data between the
`processor and the device as illustrated in Figure 1.
`To hide the details of device accesses, device drivers are
`designed to be a layer between the high—level software and low-
`levcl device. In most cases. a device driver is part of the kernel.
`Application software, which resides in user space, uses system
`calls to access the kernel driver. System calls use traps to enter
`kernel mode and dispatch requests to a specific driver. Hence we
`can partition a device driver into three parts as illustrat.ed in Figure
`l and explained below:
`-
`Core _/imclions, which trace the states of devices, enforce
`device state transitions required for certain operations, and
`operate data paths. Because such actions depend on the
`current states of the device, synchronization with the device
`is necessary. Common synchronization approaches
`are
`interrupts, polling and timer delay. In our approach, core
`functions are synthesized from a device specification. They
`interact with a platform independent
`framework called
`virtual
`envi/‘onmem. The device
`specification itself
`is
`explained in Section 4, and synthesis of core functions in
`Section 5.
`
`I
`
`-
`
`to the
`P/a(f0rm jimciions that glue the core functions
`hardware and OS platform. The virtual environment abstracts
`arclritectural behaviors
`such
`as big or
`little
`endian,
`programmed I/O, memory mapped I/O. It also specifies OS
`services and OS requirements such as memory management,
`DMA/bus controllers, synchronization inechanisnis etc. This
`virtual environment is then mapped to a particular platform
`(hardware and OS) by providing the platform functions that
`have platform specific code for the above details.
`Regisn;_v functions that export driver services into the kernel
`or application name space. For example,
`the interface can
`register a driver class to the NT I/O manager (IOM) or fill
`one entry of the VFS (Virtual File Switching) structure of the
`Unix kernel.
`A
`Figure 2 outlines our framework and illustrates how the three
`parts of the driver come together. It takes as input (1) the device
`Device
`. _
`
`.
`
`Core Gen
`
`Spccrtrcatron Core Functions (C code)
`
` Driver
`
`con1.‘gummm
`
`Mapper <::
`\/
`
`Target
`Iznvironment
`(library etc.)
`
`D Input
`
`Device Driver (C code?
`
`l-‘igure 2: Framework Overview
`
`the driver
`and (2)
`specification, which is platform neutral
`configuration, which
`specifies
`the
`device
`instance
`and
`enviroiiment; and otitputs the device driver (C program) for a
`particular device in a particular environment.
`
`
`
`Memory
`
`P
`
`.
`TOCCSSOI
`
`‘
`
`Meinoiy
`
`.
`Register
`'
`.
`Register
`.
`Device
`
`‘
`
`t‘
`\
`it
`
`1/O
`' '
`\
`I\ntcirupt
`(BUS)
`
`\
`
`.
`
`\
`
`‘i
`
`\
`
`\
`
`\
`
`
`
`Software
`
`/I
`
`User Mode:
`Application
`
`Kernel mode
`..
`lOM/VI‘5
`
`i
`
`_
`D‘ We‘
`
`
`
`\
`
`\‘
`
`Data Unit
`
`Data Unit
`
`Data Path
`
`/
`,'
`
`/’
`
`.’
`,'
`'
`
`.
`Registry
`Function
`
`care
`function
`
`_
`Platform
`Function
`
`/’
`
`ata
`D
`access
`
`\
`
`Control
`
`/
`
`’I
`
`Figure l: Driver Environment
`
`Figure I sketches the relationship between devices, processors, the
`operating system and device drivers.
`
`Proceedings of the Design,Automation and Test in Europe Conference and Exhibition (DATE’O3)
`1530-1591/03 $17.00 © 2003 IEEE
`
`
`Ilflfll
`COMPUTER
`SOCIETY
`
`Page 2 of 6
`
`

`
`Page 3 of 6
`
`The device specification provides all the information about the
`device required by the driver core function synthesis process
`(Core Gen). Core functions are implemented in the virtual
`environment. The mapper maps core functions in the virtual
`environment
`to the target environment. This mapping process
`does
`(I) platform mapping, by binding virtual OS service
`functions to the targeted OS, and virtual hardware functions to the
`targeted hardware;
`(2)
`registry mapping by translating core
`functions to the OS specific registry functions. It does this using
`the
`developer
`specified driver
`can/igr/ration. The
`driver
`configuration
`defines
`the
`target
`platform and
`necessary
`parameters. It includes the OS name, processor name, bus name,
`device instance parameters (such as interrupt vector number, base
`address), driver type (such as char device, network device), driver
`
`.drv ep2_drv (
`.05 Linux 2.4.x
`.irq 13
`.io_ext 0X30
`M ## .drV ep2_drv
`}){...}
`
`.config {
`.processor SAl1OO
`.io_base OXBOOOOOOO
`.drvType Ethnet
`
`Figure 3: SAI100 USB Device Controller (UDC)
`Driver Configuration
`
`type specific parameters (such as maximum transfer unit for a
`network device)
`etc. These coirfigurations are specified by
`keywords. Figure 3 shows the sketch of an example. This direct
`specification is sufficient
`for
`the mapper
`to target
`the core
`functions
`to a
`specific platform. While
`this
`requires
`the
`specification writer to have specific knowledge of the various
`elements of the configuration, information such as driver type and
`driver type specific parameters are encoded once and then reused
`across platform specifications.
`
`4. Device Specification
`In this section we describe the different parts of the device
`specification, which is the input
`to the generation of the core
`functions (see Figure 2). Based on our study ofdevices and device
`drivers, we partition this specification into the following parts:
`data path, device control, event handlers, core functions and
`device programming interface. Figure 1 provides some motivation
`for this division. The data path describes the transfer of data
`between the processor and the device. The device control
`describes the transitions between the states of the device using
`event driven finite state machines (EFSM) [5]. The processing of
`events in the event driven state machines is specified in event
`handlers. The core functions provide the device services to the
`upper layers of the software — the OS and the application. The
`device-programming interface provides
`the
`low-level
`access
`functions to the device registers. Eventually it is the core functions
`that need to be synthesized in C as the driver — however,
`this
`synthesis will need all
`the other parts of this specification to
`understand the complete device behavior. This partitioning of the
`specification allows for a separation of the variotis domains,
`which the device driver has to interact with, and is similar to the
`approach used by expert device driver writers.
`
`Data Path
`A dam unit is a data block moving between the device and
`.
`.
`.
`.
`.
`_
`the software by a primitive hardware operation For example, we
`can define a DMA access as a primitive hardware operation. A
`
`data unit is modeled as a triple ofdata unit size, the event enabling
`a new data unit operation, starter function, the event indicating the
`end of a data unit operation,
`stopper
`function,
`the events
`indicating errors and access operations. Starter functions are the
`O)€l'ittiOl1S perforined before data accesses. Stopper functions are
`the cleanup operations pert‘ormed when the hardware data access
`operations end. Figure 4 defines the DMA data unit ofthc transmit
`
`## DMA transmit FIFO
`.dma udc_wt = dr_fifo@ep2_space .0
`.setup %{
`IVAR CS2 TPC FLIP;
`IREG_IMP WRITE(IDMA_SIZE—1) ;
`.Cleanup
`%T IvAR_cs2_ssT_F...IP,~
`.aloort:
`ep2_not_ready
`%{
`IVAR__CS2_SST_FLIP;
`.abort
`ep2‘tpe__or__tur
`%{
`IVAR_CS2_SSTflF.aIP;
`
`## data unit
`.du ep2__du = udc_wt[64];
`
`o\°
`
`o\"-‘o\°..,.\,_.K/g,.
`
`o\°
`
`## data path
`.dp ep2 = ep2_du .0 .interface
`.block %{
`IVAR_CS2_'~"ST_WRI"E(l);
`.reset %{
`IvAR_Cs2_‘=sT_wRI':E(o),-
`
`o\°a\°
`
`...,.A.,.
`
`Figure 4: SA1 100 UDC Transmit Channe Data Unit
`and Data Path Specification
`
`channel of the SA] 100 USB device controller (UDC). While the
`details of the specification are beyond the scope of the paper, this
`illustrates the nature of the information required here.
`A data path is defined as a stream of data units. The last part
`of Figure 4 provides an example of a data path specification. It
`specifies data transfer direction and the data tinit ofthe data path.
`
`Device Control
`The device comm] specifies the state changes of a device.
`Because a device may be composed of several
`sub—devices
`operating in parallel, we use a concurrency model, event driven
`finite state machines [5], to formally model the device control. It
`has several syzic/i1‘0nizaII'0i7 properties: (1) the execution of event
`handlers and state transitions are free of race conditions, and (2)
`finite state machines do not share data and communicate through
`events if necessary. The synthesizer enforces the race condition
`free property by disabling the context switches appropriately.
`Figure 5 gives the sketch of an example of device control
`specification ofa sub—coinponent, USB settip protocol, of SA] 100
`UDC. Again, detailed syntax and semantics of the specification
`are beyond the scope of this paper, we will focus on illustrating
`the salient features ofthe specification.
`There are four types of events: hardware events, input events.
`omptu‘ events and internal even/s. Devices generate hardware
`events to indicate changes of hardware states. A typical hardware
`event is an internipt. Higher layer modules send input events (also
`called service requests) to the driver. Events sent to higher—layer
`modules are called output events. As an example, USB host
`assigns a USB address to the UDC. The driver can emit an output
`event that carries the address information when the host assigns
`the address. The uppcr—laycr software observes the USB address
`of the device through the output event. All other events are
`internal. Events
`can be considered as messages conveying
`informatioir.
`In
`addition
`to
`the
`event
`name,
`an
`event
`
`Proceedings of the Design,/xutomation and Test in Europe Conference and Exhibition (DATE‘O3)
`1530-1591/O3 $17.00©2003 IEEE
`
`liiifli
`COMpUTER
`SOCIETY
`
`Page 3 of 6
`
`

`
`Page 4 of 6
`
`may convey information by carrying a parameter. Events are
`stored in a global event queue.
`As shown in Figure 5, an event handler handles a particular
`
`Although a data llow does not have an explicit control state
`machine specified, a state machine is implicitly generated for it to
`manage the control states such as reset and blocking.
`
`Device Programming Interface Specification
`To model device register accesses, we use the concepts of
`register and variable (see Figure 6) — similar definitions can be
`.ound in Devil [3]. Event handlers and core functions access the
`
`## Eight bit register cs2 is at offset Oxl 8. The 6th and
`##
`7th bits of udccs2 are reserved and read as O.
`.reg cs2 = base[0xl 8] mask <00—————>
`.Sl0W : 8 bit;
`
`{
`.fsm usb_protocol
`## The start state is I)isa12/ed. It accepts event start.
`‘#351 Event handler is enclosed in 00,’ and 96}. The
`## destination state is Zoml,7ieSuspend.
`
`Disabled start Zombiesuspend %{
`IVAR_CR_UDD~WRITE (0) ;
`iudelay(100);
`IEvt:Out: (ep1_reset) ;
`IEvt:Out: (ep2_reset:) ;
`%};
`
`l #
`
`# Control function. The request event is start. This
`## function moves the usb_pr0toco/ state machine to
`## ZombieSuspend state, epl and ep2 to idle state.
`## (Note: epl and ep2 are the implicit state
`## machines for data flows epl and ep2. )
`
`(ep2,
`idle)
`tepl,
`.ctr1 start
`(usb_protocol, Zombiésuspend);
`
`idle)
`
`Figure 5: SAI 100 UDC USB Setup Specification
`
`event for a particular state of a state machine. The event handlers
`of a finite state machine may share data. Event handlers are non-
`blocking. As a result, blocking behaviors are e.\’piicifl,t~’ Specified
`by states. To remove a blocking operation from an event handler,
`the specification writer can restructure the state machine by
`splitting the handler at the operation and inserting a new state.
`Thus, we describe synchronization behaviors declaratively using
`states, rather than procedurally, which enables better checking.
`Specifically,
`interrupt processing is modeled as
`a couple of
`hardware event handlers.
`
`Control Function Specification
`A core function is
`responsible for providing the device
`services to the upper layers of software. As illustrated in Figure 1,
`core functions are responsible for managing data accesses and
`manipulating device states. Data accesses follow well—defined
`semantics, which specify, for example, that a block of data has to
`be transferred between the processor
`and device. Control
`functions are responsible for changing the control state of the
`device according to the state machines. As illustrated in the lower
`part of Figure 5, a core controlfzmction has an input event and a
`final state set. It accomplishes specific functions by triggering a
`sequence of transitions. Because a transition may emit multiple
`output events, multiple transitions can be enabled at one time. The
`core control function selectively fires eligible transitions, i.e. finds
`a transition path from the current state to the final state set. For
`example,
`the start function of SAllO0 UDC is defined as the
`union of start event and a set of states, as shown in Figure 5.
`When the application calls the start function, it generates the input
`event (service request) start. It then finds a transition path to states
`(usb_protocol, ZombieSuspend),
`(cpl,
`idle),
`(ep2,
`idle) and
`completes. If the current state does not accept the start event, the
`function returns abnormally. Timeout
`is optionally defined to
`avoid infinite waiting.
`
`
`
`## Variable definition for register cs2: except for
`## the two reserved bits, each bit of register cs2
`## is a variable. We generate functions such as
`## “set”, “clear” for them.
`vars cs2 { *, *, fst,
`tpc,
`tfs];
`
`sst,
`
`tur,
`
`tpe,
`
`Figure 6: SAI 100 UDC Transmit Channel Register
`and Variable Specification Example
`
`device registers through a set of APIs such as ]REG'_name__RE/JD
`and ]REG__name_WR17‘E that use these registers and variables.
`These APl’s are synthesized from the register and variable
`specifications, and extend the virtual environment. In addition to a
`basic programming interface, we provide additional features that
`enable common access mechanisms to be described succinctly.
`For example, FIFO is a common device-programming interface. It
`is always accessed through a register. Different devices use
`different mechanisms to indicate the number of data in the FIFO.
`To enable the synthesis of FIFO access routines, we have defined
`the concept of a hardware FIFO mapped register that
`is not
`illustrated in detail here because oflimitecl space.
`
`5. Synthesis
`
`Given all the parts of the specification, the synthesis process
`synthesizes the C code for the entire driver. The functions that
`need to be provided are the core functions that provide the device
`services to the upper layers of software.
`In synthesizing these
`functions, all parts of the specification are used. This section
`outlines the synthesis process.
`
`5.] Platform Function and Registry Function Mapping
`
`The platform interface includes fundamental virtual data types
`and a basic virtual API for the following categories:
`(1) Synchronization functions,
`(2) Timer management functions,
`(3) Memory management functions,
`(4) DMA and bus access functions,
`(5) Interrupthandling (setup, enable, disable, etc.),
`(6) Tracing functions,
`(7) Register/memory access functions.
`All virtual data types and API are mapped into platform
`specific types and API. This part is done manually based on an
`understanding of the platform. Note that while this
`is not
`synthesized.
`this approach provides for significant reuse as this
`needs to be done only once for each platform (or part of a
`platform).
`
`Proceedings of the Design,Automation and Test in Europe Conference and Exhibition (DATE’03)
`1530-1591/03 $17.00 © 2003 IEEE
`
`ltilll
`COIVIPUTER
`SOCIETY
`
`Page 4 of 6
`
`

`
`Page 5 of 6
`
`Figure
`
`7(a)
`
`illustrates
`.
`/*synchronizat:'ion obj ect */
`Data Type:
`ib1k_unit
`
`a platform interface
`
`abstraction,
`
`Operations :
`IDECLARE BLK_UNIT(name)
`/,t blockron bu ,,/
`inline void iblk (iblk Unit bu) I,
`/at unblock at /
`"
`inline Void iunblock (iblk unit bu) I.
`/~kCheCk if any one is blogked on bu*/
`1111 ine int-_ ichk_b1k (ib1k_un1t bu) ,-
`
`Figure 7(a): synchronization primitive abstraction
`
`in the platform independent virtual
`synchronization primitive,
`environment. Figure 7(b) shows the mapping ofit on Linux kernel
`
`typedef wai:_queue_head_t iblk_unit;
`
`\
`gdefine IDECLARE ELK UNIT (name)
`DECLARE WAIFE QUEUE HEAD(name)
`inline Void §’b1k(ib1k unit *bu)
`{
`sleep on (bu) I.
`}'
`
`inlirie void iunblock (ib1k_unit *bu)
`{ wake_up (bu) ;
`}
`
`inlirie int ichk_blk(ib1k_unit *bu)
`{ return(waitqueue_active(bu)l;
`l
`
`Figure 7(b): Linux 2.4 Mapping of the Priinitive
`specified in Figure 7(a)
`
`‘
`
`implements the interface defined in Figure 7(a) with
`2.4 that
`Linux 2.4 kernel data type and functions. For lack of space, we do
`not show the mappings on other platforms.
`We adopt a template-based approach to map the registry
`function interface to a specific platform by creating a library of
`platform specific templates. The synthesizer generates appropriate
`code to tailor the template for a particular device. Although the
`registry function generation is platform specific,
`it
`is reused for
`drivers for different devices.
`
`_
`_
`.
`5.2 Driver Core Function Synthesis
`As illustrated in Figure 1, device driver core functions are
`either data access functions or control functions. We synthesize
`data access functions from the data path specification, and control
`functions from the device control specification.
`Section 3 mentioned that driver core functions synchronize
`.
`.
`_
`t
`g
`.
`.
`I
`.
`_
`with the device through one of the 3 synchronization mechanisms.
`interrupt, poll and timer delay. As £1
`result, our driver core
`fuiietioii syiitliesizei‘ synthesizes’ both
`driver ‘functions and the
`.
`(
`V
`L
`.
`fr:;‘t::r;:::‘::i.:s:i‘;:i.:2;t;r:.:‘t:::r to
`the
`consider
`Syiichroiiization Mechanisms
`Let
`us
`syriclironization nicclianisms first. An interrupt is essentially an
`asynchronous communication mcchziriisiii whereby the lt']lc‘rl11pl'
`handler is called when the interrupt occurs. Both polling and timer
`delay are either asynchronous or blocking. For example, a timer
`delay can be a busy wait that is blocking. On the other hand, we
`
`can register a routine that is executed by the system when the
`timer expires which is an asynchronous behavior. For brevity, we
`only describe the synthesis of asynchronous eomiiiunication
`routines (e.g., interrupt handlers for interrupts), which are critical
`to synchronization niecliaiiism synthesis.
`
`function in our
`access
`Data Access Function A data
`framework is asynchronous: it does not wait for the completion of
`data access but returns right after the data access is enabled. This
`asynchronous behavior enables the overlap of data transfer and
`computation. A callback function can be registered to notify the
`completion of a data transfer. Synchronous communication is
`achieved by synchronizing the caller and the callback function
`A data path is modeled as a stream of data units. Hence, the
`data access function is implemented by iterating data unit accesses
`until the entire data block is transferred. If an error occurs, the
`whole data path access aborts. The device control can block or
`reset 3 data Pall‘-
`Control Function A control function moves the device to a
`
`particular state. The execution of application software depends on
`such a state change. Hence, a control
`function is blocking
`(synchronous) in our framework, i.e., it will not return unless the
`final state set
`is reached. The control functions do not return
`values. The device is observed through output events,
`illustrated in Section 4. We declare a variable for each output
`event. Device status is observed by reading such variables.
`
`*pr:iV,
`void Ctrl(DEV_PRIV__DS
`IEsmEvt:Val val)
`{
`Enqueue the input event;
`while (true)
`{
`whiletfirable transitions exist){
`Fire the transition?
`if (final state set is reached)
`return;
`
`‘
`l
`block (tlme_Out_Value) I’
`
`l
`
`}
`
`Figure8: Control Function
`
`lt
`A control function involves a series of state transitions.
`completes when the final state set is reached. Since our mode is
`based on event driven finite state machines, a control function
`
`Void interrupt” {
`Clear the interrupt?
`Erfqueue the hardware event’
`if (event queue was not empty)
`. return’
`,
`lf (a process/thread 1s blocked)
`unblock it and return.
`else {
`'
`While (firable transitions exist)
`
`}
`
`}
`
`{
`
`l
`
`Figure 9: lntemipt Handler
`
`firings. The state
`essentially consists of a sequence of event
`macliiiies are checked to see if the iinal state set of the coiiirol
`
`Proceedings of the Design,Automation and Test in Europe Conference and Exhibition (DATE’03)
`1530-1591/03 $t7.00©2003 IEEE
`
`.
`
`_ Hll.
`(JQMPU-1'~ER
`SOCll3'l‘Y
`
`Page 5 of 6
`
`

`
`Page 6 of 6
`
`function is reached. lf the control function is not time out and the
`final state set is reached, it returns successfully.
`Execution of EFSM We schedule the finite state machines
`using a round—robin scheduling policy. The events are consumed
`in a First Come First Served manner. A multi—pr‘ocessoi' safe, non-
`preernptivc queue is implemented. Driver functions are executed
`in the context of a process/thread. We view the execution of
`interrupt handlers as a special kernel thread. Hence, the essence of
`the core function synthesis is to distribute the event handler
`executions and state transitions to the interrupt handlers and driver
`functions. We dynamically make this decision by checking
`whether there is a blocked process/thread.
`If yes,
`the driver
`function does the work; otherwise, the interrupt handler does it.
`Figure 8 and 9 show the sketches of control
`functions and
`interrupt handlers respectively.
`
`6. Case Study
`The Intel StrongArm SAI 100 [10] is one of the more popular
`microprocessors used in embedded systems. lts peripheral control
`module contains a universal serial bus (USB) endpoint controller.
`This USB device controller (UDC) operates at half-duplex with a
`baud rate of l2Mbps. It supports three endpoints: endpoint 0 (ep0)
`through which a USB host controls the UDC, endpoint
`l (cpl)
`which is the transmit FIFO and end point 2 (ep2) which is the
`receive FIFO.
`The Linux UDC (USB device controller) driver (ported to
`Strong—Ami SA1l00) implements USB device protocol [ll] (data
`transfer and USB connection setup) through coordination with the
`UDC hardware. An Ethernet device driver interface has been
`implemented on top of the USB data flow.
`To
`evaluate our methodology, we modeled UDC and
`synthesized a UDC Linux device driver that has an Ethernet driver
`interface and manages data transfer and USB connection setup.
`UDC cpl is modeled as an OUT data path. lts data unit is a data
`packet of no more than 64 bytes transferred via DMA. Similarly
`UDC ep2 is modeled as an IN data path. The UDC control has 4
`state machines: one state machine for each endpoint and one state
`machine managing the USB protocol state of the device. The state
`machines for data flow cpl and ep2 are implicitly generated.
`Table l shows a comparison of code sizes for the original Linux
`driver,
`the
`specification in
`our
`framework and the
`final
`synthesized driver.
`
`through a USB cradle. Familiar v0.5.3 of Linux kernel 2.4.17 is
`installed on the il’aq and Redl~lat 7.2 of Linux kernel 2.4.9 is
`installed on the desktop. We compiled the synthesized code to a
`loadable kernel module with a cross-compiler for ARM,
`loaded
`the newly created module on the iPaq_, bound ll’ socket layer over
`our module and successfully tested the correctness with the
`standard TCP/lP command ping.
`
`7. Conclusions and future work
`
`Device driver development has traditionally been cumbersome
`and error prone. This trend is only worsening with IT’ based
`embedded system design where different devices need to be used
`with different platforms. The paper presents a methodology and a
`tool
`for the development of device drivers that addresses the
`complexity and portability issues. A platform independent
`specification is used to synthesize platform independent driver
`code, which is then mapped to a specific platform using platform
`specific library functions. The latter need to be developed only
`once for each component of the platform and can be heavily
`reused between different drivers. We believe this methodology
`greatly simplifies driver development as it makes it possible for
`developers to provide this specification and then leverage the
`synthesis procedures as well as the library code reuse to derive
`significant productivity benefits.
`the similarities between
`In the future, we plan to exploit
`devices of the same type. With an appropriate inheritance
`mechanism, the reusability of device specification will be largely
`increased. We will also study optimization issues such as code
`size, performance and power consumption.
`
`8. References
`
`I-l. Hsieh, A. Jureeska, L.
`[1] F. Balarin, M. Chiodo, P. Giusto,
`Lavagno, C. Passerone, A. Sangiovanni—Vincentelli, E. Sentovicli,
`K. Suzuki, and B. Tabbara, Hardware—Sofiware Co—Design of
`Embedded Systems: The Po/is Approach, Kluwer Academic Press,
`June 1997.
`J. De Man, B. Lin, K. van Rompaey, S.
`[2]
`l. Bolsen, H.
`Vercauteren, and D. Verkest, “Hardware/software co-design of
`digital telecommunication systems”, Proceeciing off/1e IEEE, Vol.
`85, No. 3, 1997, pp. 391-418.
`[3] F. Merillon, L. Reveillere, C. Consel, R. Marlet and G.
`\/Iuller,
`“Devil: An
`IDL for
`liardware
`pi‘ogi'arnming”,
`4',’
`symposizmt on operating systems design and 171711.?/t.’I1