Design of Universal PCIe Interface Module Based on Vs

Due to wide variety of interfaces and complex bus protocols, the general detection system has problems such as high bus usage threshold and poor portability of the host computer software, which greatly reduces the user’s development efficiency of the detection system. In response to the issue, this paper designs a universal interface module for PCIe based on vs. The module provides unified functional interfaces, through which the data transmission of all bus devices can be easily and reliably controlled. In this paper, the design idea of the universal interface module is explained. Finally, the module is illustrated and the result shows that the designed scheme is feasible.


Introduction
With the development of computer technology, the detection system consisting of the main control computer and various expansion modules is widely used in various fields [1]. Due to variety of interfaces of the measured object, the detection system is required to be able to integrate multiple interfaces, and these interfaces need to be able to change as the measured object changes. At present, the interconnected buses with high performance and wide application are mainly Gigabit Ethernet, PCIe, RapidIO, etc [2]. Among them, PCIe (peripheral component interconnect express), a serial computer expansion bus standard, is widely used in the field of embedded detection because of its high bandwidth, optional link number and high transmission speed [3].
For specific application of bus interfaces, each module manufacturer provides mature, complete and powerful APIs to meet various possible needs of transmitting data. However, in most detection systems, only a small part functions of bus interfaces are used, the complicated API parameters and the interfaces that cannot be transplanted due to different application protocols impose high requirements on developers of the detection system. At the same time, the interface matches the respective PC software, so the diversification of interfaces in the detection system results in poor software portability, a large amount of repetitive work for the development of the PC software and high development cost of the detection system. Therefore, how to improve program portability [4], reduce system development costs, and generalize interface applications have become some of the focuses of current research for computer detection systems.
By using the design pattern idea [5] and the technology of virtual function overloading, this paper establishes a unified user-oriented interface model and studies the generalized design of bus interface. The purpose is to make bus interfaces of the detection system intuitive and easy to use, improve the scalability and portability of system software.

Universal interface model establishment
Considering the generality requirement of interfaces, a universal interface model is established as shown in figure 1.  The whole model consists of four parts, in which the application software is responsible for humancomputer interaction, and the hardware devices follow the bus protocols to achieve their respective functions. These two parts are not described in detail in this paper. As a link between the hardware device and the operating system, driver enables the host computer to operate the hardware device indirectly by calling APIs (Application Program Interface) provided by the operating system. Referring to the seven-layer architecture of the Open System Interconnect (OSI) [6], the universal interface module designed in this paper is equivalent to the top layer of OSI, the application layer. Its function is to provide the service interface to the users directly and complete the connection between the application and the network operating system.
As a focus of this design, the universal interface module can be divided into two layers. The upper interface definition layer abstracts and defines various operations and provides general purpose interfaces to users. In addition to basic operation interfaces for data transmission, it also includes additional function interfaces and user-setting interfaces. Through this layer, the application can realize the operation of interfaces of various buses without differentiation, and users can control the data transmission process intuitively, simply and reliably.
The lower interface implementation layer distinguishes the specific application, and further designs and encapsulates the basic APIs provided by the operating system into functional interfaces for the upper layer to call, thereby completing the concrete implementation of the general purpose interfaces defined by the upper layer. This layer further designs and improves the original reading and writing functions of the respective bus. Taking PCIe bus as an example, this layer implements functions such as periodic transmission, packet transmission, task scheduling and fault tolerance mechanism setting to ensure reliable data transmission. The interface definition layer and the interface implementation layer together form a bridge between users and different bus devices.

Universal interface module design
The universal interface module is divided into an interface definition layer and an interface implementation layer. Taking PCIe, RapidIO and Ethernet protocols as examples, the interface definition layer introduces generality and functionality. The design and packaging ideas of this layer are illustrated through the class diagram and important codes. For the interface implementation layer, it takes PCIe as an example to describe how to further encapsulate the operating system APIs into functional interfaces through working timing diagrams, thereby realizing the concrete implementation of general purpose interfaces reliably.

Interface definition layer
Analogous to the black box, this layer shields diversity of different protocols, abstracts APIs under different protocols into general purpose interfaces and provides them to the users, realizing that the application does not differentiate the operations of peripheral no matter which protocol is followed. General purpose interfaces defined by this layer are shown in figure 2.  Through the overloading of above general purpose interfaces, the specific problems solved by this layer include: establishment of unified user-oriented interface model, parameterized design of interface configuration, introduction of general additional functions, design of task scheduling and working pattern. These key issues will be explained in the next section.  as control the entire data transmission process. These interfaces include obtaining the current device list, opening the device, initializing, reading, writing, aborting the transmission, setting the task priority, obtaining the error code, setting the working mode, encrypting, verifying, and turning off the device, which embody the "commonness" of interfaces. The "personality" embodied by different devices is implemented by the factory mode, that is, the DeviceFactory class in the figure 3.
After executing GetDeviceList() in the base class, we can obtain the flag word and the specific number device_num from zero without repetition corresponding to each device. According to the flag word (PCIe device is "PCIe"), the CreateDevice() method in the DeviceFactory class instantiates the InterfacePCIe object, thereby completing the overloading of virtual function under the PCIe protocol. The factory mode makes it unnecessary to change functional functions of each bus class inherited by the base class every time the device is replaced, just instantiating the corresponding object, thereby reducing the amount of code modification and repetition, and achieving the purpose of separating "realization" and "change". Because functional modules of different buses have structural similarities, the PCIe is used for description. The specific implementation code takes c++ as an example: class By instantiating different interface objects, virtual functions in the base class are overloaded in the corresponding interface subclass, and functions under the respective bus protocol are completed in the overloaded functions, thereby realizing the polymorphism required by the system. In other words, the unified user-oriented interface model completes the conversion of dedicated interfaces to general purpose interfaces. There is no method in this class, only the property set to configure the interface information. The reading/writing buffer offset address and the buffer size represent the configuration information shared by all buses. In addition, the 16-byte array m_ParamList[] is declared to store different configuration information required by each bus. For example, CAN requires baud rate and ID number. Ethernet requires IP address and port number. The volume of this array can be adjusted. All searched bus devices should be registered uniformly before the interfaces are initialized, that is, RegisterDevice(PortParam *pPortParam, char *pBuffer) in the base class. All configuration information obtained from users stores in the pBuffer array. According to the size of attributes in the PortParam class, 0-39 bytes in the array represent the configuration information of interface 0, 40-79 bytes represent of interface 1, and so on. In this function, the same number of *pPortParam objects are instantiated to the number of devices, then the configuration information in the pBuffer array is assigned to the corresponding object. The other array DeviceArray[] with the same capacity as the number of devices is created. The assigned *pPortParam pointers are stored in this array, that is, each element in the array represents the configuration information of one device, and the number of each array element represents the number of device, which corresponds to the device_num. In this way, regardless of the addition and deletion of device, it will not affect the registration and configuration of other devices.
In the subclass, the initialization virtual function is overloaded, that is, Init(char *pDeviceArray, device_num). According to the device_num, we can find the corresponding *pPortParam and then parse the configuration information in it, thereby completing the initialization of the interface. At this point, the generalization processing of the universal interface module is also completed.

General additional function.
In order to ensure the reliability and security in data transmission process, the module adds an encryption interface and a verification interface. This design uses the strategic mode to implement the introduction of multiple encryption algorithms and verification algorithms. Through this mode, whether encryption/verification or not and which encryption/verification algorithms are used will not affect the client program, which will achieve high cohesion and low coupling of code, and improve the flexibility of the application.
This mode is scalable and can continue to add verification and encryption algorithm without changing the rest of code. Users can expand the module according to this mode if the system needs to support other data processing functions.

Task scheduling.
Because the system has multiple bus interfaces to share the tasks together, in order to achieve smooth and reliable work during the data transmission process, task scheduling among interfaces is essential. In the case where users do not set the priority of interfaces, the tasks enter the queue by default in the order of arrival, and are executed in order. In order to meet the user's own requirements for the bus scheduling order, the InterfaceBase class in figure 2 reserves the SetPriorityThread (PKTHREAD Thread, KPRIORITY Priority) interface, which is convenient for the users to customize the bus priority. The priority of the transmission task in the program should correspond to the user-defined priority. If there is a task command with higher priority during the task transmission process, the corresponding thread should be created to ensure that the data transmission process conforms to the bus priority set by users.

Working pattern.
In order to make users more intuitive and more convenient to control the data transmission process of the bus device, general purpose interfaces also include GetLastError() and SetOperateMode(). Between them, GetLastError() is used to obtain the error code. Users can customize the error codes according to the possible errors during transmission process and visually monitor the status of the data transmission through the interface.
SetOperateMode(int type, unsigned int port_period, unsigned int interrupt_period) allows users to set the working mode of interfaces manually. Taking PCIe as an example, the first formal parameter represents the custom mode word, including periodic transmission mode: 1, big data transmission mode: 2, and small data transmission mode:3. For the aperiodic transmission, the second and the third parameters default, that is, the timing transmission period and the interruption period to stop periodic transmission. The program determines the required working mode automatically according to the data size when there is no working mode setting. Once the mode is set, it is forced to execute according to the user's command so that user has full control over interfaces. The universal interface module is designed and packaged through the above modes, with clear hierarchy, well-organized code and high maintainability. And the designed interfaces meet the generalized and functional requirements on the basis of ensuring the controllable bus.

Interface implementation layer
In order to improve the reliability of interfaces, in the interface implementation layer, the inherent APIs of each bus are redesigned and encapsulated into functional interfaces, which can be invoked by the interface definition layer to realize generalization of interfaces. Compared with the inherent API, the functional interface makes the data transmission process more reliable. Next, taking PCIe as an example for detailed explanation.
Typical API functions and corresponding callback routines in the kernel driver of the PCIe bus are shown in table 1. CloseHandle EvtFileCleanup EvtFileClose By calling API functions and executing the corresponding routines, the basic communication functions between the host computer and the hardware device following PCIe protocol can be realized [7]. For the data transmission process, this layer firstly solves the selection of bus working mode. Taking PCIe as an example, the design of working mode judgement is shown in figure 4.  Next, according to the user's settings, two types of working modes, periodic transmission and single transmission, will be introduced in detail. In the periodic transmission process, the operation timing diagram is used to explain the judgment and processing of the periodic transmission routine. In the single transmission, PCIe packet transmission mechanism, priority mechanism and fault tolerance mechanism are introduced in detail through timing diagrams of reading and writing processing.

Periodic transmission.
Because the periodic transmission can be regarded as resending data multiple times in a fixed cycle. it is necessary to judge whether the data is periodically sent before processing the data transmission tasks. According to the user's settings, the working timing of the periodic transmission is as shown in figure 5. According to the user's setting SetOperateMode (1, 5, 120), the flag word is 1, which means the data is sent periodically. In the periodic transmission routine, one timer is initialized according to the interface period set by the user for 5s, and the data is transmitted every 5 seconds. The interrupt timer is initialized simultaneously in the routine. After 120s, the transmission is aborted and the corresponding routine of interrupt processing is executed.

Single transmission.
A round of single data transmission includes the most basic reading and writing functions required by the detection system. According to the user's demand for the amount of the transmitted data, this design adopts two working modes: DMA transmission for big data [8] and register transmission for small data.
In order to avoid long-term occupation of the bus caused by data transmission, a packet transmission mechanism is introduced, which is convenient for other operations in the packet transmission gap. In order to ensure the controllability and correctness in the data transmission process, the custom transmission protocol is designed to perform fixed encapsulation processing on the transmitted data in the form of a structure. The data packet protocol is shown in table 2. As shown in the data packet protocol, the data portion occupies 10 KB of space, which is intended to select the data transmission mode automatically according to the data size. When there is no working mode setting, if the data size is less than 10KB, IODeviceControl direct transmission mode is adopted, and if it is larger than 10KB, DMA transmission mode is adopted. The DMA packetization method uses a header packet plus sub-packets. Each of packets has fixed length, and the last one is filled with 0 if it is not full. The sender is the process of unpacking and sending data, while the receiver is the process of receiving and combining packages. Following the data packet protocol, the writing timing is shown in figure 6. Unlike sending data, receiving data has no periodic concept and it is a passive behavior for the host computer. When the hardware device sets the interruption signal of transmitting data, the corresponding event is triggered in the kernel program, that is, WaitInterruptionEvent() in the base class. This interface listens to the event triggers of all buses. Once the event trigger is detected, it will enter the message response function of specific bus according to the trigger message, that is, the overloaded Read() in the corresponding subclass, thereby realizing the generalization of reading process. The reading timing under this design is shown in figure 7.
It can be seen from the reading timing that the fault tolerance mechanism needs to be set for receiving data. In this design, if the verification fails, data will be retransmitted automatically. If the number of retransmissions is more than three, the cause of error will be recorded for later investigation and the receiving process will be cancelled. To continue the data transmission process, sender must resend actively.
In addition, in order to ensure the real-time performance in the data transmission process, considering the dual influencing factors of waiting time and task time [9], this design sets the task priority mechanism -double queue mechanism. The data packets of big data and small data are respectively stored in the two queues, the corresponding number of data packets in the two queues are alternately popped in a fixed number ratio (e.g. large: small = 5:1). After one queue pops up packets, it switches to the other queue. If the number of packets in the queue is less than the specified number, all packets in it are popped up. If the number is zero, the other queue is switched. This kind of priority mechanism, which is mainly based on transmission of big data packets and supplemented by small data packets, has a simple algorithm and can also solve the problem that the time of big data transmission is so long that the system cannot respond in time. At the same time, it can avoid the situation that the big data transmission waits too long due to the accumulation of small data packets.  By introducing the design of periodic transmission and single transmission, this section describes design ideas and implementation methods of the interface implementation layer completely. The functional interfaces designed in this layer are secondarily encapsulated by the interface definition layer to implement general purpose interfaces that meet the design requirements.

Analysis of experimental result
In order to realize the communication bridge with reliability, functionality and versatility, this design proposes a universal interface model. To verify the feasibility of the scheme, this paper uses the PCIe interfaces applying to this model as an example to test. The test contents include reading and writing under the register transmission mode and the DMA transmission mode, and periodic transmission between the host computer software and DSP. The experimental results show that the error rate of data transmission process is low and the communication function of PCIe bus is implemented reliably.
Through multiple tests on the previous designed interfaces, this module is well adapted to the communication needs of different data sizes and multiple transmission modes. The universal module works stably and has simplified, intuitive and unified user-oriented interfaces. Its feasibility is demonstrated by the illustration of PCIe.

Conclusion
The universal interface model designed in this paper is intended to provide users with a simple, intuitive and easy-to-use universal interface module. By modelling, designing and packaging the interfaces, the program is deeply decoupled, which improves its portability and scalability. Although it is inevitable to complicate the design and sacrifice certain performance while obtaining flexibility and scalability of the interfaces, it is acceptable for most application environment of the detection systems. What's more, the generalized and modular design of the detection system, as well as the scalability and portability of the application software, are greatly improved.