THE ARINC 818 STANDARD

IMPLEMENTING ARINC 818 WHITE PAPER

​

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.