Embedded code stream analysis design based on FPGA and RTOS

In view of the high price and inconvenience of using the bitstream analyzer in the traditional digital video broadcasting system, this paper proposes a cost-effective supplementary design solution, which realizes the bitstream analysis function based on the general FPGA and RTOS and embedded hardware platform. The paper also describes several key technologies such as bitstream acquisition, bitstream analysis and information display.

The code stream analyzer can be used as a debugging tool for digital TV equipment, such as testing whether the input and output code streams of MPEG encoders, multiplexers, modems and other equipment comply with the MPEG-2/digital television broadcasting (DVB) standards. As a standard inspection device, the code stream analyzer is an indispensable and important device for the entire digital TV system. The digital TV integration system in actual use is a large and complex system engineering. From the front end to the back end, no matter which link goes wrong, it will lead to the paralysis of the entire system. In order to quickly and effectively find the source of the fault, it is necessary to use a code stream analyzer at each test point. As shown in Figure 1, the code stream analyzer can be inserted at test points 1-4 to form the monitoring, testing and alarm of the transport (TS) code stream interconnection layer.

The research work of bitstream analyzers abroad started relatively early. Bitstream analyzers came out when the MPEG-2 standard was formulated. Companies such as HP, WG, RS and Tektronix all launched their own bitstream analyzers. The products of these companies have their own characteristics, and their core is based on the PC hardware platform. Although the performance is relatively stable, the product prices are relatively expensive and inconvenient to operate. With the expansion of the scope and scale of applications, in an application scenario, it may be necessary to conduct long-term real-time bitstream analysis, monitoring, system information collection and alarm management on more test points. Expensive PC-based test equipment obviously cannot meet this requirement.

In order to solve this defect, major domestic and foreign manufacturers have turned to portable industrial computers for development. Although portable industrial computers do not have complicated peripheral connections, they also have problems such as large size and expensive hardware costs, and their functions are limited by the stability of PC hardware and operating system platforms. In addition, there is also a handheld tester on the market that has good mobility, but it cannot meet the requirements of real-time monitoring at a low cost. In view of the current application status and development status in China, we propose a design method based on a general FPGA and RTOS and an embedded hardware platform. This module can achieve stable and long-term reliable operation, has a good cost-effectiveness, and can be widely used in real-world applications.

Code stream analysis function design

The functional design will fully comply with the following standards: MPEG-2; ISO/IEC 13818-2(System); DVB; ETS 300 468(DVB SI); EN 50083-9(DVB SPI, ASI); ETR 154(Implementation guidelines for MPEG2 systems); ETR 290(Measurement Guidelines); ETR 211(DVB SI Recommendation).

As a test instrument, both the software and hardware must be stable and reliable. At the same time, consider using network communication technology to allow users to access the graphical user interface through a web browser on any computer, and display the code stream analysis results to the user in the most intuitive way. The design goal of the embedded test equipment is proposed based on actual needs. The design purpose is to be a TS code stream system monitoring device. It should be convenient in operation and use, and the fault monitoring and location should be fast and accurate. The modular design requires a compact structure and a simple interface. In response to this need, the design goal must at least achieve the following functions:

1. Extract synchronization bytes and check packet sequence errors on the code stream data, and further check the data for syntax errors at three priority levels according to the ETR290 standard; monitor the data stream in real time, and record the time and situation of the error in a timely manner; at the same time, the hardware trigger mode can be formulated according to the needs of the user, and different monitoring items can be selected.

2. Real-time statistics of the current bandwidth usage of each PID, the total number of current TS packets and the transmission bit rate.

3. Extract the PSI/SI information in the TS packets and splice them into segments, analyze the information in the segment header and store it in a specific data structure.

4. Extract PCR information from the TS stream, calculate its transmission interval, analyze PCR jitter, and report errors in a timely manner.

5. Extract PES header information and basic information of each channel of video and audio from the PES segment.

6. Analyze the audio and video data, and analyze the buffer model of each audio and video transport stream standard target decoder during decoding according to the PCR, PTS and audio and video data in the TS stream, and report errors in time when the buffer is empty or overflowed. [page]

These functions will meet the requirements of on-site monitoring of the operating environment. In practical applications, the results of these analyses need to be presented to users in some way. Therefore, the following information display is necessary.

1. Basic information: mainly provides users with the most basic information about TS streams, such as TS stream transmission rate, synchronization errors, TS packet length, video and audio ratio, brief information of PSI table, etc.

2. Real-time monitoring: This interface is designed according to the 3-level error detection content specified in the DVB ETR290 standard.

3. Program information: Displays the detailed information of PMT, SDT and EIT describing the content of a program.

4. Bandwidth information: bandwidth statistics based on PID.

5. Multiplexing structure: the most basic program multiplexing information in the TS stream.

6. PSI/SI information: Translate the binary PSI/SI information into text and display it in a tree format, so that the hierarchical structure of the TS stream is clear at a glance.

7. PCR analysis: Analyze the interval and jitter of PCR transmission.

Hardware Structure

As shown in Figure 2, this design uses Altera's FPGA - the specific model and series can be selected according to the actual design capacity. Here we will discuss the design ideas of input and output, filtering logic and control system.

The two data bus interfaces TS IN and TS OUT that connect the FPGA to the TS interface are both standard DVB_SPI (EN 50083-9) interfaces. TS IN receives the external TS code stream and sends it to the code stream filtering logic system for further processing. The TS OUT interface loops out the code stream received from TS IN, so that the transmission code stream will not be affected while the code stream is being analyzed. The DVB_SPI interface is an LVDS level signal and can be directly connected to the FPGA (refer to the ALTERA hardware manual).

If the DVB_ASI interface is used, the serial/parallel and parallel/serial conversion can also be realized through the IP core provided by Altera. Therefore, in principle, no other interface logic chip is required except the transmission transformer and protection circuit. There are two types of input interfaces in the DVB standard, ASI and SPI, and the definitions and standards of the two are different. The input signal is adjusted and unified according to the different needs of the input interface. The TS code stream synchronization signal should be extracted from the information of the ASI interface, and the duty cycle of the signal pulse should be adjusted to make the output interface signal of the ASI similar to that of the SPI. In addition, the ASI interface output has two data string modes: smooth and burst. In order to meet the working needs of the burst mode, the RAM BLOCK in the FPGA chip can be defined as FIFO for high-speed caching, so that the interface can meet the burst input of different rates, and the highest should be able to meet the input requirements of the 27MHz parallel burst mode (ASI interface 216MHz).

Some important hardware control modules need to be designed in the bitstream filtering logic unit of FPGA. The MPEG2 standard specifies the rate of TS bitstreams at each compression level. After TS bitstream multiplexing, the serial bitstream rate transmitted in actual applications may be >200MHz. Therefore, considering the working main frequency of NIOS and the actual working efficiency after loading the operating system, we need to reduce the input bitstream and input it into the analysis system. Therefore, a variety of hardware trigger mechanisms and hardware filters are designed in the hardware to meet this demand.

According to the standard definition of ETR290, the code stream analysis function is not a parallel processing mode, but a relative relationship of sequence. According to different priorities, the synchronization and continuity analysis is completed first, then the PSI information is extracted, and finally the TS streams of different PID programs are decoded according to the parsed PSI information to analyze the detailed PES stream information. The control of the input information volume can be achieved through software control. The FPGA filtering logic designs PID filters for various TS streams and organically combines these rich PID filters together. The control module can control the working mode and combination structure of these PID filters by writing commands.

According to the analysis process control requirements, when analyzing different parts of information, the control module can send commands to change the hardware combination as needed to ensure that the input code stream is only related to the current analysis work. In this way, the control of the input code stream flow can be completed without affecting the completion of the design requirements. Of course, this design is a balancing measure at the expense of real-time analysis, but the benefits are also foreseeable.

Altera's FPGA provides a pure software-designed CPU core NIOS module. For this core, Altera also provides corresponding compilers and debugging tools. We can port a small operating system to the NIOS core. Multi-task scheduling and complex calculations are implemented on this real-time operating system. The company also provides other functional modules for FPGA design such as UART, TIMER, etc. In terms of software support, it provides TCP/IP protocols that work on the NIOS core.

These resources can easily meet the design requirements, and they can be used to achieve the output requirements of the analysis results. We can choose to use different communication interfaces such as RS232/RS485, Ethernet, etc. according to different application scenarios. At the same time, we can further design the SNMP protocol on the operating system so that the code stream analysis module can be connected to the existing management system in the network environment. This is conducive to network management and control. Similarly, it is feasible to design a simple WEB SERVER function on the operating system. Users can get the analysis results immediately through the browser without installing any analysis software. These functional designs provide convenience for users' actual applications, and users can choose different control methods according to different on-site environments. [page]

Software Structure

The software design is based on a real-time operating system. Currently, there are many commercial RTOS to choose from. At the same time, there are also operating systems that can run on NIOS provided by third-party developers of Altera. This article introduces another complete embedded real-time kernel μC/OS-II and application structure. Most of the μC/OS-II source code is written in C language, and the assembly part is only about 200 lines. This shows that the real-time kernel can be easily ported to almost all embedded application CPUs. In fact, it has been successfully ported to DSP and 16/32-bit MCU. By modifying the assembly of stack pointer, stack entry and exit management, interrupt control, etc., μC/OS-II can be ported to the NIOS platform. As shown in Figure 3, the software design is based on the μC/OS-II operating system, and the design gives the software design structure of multi-process design.

The following is a brief analysis of the main functions of different processes:

1. TS stream processing process. This process completes the functions of TS input, output and memory management. It is similar to the physical layer of the communication system, facing the transmission control of the hardware system. In general, it completes reading data from FIFO and storing it in different parts of SRAM, and submits the address pointer. At the same time, the code stream to be output is read from SRAM and written to the output FIFO as required. In special cases, the input data volume is adjusted according to the input code stream rate and memory conditions.

2.MPEGII system layer analyzer. Analyze the PSI information of the input code stream according to the MPEG2 system layer standard. Categorize and store the extracted various tables and PID information. At the same time, reorganize the data according to the data structure type defined by SNMP, refresh the data as needed, and submit the results to the ETR290 error event trigger process.

3. ETR290 error monitoring process. Perform three priority level analysis and statistics according to the ETR290 standard. Analyze real-time information such as PCR jitter delay, information insertion interval, etc. according to the system clock. Store the data of the analysis results into a data structure and submit it to the communication module. Implement fault prompts and alarms through pre-designed fault modes. The fault mode can be set by software to generate an alarm for a single ETR290 error or a group of errors. Too many error alarms will cause information congestion, so combining related errors into a high-level alarm message will facilitate problem judgment.

4. Communication service process. Complete the transmission control design of Ethernet according to TCP/IP protocol and SNMP protocol. Data output transmits the statistical information database and analysis database to the server according to the standard SNMP protocol. At the same time, control command communication is carried out through TCP or UDP protocol. The statistical information data transmitted by SNMP can be semantically analyzed by external analysis software. However, it is required to transmit the hardware local clock information as reference information at the same time. The analysis data can also be directly displayed through the console window. Once the WEB SERVER function is added to the communication service, the analysis results can be directly displayed locally through the browser.

Conclusion

The embedded code stream analysis design is completely feasible and effective. At present, most of the functions have been realized. The FPGA design adopts VHDL language structure, the analysis software adopts C++ language, and the RTOS operating system can also be transplanted between different hardware; therefore, the design can be implemented on different hardware platforms. This leaves flexible space for cost control. The goal of this design is not to replace the traditional code stream analysis equipment, but to serve as a supplement. The current design has limited real-time analysis capabilities, and the analysis data is refreshed at about 500ms. However, by improving the operating frequency and performance of the FPGA and selecting high-speed SDRAM, the working performance can be quickly improved. Therefore, there is a broad prospect for performance improvement and function expansion.