设备驱动开发模拟框架

设备驱动开发模拟框架

译自：《A Simulation Framework for Device Driver Development 》 BY Yan Shoumeng Zhou Xingshe

刘建文略译（ http://blog.csdn.net/keminlau ）

Dept. of Computer Science & Engineering

Northwestern Polytechnical University, Post Code 710072

Xi'an, China

KEY:驱动开发 模拟技术

ABSTRACT

Traditional development method of device driver becomes more and more unacceptable along with the increasingly deeper application of special devices.

With a view to shorten the development cycle, this paper analyzes the traditional development model of such system, and presents a new co-development model based on device simulation. It gives the detailed design of device simulation . It also provides the implementation detail of related tools for easier simulation deployment. The simulation mechanism and the simulation tools together form a simulation framework for device driver development. The simulation process using the framework is discussed and an example application is presented.

随着特殊设备应用的深化，传统的设备驱动开发方式变得越来越不被接受。 为了缩短开发周期，本文首先分析了传统的开发模型的特点，并展示一种新的基于设备模拟（device simulation）的协助开发模型（co-development model）；接着给出设备模拟的详细设计。为了简化模拟的部署（deployment），也给出了相关工具的实现详细。模拟机制和模拟工具一起组成了一 个设备驱动开发的模拟化框架。最后讨论了使用这个框架的步骤，并给一个应用例子。

INTRODUCTION

Proprietary I/O devices are often involved in many computer application systems. In such scenarios, Developers have to develop drivers for these devices to utilize them under some operating system.

Traditionally, development of device driver can be undertaken only after hardware design finishes, for the writing and debugging process involves many interactions with real hardware. However, with the increasing competition among corporations, shorter time to market is important for a successful production.

现在很多计算机系统需要配备一些专用I/O设备，为了使用这些设备，开发者必须为它们编写在指定的操作系统下的软件（驱动程序）。在传统的开发方式下，编写设备驱动软件必须与实体硬件进行交互，设备驱动的开发被延迟到实体硬件开发完成之后。而在这个竞争激烈的市场里，更短的开发周期对产品的成功至关重要。

To shorten the development cycle of device driver, this paper proposes that using a simulation device as the target of driver's operations.

为了缩短开发周期，本文提出使用 模拟设备 作为驱动操作的目标。展示如何创建基于I/O设备的抽象模型的设备模拟机制。

 

模拟如何可能？

 

摘自《计算机体系结构软件模拟技术》 喻之斌等

计算机系统本身是一个非常复杂的系统,要使用软件来模拟 每个晶体管或每个门电路各个方面的行为特征 几乎是不可能的.人们简化系统复杂程度的常用办法是对系统按层次进行抽象,体系结构就是对计算机系统在结构层次上的简化.然而,体系结构层次上的计算机系统依然很复杂,开发其软件模拟器也因此而十分困难.

另外,目前开发软件模拟器使用的主要编程语言是 C 或 C++语言,这些语言是串行结构化语言. 使用这种语言的固有机制 ,如函数或类来模拟计算机系统部件的功能和行为 ,是一个非常耗时且容易出错的过程.

Previous works on device simulation focus on how to support development of application level software. VxSim[1], a component for platform simulation in VxWorks Tornado environment, support application software which requiring very simple interactions with hardware, but is not suitable for software with extensive device accesses, especially device drivers. A simulation development method for device driver is proposed in paper [2], which simulates all system routines in an application and compile and link the driver source code with the application together. This method can only make some testing work on device driver , but cannot support the simulation of the running of the entire application system that based on the device driver.

This paper presents a device simulation mechanism based on an abstraction model of I/O devices. Then a simulation framework for device driver development is discussed. This framework can effectively support writing and debugging of device driver without the need of hardware existence. For the running of application software is relying on the underlying device driver, it is natural that this framework also supports the development of the entire system without requiring hardware involvement.

DESIGN OF DEVICE SIMULATOR

According to analyses of various devices, we abstract I/O device as follows:

Among above formulation, REG denotes the interface registers of device; IRQ denotes the interrupt request number occupied by the device; LOG denotes the action logic, i.e. what action device should take under certain conditions. So, if we can simulate the three elements of above device abstraction model properly in a software module , we can say we have simulated the device successfully.

The software module, which simulates the three basic elements of real hardware, is called device simulator . In essence, it is also a driver module residing in kernel address space.

We will describe the detailed simulation mechanisms for the three elements in the following of this section. Basically, the REG is simulated by a kernel memory buffer ; the IRQ is simulated by a variable ; and the LOG is simulated by a user-provided switch-case routine , which is called by a kernel timer handler periodically. We will also give the primary data structure of device simulator.

对不同的设备进行抽象，得到以下一个公式：

HW ::= (REG，IRQ，LOG)

这个公式中，REG代表设备的接口寄存器；IRQ代表设备占用的中断请求号；LOG代表设备的动作逻辑（action logic），比如在一个特定的事件下，设备执行什么操作。由此可得，如果我们通过 软件模块 正确地模拟了以上设备抽象模型的三个要素的话，我们可以说成功地模拟了实际设备。这三个代表真实硬件的 软件模块 被称为[设备模拟器 ]，实际它们也是运行在内核空间的驱动模块。

• REG模拟为内核内存的缓冲区；
• IRQ模拟为一个变量；
• LOG模拟为一个函数，内有switch-case多路分支流程，被内核定时处理函数（kernel timer handler）不断地重复调用；

(1) Simulation of Registers

It is well known that address space of a process consists of user space（accessible in user mode）and system space（accessible in kernel mode）. System space is used to load the kernel components of operating system and is not accessible to application level. The space is made up of non-paged memory areas that are always visible whether the user space is active or not. Device drivers, of which both code and data reside in the system space, have read and write access rights to the entire system space. Therefore, if a driver can know the variables address of other drivers, it should be able to access the variables.

我们知道驱动模块是内核的组成部分，运行在内核空间，可访问内核空间任何地址（内核是由无分页内存区组成，任何内核代码均可访问）。因此，如果当前驱动模块知道另一驱动模块的变量地址，是可直接访问的。

Based on this point, the registers of device can be simulated simply by an unsigned character array or some memory allocated from non-paged memory area.

Considering flexibility requirement, we choose the second method, i.e. dynamically allocating certain
amounts of non-paged memory. This method enables us to change the number of register conveniently with the change of hardware design. Herein, a critical problem to solve is that other drivers, i.e. real drivers of devices, how to know the address of these simulated registers. Our solution is to introduce an intermediate medium. When the device simulator module is loaded, the head address of registers is decided. Then we can log the address into the intermediate medium, through which the real driver can get the address information of simulated registers and can access them thereafter.

基于这一点，[模拟设备的寄存器 ]可以简单地通过一[无符号字符数组 ]或少许的[无分页内存区 ]来模拟。考虑到灵活性的需要，我们选择了后者。比如，动态地分配一定的无分页内存空间。这样我们可以在硬件设计更改时轻易地增减寄存器的数量。这里有一个很严重的问题需要解决，就是驱动模块怎么知道这些模拟的寄存器的地址？我们的解决办法是利用中间媒介。当设备模拟器被载入系统后，寄存器的首地址被分配，然后我们把这些地址记入（log）中间媒介，驱动模块可以通过它来取得寄存器的地址并访问它们。

(2) Simulation of IRQ

The interrupt process mechanism in X86 architecture can be described as follows:

• Interrupt signal is sent from peripheral to interrupt controller chip or module
• Interrupt chip transform the signal into data signal and send it to CPU
• CPU search the IDT and get the vector entry
• Jump to certain interrupt service routine

Based on this knowledge, we can use a variable to simulate the IRQ and call int n directly to simulate the interrupt triggering. Herein, n is not the variable denoting IRQ but the index in IDT transformed from IRQ. The transformation, which is fulfilled by interrupt controller in real environment, can be different in different OS platforms. For example, it is to simply plus 0x20 on LINUX, but on Windows it involve special system call to complete this transformation.

X86体系的中断处理过程大概如下：

1. 设备发送中断信号到中断控制器芯片；
2. 中断控制器将中断信号转换为数据信号并发送给CPU；
3. CPU检索中断向量表（IDT）并取得中断处理入口地址；
4. 跳转到相就的中断处理函数，并执行。

由此可见，我们可以使用一个变量来模拟IRQ号并直接调用机器指令[ int n ] 来模拟中断事件触发。这里，n并不是中断请求号，而是根据中断请求号转换过来的中断向量（中断向量表的索引）。这个转换在真实环境是由中断控制器完成的， 不过转换规则在不同的OS平台有所不同。比如，it is to simply plus 0x20 on LINUX, but on Windows it involve special system call to complete this transformation.

Otherwise, we in fact can simulate the interrupt controller using an independent driver which checks whether interrupt should be triggered or not periodically and simulates the sending of interrupt to CPU. But for simplicity, we trigger the interrupt in each device simulator module directly.

实际上，我们也可以编写一个驱动模块独立地模拟中断控制器的行为，由它来决定中断的触发。不过为了简单起见，我们直接在设备模拟模块内触发中断。

(3) Simulation of Action Logic

The simulation of action logic of device under various conditions is a difficult point in the simulation mechanism. For real hardware, the detection of condition changes is accomplished through circuit behavior. If want to simulate it by software, we must have a mechanism to detect the changes of condition actively and take suitable process according to conditions.

对[ 设备的动作逻辑 ]进行模拟是实现模拟机制的难点。对于实际硬件，设备的动作逻辑实质是电路行为（circuit
behavior），也就是说设备的动作（状态改变）表现为电路状态的改变。如果我们要用软件来模拟，我们必须实现一种检测状态改变的机制，并且根据相应的状态作相应的动作处理。

Therefore, a kernel timer is adopted to detect current condition and take certain actions periodically. The timer is started in the device simulator module. And when the period expires, a “case-switch” function is called. It deserves to note that the granularity of timer is related to the simulation fidelity（忠实; 忠诚; 诚实 ）. Thus, the practical value of the period should be decided according to practical condition, or it should be able to adapt in the simulation process.

因此，内核定时器（kernel timer）被引入，实现当前状态检测和执行周期性动作。定时器在设备模拟模块内启动。当定时时间到，一“case-switch”函数被调用。这里必须注意，定时器的时间粒度（granularity）依赖了模拟的真实程度。因此，这个时间值的实际大小取决实际情况，或者能够在模拟过程中随时调整。

Considering that the driver developer of real hardware is the most familiar to hardware specification, we propose that they should present the “case-switch”function. Herein, we only provide the reference method to implement the function. A good way is to introduce the finite state machine (FSM) theory into describing the device behavior. The interface of device can be viewed as a FSM, states of which are the snapshot of the interface registers at certain time and inputs of which are writing values from real device driver and device control panel (will be described later in detail). The description based on FSM can be transformed by a special tool into practical program code as the simulation implementation of action logic.

我们假设驱动开发者对实际硬件的硬件规格 （specification）是非常熟悉的，并且他编写了各种“case-switch”处理函数。这里我们只提供实现这些函数的一些方法作参考。其中 一种比较好的方法，就是引入有限状态机理论来描述设备行为。设备的接口（控制器）可看成一台有限状态机，它的状态（states）指接口寄存器的某一时刻 的快照和来自驱动程序（或设备控制面板）的输入值。The description based on FSM can be transformed by a special tool into practical program code as the simulation implementation of action logic.

(4) Simulation of Register Access

The register access routines provided by system should be replaced so that the accesses in real device driver to registers can be redirected to the registers array of device simulator. In the simulation implementation of register access routine, a access action is divided into two steps: first getting the address of the simulated register array, then taking the real memory access action. Concurrent access to registers is possible for the support for online edit capability, which involves access to registers in device simulator. Therefore, the simulated registers are critical resources and system mutex 互斥(体) primitives should enclose the register access routines. The rewritten register access routines will be provided as a head file, and the real device driver project, to replace the system register access routines, just need to include that file. When the real hardware is finished later, we just need to discard the head file and rebuild the project to get the final device driver.

为了把对实际硬件寄存器的访问重定向到访问设备模拟器的寄存器组，系统提供的[寄存器访问函数 ]（设为Real_Acc)必须被替换。在[寄存器访问函数]的模拟实现（设为Sim_Acc）里，访问操作分两步：第一步取得模拟寄存器组的地址；第二步 执行内存访问。为了提供在线编辑的功能，可能会发生并发对寄存器组的访问，这样模拟的寄存器组成了竞争资源，必须对寄存器组实现互斥操作。Sim_Acc 函数会以头文件的形式实现，在实际的设备驱动项目里，这个头文件就是前面说的，用来替换系统提供的Real_Acc函数。当实际硬件完成开发后，我们只需 要删除的Sim_Acc函数头件文件，重建项目就可以了。

(5) Primary Data Structures

The implementation of device simulator is object based. We encapsulate the attributes and behaviors of device simulator in a structure. Herein, we adopt C language for C is the common language of driver
development. Each device simulator maintain the following data structure:

typedef struct tagSimHardware{ unsigned char *m_pRegister; //address of registers unsigned int m_uRegNum; //number of register unsigned int m_uIrq; //IRQ number unsigned int m_uPeriod; //timer period KTIMER m_Timer; //Timer pointer of member function //initialize hardware bool (*init) (PSIMHARDWARE this, unsigned int uRegNum, unsigned int nIrq, unsigned int Period); //action logic as the callback function of timer void (*ActionLogic)( PSIMHARDWARE this); //change the IRQ void (*SetIrq)( PSIMHARDWARE this); //change timer period BOOL (*SetPeriod)( PSIMHARDWARE this, unsigned int uPeriod); //save information of device simulator to medium void (*SaveConfig)( PSIMHARDWARE this); //simulation of interrupt triggering void (*GenerateInt)( PSIMHARDWARE this); } SIMHARDWARE,* PSIMHARDWARE;

SIMULATION TOOLS

This section discusses the design of aiding tools for easy simulation deployment

(1) Device Control Panel

In many cases, driver developers expect for some control capabilities over device simulators. Demands can be list as follows.

• The design of hardware can be changed frequently. The device simulator module should reflect the latest change timely and easily.
• The behavior of real device is usually difficult to control to reoccur some cases. But this capability is required in driver debugging. Thus, it would be better if device simulator module can provide functions such as register save and restoration, register edit, and interrupt generation.
• Otherwise, in the different phases of driver development, what matters is different. This demands the precision of simulator can be adjust easily.

本小节讨论辅助简化模拟部署的工具的设计。很多时候，驱动开发者有对设备模拟器进行控制或调整的需求，这些需求包括：

• 硬件设计的更改。相应的设备模拟器必须能简单快捷地跟着更改。
• 真实硬件的行为通常是很难控制它重复同一个行为动作的，但这个功能往往对驱动程序调试很有用。如果设备模块器模块提供诸如寄存器值的保存与恢复、寄存器编辑和中断触发等功能，则对驱动开发非常有益。
• 还有，在驱动开发的不同阶段，对精度要求不同，这要求模拟器能轻便的调整它的精确度。

The device control panel, an application level software that interfaces with the kernel mode device simulator, can meet these demands. Using this tool, developers can generate an interrupt manually; can change the IRQ of certain device simulator; can display and edit the registers; and can adjust the precision of simulation. In implementation, the device control panel is a user interface to the underlying device simulator and provides a channel to control the behavior of simulator.

Device simulator processes the control command issued from device control panel in IOCTL file operation. It first get a unique control command according to IOCTL number, then call functions such as GenerateInt, SetIrq, SetPeriod, SaveConfig to fulfill the required operations.

[设备控制面板 ]就是为了满足以上需求面开发的。[设备控制面板]是内核态的设备模拟器在用户态的接口。通过这个工具，开发者可以手动触发中断请求，更改某种设备模拟器的IRQ，查看和编辑寄存器的值和调整模拟的精度。在实现上，[设备控制面板]是相应设备模拟器的用户接口，提供控制模拟器的行为的通道。设备模拟器以IOCTL文件操作实现处理来自控制面板的[控制命令]，它首先根据IOCTL号取得唯一的[控制命令]，然后调用相应的功能函数，如 GenerateInt, SetIrq, SetPeriod, SaveConfig 。

(2) Simulator Auto-generator

Major implementation parts of device simulator are definite, which make it possible to provide a auto-generator of device simulator. We have designed a tool like the MS Visual Studio AppWizard, by which developers only need to provide a few indefinite aspects of implementation through friendly user interface. The tool will integrate the user input and the predefined simulator driver template and then produce a specific device simulator. Through using this tool, the difficulty of simulator development is lowered greatly, and the development cycle is shortened.

设备模拟器的主体被实现以后，可以被模板化，做成模拟器自动生成器（simulator auto-generator），然后根据各不同特征的设备（device specification）再自动生成相应的模拟器。

SIMULATION PROCESS IN THE SIMULATION FRAMEWORK

This section describes the entire simulation process in the simulation framework.

Firstly, the developer should generate a device simulator according to his device specification using the simulator auto-generator. Secondly, he should load the simulator and the real device driver into system.

Now, the upper layer application and the device driver can run just as if there is a real underlying device. The developer can easily produce the exceptional device condition through manipulating the simulator's registers and has exceptional code path of the target device driver tested sufficiently. If the device specification changes, the developer can also easily modify the simulator through deice control panel to reflect the change timely.

使用模拟框架过程大概如下：

首先，利用[模拟器自动生成器]生成设备模拟器；

接着，载入该设备模拟器及其驱动程序到系统；

到这里，应用层软件与驱动程序已经分别正常运行，仿佛有一个真实的设备在系统中。 然后，开发者可以开始对设备及设备驱动进行测试，包括使用[设备控制面板]。

Fig.1 gives the interactions among the relative components in this simulation framework.

APPLICATIONS

This section gives an application example of this simulation framework. By using this framework, the
device drivers in this application have been sufficiently programmed and tested before real hardware became available. And thus, the development period is greatly shortened.

The application system is a data acquisition system based on airborne computer. In the computer, there is a smart communication card, which is responsible to receive data from eight data channels.

The application software is responsible to fetch data from the card and save them to disk. At the same time, it also draw the data change curve on the screen and give an alarm when exception is detected.

Components of the system are presented as fig 2.

有了这个框架后，我们可以在实际设备硬件完成之前，完成设备的驱动程序相当的开发和测试工作，大大缩短开发周期。这里给出一个例子。

Our task is to develop application software and device driver for the smart communication card.

Because the smart communication card had not been completed, we can't make software programming and testing in detail. The overall development process is delayed for a time. Later, we adopt the simulation framework proposed by this paper and alleviate this problem to a great extent. Before hardware design is finished, we have developed and tested the device driver and application software sufficiently. Thus, the development cycle is shortend. Fig. 3 gives the simulation running of the application software without real hardware involved.

CONCLUSIONS

We have presented a driver development method based on simulation. The device simulation mechanism, the device control panel and the simulator auto-generator have formed a simulation framework.

Currently, this framework has been integrated into an IDE for CC-LINUX, in which it is used to support simulation debugging and simulation running of embedded system. The practices have proved that this framework can shorten the development cycle efficiently. What should be done next is how to simplify the deployment of action logic . We hope to provide a tool, which can help developers describe the action logic in FSM and generate code automatically for action logic based on the description. This will be the direction of further study.

小结，模拟框架主体由三部分组成：设备模拟机制、设备控制面板和模拟器自动生成工具。我们下一步该研究的是如何简化动作逻辑的部署。我们希望提供一种[ 工具 ]，利用它协助开发者用FSM描述动作逻辑，并且根据这些描述[ 自动地 ]生成代码。

REFERENCES

[1]VxWorks Tornado Online Help.
[2]Eddy Quicksall and Ken Gibson. Simulation and Device-Driver Development, Dr. Dobb's Journal, 1997 (1).
[3]Development Techniques for Using Simulation to Remove Risk in Software/Hardware Integration,
http://www.redhat.com/support/wpapers/cygnus/cygnus_risk/development.html.
[4]Jiang weihua and Yu huqun. A Co-simulation method for embedded system design(in Chinese),
Journal of East China University of Science and Technology, Vol. 27 No.5:475-479.
[5]Liu mouyong and Ge jiguang. Implementation of Virtual Hadware in Operatiing System Design (in
Chinese) [J]，Journal of Zhejiang University，Vo l . 3 3 No.4:351-355.