A client server model is implemented to interface the testbench with device driver.
A client is defined as a requester of services and a server is defined as the provider of services. A socket is one end of an interprocess communication channel and using which the client and server communicate with each other. The client and server establish their own socket. The Figure1 depicts the socket connection between a single client and single server. In the proposed methodology testbench is configured as the server and device driver as the client.
Device driver can issue the remote calls to the server which are processed by the simulation engine and executes the task as per the call.
At the end of the task server returns the required parameters to the client. The API creates point to point connections. The server is on one side of the connection and client is on the other side. A single process may create both client and server connections but it must not connect to itself. It means that the server should get connected to the client residing in the device driver and not to any of the clients residing in the testbench.
A virtual port number is used to establish 1 to 1 connections. The functions used in the methodology are explained in detail here. A virtual port number is used while defining and bringing up the connection. The activation of the connections use the virtual port number to make 1 to 1 connections of the client server pair. The following snippet of code explains the initialization of socket connection for the client and is developed in C.
The socket interface eliminates the need of any third party tools and software and is more native to the software developers. This section describes the processor emulation model developed for the validation of the device drivers in the verification environment. Alternatively, we have developed a processor emulation model which implements these services and mechanisms those are otherwise implemented by the OS and the real processor. Timers and memory allocation routines may be trivially implemented. For the simulation of the scheduler and interrupt interface, the authors of the paper have employed the POSIX thread library .
Scheduling mechanisms such as waiting on events are trivial and modeled in a simple manner. The only mechanism that requires a degree of extra handling and implementation is the interrupt handling service. The mechanism employed to mimic the interrupt handling service is described below. The interrupt handling mechanism is broken into two threads, namely the normal context thread and the interrupt context thread.
Both these threads are executed concurrently. The normal context thread runs the driver code which would otherwise get executed in a real processor in non-interrupt context. The interrupt context thread monitors the interrupt signal in the simulation environment.
When an interrupt is detected within the simulation environment, the interrupt context thread stalls the normal context via a UNIX signal and proceeds to execute the interrupt handlers within the device driver. Then the interrupt handling mechanism resumes the execution of the main context thread via another UNIX signal. Using this mechanism, the simulation of the processor and the interrupt context switching can be accurately simulated. The normal context thread can be randomly stopped and the interrupt handlers can be executed while the normal context is stalled. The advantage of this model is that faster simulation.
The following two functions explain the implementation of the interrupt context and the normal context threads. These two threads are called from the main function. In this section we describe the interface and access mechanisms to the system bus which is AHB bus those are used by the device driver to perform the read and write transactions. A base class called BUS is created which implements the Vera virtual ports for the bus signals and methods to drive and sample the signals with respect to the clock.
The methods in the base class and the extended class are used to generate the read and write transactions on the AHB bus. The read and write transactions are the actual transaction initiated by the processor in a real hardware.
These methods are developed as global functions and are available as remote procedure to the device driver client. Servicing the remote calls is transparent. At the end of every cycle the vera simulation engine will process the remote calls.
The remote calls will then be dispatched to tasks and functions in the vera program. When these tasks and functions complete, their returned values are sent back to the device driver. The testbench is instantiated in the test case and is named as harness. The global functions globalReadReg and globalWriteReg are the functions which in turn execute the readReg and writeReg available in the harness.
These global functions are available as remote procedure to the client and servicing remote calls is transparent. The global functions declared and defined in the testbench are passed as arguments to the above two system functions. The following piece of code explains the write transaction initiated by device driver and is developed in C.
The function globalWriteReg passed as argument gets executed by the server and the results are passed back using the argrument arg. The following piece of code explains the Read transaction initiated by device driver and is developed in C. The components described in this methodology are depicted in Figure 3. For e. The detailed device driver architecture is explained in Figure 2. It is mandatory for the device driver to adhere to the design scheme described within this section to maintain the source compatibility of the core driver within the emulation and target environments.
The Hardware Protocol component is the definition of the protocol that the hardware peripheral supports and the flow of transactions on the part of the software to support the protocol.
The hardware-software co-design and co-verification of the EHGSoC is deeply explored, whereas a co-design methodology with reconfigurable architecture is a . Co-Design is the set of emerging techniques which allows for the simultaneous design of Hardware and Software. In many cases where the application is very.
These transactions are carried out by successive register access on the part of the software. The Bus Interface is the component that interfaces with the bus that connects the hardware to the microprocessor that executes the driver. The bus interface enables read and write cycles to the device over the bus. The Platform Services are the operating system services which a driver executes within an operating system.
The Hardware Protocol component of a device driver executes all messages which are communicated to the peripheral, while the other described components are facilitators for these transactions. The maintenance of source compatibility between the simulation and target environments would be the ability to employ the same source code for the Hardware Protocol module in both the respective environments. To do the same, it is mandatory for the architecture of the device driver to adhere to the guidelines as is described in Figure2.
Figure2: Device Driver Architecture. The isolation of the Hardware Protocol from the Platform Services and the Bus Interface enables the Hardware Protocol module to operate in an operating system independent environment and the exactly same source code may be compiled for the simulation and target environments. This section explains the procedure to validate the device driver using hardware software co-verification methodology explained in this paper. Also explains the functions to be developed to enable the co-verification in the simulation environment.
Typically co-verification requires the hardware and software components to be run concurrently. The Figure3 depicts the set up used by authors for validating the device driver in RTL verification environment. The procedure to carry out the co-verification is explained in the next paragraph. Figure3: Device driver verification environment.
Test case needs to be developed in Vera to validate the device drivers.
The test case includes only the configuration of the device VIP, configuration of the simulation environment and initialization of the sockets. The test case is run in the native RTL simulation environment, where the simulation control resides with the native HDL simulator. Many type-safe languages allow memory safety violations resulting from unsafe type casting to be detected by compiler. Another approach is to use meta-level compilation MC ,. These extensions need to be written by system implementers in a high level language and dynamically linked to the compilers to do strict static analysis.
Software model checking is the algorithmic analysis of programs to prove properties of their executions.
Model checking and symbolic execution are used to verify the safety-critical properties of device drivers. The input to the model checker is the program and the temporal safety properties. The output is the proof that the program is correct or a demonstration that there exists a violation of the specification by means of a counterexample in the form of a specific execution path. The back end analysis engine SLAM used model checking and symbolic execution for compile time static verification.
The analysis engine finds all paths which can lead to violations of the API usage rules and are presented as source level error paths through the driver source code.
Internally, it abstracts the C code into a boolean program and a set of predicates which are rules that are to be observed on this program. Then it uses the symbolic model checking  to validate the predicates on the boolean program. It uses an abstraction algorithm called lazy abstraction  to build the model from the driver C code. It has been successful in verifying temporal safety properties of C programs with up to 50K lines of code. It is also used to determine if a change in the source code affects the proof of property in the previous version and is demonstrated on a Windows device driver.
Avinux  is another tool that facilitates the automatic analysis of Linux device drives and is built on top of bounded model checker CBMC. Dynamic program analysis is performed by running the program with sufficient test inputs to produce interesting behaviors. Safe Drive  is a low overhead system for detecting and recovering from type safety violations in device drivers. A similar project using hardware to isolate the device drivers from the main kernel is Nook.
Another similar work in this area is on automatic recovery of operating systems due to driver faults. MINIX 3  is an operating system which can isolate major faults, defects are detected and failing components are replaced on the fly.