A New Methodology for Hardware Software Co-verification

By Venkata Giri Kumar, Manoj Ariyamparambath, Bashuman Deb
Synopsys India Pvt Ltd
Bangalore, India

Abstract:

Traditional methods of hardware software co-verification use either the industry standard accelerators/emulators or the instruction set simulators. Both the methodologies are well proven and are well established in SOC verification environment. The design, development and validation of device drivers require these tools and software and it would be an expensive proposition for IP developers. These methodologies may not be appropriate for the validation of the device drivers developed for IPs. The authors proposed a new methodology for the hardware software co-verification which is used to validate the device drivers using the RTL verification environment. This methodology reduces simulation time and also effectively re-uses the verification environment.

The methodology applied is by developing the device driver using platform-independent guidelines and executing it within a microprocessor-like environment, which connects to the RTL verification environment over inter-process communication channels.

In the current work, the authors have demonstrated the efficiency of the methodology by developing drivers which required minimal changes when ported to the hardware platform.

1. INTRODUCTION

Recent advancements in the processor based accelerators/emulators and instruction set simulators enabled the SoC developers to verify the device drivers using the hardware software co-verification techniques. State of the art tools and methodologies are available to integrate the software into the hardware at RTL verification stage and provide a complete solution. Typically the design phase of SoC focuses on the IP reuse and the verification phase addresses the validation of the associated device driver in the hardware/software co-verification. The SoC developers might demand the IP developers for a sample device driver or a full fledged device driver. In any case the traditional co-verification techniques would invite considerable investment for host controller IP developers if they wish to provide device driver along with their IP.

The system level platforms [1] enable the software developers to start validating the software well before the availability of the silicon. These platforms require hardware models developed in C/C++ to integrate into their environments. This could mean additional effort.

The processor based accelerators/emulators [2] are used to perform hardware/software co-simulation. Software debug environments can be connected to these emulators which enable the device driver developers to validate their code concurrent to the hardware verification. Emulation based verification enables the software designers to validate the embedded software even before the first silicon is available. The emulation based co-verification suites well for the SoC platform but it becomes an expensive solution for IP developers.

The hardware software co-verification using Instruction Set Simulators (ISS) [3] involves the processor specific ISS, logic simulator and the RTL model of the IP. Transaction based acceleration uses the Standard Co-Emulation Modeling Interface (SCE-MI) to connect the logic simulator to ISS. Alternatively an industry standard PLI interface can be used to connect the logic simulator to ISS. Whenever an IO or memory mapped IO instruction is executed the ISS passes the IO to the simulator and the resultant output is passed back by the RTL to the ISS. The ISS based co-verification is relatively less expensive compared to the emulator based co-verification. The disadvantage with ISS based co-verification is that the simulation performance goes down as the number of interactions between the ISS and simulator increase.

In this paper, the authors have proposed and developed a new methodology for the hardware software co-verification to validate the device driver in RTL verification environment. The proposed methodology overcomes the disadvantages of the above two techniques. The authors have validated the device driver developed for one of their host controller IP using this methodology. The host controller IP uses the AHB as the host interface. The validated device driver is ported into the real hardware without any change in the actual code.

The paper is organized as follows: In Section 2, we introduce the methodology and the flow. Each step in the methodology is detailed in the subsequent sections (Section 3 – Section 6).

2. OVERVIEW OF THE METHODOLOGY

This section explains the methodology proposed for the Hardware Software co-verification which enables the validation of the device driver at the RTL verification stage itself. This methodology does not use any of these industry standard co-verification tools like accelerators/emulators or Instruction Set Simulators. The authors have developed a new methodology to perform the co-verification which enables the IP developers to validate the device drivers without using any of these expensive emulators and instruction set simulators. The validation of the device drivers using this methodology would be more native to the software developers and does not require any knowledge and expertise in third party tools and software.

The IP verification environment is developed using Hardware Verification Languages (HVL) like VERA. The device driver is developed using software languages like ‘C’ and runs on the operating systems like UNIX / Windows. In the current paper authors have used VERA to develop the verification environment and ‘C’ to develop the device driver. The methodology has been verified in Linux platform.

The methodology proposes a well defined flow to enable the hardware software co-verification in the RTL verification environment. The following steps are defined to implement the methodology

1. Component and Interface Definition
2. Device Driver Architecture
3. Co-Verification

The authors have designed, developed and validated the device drivers using this methodology. The underlying concept is that the device driver validation re-uses the existing RTL verification environment and adds only the requisite components and interfaces to seamlessly integrate the device drivers into the environment.

3. COMPONENT AND INTERFACE DEFINITION

The following components are defined to enable the hardware software co-verification 1) Socket Interface, 2) Processor Emulation Model and 3) VERA Method Interface.

3.1 Socket Interface

The authors have chosen the socket communication as an interface mechanism between the hardware and device driver. The socket communication is primarily used in hardware software co-verification. The testbench which includes the DUT, BFMs, Monitors and checkers constitute the hardware component and the device driver becomes the software component in the hardware software co-verification.

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.

Figure1: Client Server Model

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.

A set of functions in the form of API are available in VERA [6] which supports the hardware software co-verification.. The API creates point to point connections. A connection consists of a client/server pair. 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. The functions defining the socket connections are vsv_make_server and vsv_make_client. The function that activates the socket connections is vsv_up_connections and execution of this function activates the defined connections. 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 server.

task initializeServer ()
{
}

The following snippet of code explains the initialization of socket connection for the client and is developed in C

static int intializeClient (int *conn)
{
}

The socket interface eliminates the need of any third party tools and software and is more native to the software developers.

3.2. Processor Emulation Model

This section describes the processor emulation model developed for the validation of the device drivers in the verification environment.

A device driver traditionally leverages services extended by an operating system for scheduling, memory allocation, timers, mutual exclusion & locking mechanisms and interrupt handling. In our methodology we don’t use processor and OS components to validate the device driver. 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 [4]. 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 processor emulation model is developed using ‘C’ and standard POSIX thread library. 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.

static void interrupt_context_start(void *arg) {
}
static void normal_context_start(void *arg) {

3.3 VERA Method Interface

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 base class BUS is extended to HOST_BUS class, which implements the AHB protocol. 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 methods in the BUS and HOST_BUS classes are interfaced to the device driver using global functions and tasks. The testbench is instantiated in the test case and is named as harness. The readReg and writeReg methods available in the harness execute AHB Read and AHB Write transactions respectively. 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 following code explains the functionality of the globalReadReg.

function integer globalReadReg (integer address) {
globalReadReg = harness.readReg (address);
}

The following code explains the functionality of the globalWriteReg.

function integer globalWriteReg(integer address,integer val) {
globalWriteReg = harness.writeReg(address,val);
}

There are two system functions available namely vsv_call_func and vsv_call_task which can submit remote calls from vera program (server) to a remote client. 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 system function vsv_call_func submits a remote call to the vera program. The argument client_id is the virtual port number defined during the client connection. The function globalWriteReg passed as argument gets executed by the server and the results are passed back using the argrument arg. The argument return_value is a variable that matches the type returned by the remote function. The argument, no_of_arguments, must match the corresponding arguments of the function side.

u32 set_register (Controller_Reg reg, u32 val) {
}

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.g. the Component and Interface definition is mapped to Vera socket i/f and processor emulation model. The detailed device driver architecture is explained in Figure 2.

4. DEVICE DRIVER ARCHITECTURE

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. All device drivers can be divided into three distinct parts, 1) The Hardware Protocol 2) The Bus Interface and 3) The Platform Services.

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. 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. These services typically are memory allocation/de-allocation, locking and exclusion primitives, interrupt handling, timers and interfaces to the scheduling infrastructure.

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.

The device driver used in simulation environment would contain only the following: Hardware Protocol, Register Access API components, Socket i/f and Processor emulation model tasks.

5. CO-VERIFICATION

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. After completing the initialization the server component, the testbench waits for socket connections to be established by the client residing in the device driver. The device driver needs to be executed in the same host machine in which the simulation is running and is executed before any specified socket connection timeout happens on the server side. Once the connection is established, the device driver can initiate the transactions towards the device through the host controller DUT.

The device driver code can be partitioned into two parts namely platform dependent and platform independent. The co-verification does not require the platform dependent code and uses the platform independent device driver code as is but for the function which performs the read and write transactions. The device driver uses the processor interface to perform the read and write transactions and hence cannot be used with the simulation environment.

The following functions belong to the device driver ported to the actual hardware.

u32 set_register(Controller_Reg reg, u32 val)
{
}

u32 read_register(Controller_Reg reg)
{
}

In our methodology, the additional requirement is to develop new functions with the same name and same arguments to perform the read and write transactions in the simulation environment. These functions are developed using socket communications as explained in section 3.3.

6. ADVANTAGES OF THE METHODOLOGY

The co-verification methodology described in this paper is well suited to the IP developers and has many advantages compared to the traditional co-verification methods.

The simulation speeds using this methodology are faster compared to the methods which employ the instruction set simulators. The ISS executes every instruction and interacts with the simulation environment for every IO/Memory transactions. The simulation speeds come down drastically if there is more number of IO/Memory transactions. Whereas the proposed methodology exhibits faster simulation speeds as it does not need to execute the instructions to perform IO/Memory transactions.

The development of verification flow using this methodology is extremely simple and uses the standard operating system services. The development is much more complex when the industry standard accelerators/emulators are used. It also requires the knowledge and expertise of the third party tools and software. Moreover any issues with these tools need attention of the third party vendor which is a time consuming process.

The cost incurred in deploying the proposed methodology is almost zero. The other traditional methodologies are much more expensive and need to procure the relevant hardware and software tools. This would be an additional investment for the IP developers.

The other advantage with this methodology is that it is independent of the processor interface used in the IP. The device driver developed using this methodology does not get constrained by the specific cross compiler and can be used with any processor. The host controller IP developed for a particular processor interface may get converted to a different processor interface but device driver can be reused without any modifications.

7. LIMITATIONS OF THE METHODOLOGY

The co-verification methodology described in this paper has the following limitations.

The processor emulation model does not model all the OS related services. The interrupt handling and context switching modeled here is not a timing accurate representation of a real time system with processor model. The latency associated with the real processor and OS are not modeled in this methodology.

CONCLUSION

In the current work, the authors have developed a new methodology for hardware software co-verification without using the industry standard tools and software. The device driver developed using this methodology is validated successfully with one of our host controller IP [5]. Later device driver is ported successfully into the actual hardware and the porting is seamlessly done without any change to the actual code. The device driver software developed and validated using this methodology is successfully used by the customers with their actual silicon.

REFERENCES

[1] Virtual platforms

[2] Accelerators/Emulators

[3] Instruction Set Simulators

[4] POSIX thread library

[5] Synopsys Designware Mobile Storage Host Controller IP

[6] Open Vera User Manual