Aurora 8B/10B v11.

LogiCORE IP Product Guide

Vivado Design Suite

PG046 October 19, 2023

AMD Adaptive Computing is creating an environment where

employees, customers, and partners feel welcome and included.
To that end, we’re removing non-inclusive language from our
products and related collateral. We’ve launched an internal
initiative to remove language that could exclude people or
reinforce historical biases, including terms embedded in our
software and IPs. You may still find examples of non-inclusive
language in our older products as we work to make these
changes and align with evolving industry standards. Follow this
link for more information.
Table of Contents
IP Facts

Chapter 1: Overview
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Licensing and Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 2: Product Specification

Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 3: Designing with the Core

General Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Serial Transceiver Reference Clock Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Reset and Power Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Shared Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Using the Scrambler/Descrambler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Using CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Hot-Plug Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Clock Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Using Little Endian Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 4: Design Flow Steps

Customizing and Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapter 5: Detailed Example Design

Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Using the Vivado Design Suite Debug Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Aurora 8B/10B v11.1 Send Feedback

2
PG046 October 19, 2023
 Chapter 6: Test Bench

Appendix A: Verification, Compliance, and Interoperability

Appendix B: Upgrading
Device Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Upgrading in the Vivado Design Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Migrating Local Link-based Aurora Cores to the AXI4-Stream Aurora Core . . . . . . . . . . . . . . . . . . 91

Appendix C: Debugging
Finding Help with AMD Adaptive Computing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Simulation Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Next Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
AXI4-Stream Interface Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Appendix D: Generating a Wrapper File from the Transceiver Wizard

Appendix E: Handling Timing Errors

Appendix F: Additional Resources and Legal Notices

Support Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Finding Additional Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Please Read: Important Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Aurora 8B/10B v11.1 Send Feedback

3
PG046 October 19, 2023
 IP Facts

Introduction
LogiCORE IP Facts Table
The AMD LogiCORE™ IP Aurora 8B/10B core
Core Specifics
supports the AMBA® protocol AXI4-Stream
Supported AMD UltraScale+™(2), AMD UltraScale™(2),
user interface. The core implements the Aurora Device AMD Zynq™ 7000,
8B/10B protocol using the high-speed serial Family(1) AMD 7 Series(3)
transceivers on AMD Zynq™ 7000 SoC, AMD Supported
AXI4-Stream
Artix™ 7, AMD Kintex™ 7 and AMD Virtex™ 7 User Interfaces

families, AMD UltraScale™ and AMD Resources Performance and Resource Utilization web page
UltraScale+ ™ families. Provided with Core

Design Files Register transfer level (RTL)

Features Example
Verilog and VHDL(2)
Design

• General-purpose data channels with throughput Test Bench Verilog and VHDL(4)
range from 480 Mbps to 84.48 Gbps Constraints
Xilinx Design Constraints (XDC)
• Supports up to 16 consecutively bonded 7 File
series GTX/GTH, UltraScale™ GTH or UltraScale+ Simulation Source HDL with SecureIP transceiver simulation
GTH transceivers and up to four bonded GTP Model models
transceivers
Supported
• Aurora 8B/10B protocol specification v2.3 S/W Driver
N/A
compliant
Tested Design Flows(5)
• Low resource cost (see Resource Utilization)
Design Entry AMD Vivado™ Design Suite
• Easy-to-use AXI4-Stream based framing (or
streaming) and flow control interfaces For supported simulators, see the
Simulation Vivado Design Suite User Guide: Release Notes,
• Automatically initializes and maintains the Installation, and Licensing.
channel
Synthesis Vivado Synthesis
• Full-duplex or simplex operation
Support
• 16-bit additive scrambler/descrambler
Release Notes
• 16-bit or 32-bit Cyclic Redundancy Check (CRC) and Known Master Answer Record: 54367
for user data Issues

• Hot-plug logic All Vivado IP

Master Vivado IP Change Logs: 72775
Change Logs
• Configurable DRP/INIT clock
Support web page
• Single/Differential clocking option for
GTREFCLK and core INIT_CLK Notes:
1. For a complete list of supported devices and configurations, see the
Vivado IP catalog and associated FPGA data sheets.
2. For more information, see the Virtex UltraScale FPGAs Data Sheet: DC
and AC Switching Characteristics (DS893) [Ref 20], Kintex UltraScale
FPGAs Data Sheet: DC and AC Switching Characteristics (DS892) [Ref 19],
Kintex UltraScale+ FPGAs Data Sheet: DC and AC Switching
Characteristics (DS922) [Ref 21], and Virtex UltraScale+ FPGAs Data
Sheet: DC and AC Switching Characteristics (DS923) [Ref 22].
3. For more information, see the 7 Series FPGAs Overview (DS180) [Ref 17]
and the UltraScale Architecture and Product Overview (DS890) [Ref 18].
4. The IP core is delivered as Verilog source code and comes with an
example design and supporting modules for simple simulation and
hardware demonstration.
5. For the supported versions of the tools, see the
Vivado Design Suite User Guide: Release Notes, Installation, and
Licensing.

Aurora 8B/10B v11.1 Send Feedback 4

PG046 October 19, 2023
 Chapter 1

Overview
This guide describes how to generate an AMD LogiCORE™ IP Aurora 8B/10B core using
AMD UltraScale™ and UltraScale+™ family GTH transceivers, AMD Kintex™ 7, Virtex™ 7
FPGA GTX and GTH transceivers, AMD Artix™ 7 FPGA GTP transceivers, and AMD Zynq™
7000 device GTX and GTP transceivers. The Aurora 8B/10B core supports the AMBA®
protocol AXI4-Stream user interface.

The AMD Vivado™ Design Suite produces source code for Aurora 8B/10B cores with a
configurable datapath width. The cores can be simplex or full-duplex, and feature one of
two simple user interfaces and optional flow control.

The Aurora 8B/10B core (Figure 1-1) is a scalable, lightweight, link-layer protocol for
high-speed serial communication. The protocol is open and can be implemented using
AMD FPGA technology. The protocol is typically used in applications requiring simple,
low-cost, high-rate, data channels and is used to transfer data between devices using one
or many transceivers.
X-Ref Target - Figure 1-1

Aurora Channel
Partners

Aurora Aurora
Lane 1 Channel

User User
User Interface Interface User
Aurora Core Aurora Core
Application Application

Aurora
Lane n

User Data 8B/10B User Data

Encoded Data
X13009

Figure 1‐1: Aurora 8B/10B Channel Overview

Aurora 8B/10B v11.1 Send Feedback

5
PG046 October 19, 2023
 Chapter 1: Overview

Aurora 8B/10B cores automatically initialize a channel when they are connected to an
Aurora channel partner and pass data freely across the channel as frames or streams of data.
Aurora frames can be any size, and can be interrupted at any time. Gaps between valid data
bytes are automatically filled with idles to maintain lock and prevent excessive
electromagnetic interference. Flow control can be used to reduce the rate of incoming data
or to send brief, high-priority messages through the channel.

Streams are single, unending frames. In the absence of data, idles are transmitted to keep
the link alive. The Aurora 8B/10B core detects single-bit and most multi-bit errors using
8B/10B coding rules. Excessive bit errors, disconnections, or equipment failures cause the
core to reset and attempt to re-initialize a new channel.

RECOMMENDED: Although the Aurora 8B/10B core is a fully-verified solution, the challenge associated
with implementing a complete design varies depending on the configuration and functionality of the
application. For best results, experience building high-performance, pipelined FPGA designs using AMD
implementation tools and constraints files (XDC) with the Vivado Design Suite is recommended. Read
Status, Control, and the Transceiver Interface, carefully.

Consult the PCB design requirements information in:

• UltraScale FPGAs GTH Transceivers User Guide (UG576) [Ref 1]

• 7 Series FPGAs GTP Transceivers User Guide (UG482) [Ref 2]
• 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476) [Ref 3]

Contact your local AMD representative for a closer review and estimation for your specific
requirements.

Applications
Aurora 8B/10B cores can be used in a wide variety of applications because of their low
resource cost, scalable throughput, and flexible data interface. Examples of core
applications include:

• Chip-to-chip links: Replacing parallel connections between chips with high-speed

serial connections can significantly reduce the number of traces and layers required on
a PCB. The core provides the logic needed to use GTP, GTX, and GTH transceivers, with
minimal FPGA resource cost.
• Board-to-board and backplane links: The core uses standard 8B/10B encoding,
making it compatible with many existing hardware standards for cables and
backplanes. Aurora 8B/10B cores can be scaled, both in line rate and channel width, to
allow inexpensive legacy hardware to be used in new, high-performance systems.

Aurora 8B/10B v11.1 Send Feedback

6
PG046 October 19, 2023
 Chapter 1: Overview

• Simplex connections (unidirectional): The Aurora protocol provides alternate ways to

perform unidirectional channel initialization making possible the use of the GTP, GTX,
and GTH transceivers in the absence of a back channel and to reduce costs due to
unused full-duplex resources.

Licensing and Ordering

This LogiCORE™ IP module is provided at no additional cost with the AMD Vivado Design
Suite under the terms of the End User License. Information about this and other AMD
LogiCORE IP modules is available at the Intellectual Property page. For information about
pricing and availability of other AMD LogiCORE IP modules and tools, contact your local
sales representative.

For more information, visit the Aurora 8B/10B product page.

Aurora 8B/10B v11.1 Send Feedback

7
PG046 October 19, 2023
 Chapter 2

Product Specification
Figure 2-1 shows a block diagram of the implementation of the Aurora 8B/10B core.
X-Ref Target - Figure 2-1

Control Serial I/O

Global Logic GT
Interface Lane Lane 1
(Channel Transceiver 1
Logic
Maintenance) (Lane 1)

RX User Serial I/O

GT
RX Data Interface Lane Lane 2
Transceiver 2
(Framing or Logic
(Lane 2)
Streaming) Aurora Channel
Serial I/O

TX User Serial I/O

GT
Interface Lane Lane n
TX Data Transceiver n
(Framing or Logic
(Lane n)
Streaming)

X14612

Figure 2‐1: Aurora 8B/10B Core Block Diagram

The major functional modules of the Aurora 8B/10B core are:

• Lane Logic: Each GTP, GTX, or GTH transceiver (hereinafter called transceiver) is driven
by an instance of the lane logic module, which initializes each individual transceiver
and handles the encoding and decoding of control characters and error detection.
• Global Logic: The global logic module performs the bonding and verification phases of
channel initialization. During operation, the module generates the random idle
characters required by the Aurora protocol and monitors all the lane logic modules for
errors.
• RX User Interface: The AXI4-Stream RX user interface moves data from the channel to
the application and performs flow control functions.
• TX User Interface: The AXI4-Stream TX user interface moves data from the application
to the channel and performs flow control TX functions. The standard clock
compensation module is embedded inside the core. This module controls periodic
transmission of the clock compensation (CC) character.

Aurora 8B/10B v11.1 Send Feedback

8
PG046 October 19, 2023
 Chapter 2: Product Specification

Performance
Maximum Frequencies
For details about maximum frequencies, visit the Performance and Resource Utilization web
page.

Latency
Latency through an Aurora 8B/10B core is caused by pipeline delays through the protocol
engine (PE) and through the transceivers. The PE pipeline delay increases as the
AXI4-Stream interface width increases. The transceiver delays are dependent on the
features and attributes of the selected transceivers.

This section outlines expected latency for the Aurora 8B/10B core AXI4-Stream user
interface in terms of user_clk cycles for 2-byte-per-lane and 4-byte-per-lane designs. For
the purposes of illustrating latency, the Aurora 8B/10B modules are partitioned into
transceiver logic and protocol engine (PE) logic which is implemented in the FPGA
programmable logic.

Note: These numbers do not include the latency incurred due to the length of the serial connection
between each side of the Aurora 8B/10B channel.

Figure 2-2 illustrates the latency of the datapath for the default configuration. Latency can
vary based on the transceiver(s) used in the design and the IP configuration.
X-Ref Target - Figure 2-2

TX AXI Interface TX TX RX RX RX AXI Interface

s_axi_tx_tvalid PE GT Transceiver GT Transceiver PE m_axi_rx_tvalid
X13191

Figure 2‐2: Latency of the Data Path

Minimum latency for a two-byte framing design from s_axi_tx_tvalid to

m_axi_rx_tvalid is approximately 37 user_clk cycles in functional simulation for the
default core configuration (see Figure 2-3).

Aurora 8B/10B v11.1 Send Feedback

9
PG046 October 19, 2023
 Chapter 2: Product Specification

X-Ref Target - Figure 2-3

;

Figure 2‐3: Aurora 8B/10B 2-Byte Latency

Minimum latency for a default four-byte framing design from s_axi_tx_tvalid to

m_axi_rx_tvalid is approximately 41 user_clk cycles in functional simulation.

The pipeline delays are designed to maintain the clock speed. If there is no dependency,
check if the latency can be added through other optional features.

Throughput
Aurora 8B/10B core throughput depends on the number of the transceivers and the
targeted line rate. Throughput varies from 0.4 Gb/s to 84.48 Gb/s for a single lane design to
a 16-lane design, respectively. The throughput was calculated using 20% overhead of the
Aurora 8B/10B protocol encoding and 0.5 Gb/s to 6.6 Gb/s line rate range.

Resource Utilization
For full details about performance and resource utilization, visit the Performance and
Resource Utilization web page.

Aurora 8B/10B v11.1 Send Feedback

10
PG046 October 19, 2023
 Chapter 2: Product Specification

Port Descriptions
The parameters used to generate each Aurora 8B/10B core determine the interfaces
available for that specific core. The interfaces are visible in the IP symbol as seen in
Figure 2-4. In the IP symbol, if you left-click the + sign beside the interface, you can see the
ports grouped in it. In this section, that is, Port Descriptions, in general, the interface
appears as a single row entry followed by the ports which are grouped in it. For example in
Table 2-1 (TX) the USER_DATA_S_AXIS_TX is the interface and the s_axi_tx_* ports are
grouped into that interface. The cores have four to six interfaces.
X-Ref Target - Figure 2-4

Notes:
1. [n:0] bus format is used when the Little Endian Support option is selected.
2. [0:n] bus format is used when the Big Endian Support option is selected.
3. Ports are active-High unless otherwise specified.

Figure 2‐4: IP Top-Level Interface

Aurora 8B/10B v11.1 Send Feedback

11
PG046 October 19, 2023
 Chapter 2: Product Specification

User Interface
The Aurora 8B/10B core can be generated with either a framing or streaming user data
interface. This interface includes all the ports needed for streaming or framed data transfer.
The framing user interface complies with the AMBA® AXI4-Stream Protocol Specification
[Ref 4] and comprises the signals necessary for transmitting and receiving framed user data.
The streaming interface allows data to be sent without frame delimiters, is simpler to
operate, and uses fewer resources than a framing interface. The data port width depends on
the lane width and the number of lanes selected.

Top-Level Architecture
The Aurora 8B/10B core top level (block level) file instantiates the lane logic module, TX and
RX AXI4-Stream modules, the global logic module, and the wrapper for the transceiver. Also
instantiated are the clock, reset circuit, frame generator and checker modules in the
example design.

Figure 2-5 shows the Aurora 8B/10B core top level for a duplex configuration. The top-level
file is the starting point for a user design.
X-Ref Target - Figure 2-5

Aurora 8B/10B Top Level

TX Transceiver
AXI4-Stream Wrapper

TX
Stream

Transmit User Interface GTX/GTH

Lane Global
Logic Logic Transceiver

RX
AXI4-Stream

RX
Stream

Receive User Interface

X13192

Figure 2‐5: Top-Level Architecture

This section provides the streaming and framing interface details. User interface logic
should be designed to comply with the timing requirement of the respective interface as
explained here.

Aurora 8B/10B v11.1 Send Feedback

12
PG046 October 19, 2023
 Chapter 2: Product Specification

AXI4-Stream Bit Ordering

Aurora 8B/10B cores use ascending ordering. They transmit and receive the most significant
bit of the most significant byte first. Figure 2-6 shows the organization of an n-byte
example of the AXI4-Stream data interfaces of an Aurora 8B/10B core.
X-Ref Target - Figure 2-6

Most Significant Byte Least Significant Byte

Byte 0 Byte 1 Byte n

TX_D 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 n0 n1 n2 n3 n4 n5 n6 n

Most significant bit transmitted first Least significant bit transmitted last
X129

Figure 2‐6: AXI4-Stream Interface Bit Ordering

User Interface Ports

Table 2-1 and Table 2-2 list duplex and simplex core AXI4-Stream TX and RX data port
descriptions.

Table 2‐1: User I/O Ports (TX)

Name Direction Clock Description

Domain
USER_DATA_S_AXI_TX
s_axi_tx_tdata[0:(8n–1)] or Outgoing data. n is the number of bytes computed
Input user_clk
s_axi_tx_tdata[(8n–1):0] as Number of lanes x Lane Width.
Asserted when signals from the source are accepted
s_axi_tx_tready Output user_clk
and when outgoing data is ready to send.
s_axi_tx_tlast(1) Input user_clk Signals the end of the frame.
Specifies the number of valid bytes in the last data
beat; valid only while s_axi_tx_tlast is asserted.
s_axi_tx_tkeep is the byte qualifier that indicates
s_axi_tx_tkeep[0:(n–1)] or whether the content of the associated byte of
Input user_clk
s_axi_tx_tkeep[(n–1):0](1) s_axi_tx_tdata is valid or not. The Aurora 8B/10B core
expects the data to be filled continuously from LSB
to MSB. There cannot be invalid bytes interleaved
with the valid s_axi_tx_tdata bus.
Asserted when outgoing AXI4-Stream signals or
s_axi_tx_tvalid Input user_clk
signals from the source are valid.

Notes:
1. This port is not available if the Streaming interface option is chosen.

Aurora 8B/10B v11.1 Send Feedback

13
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐2: User I/O Ports (RX)

Clock
Name Direction Domain Description

USER_DATA_M_AXI_RX
m_axi_rx_tdata[0:8(n–1)] or Incoming data from channel partner (Ascending bit
Output user_clk
m_axi_rx_tdata[8(n–1):0] order).
Signals the end of the incoming frame (asserted for
m_axi_rx_tlast(1) Output user_clk
a single user clock cycle).
m_axi_rx_tkeep[0:(n–1)] or Specifies the number of valid bytes in the last data
Output user_clk
m_axi_rx_tkeep[(n–1):0] (1) beat.
Asserted when outgoing data and control signals
m_axi_rx_tvalid Output user_clk or data and control signals from an Aurora 8B/10B
core are valid.

Notes:
1. This port is not available if the Streaming interface option is chosen.

Framing Interface
Figure 2-7 shows the framing user interface of the Aurora 8B/10B core, with the
AXI4-Stream compliant ports for TX and RX data.
X-Ref Target - Figure 2-7

s_axi_tx_data m_axi_rx_tdata
s_axi_tx_tkeep m_axi_rx_tkeep
s_axi_tx_tlast m_axi_rx_tlast
Framing
s_axi_tx_tvalid m_axi_rx_tvalid
Interface
s_axi_tx_tready
reset
X12992
user_clk

Figure 2‐7: Aurora 8B/10B Core Framing Interface (AXI4-Stream)

Transmitting Data
To transmit data, the user application manipulates control signals to cause the core to do
the following:

• Take data from the user interface on the s_axi_tx_tdata bus when
s_axi_tx_tvalid and s_axi_tx_tready signals are asserted.
• Stripe the data across lanes in the Aurora 8B/10B channel.
• Use the s_axi_tx_tvalid signal to transmit data. The user application can deassert
s_axi_tx_tvalid to insert idles on the line (introduce stalls or pause).
• Pause data (that is, insert idles) (s_axi_tx_tvalid is deasserted).

Aurora 8B/10B v11.1 Send Feedback

14
PG046 October 19, 2023
 Chapter 2: Product Specification

When the core receives data, it does the following:

• Detects and discards control bytes (idles, clock compensation, Start of Channel PDU
(SCP), End of Channel Protocol Data Unit (ECPDU) and PAD.
• Asserts framing signal (m_axi_rx_tlast) and specifies the number of valid bytes in
the last data beat (m_axi_rx_tkeep).
• Recovers data from the lanes
• Assembles data for presentation to the user interface on the m_axi_rx_tdata bus by
asserting of the m_axi_rx_tvalid signal.

The Aurora 8B/10B core samples data only when both s_axi_tx_tready and
s_axi_tx_tvalid are asserted (High).

AXI4-Stream data is only valid when it is framed. Data outside of a frame is ignored. To start
a frame, assert s_axi_tx_tvalid while the first word of data is on the s_axi_tx_tdata
port. To end a frame, assert s_axi_tx_tlast while the last word (or partial word) of data
is on the s_axi_tx_tdata port and use s_axi_tx_tkeep to specify the number of valid
bytes in the last data beat.

In the case of frames that are a single word long or less, s_axi_tx_tvalid and
s_axi_tx_tlast are asserted simultaneously.

Aurora 8B/10B Frames

The TX submodules translate each received user frame through the TX interface to an
Aurora 8B/10B frame. The start of frame (SOF) is indicated by the addition of a 2-byte SCP
code group at the beginning of the frame. The end of frame (EOF) is indicated by the
addition of a 2-byte End of Channel Protocol (ECP) code group at the end of the frame. Idle
code groups are inserted whenever data is not available. Code groups are 8B/10B encoded
byte pairs and all data are sent as code groups, so user frames with an odd number of bytes
have a control character called PAD appended to the end of the frame to fill out the final
code group. Table 2-3 shows a typical Aurora 8B/10B frame with an even number of data
bytes.

Length
The user application controls the channel frame length by manipulation of the
s_axi_tx_tvalid and s_axi_tx_tlast signals. The Aurora 8B/10B core responds with
start-of-frame and end-of-frame ordered sets, /SCP/ and /ECP/ respectively, as shown in
Table 2-3.

Table 2‐3: Typical Channel Frame

Data Byte Data Byte Data Byte Data Byte Data Byte
/SCP/1 /SCP/2 ... /ECP/ 1 /ECP/ 2
0 1 2 n–1 n

Aurora 8B/10B v11.1 Send Feedback

15
PG046 October 19, 2023
 Chapter 2: Product Specification

Example A: Simple Data Transfer

Figure 2-8 shows an example of a simple data transfer on an AXI4-Stream interface that is
n-bytes wide. In this case, the amount of data being sent is 3n bytes and so requires three
data beats. s_axi_tx_tready is asserted, indicating that the AXI4-Stream interface is
ready to transmit data.

The user application asserts s_axi_tx_tvalid during the first n bytes to begin data
transfer. An /SCP/ ordered set is placed on the first two bytes of the channel to indicate the
start of the frame. Then the first n–2 data bytes are placed on the channel. Because of the
offset required for the /SCP/, the last two bytes in each data beat are always delayed one
cycle and transmitted on the first two bytes of the next beat of the channel.

To end the data transfer, the user application asserts s_axi_tx_tlast, the last data bytes,
and the appropriate value on the s_axi_tx_tkeep bus. In this example,
s_axi_tx_tkeep is set to N in the waveform for the demonstration to indicate that all
bytes are valid in the last data beat. When s_axi_tx_tlast is asserted,
s_axi_tx_tready is deasserted in the next clock cycle and the core uses the gap in the
data flow to send the final offset data bytes and the /ECP/ ordered set, indicating the end
of the frame. s_axi_tx_tready is reasserted on the next cycle to allow data transfers to
continue.
X-Ref Target - Figure 2-8

user_clk

s_axi_tx_tvalid

s_axi_tx_tready

s_axi_tx_tlast

s_axi_tx_tdata[0:(8n-1)] X Data 0 Data 1 Data 2 X

s_axi_tx_tkeep[0:(n-1)] X N X

x14617

Figure 2‐8: Simple Data Transfer

Example B: Data Transfer with Pad

Figure 2-9 shows an example of a (3n–1)-byte data transfer that requires the use of a pad.
The Aurora 8B/10B core appends a pad character for a frame with an odd number of bytes
as per the protocol requirement. A transfer of 3n–1 data bytes requires two full n-byte data
words and one partial data word. In this example, s_axi_tx_tkeep is set to N–1 to
indicate n–1 valid bytes in the last data word.

Aurora 8B/10B v11.1 Send Feedback

16
PG046 October 19, 2023
 Chapter 2: Product Specification

X-Ref Target - Figure 2-9

user_clk

s_axi_tx_tvalid

s_axi_tx_tready

s_axi_tx_tlast

s_axi_tx_tdata [0:(8n-1)]

s_axi_tx_tkeep [0:(n-1)]

X13796

Figure 2‐9: Data Transfer with Pad

Example C: Data Transfer with Pause

Figure 2-10 shows how a user interface can pause data transmission during a frame
transfer. In this example, the user application pauses the data flow after the first n bytes by
deasserting s_axi_tx_tvalid, and transmitting idles instead. The pause continues until
s_axi_tx_tvalid is deasserted.
X-Ref Target - Figure 2-10

user_clk

s_axi_tx_tvalid

s_axi_tx_tready

s_axi_tx_tlast

s_axi_tx_tdata [0:(8n-1)]

s_axi_tx_tkeep [0:(n-1)]

X13797

Figure 2‐10: Data Transfer with Pause

Aurora 8B/10B v11.1 Send Feedback

17
PG046 October 19, 2023
 Chapter 2: Product Specification

Example D: Data Transfer with Clock Compensation

The Aurora 8B/10B core automatically interrupts data transmission when it sends clock
compensation sequences. The clock compensation sequence imposes 12 bytes of overhead
per lane every 10,000 bytes.

Figure 2-11 shows how the Aurora 8B/10B core pauses data transmission during the clock
compensation sequence.
X-Ref Target - Figure 2-11

user_clk

s_axi_tx_tvalid

s_axi_tx_tready

s_axi_tx_tlast

s_axi_tx_tdata [0:(8n-1)]

s_axi_tx_tkeep [0:(n-1)]

X13795

Figure 2‐11: Data Transfer Paused by Clock Compensation

Because of the need for clock compensation every 10,000 bytes per lane (5,000 clocks for
2-byte per lane designs; 2,500 clocks for 4-byte per lane designs), you cannot continuously
transmit data nor can data be continuously received. During clock compensation, data
transfer is suspended for six or three clock periods.

Receiving Data
The RX submodules have no built-in elastic buffer for user data. As a result, there is no
m_axi_rx_tready signal on the RX AXI4-Stream interface. The only way for the user
application to control the flow of data from an Aurora 8B/10B channel is to use one of the
core optional flow control features.

The m_axi_rx_tvalid signal is asserted concurrently with the first word of each frame
from the Aurora 8B/10B core. m_axi_rx_tlast is asserted concurrently with the last word
or partial word of each frame. The m_axi_rx_tkeep port indicates the number of valid
bytes in the final word of each frame.The m_axi_rx_tkeep signal is only valid when
m_axi_rx_tlast is asserted.

The Aurora 8B/10B core can deassert m_axi_rx_tvalid anytime, even during a frame.
The core can occasionally deassert m_axi_rx_tvalid even if the frame was originally
transmitted without pauses. These pauses are a result of the framing character stripping
and left alignment process.

Aurora 8B/10B v11.1 Send Feedback

18
PG046 October 19, 2023
 Chapter 2: Product Specification

Figure 2-12 shows an example of 3n bytes of received data interrupted by a pause. Data is
presented on the m_axi_rx_tdata bus. When the first n bytes are placed on the bus,
m_axi_rx_tvalid is asserted to indicate that data is ready for the user application. The
core deasserts m_axi_rx_tvalid on the clock cycle following the first data beat to
indicate a pause in the data flow.

After the pause, the core asserts m_axi_rx_tvalid and continues to assemble the
remaining data on the m_axi_rx_tdata bus. At the end of the frame, the core asserts
m_axi_rx_tlast. The core also computes the value of m_axi_rx_tkeep bus and
presents it to the user application based on the total number of valid bytes in the final word
of the frame.
X-Ref Target - Figure 2-12

user_clk

m_axi_rx_tvalid PAUSE

m_axi_rx_tlast
m_axi_rx_tdata[0:(8n-1)] X Data 0 X Data 1 Data 2 X

m_axi_rx_tkeep[0:(n-1)] X N X

X14615

Figure 2‐12: Data Reception with Pause

Framing Efficiency
There are two factors that affect framing efficiency in the Aurora 8B/10B core:

• Size of the frame

• Width of the datapath

The CC sequence, which uses 12 bytes on every lane every 10,000 bytes, consumes about
0.12% of the total channel bandwidth.

All bytes in the Aurora 8B/10B core are sent in two-byte code groups. Aurora 8B/10B frames
with an even number of bytes have four bytes of overhead, two bytes for SCP (start of
frame) and two bytes for ECP (end of frame). Aurora 8B/10B frames with an odd number of
bytes have five bytes of overhead, four bytes of framing overhead plus an additional byte
for the pad byte.

The core transmits frame delimiters only in specific lanes of the channel. SCP is only
transmitted in the left-most (most-significant) lane, and ECP is only transmitted in the
right-most (least-significant) lane. Any space in the channel between the last code group
with data and the ECP code group is padded with idles. The result is reduced resource cost
for the design, at the expense of a minimal additional throughput cost. Though the SCP and
ECP could be optimized for additional throughput, the single frame per cycle limitation
imposed by the user interface would make this improvement unusable in most cases.

Aurora 8B/10B v11.1 Send Feedback

19
PG046 October 19, 2023
 Chapter 2: Product Specification

Use the formula shown in Equation 2-1 to calculate the efficiency for a design of any
number of lanes, any width of interface, and frames of any number of bytes.

Note: This formula includes the overhead for clock compensation.

100n
E = -------------------------------------------------------- Equation 2‐1
12n
n + 4 + 0.5 + IDLEs + ----------
Where: 9988

° E = The average efficiency of a specified PDU

° n = Number of user data bytes

° 12n/9988 = Clock correction overhead

° 4 = Overhead of SCP + ECP

° 0.5 = Average PAD overhead

° IDLEs = Overhead for IDLEs = (w/2) – 1

° w = Interface width

Table 2-4 is an example calculated from Equation 2-1. It shows the efficiency for an 8-byte,
4-lane channel and illustrates that the efficiency increases as the length of channel frames
increases.

Table 2‐4: Efficiency Example

User Data Bytes Percent Efficiency
100 92.92
1,000 99.14
10,000 99.81

Table 2-5 shows the overhead in an 8-byte, 4-lane channel when transmitting 256 bytes of
frame data across the four lanes. The resulting data unit is 264 bytes long due to start and
end characters, and due to the idles necessary to fill out the lanes. This amounts to 3.03%
of overhead in the transmitter. In addition, a 12-byte clock compensation sequence occurs
on each lane every 10,000 bytes, which adds a small amount more to the overhead. The
receiver can handle a slightly more efficient data stream because it does not require any
idle pattern.

Aurora 8B/10B v11.1 Send Feedback

20
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐5: Typical Overhead for Transmitting 256 Data Bytes

Character or Data Byte
Lane Clock Function
Byte 1 Byte 2
0 1 Start of channel frame /SCP/1 /SCP/ 2
1 1 Channel frame data D0 D1
2 1 Channel frame data D2 D3
3 1 Channel frame data D4 D5
.
.
.
0 33 Channel frame data D254 D255
1 33 Transmit idles /I/ /I/
2 33 Transmit idles /I/ /I/
3 33 End of channel frame /ECP/ 1 /ECP/2

Table 2-6 shows the overhead that occurs with each value of s_axi_tx_tkeep.

Table 2‐6: Value of s_axi_tx_tkeep and Corresponding Bytes of Overhead

s_axi_tx_tkeep Bus Value
(in Binary) SCP Pad ECP Idles Total

1000_0000 1 11
6
1100_0000 0 10
1110_0000 1 9
4
1111_0000 0 8
2 2
1111_1000 1 7
2
1111_1100 0 6
1111_1110 1 5
0
1111_1111 0 4

Note: When the Little Endian option is selected in the Vivado Integrated Design Environment (IDE),
s_axi_tx_tkeep bit ordering changes from MSB to LSB.

Aurora 8B/10B v11.1 Send Feedback

21
PG046 October 19, 2023
 Chapter 2: Product Specification

Streaming Interface
Figure 2-13 shows an example of an Aurora 8B/10B core configured with a streaming user
interface.
X-Ref Target - Figure 2-13

s_axi_tx_data m_axi_rx_tdata

s_axi_tx_tvalid
Streaming m_axi_rx_tvalid
s_axi_tx_tready
Interface
reset X12993

user_clk

Figure 2‐13: Aurora 8B/10B Core Streaming User Interface

Streaming Interface Ports

Table 2-1, page 13 and Table 2-2, page 14 list duplex and simplex core AXI4-Stream TX and
RX data port descriptions.

Transmitting and Receiving Data

The streaming interface allows the Aurora 8B/10B channel to be used as a pipe. After
initialization, the channel is always available for writing, except when sending clock
compensation sequences. Core data transfer is compliant with the AXI4-Stream protocol.

When s_axi_tx_tvalid is deasserted, gaps are created between words and the gaps are
preserved, except when clock compensation sequences are being transmitted.

When data arrives at the RX side of the Aurora 8B/10B channel it is presented on the
m_axi_rx_tdata bus and m_axi_rx_tvalid is asserted. The data must be read
immediately or it is lost. If this is unacceptable, a buffer must be connected to the RX
interface to hold the data until it can be used.

Example A: TX Streaming Data Transfer

Figure 2-14 shows a typical example of streaming data. The Aurora 8B/10B core indicates
that it is ready to transfer data by asserting s_axi_tx_tready. One cycle later, the user
logic indicates that it is ready to transfer data by asserting the s_axi_tx_tdata bus and
the s_axi_tx_tvalid signal. Because both ready signals are now asserted, data D0 is
transferred from the user logic to the Aurora 8B/10B core. Data D1 is transferred on the
following clock cycle. In this example, the Aurora 8B/10B core deasserts its ready signal,
s_axi_tx_tready, and no data is transferred until the next clock cycle when, again, the
s_axi_tx_tready signal is asserted. Then the user logic deasserts s_axi_tx_tvalid
on the next clock cycle, and no data is transferred until both ready signals are asserted.

Aurora 8B/10B v11.1 Send Feedback

22
PG046 October 19, 2023
 Chapter 2: Product Specification

X-Ref Target - Figure 2-14

user_clk

s_axi_tx_tvalid

s_axi_tx_tready

s_axi_tx_tdata [0:(64n-1)] Databeat Databeat Databeat Databeat

X X X
0 1 2 3

X13805

Figure 2‐14: Typical Streaming Data Transfer

Example B: RX Streaming Data Transfer

Figure 2-15 shows the receiving end of the data transfer that is shown in Figure 2-14.
X-Ref Target - Figure 2-15

user_clk

m_axi_rx_tvalid

m_axi_rx_tdata [0:(8n-1)]

X13802

Figure 2‐15: Typical Data Reception

Flow Control
This section explains how to use Aurora 8B/10B flow control. Two optional flow control
interfaces are available on cores using a framing interface. Native flow control (NFC)
regulates the data transmission rate at the receiving end of a full-duplex channel. User flow
control (UFC) accommodates high-priority messages for control operations.

User Flow Control Interface

The UFC interface is created when the core is generated with UFC enabled (Figure 2-16).
UFC s_axi_ufc_tx_tvalid and s_axi_ufc_tx_tready ports on the TX side start the
UFC message and a 3-bit s_axi_ufc_tx_tdata port specifies the length of the message.
With s_axi_ufc_tx_tready asserted, the UFC message can be supplied to the data port.

Aurora 8B/10B v11.1 Send Feedback

23
PG046 October 19, 2023
 Chapter 2: Product Specification

X-Ref Target - Figure 2-16

user_clk m_axi_ufc_rx_tdata[0:(8n-1)]
reset m_axi_ufc_rx_tkeep[0:1]
UFC
s_axi_ufc_tx_tvalid m_axi_ufc_rx_tvalid
Interface
s_axi_ufc_tx_tdata[0:2] m_axi_ufc_rx_tlast
s_axi_ufc_tx_tready

Figure 2‐16: Aurora 8B/10B Core UFC Interface

The RX side of the UFC interface consists of a set of AXI4-Stream ports that allows the UFC
message to be read as a frame. Simplex modules retain only the interface needed to send
data in the supported direction.

Table 2-7 describes the ports for the UFC interface.

Table 2‐7: UFC I/O Ports

Clock
Name Direction Domain Description

UFC_S_AXIS_TX
Asserted to request a UFC message be sent to
the channel partner. Must be held until
s_axi_ufc_tx_tready is asserted. Do not assert
s_axi_ufc_tx_tvalid Input user_clk
this signal unless the entire UFC message is
ready to be sent; a UFC message cannot be
interrupted after it has started.
Specifies the size of the UFC message that is
s_axi_ufc_tx_tdata[0:2] or
Input user_clk sent. The SIZE encoding is a value between 0 and
s_axi_ufc_tx_tdata[2:0]
7. See Table 2-8.
Asserted when an Aurora 8B/10B core is ready to
read the contents of the UFC message. On the
cycle after the s_axi_ufc_tx_tready signal is
asserted, data on the s_axi_tx_tdata port is
s_axi_ufc_tx_tready Output user_clk treated as UFC data. s_axi_tx_tdata data
continues to be used to fill the UFC message
until enough cycles have passed to send the
complete message. Unused bytes from a UFC
cycle are discarded.
UFC_M_AXIS_RX
m_axi_ufc_rx_tdata[0:(8n–1)] or Incoming UFC message data from the channel
Output user_clk
m_axi_ufc_rx_tdata[(8n–1):0] partner (n = 16 bytes maximum).
Asserted when the values on the
m_axi_ufc_rx_tvalid Output user_clk
m_axi_ufc_rx_tdata ports are valid.

Aurora 8B/10B v11.1 Send Feedback

24
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐7: UFC I/O Ports (Cont’d)

Name Direction Clock Description

Domain
m_axi_ufc_rx_tlast Output user_clk Signals the end of the incoming UFC message.
Specifies the number of valid bytes of data
presented on the m_axi_ufc_rx_tdata port on the
m_axi_ufc_rx_tkeep[0:(n–1)] or
Output user_clk last word of a UFC message. Valid only when
m_axi_ufc_rx_tkeep[(n–1):0]
m_axi_ufc_rx_tlast is asserted (n = 16 bytes
maximum).

Transmitting UFC Messages

UFC messages can carry an even number of data bytes from 2 to 16. The user application
specifies the length of the message by driving a SIZE code on the s_axi_ufc_tx_tdata
port. Table 2-8 shows the legal SIZE code values for UFC messages.

Table 2‐8: SIZE Encoding

SIZE Field Contents UFC Message Size
000 2 bytes
001 4 bytes
010 6 bytes
011 8 bytes
100 10 bytes
101 12 bytes
110 14 bytes
111 16 bytes

To send a UFC message, the user application asserts s_axi_ufc_tx_tvalid while driving
the s_axi_ufc_tx_tdata port with the desired SIZE code. The s_axi_ufc_tx_tvalid
signal must be held until the Aurora 8B/10B core asserts the s_axi_ufc_tx_tready
signal. The data for the UFC message must be placed on the s_axi_tx_tdata port,
starting on the first cycle after s_axi_ufc_tx_tready is asserted. The core deasserts
s_axi_tx_tready while the s_axi_tx_tdata port is being used for UFC data.

Note: A UFC request should be given only after completion of the current UFC request; back-to-back
UFC requests might not honored by IP.

Aurora 8B/10B v11.1 Send Feedback

25
PG046 October 19, 2023
 Chapter 2: Product Specification

Figure 2-17 shows a useful circuit for switching TX_D from sending regular data to UFC
data.
X-Ref Target - Figure 2-17

Aurora 8B/10B Core

UFC Data 0
s_axi_tx_tdata Data Interface

Regular Data 1

s_axi_tx_tready
UFC Interface

X12996-072717

Figure 2‐17: Data Switching Circuit

Table 2-9 shows the number of cycles required to transmit UFC messages of different sizes
based on the width of the AXI4-Stream data interface. UFC messages should never be
started until all message data is available. Unlike regular data, UFC messages cannot be
interrupted after s_axi_ufc_tx_tready has been asserted until completion of the
current UFC message.

Aurora 8B/10B v11.1 Send Feedback

26
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐9: Number of Data Beats Required to Transmit UFC Messages

s_axi_ufc_tx_tdata AXI4 Interface Number of AXI4 Interface Number of
UFC Message Value Width Data Beats Width Data Beats
2 Bytes 0 1
4 Bytes 1 2
6 Bytes 2 3 1
8 Bytes 3 4
2 Bytes 10 Bytes
10 Bytes 4 5
12 Bytes 5 6
14 Bytes 6 7 2
16 Bytes 7 8
2 Bytes 0
1
4 Bytes 1
6 Bytes 2
2 1
8 Bytes 3
4 Bytes 12 Bytes
10 Bytes 4
3
12 Bytes 5
14 Bytes 6
4 2
16 Bytes 7
2 Bytes 0
4 Bytes 1 1
6 Bytes 2
8 Bytes 3 1
6 Bytes 14 Bytes
10 Bytes 4 2
12 Bytes 5
14 Bytes 6
3
16 Bytes 7 2
2 Bytes 0
4 Bytes 1
1
6 Bytes 2
8 Bytes 3 16 Bytes or
8 Bytes 1
10 Bytes 4 more

12 Bytes 5
2
14 Bytes 6
16 Bytes 7

Aurora 8B/10B v11.1 Send Feedback

27
PG046 October 19, 2023
 Chapter 2: Product Specification

Example A: Transmitting a Single-Cycle UFC Message

The procedure for transmitting a single cycle UFC message is shown in Figure 2-18. In this
case, a 4-byte message is being sent on a 4-byte interface.

Note: The s_axi_ufc_tx_tready signal is deasserted for two cycles. Aurora 8B/10B cores use
this gap in the data flow to transmit the UFC header and message data.
X-Ref Target - Figure 2-18

user_clk

s_axi_ufc_tx_tvalid

s_axi_ufc_tx_tready

s_axi_ufc_tx_tdata[0:2]

s_axi_tx_tready

s_axi_tx_tdata [0:(8n-1)]

X13803

Figure 2‐18: Transmitting a Single-Cycle UFC Message

Example B: Transmitting a Multicycle UFC Message

The procedure for transmitting a two-cycle UFC message is shown in Figure 2-19. In this
case the user application is sending a 4-byte message using a 2-byte interface.
s_axi_tx_tready is deasserted for three cycles: one cycle for the UFC header which is
sent during the s_axi_ufc_tx_tready cycle, and two cycles for UFC data.
X-Ref Target - Figure 2-19

user_clk

s_axi_ufc_tx_tvalid

s_axi_ufc_tx_tready

s_axi_ufc_tx_tdata[0:2] X X 1 X X X

s_axi_tx_tready

s_axi_tx_tdata[0:(8n–1)] Data0 Data1 Data2 X UFC UFC Data3

Figure 2‐19: Transmitting a Multicycle UFC Message

Aurora 8B/10B v11.1 Send Feedback

28
PG046 October 19, 2023
 Chapter 2: Product Specification

Receiving User Flow Control Messages

When the Aurora 8B/10B core receives a UFC message, it passes the data to the user
application through a dedicated UFC AXI4-Stream interface. The data is presented on the
m_axi_ufc_rx_tdata port; m_axi_ufc_rx_tvalid indicates the start of the message
data and m_axi_ufc_rx_tlast indicates the end. m_axi_ufc_rx_tkeep is used to
show the number of valid bytes on m_axi_ufc_rx_tdata during the last cycle of the
message.

Example A: Receiving a Single-Cycle UFC Message

Figure 2-20 shows an Aurora 8B/10B core with a 4-byte data interface receiving a 4-byte
UFC message. The core presents this data to the user application by asserting
m_axi_ufc_rx_tvalid and m_axi_ufc_rx_tlast to indicate a single cycle frame.
m_axi_ufc_rx_tkeep is set to 4'hF, indicating only the four most significant bytes of
the interface are valid.
X-Ref Target - Figure 2-20

user_clk

m_axi_ufc_rx_tvalid

m_axi_ufc_rx_tlast

m_axi_ufc_rx_tkeep [0:(n-1)]

m_axi_ufc_rx_tdata [0:(8n-1)]

X13801

Figure 2‐20: Receiving a Single-Cycle UFC Message

Example B: Receiving a Multicycle UFC Message

Figure 2-21 shows an Aurora 8B/10B core with a 4-byte interface receiving an 8-byte
message.

Note: The resulting frame is two cycles long, with m_axi_ufc_rx_tkeep set to 4'hF on the
second cycle indicating that all four bytes of the data are valid.

Aurora 8B/10B v11.1 Send Feedback

29
PG046 October 19, 2023
 Chapter 2: Product Specification

X-Ref Target - Figure 2-21

user_clk

m_axi_ufc_rx_tvalid

m_axi_ufc_rx_last

m_axi_ufc_rx_tkeep[0:(8n–1)] X X X X 4'hF X X

m_axi_ufc_rx_tdata[0:(n–1)] X X X UFC UFC X X

X13798

Figure 2‐21: Receiving a Multicycle UFC Message

Native Flow Control

The Aurora 8B/10B protocol includes the native flow control (NFC) interface (Figure 2-22)
which allows receivers to control the rate at which data is received by specifying the number
of idle data beats that must be placed into the data stream. The data flow can even be
turned off completely by requesting the transmitter to temporarily send only idles (XOFF).
NFC is typically used to prevent FIFO overflow conditions. For a detailed explanation of NFC
operation and codes, see the Aurora 8B/10B Protocol Specification (SP002) [Ref 5].
X-Ref Target - Figure 2-22

user_clk m_axi_nfc_tx_tvalid
reset m_axi_nfc_tx_tdata[0:3]
NFC
s_axi_nfc_tx_tvalid
Interface
s_axi_nfc_tx_tdata[0:3]
s_axi_nfc_tx_tready

Figure 2‐22: Aurora 8B/10B Core NFC Interface

Native Flow Control Interface

The NFC interface is created when the core is generated with the NFC option enabled. This
interface includes a request (s_axi_nfc_tx_tvalid) and an acknowledge
(s_axi_nfc_tx_tready) port that are used to send NFC messages, and a 4-bit
s_axi_nfc_tx_tdata port to specify the number of idle cycles requested.

Table 2-10 lists the ports for the NFC interface available only in full-duplex Aurora 8B/10B
cores.

Aurora 8B/10B v11.1 Send Feedback

30
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐10: NFC I/O Ports

Clock
Name Direction Domain Description

NFC_S_AXIS_TX
s_axi_nfc_tx_tready Output user_clk Asserted when the core accepts an NFC request.
s_axi_nfc_tx_tdata[0:3] Indicates the number of PAUSE idles the channel
or Input user_clk partner must send when it receives the NFC message.
s_axi_nfc_tx_tdata[3:0] Must be held until s_axi_nfc_tx_tready is asserted.
Asserted to request an NFC message be sent to the
s_axi_nfc_tx_tvalid Input user_clk channel partner. Must be held until s_axi_nfc_tx_tready
is asserted.
NFC_M_AXIS_RX
m_axi_nfc_tx_tvalid Output user_clk Indicates an NFC message is received from the partner.
m_axi_nfc_tx_tdata[0:3]
or Indicates the PAUSE value of the received NFC
Output user_clk message. This port should be sampled with
m_axi_nfc_tx_tdata[3:0]
m_axi_nfc_tx_tvalid.

Table 2-11 shows the codes for native flow control (NFC). These values are driven on bits
[0:3] for big endian format and [3:0] for little endian format.

Table 2‐11: NFC Codes

s_axi_nfc_tx_tdata Idle Cycles Requested
0000 0 (XON)
0001 2
0010 4
0011 8
0100 16
0101 32
0110 64
0111 128
1000 256
1001 to 1110 Reserved
1111 Infinite (XOFF)

The user application asserts s_axi_nfc_tx_tvalid and writes an NFC code to

s_axi_nfc_tx_tdata. The NFC code indicates the minimum number of idle cycles the
channel partner should insert in its TX data stream. The user application must hold
s_axi_nfc_tx_tvalid and s_axi_nfc_tx_tdata until s_axi_nfc_tx_tready is
asserted. Aurora 8B/10B cores cannot transmit data while sending NFC messages.
s_axi_tx_tready is always deasserted on the cycle following an
s_axi_nfc_tx_tready assertion.

Aurora 8B/10B v11.1 Send Feedback

31
PG046 October 19, 2023
 Chapter 2: Product Specification

Example A: Transmitting an NFC Message

Figure 2-23 shows an example of the transmit timing when the user application sends an
NFC message to a channel partner.

The s_axi_nfc_tx_tready signal is deasserted for one cycle (assumes that n is at least
2) to create the gap in the data flow in which the NFC message is placed.
X-Ref Target - Figure 2-23

Figure 2‐23: Transmitting an NFC Message

Aurora 8B/10B v11.1 Send Feedback

32
PG046 October 19, 2023
 Chapter 2: Product Specification

Example B: Receiving a Message with NFC Idles Inserted

Figure 2-24 shows an example of the signals on the TX user interface when an NFC message
is received. In this case, the NFC message has a code of 0001, requesting two data beats of
idles. The core deasserts s_axi_tx_tready on the user interface until enough idles have
been sent to satisfy the request. In this example, the core is operating in immediate NFC
mode, where NFC idles are inserted immediately. Aurora 8B/10B cores can also operate in
completion mode, where NFC idles are only inserted between frames. If a completion mode
core receives an NFC message while it is transmitting a frame, it finishes transmitting the
frame before deasserting s_axi_tx_tready to insert idles.
X-Ref Target - Figure 2-24

user_clk

s_axi_tx_tkeep [0:(n-1)]

s_axi_tx_tlast

s_axi_tx_tvalid

s_axi_tx_tready

s_axi_tx_tdata [0:(8n-1)]

X13799

Figure 2‐24: Receiving a Message with NFC Idles Inserted

Status, Control, and the Transceiver Interface

The status and control ports of the Aurora 8B/10B core allow applications to monitor the
channel and use built-in features of the transceivers. This section provides diagrams and
port descriptions for the status and control interface, the transceiver serial I/O interface,
and the sideband initialization ports used exclusively for simplex modules.

Aurora 8B/10B v11.1 Send Feedback

33
PG046 October 19, 2023
 Chapter 2: Product Specification

Status and Control Ports

Table 2-12 describes the function of each of the status and control ports of the Aurora
8B/10B core. Table 2-14 describes the transceiver ports.

Table 2‐12: Status and Control Ports

Name Direction Clock Description

Domain
Asserted when Aurora 8B/10B channel initialization is
channel_up/
complete and the channel is ready for data transfer.
tx_channel_up/ Output user_clk
tx_channel_up and rx_channel_up are only applicable to
rx_channel_up
their respective simplex cores.
Asserted for each lane upon successful lane initialization,
lane_up[0:m–1]/
with each bit representing one lane. tx_lane_up[0:(m–1)]
tx_lane_up[0:m–1]/ Output user_clk
and rx_lane_up[0:(m–1)] are only applicable to their
rx_lane_up[0:m–1] (1)
respective simplex cores.
Channel frame/protocol error detected. This port is
frame_err Output user_clk asserted for a single clock. Not available on simplex TX
cores.
hard_err/ Hard error detected (asserted until Aurora 8B/10B core
tx_hard_err/ Output user_clk resets). tx_hard_err and rx_hard_err are only applicable to
rx_hard_err their respective simplex cores.
Soft error detected in the incoming serial stream. Not
soft_err Output user_clk
available on simplex TX core.
Resets the Aurora 8B/10B core (active-High). This signal
reset/
must be asserted for at least six user_clk cycles.
tx_system_reset/ Input async
tx_system_reset and rx_system_reset are only applicable to
rx_system_reset
their respective simplex cores.
The reset signal for the transceivers is connected to the top
level through a debouncer. The gt_reset port should be
asserted when the module is first powered up in hardware.
This systematically resets all Physical Coding Sublayer (PCS)
and Physical Medium Attachment (PMA) subcomponents of
gt_reset Input async the transceiver.
The signal is debounced using init_clk_in and must be
asserted for six init_clk_in cycles.
See the Reset section in the respective transceiver user
guide for further details.
link_reset_out Output init_clk Driven High if hot-plug count expires.
The init_clk_in port is required because user_clk stops when
gt_reset is asserted. It is recommended that the frequency
chosen for init_clk_in be lower than the GT Reference Clock
input frequency.
For UltraScale and UltraScale+ architecture designs:
init_clk_in Input NA
See UltraScale FPGAs GTH Transceivers User Guide (UG576)
[Ref 1] for more details on the range of allowable frequency
as updated in the GUI customization. This is also connected
to the DRPCLK port of GTHE3/GTYE3/GTHE4/GTYE4 channel
primitives.

Aurora 8B/10B v11.1 Send Feedback

34
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐12: Status and Control Ports (Cont’d)

Name Direction Clock Description

Domain
Asserted when the RX channel partner has completed lane
tx_aligned (2) Input user_clk
initialization for all lanes. Typically connected to rx_aligned.
Asserted when the RX channel partner has completed
tx_bonded (2) Input user_clk channel bonding. Not needed for single-lane channels.
Typically connected to rx_bonded.
Asserted when the RX channel partner has completed
tx_verify (2) Input user_clk
verification. Typically connected to rx_verify.
Asserted when reset is required because of initialization
status of RX channel partner. This signal must be
tx_reset(2) Input user_clk
synchronous to user_clk and must be asserted for at least
one user_clk cycle. Typically connected to rx_reset.
Asserted when RX module has completed lane initialization.
rx_aligned (3) Output user_clk
Typically connected to tx_aligned.
Asserted when RX module has completed channel bonding.
rx_bonded(3) Output user_clk Not used for single-lane channels. Typically connected to
tx_bonded.
Asserted when RX module has completed verification.
rx_verify(3) Output user_clk
Typically connected to tx_verify.
Asserted when the RX module needs the TX module to
rx_reset (3) Output user_clk
restart initialization. Typically connected to tx_reset.

Notes:
1. m is the number of transceivers. See Error Status Signals for more details.
2. Only available in TX-only simplex dataflow mode and sideband as back channel core configuration.
3. Only available in RX-only simplex dataflow mode and sideband as back channel core configuration.

Aurora 8B/10B v11.1 Send Feedback

35
PG046 October 19, 2023
 Chapter 2: Product Specification

Full-Duplex Cores
Full-Duplex Status and Control Ports

Full-duplex cores provide a TX and an RX Aurora 8B/10B channel connection. Figure 2-25
shows the status and control interface for a full-duplex Aurora 8B/10B core.
X-Ref Target - Figure 2-25

loopback hard_err
power_down Full-Duplex soft_err
Status and
reset frame_err
Control
gt_reset Interface channel_up
init_clk_in lane_up

X13002

Figure 2‐25: Status and Control Interface for Full-Duplex Cores

Error Status Signals

Equipment problems and channel noise can cause errors during Aurora 8B/10B channel
operation. 8B/10B encoding allows the Aurora 8B/10B core to detect all single-bit errors
and most multi-bit errors that occur in the channel and to assert soft_err on every cycle.
The TX simplex cores do not include a soft_err port. All transmit data is assumed to be
correct at transmission unless there is an equipment issue.

The core also monitors each transceiver for hardware errors such as buffer
overflow/underflow and loss of lock and asserts the hard_err signal. RX-side hard errors
in simplex cores are reported using the rx_hard_err signal. Catastrophic hardware errors
can also manifest themselves as a burst of soft errors. The core uses the leaky bucket
algorithm described in the Aurora 8B/10B Protocol Specification (SP002) [Ref 5] to detect
large numbers of soft errors occurring in a short period of time, and asserts the hard_err
or rx_hard_err signal.

Whenever a hard error is detected, the core automatically resets itself and attempts to
re-initialize. This allows the channel to re-initialize and to be reestablished as soon as the
hardware issue that caused the hard error is resolved. Soft errors do not lead to a reset
unless enough of them occur in a short period of time.

Aurora 8B/10B cores with the AXI4-Stream data interface can also detect errors in Aurora
8B/10B frames and assert the frame_err signal. Frame errors can be frames with no data,
consecutive Start of Frame symbols, and consecutive End of Frame symbols. This signal is
not available with simplex TX cores. When available, this signal is usually asserted close to
a soft_err assertion, with soft errors being the main cause of frame errors.

Table 2-13 summarizes the error conditions Aurora 8B/10B cores can detect and the error
signals used to alert the user application.

Aurora 8B/10B v11.1 Send Feedback

36
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐13: Error Signals in Cores

Signal Description TX RX
TX Overflow/Underflow: The elastic buffer for TX data overflows or underflows.
This can occur when the user clock and the reference clock sources are not running x
at the same frequency.
RX Overflow/Underflow: The elastic buffer for RX data overflows or underflows.
This can occur when the clock source frequencies for the two channel partners are x
not within ± 100 ppm.
hard_err Bad Control Character: The protocol engine attempts to send a bad control
x
character. This is an indication of design corruption or catastrophic failure.
Soft Errors: There are too many soft errors within a short period of time. The Aurora
8B/10B protocol defines a leaky bucket algorithm for determining the acceptable
number of soft errors within a given time period. When this number is exceeded, the x
physical connection might be too poor for communication using the current voltage
swing and pre-emphasis settings.
Invalid Code: The 10-bit code received from the channel partner was not a valid
code in the 8B/10B table. This usually means a bit was corrupted in transit, causing
x
a good code to become unrecognizable. Typically, this also results in a frame error
or corruption of the current channel frame.
soft_err Disparity Error: The 10-bit code received from the channel partner did not have the
correct disparity. This error is also usually caused by corruption of a good code in
x
transit, and can result in a frame error or bad data if it occurs while a frame is being
sent.
No Data in Frame: A channel frame is received with no data. x
Truncated Frame: A channel frame is started without ending the previous channel
x
frame, or a channel frame is ended without being started.
frame_err Invalid Control Character: The protocol engine receives a control character that it
x
does not recognize.
Invalid UFC Message Length: A UFC message is received with an invalid length. x

Full-Duplex Initialization

Full-duplex cores initialize automatically after power-up, reset, or hard error and perform
the Aurora 8B/10B initialization procedure until the channel is ready for use. The lane_up
bus indicates which lanes in the channel have finished the lane initialization procedure. This
signal can be used to help debug equipment problems in a multi-lane channel.
channel_up is asserted only after the core completes the entire initialization procedure.

Aurora 8B/10B cores cannot receive data before channel_up is asserted. Only the
m_axi_rx_tvalid signal on the user interface should be used to qualify incoming data.
channel_up can be inverted and used to reset modules that drive the TX side of a
full-duplex channel, because no transmission can occur until after channel_up. If user
application modules need to be reset before data reception, one of the lane_up signals
can be inverted and used. Data cannot be received until after all the lane_up signals are
asserted.

Aurora 8B/10B v11.1 Send Feedback

37
PG046 October 19, 2023
 Chapter 2: Product Specification

Note: The WATCHDOG_TIMEOUT parameter is available in the channel_init_sm module to

control the watchdog timers present in the channel initialization process.

Simplex Cores
Simplex TX Status and Control Ports

Simplex TX cores allow user applications to transmit data to a simplex RX core. They have no
RX connection. Figure 2-26 shows the status and control interface for a simplex TX core.
X-Ref Target - Figure 2-26

power_down tx_hard_err
tx_system_reset tx_channel_up
Simplex TX
tx_aligned Status and tx_lane_up
tx_bonded Control
tx_verify
Interface
tx_reset

X13004

Figure 2‐26: Status and Control Interface for Simplex TX Core

Simplex RX Status and Control Ports

Simplex RX cores allow user applications to receive data from a simplex TX core. Figure 2-27
shows the status and control interface for a simplex RX core.
X-Ref Target - Figure 2-27

power_down rx_hard_err
rx_system_reset soft_err
frame_err
Simplex RX rx_channel_up
Status and
rx_lane_up
Control
Interface rx_aligned
rx_bonded
rx_verify
rx_reset
X13003

Figure 2‐27: Status and Control Interface for Simplex RX Core

Aurora 8B/10B v11.1 Send Feedback

38
PG046 October 19, 2023
 Chapter 2: Product Specification

Simplex Initialization

Simplex cores do not depend on signals from an Aurora 8B/10B channel for initialization.
Instead, the TX and RX sides of simplex channels communicate their initialization state
through a set of sideband initialization signals: aligned, bonded, verify, and reset;
one set for the TX side with a TX_ prefix, and one set for the RX side with an RX_ prefix. The
bonded port is only used for multi-lane cores.

There are two ways to initialize a simplex module using the sideband initialization signals:

• Send the information from the RX sideband initialization ports to the TX sideband
initialization ports
• Drive the TX sideband initialization ports independently of the RX sideband
initialization ports using timed initialization intervals

Both initialization methods are described in the following sections.

Using a Back Channel

A back channel is the safest way to initialize and maintain a simplex channel in the absence
of a channel between RX and TX. The back channel need only deliver messages to the TX
side to indicate which of the sideband initialization signals is asserted when the signals
change.

The example design included in the example_design directory with simplex Aurora 8B/10B
cores shows a simple side channel that uses three or four I/O pins on the device.

Using Timers

If a back channel is not possible, serial channels can be initialized by driving the TX simplex
initialization with a set of timers. The timers must be designed carefully to meet the needs
of the system because the average time for initialization depends on many channel specific
conditions such as clock rate, channel latency, skew between lanes, and noise.
C_ALIGNED_TIMER, C_BONDED_TIMER, and C_VERIFY_TIMER are timers used for assertion
of tx_aligned, tx_bonded, and tx_verify signals, respectively. These timers use
worst-case values obtained from corner case functional simulations and implemented in the
<component name>_core module.

Note: These signals are not updated on the actual status of the channel, but after the timer expires.

Some of the initialization logic in the Aurora 8B/10B module uses watchdog timers to
prevent deadlock. These watchdog timers are used on the RX side of the channel, and can
interfere with the proper operation of TX initialization timers. If the RX simplex module goes
from aligned, bonded or verify, to reset, make sure that it is not because the TX logic
spend too much time in one of those states. If a particularly long timer is required to meet
the needs of the system, the watchdog timers can be adjusted by editing the module. For
most cases, this should not be necessary and is not recommended.

Aurora 8B/10B v11.1 Send Feedback

39
PG046 October 19, 2023
 Chapter 2: Product Specification

Aurora 8B/10B channels normally re-initialize only in the case of failure. When there is no
back channel available, event-triggered re-initialization is impossible for most errors
because, typically, the RX side detects the failure while the condition must be handled by
the TX side. The solution is to make timer-driven TX simplex modules re-initialize on a
regular basis. If a catastrophic error occurs, the channel is reset and running again after the
next re-initialization period arrives. System designers should balance the average time
required for re-initialization against the maximum time their system can tolerate an
inoperative channel to determine the optimum re-initialization period for their systems.

Note: The WATCHDOG_TIMEOUT parameter is available in the tx_channel_init_sm/

rx_channel_init_sm module to control the watchdog timers present in the channel initialization
process.

Transceiver Interface
IMPORTANT: The ports in the Transceiver Control And Status Interface must be driven in accordance
with the appropriate GT user guide. Using the input signals listed in Table 2-14 improperly might result
in unpredictable behavior of the IP core.

This interface includes the serial I/O ports of the transceivers, and the control and status.

Table 2‐14: Transceiver Ports

Name Direction Clock Domain Description
rxp[0:m–1](1) Input RX Serial Clock Positive differential serial data input pin.
rxn[0:m–1] (1) Input RX Serial Clock Negative differential serial data input pin.
txp[0:m–1] (1) Output TX Serial Clock Positive differential serial data output pin.
txn[0:m–1](1) Output TX Serial Clock Negative differential serial data output pin.
Drives the power-down input of the
power_down Input user_clk transceiver. For more information, see the
applicable transceiver user guide.
The loopback[2:0] port selects between the
normal operation and different loopback
loopback[2:0] Input user_clk modes of the transceiver. See the 7 Series
FPGAs GTX/GTH Transceivers User Guide
(UG476) [Ref 3].
tx_resetdone_out Output user_clk The TXRESETDONE signal of the transceiver.
rx_resetdone_out Output user_clk The RXRESETDONE signal of the transceiver.

Aurora 8B/10B v11.1 Send Feedback

40
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐14: Transceiver Ports (Cont’d)

Name Direction Clock Domain Description
Indicates that the incoming serial transceiver
refclk is locked by the transceiver
phase-locked loop (PLL). See the applicable
transceiver guide for more information.
tx_lock Output user_clk Note: The tx_lock signal coming from the
aurora is asynchronous. A synchronizer is
added to use it in user_clk/init_clk domain.
Update the clock domain column of
tx_lock signal to async from the user_clk.
Transceiver DRP Ports
drpaddr_in/
Input drpclk_in DRP address bus.
gt<=: lane :>_drpaddr
drpclk_in/
Input drpclk_in DRP interface clock.
gt<=: lane :>_drpclk
drpdi_in/ Data bus for writing configuration data from
Input drpclk_in
gt<=: lane :>_drpdi the FPGA logic resources to the transceiver.
drpdo_out/ Data bus for reading configuration data from
Output drpclk_in
gt<=: lane :>_drpdo the transceiver to the FPGA logic resources.
drpen_in/
Input drpclk_in DRP enable signal.
gt<=: lane :>_drpen
Indicates that the operation is complete for
drprdy_out/
Output drpclk_in write operations and data is valid for read
gt<=: lane :>_drprdy
operations.
drpwe_in/
Input drpclk_in DRP write enable.
gt<=: lane :>_drpwe
Transceiver Debug Ports
gt<lane>_txpostcursor_
Transmitter post-cursor TX pre-emphasis
in/ Input async
control.
gt_txpostcursor (4)(6)
gt<lane>_txprecursor_i
Transmitter pre-cursor TX pre-emphasis
n/ Input async
control.
gt_txprecursor (4)(6)
Set High to work with txchardispval to force
gt<lane>_txchardispmo running disparity negative or positive when
Input user_clk
de_in(4) (6)(10) encoding TXDATA. Set Low to use normal
running disparity.
gt<lane>_txchardispval Works with txchardispmode to provide
Input user_clk
_in (4)(6) (10) running disparity control.
gt<lane>_txdiffctrl_in/
Input async Driver Swing Control.
gt_txdiffctrl(4)(6)
Allows the main cursor coefficients to be
gt<lane>_txmaincursor_
Input async directly set if the TX_MAINCURSOR_SEL
in(4)(6) (10)
attribute is set to 1'b1.

Aurora 8B/10B v11.1 Send Feedback

41
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐14: Transceiver Ports (Cont’d)

Name Direction Clock Domain Description
The txpolarity port is used to invert the
polarity of outgoing data.
gt<lane>_txpolarity_in/ • 0: Not inverted. TXP is positive, and TXN is
Input user_clk
gt_txpolarity(4)(6) negative.
• 1: Inverted. TXP is negative, and TXN is
positive.
gt<lane>_tx_buf_err_ou TX buffer status. txbufstatus[1] is connected
Output user_clk
t(4)(6)(10) to this port.
When set to 1'b1, the current value of the
gt<lane>_rxlpmhfhold_i high-frequency boost is held.
Input user_clk
n(4)(7)(10) When set to 1'b0, the high-frequency boost
is adapted.
When set to 1'b1, the current value of the
gt<lane>_rxlpmlfhold_i low-frequency boost is held.
Input user_clk
n(4)(7)(10) When set to 1'b0, the low-frequency boost
is adapted.
RX datapath
gt<lane>_rxlpmen_in/
Input async • 0: decision feedback equalizer (DFE)
gt_rxlpmen(4)(8)
• 1: low power mode (LPM)
gt<lane>_rxcdrovrden_i
n/ Input async Reserved.
gt_rxcdrovrden (4)(8)
gt<lane>_rxcdrhold_in/ Hold the clock data recovery (CDR) control
Input async
gt_rxcdrhold(4)(9) loop frozen.
gt<lane>_rxdfelpmreset
This port is driven High and then deasserted
_in/ Input async
to start the DFE reset process.
gt_rxdfelpmreset(4)(8)
GTX transceiver:
• RXDFEVP[6:0] = RXMONITOROUT[6:0]
• RXDFEUT[6:0] = RXMONITOROUT[6:0]
gt<lane>_rxmonitorout • RXDFEAGC[4:0] = RXMONITOROUT[4:0]
Output async
_out(4)(8) (10) GTH transceiver:
• RXDFEVP[6:0] = RXMONITOROUT[6:0]
• RXDFEUT[6:0] = RXMONITOROUT[6:0]
• RXDFEAGC[3:0] = RXMONITOROUT[4:1]
Select signal for rxmonitorout[6:0]
• 2'b00: Reserved
gt<lane>_rxmonitorsel_ • 2'b01: Select automatic gain control
Input async
in(4)(8) (10) (AGC) loop
• 2'b10: Select UT loop
• 2'b11: Select VP loop
gt<lane>_eyescanreset_
This port is driven High and then deasserted
in/ Input async
to start the EYESCAN reset process.
gt_eyescanreset(4)(9)

Aurora 8B/10B v11.1 Send Feedback

42
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐14: Transceiver Ports (Cont’d)

Name Direction Clock Domain Description
gt<lane>_eyescandatae
Asserts High for one rec_clk cycle when an
rror_out/
Output async (unmasked) error occurs while in the COUNT
gt_eyescandataerror(4)(9
) or ARMED state.

gt<lane>_eyescantrigge
r_in/ Input user_clk Causes a trigger event.
gt_eyescantrigger(4)(9)
This signal from the comma detection and
realignment circuit is High to indicate that
the parallel data stream is properly aligned
on byte boundaries according to comma
gt<lane>_rxbyteisaligne detection.
Output user_clk
d_out(4) (9)(10)
• 0: Parallel data stream not aligned to byte
boundaries
• 1: Parallel data stream aligned to byte
boundaries
This signal is asserted when the comma
alignment block detects a comma. The
gt<lane>_rxcommadet_ assertion occurs several cycles before the
out/ Output user_clk comma is available at the FPGA RX interface.
gt_rxcommadet(4)(9)
• 0: Comma not detected
• 1: Comma detected
Indicates the corresponding byte shown on
gt<lane>_rx_disp_err_o
Output user_clk rxdata has a disparity error. The rxdisperr pin
ut(4)(9)(10)
of the transceiver is connected to this port.
Indicates the corresponding byte shown on
gt<lane>_rx_not_in_tabl rxdata was not a valid character in the 8B/10B
Output user_clk
e_out (4) (9)(10) table. rxnotintable pin of the transceiver is
connected to this port.
This signal from the comma detection and
realignment circuit indicates that the byte
alignment within the serial data stream has
changed due to comma detection.
• 0: Byte alignment has not changed
gt<lane>_rx_realign_ou • 1: Byte alignment has changed
Output user_clk
t(4)(9)(10) Data can be lost or repeated when alignment
occurs, which can cause data errors (and
disparity errors when
the 8B/10B decoder is used).
The rxbyterealign pin of the transceiver is
connected to this port.
gt<lane>_rx_buf_err_ou RX buffer status. rxbufstatus[2] is connected
Output user_clk
t(4)(9)(10) to this port.
PLL0LOCK and PLL1LOCK of the 7 series FPGA
gt0_pll0lock_out,
Output async GTP transceiver COMMON block.
gt0_pll1lock_out (4)
Available shared logic is in core.

Aurora 8B/10B v11.1 Send Feedback

43
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐14: Transceiver Ports (Cont’d)

Name Direction Clock Domain Description
PLL0LOCK and PLL1LOCK of the 7 series FPGA
GTP transceiver COMMON block.
gt1_pll0lock_out,
Output async Available shared logic is in the core and two
gt1_pll1lock_out (4)
quads are selected during core
configuration.
This active-High PLL frequency lock signal
indicates that the PLL frequency is within
predetermined tolerance. The transceiver
gt<lane>_cplllock_out/
Output async and its clock outputs are not reliable until this
gt_cplllock (4)
condition is met.
Not available with 7 series FPGAs GTP
transceivers.
When this port is driven High, errors are
gt<lane>_txprbsforceer forced in the PRBS transmitter. While this
r_in/ Input async port is asserted, the output data pattern
gt_prbsforceerr (4)(6) contains errors. When txprbssel is set to 000,
this port does not affect txdata.
gt<lane>_txprbssel_in/ Transmitter pseudo-random binary sequence
Input async
gt_prbssel(4)(6) (PRBS) generator test pattern control.
This port is used to reset the TX PCS. It is
gt<lane>_txpcsreset_in/ driven High and then deasserted to start the
Input async
gt_txpcsreset (4)(6) PCS reset process. In sequential mode,
activating this port only resets the TX PCS.
This port is used to reset the TX PMA. It is
gt<lane>_txpmareset_in driven High and then deasserted to start the
/ Input async TX PMA reset process. In sequential mode,
gt_txpmareset(4)(6) activating this port resets both the TX PMA
and the TX PCS.
This active-High signal indicates the GTX or
GTH transceiver TX has finished reset and is
gt<lane>_txresetdone_
ready for use. This port is driven Low when
out/ Output async
gttxreset goes High and is not driven High
gt_txresetdone(4)(6)
until the GTX/GTH transceiver TX detects
txuserrdy High.
gt<lane>_txbufstatus_o
ut/ Output user_clk TX buffer status.
gt_txbufstatus(4)(6)
When High, this signal blocks transmission of
gt<lane>_txinhibit_in/
Input user_clk TXDATA and forces the serial data output pin
gt_txinhibit(4)(5)(10)(11) TXP TXP to 0 and TXN to 1.

Aurora 8B/10B v11.1 Send Feedback

44
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐14: Transceiver Ports (Cont’d)

Name Direction Clock Domain Description
When asserted, this active-High signal
indicates the GTX or GTH transceiver RX has
finished reset and is ready for use. In
sequential mode, this port is driven Low
gt<lane>_rxresetdone_
when gtrxreset is driven High. This signal is
out/ Output user_clk
not driven High until rxuserrdy goes High. In
gt_rxresetdone (4)(9)
single mode, this port is driven Low when any
of the RX resets are asserted. This signal is
not asserted until all RX resets are deasserted
and rxuserrdy is asserted.
gt<lane>_rxbufstatus_o
ut/ Output user_clk RX buffer status.
gt_rxbufstatus(4)(9)
When set to 1'b1, the high-frequency boost
gt<lane>_rxlpmhfovrde is controlled by the RXLPM_HF_CFG attribute.
Input user_clk
n_in(4)(7) When set to 1'b0, the high-frequency boost
is controlled by the rxlpmhfhold signal.
gt<lane>_rxlpmreset_in(
4)(7) Input async Resets the LPM circuitry.

gt<lane>_rxprbserr_out
This non-sticky status output indicates that
/ Output user_clk
PRBS errors have occurred.
gt_rxprbserr(4)(9)
gt<lane>_rxprbssel_in/
Input user_clk Receiver PRBS checker test pattern control.
gt_rxprbssel(4)(9)
gt<lane>_rxpcsreset_in/ This port is driven High and then deasserted
Input user_clk
gt_rxpcsreset(4)(9) to start the PCS reset process.
gt<lane>_rxpmareset_in
This port is driven High and then deasserted
/ Input async
to start RX PMA reset process.
gt_rxpmareset (4)(9)
This active-High signal indicates GTH/GTP RX
PMA reset is complete. This port is driven
gt<lane>_rxpmaresetdo Low when gtrxreset or rxpmareset is
ne_out/ Output async asserted.
gt_rxpmaresetdone(4) Available for duplex and RX-Only simplex
configuration and applicable for 7 series GTP
and GTH transceivers only.
gt<lane>_dmonitorout_
out/ Output async Digital Monitor Output Bus
gt_dmonitorout (4)(9)
This port is driven High and then deasserted
to start the RX elastic buffer reset process. In
gt<lane>_rxbufreset_in/
Input async either single mode or sequential mode,
gt_rxbufreset(4)(9)
activating rxbufreset resets the RX elastic
buffer only.

Aurora 8B/10B v11.1 Send Feedback

45
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐14: Transceiver Ports (Cont’d)

Name Direction Clock Domain Description
PCSRSVDIN[2] is the DRP reset pin. For
read-only registers, if a DRPRDY is not seen
within 500 DRPCLK cycles after initiating a
gt_pcsrsvdin(4)(10)(11) Input async DRP transaction, reset the DRP interface
using the port PCSRSVDIN[2]. This is
available only in UltraScale device based
designs.

Notes:
1. m is the number of transceivers.
2. The transceiver debug ports are enabled if the Additional transceiver control and status ports check-box option is
selected in the Vivado IDE.
3. <lane> takes values from 0 to AURORA_LANES.
4. For designs using UltraScale devices, the prefixes of the optional transceiver debug ports for single-lane cores are
changed from gt<lane> to gt, and the postfixes _in and _out are removed. For multi-lane cores, the prefixes of the
optional transceiver debug ports gt(n) are aggregated into a single port.
5. See the relevant transceiver user guide for more information on transceiver debug ports.
6. Available with duplex and TX-only simplex configurations.
7. Available with duplex and RX-only simplex configurations and applicable to 7 series FPGAs GTP transceivers only.
8. Available with duplex and RX-only simplex configurations and applicable to 7 series FPGAs GTX and GTH transceivers
only.
9. Available with duplex and RX-only simplex configurations.
10.Not available with UltraScale devices.
11.Not available in 7 series devices.
12.Refer to the relevant UG transceiver guide for more information on DRP ports.

Clock Interface
The clock interface has ports for the transceiver reference clock, and parallel clocks that the
Aurora 8B/10B core shares with application logic.

Table 2-15 describes the Aurora 8B/10B core clock ports.

Table 2‐15: Clock Ports for Aurora 8B/10B Core

Clock Ports Direction Description
If a PLL is used to generate clocks for the Aurora 8B/10B core,
the pll_not_locked signal should be connected to the inverse
pll_not_locked Input of the locked signal of the PLL. If the PLL is not used to
generate clock signals for the Aurora 8B/10B core, tie
pll_not_locked to ground.
Parallel clock shared by the Aurora 8B/10B core and the user
application. user_clk and sync_clk are the outputs of a PLL or
user_clk Input BUFG driven by tx_out_clk. These clock generations are
available in the <component name>_clock_module file.
The user_clk goes as the txusrclk2 input to the transceiver.

Aurora 8B/10B v11.1 Send Feedback

46
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐15: Clock Ports for Aurora 8B/10B Core (Cont’d)

Clock Ports Direction Description
Parallel clock used by the internal synchronization logic of the
sync_clk Input transceivers. sync_clk goes as the txusrclk input to the
transceiver.
The gt_refclk (clkp/clkn) port is a dedicated external
gt_refclk Input
transceiver reference clock fed through IBUFDS_GTE.
This port should be connected to the
gt0_pll0outclk_in/ PLL0OUTCLK/PLL1OUTCLK clock output generated by
Input
gt1_pll0outclk_in GTPE2_COMMON. This port is internally connected to the
PLL0CLK/PLL1CLK port on the GTPE2_CHANNEL primitive.
This port should be connected to the
PLL0OUTREFCLK/PLL1OUTREFCLK clock output generated by
gt0_pll0outrefclk_in/
Input GTPE2_COMMON. This port is internally connected to the
gt0_pll1outrefclk_in
PLL0REFCLK/PLL1REFCLK port on the GTPE2_CHANNEL
primitive.
quad1_common_lock_in Input GTPE2_COMMON PLL lock input port.

Table 2-16 provides details about the port changes due to selection of the Shared Logic
option.

Table 2‐16: Port Changes Due to Shared Logic Option

Name Direction Description Remarks
Enabled when Shared Logic
in core is selected. The
gt_refclk1_p
Input Transceiver reference clock 1 Single Ended GT REFCLK
gt_refclk1_n option gives a single-ended
gtrefclk1 input.
Enabled when Shared Logic
in core is selected. The
gt_refclk2_p
Input Transceiver reference clock 2 Single Ended GT REFCLK
gt_refclk2_n
option gives a single ended
gtrefclk2 input.
Enabled when Shared Logic
Output of IBUFDS_GTE2 for in core is selected. Not
gt_refclk1_out Output
transceiver reference clock 1 available for the Single
Ended GT REFCLK option.
Enabled when Shared Logic
Output of IBUFDS_GTE2 for in core is selected. Not
gt_refclk2_out Output
transceiver reference clock 2 available for the Single
Ended GT REFCLK option.
Parallel clock shared by Enabled when Shared Logic
user_clk_out Output
Aurora 8B/10B core in core is selected
txusrclk for Artix ™ 7 device Enabled when Shared Logic
sync_clk_out Output
GTP transceiver designs in core is selected
Output of de-bouncer for Enabled when Shared Logic
sys_reset_out Output
reset in core is selected

Aurora 8B/10B v11.1 Send Feedback

47
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐16: Port Changes Due to Shared Logic Option (Cont’d)

Name Direction Description Remarks
Output of de-bouncer for Enabled when Shared Logic
gt_reset_out Output
gt_reset in core is selected
Enabled when Shared Logic
init_clk_p in core is selected. The
Free running system/board
Input Single Ended INIT CLK
init_clk_n clock
option provides a single
ended init_clk input.
Enabled when Shared Logic
Output of system clock in core is selected. Not
init_clk_out Output
differential buffer available for the Single
Ended INIT CLK option.
gt0_pll0refclklost_out Indicates refclklost port of Enabled when Shared Logic
Output
gt1_pll0refclklost_out (1) the GTPE2_COMMON in core is selected.
Indicates PLL of the
quad1_common_lock_out Enabled when Shared Logic
Output GTPE2_COMMON is
quad2_common_lock_out (1) in core is selected.
achieved lock
gt0_pll0outclk_out
gt0_pll1outclk_out
gt0_pll0outrefclk_out
gt0_pll1outrefclk_out Clock outputs generated by Enabled when Shared Logic
Output
gt1_pll0outclk_out GTPE2_COMMON in core is selected.
gt1_pll1outclk_out
gt1_pll0outrefclk_out
gt1_pll1outrefclk_out(1)
Indicates PLL of the
Enabled when Shared Logic
gt<quad>_qplllock_out (2)(3) Output GTXE2_COMMON/GTHE2_
in core is selected.
COMMON has achieved lock
Indicates reference clock
gt<quad>_qpllrefclklost input to the Enabled when Shared Logic
Output
_out (2)(3) GTXE2_COMMON/GTHE2_ in core is selected.
COMMON is lost
gt_qpllclk_quad<quad>_out Clock outputs generated by
Enabled when Shared Logic
gt_qpllclk_quad<quad> Output GTXE2_COMMON/GTHE2_
in core is selected.
_out (2)(3) COMMON
Quad phase-locked loop
(QPLL) reference clock
gt_qpllrefclk_quad<quad>_ Enabled when Shared Logic
Output output generated by the
out in core is selected.
GTXE2_COMMON/GTHE2_C
OMMON
Indicates PLL of the Enabled when Shared Logic
gt<quad>_qplllock_in Input GTXE2_COMMON/GTHE2_ in example design is
COMMON has achieved lock selected.

Aurora 8B/10B v11.1 Send Feedback

48
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐16: Port Changes Due to Shared Logic Option (Cont’d)

Name Direction Description Remarks
Indicates that the reference
Enabled when Shared Logic
clock input to the
gt<quad>_qpllrefclklost_in Input in example design is
GTXE2_COMMON/GTHE2_
selected.
COMMON is lost
Clock outputs generated
Enabled when Shared Logic
from the
gt_qpllclk_quad<quad>_in Input in example design is
GTXE2_COMMON/GTHE2_C
selected.
OMMON
QPLL reference clock output
Enabled when Shared Logic
gt_qpllrefclk_quad<quad>_ generated from the
Input in example design is
in GTXE2_COMMON/GTHE2_C
selected.
OMMON

Enabled when Shared Logic

gt_qpllreset_out Output Tied to ground in example design is
selected.

Enabled when Shared Logic

Parallel clock shared by
tx_out_clk Output in example design is
Aurora 8B/10B core
selected.

Notes:
1. Ports from GTPE2_COMMON are applicable only to Artix 7 FPGA GTP transceiver designs.
2. Ports from GTXE2_COMMON/GTHE2_COMMON are applicable only to 7 series FPGA GTX/GTH transceiver
designs.
3. These ports are enabled for each selected quad. <quad> refers to the transceiver quad numbered from 1 to 12.

CRC
The CRC module provides a 16-bit or 32-bit CRC, implemented for user data. Table 2-17
describes the CRC module ports.

Table 2‐17: CRC Module Ports

Clock
Port Name Direction Description
Domain
CRC valid port. When asserted High, enables sampling
crc_valid Output user_clk
the crc_pass_fail_n signal.
The crc_pass_fail_n signal is asserted High on transmit
and receive when the CRC values for both the transmitter
crc_pass_fail_n Output user_clk
and receiver match. The crc_pass_fail_n signal should only
be sampled with the crc_valid signal.

See Using CRC in Chapter 3 for more information.

Aurora 8B/10B v11.1 Send Feedback

49
PG046 October 19, 2023
 Chapter 2: Product Specification

Generation of Aurora Without GT

This option is available only in UltraScale and UltraScale+ devices. When enabled, it
generates the Aurora core without the GT and moves the transceiver from the core to the
support level in example design. Table 2-18 provides the list of ports used to interact with
the GT transceiver, outside the Aurora IP.

Table 2‐18: List of Ports to Interact with GT Transceiver

Clock
Name Direction Description
Domain
Active-High indication to Aurora that the
transmitter reset sequence of transceiver
gttxresetdone_in Input user_clk
primitives as initiated by the reset controller helper
block is completed.

Active-High indication to Aurora that the receiver

gtrxresetdone_in Input user_clk reset sequence of transceiver primitives as initiated
by the reset controller helper block has completed

User interface for data received by transceiver

rxdata_in Input user_clk
channels
Connects to rxctrl3_out port of UltraScale GT
rxnotintable_in(1) Input -
Wizard
Connects to rxctrl1_out port of UltraScale GT
rxdisperr_in (1) Input -
Wizard
Connects to rxctrl2_out port of UltraScale GT
rxchariscomma_in(1) Input -
Wizard
Connects to rxctrl0_out port of UltraScale GT
rxcharisk_in(1) Input -
Wizard
Connects to rxbyterealign_out port of UltraScale
rxrealign_in(1) Input -
GT Wizard

Connects to rxbufstatus_out port of UltraScale GT

rxbufferr_in (1) Input -
Wizard

Connects to txbufstatus_out port of UltraScale GT

txbuferr_in(1) Input -
Wizard

Connects to rxchanisaligned_out port of UltraScale

chbonddone_in (1) Input -
GT Wizard
Connects to txoutclk_out port of UltraScale GT
txoutclk_in Input -
Wizard
Connects to cplllock_out port of UltraScale GT
txlock_in Input
Wizard

rxfsm_datavalid_out Output user_clk Active-High indicates all lanes on Aurora are up

Aurora 8B/10B v11.1 Send Feedback

50
PG046 October 19, 2023
 Chapter 2: Product Specification

Table 2‐18: List of Ports to Interact with GT Transceiver (Cont’d)

Name Direction Clock Description

Domain
Active-High if Aurora detects polarity reversal in
rxpolarity_out Output user_clk incoming rxdata This data is used as a part of the
polarity inversion logic while bringing the link up.
rxreset_out Output user_clk Reset generated from Aurora lanes
Connects to TXCTRL2 on transceiver channel
txcharisk_out Output user_clk
primitives

Connected to user interface in US GT Wizard for

txdata_out Output user_clk
data to be transmitted by transceiver channels

Connects to gtwiz_reset_rx_datapath_in port of US

gtrxreset_out Output user_clk
GT Wizard
Aligns the byte boundary when comma plus or
enacommaalign_out Output user_clk
minus is detected.
Connects to rxchanbonden_in port of US GT
enchansync_out Output user_clk
Wizard

Notes:
1. See UltraScale FPGAs Transceivers Wizard LogiCORE IP Product Guide (PG182)[Ref 16] for more information.
2. See UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 1], 7 Series FPGAs GTP Transceivers User
Guide (UG482) [Ref 2] and 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476) [Ref 3] for more information
on polarity inversion

Aurora 8B/10B v11.1 Send Feedback

51
PG046 October 19, 2023
 Chapter 3

Designing with the Core

This chapter includes guidelines and additional information to make designing with the
core easier.

General Design Guidelines

This section describes the steps required to turn an Aurora 8B/10B core into a fully
functioning design with user-application logic. Not all implementations require all of the
design steps listed here. Follow the logic design guidelines in this manual carefully.

Use the Example Design as a Starting Point

Each instance of an Aurora 8B/10B core that is created is delivered with an example design
that can be simulated and implemented in an FPGA. This design can be used as a starting
point for your own design or can be used to troubleshoot the user application, if necessary.

Know the Degree of Difficulty

Aurora 8B/10B core design is challenging to implement in any technology, and the degree
of difficulty is further influenced by:

• Maximum system clock frequency

• Targeted device architecture
• Nature of the user application

All Aurora 8B/10B core implementations require careful attention to system performance
requirements. Pipelining, logic mappings, placement constraints, and logic duplications are
all methods that help boost system performance.

Keep It Registered
To simplify timing and increase system performance in an FPGA design, keep all inputs and
outputs registered with flip-flops between the user application and the core in its respective
clock domain. Registering signals might not be possible for all paths, but doing so
simplifies timing analysis and makes it easier for the AMD tools to place-and-route the
design.

Aurora 8B/10B v11.1 Send Feedback

52
PG046 October 19, 2023
 Chapter 3: Designing with the Core

Recognize Timing Critical Signals

The XDC file provided with the example design for the core identifies the critical signals and
the timing constraints that should be applied.

Make Only Allowed Modifications

The Aurora 8B/10B core is not expected to be modified by user. Any modifications might
have adverse effects on the system timings and protocol compliance. Supported user
configurations of the Aurora 8B/10B core can only be made by selecting options from the
AMD Vivado™ Integrated Design Environment (IDE).

Serial Transceiver Reference Clock Interface

The core requires a high-quality, low-jitter reference clock to drive the high-speed TX clock
and clock recovery circuits in the transceivers. It also requires at least one frequency-locked
parallel clock for synchronous operation with the user application. The Aurora 8B/10B core
configures Channel Phase Locked Loop (CPLL) in AMD UltraScale™ and UltraScale+™
families, Virtex™ 7, Kintex™ 7, and Zynq™ 7000 family designs.

Clock Interface Ports for the Aurora 8B/10B Core

See Table 2-15, page 46 for descriptions of the transceiver ports on the clock interface.

Clocking from Neighboring Transceiver Quads

The AMD implementation tools make the necessary adjustments to the north-south routing
and pin swapping to the transceiver clock inputs to route clocks from one quad to another,
when required.

IMPORTANT: The following rules must be observed when sharing a reference clock to ensure that jitter
margins for high-speed designs are met:

• The total number of GTX or GTH transceiver quads sourced by an external clock pin pair
(mgtrefclkn/mgtrefclkp) in 7 series FPGAs must not exceed three quads (one quad
above and one quad below), or 12 GTXE2_CHANNEL/GTHE2_CHANNEL transceivers.
Designs with more than 12 transceivers or more than three quads in 7 series FPGAs
should use multiple external clock pins.
• The total number of transceiver quads sourced by an external clock pin pair
(mgtrefclkn/mgtrefclkp) in UltraScale architecture FPGAs must not exceed five
quads (two quads above and two quads below), or 20 GTHE3_CHANNEL transceivers.

Aurora 8B/10B v11.1 Send Feedback

53
PG046 October 19, 2023
 Chapter 3: Designing with the Core

IMPORTANT: Manual edits are not recommended, but are possible using the recommendations in the
UltraScale FPGAs GTH Transceivers User Guide (UG576) [Ref 1] and 7 Series FPGAs GTX/GTH
Transceivers User Guide (UG476) [Ref 3].

Reset and Power Down

Reset
The reset signals are used to set the Aurora 8B/10B core to a known starting state. On reset,
the core stops any current operation and re-initializes a new channel.

On full-duplex modules, the reset signal resets both the TX and RX sides of the channel.
On simplex modules, tx_system_reset resets TX channels and rx_system_reset
resets RX channels. The gt_reset signal resets the transceivers which eventually resets the
core.

Note: The tx_system_reset is separate from the tx_reset and rx_reset signals used on the
simplex sideband interface.

Use Case 1: Assertion of reset in a duplex core

The reset assertion in the duplex core should be a minimum of six user_clk time
periods. As a result, channel_up is deasserted after three user_clk cycles as shown in
Figure 3-1.
X-Ref Target - Figure 3-1

user_clk
reset
channel_up

X14616

Figure 3‐1: Reset Assertion in a Duplex Core

Use Case 2: gt_reset assertion in a duplex core

Figure 3-2 shows the gt_reset assertion in the duplex core and should be a minimum of
six init_clk_in time periods. As a result, user_clk is stopped after a few clock cycles
because there is no txoutclk from the transceiver and channel_up is subsequently
deasserted.

Aurora 8B/10B v11.1 Send Feedback

54
PG046 October 19, 2023
 Chapter 3: Designing with the Core

X-Ref Target - Figure 3-2

init_clk
gt_reset
user_clk
channel_up
X14613

Figure 3‐2: gt_reset Assertion in a Duplex Core

Use Case 3: tx_system_reset and rx_system_reset assertion in a simplex core

Figure 3-3 shows the simplex-TX core and simplex-RX core connected in a system. TX_IP
and RX_IP could be in the same or multiple device(s).
X-Ref Target - Figure 3-3

TX_IP RX_IP

Simplex-TX Simplex-RX
tx_system_reset rx_system_reset
Core Core

Figure 3‐3: System with Simplex Cores

Figure 3-4 shows the recommended procedure of tx_system_reset and
rx_system_reset assertion in the simplex core.

1. tx_system_reset and rx_system_reset are asserted for at least six clock

user_clk time periods.
2. tx_channel_up and rx_channel_up are deasserted after three user_clk cycles.
3. rx_system_reset is deasserted (or) released after tx_system_reset is deasserted.
This ensures that the transceiver in the simplex-TX core starts transmitting initialization
data much earlier and it enhances the likelihood of the simplex-RX core aligning to the
correct data sequence.
4. rx_channel_up is asserted before tx_channel_up assertion. This condition must be
satisfied by the simplex-RX core and simplex timer parameters (C_ALIGNED_TIMER,
C_BONDED_TIMER and C_VERIFY_TIMER) in the simplex-TX core need to be adjusted to
meet this criteria.
5. tx_channel_up is asserted when the simplex-TX core completes the Aurora 8B/10B
protocol channel initialization sequence transmission for the configured time. Assertion
of tx_channel_up last ensures that the simplex-TX core transmits the Aurora
initialization sequence when the simplex-RX core is ready.

Aurora 8B/10B v11.1 Send Feedback

55
PG046 October 19, 2023
 Chapter 3: Designing with the Core

Note: Long delays between each board reset assertion/de-assertion are not anticipated. System
level considerations might be necessary to ensure each board goes through the reset sequence flow
without long delays. AMD highly recommends timely de-assertion of both board reset signals, with
a suggested gap to be within a few µs to avoid long delays.
X-Ref Target - Figure 3-4

Figure 3‐4: tx_system_reset and rx_system_reset Assertion in the Simplex Core

Note: The above use cases describes the impact on channel up with the assertion of resets during
normal operation.

Aurora 8B/10B Duplex Power On Sequence

During the board power-on sequence, both gt_reset and reset signals must be High.
The transceiver reference clock (GT_REFCLK) and the core free running clocks (INIT_CLK)
are expected to be stable during power-on for the proper functioning of the Aurora 8B/10B
core.
X-Ref Target - Figure 3-5

(boardA) INIT_CLK

gt_reset
de-assert synchronous
reset to user_clk

(boardB) INIT_CLK

gt_reset
de-assert synchronous
reset to user_clk

X15654-120915

Figure 3‐5: Aurora 8B/10B Duplex Power On Sequence

Aurora 8B/10B Duplex Normal Operation Reset Sequence

During normal operation, the reset signal is expected to be asserted for at least 128
user_clk time period before assertion of the gt_reset signal to ensure that the portion
of the core in programmable logic reaches a known reset state before the user_clk signal
is suppressed due to the assertion of gt_reset (Figure 3-6).

Aurora 8B/10B v11.1 Send Feedback

56
PG046 October 19, 2023
 Chapter 3: Designing with the Core

X-Ref Target - Figure 3-6

Figure 3‐6: Aurora 8B/10B Duplex Normal Operation Reset Sequence

Aurora 8B/10B Simplex Power On Sequence

During power-on, the gt_reset and reset signals of both the TX simplex and RX simplex
cores are expected to be High. It is expected that INIT_CLK and GT_REFCLK are stable
during power-on. The gt_reset signal on the TX board must be deasserted first, followed
by the deassertion of gt_reset on the RX side; this ensures proper CDR lock on the RX
side (Figure 3-7).
X-Ref Target - Figure 3-7

(boardA TX) INIT_CLK

A
gt_reset
reset B

(boardB RX) INIT_CLK

gt_reset C

reset D

X15653-120915

Figure 3‐7: Aurora 8B/10B Simplex Power On Reset Sequence

Simplex power-on sequence:

1. Deassert TX-side gt_reset (A)

2. Deassert RX-side gt_reset (C)
3. Deassert RX-side rx_system_reset synchronous to user_clk (D)
4. Deassert TX-side tx_system_reset synchronous to user_clk (B)
Note: Care must be taken to ensure that the (D) to (B) time difference is as minimal as possible.

Aurora 8B/10B Simplex Normal Operation Reset Sequence

For the simplex configuration, it is recommended that the TX side reset sequence is tightly
coupled with the RX side reset sequence because the TX and RX links do not have a
communication feedback path. Note that if the RX side is reset, there is no direct
mechanism to notify the TX side of the reset. Hence, for Aurora 8B/10B simplex cores, reset
coupling needs to be handled at the system level. Every TX-side reset must be followed by
the RX-side and, as shown in Figure 3-8, the time between RX-side reset deassertion and
TX-side reset deassertion must be kept as minimal as possible. Before asserting gt_reset,
a minimum of 128 clock time period is required for ensuring that the portion of the core in

Aurora 8B/10B v11.1 Send Feedback

57
PG046 October 19, 2023
 Chapter 3: Designing with the Core

programmable logic reaches a known reset state before the user_clk is suppressed by the
assertion of gt_reset. The assertion time of gt_reset must be a minimum of six
init_clk time periods, to satisfy the de-bouncing circuit included in the core.
X-Ref Target - Figure 3-8

(boardA TX) INIT_CLK

gt_reset
reset

(boardB RX)
INIT_CLK
gt_reset
reset

X15652-120915

Figure 3‐8: Aurora 8B/10B Simplex Normal Operation Reset Sequence

Power Down
This is an active-High signal. When powerdown is asserted, the transceivers in the Aurora
8B/10B core are turned off, putting them into a non-operating, low-power mode. When
powerdown is deasserted, the core automatically resets. gt_reset must be asserted after
powerdown deassertion as indicated in the guidelines of the transceiver user guide.

CAUTION! Use care when asserting the powerdown signal on cores that use tx_out_clk (see Serial
Transceiver Reference Clock Interface, page 53). tx_out_clk stops when the GTP, GTX, and GTH
transceivers are powered down. See the 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476)
[Ref 3], 7 Series FPGAs GTP Transceivers User Guide (ug482) [Ref 2], and the UltraScale Architecture
GTH Transceivers User Guide (UG576) [Ref 1].

Shared Logic
The shared logic option in the Vivado IDE configures the core to include sharable resources
such as the transceiver quad PLL (QPLL), the transceiver differential refclk buffer
(IBUFDS_GTE2), and clocking and reset logic in the core or in the example design. When the
include shared logic in core option is selected, all sharable resources are available to
multiple instances of the core minimizing the amount of HDL modifications required while
retaining the flexibility to address more use cases.

The shared logic hierarchy is called <component_name>_support. Figure 3-9 and

Figure 3-10 show two hierarchies where the shared logic block is contained either in the
core or in the example design. The difference between the two hierarchies is the boundary
of the core. It is controlled using the Shared Logic option in the Vivado IDE (see Figure 4-4,
page 73).

Aurora 8B/10B v11.1 Send Feedback

58
PG046 October 19, 2023
 Chapter 3: Designing with the Core

Note: The Single Ended option when share logic is in the core will exclude respective differential
clock buffers from the core.
Note: Grayed blocks in Figure 3-9 and Figure 3-10 refer to the IP core.
X-Ref Target - Figure 3-9

<component_name>_exdes

<component_name>

<component_name>_support

Shared Logic <component_name>_core

X14120

Figure 3‐9: Shared Logic Included in Core

X-Ref Target - Figure 3-10

<component_name>_exdes

<component_name>_support

<component_name>

Shared Logic
<component_name>_core

X14121

Figure 3‐10: Shared Logic Included in Example Design

Aurora 8B/10B v11.1 Send Feedback

59
PG046 October 19, 2023
 Chapter 3: Designing with the Core

The contents of the shared logic depend upon the physical interface and the target device.
Shared logic contains instance(s) of the transceiver differential buffer
(IBUFDS_GTE2/IBUFDS_GTE3), support reset logic, and an instantiation of
<USER_COMPONENT_NAME:>_CLOCK_MODULE. Shared logic also contains an instance of
the transceiver common, GTPE2_COMMON, GTXE2_COMMON or GTHE2_COMMON, based
on the selected transceiver type. Support reset logic contains the de-bouncer logic for the
reset and gt_reset ports.

Note: The Aurora 8B/10B core uses CPLL and does not use QPLL (that is,
GTXE2_COMMON/GTHE2_COMMON). QPLL is brought out for Zynq 7000 and 7 series devices and
instantiated in shared logic for uniformity with other AMD serial connectivity cores.

Table 3-1 lists shared resources for each family.

Table 3‐1: Sharable Resources

Transceiver Type used in the Resources
Aurora 8B/10B Core
IBUFDS_GTE2: transceiver reference clock
Zynq 7000 and 7 series device
GT*_COMMON: transceiver clocking;
GTX/GTH/GTP transceivers in 2-byte
BUFG: clocking
mode
IBUFDS: init_clk
IBUFDS_GTE2: transceiver reference clock
Zynq 7000 and 7 series device GT*_COMMON: transceiver clocking
GTX/GTH/GTP transceivers in 4-byte MMCM: clocking
mode 2xBUFG: clocking;
IBUFDS: init_clk
IBUFDS_GTE3: transceiver reference clock
UltraScale GTH Transceivers
BUFG_GT: clocking
IBUFDS_GTE4: transceiver reference clock
UltraScale+ GTH Transceivers
BUFG_GT: clocking

The gt_refclk1_out and gt_refclk2_out signals can be shared by other transceivers

in the design and should follow the transceiver clocking guidelines for connectivity and
transceiver quad proximity.

Figure 3-11 shows the sharable resource connections from the core having shared logic
included (aurora_8b10b_0) to the instance of another core without shared logic
(aurora_8b10b_1). Some ports might change based on the core configuration and the type
of transceiver selected. Table 2-16, page 47 provides details about the port changes due to
selection of the Shared Logic option.

Aurora 8B/10B v11.1 Send Feedback

60
PG046 October 19, 2023
 Chapter 3: Designing with the Core

X-Ref Target - Figure 3-11

Figure 3‐11: Sharable Resource Connection Example Using IP Integrator

Using the Scrambler/Descrambler

A 16-bit additive scrambler/descrambler, implemented for data with the polynomial: G(x) =
X16 + X5 + X4 + X3 + 1, is available in the <component name>_scrambler.v[hd]
module.

It ensures non-occurrence of repetitive data over long periods of time. The scrambler and
descrambler are synchronized based on transmission and reception of the clock
compensation characters respectively.

Note: The scrambler affects data symbols only.

Aurora 8B/10B v11.1 Send Feedback

61
PG046 October 19, 2023
 Chapter 3: Designing with the Core

Using CRC
A 16-bit or 32-bit CRC, implemented for user data, is available in the
<component name>_crc_top.v[hd] module. CRC16 is generated for 2-byte designs,
and CRC32 is generated for 4-byte designs. The crc_valid and crc_pass_fail_n
signals indicate the result of a received CRC with a transmitted CRC (see Table 2-17,
page 49). The CRC-CCITT (16'h1021) and the standard Ethernet polynomial (32'h04C11DB7)
are used as CRC polynomials for 16-bit and 32-bit respectively. The CRC is computed per
lane and is suffixed to the data. At the receiver AXI interface, the CRC is removed and the
packet is sent as received at the AXI interface of the transmitter. Figure 3-12 illustrates how
the same data packet is sent without CRC and when CRC option is enabled.
X-Ref Target - Figure 3-12

Figure 3‐12: User Data Transmission Without and With CRC

Aurora 8B/10B v11.1 Send Feedback

62
PG046 October 19, 2023
 Chapter 3: Designing with the Core

Hot-Plug Logic
Hot-plug logic in Aurora 8B/10B (using the free-running init_clk signal) is based on the
received clock compensation characters. Reception of clock compensation characters by
the Aurora RX interface implies that the communication channel is alive and not broken. If
clock compensation characters are not received in a predetermined time, the hot-plug logic
resets the core and the transceiver. The clock compensation module must be used for
Aurora 8B/10B designs.

IMPORTANT: To ensure predictable link operation, It is highly recommended that hot-plug logic is not
disabled.

Clock Compensation
Clock compensation is a feature allowing up to ±100 ppm difference in the reference clock
frequencies used on each side of an Aurora 8B/10B channel. A standard clock compensation
module <component_name>_standard_cc_module.v[hd] is generated with the core
in accordance with the Aurora 8B/10B Protocol Specification (SP002) [Ref 5].

The standard_cc_module handles the periodicity of generation of the clock

compensation character as described in Table 3-2. The periodicity can be controlled with
CC_FREQ_FACTOR.

Table 3‐2: Clock Compensation Cycles

Lane Width USER_CLK Cycles Between DO_CC DO_CC Duration (USER_CLK cycles)
2 5,000 6
4 2,500 3

The number of lookahead cycles required to prevent a 16-byte UFC message from colliding
with a clock compensation sequence depends on the number of lanes in the channel and
the width of each lane.

Native flow control message requests are not acknowledged during clock compensation
character transmission. This helps to prevent the collision of an NFC message and the clock
compensation sequence.

IMPORTANT: The parameter CC_FREQ_FACTOR determines the frequency of the CC sequence. Any
attempt to increase or decrease the parameter should be done with careful analysis and testing.

Aurora 8B/10B v11.1 Send Feedback

63
PG046 October 19, 2023
 Chapter 3: Designing with the Core

• Be sure the duration and period selected is sufficient to correct for the maximum
difference between the frequencies of the clocks that are used.
• Do not perform multiple clock correction sequences within eight cycles of one another.
• Replacing long sequences of idles (>12 cycles) with CC sequences can reduce EMI.

Using Little Endian Support

The Aurora 8B/10B core supports user interfaces in big endian format by default. It also
supports the little endian format to connect seamlessly to AXI4-Stream compliant IP cores.

Aurora 8B/10B v11.1 Send Feedback

64
PG046 October 19, 2023
 Chapter 4

Design Flow Steps

This chapter describes customizing and generating the core, constraining the core, and the
simulation, synthesis and implementation steps that are specific to this IP core. More
detailed information about the standard design flows and the AMD Vivado™ IP integrator
can be found in these Vivado Design Suite user guides:

• Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
[Ref 6]
• Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 7]
• Vivado Design Suite User Guide: Getting Started (UG910) [Ref 8]
• Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 9]

Customizing and Generating the Core

This section includes information about using AMD tools to customize and generate the
Aurora 8B/10B core in the Vivado design suite.

When customizing and generating the core in the Vivado IP integrator, see the Vivado
Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) [Ref 6] for
detailed information. IP integrator might auto-compute certain configuration values when
validating or generating the design. To check whether the values change, see the
description of the parameter in this chapter. To view the parameter value, run the
validate_bd_design command in the Tcl Console.

IP can be customized for use in a design by specifying values for the various parameters
associated with the IP core using these steps:

1. Select the IP from the Vivado IP catalog.

2. Double-click the selected IP or select the Customize IP command from the toolbar or
right-click menu.

For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 7] and
the Vivado Design Suite User Guide: Getting Started (UG910) [Ref 8].

Note: Figures in this chapter are illustrations of the Vivado Integrated Design Environment (IDE).
This layout might vary from the current version.

Aurora 8B/10B v11.1 Send Feedback

65
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

The Aurora 8B/10B core can be customized to suit a wide variety of requirements using the
Vivado IP catalog tool. This chapter details the available customization parameters and how
these parameters are specified within the Customize IP interface.

Customize IP
Figure 4-1 shows the Core Options tab of the Customize IP interface with the default
options for Zynq™ 7000 and 7 series devices. The left side displays a representative block
diagram of the Aurora 8B/10B core as currently configured. The right side consists of
user-configurable parameters.

The GT Selections tab is shown in Figure 4-5 for Virtex™ 7 and Kintex™ 7 FPGA GTX and GTH
transceivers.
X-Ref Target - Figure 4-1

Figure 4‐1: Aurora 8B/10B Core Options Tab for Zynq 7000 and 7 Series Devices

Aurora 8B/10B v11.1 Send Feedback

66
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

X-Ref Target - Figure 4-2

Figure 4‐2: Aurora 8B/10B Core Options Tab for UltraScale Devices

Aurora 8B/10B v11.1 Send Feedback

67
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

X-Ref Target - Figure 4-3

Figure 4‐3: Aurora 8B/10B Core Options Tab for UltraScale Devices showing Advanced GT Options

The following four customization options are shown only in the Core Options tab for
UltraScale devices. See UltraScale FPGAs Transceivers Wizard (PG182)[Ref 16] for additional
details on the Advanced GT options selection.

Figure 4-2 and Figure 4-3 shows the Core Options tab for UltraScale™ devices.

Component Name
Enter the top-level name for the core in this text box. Illegal names are highlighted in red
until they are corrected.

Default: aurora_8b10b_0

Lane Width
Select the byte width of the transceivers used in the core.

This parameter defines the TXDATA/RXDATA width of the transceiver and the user interface
data bus width as well. Valid values are 2 and 4.

Default: 2

Aurora 8B/10B v11.1 Send Feedback

68
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Line Rate
Enter a line rate value in gigabits per second within the valid range from 0.5 (Gb/s) to 6.6
(Gb/s).

This value is the unencoded bit rate at which data is transferred over the serial link. The
aggregate data rate of the core is (0.8 x line rate) x Aurora 8B/10B lanes. Line rate is limited
based on the speed grade and package of the selected device (see the respective device
family data sheet for details on the line rate limits).

Default: 3.125 Gb/s

Column Used
Select appropriate GT column from the drop-down list.

Default: Right

Lanes
Select the number of lanes to be used in the core. The valid range depends on the target
device selected.

Default: 1

Starting GT Quad
Select the starting GT Quad of the starting lane from the drop-down list. The core gets
configured with a consecutive number of lanes with the lane selection option selected.

Default: Quad X1Y0

Starting GT Lane
Select the starting lane of the core from the drop-down list. With a starting Quad, lanes and
starting lane, the core gets generated with a consecutive number of lanes.

Default: X1Y0

Note: Channel bonding across SLR boundaries are not supported by the core and restricted from
the Vivado IDE.

GT Refclk Selection
Select reference clock sources for the UltraScale device transceivers from the drop-down
list.

Default: MGTREFCLK0 of Quad X1Y0

Aurora 8B/10B v11.1 Send Feedback

69
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Note: Applicable only for UltraScale devices.

GT REFCLK (MHz)
Select a reference clock frequency for the transceiver from the drop-down list. Reference
clock frequencies depend on the line rate selected. For best results, select the highest rate
that can be practically applied to the reference clock input of the target device.

Default: 125.000 MHz

INIT clk (MHz)

Enter a valid INIT clock frequency into the text box.

Default: 50 MHz for Zynq 7000 and 7 series devices, (line_rate/lane_width) for
UltraScale devices.

DRP clk (MHz)

Enter a valid DRP clock frequency into the text box. INIT clock and DRP clock frequencies are
the same for UltraScale devices.

Default: 50 MHz

Dataflow Mode
Select the options for the direction of the channel that the Aurora 8B/10B core supports.
Simplex Aurora 8B/10B cores have a single, unidirectional serial port that connects to a
complementary simplex Aurora 8B/10B core. Available options are RX-only Simplex,
TX-only Simplex, and Duplex.

Default: Duplex

Generate Aurora without GT

This option is available only for UltraScale and UltraScale+ devices. If this option is selected,
then the Aurora core is generated without the GT, which is available in the example design.

Aurora 8B/10B v11.1 Send Feedback

70
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Interface
Select the type of datapath interface used for the core. Select Framing to use an
AXI4-Stream interface that allows encapsulation of data frames of any length. Select
Streaming to use a simple AXI4-Stream interface to stream data through the Aurora 8B/10B
channel.

Default: Framing

Flow Control
Select the required option to add flow control to the core. User flow control (UFC) allows
applications to send a brief, high-priority message through the Aurora 8B/10B channel.
Native flow control (NFC) allows full duplex receivers to regulate the rate of the data sent to
them. Immediate mode allows idle codes to be inserted within data frames while
completion mode only inserts idle codes between complete data frames.

Available options follow:

• None
• UFC
• Immediate NFC
• Completion NFC
• UFC + Immediate NFC
• UFC + Completion NFC

Default: None

Back Channel
Select the options for Back Channel only for simplex Aurora cores; duplex Aurora cores do
not require this option. The available options are:

• Sidebands
• Timer

Default: Sidebands

Use Scrambler/Descrambler
Select to include the 16-bit additive scrambler/descrambler to the Aurora 8B/10B design.
See Using the Scrambler/Descrambler in Chapter 3 for more information.

Default: Unchecked

Aurora 8B/10B v11.1 Send Feedback

71
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Little Endian Support

Select to change all of the interface(s) to little endian format. See Using Little Endian
Support in Chapter 3 for more information. By default, the core uses big endian format.

Default: Unchecked

Additional Transceiver Control and Status Ports

Select to include transceiver control and status ports in core top level.

Default: Unchecked

Vivado Lab Tools

Select to add Vivado lab tools to the Aurora 8B/10B core. This option provides a debugging
interface that shows the core status signals in the Vivado Logic Analyzer.

Default: Unchecked

Use CRC
Select to include the CRC for user data. Depending on the Lane Width of 2 or 4, the core
implements CRC16 or CRC32 respectively. See Using CRC in Chapter 3 for more information.

Default: Unchecked

C_DOUBLE_GTRXRESET
This parameter can be set to 1 using the TCL console while customizing the IP. Enable this
parameter to assert an additional reset in case of frequent buffer overflow/underflow as a
result of very high ppm differences. During IP hardware debug, you may also set this
parameter if RX electrical idle exit condition is seen after the gt_reset_i is deasserted.

Default: 0 (not present on GUI)

Aurora 8B/10B v11.1 Send Feedback

72
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Shared Logic
Figure 4-4 shows the Shared Logic tab of the Customize IP interface.
X-Ref Target - Figure 4-4

Figure 4‐4: Aurora 8B/10B Shared Logic Tab

Select the option to include the transceiver common PLL and its logic either in the IP core
or in the example design.

Available options:

• include Shared Logic in core

• include Shared Logic in example design

Default: include shared logic in example design

Aurora 8B/10B v11.1 Send Feedback

73
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Figure 4-5 shows the GT Selections tab of the Customize IP interface.

X-Ref Target - Figure 4-5

Figure 4‐5: Aurora 8B/10B GT Selections Tab

Column/Row Used
This option will be visible only for the device which has more than one column/row.

Select the appropriate column/row of transceivers used from the drop-down list. The
column used is enabled only for Virtex 7 and Kintex 7 devices and the row used is enabled
only for Artix™ 7 devices.

Default: left/top

Lanes
Select the number of lanes (transceivers) to be used in the core. The valid range is from 1 to
16 and depends on the target device selected.

Default: 1

Aurora 8B/10B v11.1 Send Feedback

74
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Lane Assignment
See the diagram in the information area in Figure 4-5. Two rows or four boxes represent a
quad. Each active box represents an available transceiver. A tooltip is provided to specify
which transceiver (for example, GTXE2_CHANNEL_X0Y0) is being implemented in hardware.

The Aurora 8B/10B core generates transceiver placement (LOC) constraints in ascending
fashion. Lane numbering serves only to enable the lanes and not to assign lane numbers.

RECOMMENDED: Always select consecutive/physically adjacent lanes for a multi-GT design.

GT Refclk1 and GT RefclK2

Select reference clock sources for the GTP, GTX, or GTH Quad from the drop-down list in this
section.

Default: GT REFCLK Source 1: GTPQn/GTXQn/GTHQn; GT REFCLK Source 2: None

Note: The value of n depends upon the serial transceiver (GTX or GTH) position.

Core Generation
Click OK to generate the core. The modules for the Aurora 8B/10B core are written to the
Vivado design tools project directory using the same name as the top level of the core. See
Output Generation, page 78 for details about the example_design directory and files.

Notes:

1. In the IP integrator the Aurora 8B/10B core sets the expected frequency values in long
format as per the IP integrator guidelines; however, internally the core precision is the
same as shown in Vivado IDE.
2. Data and flow control ports are grouped into AXI4-Stream interfaces. The other input
and output ports are grouped into display interfaces.
3. For the ports grouped in display interfaces the connections should be made manually.

Aurora 8B/10B v11.1 Send Feedback

75
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

User Parameters
Table 4-1 shows the relationship between the fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl Console).

Table 4‐1: Vivado IDE Parameter to User Parameter Relationship

Vivado IDE Parameter/Value(1) User Parameter/Value(1) Default Value
Core Options
Physical Layer
Lane Width (Bytes) C_LANE_WIDTH 2
Line Rate (Gb/s) C_LINE_RATE 3.125
Column Used C_UCOLUMN_USED right
Starting GT Quad C_START_QUAD Quad X0Y0
Starting GT Lane C_START_Lane X0Y0
MGTREFCLK0 of
GT Refclk Selection C_REFCLK_SOURCE
Quad X0Y0
GT Refclk (MHz) C_REFCLK_FREQUENCY 125.000
INIT clk (MHz) C_INIT_CLK 50.000
DRP clk (MHz)(4) DRP_FREQ 50.000
Aurora without GT(5) C_GTWIZ_OUT false
Link Layer
Dataflow Mode Dataflow_Config Duplex
Interface Interface_Mode Framing
Flow Control Flow_Mode None
Back Channel Backchannel_mode Sidebands
Scrambler/Descrambler C_USE_SCRAMBLER false
Little Endian Support C_USE_BYTESWAP false
Error Detection
CRC C_USE_CRC false
Debug and Control
Vivado Lab Tools C_USE_CHIPSCOPE false
Additional transceiver control and
TransceiverControl false
status ports
GT Selections
Lanes C_AURORA_LANES 1
Lane Assignment(2)(4)
Select transceiver to include
C_GT_LOC_1 1
GTXE2_CHANNEL_X0Y0 in your design
Select transceiver to include
C_GT_LOC_2 X
GTXE2_CHANNEL_X0Y1 in your design

Aurora 8B/10B v11.1 Send Feedback

76
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Table 4‐1: Vivado IDE Parameter to User Parameter Relationship (Cont’d)

Vivado IDE Parameter/Value(1) User Parameter/Value(1) Default Value
Select transceiver to include
C_GT_LOC_3 X
GTXE2_CHANNEL_X0Y2 in your design

Select transceiver to include

C_GT_LOC_4 X
GTXE2_CHANNEL_X0Y3 in your design

Select transceiver to include

C_GT_LOC_5 X
GTXE2_CHANNEL_X0Y4 in your design
Select transceiver to include
C_GT_LOC_6 X
GTXE2_CHANNEL_X0Y5 in your design
Select transceiver to include
C_GT_LOC_7 X
GTXE2_CHANNEL_X0Y5 in your design

Select transceiver to include

C_GT_LOC_8 X
GTXE2_CHANNEL_X0Y7 in your design
Select transceiver to include
C_GT_LOC_9 X
GTXE2_CHANNEL_X0Y8 in your design
Select transceiver to include
C_GT_LOC_10 X
GTXE2_CHANNEL_X0Y9 in your design
Select transceiver to include
C_GT_LOC_11 X
GTXE2_CHANNEL_X0Y10 in your design
Select transceiver to include
C_GT_LOC_12 X
GTXE2_CHANNEL_X0Y11 in your design
Select transceiver to include
C_GT_LOC_13 X
GTXE2_CHANNEL_X0Y12 in your design
Select transceiver to include
C_GT_LOC_14 X
GTXE2_CHANNEL_X0Y13 in your design
Select transceiver to include
C_GT_LOC_15 X
GTXE2_CHANNEL_X0Y14 in your design
Select transceiver to include
C_GT_LOC_16 X
GTXE2_CHANNEL_X0Y15 in your design
GT Refclk (MHz)
GT Refclk1 (4) C_GT_CLOCK_1 GTXQ0
GT Refclk2 (4) C_GT_CLOCK_2 None

Aurora 8B/10B v11.1 Send Feedback

77
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Table 4‐1: Vivado IDE Parameter to User Parameter Relationship (Cont’d)

Vivado IDE Parameter/Value(1) User Parameter/Value(1) Default Value
Shared Logic
Include Shared Logic in core(3) 1
Include Shared Logic in example design SupportLevel 0
(Default Mode)
Single Ended INIT CLK SINGLEEND_INITCLK false
Single Ended GTREF CLK SINGLEEND_GTREFCLK false
Starting GT Quad C_START_QUAD Quad_X1Y0
Starting GT Lane C_START_LANE X1Y0
GT Refclk Selection C_REFCLK_SOURCE MGTREFCLK1 of Quad X1Y0
Notes:
1. Parameter values are listed in the table where the Vivado IDE parameter value differs from the user parameter
value. Such values are shown in this table as indented below the associated parameter.
2. X0Y0 GT selection is based on column.
3. If Shared Logic in core option is selected, SupportLevel is 1.
4. Not available with UltraScale devices.
5. Generate Aurora without GT option is available only for UltraScale and UltraScale+ devices in IP catalog.

Output Generation
The customized Aurora 8B/10B core is delivered as a set of HDL source modules in the
language selected. These files are arranged in a predetermined directory structure under
the project directory name provided to the IP catalog when the project is created.

If the VHDL language is selected for UltraScale devices, the IP top-level wrapper file is VHDL
and the underlying design source files are Verilog.

For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 7].

Constraining the Core

This section provides information for constraining the Aurora 8B/10B core in the Vivado
design suite.

Required Constraints
This section is not applicable for this IP core.

Device, Package, and Speed Grade Selections

This section is not applicable for this IP core.

Aurora 8B/10B v11.1 Send Feedback

78
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

Clock Frequencies
The Aurora 8B/10B core example design clock constraints can be grouped into following
three categories:

• GT reference clock constraint

The Aurora 8B/10B core example design uses a minimum of one and a maximum of two
reference clocks. The number of GT reference clocks is dependent upon the transceiver
selection. The GT REFCLK value selected on the first page of the Vivado IDE is used to
constrain the GT reference clock using the create_clock XDC command.

Note: For UltraScale devices, the GT reference clock location constraint should be added to
<user_component_name>_example.xdc .

• TXOUTCLK clock constraint

TXOUTCLK is generated by the transceiver based on the input reference clock and the
divider settings of the transceiver. The create_clock XDC command is used to
constrain TXOUTCLK.

• INIT CLK constraint

The Aurora 8B/10B core example design uses a debounce circuit to sample GT_RESET
which is clocked asynchronously by the system clock. The create_clock XDC
command is used to constrain the system clock.

RECOMMENDED: Use a system clock frequency lower than the GT reference clock frequency.

Clock Management
Not Applicable

Clock Placement
Not Applicable

Banking
Not Applicable

Transceiver Placement
The set_property XDC command is used to constrain the transceiver location. This is
provided as a tooltip on the second page of the Vivado IDE. A sample XDC is provided for
reference.

Aurora 8B/10B v11.1 Send Feedback

79
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

I/O Standard and Placement

The positive differential clock input pin (ends with _P) and negative differential clock input
pin (ends with _N) are used as the GT reference clock. The set_property XDC command
is used to constrain the location of the GT reference clock pins.

False Paths
The set_false_path XDC command is used to constrain the false paths (signal crossing
clock domain).

Example Design XDC

The generated Verilog example design is configured with a two-byte lane width, 3.125 Gb/s
line rate, and a 125.0 MHz reference clock. The XDC file generated for the
XC7VX690T-FFG1761-2 device follows:

################################################################################
## XDC generated for xc7vx690t-ffg1761-2 device
# 125.0MHz GT Reference clock constraint
create_clock -name GT_REFCLK1 -period 8.0 [get_ports GTHQ1_P]
####################### GT reference clock LOC #######################
set_property LOC AW9 [get_ports GTHQ1_N]
set_property LOC AW10 [get_ports GTHQ1_P]

# USER_CLK Constraint: Value is selected based on the line rate (3.125 Gb/s) and lane width (2-Byte)
# create_clock -name user_clk_i -period 6.400 [get_pins aurora_module_i/clock_module_i/user_clk_buf_
i/I]

# 20.0 ns period Board Clock Constraint

create_clock -name init_clk_i -period 20.0 [get_ports INIT_CLK_P]

# 20.000 ns period DRP Clock Constraint

create_clock -name drp_clk_i -period 20.000 [get_ports DRP_CLK_IN]

###### CDC in RESET_LOGIC from INIT_CLK to USER_CLK ##############

set_false_path -through [get_pins -hier *cdc_to*]

##################### Location constraint #########################

##Note: User should add LOC based upon the board
# Below LOCs are place holders and need to be changed as per the device and board
#set_property LOC D17 [get_ports INIT_CLK_P]
#set_property LOC D18 [get_ports INIT_CLK_N]
#set_property LOC G19 [get_ports RESET]
#set_property LOC K18 [get_ports GT_RESET_IN]
#set_property LOC A20 [get_ports CHANNEL_UP]
#set_property LOC A17 [get_ports LANE_UP]
#set_property LOC Y15 [get_ports HARD_ERR]
#set_property LOC AH10 [get_ports SOFT_ERR]
#set_property LOC AD16 [get_ports ERR_COUNT[0]]
#set_property LOC Y19 [get_ports ERR_COUNT[1]]
#set_property LOC Y18 [get_ports ERR_COUNT[2]]
#set_property LOC AA18 [get_ports ERR_COUNT[3]]
#set_property LOC AB18 [get_ports ERR_COUNT[4]]
#set_property LOC AB19 [get_ports ERR_COUNT[5]]

Aurora 8B/10B v11.1 Send Feedback

80
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

#set_property LOC AC19 [get_ports ERR_COUNT[6]]

#set_property LOC AB17 [get_ports ERR_COUNT[7]]
#set_property LOC AC17 [get_ports FRAME_ERR]

#set_property LOC AG29 [get_ports DRP_CLK_IN]

#// DRP CLK needs a clock LOC

##Note: User should add IOSTANDARD based upon the board

# Below IOSTANDARDs are place holders and need to be changed as per the device and board
#set_property IOSTANDARD DIFF_HSTL_II_18 [get_ports INIT_CLK_P]
#set_property IOSTANDARD DIFF_HSTL_II_18 [get_ports INIT_CLK_N]
#set_property IOSTANDARD LVCMOS18 [get_ports RESET]
#set_property IOSTANDARD LVCMOS18 [get_ports GT_RESET_IN]

#set_property IOSTANDARD LVCMOS18 [get_ports CHANNEL_UP]

#set_property IOSTANDARD LVCMOS18 [get_ports LANE_UP]
#set_property IOSTANDARD LVCMOS18 [get_ports HARD_ERR]
#set_property IOSTANDARD LVCMOS18 [get_ports SOFT_ERR]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[0]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[1]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[2]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[3]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[4]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[5]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[6]]
#set_property IOSTANDARD LVCMOS18 [get_ports ERR_COUNT[7]]
#set_property IOSTANDARD LVCMOS18 [get_ports FRAME_ERR]

#set_property IOSTANDARD LVCMOS18 [get_ports DRP_CLK_IN]

#// DRP CLK needs a clock IOSTDLOC

##################################################################

############################### GT LOC ###################################

set_property LOC GTHE2_CHANNEL_X1Y4 [get_cells
aurora_module_i/aurora_8b10b_0_i/inst/gt_wrapper_i/aurora_8b10b_0_multi_gt_i/gt0_aurora_8b10b_0_i/
gthe2_i]

The preceding XDC is provided for reference. The example design XDC is created
automatically when the core is generated from the Vivado design tools.

Simulation
This section contains information about simulating IP in the Vivado design suite. For
comprehensive information about Vivado design suite simulation components, as well as
information about using supported third-party tools, see the Vivado Design Suite User
Guide: Logic Simulation (UG900) [Ref 9].

IMPORTANT: For cores targeting UltraScale, 7 series or Zynq 7000 devices, UNIFAST libraries are not
supported. AMD IP is tested and qualified with UNISIM libraries only.

Aurora 8B/10B v11.1 Send Feedback

81
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

The Aurora 8B/10B core delivers a demonstration test bench for the example design. The
TEST COMPLETED SUCCESSFULLY message signifies the completion of the example design
simulation.

Note: The Reached max. simulation time limit message means that simulation was
not successful. See Appendix C, Debugging for more information.

Simulating the duplex core is a single-step process after generating an example design.
Simplex core simulation requires partner generation. The partner core is generated
automatically and the synthesized netlist is available under the simulation file set when
clicking Open IP Example Design. Due to the synthesizing of the partner core, opening a
simplex core example design takes more time than the duplex example design generation.

Note: Simulation requires that the Labtools option to be unchecked.

Simulation speed up
The C_EXAMPLE_SIMULATION parameter is introduced to speed up post
synthesis/implementation netlist functional simulations:

1. If you are using the tcl script to generate an IP Core, add the Parameter
c_example_simulation to set to true as part of the tcl script.
Note: This mode of IP core generation is only for Simulation purposes. If you intend to test on
board, the above command should not be added as part of the IP core generation.
2. If you do not want to set tcl commands during IP core generation and instead edit the
code to see the simulation speed up, then change the EXAMPLE_SIMULATION
parameter in the generated RTL code to 1 in the following file to speed up functional
simulations:

<USER_COMPONENT_NAME>_core.v[hd]

For more information, see the Vivado Design Suite User Guide: Designing with IP (UG896)
[Ref 7].

Synthesis and Implementation

This section contains information about synthesis and implementation in the Vivado design
suite. For more details about synthesis and implementation, see the Vivado Design Suite
User Guide: Designing with IP (UG896) [Ref 7].

Implementation Overview
The quick start example consists of the following components:

• An instance of the Aurora 8B/10B core generated using the default parameters

Aurora 8B/10B v11.1 Send Feedback

82
PG046 October 19, 2023
 Chapter 4: Design Flow Steps

° Full-duplex with a single transceiver

° AXI4-Stream interface
• A demonstration test bench to simulate two instances of the example design

The Aurora 8B/10B example design has been tested with the Vivado design suite for
synthesis and Mentor Graphics Questa Advanced Simulator for simulation.

Implementing the Example Design

To generate the example design, follow these steps:

1. Right-click the generated IP and select Open Example Design.

2. Click Run Implementation.
3. When the implementation process completes, click Generate Bitstream to create a
bitstream for the selected target device.
Note: The LOC and IO standards must be specified in the XDC file for all input and output ports of
the design.

Generating the Core

To generate an Aurora 8B/10B core with default values using the Vivado design tools, see
Designing a System Using the Aurora 8B10B Core (Duplex) on the KC705 Evaluation Kit
(XAPP1193) [Ref 10].

Aurora 8B/10B v11.1 Send Feedback

83
PG046 October 19, 2023
 Chapter 5

Detailed Example Design

This chapter contains information about the example design provided in the AMD Vivado™
Design Suite.

Example Design
Each Aurora 8B/10B core includes an example design (<component name>_exdes) that
uses the core in a simple data transfer system.

The example design consists these components:

• Frame generator (FRAME_GEN) connected to the TX interface

• Frame checker (FRAME_CHECK) connected to the RX user interface
• VIO/ILA instance for debug and testing

Figure 5-1 illustrates the block diagram of the example design for a full-duplex core.
X-Ref Target - Figure 5-1

Aurora Example Design

FRAME_GEN TX
Aurora
8B/10B
FRAME_CHECK RX

Demonstration
Test Bench
(<component name>_TB)

Aurora Example Design

FRAME_GEN TX
Aurora
8B/10B
FRAME_CHECK RX

X12997

Figure 5‐1: Example Design

Aurora 8B/10B v11.1 Send Feedback

84
PG046 October 19, 2023
 Chapter 5: Detailed Example Design

The example design uses all of the core interfaces. Simplex cores without a TX or RX
interface have no FRAME_GEN or FRAME_CHECK block, respectively.

The FRAME_GEN module generates user traffic to each of the PDU, UFC and NFC interfaces
following the AXI4-Stream protocol. This module contains a pseudo-random number
generator using a linear feedback shift register (LFSR) with a specific initial value to
generate a predictable sequence of data. The FRAME_CHECK module uses this data
sequence to verify the integrity of the Aurora data channel. Module inputs are user_clk,
reset and channel_up.

The FRAME_CHECK module verifies the integrity of the RX data. This module uses the same
LFSR and initial value as the FRAME_GEN module to generate the expected RX frame data.
The received user data is compared with the locally-generated stream and any errors are
reported per the AXI4-Stream protocol. The FRAME_CHECK module is applicable to PDU,
UFC and NFC interfaces.

The example design can be used to quickly get an Aurora 8B/10B design up and running on
a board, or perform a quick simulation of the module. The design can also be used as a
reference for the connecting the more complicated interfaces of the Aurora 8B/10B core,
such as the clocking interface.

When using the example design on a board, be sure to edit the <component name>_
exdes.xdc file to supply the correct pins and clock constraints.

Table 5-1 describes the ports of the example design.

Table 5‐1: Example Design I/O Ports

Clock
Port Direction Domain Description

RX Serial
rxn[0:m–1] Input Negative differential serial data input pin.
Clock
RX Serial
rxp[0:m–1] Input Positive differential serial data input pin.
Clock
TX Serial
txn[0:m–1] Output Negative differential serial data output pin.
Clock
TX Serial
txp[0:m–1] Output Positive differential serial data output pin.
Clock
Count of the number of data words received
err_count[0:7] Output user_clk by the frame checker that did not match the
expected value.
Reset signal for the example design. The
reset Input user_clk reset is debounced using a user_clk signal
generated from the reference clock input.
GT Reset signal for the example design.
gt_reset Input init_clk_in gt_reset is debounced using the init_clk_in
signal.

Aurora 8B/10B v11.1 Send Feedback

85
PG046 October 19, 2023
 Chapter 5: Detailed Example Design

Table 5‐1: Example Design I/O Ports (Cont’d)

Port Direction Clock Description

Domain
The reference clocks for the Aurora 8B/10B
core are brought to the top level of the
<reference clock(s)> Input - example design. See Serial Transceiver
Reference Clock Interface, page 53 for
details about the reference clocks.
The error signals from the Aurora 8B/10B
core Status and Control interface are
<core error signals> (1) Output user_clk
brought to the top level of the example
design and registered.
The channel up status signals for the core are
brought to the top level of the example
design and registered. Full-duplex cores
<core channel up signals> (1) Output user_clk
have a single channel up signal; simplex
cores have one for each channel direction
supported.
The lane up status signals for the core are
brought to the top level of the example
design and registered. Cores have a lane up
<core lane up signals> (1) Output user_clk signal for each GTP or GTX transceiver they
use. Simplex cores have a separate lane up
signal per GTP or GTX transceiver they use
for each channel direction supported.
If the core is a simplex core, its sideband
Input/ initialization ports are registered and
<simplex initialization signals> (1) user_clk
Output brought to the top level of the example
design.

Notes:
1. See Status, Control, and the Transceiver Interface, page 33 for details.

Using the Vivado Design Suite Debug Feature

The Integrated Logic Analyzer (ILA) and Virtual Input Output (VIO) cores in the Vivado lab
tools feature help to debug and validate the design in boards. These cores are provided
with the Aurora 8B/10B core. Select the Vivado Lab Tools check box on the Core Options
tab of the Customize IP interface in the Vivado Integrated Design Environment (IDE) to
include the ILA and VIO cores in the example design. Alternatively, the USE_CHIPSCOPE
parameter in the <component name>_exdes module can be set to 1 before running
implementation.

See the Vivado Design Suite User Guide: Programming and Debugging (UG908) [Ref 11].

Aurora 8B/10B v11.1 Send Feedback

86
PG046 October 19, 2023
 Chapter 6

Test Bench
The Aurora 8B/10B core delivers a demonstration test bench for the example design. This
chapter describes the Aurora test bench and its functionality. The test bench consist of the
following modules:

• Device Under Test (DUT)

• Clock and reset generator
• Status monitor

The Aurora test bench components can change based on the selected Aurora 8B/10B core
configurations, but the basic functionality remains the same for all of the core
configurations.
X-Ref Target - Figure 6-1

Aurora Test Bench

Clock and Reset

Generator

High Speed
AXI4-Stream Interface AXI4-Stream Interface
Serial Interface

FRAME_GEN TXP/TXN RXP/RXN FRAME_CHECK

Duplex Duplex
Aurora Aurora
Core Core
FRAME_CHECK RXP/RXN TXP/TXN FRAME_GEN

DUT1 (Aurora Exdes) DUT2 (Aurora Exdes)

Status Monitor

X13546

Figure 6‐1: Aurora Test Bench for Duplex Configuration

Aurora 8B/10B v11.1 Send Feedback

87
PG046 October 19, 2023
 Chapter 6: Test Bench

The Aurora test bench environment connects the Aurora duplex core in loopback using a
high-speed serial interface. Figure 6-1 shows the Aurora test bench for the duplex
configuration.

The test bench first verifies the channel state, then monitors the integrity of the user and
UFC data for a predetermined simulation time. The channel_up assertion message
indicates successful link training and channel bonding (in the case of multi-lane designs). A
counter is maintained in the FRAME_CHECK module to track the reception of any erroneous
data. The test bench flags an error when erroneous data is received.
X-Ref Target - Figure 6-2

Aurora Test Bench

Clock and Reset

Generator

High Speed
AXI4-Stream Interface AXI4-Stream Interface
Serial Interface

Simplex Partner
Aurora Core Simplex
Aurora Core
FRAME_GEN FRAME_CHECK
TXP/TXN RXP/RXN

RX_AURORA_IP_TX
AURORA_IP_TX (Aurora Exdes) (Partner Aurora Exdes)

Status Monitor

X13545

Figure 6‐2: Aurora Test Bench for Simplex Configuration

The Aurora test bench environment connects the Aurora simplex core to the partner
simplex Aurora core using the high-speed serial interface. Figure 6-2 shows the Aurora test
bench for the simplex configuration where DUT1 is configured as TX-only simplex and
DUT2 is configured as RX-only simplex.

The test bench first verifies the state of the transmitter and receiver channels, then
monitors the integrity of the user data for a predetermined simulation time. The
tx_channel_up and rx_channel_up assertion messages indicate successful link
training and channel bonding (in case of multi-lane designs).

Aurora 8B/10B v11.1 Send Feedback

88
PG046 October 19, 2023
 Appendix A

Verification, Compliance, and

Interoperability
This appendix provides details about how this IP core was tested for compliance.

Aurora 8B/10B cores are verified for protocol compliance using an array of automated
hardware and simulation tests. The core comes with an example design implemented using
a linear feedback shift register (LFSR) for understanding/verification of the core features.

Aurora 8B/10B cores are tested in hardware for functionality, performance, and reliability
using AMD evaluation platforms. Aurora verification test suites for all possible modules are
continuously being updated to increase test coverage across the range of possible
parameters for each individual module.

A series of Aurora 8B/10B core test scenarios are validated using the various AMD
development boards listed in Table A-1. These boards permit the prototyping of system
designs where the Aurora 8B/10B core allows high-speed serial communication between
two boards. The testing of Aurora example design for various configurations are performed
either by board-to-board testing using standard Bulls Eye connectors or SMA connectors.
External cable loopback tests are performed as part of reset stress testing. The test
sequence uses AMD Vivado™ Lab Tools and follows the sequence and tests represented in
the example design simulation. AMD recommends the use of an Aurora IP with link partners
of the same version.

Note: There is no particular requirement with respect to the sequence of resets applied on the
boards. The system functions as designed, irrespective of which board is reset first. For reset
sequencing of Simplex use cases, see, Reset and Power Down.
Note: Interoperability is not tested beyond one generation. It is advised to be cautious on Reset and
Power Sequencing when not using compatible GTs.

Table A‐1: AMD Development Boards

Target
Evaluation Boards Characterization Boards
Family
7 series KC705, VC707, VC709, ZC706, AC701 KC724, VC2703, VC7215, ZC723, ZC720
UltraScale™
KCU105, VCU108, VCU110, KCU114 UC1250, UC1283, UC1287
architecture

Aurora 8B/10B v11.1 Send Feedback

89
PG046 October 19, 2023
 Appendix B

Upgrading
This appendix contains information about migrating a design to a different device and for
upgrading to a more recent version of the IP core. For customers upgrading in the AMD
Vivado™ design suite, important details (where applicable) about any port changes and
other impact to user logic are included.

Device Migration
When migrating from a 7 series GTX or GTH transceiver device to an UltraScale™
architecture GTH transceiver, the prefixes of the optional transceiver debug ports for
single-lane cores are changed from “gt0”, “gt1” to “gt”, and the postfix “_in” and “_out” are
dropped. For multi-lane cores, the prefixes of the optional transceiver debug ports, gt(n),
are aggregated into a single port. For example: gt0_gtrxreset and gt1_gtrxreset
now become gt_gtrxreset[1:0]. This rule applies for all ports, with the exception of
the DRP buses which follow the convention of gt(n)_drpxyz.

IMPORTANT: Update your design to use the new transceiver debug port names. For more information
about migration to UltraScale architecture devices, see the UltraScale Architecture Migration
Methodology Guide (UG1026) [Ref 12].

IMPORTANT: When upgrading across different Devices, you need to double check the GT locations and
corresponding customization parameters for a new target device.

Aurora 8B/10B v11.1 Send Feedback

90
PG046 October 19, 2023
 Appendix B: Upgrading

Upgrading in the Vivado Design Suite

In the latest revision of the core, there have been several changes to ensure
pin-incompatibility with the previous core versions. These changes were required as part of
the general one-off hierarchical changes to enhance the customer experience and are not
likely to occur again.

As part of the hierarchical changes to the core, it is now possible to have the core itself
include all of the logic which can be shared between multiple cores, which was previously
exposed in the example design for the core.

RECOMMENDED: When updating from a previous version to a recent version with shared logic, there is
no simple upgrade path and AMD recommends that you consult the Shared Logic sections of this
document for more guidance.

Migrating Local Link-based Aurora Cores to the

AXI4-Stream Aurora Core
Introduction
This section describes migrating legacy Aurora cores based on LocalLink (LL) to the
AXI4-Stream Aurora core.

Prerequisites
• Vivado design tools build containing the Aurora 8B/10B core supporting the
AXI4-Stream protocol
• Familiarity with the Aurora directory structure
• Familiarity with running the Aurora example design
• Basic knowledge of the AXI4-Stream and LocalLink protocols
• Latest product guide (PG046) of the core with the AXI4-Stream updates
• Legacy LogiCORE IP Aurora 8B/10B Data Sheet (DS637) [Ref 13] and LogiCORE IP Aurora
8B/10B User Guide (UG353) [Ref 14] for reference.
• Migration guide (this appendix)

Aurora 8B/10B v11.1 Send Feedback

91
PG046 October 19, 2023
 Appendix B: Upgrading

Limitations
This section outlines the limitations of the Aurora 8B/10B core for AXI4-Stream support. It
is essential to observe two limitations while interfacing the Aurora 8B/10B core with the
AXI4-Stream compliant interface core:

• The Aurora 8B/10B core supports only continuous aligned streams and continuous
unaligned streams. The position bytes are valid only at the end of packet. In other
words, tkeep is sampled only at tlast assertion.
• The AXI4-Stream protocol supports transfers with zero data at the end of the packet,
but the Aurora 8B/10B core expects at least one byte to be valid at the end of the
packet. In other words, tkeep should contain a non-zero value during tlast
assertion.

Overview of Major Changes since version 11.0

The major change to the core is the addition of the AXI4-Stream interface:

• Flow control interface ports mapped to the standard AXI4-Stream interface.

• Single-ended clock option added to core init_clk and gt_refclk.
• GT selection option for the UltraScale device added to the core.
• All reset inputs made asynchronous.
• Standard CC module made part of IP; do_cc and warn_cc ports removed.
• Single-ended clocking option added to the core when shared logic is in the core.
• All core input and output ports grouped as interfaces.
• Line rate value restricted to 4 decimal digits for UltraScale devices.
• INIT clock frequency value restricted to 6 decimal digits.

Aurora 8B/10B v11.1 Send Feedback

92
PG046 October 19, 2023
 Appendix B: Upgrading

Block Diagram
Figure B-1 shows an example Aurora design using the legacy LocalLink interface. Figure B-2
shows an example Aurora design using the AXI4-Stream interface.
X-Ref Target - Figure B-1

LocalLink
FRAME GEN

LocalLink
AURORA DESIGN

LocalLink
FRAME CHECK

X13194

Figure B‐1: Legacy Aurora Example Design

X-Ref Target - Figure B-2

AXI4-Stream Aurora Design Top

LL to AXI4_S

Existing LL based AXI4-Stream

Design Aurora Design
AXI4_S to LL

X13193

Figure B‐2: AXI4-Stream Aurora Example Design

Aurora 8B/10B v11.1 Send Feedback

93
PG046 October 19, 2023
 Appendix B: Upgrading

Migration Steps
Begin by generating an AXI4-Stream Aurora 8B/10B core from the Vivado Design Suite.

Simulate the Core

1. Click Run Simulation in the Vivado Integrated Design Environment (IDE) and select the
type of simulation.
2. QuestaSim launches and compiles the modules.
3. The wave_mti.do file loads automatically and populates the AXI4-Stream signals.
4. Allow the simulation to run. This might take some time.
a. Initially lane up is asserted.
b. Channel up is then asserted and the data transfer begins.
c. Data transfer from all flow control interfaces now begins.
d. The frame checker continuously checks the received data and reports any data
mismatch.
5. A TEST PASS or TEST FAIL status is printed on the QuestaSim console providing the
status of the test.

Implement the Core

1. Click Run Implementation in the Vivado IDE to run synthesis and implementation.

Integrate to an Existing LocalLink-based Aurora 8B/10B Design

1. The Aurora 8B/10B core provides a light-weight shim to interface to any existing LL
based interface. The shims are delivered along with the core.
2. See Figure B-2, page 93 for the emulation of an LL Aurora core from an AXI4-Stream
Aurora core.
3. Two shims <component name>_ll_to_axi.v[hd] and <component name>_
axi_to_ll.v[hd] are provided in the src directory of the AXI4-Stream Aurora core.
4. Instantiate both the shims along with <component name>.v[hd] in the existing LL
based design top.
5. Connect the shim and AXI4-Stream Aurora design as shown in Figure B-2, page 93.
6. The latest AXI4-Stream Aurora core can now be used with any existing LL design.

Aurora 8B/10B v11.1 Send Feedback

94
PG046 October 19, 2023
 Appendix B: Upgrading

Vivado IDE Changes

Figure B-3 shows the AXI4-Stream signals in the IP Symbol diagram.
X-Ref Target - Figure B-3

Figure B‐3: AXI4-Stream Signals

Aurora 8B/10B v11.1 Send Feedback

95
PG046 October 19, 2023
 Appendix C

Debugging
This appendix provides information on using resources available on the AMD Support
website, available debug tools, and a step-by-step process for debugging designs that use
the Aurora 8B/10B core. This appendix uses a flow diagram as a guide to the debug process.

Finding Help with AMD Adaptive Computing

Solutions
To help in the design and debug process when using the Aurora 8B/10B core, the Support
web page contains key resources such as product documentation, release notes, answer
records, information about known issues, and links for obtaining further product support.
The Community Forums are also available where members can learn, participate, share, and
ask questions about AMD Adaptive Computing Solutions

Documentation
This product guide is the main document associated with the Aurora 8B/10B core. This
guide, along with documentation related to all products that aid in the design process, can
be found on the Support web page or by using the AMD Adaptive Computing
Documentation Navigator.

Download the Documentation Navigator from the Downloads page. For more information
about this tool and the features available, open the online help after installation.

Solution Centers
See the Aurora Solutions Center for support specific to the Aurora 8B/10B core.

Answer Records
Answer Records include information on commonly encountered problems, helpful
information on how to resolve these problems, and any known issues with an AMD Adaptive
Computing product. Answer Records are created and maintained daily to ensure that users
have access to the most accurate information available.

Aurora 8B/10B v11.1 Send Feedback

96
PG046 October 19, 2023
 Appendix C: Debugging

Answer Records for this core can be located by using the Search Support box on the main
Support web page. To maximize your search results, use proper keywords such as:

• Product name
• Tool message(s)
• Summary of the issue encountered

A filter search is available after results are returned to further target the results.

To use the Answers Database Search:

1. Enter keywords in the provided search field and select Search.

° Examples of searchable keywords are product names, error messages, or a generic

summary of the issue encountered.

° To see all answer records directly related to the Aurora 8B/10B core, search for the
phrase "Aurora 8B10B"

Master Answer Record for the Aurora 8B/10B Core AR: 54367

Technical Support
AMD provides technical support on the Community Forums for this LogiCORE™ IP product
when used as described in the product documentation. AMD Adaptive Computing cannot
guarantee timing, functionality, or support of the product if you do the following:

• Implement the solution in devices that are not defined in the documentation.
• Customize the solution beyond that allowed in the product documentation.
• Change any section of the design labeled DO NOT MODIFY.

To ask questions, navigate to the Community Forums.

To ask questions, navigate to the Community Forums. Also, see GT_Debug_Flowchart for
transceiver debugging mentioned in the following Answer Record.

AR: 57237

Aurora 8B/10B v11.1 Send Feedback

97
PG046 October 19, 2023
 Appendix C: Debugging

Debug Tools
There are many tools available to address Aurora 8B/10B core design issues. It is important
to know which tools are useful for debugging various situations.

Note: The init_clk_in clock input is provided as a stable and free running clock to drive the
Debug cores and the stability of this clock source is key to ensure debugging is proper. Ensure that
only after this clock is stable the pma_init input of the IP is deasserted. The init_clk_in must
always be stable.

Transceiver Wizard
Serial transceiver attributes play a vital role in Aurora 8B/10B core functionality and
performance. See Appendix D, Generating a Wrapper File from the Transceiver Wizard to
get the latest attribute updates for the core.

Simulation Debug
Lanes and Channel do not come up in simulation
• The most effective method of debugging this condition is to view the signals from one
instance of the serial transceivers that is not working.
• Make sure that the serial transceiver reference clock and user clocks are all toggling.
• Check to see that txoutclk from the serial transceiver wrapper is toggling. If not, it
might take longer for the PMA to finish locking. Wait for lane up and channel up. It
might take even longer for simplex designs.
• Make sure that txn and txp are toggling. If not, make sure to wait long enough and
ensure that the TX signal is not being driven by another signal.
• Check the pll_not_locked signal in the design. If it is held active-High, the Aurora
module is unable to initialize.
• Be sure the power_down signal is not asserted.
• If you assert rx_reset while using Timer mode and simplex configuration, you
should also assert tx_reset to ensure that the core transmits the required
initialization patterns for the rx_lane_up and rx_channel_up to come up.
• If you are using Verilog simulation, instantiate the glbl module and use it to drive the
power_up reset at the beginning of the simulation. This procedure simulates the reset
that occurs after configuration. Hold this reset for a few cycles.

The following code can be used an example:

//Simulate the global reset that occurs after configuration at

//the beginning
//of the simulation.
Aurora 8B/10B v11.1 Send Feedback
98
PG046 October 19, 2023
 Appendix C: Debugging

assign glbl.GSR = gsr_r;

assign glbl.GTS = gts_r;

initial
begin
gts_r = 1'b0;
gsr_r = 1'b1;
#(16*CLOCKPERIOD_1);
gsr_r = 1'b0;
end

If using a multi-lane channel, make sure all of the serial transceivers on each side of the
channel are connected in the correct order.

Channel comes up in simulation but s_axi_tx_tvalid is never

asserted (never goes High)
• If the module includes flow control but is not being used, make sure the request signals
are not currently driven Low. s_axi_nfc_tx_tvalid and s_axi_ufc_tx_tvalid
are active-High. If they are High, s_axi_tx_tvalid stays Low because the channel is
being allocated for flow control.
• If NFC is enabled, make sure the channel partner did not send an NFC XOFF message.
This cuts off the channel for normal data until the other side sends an NFC XON
message to turn the flow on again. See Native Flow Control Interface in Chapter 2 for
more details.

Bytes and words are being lost as they travel through the
Aurora channel
• If using the AXI4-Stream interface, make sure the data is written correctly. The most
common mistake is to assume words are written without monitoring tvalid. Also
remember that the tkeep signal must be used to indicate which bytes are valid when
tlast is asserted. tkeep is ignored when tlast is not asserted (active-High).
• Make sure to read correctly from the RX interface. Data and framing signals are only
valid when tvalid is asserted.
• If you still see bytes/words being lost on the receiver side, check the GT receiver output
data interface. If you notice that data is already lost at the GT receiver output interface,
the issue could be caused by GT or any earlier stage in the system.

Aurora 8B/10B v11.1 Send Feedback

99
PG046 October 19, 2023
 Appendix C: Debugging

Problems while compiling the design

• Make sure to include all the files from the src directory when compiling.
• If using VHDL, make sure to include the aurora_pkg.vhd file in synthesis.
• Make sure the simulator and libraries are set up correctly.
• Make sure the simulator language is set to mixed.

Next Step
If the debug suggestions listed previously do not resolve the issue, open a support case to
have the appropriate AMD expert assist with the issue.

To create a technical support case, see the Service Portal web page.

Items to include when opening a case:

• Detailed description of the issue and results of the steps listed previously.
• Attach a value change dump (VCD) or wave log format (WLF) dump of the simulation.
• Attach the XCI/XCO file from the IP.
• If any modifications are updated to the IP generated out of Vivado and reasons for
doing the changes.
• The.ila dump of the Hardware captures optionally, if available.

To discuss possible solutions, use the User Community.

Hardware Debug
Most Vivado Integrated Design Environment (IDE) fields have tool tips which serve as
guidelines to configure and generate the core properly. Refer to and follow all
RECOMMENDED and IMPORTANT notes in the product guide.

RECOMMENDED: Ensure that the serial transceiver attributes are updated. See Appendix D, Generating
a Wrapper File from the Transceiver Wizard for instructions and information about updating the serial
transceiver attribute settings. This section provides a debug flow diagram for resolving some of the
most common issues.

This section provides a debug flow diagram for resolving some of the most common issues.
See GT_Debug_Flowchart for transceiver debugging mentioned in the following Answer
Record: AR: 57237

Aurora 8B/10B v11.1 Send Feedback

100
PG046 October 19, 2023
 Appendix C: Debugging

The Transceiver Debug ports mentioned in Table 2-11, page 31 are operational when you
enable the Additional Transceiver Control and Status Ports option in Aurora_8b10b
interface. Refer to Aurora_8b10b IP Example design for recommended connections for
additional transceiver control and status ports in the following guides:

• 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476) [Ref 3]

• UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 1]

Aurora 8B/10B v11.1 Send Feedback

101
PG046 October 19, 2023
 Appendix C: Debugging

Figure C-1 shows the various steps for performing a hardware debug.
X-Ref Target - Figure C-1

START

Transceiver Attribute
Check (Step 1)

GT REFCLK and GT PLL

LOCK Check (Step 2)

GT TX/RX RESETDONE
Check (Step 3)

USER_CLK Generation
Check (Step 4)

MMCM Lock Check

(Step 5)

RXDISPERR/
RXNOTINTABLE Check
(Step 6)

LANE_UP Assertion Check

(Step 7)

Yes Single Lane? No

CHANNEL_UP Assertion Channel Bonding Assertion

Check (Step 8) Check (Step 8)

Periodic Channel Failures CHANNEL_UP Assertion

Check (Step 9) Check (Step 9)

Periodic Channel Failures

Check (Step 10)

Data Transfer Check

LOOPBACK Testing Check

END

Figure C‐1: Flow Chart

Aurora 8B/10B v11.1 Send Feedback

102
PG046 October 19, 2023
 Appendix C: Debugging

STEP 1: Transceiver Debug

With the transceiver being the critical building block in the Aurora 8B/10B core, debugging
and ensuring proper transceiver operation is very important.

1. Transceiver attribute check:

Transceiver attributes must match with the silicon version of the device being used on
the board. Apply all applicable workarounds and Answer Records given for the
respective silicon version.
2. GT REFCLK and GT PLL LOCK check

A low-jitter differential clock must be provided to the transceiver reference clock. Check
and make sure the REFCLK location constraints are correct with respect to the board
schematics. REFCLK should be active and should meet the phase noise requirements of
the transceiver.

The transceiver locks on to the incoming GT REFCLK signal and asserts the PLL0LOCK
signal. If PLL0LOCK is toggling periodically, check that the FSM reset done signals are
toggling. Make sure that the GT PLL attributes are set correctly and that the transceiver
generates the txoutclk with the expected frequency for the given line rate and
datapath width options. Note that the Aurora 8B/10B core uses Channel PLL (CPLL) in
the generated core for AMD Virtex™ 7 and Kintex™ 7 FPGA GTX and GTH transceivers
and PLL0/PLL1 for Artix™ 7 FPGA GTP transceivers. Check the transceiver power supply
MGTAVCC value.
3. Transceiver TX/RX FSM RESETDONE check

The Aurora 8B/10B core uses sequential reset mode; all of the transceiver components
are reset sequentially, one after another. The txresetdone and rxresetdone signals
should be asserted at the end of the transceiver initialization. In general, rxresetdone
assertion takes longer compared to the TXRESETDONE assertion. Check if user_clk
and sync_clk are connected properly. Make sure the gt_reset signal pulse width
duration complies with the respective transceiver guideline. Probe the signals and FSM
states from the RX/TX STARTUP FSM module. If the RX/TX fsm_resetdone signals are
asserted and the partner is reprogrammed, GTRXRESET should be asserted manually if
hot-plug logic is disabled.

STEP 2: USER_CLK Generation Check

The transceiver generates txoutclk based on the line rate and lane-width parameters. The
user_clk signal is generated from txoutclk and is used by the Aurora 8B/10B core to
clock FPGA logic. Therefore, ensure that user_clk is generated properly with the expected
frequency from txoutclk. If user_clk frequency is not in the expected range, check the
frequency of the transceiver reference clock and verify the transceiver PLL attributes.

Aurora 8B/10B v11.1 Send Feedback

103
PG046 October 19, 2023
 Appendix C: Debugging

STEP 3: MMCM Lock Check

The Aurora 8B/10B core expects all clocks to be stable. If clocks are generated using the
MMCM, ensure that the reset inputs are held High until the generated clock is stable. It is
recommended to stop the output clock from the MMCM until it is locked. For cores
generated with a 4-byte lane width in Artix 7 devices, the MMCM is used to generate
user_clk and sync_clk. Make sure that the TX_LOCK output from the Aurora 8B/10B
core is inverted and connected to MMCM_RESET. If MMCM_LOCK is toggling periodically,
check that the TX_STARTUP_FSM module is restarting and probe the signals and states of
the FSM.

STEP 4: RXDISPERR/RXNOTINTABLE Check

The Aurora 8B/10B core defines RXDISPERR and RXNOTINTABLE using the soft_error
signal. If the core asserts the soft_error signal, probe the RXDISPERR and
RXNOTINTABLE ports of the transceiver. If the transceiver indicates a RXDISPERR or
RXNOTINTABLE error, enable internal loopback and check again. If the loopback test
passes, check the transmitted data and cable for channel integrity. Run integrated bit error
ratio test (IBERT) to confirm the link connectivity and signal integrity (SI) on the channel. If
the IBERT runs fail, monitor the power supplies, check the termination circuit, run SI
simulations, check LPM versus DFE based on attenuation, etc. Also, enabling the scrambler
option in the core is useful to check EMI issues generated over the link.

STEP 5: LANE_UP Assertion Check

The lane_up assertion indicates that the communication between the transceiver and its
channel partner is established and link training is successful. The LANE_INIT_SM module
FSM state signals must be brought to debug if lane_up is not asserted. For a simplex-timer
core, check and follow the reset sequence requirement. If the TX transceiver needs to be
reset as per the system design, increase the C_ALIGNED_TIMER, C_BONDED_TIMER, and
C_VERIFY_TIMER attributes based on the latency between the release of TX_RESET and
RX_RESET. See the Lane Initialization Procedure in the Aurora 8B/10B Protocol Specification
v2.2 (SP002) [Ref 5] for lane_up assertion.

STEP 6: CHANNEL_UP Assertion Check

The criteria for channel_up assertion verification are:

• The sequence defined in the Aurora 8B/10B protocol being transferred between
channel partners
• Successful reception of four verification sequences

Aurora 8B/10B v11.1 Send Feedback

104
PG046 October 19, 2023
 Appendix C: Debugging

Enable loopback mode and check for lane_up assertions. The CHANNEL_INIT_SM module
FSM state signals must be brought to debug if channel_up is not asserted. For a simplex
link, the simplex TX transceiver might have already achieved channel_up status. If the TX
transceiver needs to be reset as per the system design, increase the SIMPLEX_TIMER_VALUE
attribute based on the latency between the release of TX_RESET and RX_RESET. See the
Channel Verification Procedure in the Aurora 8B/10B Protocol Specification v2.2 (SP002)
[Ref 5] for channel_up assertion.

STEP 6A: Channel Bonding Assertion Check

Channel bonding is necessary for a multi-lane Aurora design. Channel bonding is
performed by the transceiver and the required logic is present in the transceiver_wrapper
module. Make sure that the channel bonding level and master and slave connections are
correct. Check that the CLK_COR_MIN_LAT and CLK_COR_MAX_LAT attributes of the
transceiver are set as recommended. See the Channel Bonding Procedure in the Aurora
8B/10B Protocol Specification v2.2 (SP002) [Ref 5] for channel_up assertion.

STEP 6B: CHANNEL_UP Assertion Check

This step is the same as STEP 6 described previously.

STEP 7: Periodic Channel Failures Check

If the Aurora 8B/10B core asserts and deasserts the channel_up signal, enable internal
loopback and check for a stable channel up condition. Probe RXBUFSTATUS of the
transceiver. If there is overflow or underflow, the CLK_COR_MIN_LAT and
CLK_COR_MAX_LAT attribute values for the transceiver must be adjusted. Also make sure
the hot-plug logic is disable when the standard_cc block is not used. In a duplex link, if the
RXBUFSTATUS signal is toggling frequently before lane_up or channel_up assertion, or if the
link is flaky as a result of RX electrical idle exit after the gt_reset_i is deasserted, enable
the newly added user parameter C_DOUBLE_GTRXRESET. This parameter can be enabled
during IP core generation using the Tcl mode. By enabling this TCL parameter, the IP core
attempts to repeat the GT RX reset sequence after it achieves initial symbol lock to avoid
any potential errors seen during link initialization as referred in (UG476) [Ref 3] and (UG576)
[Ref 1].

STEP 8: Data Transfer Check

After channel_up is asserted, the Aurora 8B/10B core is ready to transfer data. Data errors
can be monitored at the err_count_r signal in VIO. The tx_d and rx_d signals are
connected to monitor the data transfer. soft_err, hard_err and frame_err are also
connected to VIO. A FIFO is used by the transceiver for clock correction and channel
bonding. Overflow and underflow of this FIFO results in a hard_err (HARD_ERR). Tune the
CLK_COR_MIN_LAT and CLK_COR_MAX_LAT attributes of the transceiver to correct the FIFO
overflow/underflow errors.

Aurora 8B/10B v11.1 Send Feedback

105
PG046 October 19, 2023
 Appendix C: Debugging

Note: The ENABLE_SOFT_ERR_MONITOR parameter is available in the err_detect module under the
src directory to control the leaky bucket algorithm. This parameter can be to set to 0 to disable the
leaky bucket algorithm for debug purposes.

STEP 9: LOOPBACK Configuration Testing

Loopback modes are specialized configurations of the transceiver datapath. The Aurora
8B/10B example design loopback port controls the loopback modes. Four loopback modes
are available. Refer to the respective transceiver user guide for more information.
Figure C-2 illustrates a loopback test configuration with four different loopback modes.
X-Ref Target - Figure C-2

Link Near-End Test Structures Link Far-End Test Structures

Test Logic Near-End GTX Far-End GTX

RX-PCS RX-PMA

Traffic
Checker

TX-PMA TX-PCS

TX-PCS 1 TX-PMA 2 3 4

Traffic
Generator

RX-PMA RX-PCS

X13196

Figure C‐2: Loopback Testing Overview

STEP 10: Channel comes up in simulation but not in hardware

• Both reset and gt_reset inputs are active-High. Make sure the reset polarity is
taken care in the hardware.
• Make sure the refclk frequency is exactly the same as the Aurora 8B/10B core is
generated for.
• If the refclk is driven from a synthesizer, make sure the synthesizer is stable (locked).
• Make sure the cable connection from TXP/TXN to RXP/RXN is proper.
• If there are RXNOTINTABLE errors observed from the serial transceiver, validate the link
using IBERT. Make sure there is no BER in the channel. Use the sweep test in the IBERT
tool and use the same serial transceiver attributes which provide "Zero" BER in IBERT.
• A burst of soft errors results in a hard error and re-initializes the channel. Set
ENABLE_SOFT_ERR_MONITOR to 0 in the <component name>_err_detect module
to disable hard error assertion from soft errors.

Aurora 8B/10B v11.1 Send Feedback

106
PG046 October 19, 2023
 Appendix C: Debugging

Additional Assistance
If the debug suggestions listed previously do not resolve the issue, open a support case to
have the appropriate AMD expert assist with the issue.

To create a technical support case in WebCase.

Items to include when opening a case:

• Detailed description of the issue and results of the steps listed previously.
• Attach Vivado lab tools captures taken in the previous steps.

To discuss possible solutions, use the User Community.

AXI4-Stream Interface Debug

If data is not being transmitted or received, check the following conditions:

• If transmit s_axi_tx_tready is stuck Low following the s_axi_rx_tvalid input

being asserted, the core cannot send data.
• If the receive m_axi_rx_tvalid is stuck Low, the core is not receiving data.
• Check that the user_clk input is connected and toggling.
• Check that the AXI4-Stream waveforms are being followed. See Figure 2-8, page 16 for
data transfer and Figure 2-12, page 19 for data reception.
• Check core configuration.

Aurora 8B/10B v11.1 Send Feedback

107
PG046 October 19, 2023
 Appendix D

Generating a Wrapper File from the

Transceiver Wizard
The transceiver attributes play a vital role in the functionality of the Aurora 8B/10B core. Use
the latest Transceiver Wizard to generate the transceiver wrapper file.

RECOMMENDED: AMD strongly recommends that the transceiver wrapper file is updated in the AMD
Vivado™ Design Suite tool releases when the transceiver wizard has been updated but the Aurora core
has not.

This appendix provides instructions to generate these transceiver wrapper files.

Use these steps to generate the transceiver wrapper file using the 7 series FPGAs
transceivers wizard:

1. Using the Vivado IP catalog, run the latest version of the 7 Series FPGAs Transceivers
Wizard. Make sure the Component Name of the transceiver wizard matches the
Component Name of the Aurora 8B/10B core.
2. Select the protocol template from the following based on the number of lane(s) and lane
width:

° Aurora 8B/10B single lane 2 byte

° Aurora 8B/10B single lane 4 byte

° Aurora 8B/10B multi lane 2 byte

° Aurora 8B/10B multi lane 4 byte

3. Change the Line Rate in both TX and RX based on the application requirement.
4. Select the Reference Clock from the drop-down menu in both TX and RX based on the
application requirement.
5. Select transceiver(s) and the clock source(s) based on the application requirement.
6. Keep the default for all other settings.
7. Generate the core.
8. Replace the <component name>_gt.v[hd] and <component name>_
multi_gt.v[hd] files in the gt directory available in the Aurora 8B/10B core with the
generated <component name>_gt.v[hd] and <component name>_
multi_gt.v[hd] files generated from the 7 series FPGAs transceivers wizard.

Aurora 8B/10B v11.1 Send Feedback

108
PG046 October 19, 2023
 Appendix D: Generating a Wrapper File from the Transceiver Wizard

The transceiver settings for the Aurora 8B/10B core are now up to date.

Note: The UltraScale™ architecture Aurora 8B/10B core uses the hierarchical core calling method to
call the UltraScale device gtwizard IP core. In this way, all the transceiver attributes, parameters, and
required workarounds are in place and correct. Manual editing of the UltraScale device transceiver
files are not required in most of the cases. The attribute(s) in the Aurora 8B/10B core example design
XDC file can be updated.

Aurora 8B/10B v11.1 Send Feedback

109
PG046 October 19, 2023
 Appendix E

Handling Timing Errors

This appendix describes how to handle timing errors resulting from transceivers that are
located far apart from each other. The Aurora 8B/10B core allows selecting any combination
of transceiver(s) during core generation. The design parameters that affect the timing
performance are:

• Line rate
• Transceiver datapath width (2/4 bytes)
• Number of unused transceivers between two selected transceivers

As a result of one or more of these parameters, timing errors can occur because:

• CHBONDO does not meet timing

• RXCHARISCOMMA, RXCHARISK, and RXCHANISALIGNED do not meet timing

The following suggestions can be attempted to meet timing:

• Select the transceivers consecutively.

Use the Lane Assignment in the Aurora 8B/10B AMD Vivado™ Integrated Design
Environment (IDE) to select the transceivers during core generation.

Note: Most of the timing errors are due to unused transceivers and channel bonding signals
connections among transceivers.
• Use the Strategies options provided for implementation in the Vivado Design Suite. See
the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 7] for instructions
on how to use the Strategies options.

Aurora 8B/10B v11.1 Send Feedback

110
PG046 October 19, 2023
 Appendix F

Additional Resources and Legal Notices

Support Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see
Support.

Finding Additional Documentation

Documentation Portal
The AMD Adaptive Computing Documentation Portal is an online tool that provides robust
search and navigation for documentation using your web browser. To access the
Documentation Portal, go to https://docs.xilinx.com.

Documentation Navigator
Documentation Navigator (DocNav) is an installed tool that provides access to AMD
Adaptive Computing documents, videos, and support resources, which you can filter and
search to find information. To open DocNav:

• From the AMD Vivado IDE, select Help > Documentation and Tutorials.
• On Windows, click the Start button and select Xilinx Design Tools > DocNav.
• At the Linux command prompt, enter docnav.
Note: For more information on DocNav, refer to the Documentation Navigator User Guide (UG968).

Design Hubs
AMD Design Hubs provide links to documentation organized by design tasks and other
topics, which you can use to learn key concepts and address frequently asked questions. To
access the Design Hubs:

• In DocNav, click the Design Hubs View tab.

• Go tot the Design Hubs web page.

Aurora 8B/10B v11.1 Send Feedback

111
PG046 October 19, 2023
 Appendix F: Additional Resources and Legal Notices

References
These documents provide supplemental material useful with this product guide. You should
be familiar with these documents prior to generating an Aurora 8B/10B core.

1. UltraScale Architecture GTH Transceivers User Guide (UG576)

2. 7 Series FPGAs GTP Transceivers User Guide (UG482)
3. 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476)
4. AMBA AXI4-Stream Protocol Specification (v1.0)
5. Aurora 8B/10B Protocol Specification (SP002)
6. Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
7. Vivado Design Suite User Guide: Designing with IP (UG896)
8. Vivado Design Suite User Guide: Getting Started (UG910)
9. Vivado Design Suite User Guide - Logic Simulation (UG900)
10. Designing a System Using the Aurora 8B10B Core (Duplex) on the KC705 Evaluation Kit
(XAPP1193)
11. Vivado Design Suite User Guide: Programming and Debugging (UG908)
12. UltraScale Architecture Migration Methodology Guide (UG1026)
13. LogiCORE IP Aurora 8B/10B v5.3 Data Sheet (DS637)
14. LogiCORE IP Aurora 8B/10B v5.3 User Guide (UG353)
15. Packaging Custom AXI IP for Vivado IP Integrator Application Note (XAPP1168)
16. UltraScale FPGAs Transceivers Wizard LogiCORE IP Product Guide (PG182)
17. 7 Series FPGAs Data Sheet: Overview (DS180)
18. UltraScale Architecture and Product Overview (DS890)
19. Kintex UltraScale FPGAs Data Sheet: DC and AC Switching Characteristics (DS892)
20. Virtex UltraScale FPGAs Data Sheet: DC and AC Switching Characteristics (DS893)
21. Kintex UltraScale+ FPGAs Data Sheet: DC and AC Switching Characteristics (DS922)
22. Virtex UltraScale+ FPGAs Data Sheet: DC and AC Switching Characteristics (DS923)

Revision History
The following table shows the revision history for this document.

Aurora 8B/10B v11.1 Send Feedback

112
PG046 October 19, 2023
 Appendix F: Additional Resources and Legal Notices

Date Version Revision

10/19/2023 11.1 • Updated figures Figure 3-4 and Figure 3-6.
• Added guidance for avoiding long delays in assertion/de-assertion.
05/11/2022 11.1 • Updated the Example B: Receiving a Message with NFC Idles Inserted
section.
• Updated the Reset and Power Down section.
• Updated the Simulation speed up section.
04/04/2018 11.1 • Added a note to the description in Appendix A.
• Added a bullet about data loss at GT receiver output interface in Appendix C.
10/04/2017 11.1 • Added description for the C_DOUBLE_GTRXTESET parameter.
04/05/2017 11.1 • Added support to generate Aurora without GT for UltraScale and
UltraScale+ devices.
10/05/2016 11.0 • Removed the Example design directory structure due to the updates in
Vivado flows for 2016.3 to support Windows shorter paths.
06/08/2016 11.0 • Added Reference to GT_Debug_Flowchart in AR 57237.
• Updated C_EXAMPLE_SIMULATION usage description.
04/06/2016 11.0 Updated the support for tested development boards.
11/18/2015 11.0 Added support for UltraScale+ families.
09/30/2015 11.0 • Removed BUFG on the drpclk_in signal in the core and added in example
design.
• Added description of Figure 2-4 in the Port Description section.
• Added links to the web page for performance and utilization characteristics.

Aurora 8B/10B v11.1 Send Feedback

113
PG046 October 19, 2023
 Appendix F: Additional Resources and Legal Notices

Date Version Revision

04/01/2015 11.0 General Changes
• Added GT location selection option for the UltraScale™ device section.
• Modified AXI4-Stream information.
• Grouped Flow control ports into the AXI4-Stream interface.
• Updated Reset section.
• Moved Clock Compensation section to Chapter 3, Designing with Core.
• Added Single/Differential clocking option for GTREFCLK and core INIT_CLK.
• Removed do_cc signal throughout.
• Moved all of the material in the Core Features chapter to the end of Chapter
3, Designing with the Core. Deleted Chapter 4.
• Changed reset to reset_pb, s_axi_ufc_tx_req to s_axi_ufc_tx_tvalid, usr_clk to
user_clk, tx_reset to tx_reset_pb, and rx_reset to rx_reset_pb, s_axi_ufc_tx_ms
to s_axi_ufc_tx_tdata, s_axi_ufc_tx_ack to s_axi_ufc_tx_tready, s_axi_tx_ready
to s_axi_ufc_tx_tready, s_axi_tx_tdata to s_axi_ufc_tx_tdata, s_axi_nfc_req to
s_axi_nfc_tx_tvalid, s_axi_nfc_nb to s_axi_nfc_tx_tdata, s_axi_nfc_ack to
s_axi_nfc_tx_tready, s_axi_nfc_ack to s_axi_nfc_tx_tvalid, m_axi_rx_snf to
m_axi_nfc_tx_tvalid, m_axi_ufc_rx to m_axi_ufc_rx_tdata, m_axi_tx_fc_nb[0:3]
to m_axi_nfc_tx_tdata[0:3].
• Removed do_cc information.
• Added the Single Ended option material throughout.
• Changed IBUFDS to IBUFDS_GTE.
Chapter 2: Product Specification
• Modified TX User interface description.
• Updated Figure 2-4, Figure 2-7, Figure 2-8, Figure 2-12, Figure 2-13, Figure
2-14, Figure 2-16, Figure 2-17, Figure 2-18, Figure 2-19, Figure 2-22, Figure
2-23, and Figure 2-26.
• Removed paragraph about AXI4-Stream signal sampling.
• Added information about s_axi_tx_tkeep.
• Added reset and user_clk ports to Figure 2-7 and Figure 2-13.
• Removed Data Strobe section.
• Added heading rows UFC_S_AXIS_TX and UFC_M_AXIS_RX to Table 2-11.
• Modified some clock domains in Table 2-16.
• Modified m_axi_ufc_rx_tvalid description.
• Deleted m_axi_ufc_rx_tvalid and m_axi_ufc_rx_tlast from Figure 2-22.
• Adding heading rows NFC_S_AXIS_TX and NFC_M_AXIS_RX to Table 2-14.
• Modified Figure 2-23: Transmitting an NFC Message.

Aurora 8B/10B v11.1 Send Feedback

114
PG046 October 19, 2023
 Appendix F: Additional Resources and Legal Notices

Date Version Revision

04/01/2015 Chapter 2: Product Specification (continued)
(continued) • Added Important note about ports in the Transceiver Interface section.
• Added rows for gt<lane>_txinhibit_in/gt_txinhibit and gt_pcsrsvdin to Table
2-18: Transceiver Ports.
• Added notes 11 and 12 to Table 2-18: Transceiver Ports
• Added 7 rows to Table 2-20: Added text about the Single Ended GT REFCLK
and Single Ended INIT CLK options to Table 2-20.
gt_qpllrefclk_quad<quad>_out, gt<quad>_qplllock_in,
gt<quad>_qpllrefclklost_in, gt_qpllclk_quad<quad>_in,
gt_qpllrefclk_quad<quad>_in, gt_qpllreset_out, tx_out_clk.
• Changed “clock cycles” to “time period” throughout.
• Extensively revised the Clock Compensation section. Removed Figures 2-28
and 2-29. Relocated after the Hot-Plug Logic section in Chapter 3
Chapter 3: Designing with the Core
• Moved all of the material in Chapter 4: Core Features to the end of this
chapter.
• Added a note about the Single Ended option to the Shared Logic section.
• Updated Figure 3-11.
Chapter 4: Design Flow Steps
• Updated all Vivado IDE figures to version 11.0.
• Updated Recommended note in the Lane Assignment section.
• Added Starting GT Quad and Starting GT Lane options.
• Added six rows to Table 4-1: Column Used, Starting GT Quad, Starting GT
Lane, GT Refclk Selection, Single Ended INIT CLK, and Single Ended GTREF
CLK.
• Added notes about IP integrator and data and flow control ports to Core
Generation section.
Appendix B: Migrating and Upgrading
• Updated Overview of Major Changes section.
• Updated Figure B-3: AXI4-Stream Signals.
10/01/2014 10.3 • Added new v10.3 core features and attributes
• Rearranged content to consolidate topics and better conform to template
06/06/2014 10.2 • Added information about migrating transceiver ports to UltraScale devices.
06/04/2014 10.2 • Added User Parameter information.
• Fixed gt0_dmonitorout_out port width for GTX devices in transceiver
debug ports
04/02/2014 10.2 • Added UltraScale architecture support.
• Updated init_clk frequency requirements.
• Added little endian support to User Data, NFC and UFC interfaces.
12/18/2013 10.1 • Added transceiver debug ports.
• Updated all screen captures.
• Updated all signals in figures to lowercase.

Aurora 8B/10B v11.1 Send Feedback

115
PG046 October 19, 2023
 Appendix F: Additional Resources and Legal Notices

Date Version Revision

10/02/2013 10.0 • Added new chapters: Simulation, Test Bench and Synthesis and
Implementation.
• Added shared logic and transceiver debug features.
• Updated directory and file structure.
• Updated resource utilization tables.
• Added information about hot-plug logic.
• Updated screen captures for Figures 5-1, 5-2, 5-3, 5-4, 5-5, 8-1 and B-3.
• Changed all uppercase signal names to lowercase.
• Updated Migrating and Upgrading appendix.
06/19/2013 9.1 • Revision number advanced to 9.1 to align with core version number.
• Updated for Vivado™ Design Suite v2013.2 and ISE™ Design Suite v14.6.
• Aurora 8B10B v9.0 core is updated to Aurora 8B10B v9.1 based on revision
guidelines.
03/20/2013 3.0 • Updated for Vivado Design Suite and core version 11.0
• Modified Appendix C, Debugging with transceiver debug details.
• Updated screen captures in Chapter 5, Chapter 7, and Appendix B.
• Removed ISE, CORE Generator™, UCF, Virtex™-6, and Spartan™-6 material.
• Updated Reset waveforms.
• Updated Directory and File Structure.
• Created lowercase ports for Verilog.
12/18/2012 2.0.1 • Updated for Vivado Design Suite v2012.4 and ISE Design Suite v14.4.
• Modified maximum and minimum latency.
• Added many new signals to Table 2-22, Transceiver Ports.
• Updated screen captures in Chapter 5, Chapter 7, and Appendix B.
• Modified Appendix C, Debugging
10/16/2012 2.0 This release supports core version 8.3 with Vivado Design Suite v2012.3 and
ISE Design Suite v14.3.
Major changes include:
• Updated screen captures for Figures 5-1, 5-2, 7-2, 8-1, 8-2, 8-3, 8-4, 10-2,
and B-3.
• Added steps for Generating the Core in Chapter 7.
• Added Artix™-7 device support.
• Added GTH transceiver support.
• Added LOOPBACK[2:0] and GT_RESET ports to Table 2-22.
• Replaced IBUFDS_GTXE1 to IBUFDS_GTE2 in Figure 3-2.
• Removed Design Constraints section in Chapter 6.
• Added Clock Frequencies, I/O Placement, and I/O Standard and Placement
sections.
07/25/2012 1.0 • Initial Xilinx release. This release supports core version 8.2 with Vivado™
Design Suite v2012.2. This document replaces UG766 and DS797.

Aurora 8B/10B v11.1 Send Feedback

116
PG046 October 19, 2023
 Appendix F: Additional Resources and Legal Notices

Please Read: Important Legal Notices

The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions,
and typographical errors. The information contained herein is subject to change and may be rendered inaccurate for many
reasons, including but not limited to product and roadmap changes, component and motherboard version changes, new model
and/or product releases, product differences between differing manufacturers, software changes, BIOS flashes, firmware
upgrades, or the like. Any computer system has risks of security vulnerabilities that cannot be completely prevented or mitigated.
AMD assumes no obligation to update or otherwise correct or revise this information. However, AMD reserves the right to revise
this information and to make changes from time to time to the content hereof without obligation of AMD to notify any person of
such revisions or changes. THIS INFORMATION IS PROVIDED ‘AS IS.’ AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH
RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS, OR OMISSIONS
THAT MAY APPEAR IN THIS INFORMATION. AMD SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY PERSON FOR ANY
RELIANCE, DIRECT, INDIRECT, SPECIAL, OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION
CONTAINED HEREIN, EVEN IF AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
AUTOMOTIVE APPLICATIONS DISCLAIMER
AUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOT WARRANTED FOR USE IN THE DEPLOYMENT OF
AIRBAGS OR FOR USE IN APPLICATIONS THAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS A
SAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262 AUTOMOTIVE SAFETY STANDARD ("SAFETY
DESIGN"). CUSTOMER SHALL, PRIOR TO USING OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY
TEST SUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATION WITHOUT A SAFETY DESIGN IS FULLY
AT THE RISK OF CUSTOMER, SUBJECT ONLY TO APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT
LIABILITY

© Copyright 2012–2023 Advanced Micro Devices, Inc. AMD, the AMD Arrow logo, Artix, Kintex, UltraScale+, Virtex, Vivado, Zynq,
and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for
identification purposes only and may be trademarks of their respective companies. AMBA, AMBA Designer, Arm, ARM1176JZ-S,
CoreSight, Cortex, PrimeCell, Mali, and MPCore are trademarks of Arm Limited in the EU and other countries. MATLAB and
Simulink are registered trademarks of The MathWorks, Inc. All other trademarks are the property of their respective owners.

Aurora 8B/10B v11.1 Send Feedback

117
PG046 October 19, 2023