Adaptive Device Driver Framework for Parallel Hardware Development
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The development of device drivers for hardware is time-consuming and costly due to the need for custom programming and lack of parallel development with hardware design, leading to delays and increased costs from improper documentation and serialization of driver development.
Innovation Solution
A method for specifying device driver parameters on-board hardware, allowing for the customization of adaptive device drivers that interface with board devices and their functional elements, enabling parallel development and reuse of driver components.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a customized device driver is developed from scratch to fit the specific hardware design, then the device driver can be tailored precisely to hardware requirements, but the development time and cost increase significantly
Solution Approach 1:
The device driver is segmented into a framework portion (common functionality) and a customized portion (hardware-specific functionality). The framework can be reused across multiple hardware devices, while only the hardware-specific portion needs to be customized. This segmentation allows parallel development of the framework and hardware design, reducing overall development time while maintaining precise hardware compatibility.
Solution Approach 2:
The device driver framework is developed and prepared in advance, before the specific hardware design is finalized. This preliminary action allows the framework to be ready for customization when hardware development is complete, enabling parallel development processes and reducing the serialization delay between hardware and software development.
2Reliability
If device driver development is serialized after hardware design completion, then hardware can be fully developed and tested first, but software developers lose influence over hardware designs and development time increases
Solution Approach 1:
By segmenting the device driver into framework and hardware-specific portions, hardware designers can provide early specifications for the hardware-specific interface while software developers work on the framework. This enables overlapping development activities and maintains hardware design reliability while improving overall productivity.
Solution Approach 2:
The device driver framework is designed with universal functionality that can accommodate multiple hardware designs. This universality allows hardware designers to iterate on hardware designs while the framework remains applicable, maintaining hardware functionality requirements while enabling parallel development and improving productivity.
3Adaptability or versatility
If a monolithic device driver solution is used to control many different hardware functions, then comprehensive hardware control is achieved, but development and testing become extremely time-consuming
Solution Approach 1:
The monolithic device driver is segmented into a framework portion handling common functions and hardware-specific portions handling device-specific functions. This reduces the complexity of the main framework that needs to be developed and tested, while maintaining comprehensive hardware function coverage through modular additions.
Solution Approach 2:
The framework is designed with universal multi-functionality to handle common hardware operations across different devices. This reduces the overall complexity by eliminating redundant code for common functions, while hardware-specific portions add only the necessary specialized functionality.
4Reliability
If software is written specifically for each hardware device and function combination, then precise hardware control is achieved, but development cost and time increase
Solution Approach 1:
The device driver is segmented into a reusable framework and hardware-specific modules. The framework can be manufactured and distributed once, while only the relatively small hardware-specific portions need to be customized for each device. This significantly reduces development cost while maintaining precise hardware control through the hardware-specific modules.
Solution Approach 2:
The framework portion of the device driver is copied and reused across multiple hardware devices. This copying approach eliminates the need to rewrite common functionality for each device, reducing development cost while the hardware-specific portions ensure precise control for each device type.
Data Source
AI summary
Aspects of the present invention provide a method of specifying a device driver design for a board device. The method includes receiving a board device with various functional elements and on-board storage to be operatively coupled to a computing device through an interconnect. The device driver design is specified through the identification of one or more device driver parameters. The device driver parameters are to be used subsequently to customize an adaptive device driver that interfaces with the board device and each of the one or more functional elements. Device driver parameters are stored in a predetermined storage construct allocated from the board device. These device driver parameters remain stored in the storage construct until there is a need for the board device and corresponding device driver. Customizing the adaptive device driver is done after the device driver parameters have been stored and typically when a computer device starts or ‘boots”. Initially, aspects of the present invention may receive an indication that a board device and one or more functional elements associated with the board device have been attached to an interconnect and requires a device driver. Next, aspect of the present invention retrieve device driver parameters from the storage constructs and customizes the adaptable device driver into a device driver for the board device in accordance with the device driver parameters.