'

Developer Referance

In this section we introduce the technology behind DeviceDrivers.org and the way it works. If you are new to the concept of device driver automation or visiting this web-page for the first time we strongly recommend you go through the FAQ section.

Device Driver writing or automation needs two distinct set of information or knowledge bank. One of it being the hardware knowledge for which the device driver has to be developed or automated. By hardware, we mean a piece of electronic hardware (device) or Integrated Circuit(IC) or a programmable IP (silicon Intellectual Property), or even a systemC model of a device/IP. The other bank of information is that of the environment in which device driver is to function/run. Typically environment refers to an Operating System or a bare metal (NO OS) scenario or it could even be an IC validation environment.

The hardware knowledge is captured in a High Level Specification called Device Programming Sequence (DPS). Similarly the environment for the driver is specified in a configuration file called Run Time Specification (RTS).

The two specifications (hardware and run-time) are used as input to Device Driver Generator (DDGen) tool. One can think of DDGen tool as an intelligent Compiler that can understand and interpret the input specifications and then outputs a device driver (ANSI C) code!

In the Developer Reference sections we explain, in detail, the DPS and RTS constructs and how device driver developer could create high level input specifications by themselves. We hope this will act as a User Reference Manual for anyone interested to learn about software device drivers automation using the DDGen Tool.

We would love to hear your feedback on the DeviceDrivers.Org!

Frequently Asked Questions


How does DDGen generate driver code?

At the heart of the DDGen tool is an expert ‘engine’ that acts on two formal input specifications. The working phases of the tool can be summarized as follows:

  • The tool parses the hardware specifications (DPS) and populates a data structure (call it HW-DS) with relevant information about the hardware device (ASIC/IC/SOC).
  • Similarly the tool parses the run-time environment specification (RTS) and builds up another data structure (call it SW-DS).
  • The tool then builds the data transfer routines for the device. This phase is influenced by the RTS. Concepts like interrupts handling, buffering mechanisms are addresses by the tool during this phase.
  • DDGen then looks at the features, or programming sequences of the device. The RTS influences the generation of features like low level device ‘read’ & ‘write’ methods.
  • The next phase of the tool generates routines that take care of INITIALIZATION (Init) and FINALIZATION (Finit) functions of the device.
  • Generation of the interrupt service routine is done next.
  • Operating System (OS) related code generation gets done next. This will involve providing of OS wrapper so that the code generated in above steps.
  • The tool now generates only those primary register access methods that are needed by the driver.
  • The last and final step involves code re-arrangement and creation of driver files (as required by an application)


Does the tool follow any industry standards for creating input specifications?

Yes. The hardware and environment specifications (DPS & RTS) are largely built on IEEE standards for SoC IP packaging called IP-XACT (formerly known as SPIRIT now part of Accellera Standards). Vayavya has developed extensions to current IP-XACT specifications in order to generate device drivers. However, DPS is a proprietary specification developed by Vayavya Labs.


Does DeviceDrivers.org help in generating device drivers for any Operating System and platform?

Yes our goal is to meet that kind of requirement and we are working and making periodic upgrades to the tool to support a variety of operating systems and devices. The tool generates ANSI C based device drivers and hence supports any Processor that has a C compiler to compile the drivers for target. The current supported Operating systems are: Linux, Win CE, VXWorks, TI’s DSP-BIOS and Bare metal drivers. The tool generates a wide range of device drivers like: UART, I2C, DMA Controller, Ethernet, USB etc..


Can DeviceDriver.org help me in porting the drivers?

The optimal use of DDGen is for writing (generating) device drivers for new systems. However we understand that many of our customers would like to port their existing drivers from one OS to another OS. DDGen be used to reduce the engineering effort and costs for porting drivers. The steps followed in such cases are:

  • Write the DPS and RTS by looking at the datasheets and design documents
  • Use the tool to generate new set of drivers
  • In the event of non-availability of device data sheet and design documents Vayavya’s application team can help customers to re-construct the DPS and RTS files from the existing drivers and firmware source code base


Do you have a standalone version of the product that can be deployed for an enterprise?

We believe DeviceDrivers.Org as SaaS model should meet requirements of any enterprise. The tool is available as a node-locked or server based float license. DDGen tool is also available as an Eclipse plug-in for PCs/Laptops. The developers get the benefit to use the features of Eclipse IDE and the tool generated driver code is readily available as “Project” code in the Eclipse environment.


Where can I get more information on creating input specifications?

We have detailed language reference manuals which help developers create input specifications (DPS & RTS). Please write to us at support@devicedrivers.org for a copy of Language Reference Manual.