- 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.
Yes, Find it here Japanese FAQ
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.
- 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)
- Semiconductor firms (IC/ASIC/SoC makers)
- IP vendors
- OS vendors and
- Embedded Design Services firms
- 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.
Is the generated driver configurable for optimizations on power consumed, code size and performance?
- Write the DPS and RTS by looking at the datasheets and design documents
- Use the tool to generate new set of drivers
What is the extent of testing that has been done on the generated code? How can I be assured of quality?
- 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
What are the comparison figures (performance vs. size) for the tool generated code to hand written code?
Is the generated code specific to a processor and compiler tool-chain? If yes, how can I control the processor/tool-chain being used?
Is the description in DPS sufficient to generate a full driver, or what will be generated just a skeleton?
How do we publish the APIs generated by the DDGen so that Device driver users can use the generated driver?
Licensing and Support
- 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