Protocol Stack Development Process

The rise of the network and the development of the communication technology of Apsara stack have been accompanied by the development of the software radio ideology and technology. Among them, it is worth noting the content of protocol stack development. In modern digital communication systems, DSP and other digital signal processors are increasingly used in combination with high-speed AD and DA Converters for the modulation and demodulation of physical layer signals in the OSI Layer-7 Communication System Model) and data link layer channel coding and decoding. in recent years, the theory of digital signal processing has developed rapidly, and the frequency and capability of digital signal processors have been constantly improved. More and more work in digital communication systems can be completed through DSP, as a result, the program structure of DSP is becoming more and more complex. communication Signals, especially wireless communications, have strong real-time and random characteristics, resulting in a lack of regularity in DSP input data, as a result, problems in the corresponding processing program are not easy to reproduce, and the problems are difficult to track and capture, which brings great difficulties to the DSP program design and debugging. to address this problem, this paper designs a data collection and simulation system suitable for protocol stack development and debugging Based on the Data Processing Methods of the general underlying communication protocol stack, to track, reproduce, and find program defects.

1. Data Collection System

The data collection system collects data from a working communication terminal.

1.1 collection point selection

The entire communication system has multiple data collection start points (Optional). You can directly sample the intermediate frequency signal, sample the baseband signal, and simulate the AD data receiving sequence in the system, directly receives AD output data. however, the first two collection points cannot ensure that the collected signal data is exactly the same as the DSP input data. The analog AD data timing may affect the master-slave relationship between DSP and AD, it affects the normal operation of the DSP protocol stack, and it is also difficult to collect various external interruptions. therefore, the most secure way is that the DSP outputs the data it receives through the data bus. the disadvantage of this method is that it requires a small amount of DSP resources, but this is completely negligible compared with the protocol stack operation, without affecting the protocol stack development and its own operation.

1.2 hardware connection

Reference [1] analyzes and compares various data collection systems, and points out that the USB Bus is an ideal interface between data acquisition card and PC. Therefore, CY68013A is used as the USB interface chip. one FPGA is used to convert the data format between DSP and CY68013A. The CY68013A firmware program is stored in E2PROM and connected through I2C bus.

In addition to the 16-Bit Data Bus output, the DSP also extracts the seven-bit address line A0 ~ A6), used to distinguish different data types. FPGA must convert the data format output by the DSP external bus into a format compatible with CY68013A external GPIF.

1.3 FPGA Program Design

The CY68013A external GPIF port can be used as the data input port with only 16-bit FD0 ~ FD15), while the DSP outputs a total of 23-bit information data (16-bit data cable D0 ~ D15 and 7-bit address lines A0 ~ A6), so we need to embed the extra 7-bit address information into the data. Split one 16-bit data into two, each of which is 8 low (FD0 ~ FD7) is used to store original data information (D0 ~ D7 or D8 ~ D15), high 7-bit (FD8 ~ FD14) Stores address type information A0 ~ A6), the highest bit FD15) is used to identify FD0 ~ FD7 is the D0 ~ of the original data ~ D7 or D8 ~ The D15.CY68013A GPIF port uses an internal 48 MHz clock. According to the reference [2], each GPIF signal cycle is 20.83 ns, and the two clocks are not synchronized. FPGA is compatible with high-speed devices, A higher clock source is required. therefore, in order to ensure that GPIF can collect RDY signals, the signal output by FPGA must maintain at least 1.5 GPIF signal periods. each time GPIF reads data from the outside and saves the data to the FIFO, it requires six States. Therefore, each output data must have more than six GPIF signal periods. taking TI's C55 series DSPs as an example, the clock speed is 144 MHz and the FPGA is connected to the EMIFS external bus.

Considering that the DSP output data clock may be faster than the CY68013A GPIF acquisition clock, FPGA needs to design a built-in FIFO memory for caching DSP output data.

1.4 USB firmware design

Because the built-in 8051 kernel clock cycle of CY68013A is slow and not suitable for high-speed transmission, only 8051 is used in the collection program for Initialization Configuration, without interfering with the data transmission process. CY68013A reads data from the external GPIF and saves the data to the FIFO. When the FIFO is full, the data is transmitted to the PC through USB. use the general program framework and graphical GPIF design tools provided by Cypress to edit GPIF waveforms. the Bulk transmission mode is commonly used when a large amount of data is transmitted on the USB bus. The hardware configuration program adopts the program template provided by Cypress. For details, refer to [3, the program framework is similar to the references [4, 5.

1.5 PC Receiver

The USB driver can directly use the ez-usb driver provided by Cypress. the ez-usb driver does not provide an advanced file operation I/O method. Therefore, you need to call the DeviceIoControl function at the underlying layer for processing. considering that Bulk transmission mode is completely initiated by the host PC), the slave collection board can only passively wait. When the built-in FIFO of CY68013A is full, if the host cannot initiate read operations in a timely manner, the FIFO will no longer receive data write operations, resulting in a small amount of data loss. for underlying protocol stack debugging, this small amount of data loss may cause program process errors and is unacceptable. therefore, the receiving program on the PC end should adopt multi-thread processing, and list the work of receiving USB data as a separate thread, and set its priority to THREAD_PRIORITY_TIME_CRITICAL with the highest real-time performance, prevents data reception from being interrupted by other processes in the system to ensure that each read operation can be sent in a timely manner. at the same time, it is necessary to ensure that as few processes run simultaneously in the PC operating system responsible for data collection, and disable unnecessary background processes.

The data received by the PC is first stored in a temporary file for later parsing and simulation. temporary files are stored in 16 bits. Each data is expressed in two words. The low byte is in front of the data format after FPGA conversion.

2. Simulation System

The simulation system uses the data collected by the collection system to reproduce the protocol stack running status in the communication terminal, so that developers can check program errors at any time and debug the program.

2.1 System Framework

To reproduce the running status of the underlying protocol stack, in addition to ensuring the consistency of the overall input and output of the protocol stack development, the greatest difficulty lies in the system timing and the ability to accurately reproduce the occurrence time of various events. most of the Digital Communication Systems Based on the software radio technology adopt the oversampling method, and the AD/DA rate is relatively high and stable, therefore, most of the underlying protocol stacks adopt AD/DA Input and Output interruptions as system timing. when the communication terminal is used as the receiver, the underlying protocol stack must use the AD sample data as the driving data for estimation and balancing of other channels, demodulation, and channel decoding, DA output data is the final output result of the underlying protocol stack and needs to be verified by a simulation program. therefore, the simulation program can use the AD/DA interrupt to divide the minimum time slice for running the program. The number of interruptions is used to timing the occurrence of other events, the simulation program judges the number of AD/DA data and calls various program functions to reproduce the running status and data flow of the underlying protocol stack. this ensures that the simulation program is consistent with the Protocol Stack running in the DSP to reproduce the problem as much as possible without increasing the overhead.

2.2 output data

According to the data collection point selected in section 1.1, the data used for simulation should be output in the DSP's underlying protocol stack Code: (1) the frontend AD/DA data must be output, and the interaction data between the underlying protocol stack and the upper protocol stack, which is the input data and final output result required for receiving and transmitting information from the underlying communication protocol stack; (2) the interruption and input data generated by other peripheral devices also affect the underlying protocol stack process, which is necessary for simulation. (3) status changes such as pending, running, and ending of tasks in the underlying protocol stack must be output to ensure that the simulation running time is consistent with the actual situation. in addition, global variables that change multiple times between two AD/DA Interruptions also need to be output to make up for the lack of time slice division.

2.3 Data Parsing

The received data stored in section 1.5 cannot be directly used for simulation. format conversion is required. according to the system framework described in section 2.1, all events are timing Based on AD/DA data. Therefore, except for AD/DA data, the number of AD/DA data must be recorded for other types of data, as a timestamp, all data can be divided into two categories: AD/DA data and non-AD/DA data. for ease of simulation, these two types of data are stored in two files respectively. when parsing data, we need to re-combine the two 16-Bit Data split by FPGA to be compatible with CY68013A in section 1.3 and separate the data of different types. AD/DA data is generally fixed in length and determined by the number of digits in the resolution of the AD/DA Converter. For example, if the AD/DA data is 16 bits, one data is output at a time, the parsed data format is shown in table 2.

The length of non-AD/DA data varies according to program requirements. The length information can be included in the output data of the program developed on the protocol stack, you can also specify the Data Length in advance in the receiving and output programs. for example, if the non-AD/DA data is in the unit of words and the data length is N, the parsed data format is shown in table 3.

Because the underlying protocol stack needs to take into account peripheral hardware control, many external interruptions may interrupt data output. Therefore, nesting between various data needs to be considered during data parsing. therefore, you can use a separate buffer for each type of data, and store the data in the file after it is parsed to one complete data record, at the same time, ensure that all non-AD/DA data in the file is arranged in the order of occurrence time.

2.4 System Simulation

Before system simulation, you must first convert the underlying protocol stack code running on the DSP to the code running on the PC. Generally, the DSP is developed by combining the C language and assembly language, C code basically does not need to be modified much, but the compilation code needs to be translated into C code according to its working principle. during system simulation, the parsed data file in Section 2.3 is used as the input, and the simulation system framework defined in section 2.1 is driven by AD/DA data, by judging the occurrence time of non-AD/DA data, the AD/DA Data Count value is used to mobilize the running of each part of the underlying protocol stack, so as to reproduce the running status of the Protocol Stack and debug the program. some hardware operations require the control of the underlying protocol stack. During simulation, you can write them to a file in the format of "[occurrence time] hardware operation content" as the output of the simulation program. in this way, the relationship between various hardware operations is clear and visualized by querying output files, which facilitates the discovery of logical errors in hardware control.

In this paper, a data collection and simulation system is designed for the development of the underlying protocol stack. Using the high-speed transmission feature of USB and the convenience of physical connection, CY68013A is used for data transmission, fully utilize its GPIF resources and Use FPGA for format conversion. the overall framework and data conversion details of the simulation system are described in detail. the system can be used for debugging various types of protocol stacks to facilitate tracking and reproduction of problems. the experiment shows that the system can withstand 100 Mb/s real-time data streams and is widely used in the development of digital cluster handheld terminals, which not only reduces the difficulty of protocol stack development, it also shortens the development cycle and has high practicability.