DDGen (Device Driver Generator) is Vayavya Labs first generation tool for enhancing the productivity of embedded designers/programmers. As the name suggests the tool aids in generation of device drivers and low level access methods for any device (IC/ASIC/SoC) on any given platform (Operating systems and Processor). The tool (DDGen) automates driver generation by taking in two inputs namely:
- Device specification ( IC specification like register specification and programming sequence that is commonly given in the form of a Data sheet)
- Run Time environment specification(system software specified at very high level by an architect or designer)
The device specification and run time specifications are done using formal languages.
DDGen helps in reducing the time required for device driver development. The tool articulates the principle of "Spec once and generate many times". The idea is to capture the device (IC/ASIC/SoC) specification once and in the correct format (without the ambiguity as seen in the data sheets, due to the use of an informal language such as English). Every time the device is used in different applications only the specification related to run time environment (software specification) needs to be changed or redefined. This would result in saving substantial amount of time for the design engineers.
Also the IC vendor can reduce his/her support costs (man days/months effort) by recommending their vendors to adopt the tool.
DDGen relies on two inputs namely Device and Programming Sequence (DPS, a formal specification developed by Vayavya Labs which is similar to Verilog or C language) of a device (IC) and "Run Time Software Specification" (RTS, expressed using certain Keywords and constructs). These two inputs are expected to give all the details that a typical driver programmer would need while developing a device driver. Since the inputs are in a formal language a tool can interpret these inputs and then generate a ANSI C compliant driver code.
The heart of the tool is an expert system that acts on two formal input specifications. The different phases of the tool can be described as follows:
- The tool parses the Device Specification (DPS) and populates a data structure (call it HW-DS) with relevant information about the hardware device (IC).
- The tool parses the Run Time Software 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.
- The tool then looks at the features, or programming sequences of the device. The RTS influences the generations 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 (Finite) 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 STEPS 3 & 4 is encapsulated as per the OS needs.
- The tool now generates only those primary register access methods that are needed by the driver.
- The last step involves code re-arrangement and creation of driver files (as required by an application)
Yes. We have a Release Version of the tool that supports industry accepted standard IP-XACT (formerly known as SPIRIT now part of Accellera Standars)). 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.
We are now at beta stage where some of the prominent semiconductor vendors are evaluating the tool for deployment in their design flow. Please contact our sales/marketing division (email@example.com) for more details.
Vayavyas tools are targeted for embedded system programmers. The tools can be used by:
- Semiconductor firms (IC/ASIC/SoC makers)
- IP vendors
- OS vendors and
- Embedded Design Services firms
Besides the semiconductor, design service firms, and the embedded tools vendors, the following can also be Vayavya Labs’ customers:
- Embedded tools developers /vendors: Existing EDA/ESL or embedded tool providers can use the DDGen to bundle along with their existing tools to provide value added services to their customers
- Semiconductor and module distributors: The semiconductor distributors and module vendors can also look forward to the use of DDGen to extend their portfolio of services. The tool will help in supporting customers better and to provide value-added services to customers who are looking at one-stop-solution- providers for their designs.
The table below captures some of the features specific to operating system, processor, interface support and the tool release version.
Yes. The tool supports driver generation for various class of USB drivers such as mass storage, HID, Audio class. The tool also supports USB Host and HSOTG class of driver generation.
Yes. We have tested the tool for generating a video driver for custom ASIC targeted for TV applications. An image processing driver is no different from any control driver when looked solely from driver code point of view. One can say that the processing of data (image data) and the way it is sequenced while processing, is what differentiates an image driver from the rest of the drivers. Since DDGen collects the device programming sequence (as part of DPS), and the RTS specification captures the critical parameters of the design, the tool can generate any type of driver.
DDGen does not do anything special for multi-processor architectures as of now. However we do have a command line option that will generate drivers for multiple devices on a single SOC at one go.
Is the generated driver configurable for optimizations on power consumed, code size and performance?
Configuration input in RTS can be used to control the generated code to optimize the code for performance or code size. The current version of DDGen has only limited set of configuration options, and optimizations for power are not supported. The next version of DDGen will provide additional options for optimizations.
The optimal use of DDGen is for writing (generating) device drivers for new systems. However customers who would like to port their existing drivers from one OS to another OS can also use DDGen to reduce the engineering effort and costs. 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 driver and firmware source code base
What is the extent of testing that has been done on the generated code? How can I be assured of quality?
We strive to ensure that the generated code is of high quality. The tool is checked with a representative set of DPS/RTS inputs. The following checks are in place in our regression workflow:
- Turn on all warnings (e.g, -Wall option of gcc) and ensure that the compiler reports zero warnings
- Compare the generated output with a golden reference code, and ensure no differences are present. The golden reference code has been pre-tested on board and is known to work correctly.
- Check for memory leaks in the driver code with Valgrind
Specification – DPS and RTS
Specification - DPS and RTS
Our internal evaluations show that the engineers can pick up this language within 3-4 days after the training by our Field Application Engineers. DPS is more of a specification language than a programming language, and borrows many of its keywords and constructs from the popular hardware descriptor languages and C- Programming language that IC/SW engineers are familiar with. RTS is similar in syntax to a configuration file – it is a simple task to edit/write it with help of the reference manual.
DPS is easy and a formal way to express the device specification. Currently the device (IC) specification is being done by the IC engineers using English as the medium of communication. This, many a times, results in translation errors and misinterpretation by IC users. Formal specification would remove any such ambiguity and also pave way for automation of laborious work flows. Using DPS not only aids device driver generation but in future it will aid verification test vector generation, which is an important design activity for IC design flow. The net result of all this is significant time gains in product roll out.
The current version (Release 1.1) of the tool has a limited GUI support. We are in the process of upgrading our GUI support for the tool. The current GUI enables developers to ‘edit’ contents of existing DPS and RTS libraries and modify the same for new projects. The goal is to have a GUI that can be a plug-in component for Eclipse based Development Environment.
What are the comparison figures (performance vs. size) for the tool generated code to hand written code?
Tables shown below give details about productivity improvement, code size for the device drivers generated using DDGen. The matrices below are from some of the BETA customer sites.
Is the generated code specific to a processor and compiler tool-chain? If yes, how can I control the processor/tool-chain being used?
Most of the generated code is ANSI-C and is not specific to a processor architecture/tool-chain. However, some sections of the code are based on a specified tool-chain. The user can select the processor and tool-chain to be used, by editing the RTS (Run Time software Specification)
The tool generates human readable code. Comments are generated to describe the functionality of the generated code, indentation is maintained, and the function names in the generated code map to the constructs in DPS.
Is the description in DPS sufficient to generate a full driver, or what will be generated just a skeleton?
The goal of DDGen is to generate a complete driver, not just a template/skeleton file that the user has to edit later. DPS captures the complete specification as is required for generation of device driver based on a single device. However, in case of aggregate device drivers (drivers that use services from other devices/drivers), editing the generated code will be required.
How do we publish the APIs generated by the DDGen so that Device driver users can use the generated driver?
The functionality of the APIs are implemented in what is called a “feature” in the DPS file. The name of the feature along with the input and output parameters determine the API signature that will be generated.
The information pertaining to the APIs generated by DDGen in terms of parameters passed, return type and the functionality of the API can also be extracted by “doxygen”.
Since the final source code can be edited directly, it is possible to change the signature/implementation of the generated function. However, this approach is not recommended – changing the corresponding sections in the DPS file is preferred.
Licensing and Support
Licensing and Support
Vayavya labs offers different licensing models to its customers. Click for more details.
The cost of a license depends on the type of license (check above FAQ for details on licensing models). Additionally Vayavya allows for a flexible licensing mechanism wherein a customer can, (at a very high level) define his licensing components (OS support, Processors, interface requirements). The cost for such license will be worked out on individual basis.
Please contact firstname.lastname@example.org for further details.
A typical license will carry a free technical support (over email/telephone) for a period of 3 months from the date of purchase of the license. In addition to this, there will be an on-site training given by our field application engineering team on usage of the tool, writing the DPS and RTS files. This training will be for 2 days. The product license also carries user manuals example code (DPS and RTS).
In addition to this, customers can opt for a paid support. This involves the following:
- Availability of an on-site application engineer charged by per man hour rate (typically for one month). The travel and lodge costs of the engineer to borne by the customer
- An off site application engineering support where our engineering team will help specific device/software related queries and also debug the generated driver code (if required).
- Annual maintenance contract where Vayavya Labs will support the licenses with software upgrades, bug fixes, and additionally the telephone and email support for the licensed product is extended for one year
We keep adding different OS support into the tool as we make updated release of the tool. Adding a support for any new OS into the tool is matter or 6~8 weeks time line.
However if a customer is interested in licensing the tool for a particular OS development activities can be expedited.
We like the concept of Vayavya Labs tools; however we would not like to license the tool as we do not write too many device drivers, so how can we work with you?
Our aim is to simplify the device driver writing and help embedded firms to save on their investments on driver/firmware development costs and timelines. Vayavya can deploy the tool internally to deliver your firmware/driver requirement. We will pass on the benefits of cost and time to your projects. By this way you save on upfront investments in tool and also benefit from savings on development and quicker delivery.
In order to evaluate DDGen please write to us at email@example.com
You could also get in touch with us on telephone at +91-831-2463525.
Please note that, as part of evaluation our sales team will collect certain information like: the primary focus of your firm, size of embedded systems teams at your organization, number of drivers handled by your teams, processor, device, interconnects used in your organization or by your team.
Once you sign up for DDGen evaluation you will get a dedicated point of contact for support. Alternatively you could always contact us in the following ways: