A Protocol Standard for Displays, Sensors & Critical Video Systems
IMPLEMENTING ARINC 818
GRT has done more than 100 ARINC 818 implementations, from very simple to extremely complex. Implementing ARINC 818 into an FPGA takes planning and knowledge and not all cases are alike. GRT has written many white papers on different aspects of implementing ARINC 818. In the paper Make VS Buy: GRT’s ARINC 818 IP Core, we provide some guidelines that will help orient you to some of the key considerations. Since some implementations are much more difficult than others, there is no “one size fits all” approach to implementing ARINC 818. For example, if you are creating a fixed resolution receiver, with no error detection, fixed ancillary data and loose timing and jitter requirements, combined with a very skilled FPGA designer, the implementation will be very straight-forward and may be completed in four to six weeks. However, if you have a complex implementation that requires both Rx and Tx capabilities, robust error detection, real-time updating of ancillary data, DO-254 certification and strict line-synchronous timing, the implementation can stretch to 18 months or more.
The two tabs below provide excerpts from the following two papers to help orient you to the task of implementing ARINC 818:
Implementing ARINC 818 White Paper
Make VS Buy: GRT’s ARINC 818 IP Core.
Building ARINC 818 Frames
Building ARINC 818 frames is simple in concept. The simple structure can be misleading due the number of intricate details that have to be managed, including the line and frame timing.
A state machine is needed that is triggered by different events, such as a vertical or horizontal sync pulse. When the sync pulses are received, the frame assembly begins pulling information from memory and registers. Since the first ADVB frame contains the container header and the ancillary data, it will typically be a different size than all the other frames that carry the video payload.
In addition to the basic ARINC 818 frame, most systems will also require status and error reporting, such as: loss of sync, 8B/10B errors, running disparity errors, SOFi detect, EOFn detect, and CRC errors. Airborne systems require a failure mode and effect analysis (FMEA) to be conducted based on system safety and criticality levels of the device where ARINC 818 is implemented. The FMEA will typically require internal operation of the ARINC 818 transceivers to be visible and monitored for health and this information fed into a larger built in test and health monitoring system.
FPGA Implementation Issues
A plethora of FPGAs exist that are capable of handling the ARINC 818 link rates and throughputs. The authors have worked primarily with Altera and Xilinx FPGAs, and although ARINC 818 can be implemented on other families of devices, they will not comment on implementation issues for other families of devices.
The FPGA chosen can make a difference in the complexity of implementing ARINC 818. Some implementation issues to consider are presented below.
One of the major concerns when designing a communication system based on FPGA's is the interface with the Hard Serial Transceiver blocks. Besides setting up the clocking schemes and data rates and protocols for transmission and reception, one has to interface with the serial transceivers for signals such loss of sync, 8B/10B errors, running disparity, etc. The signals are handled differently by each family of FPGA's (even within a particular series of devices, such as the Xilinx Virtex 5 series). For example, in the Virtex 5 series, the loss of sync signal for an LX50 FPGA works differently than the loss of sync signal for an LX110T FPGA. Porting a design between these two should have been trivial, but required serious effort due to undocumented features.
Also, the same signals may not exist for different transceivers from Altera and Xilinx. When moving across vendors, the transceiver interface has to be re-designed completely. For example, some Xilinx FPGA's allow the monitoring of Tx running disparity. This feature is not available on some Altera FPGA's. Since the system will need this information, the interface would have to be redesigned to keep track of the disparity and to ensure proper code insertion to maintain negative running disparity. This issue will be discussed in depth in another section.
Clocking nuances between recovered clocks, system clocks, and other discrete clocks (TX pixel, RX pixel) must be dealt with carefully to prevent clock domain-crossing violations. Porting HDL modules from one device to another will require ample testing and most likely code adjustments Reset architecture can be challenging, especially with Gigabit transceivers. For example, on a recent Altera design a “dark fiber” problem was encountered. Altera CDR circuits of GXBs got stuck in an unrecoverable state when initiated in the absence of a valid ARINC 818 input (and embedded clock). Special logic was developed to keep the GXB in reset until a valid ARINC 818 signal was detected on the fiber.
Running Disparity for Ordered Sets
Because ADVB is based on Fibre Channel, it allows for only the ordered sets (OS) defined by fiber channel. Specifically, there are two possible versions of an OS, and only those with beginning running disparity negative are allowed. This imposes the requirement that the running disparity immediately preceding the insertion of an OS must be negative (such that the correct one of two possible 40-bit ordered sets are inserted).
Because the running disparity is random at the end of payload data in an ADVB frame, FPGA logic must be developed to guarantee this negative running disparity. The job of this logic will be to insert one of two possible EOF OS’s at the end of an ADVB packet to control the disparity—either one that is neutral (and maintains the running disparity) or one that flips the running disparity. Possible EOF ordered sets are listed in Table 1.
The proper insertion of the correct EOF requires logic that tracks the running disparity of the transmitted ADVB stream. Some FPGAs have serializers that provide a running disparity signal that can be monitored by the fabric. For such devices, the logic to insert the correct EOF is straightforward.
Other FPGA devices allow for the forcing the running disparity for particular outgoing 8B/10B codes. For such FPGAs, the fabric needs to force the running disparity periodically and include logic for maintaining a copy of the transmitted running disparity. The internal copy can then be used to properly insert the EOFs in the ADVB stream.
For FPGAs that provide no information about running disparity, and no mechanism for forcing running disparity, more elaborated schemes are required, and in some cases, these FPGAs will not be able to comply with the ARINC 818 standard.
Depending on the chosen FPGA and the built-in features of the FPGA, engineers should expect to spend several weeks de-bugging running disparity. Access to an ARINC 818 analyzer, however, will accelerate this work.
Synchronous Line Timing Issue
Flight safety in avionics requires that display systems not present any stale or misleading images to the pilot. Display manufactures can guarantee that their display product do not present stale images by simply removing full image buffers from the display head and relying on line FIFOs.
Because of scan requirements for the LCD, where line scans must be started at precise intervals, strict timing requirements must be imposed on the ADVB link. The ADVB link must supply line data in a timely way to guarantee that a full line is presented to the receivers FIFO at the beginning of each line scan.
It is common that receiver FIFOs are implemented with Block RAMs available within FPGA devices used in the display head. FPGA resource constraints will permit a FIFO of only one or two lines deep. This may seem sufficient to support the precise LCD scan requirements until a more careful analysis is performed.
As an example, consider a 3.1875 Gbps ADVB link designed for an SXGA+ (1400 x 1050) display that has implemented a receiving FIFO that is 2 lines deep. The normal operation for the display head will commence the LCD scan of the first line when a full line has accumulated in the receive FIFO. For SXGA+, the horizontal scan time is approximately 15 µs, and therefore…
For the remainder of this paper outlined below, request a copy of the White Paper:
Implementing ARINC 818 Table of Contents
ARINC 818 IP Core Use
ARINC 818 IP Core Structure
Signal Switching Considerations
Switching with Uninterrupted Video Frames
Heterogeneous Video Resolutions
Time Interleaving of Video Streams
Video Timing Validation
Physical Layer Considerations
K28.5 D21.4 D21.3 D21.3
K28.5 D21.5 D21.3 D21.3
K28.5 D21.4 D21.6 D21.6
K28.5 D21.5 D21.6 D21.6