Developing Windows NT Device Drivers: A Programmer's Handbook
Developing Windows NT Device Drivers: A Programmer's Handbook
Improving Driver Robustness: An Evaluation of the Devil Approach
DSN '01 Proceedings of the 2001 International Conference on Dependable Systems and Networks (formerly: FTCS)
A DSL Approach to Improve Productivity and Safety in Device Drivers Development
ASE '00 Proceedings of the 15th IEEE international conference on Automated software engineering
Devil: an IDL for hardware programming
OSDI'00 Proceedings of the 4th conference on Symposium on Operating System Design & Implementation - Volume 4
A domain specific language for video device drivers: from design to implementation
DSL'97 Proceedings of the Conference on Domain-Specific Languages on Conference on Domain-Specific Languages (DSL), 1997
A hardware/software codesign approach for programmable IO devices
GLSVLSI '05 Proceedings of the 15th ACM Great Lakes symposium on VLSI
Cooptimization of interface hardware and software for I/O controllers
Proceedings of the conference on Design, automation and test in Europe: Proceedings
Optimal allocation of I/O device parameters in hardware and software codesign methodology
EUC'07 Proceedings of the 2007 international conference on Embedded and ubiquitous computing
Correctness proofs for device drivers in embedded systems
SSV'10 Proceedings of the 5th international conference on Systems software verification
| Hi-index | 0.00 |
Writing code that talks to hardware is a crucial part of any embedded project. Both productivity and quality are needed, but some flaws in the traditional development process make these requirements difficult to meet.We have recently introduced a new approach of dealing with hardware, based on the Devil language. Devil allows to write a high-level, formal definition of the programming interface of a peripheral circuit. A compiler automatically checks the consistency of a Devil specification, from which it generates the low-level, hardware-operating code.In our original framework, the generated code is dependent of the host architecture (CPU, buses, and bridges). Consequently, any variation in the hardware environment requires a specific tuning of the compiler. Considering the variability of embedded architectures, this is a serious drawback. In addition, this prevents from mixing different buses in the same circuit interface.In this paper, we remove those limitations by improving our framework in two ways. (i) We propose a better isolation between the Devil compiler and the host architecture. (ii) We introduce Trident, a language extension aimed at mapping one or several buses to each peripheral circuit.