Subject: Introduction to Serial Gigabit Transceivers – FPGA implementation and testing of Aurora 8b10b protocol over SFP modules and fiber-optic cable.
Serial gigabit communication availability is one of the key properties of modern FPGA architectures. Conversion from parallel interfaces to serial interfaces has a long history. There are still high-speed parallel interfaces most common one is DDR DRAMs. However, a lot parallel interfaces have replaced by serial ones throughout the recent years.
There is a great book from Xilinx (now AMD) called “HIGH-SPEED SERIAL I/O MADE SIMPLE” which was published in 2005 and had some interesting foreword predictions from Raymond Johnson in the book:
“Today we are again in a position to be both witness and participant in one of these rare technological moments. A fundamental shift is occurring in the electronics industry⎯a shift from parallel I/O schemes to serial I/O connectivity solutions. This change is driven by companies across a wide-range of industries as a means to reduce system costs, simplify system design, and provide the scalability needed to meet new bandwidth requirements.”
“At Xilinx, we firmly believe that serial connectivity solutions will ultimately be deployed in nearly every aspect of every electronic product imaginable. This deployment will appear in chip-tochip interfaces, backplane connectivity and system boards, and box-to-box communications, to name a few. In support of this belief, we announced a ”High-Speed Serial Initiative” to help accelerate the industry move from parallel to high-speed serial I/O.”
Gigabit transceivers (GTs) are now common in a lot of applications from high-speed ADC/DAC interfacing to fiber-optic communication, 10G Ethernet, PCIe and high-resolution video streaming interfaces. AMD FPGA families have different transceiver solutions which have a variety of different bandwidth performances. 7 series FPGAs have GTP, GTX, GTH and GTZ coded transceiver primitives. Artix-7 family has GTP of 6.6 Gbps BW, Kintex-7 family has GTX of 12.5 Gbps, Virtex-7 family has GTH of 13.1 Gbps and GTZ of 28.05 Gbps. Customers need to decide the FPGA family according to needs of the bandwidth requirements and protocol support of the transceivers. In this post, I will show how to implement Aurora 8b10b link layer protocol over SFP fiber-optic modules in physical layer.
Aurora has 2 different IPs: 8b10b and 64b66b. They are very similar but 64b66b has more speed capability. However, for our test 8b10b is enough. Aurora specification is available and free to use and can be found in internet. In the specification it is written that:
“The Aurora 8B/10B protocol is a scalable, lightweight, link-layer protocol that can be used to move data point-to-point across one or more high-speed serial lanes. The Aurora 8B/10B protocol is an open standard and is available for implementation by anyone without restriction”
AMD provides Aurora 8b10b IP in Vivado. We can also use “7 Series Transceiver Wizard” IP to create Aurora 8b10b link. However, I found Aurora 8b10b IP more useful and easier to use and utilized it in the example project.
In Aurora 8b10b IP customization GUI there are 3 tabs: “Core Options”, “GT Selections” and “Shared Logic”. In core options tab, you can choose different options about lane width, line rate, GT ref clock, INIT clock and DRP clock frequencies, dataflow being duplex, transmit or receive only, interface being framing or streaming and debug options:

In GT selections tab you can choose how many lanes will be in the core, available from 1 to 16. Shared logic option is somehow confusing, you need to select one options from the two: “include shared logic in core” or “include shared logic in example design”. So in order to choose which fits best for our purpose, we need to understand what are the components of the shared logic. Let’s focus on the architecture of the GT. Different GT macros reside in columns of the FPGA architecture like BRAMs and DSPs. In Kintex-7 325T FPGA, there are 16 GTXE2_CHANNEL primitives while 4 of them compose a GTX Quad with a shared GTXE2_COMMON primitive:

If you choose “include shared logic in core” option, then the GTXE2_COMMON primitive, clocking and reset support logic will be inside the wrapped IP file. If you choose “include shared logic in example design” option, these common logic and primitives will be outside of the wrapped IP file. Our FPGA prototyping board has 4 SFP connectors each connected to the GTXE2_CHANNEL X0Y8/9/10/11 quad. In this tutorial 2 SFP fiber module with a multi-mode fiber-optic cable are connected into X0Y8 and X0Y9 GT channels. You need to be careful while selecting the line rate, since some SFP fiber modules support max 1.25 Gbps while some 10 Gbps. Those are used in this tutorial were 1.25 Gbps, so we need to select 1.25 Gbps for line rate.
In order to test Aurora 8b10b IPs over fiber-optic physical layer, a Vivado project is created which instantiates 2 Aurora IPs and a UART transceiver to communicate to over serial port. Here is the project hierarchy:

gt_common_support module instantiates GTXE2_COMMON primitive. Two different support reset modules are added to generate reset signals for the GTs. Clock_module instantiates necessary clocking buffers. If you want to use just one Aurora 8b10b IP, then just copying the example project of the IP is enough. But, if you want to instantiate more then one, you need to do some modifications. Here in the example, AURORA_WRAPPER module wraps all the support logic and Aurora IPs and create interface for the user application side for 2 different Aurora interfaces.
Another important point is reset sequence of the GTs. In Aurora 8b10b IP user guide, a power up and normal reset sequences are given:


We experienced some problems on power on reset of the GTs. Sometimes GTs are not initialized properly after power on reset, channel up and lane up status signals keep low after power on, whereas they need to be high. This is stated in some posts in Xilinx forum. To ensure a reliable application, a normal operation reset sequence is added to the design if channel and lane up signals are still low after power on reset. Our results show that if power on reset was not able to initialize the GTs, normal reset always does the proper job. So, one should be aware of the reset problem.
Another key point is, SFP connectors have a pin called “tx_disable”. You need to enable transmission by driving ‘0’ to tx_disable pin of the SFP. If you forget this, you can be debugging hours to find what is going wrong!
Also, do not forget that you need to give location constraint for the Aurora IPs to tell the tool that which GTX channels will be utilized for the Aurora 8b10b IP. Search in source files for “GTXE2_CHANNEL” instantiation and give the location constraint in a proper hierarchical way in xdc file such as:
set_property LOC GTXE2_CHANNEL_X0Y8 [get_cells AURORA_WRAPPER/aurora_8b10b_rx_i/U0/gt_wrapper_i/aurora_8b10b_multi_gt_i/gt0_aurora_8b10b_i/gtxe2_i]
set_property LOC GTXE2_CHANNEL_X0Y9 [get_cells AURORA_WRAPPER/aurora_8b10b_tx_i/U0/gt_wrapper_i/aurora_8b10b_multi_gt_i/gt0_aurora_8b10b_i/gtxe2_i]
Here is the device view after implementation:

We tested this setup by sending 4 bytes of data from PC through UART and then using one Aurora IP to transmit these 4 bytes of data and using the other Aurora IP to receive the data. Then we sent the received data from Aurora IP to the PC to check the integrity is successful, and it was.
We tried to summarize the usage of Aurora 8b10b IP, instantiation of gigabit transceivers and how one can test their design on an FPGA board. You can access us to get more info about how to implement Aurora 8b10b link over SFP fiber-optic modules. Just email to:
info@anadologic.com
“𝑺𝒉𝒂𝒓𝒊𝒏𝒈 𝒌𝒏𝒐𝒘𝒍𝒆𝒅𝒈𝒆 𝒊𝒔 𝒕𝒉𝒆 𝒎𝒐𝒔𝒕 𝒆𝒇𝒇𝒊𝒄𝒊𝒆𝒏𝒕 𝒍𝒆𝒂𝒓𝒏𝒊𝒏𝒈 𝒎𝒆𝒕𝒉𝒐𝒅”