50g MAC
50g MAC
Introduction
Features
IP Facts
Overview
Navigating Content by Design Process
Subsystem Overview
Feature Summary
Applications
Licensing and Ordering
Product Specification
Typical Operation
Statistics Gathering
Testability Functions
Standards
Performance and Resource Utilization
Latency
Port Descriptions
Auto-Negotiation (AN) and Link Training (LT)
Link Training Description
Board Testing of the 40G/50G High Speed Ethernet Using the AXI4-Lite Interface
Forward Error Correction (FEC)
PCS Variant
AXI4-Lite Register Space
Designing with the Subsystem
General Design Guidelines
Clocking
LogiCORE Example Design Clocking and Resets
SerDes Data Mapping for GTM
IEEE PTP 1588v2 for 40G/50G Subsystem
IEEE PTP 1588v2 Functional Description
RS-FEC Support
Status/Control Interface
Design Flow Steps
Customizing and Generating the Subsystem
Constraining the Subsystem
Simulation
Synthesis and Implementation
Example Design
Example Design Hierarchy
Example Design Hierarchy (GT in Example Design)
User Interface
Core xci Top Level Port List
Duplex Mode of Operation
Run Time Switchable
Introduction
The AMD High Speed Ethernet IP Subsystem implements the 40G or 50G Ethernet Media
Access Controller (MAC) with a Physical Coding Sublayer (PCS) or standalone PCS.
Features
Designed to the Ethernet requirements for 50 Gb/s operation as defined in Schedule 3 of
the 25G Ethernet Consortium (Ethernet Technology Consortium). See the note at the
bottom of the page.
Designed to the requirements for 40 Gb/s operation as defined in IEEE 802.3 Clause 82
IEEE Standard for Ethernet (IEEE Std 802.3-2015).
Includes complete Ethernet MAC and PCS functions or standalone PCS.
Simple packet-oriented user interface.
Low latency mode.
Comprehensive statistics gathering.
Status signals for all major functional indicators.
Delivered with a top-level wrapper including functional transceiver wrapper, IP netlist,
sample test scripts, and AMD Vivado™ design tools compile scripts.
Optional fee based AN/LT/KR Forward Error Correction (FEC) features.
Optional KP4 FEC feature for GTM devices.
✎ Note: To access the 25G specification, visit the Ethernet Technology Consortium website.
IP Facts
AMD LogiCORE™ IP Facts Table
Subsystem Specifics
Support
1. For the supported versions of third-party tools, see the Vivado Design Suite User
Guide: Release Notes, Installation, and Licensing (UG973).
2. Contact AMD Technical Support for your design requirements.
Overview
Navigating Content by Design Process
AMD Adaptive Computing documentation is organized around a set of standard design
processes to help you find relevant content for your current development task. You can access
the AMD Versal™ adaptive SoC design processes on the Design Hubs page. You can also
Port Descriptions
AXI4-Lite Register Space
Configuration Registers
Status Registers
Statistics Counters
Clocking
Customizing and Generating the Subsystem
Example Design
Debugging
Subsystem Overview
The AMD 40G/50G High Speed Ethernet Subsystem implements a 40G/50G Ethernet Media
Access Controller (MAC) module with 40G/50G PCS or standalone 40G/50G PCS.
The 40G/50G High Speed Ethernet Subsystem is designed to Schedule 3 of the 25G and 50G
Ethernet Consortium specification r1.6 for the 50 Gb/s operation and IEEE 802.3 for 40 Gb/s
operation; it is hardware proven, and offers system designers with a risk-free and quick path
for systems that implement 40G/50G Ethernet protocols.
This guide also describes the 40G/50G High Speed Ethernet Subsystem in detail and provides
the information required to integrate the 40G/50G High Speed Ethernet Subsystem into user
designs. The document assumes you are familiar with the IEEE Std 802.3-2015 protocol and
FPGA design and methodology. See Product Specification for detailed information. For AMD
device platform-specific information, see Support. See also the IEEE Standard for Ethernet
(IEEE Std 802.3-2015).
Feature Summary
Supports custom preambles
Programmable Inter Packet Gap (IPG)
Simple packet oriented 128-bit straddled packet AXI4-Stream Interface for 40 Gb/s and
50 Gb/s operation
Optional 256-bit regular AXI4-Stream Interface for 40 Gb/s operation
Optional Clause 74 Forward Error Correction (FEC)
50G FEC (Ethernet Consortium Schedule 3 specification, based on IEEE 802.3 Clause
91)
Optional 1588v2 PTP 1-step and 2-step timestamping
Optional Auto-Negotiation and Link Training
AXI4-Stream
Low X X X X
Latency
40G
MAC
+
PCS
40G X X X X X X X X
MAC
+
PCS
40G X X X X1
PCS-
only
Low X X X
Latency
50G
MAC
+
PCS
50G X X X X X X X X X
MAC
AXI4-Stream
+
PCS
50G X X X X X X1
PCS-
only
Runtime X X X - - X X X X
switchable
40/50G
MAC+PCS
3
Runtime - X - - - X X X X1
switchable
40/50G
PCS-
only 3
Applications
The AMD 40G/50G High Speed Ethernet Subsystem is designed to function as the network
interface for applications that require a very high bit rate, such as:
Ethernet switches
IP routers
Data center switches
Communications equipment
To keep up with increasing CPU and storage bandwidth, rack, or blade servers must
support aggregate throughputs faster than 10 Gb/s (single lane) or 20 Gb/s (dual lane)
from their Network Interface Card (NIC) or LAN-on-Motherboard (LOM) networking ports.
Given the increased bandwidth to endpoints, uplinks from Top-of-Rack (TOR) or Blade
switches need to transition from 40 Gb/s (four lanes) to 100 Gb/s (four lanes) while
ideally maintaining the same per-lane breakout capability.
Due to the expected adoption of 100GBASE-CR4/KR4/SR4/LR4, SerDes, and cabling
technologies are already being developed and deployed to support 25 Gb/s per physical
lane, twin-ax cable, or fiber.
License Checkers
If the IP requires a license key, the key must be verified. The AMD Vivado™ design tools have
several license checkpoints for gating licensed IP through the flow. If the license check
succeeds, the IP can continue generation. Otherwise, generation halts with an error. License
checkpoints are enforced by the following tools:
Vivado Synthesis
Vivado Implementation
write_bitstream (Tcl command)
‼ Important: IP license level is ignored at checkpoints. The test confirms a valid license
exists. It does not check IP license level.
Product Specification
The 40G/50G High Speed Ethernet IP subsystem provides ease of use connecting to the High
Speed Ethernet core. Based on the configuration, this subsystem creates interface ports,
instantiates the 40G/50G High Speed Ethernet Subsystem and high speed serialize and
deserializer (SerDes) blocks, provides the appropriate clock signals, and connects to the AXI4-
Stream user-side interface.
The block diagram for the 40G/50G High Speed Ethernet Subsystem is shown in the following
figure. The right-hand side is the user interface and the left-hand side is the external device
interface.
Figure: 40G/50G High Speed Ethernet Subsystem with 128-bit Straddled AXI4-Stream
The PCS architecture is based on distributing (or striping) parts of a packet over several
(relatively) lower speed physical interfaces by the transmitting device. The receiving device
PCS layer is responsible for stripping the different parts and rebuilding the packet before
Typical Operation
The core handles all protocol-related functions to communicate with the PCS and Ethernet
MAC interface of another device. This includes handshaking, synchronizing, and error
checking. You provide packet data through the AXI4-Stream TX interface, and receive packet
data from the AXI4-Stream RX interface. A detailed description is given in AXI4-Stream
Interface.
The 40G/50G High Speed Ethernet Subsystem is designed to be as flexible as possible and
can be used in many different applications. The RX path does not perform any buffering other
than the pipelining required to perform the required operations. Received data is passed
directly to the user interface in a cut-through manner, allowing you the flexibility to implement
any required buffering scheme. Also, the core TX path consists of a single pipeline with
minimal buffering to provide reliable cut-through operation.
Statistics Gathering
The 40G/50G High Speed Ethernet Subsystem provides a flexible and user-friendly
mechanism for gathering statistics. For every one of the supported statistics, the core has an
output signal (or bus) that indicates an increment value for the statistic in a given clock cycle.
This mechanism allows you to select which statistics are required in the system without having
the cost overhead of a full set of counters. Additionally, and more importantly, you can
implement any counter and statistics gathering mechanism required by the system. For
example, you can build 32-bit or 64-bit counters as needed, or implement clear-on-read or
saturated counters, as required. An optional AXI4-Lite register implementation is available
Testability Functions
The core implements the test pattern generation and checking as defined in Clause 82.2.10
(test-pattern generators) and 82.2.17 (test-pattern checkers). For details, see the IEEE
Standard for Ethernet (IEEE Std 802.3-2015).
Standards
The 40G/50G High Speed Ethernet Subsystem is designed to Schedule 3 of the 25G and 50G
Ethernet Consortium specification r1.6 for the 50 Gb/s operation and IEEE 802.3 for 40 Gb/s
operation.
Latency
The following table provides the measured latency information for the low latency design of the
40G/50G IP core. This is the combined RX and TX latency for the core and does not include
latency in the transceiver.
Table: Latency Results For Low Latency Design of the 40/50G IP Core
1. These numbers include both RX and TX fabric logic, but do not include the GT.
2. The MAC+PCS numbers are for low latency with FIFO removed. PCS/PMA always
has FIFO, due to which the latency numbers are higher.
Port Descriptions
The following tables list all ports applicable to the 40G/50G subsystem including the ports
used for optional features at the name_hsec_cores hierarchy level. At the xci top level
hierarchy the ports change some to include the instantiated transceiver core and other shared
logic. The port list at the XCI level of the hierarchy is described in Core xci Top Level Port List
in Example Design. Other Ports are described in PCS Variant and Auto-Negotiation (AN) and
Link Training (LT).
The following figure shows the relationship between the hierarchical blocks and illustrates the
differences among the blocks in relation to the signals.
✎ Note: When you generate the optional AXI4-Lite registers, some of these ports can be
accessed by the corresponding register instead of a broadside bus.
The following sections describe the ports. The VL_LANES parameter is 4 and the LANES
parameter is 2 for 50 Gb/s operation and 4 for 40 Gb/s operation. For GTM, see SerDes Data
Mapping for GTM.
Transceiver Ports
The following table describes the transceiver I/O ports. Refer to the Clocking topic for clock
domain information.
Related Information
Clocking
AXI4-Stream Interface
This section describes how to connect the AXI4-Stream data interfaces of the 40G/50G
subsystem. The AXI4-Stream interface follows the standard Arm® AMBA 4 AXI4-Stream
Protocol v1.0 Specification but makes extensive use of "user" signals. Refer to the AMBA
AXI4-Stream Protocol Specification (ARM IHI 0051A) for a detailed description of the
interface.
The 40G/50G High Speed Ethernet subsystem provides a 128-bit straddle packet AXI4-
Stream interface for operations at 40 Gb/s and 50 Gb/s. Additionally, there is a choice of a
256-bit regular AXI4-Stream interface for the IP operating at 40 Gbps only.
In the AXI4-Stream interface, the following tables describe the clock/reset signals, the Receive
interface signals, and the Transmit interface signals.
The receive AXI4-Stream interface is similar to the transmit side, with the RX data
corresponding to the received Ethernet frame. The other signals on the RX AXI bus have a
meaning analogous to the signals on the TX bus.
The following table shows the AXI4-Stream receive interface signals.
rx_axis_tuser_mty0[2:0]
O rx_core_clk This bus indicates how many bytes of the
rx_axis_tuser_mty1[2:0] rx_axis_tdata bus are empty or invalid for the
last transfer of the current packet. This bus is
only valid during cycles when both
rx_axis_tuser_ena and rx_axis_tuser_eop are
1.
There are two bits—one for each segment.
✎ Note: In the 128-bit Straddle Packet Interface, the TX AXIS interface is generally
synchronous with tx_out_clk and the RX AXIS interface is synchronous with rx_clk_out.
The timing of a normal inbound frame transfer is represented below. The client must be
prepared to accept data at any time as there is insufficient buffering within the core to allow for
latency in the receive client. When frame reception begins, data is transferred on consecutive
clock cycles to the receive client. During frame reception, rx_axis_tuser_tvalid is asserted
to indicate that valid frame data is being transferred to the client on rx_axis_tdata. All bytes
are always valid throughout the frame, as indicated by all rx_axis_tuser_mty bits being set
to 0, except during the final transfer of the frame when rx_axis_tuser_eop is asserted.
During this final transfer of data for a frame, rx_axis_tuser_mty bits indicate the final valid
bytes of the frame.
Figure: RX Waveform
The signals shown in the figure above waveform are described in the following subsections.
rx clk
The rx_clk_out signal should be used as the clock reference for all RX AXI4-Stream
signals. All RX AXI signals are aligned to the rising edge of this clock.
rx_axis_tdata[127:0]
This bus provides the packet-oriented data corresponding to the received Ethernet
frame. Data is clocked by therx_clk_out signal. The following figure illustrates how the
end of an Ethernet frame is mapped onto the bit positions of the RX AXI4-Stream
interface. Note the positions of the ENA0 and ENA1 signals relative to the bits positions
of the RX AXI4-Stream bus. This mapping is for a 128-bit AXI4-Stream bus.
The following figure shows a normal receive cycle with back-to-back continuous transfers. A
124 byte packet starts on segment 0 and ends on segment 1. This is followed by a 99 byte
packet that starts in the next clock cycle on segment 0 and ends on segment 0.
Figure: RX Mapping
rx_axis_tuser_tvalid
When asserted, this signal indicates that data on the RX AXI bus is valid.
rx_axis_tuser_ena0, rx_axi_tuser_ena1
When asserted, this signal indicates that data for the associated segment is valid.
rx_axis_tuser_sop0, rx_axis_tuser_sop1
This signal indicates the start of an Ethernet frame on the RX AXI bus. There is one SOP
signal for each segment.
rx_axis_tuser_eop0, rx_axis_tuser_eop1
This signal indicates the end of an Ethernet frame on the RX AXI bus. There is one EOP
signal for each segment.
rx_axis_tuser_mty0[2:0], rx_axis_tuser_mty1[2:0]
As in the TX AXI interface, the mty signal indicates how many bytes of the current cycle
are unused (empty) during the last cycle of a received packet (the EOP cycle). There is
one mty signal for each RX segment.
Figure: TX Waveform
The following figure shows a normal transmit cycle with back-to-back continuous transfers. A
115 byte packet starts on segment 0 and ends on segment 0. This is immediately followed by
an 81 byte packet that starts in the same clock cycle in segment 1, and ends on segment 1.
The signals shown in the Figure 1 and Figure 2 waveforms are described in the following
subsections.
tx_clk
This is the signal tx_clk_out output of the subsystem. All TX AXI signals are referenced
to this clock. The frequency of this clock is normally 390.625 MHz for 50G operation and
312.5 MHz for 40G operation.
tx_axis_tdata[127:0]
This is the bus for the frame to be transmitted.
The following figure illustrates how the start of an Ethernet frame is mapped onto the bit
positions of the TX AXI4-Stream interface when tx_axis_tuser_sop0 = 1. Note the positions of
the ENA0 and ENA1 signals relative to the bits positions of the TX AXI4-Stream bus.
This mapping is for a 128-bit AXI4-Stream bus.
Figure: TX Mapping
tx_axis_tvalid
When High, this signal indicates that there is valid data on the TX AXI bus.
tx_axis_tuser_ena0, tx_axis_tuser_ena1
These signals enable the transfer of data over the TX bus when asserted. Data transfer
has to be validated with the tvalid signal in order for a transfer to take place.
tx_axis_tuser_sop0, tx_axis_tuser_sop1
These signals indicate the start of an Ethernet frame in that cycle. Only one SOP is
permitted in a bus cycle. There is a separate SOP signal for each AXI segment.
tx_axis_tuser_eop0, tx_axis_tuser_eop1
These signals indicate the end of an Ethernet frame in that cycle. Only one EOP is
permitted in a bus cycle. There is a separate EOP signal for each AXI segment.
tx_axis_tuser_mty0[2:0], tx_axis_tuser_mty1[2:0]
These signals indicate which bytes of the corresponding segment are not used ("empty").
If tx_mtyin has a value of 0x0, there are no empty byte lanes, or in other words, all bits
of the data bus are valid.
tx_unfout
Not shown on the waveforms in the previous TX Waveform timing diagram is the
tx_unfout output indicator. When this signal is High, it indicates that there has not been
a sufficient data transfer and the Ethernet interface undergoes underflow. This must not
be allowed to occur. You must ensure that you transfer data whenever tx_axis_tready
is High until you reach the end of the Ethernet frame.
✎ Note: When this signal sampled as 1, you need to apply tx_reset/sys_reset to
recover the core from the underflow issue. tx_reset resets the TX path only and
sys_reset recovers the complete system.
tx_axis_user_err0, tx_axis_user_err1
This signal is used to indicate that a packet contains an error when it is sampled as a 1
and is 0 for all other transfers of the packet. This signal is sampled only in cycles when
tx_axis_tuser_ena and tx_axis_tuser_eop are sampled as 1. When this signal is
sampled as a 1, the last data word is replaced with the 802.3 Error Code control word
that guarantees the partner device receives the packet in error. If a packet is input with
this signal set to a 1, the FCS checking and reporting is disabled (only for that packet).
The 40G/50G IP Subsystem provides an option of a 256-bit AXI4-Stream packet interface for
operation at 40 Gb/s.
For transmit data, tx_axis_tdata[255:0], the port is logically divided into lane 0 to lane 31.
See the following table.
0 7:0
1 15:8
2 23:16
3 31:24
4 39:32
5 47:40
6 55:48
7 63:56
8 71:64
9 79:72
10 87:80
11 95:88
12 103:96
13 111:110
14 119:112
15 127:120
16 135:128
17 143:136
18 151:144
19 159:152
20 167:160
21 175:168
22 183:176
23 191:184
24 199:192
25 207:200
26 215:208
27 223:216
28 231:224
29 239:232
30 247:240
31 255:248
Normal Transmission
The timing of a normal frame transfer is shown in the following figure. When the client wants to
transmit a frame, it asserts the tx_axis_tvalid signal and places the data and control in
tx_axis_tdata and tx_axis_tkeep in the same clock cycle. When this data is accepted by
the core, indicated by tx_axis_tready being asserted, the client must provide the next cycle
of data. If tx_axis_tready is not asserted by the core, the client must hold the current valid
data value until it is. The end of the packet is indicated to the core by tx_axis_tlast
asserted for 1 cycle. The bits of tx_axis_tkeep are set appropriately to indicate the number of
valid bytes in the final data transfer. tx_axis_tuser is also asserted to indicate a bad packet.
After tx_axis_tlast is deasserted, any data and control is deemed invalid until
tx_axis_tvalid is next asserted.
Continuous data transfer on the transmit AXI4-Stream interface is possible, as the signal
tx_axis_tvalid can remain continuously High, with packet boundaries defined solely by
tx_axis_tlast asserted for the end of the Ethernet packet. However, the core can deassert
the tx_axis_tready acknowledgment signal to throttle the client data rate as required. See
the following figure.
The client data logic can update the AXI4-Stream interface with valid data while the core has
deasserted the tx_axis_tready acknowledgment signal. However, when valid is asserted
Aborting a Transmission
The aborted transfer of a packet on the client interface is called an underrun. This can happen
if a FIFO in the AXI Transmit client interface empties before a frame is completed.
This is indicated to the core in one of two ways.
✎ Note: In 256b Packet Interface mode, both the TX and RX AXI4-Stream interfaces are
synchronous to a single input clock, and rx_core_clk is typically driven by tx_clk_out.
For receive data, rx_axis_tdata[63:0], the port is logically divided into lane 0 to lane 7. See
the following table.
0 7:0
1 15:8
2 23:16
3 31:24
4 39:32
5 47:40
6 55:48
7 63:56
8 71:64
9 79:72
10 87:80
11 95:88
12 103:96
13 111:110
14 119:112
15 127:120
16 135:128
17 143:136
18 151:144
19 159:152
20 167:160
21 175:168
22 183:176
23 191:184
24 199:192
25 207:200
26 215:208
27 223:216
28 231:224
29 239:232
30 247:240
31 255:248
The timing of a normal inbound frame transfer is represented in following figure. The client
must be prepared to accept data at any time; there is no buffering within the core to allow for
latency in the receive client.
During frame reception, rx_axis_tvalid is asserted to indicate that valid frame data is being
transferred to the client on rx_axis_tdata. All bytes are always valid throughout the frame,
as indicated by all rx_axis_tkeep bits being set to 1, except during the final transfer of the
frame when rx_axis_tlast is asserted. During this final transfer of data for a frame,
rx_axis_tkeep bits indicate the final valid bytes of the frame using the mapping from above.
The valid bytes of the final transfer always lead out from rx_axis_tdata[7:0]
(rx_axis_tkeep[0]) because Ethernet frame data is continuous and is received least
significant byte first.
The rx_axis_tlast is asserted and rx_axis_tuser is deasserted, along with the final bytes
of the transfer, only after all the frame checks are completed. This is after the frame check
sequence (FCS) field has been received. The core asserts the rx_axis_tuser signal to
indicate that the frame was successfully received and that the frame should be analyzed by
the client. This is also the end of the packet signaled by rx_axis_tlast asserted for one
cycle.
The case of an unsuccessful frame reception (for example, a runt frame or a frame with an
incorrect FCS) is shown in the following figure. In this case the bad frame is received and the
signal rx_axis_tuser is asserted to the client at the end of the frame. It is the responsibility
of the client to drop the data already transferred for this frame.
The following conditions cause the assertion of rx_axis_tlast along with rx_axis_tuser =
1 signifying a bad frame.
1. These signals are available only in the 256-bit non-segmented AXI4-Stream Variant.
ctl_rx_enable I rx_serdes_clk
RX Enable. For normal operation, this
input must be set to 1. When this input
is set to 0, after the RX completes the
reception of the current packet (if any),
it stops receiving packets by keeping
the PCS from decoding incoming data.
In this mode, there are no statistics
reported and the AXI4-Stream
interface is idle.
ctl_rx_check_preamble I rx_serdes_clk
When asserted, this input causes the
Ethernet MAC to check the preamble
of the received frame.
ctl_rx_check_sfd I rx_serdes_clk
When asserted, this input causes the
Ethernet MAC to check the start of
ctl_rx_force_resync I rx_serdes_clk
RX force resynchronization input. This
signal is used to force the RX path to
reset, re-synchronize, and realign. A
value of 1 forces the reset operation. A
value of 0 allows normal operation.
✎ Note: This input should normally be
Low and should only be pulsed (1
cycle minimum pulse) to force
realignment.
CTL_RX_FORCE_RESYNC restarts
the synchronization state machine but
does not reset the GT logic. In most
cases when there is an RX failure, the
GT RX needs to be reset.
ctl_rx_delete_fcs I rx_serdes_clk
Enable FCS removal by the RX core. If
this bit is set to 0, the 40G/50G High
Speed Ethernet Subsystem does not
remove the FCS of the incoming
packet. If this bit is set to 1, the
40G/50G High Speed Ethernet
Subsystem deletes the FCS to the
received packet. FCS is not deleted for
packets that are 8 bytes long. This
input should only be changed while the
corresponding reset input is asserted.
ctl_rx_ignore_fcs I rx_serdes_clk
Enable FCS error checking at the
AXI4-Stream interface by the RX core.
If this bit is set to 0, a packet received
with an FCS error is sent with the
rx_errout pin asserted during the last
transfer (rx_eopout and rx_enaout
sampled 1). If this bit is set to 1, the
40G/50G High Speed Ethernet
Subsystem does not flag an FCS error
at the AXI4-Stream interface.
✎ Note: The statistics are reported as
if the packet is good. The
ctl_rx_max_packet_len[14:0] I rx_serdes_clk
Any packet longer than this value is
considered to be oversized. If a packet
has a size greater than this value, the
packet is truncated to this value and
the rx_errout signal is asserted along
with the rx_eopout signal. Packets less
than 16 bytes are dropped. The
allowed value for this bus can range
from 64 to 16,383.
ctl_rx_max_packet_len[14] is reserved
and must be set to 0.
ctl_rx_min_packet_len[7:0] I rx_serdes_clk
Any packet shorter than this value is
considered to be undersized. If a
packet has a size less than this value,
the rx_errout signal is asserted during
the rx_eopout asserted cycle. Packets
that are less than 16 bytes are
dropped.
✎ Note: This value should be greater
than or equal to 64B.
ctl_rx_vl_length_minus1[15:0] I rx_serdes_clk
Number of words in between PCS
Lane markers minus one. Default
value, as defined in IEEE Std 802.3-
2015, should be set to 16,383. This
input should only be changed while the
corresponding reset input is asserted.
✎ Note: When RS-FEC is enabled in
the 50G core configuration, this value
is set to 20479.
ctl_rx_vl_marker_id[VL_LANES- I rx_serdes_clk
These inputs set the PCS Lane
1:0][63:0] markers for each PCS lane. These
inputs should be set to the values as
defined in the IEEE Std 802.3-2015.
For IEEE 802.3 default values, see
Section 5.3 [ IEEE Standard for
Ethernet (IEEE Std 802.3-2015)]. This
stat_rx_framing_err_valid_[VL_LANES-
O rx_clk_out Valid indicator for
1:0] stat_rx_framing_err_[VL_LANES-1:0].
When one of these outputs is sampled
as a 1, the value on the corresponding
stat_rx_framing_err_[VL_LANES-1:0]
is valid.
stat_rx_test_pattern_mismatch[3|2|1|0:0]
O rx_clk_out Test pattern mismatch increment. A non zero
value in any cycle indicates how many
mismatches occurred for the test pattern in
the RX core. This output is only active when
ctl_rx_test_pattern is set to a 1. This output
can be used to generate MDIO register
3.43.15:0 as defined in Clause 82.3. This
output is pulsed for one clock cycle.
stat_rx_total_good_bytes[13:0]
O clk Increment for the total number of good bytes
received. This value is only non-zero when a
packet is received completely and contains
no errors.
stat_rx_packet_65_127_bytes
O clk Increment for good and bad packets
received that contain 65 to 127 bytes.
stat_rx_packet_128_255_bytes
O clk Increment for good and bad packets
received that contain 128 to 255 bytes.
stat_rx_packet_256_511_bytes
O clk Increment for good and bad packets
received that contain 256 to 511 bytes.
stat_rx_packet_512_1023_bytes
O clk Increment for good and bad packets
received that contain 512 to 1,023 bytes.
stat_rx_packet_1024_1518_bytes
O clk Increment for good and bad packets
received that contain 1,024 to 1,518 bytes.
stat_rx_packet_1519_1522_bytes
O clk Increment for good and bad packets
received that contain 1,519 to 1,522 bytes.
stat_rx_packet_1523_1548_bytes
O clk Increment for good and bad packets
received that contain 1,523 to 1,548 bytes.
stat_rx_packet_1549_2047_bytes
O clk Increment for good and bad packets
received that contain 1,549 to 2,047 bytes.
stat_rx_packet_2048_4095_bytes
O clk Increment for good and bad packets
received that contain 2,048 to 4,095 bytes.
stat_rx_packet_4096_8191_bytes
O clk Increment for good and bad packets
received that contain 4,096 to 8,191 bytes.
stat_rx_packet_8192_9215_bytes
O clk Increment for good and bad packets
received that contain 8,192 to 9,215 bytes.
stat_rx_packet_small[n:0] O clk Increment for all packets that are less than
64 bytes long. Packets that are less than 16
bytes are dropped.
stat_rx_packet_large O clk Increment for all packets that are more than
9,215 bytes long.
stat_tx_total_good_bytes[13:0]
O clk Increment for the total number of good bytes
transmitted. This value is only non-zero
when a packet is transmitted completely and
contains no errors.
stat_tx_packet_65_127_bytes
O clk Increment for good and bad packets
transmitted that contain 65 to 127 bytes.
stat_tx_packet_128_255_bytes
O clk Increment for good and bad packets
transmitted that contain 128 to 255 bytes.
stat_tx_total_good_bytes[13:0]
O clk Increment for the total number of good bytes
transmitted. This value is only non-zero
when a packet is transmitted completely and
contains no errors.
stat_tx_packet_65_127_bytes
O clk Increment for good and bad packets
transmitted that contain 65 to 127 bytes.
stat_tx_packet_128_255_bytes
O clk Increment for good and bad packets
transmitted that contain 128 to 255 bytes.
stat_tx_packet_256_511_bytes
O clk Increment for good and bad packets
transmitted that contain 256 to 511 bytes.
stat_tx_packet_512_1023_bytes
O clk Increment for good and bad packets
transmitted that contain 512 to 1,023 bytes.
stat_tx_packet_1024_1518_bytes
O clk Increment for good and bad packets
transmitted that contain 1,024 to 1,518
bytes.
stat_tx_packet_1519_1522_bytes
O clk Increment for good and bad packets
transmitted that contain 1,519 to 1,522
bytes.
stat_tx_packet_1523_1548_bytes
O clk Increment for good and bad packets
transmitted that contain 1,523 to 1,548
bytes.
stat_tx_packet_1549_2047_bytes
O clk Increment for good and bad packets
transmitted that contain 1,549 to 2,047
bytes.
stat_tx_packet_2048_4095_bytes
O clk Increment for good and bad packets
transmitted that contain 2,048 to 4,095
bytes.
stat_tx_packet_4096_8191_bytes
O clk Increment for good and bad packets
transmitted that contain 4,096 to 8,191
bytes.
stat_tx_packet_8192_9215_bytes
O clk Increment for good and bad packets
transmitted that contain 8,192 to 9,215
bytes.
stat_tx_packet_small O clk Increment for all packets that are less than
64 bytes long.
stat_tx_packet_large O clk Increment for all packets that are more than
9,215 bytes long.
ctl_rx_pause_enable[8:0]
I rx_serdes_clkRX pause enable signal. This input is used to
enable the processing of the pause quanta for
the corresponding priority.
✎ Note: This signal only affects the RX user
interface, not the pause processing logic.
ctl_tx_pause_enable[8:0]
I clk TX pause enable signal. This input is used to
enable the processing of the pause quanta for
the corresponding priority. This signal gates
transmission of pause packets.
ctl_rx_opcode_max_gcp[15:0]
I rx_serdes_clkMaximum global control opcode value.
ctl_rx_opcode_max_pcp[15:0]
I rx_serdes_clkMaximum priority control opcode value.
ctl_tx_pause_refresh_timer[8:0]
I clk These nine buses set the retransmission
[15:0] time of pause packets for each of the eight
priorities in priority-based pause operation
and the global pause operation. The value
for ctl_tx_pause_refresh_timer[8] is used
for global pause operation. All other
values are used for priority pause
operation.
The Auto-Negotiation function allows an Ethernet device to advertise the modes of operation it
possesses to another device at the remote end of a Backplane Ethernet link and to detect
corresponding operational modes the other device might be advertising. The objective of this
Auto-Negotiation function is to provide the means to exchange information between two
devices and to automatically configure them to take maximum advantage of their abilities. It
has the additional objective of supporting a digital signal detect to ensure that the device is
attached to a link partner rather than detecting a signal due to crosstalk. When Auto-
Negotiation is complete, the ability is reported according to the available modes of operation.
The following additional signals are used for the auto-negotiation function. These signals are
found at the *wrapper.v hierarchy.
ctl_an_ability_100gbase_kr4 I an_clk
ctl_an_ability_10gbase_kr I an_clk
ctl_an_ability_10gbase_kx4 I an_clk
ctl_an_ability_25gbase_krcr I an_clk
ctl_an_ability_25gbase_cr1 I an_clk
ctl_an_ability_25gbase_krcr_s I an_clk
ctl_an_ability_25gbase_kr1 I an_clk
ctl_an_ability_40gbase_cr4 I an_clk
ctl_an_ability_40gbase_kr4 I an_clk
ctl_an_ability_50gbase_cr2 I an_clk
ctl_an_ability_50gbase_kr2 I an_clk
ctl_lt_polynomial_select I an_clk
ctl_an_ability_2_5gbase_kx I an_clk
ctl_an_ability_5gbase_kr I an_clk
ctl_an_ability_50gbase_krcr I an_clk
ctl_an_ability_200gbase_kr4cr4 I an_clk
ctl_an_ability_100gbase_kr2cr2 I an_clk
stat_an_link_cntl_1000base_kx[1:0]
O an_clk
stat_an_link_cntl_100gbase_cr10[1:0]
O an_clk
stat_an_link_cntl_100gbase_cr4[1:0]
O an_clk
stat_an_link_cntl_100gbase_kp4[1:0]
O an_clk
Link Control outputs from the auto-
stat_an_link_cntl_100gbase_kr4[1:0]
O an_clk negotiation controller for the various
Ethernet protocols. Settings are as
stat_an_link_cntl_10gbase_kr[1:0]O an_clk
follows:
stat_an_link_cntl_10gbase_kx4[1:0]
O an_clk
00: DISABLE; PCS is
stat_an_link_cntl_25gbase_krcr[1:0]
O an_clk disconnected;
01: SCAN_FOR_CARRIER; RX
stat_an_link_cntl_25gbase_cr1[1:0]
O an_clk
is connected to PCS;
stat_an_link_cntl_25gbase_krcr_s[1:0]
O an_clk 11: ENABLE; PCS is connected
for mission mode operation.
stat_an_link_cntl_25gbase_kr1[1:0]
O an_clk 10: not used
stat_an_link_cntl_40gbase_cr4[1:0]
O an_clk
stat_an_link_cntl_40gbase_kr4[1:0]
O an_clk
stat_an_link_cntl_50gbase_cr2[1:0]
O an_clk
stat_an_link_cntl_50gbase_kr2[1:0]
O an_clk
stat_an_lp_ability_10gbase_kr O an_clk
stat_an_lp_ability_10gbase_kx4 O an_clk
stat_an_lp_ability_25gbase_krcr O an_clk
stat_an_lp_ability_25gbase_krcr_s
O an_clk
stat_an_lp_ability_40gbase_cr4 O an_clk
stat_an_lp_ability_40gbase_kr4 O an_clk
stat_an_lp_fec_25g_baser_request
O an_clk This signal indicates the advertised
value of the clause 74 FEC request
bit in the receive link codeword on the
corresponding 25 Gb/s PMD interface
from the link partner. It becomes valid
when the output signal
stat_an_lp_ability_valid is asserted.
stat_fec_inc_cant_correct_count[3:0]
O rx_serdes_clkLogical indication of uncorrectable
errors. If an uncorrectable packet is
encountered, this
output signal cycles once. The signal
is High
for a minimum of 16 clocks and goes
Low for a minimum of 16 clocks.
There is one per lane.
stat_an_lp_ability_extended_fec[1:0]
O an_clk This output indicates the extended
FEC abilities as defined in Schedule
3.
The following additional signals are used for the link-training function. These signals are found
at the *wrapper.v hierarchy.
stat_lt_stat_m1_from_rx0[1:0]
O rx_serdes_clkThis 2-bit field indicates the update status
bits for the k-1 coefficient, as received
from the link partner in the status block.
Overview
The following figure as per IEEE P802.3 illustrates the position of the AN function in the OSI
reference model.
The Auto-Negotiation IP core implements the requirements as specified in Clause 73, IEEE
Std 802.3-2015, including those amendments specified in IEEE P802.3by and Schedule 3 of
the 25 GE Consortium.
The functions of the AN IP core are explicitly listed in clause 73, especially in Figure 73-11,
Arbitration state diagram, of section 73.10.4, State diagrams.
During normal mission mode operation, with link control outputs set to (bin)11, the bit
operating frequency of the SerDes input and output is typically 10.3125 or 25.78125 Gb/s.
However, the Dual Manchester Encoding (DME) bit rate used on the lane during auto-
negotiation is quite a bit different than the mission mode operation.
To accommodate this requirement, the AN IP core uses over-sampling and over-driving to
match the 156.25 Mb/s auto-negotiation speed (DME clock frequency 312.5 MHz) with the
mission mode 10.3125 or 25.78125 Gb/s physical lane speed.
autoneg_enable
When the autoneg_enable input signal is set to a 1, auto-negotiation begins
automatically at power-up, or if the carrier signal is lost, or if the input
restart_negotiation signal is cycled from a 0 to a 1. All of the 'ability' input signals
and the two input signals PAUSE and ASM_DIR are tied Low or High to indicate the
capability of the hardware. The nonce_seed[7:0] input must be set to a unique value for
every instance of the auto-negotiator. The AN IP does not function if the nonce_seed is
set to 0. This is important to guarantee that no deadlocks occur at power-up. If two link
partners connected together attempt to auto-negotiate with their nonce_seed[7:0]
inputs set to the same value, the auto-negotiation fails continuously. The pseudo_sel
input is an arbitrary selection that is used to select the polynomial of the random bit
generator in bit position 49 of the DME pages used during auto-negotiation. Any selection
on this input is valid and does not result in any adverse behavior.
Link Control
When auto-negotiation has begun, the various 'link control' signals are activated,
depending on the disposition of the corresponding 'Ability' inputs for those links.
Subsequently, the corresponding 'link status' signals are monitored by the AN IP
hardware for an indication of the state of the various links that can be connected. If
particular links are unused, the corresponding link control outputs are unconnected, and
the corresponding link-status inputs should be tied Low. During this time, the AN IP
hardware sets up a communication link with the link partner and uses this link to
negotiate the capabilities of the connection.
Autoneg Complete
When Auto-Negotiation is complete, the autoneg_complete output signal is asserted. In
addition to this, the output signal an_fec_enable is asserted if the Forward Error
Correction hardware is to be used; the output signal tx_pause_en is asserted if the
transmitter hardware is allowed to generate PAUSE control packets, the output signal
rx_pause_en is asserted if the receiver hardware is allowed to detect PAUSE control
packets, and the output link control of the selected link is set to its mission mode value
(bin)11.
‼ Important: The autoneg complete signal is not asserted until rx_status is received
from the PCS. That means that, where link training is included, the autoneg_complete
output signal is not asserted until after link training has completed and rx_status is High.
Link Training (LT) is performed after auto-negotiation (AN) converges to a backplane or copper
technology. Technology selection can also be the result of a manual entry or parallel detection.
Transmit
The LT transmit block constructs a 4,384-bit frame that contains a frame delimiter, control
channel, and link training sequence. It is formatted as follows:
It is recommended that the control channel bits not be changed by the link training algorithm
while the transmit state machine is in the process of transmitting them or they can be received
incorrectly, possibly resulting in a DME error. The time begins when tx_SOF is asserted and
ends at least 288 bit times later, or approximately 30 ns.
✎ Note: Although the coefficient and status contain 128 bit times at the line rate, the actual
signaling rate for these two fields is reduced by a factor of 8. Therefore, the DME clock rate is
one quarter of the line rate.
Frame Marker
The frame marker consists of 16 consecutive 1s followed by 16 consecutive 0s. This
pattern is not repeated in the remainder of the frame.
The functions of each bit are defined in IEEE 802.3 Clause 72. Their purpose is to
communicate the adjustments of the transmit equalizer during the process of link training.
The corresponding signal names are defined in Port Descriptions.
Training Sequence
The training sequence consists of a Pseudo Random Bit Sequence (PRBS) of 4,094 bits
followed by two zeros, for a total of 4,096 bits. The PRBS is transmitted at the line rate of
10.3125 or 25.78125 Gbps. The PRBS generator receives an 11-bit seed from an
external source. Seed must be non-zero. Subsequent to the initial seed being loaded, the
PRBS generator continues to run with no further intervention being required.
The PRBS generator itself is implemented with a circuit that corresponds to the following
polynomial:
G(x)= 1 + x9 + x11
Receive
The receive block implements the frame alignment state diagram illustrated in IEEE 802.3
Clause 72.
Received Data
The receiver outputs the control channel with the bit definitions previously defined in the
previous two tables and signal names defined in Port Descriptions. If a DME_error has
occurred during the reception of a particular DME frame, the control channel outputs are
not updated but retain the value of the last received good DME frame and are updated
when the next good DME frame is received.
Related Information
Transmit
Port Descriptions
No FEC
Clause 74 FEC (shortened cyclic code (2112, 2080))
Clause 91 FEC (Reed-Solomon (528,514))
The FEC mode is communicated to the link partner during the auto-negotiation phase.
PCS Variant
A PCS-only variant of the 40G/50G Ethernet IP subsystem can be generated from the same
wizard.
Features
Block Diagram
The following figure is a block diagram of the 40/50 Gb/s PCS-only variant.
The following table shows the 40G/50G PCS IP core ports. These are the ports when the
PCS-only option is provided. There are no FCS functions and no AXI4-Stream-related ports.
The PCS does not contain the Pause and Flow Control ports. The system interface is
XLGMII/50GMII instead of the AXI4-Stream.
These signals are found at the *wrapper.v hierarchy. Refer to PCS Clocking for clock domain
definitions.
Transceiver I/O
ctl_rx_vl_length_minus1[15:0]
I static Number of words in between PCS Lane
markers minus one for RX. Default value,
as defined in the IEEE 802.3, should be set
to 16,383.
This input should only be changed while the
corresponding reset input is asserted.
✎ Note: When RS-FEC is enabled in the
50G core configuration, this value is set to
20479.
ctl_tx_vl_length_minus1[15:0]
I static Number of words in between PCS Lane
markers minus one for TX. Default value, as
defined in the IEEE 802.3, should be set to
16,383.
This input should only be changed while the
corresponding reset input is asserted.
✎ Note: When RS-FEC is enabled in the
50G core configuration, this value is set to
20479.
Testability
In addition to the local loopback available at the PMA, the 40G/50G PCS provides test pattern
and remote loopback functions as illustrated in the following figure.
When enabled, the transmitted test pattern is continuous idle characters. The idle characters
are scrambled.
PCS Clocking
The 40G/50G High Speed Ethernet Subsystem PCS uses separate RX and TX clock domains
with RX and TX comprised of three clock domains each as illustrated in the following figure.
These clocks drive logic for the XLGMII/50GMII interfaces. The required clock frequency is
determined by the Media Independent Interface (MII) bus width and the data rate. For
example, for a 50GMII interface (50 Gb/s) and a data bus width of 128 bits, the required clock
frequency is 50e9/128 = 390.625 MHz. For 40G the formula is 40e9/128 = 312.5 MHz. This
clock frequency is determined according to the IEEE Standard for Ethernet (IEEE Std 802.3-
2015) specification.
SerDes Clocks
RX
Each SerDes lane has its own recovered clock. This clock is used for all of the logic for
that SerDes lane. The 40G/50G High Speed Ethernet Subsystem synchronizes the
received data from all of the SerDes to the RX core clock domains. There is one clock
per SerDes lane. The SerDes clock frequency is equal to the data rate divided by the
SerDes width. For example, at a data rate of 25.78125 Gb/s per lane and a 66-bit
SerDes, the clock frequency is 25.78125e9/66=390.625 MHz.
TX
The TX SerDes domain is associated with the TX lane logic. Both TX transceivers must
be clocked with the same frequency. The frequency is calculated in the same way as
documented in RX.
AXI4-Lite Ports
The following figure describes the port list for the AXI processor interface.
Base Pages
Configuration Registers
The configuration space provides software with the ability to configure the IP core for various
use cases. Certain features are optional (such as Auto-Negotiation, Link Training, and Flow
Control), in which case the applicable registers are considered RESERVED.
0x0044 CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG1:
Only in
0044 MAC+PCS
variant
0x0048 CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG2:
Only in
0048 MAC+PCS
variant
0x004C CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG3:
Only in
004C MAC+PCS
variant
0x0050 CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG4:
Only in
0050 MAC+PCS
variant
0x0054 CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG5:
Only in
0054 MAC+PCS
variant
0x0058 CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG1:
Only in
0058 MAC+PCS
variant
0x005C CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG2:
Only in
005C MAC+PCS
variant
0x0060 CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG3:
Only in
0060 MAC+PCS
variant
0x0064 CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG4:
Only in
0064 MAC+PCS
variant
0x0068 CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG5:
Only in
0068 MAC+PCS
variant
0x006C CONFIGURATION_TX_FLOW_CONTROL_PPP_ETYPE_OP_REG:
Only in
006C MAC+PCS
variant
0x0070 CONFIGURATION_TX_FLOW_CONTROL_GPP_ETYPE_OP_REG:
Only in
0070 MAC+PCS
variant
0x0074 CONFIGURATION_TX_FLOW_CONTROL_GPP_DA_REG_LSB:
Only in
0074 MAC+PCS
variant
0x0078 CONFIGURATION_TX_FLOW_CONTROL_GPP_DA_REG_MSB:
Only in
0078 MAC+PCS
variant
0x007C CONFIGURATION_TX_FLOW_CONTROL_GPP_SA_REG_LSB:
Only in
007C MAC+PCS
variant
0x0080 CONFIGURATION_TX_FLOW_CONTROL_GPP_SA_REG_MSB:
Only in
0080 MAC+PCS
variant
0x0084 CONFIGURATION_TX_FLOW_CONTROL_PPP_DA_REG_LSB:
Only in
0084 MAC+PCS
variant
0x0088 CONFIGURATION_TX_FLOW_CONTROL_PPP_DA_REG_MSB:
Only in
0088 MAC+PCS
variant
0x008C CONFIGURATION_TX_FLOW_CONTROL_PPP_SA_REG_LSB:
Only in
008C MAC+PCS
variant
0x0090 CONFIGURATION_TX_FLOW_CONTROL_PPP_SA_REG_MSB:
Only in
0090 MAC+PCS
variant
0x009C CONFIGURATION_RX_FLOW_CONTROL_PPP_ETYPE_OP_REG:
Only in
009C MAC+PCS
variant
0x00A0 CONFIGURATION_RX_FLOW_CONTROL_GPP_ETYPE_OP_REG:
Only in
00A0 MAC+PCS
variant
0x00A4 CONFIGURATION_RX_FLOW_CONTROL_GCP_PCP_TYPE_REG:
Only in
00A4 MAC+PCS
variant
0x00A8 CONFIGURATION_RX_FLOW_CONTROL_PCP_OP_REG:Only in
00A8 MAC+PCS
variant
0x00AC CONFIGURATION_RX_FLOW_CONTROL_GCP_OP_REG:Only in
00AC MAC+PCS
variant
0x00B0 CONFIGURATION_RX_FLOW_CONTROL_DA_REG1_LSB:
Only in
00B0 MAC+PCS
variant
0x00B4 CONFIGURATION_RX_FLOW_CONTROL_DA_REG1_MSB:
Only in
00B4 MAC+PCS
variant
0x00B8 CONFIGURATION_RX_FLOW_CONTROL_DA_REG2_LSB:
Only in
00B8 MAC+PCS
variant
0x00BC CONFIGURATION_RX_FLOW_CONTROL_DA_REG2_MSB:
Only in
00BC MAC+PCS
variant
0x00C0 CONFIGURATION_RX_FLOW_CONTROL_SA_REG1_LSB:Only in
00C0 MAC+PCS
variant
0x00C4 CONFIGURATION_RX_FLOW_CONTROL_SA_REG1_MSB:
Only in
00C4 MAC+PCS
variant
Status Registers
The status registers provide an indication of the health of the system. These registers are
read-only and a read operation clears the register.
Status registers are cleared according to the following conditions>
0x0400
STAT_TX_STATUS_REG1: 0400
0x0404
STAT_RX_STATUS_REG1: 0404
0x0408
STAT_STATUS_REG1: 0408
0x040C
STAT_RX_BLOCK_LOCK_REG: 040C
0x0410
STAT_RX_LANE_SYNC_REG: 0410
0x0414
STAT_RX_LANE_SYNC_ERR_REG: 0414
0x0418
STAT_RX_AM_ERR_REG: 0418
0x041C
STAT_RX_AM_LEN_ERR_REG: 041C
0x0420
STAT_RX_AM_REPEAT_ERR_REG: 0420
0x0424
STAT_RX_LANE_DEMUXED: 0424
0x0428
STAT_RX_PCS_LANE_NUM_REG1: 0428
0x043C
STAT_RX_RSFEC_STATUS_REG: 043C
0x0440
STAT_RX_RSFEC_LANE_FILL_REG1: 0440
0x0448
STAT_RX_FEC_STATUS_REG: 0448
0x044C
STAT_TX_RSFEC_STATUS_REG: 044C
0x0450
STAT_TX_FLOW_CONTROL_REG1: 0450 Only in MAC+PCS variant
0x0454
STAT_RX_FLOW_CONTROL_REG1: 0454 Only in MAC+PCS variant
0x0458
STAT_AN_STATUS: 0458
0x045C
STAT_AN_ABILITY: 045C
0x0460
STAT_AN_LINK_CTL: 0460
0x0464
STAT_LT_STATUS_REG1: 0464
0x0468
STAT_LT_STATUS_REG2: 0468
0x046C
STAT_LT_STATUS_REG3: 046C
0x0470
STAT_LT_STATUS_REG4: 0470
0x0474
STAT_LT_COEFFICIENT0_REG: 0474
0x0478
STAT_LT_COEFFICIENT1_REG: 0478
0x047C
STAT_CORE_SPEED_REG: 047C
0x04A0
STAT_GT_WIZ_REG: 04A0
0x9F0
STAT_AN_LINK_CTL2: 09F0
Statistics Counters
The statistics counters provide histograms of the classification of traffic and error counts.
These counters can be read either by a 1 on pm_tick or by writing a 1 to TICK_REG,
depending on the value of MODE_REG[30](that is tick_reg_mode_sel).
The counters employ an internal accumulator. A write to the TICK_REG register causes the
accumulated counts to be pushed to the readable STAT_*_MSB/LSB registers and
simultaneously clear the accumulators. Next, the STAT_*_MSB/LSB registers can be read. In
this way all values stored in the statistics counters represent a snapshot over the same time-
interval.
✎ Note: These readable STAT_*_MSB/LSB registers are not resettable. This can result in
unknown data being present after reset but prior to a TICK_REG write.
The STAT_CYCLE_COUNT_MSB/LSB register contains a count of the number of RX core
clock cycles between TICK_REG register writes. This allows for easy time-interval based
statistics.
The counters have a default width of 48b. The counters saturate to 1s. The values in the
counters are held until the next write to the TICK_REG register.
The first of the pair of addresses shown for the counters are the addresses of the LSB register,
or bits 31:0 of the count. The MSB bits 47:32 of the counter are located at + 0x4 from the LSB.
Statistic counter registers are cleared according to the following conditions.
0x0670 STAT_RX_RSFEC_CORRECTED_CW_INC_LSB:
0670
0x0674 STAT_RX_RSFEC_CORRECTED_CW_INC_MSB:
0674
0x0678 STAT_RX_RSFEC_UNCORRECTED_CW_INC_LSB:
0678
0x067C STAT_RX_RSFEC_UNCORRECTED_CW_INC_MSB:
067C
0x0680 STAT_RX_RSFEC_ERR_COUNT0_INC_LSB:
0680
0x0684 STAT_RX_RSFEC_ERR_COUNT0_INC_MSB:
0684
0x0688 STAT_RX_RSFEC_ERR_COUNT1_INC_LSB:
0688
0x068C STAT_RX_RSFEC_ERR_COUNT1_INC_LSB:
068C
0x0928 STAT_FEC_INC_CANT_CORRECT_COUNT_LSB:
0928
0x092C STAT_FEC_INC_CANT_CORRECT_COUNT_MSB:
092C
Register Definitions
Configuration Registers
This section contains descriptions of the configuration registers. In the cases where the
features described in the bit fields are not present in the IP core, the bit field reverts to
RESERVED. Reserved fields in the configuration registers do not accept any written value,
and always return a 0 when read. Registers or bit fields within registers can be accessed for
read-write (RW), write-only (WO), or read-only (RO). Default values shown are decimal values
and take effect after s_axi_aresetn.
A description of each signal is found in the port list section of this document.
0 0 RW ctl_gt_reset_all
✎ Note: This is a clear on write register.
1 0 RW ctl_gt_rx_reset
2 0 RW ctl_gt_tx_reset
RESET_REG: 0004
This is a clear on write register. This is available when the Include ANLT Logic option selected
in the Configuration tab.
1:0 0 RW rx_serdes_reset
28 0 RW ctl_an_reset
29 0 RW tx_serdes_reset
30 0 RW rx_reset
31 0 RW tx_reset
MODE_REG: 0008
0 1 RW en_wr_slverr_indication
1 1 RW en_rd_slverr_indication
30 1 RW tick_reg_mode_sel
1. The 0th and 1st bit of mode_reg register provides the flexibility to disable or enable
the slv error. The user can write '0' to these bits to suppress the reporting of slv error.
CONFIGURATION_TX_REG1: 000C
0 1 RW ctl_tx_enable 1
1 1 RW ctl_tx_fcs_ins_enable 1
2 0 RW ctl_tx_ignore_fcs 1
3 0 RW ctl_tx_send_lfi 1
4 0 RW ctl_tx_send_rfi 1
5 0 RW ctl_tx_send_idle 1
13:10 12 RW ctl_tx_ipg_value 1
14 0 RW ctl_tx_test_pattern
18 0 RW ctl_tx_custom_preamble_enable 1
CONFIGURATION_RX_REG1: 0014
0 1 RW ctl_rx_enable 1
1 1 RW ctl_rx_delete_fcs 1
2 0 RW ctl_rx_ignore_fcs 1
3 0 RW ctl_rx_process_lfi 1
4 1 RW ctl_rx_check_sfd 1
5 1 RW ctl_rx_check_preamble 1
6 0 RW ctl_rx_force_resync 1
7 0 RW ctl_rx_test_pattern
18 0 RW ctl_rx_custom_preamble_enable 1
CONFIGURATION_RX_MTU: 0018
7:0 64 RW ctl_rx_min_packet_len
CONFIGURATION_VL_LENGTH_REG: 001C
TICK_REG: 0020
0 0 WO tick_reg
CONFIGURATION_REVISION_REG: 0024
7:0 3 RO major_rev
15:8 3 RO minor_rev
31:24 0 RO patch_rev
CONFIGURATION_1588_REG: 0038
0 0 RW ctl_tx_ptp_1step_enable
1 0 RW ctl_tx_ptp_vlane_adjust_mode
2 0 RW ctl_ptp_transpclk_mode
26:16 0 RW ctl_tx_ptp_latency_adjust
CONFIGURATION_TX_FLOW_CONTROL_REG1: 0040
8:0 0 RW ctl_tx_pause_enable
CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG1: 0044
15:0 00 RW ctl_tx_pause_refresh_timer0
31:16 0 RW ctl_tx_pause_refresh_timer1
15:0 0 RW ctl_tx_pause_refresh_timer2
31:16 0 RW ctl_tx_pause_refresh_timer3
CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG3: 004C
15:0 0 RW ctl_tx_pause_refresh_timer4
31:16 0 RW ctl_tx_pause_refresh_timer5
CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG4: 0050
15:0 0 RW ctl_tx_pause_refresh_timer6
31:16 0 RW ctl_tx_pause_refresh_timer7
CONFIGURATION_TX_FLOW_CONTROL_REFRESH_REG5: 0054
15:0 0 RW ctl_tx_pause_refresh_timer8
CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG1: 0058
15:0 00 RW ctl_tx_pause_quanta0
31:16 0 RW ctl_tx_pause_quanta1
15:0 00 RW ctl_tx_pause_quanta2
31:16 0 RW ctl_tx_pause_quanta3
CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG3: 0060
15:0 00 RW ctl_tx_pause_quanta4
31:16 0 RW ctl_tx_pause_quanta5
CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG4: 0064
15:0 00 RW ctl_tx_pause_quanta6
31:16 0 RW ctl_tx_pause_quanta7
CONFIGURATION_TX_FLOW_CONTROL_QUANTA_REG5: 0068
15:0 00 RW ctl_tx_pause_quanta8
CONFIGURATION_TX_FLOW_CONTROL_PPP_ETYPE_OP_REG: 006C
31:16 1 RW ctl_tx_opcode_gpp
CONFIGURATION_TX_FLOW_CONTROL_GPP_DA_REG_LSB: 0074
31:0 0 RW ctl_tx_da_gpp[31:0]
CONFIGURATION_TX_FLOW_CONTROL_GPP_DA_REG_MSB: 0078
15:0 0 RW ctl_tx_da_gpp[47:32]
CONFIGURATION_TX_FLOW_CONTROL_GPP_SA_REG_LSB: 007C
31:0 0 RW ctl_tx_sa_gpp[31:0]
CONFIGURATION_TX_FLOW_CONTROL_GPP_SA_REG_MSB: 0080
15:0 0 RW ctl_tx_sa_gpp[47:32]
CONFIGURATION_TX_FLOW_CONTROL_PPP_DA_REG_LSB: 0084
31:0 0 RW ctl_tx_da_ppp[31:0]
CONFIGURATION_TX_FLOW_CONTROL_PPP_DA_REG_MSB: 0088
15:0 0 RW ctl_tx_da_ppp[47:32]
CONFIGURATION_TX_FLOW_CONTROL_PPP_SA_REG_LSB: 008C
31:0 0 RW ctl_tx_sa_ppp[31:0]
CONFIGURATION_TX_FLOW_CONTROL_PPP_SA_REG_MSB: 0090
15:0 0 RW ctl_tx_da_ppp[47:32]
CONFIGURATION_RX_FLOW_CONTROL_REG1: 0094
8:0 0 RW ctl_rx_pause_enable
9 0 RW ctl_rx_forward_control
10 0 RW ctl_rx_enable_gcp
11 0 RW ctl_rx_enable_pcp
12 0 RW ctl_rx_enable_gpp
13 0 RW ctl_rx_enable_ppp
14 0 RW ctl_rx_check_ack
0 0 RW ctl_rx_check_mcast_gcp
1 0 RW ctl_rx_check_ucast_gcp
2 0 RW ctl_rx_check_sa_gcp
3 0 RW ctl_rx_check_etype_gcp
4 0 RW ctl_rx_check_opcode_gcp
5 0 RW ctl_rx_check_mcast_pcp
6 0 RW ctl_rx_check_ucast_pcp
7 0 RW ctl_rx_check_sa_pcp
8 0 RW ctl_rx_check_etype_pcp
9 0 RW ctl_rx_check_opcode_pcp
10 0 RW ctl_rx_check_mcast_gpp
11 0 RW ctl_rx_check_ucast_gpp
12 0 RW ctl_rx_check_sa_gpp
13 0 RW ctl_rx_check_etype_gpp
14 0 RW ctl_rx_check_opcode_gpp
15 0 RW ctl_rx_check_mcast_ppp
16 0 RW ctl_rx_check_ucast_ppp
17 0 RW ctl_rx_check_sa_ppp
18 0 RW ctl_rx_check_etype_ppp
19 0 RW ctl_rx_check_opcode_ppp
CONFIGURATION_RX_FLOW_CONTROL_PPP_ETYPE_OP_REG: 009C
CONFIGURATION_RX_FLOW_CONTROL_GPP_ETYPE_OP_REG: 00A0
31:16 1 RW ctl_rx_opcode_gpp
CONFIGURATION_RX_FLOW_CONTROL_GCP_PCP_TYPE_REG: 00A4
CONFIGURATION_RX_FLOW_CONTROL_PCP_OP_REG: 00A8
CONFIGURATION_RX_FLOW_CONTROL_GCP_OP_REG: 00AC
15:0 1 RW ctl_rx_opcode_min_gcp
31:16 6 RW ctl_rx_opcode_max_gcp
31:0 0 RW ctl_rx_pause_da_ucast[31:0]
CONFIGURATION_RX_FLOW_CONTROL_DA_REG1_MSB: 00B4
15:0 0 RW ctl_rx_pause_da_ucast[47:32]
CONFIGURATION_RX_FLOW_CONTROL_DA_REG2_LSB: 00B8
31:0 0 RW ctl_rx_pause_da_mcast[31:0]
CONFIGURATION_RX_FLOW_CONTROL_DA_REG2_MSB: 00BC
15:0 0 RW ctl_rx_pause_da_mcast[47:32]
CONFIGURATION_RX_FLOW_CONTROL_SA_REG1_LSB: 00C0
31:0 0 RW ctl_rx_pause_sa[31:0]
CONFIGURATION_RX_FLOW_CONTROL_SA_REG1_MSB: 00C4
15:0 0 RW ctl_rx_pause_sa[47:32]
CONFIGURATION_RSFEC_REG: 00D0
0 0 RW ctl_rsfec_enable
2 0 RW ctl_rx_rsfec_enable_indication
3 0 RW ctl_rx_rsfec_enable_correction
5 0 RW ctl_rsfec_ieee_error_indication_mode
CONFIGURATION_FEC_REG: 00D4
0 0 RW ctl_fec_rx_enable
1 0 RW ctl_fec_tx_enable
2 0 RW ctl_fec_enable_error_to_pcs
CONFIGURATION_AN_CONTROL_REG1: 00E0
0 0 RW ctl_autoneg_enable
1 1 RW ctl_autoneg_bypass 1
9:2 0 RW ctl_an_nonce_seed
10 0 RW ctl_an_pseudo_sel
11 0 RW ctl_restart_negotiation
12 0 RW ctl_an_local_fault
CONFIGURATION_AN_CONTROL_REG2: 00E4
0 0 RW ctl_an_pause
1 1 RW ctl_an_asmdir
16 0 RW ctl_an_fec_10g_request
17 0 RW ctl_an_fec_ability_override
18 0 RW ctl_an_cl91_fec_request
19 0 RW ctl_an_cl91_fec_ability
20 0 RW ctl_an_fec_25g_rs_request
21 0 RW ctl_an_fec_25g_baser_request
CONFIGURATION_AN_ABILITY: 00F8
0 0 RW ctl_an_ability_1000base_kx
1 0 RW ctl_an_ability_10gbase_kx4
2 0 RW ctl_an_ability_10gbase_kr
3 0 RW ctl_an_ability_40gbase_kr4
4 0 RW ctl_an_ability_40gbase_cr4
5 0 RW ctl_an_ability_100gbase_cr10
6 0 RW ctl_an_ability_100gbase_kp4
7 0 RW ctl_an_ability_100gbase_kr4
8 0 RW ctl_an_ability_100gbase_cr4
9 0 RW ctl_an_ability_25gbase_krcr_s
10 0 RW ctl_an_ability_25gbase_krcr
11 0 RW ctl_an_ability_2_5gbase_kx
12 0 RW ctl_an_ability_5gbase_kr
13 0 RW ctl_an_ability_50gbase_krcr
14 0 RW ctl_an_ability_100gbase_kr2cr2
15 0 RW ctl_an_ability_200gbase_kr4cr4
16 0 RW ctl_an_ability_25gbase_kr1
17 0 RW ctl_an_ability_25gbase_cr1
18 0 RW ctl_an_ability_50gbase_kr2
19 0 RW ctl_an_ability_50gbase_cr2
CONFIGURATION_LT_CONTROL_REG1: 0100
0 0 RW ctl_lt_training_enable
1 0 RW ctl_lt_restart_training
CONFIGURATION_LT_TRAINED_REG: 0104
3:0 0 RW ctl_lt_rx_trained
CONFIGURATION_LT_PRESET_REG: 0108
3:0 0 RW ctl_lt_preset_to_tx
CONFIGURATION_LT_INIT_REG: 010C
3:0 0 RW ctl_lt_initialize_to_tx
CONFIGURATION_LT_SEED_REG0: 0110
10:0 0 RW ctl_lt_pseudo_seed0
26:16 0 RW ctl_lt_pseudo_seed1
CONFIGURATION_LT_SEED_REG1: 0114
10:0 0 RW ctl_lt_pseudo_seed2
26:16 0 RW ctl_lt_pseudo_seed3
CONFIGURATION_LT_COEFFICIENT_REG0: 0130
1:0 0 RW ctl_lt_k_p1_to_tx0
3:2 0 RW ctl_lt_k0_to_tx0
5:4 0 RW ctl_lt_k_m1_to_tx0
7:6 0 RW ctl_lt_stat_p1_to_tx0
9:8 0 RW ctl_lt_stat0_to_tx0
11:10 0 RW ctl_lt_stat_m1_to_tx0
17:16 0 RW ctl_lt_k_p1_to_tx1
19:18 0 RW ctl_lt_k0_to_tx1
21:20 0 RW ctl_lt_k_m1_to_tx1
23:22 0 RW ctl_lt_stat_p1_to_tx1
25:24 0 RW ctl_lt_stat0_to_tx1
27:26 0 RW ctl_lt_stat_m1_to_tx1
CONFIGURATION_LT_COEFFICIENT_REG1: 0134
1:0 0 RW ctl_lt_k_p1_to_tx2
3:2 0 RW ctl_lt_k0_to_tx2
5:4 0 RW ctl_lt_k_m1_to_tx2
7:6 0 RW ctl_lt_stat_p1_to_tx2
9:8 0 RW ctl_lt_stat0_to_tx2
11:10 0 RW ctl_lt_stat_m1_to_tx2
17:16 0 RW ctl_lt_k_p1_to_tx3
19:18 0 RW ctl_lt_k0_to_tx3
21:20 0 RW ctl_lt_k_m1_to_tx3
23:22 0 RW ctl_lt_stat_p1_to_tx3
25:24 0 RW ctl_lt_stat0_to_tx3
27:26 0 RW ctl_lt_stat_m1_to_tx3
USER_REG_0: 0138
31:0 0 RW user_reg0
SWITCH_CORE_SPEED_REG: 013C
0 0 RW axi_ctl_core_mode_switch
GT_WIZ_CONTROL_REG: 0154
Table: GT_WIZ_CONTROL_REG
20 1'b0 RW gtwiz_rxcdrhold
Status Registers
The following tables describe the status registers for this Ethernet IP core.
Some bits are sticky, that is, latching their value High or Low once set. This is indicated by the
type LH (latched High) or LL (latched Low).
0 0 RO LH stat_tx_local_fault
For Runtime Switch mode only. A write 1 enables the mode switch between 40G and 50G.
This is a clear on the write register. This is an input to the trans debug module that performs
the GT DRP operations.
STAT_RX_STATUS_REG1: 0404
0 1 RO LL stat_rx_status
1 1 RO LL stat_rx_aligned
2 0 RO LH stat_rx_misaligned
3 0 RO LH stat_rx_aligned_err
4 0 RO LH stat_rx_hi_ber
5 0 RO LH stat_rx_remote_fault 1
6 0 RO LH stat_rx_local_fault
7 0 RO LH stat_rx_internal_local_fault 1
8 0 RO LH stat_rx_received_local_fault 1
9 0 RO LH stat_rx_bad_preamble 1
10 0 RO LH stat_rx_bad_sfd 1
11 0 RO LH stat_rx_got_signal_os 1
0 0 RO LL stat_rx_status 3
1 0 RO LL stat_rx_aligned 2
2 0 RO LH stat_rx_misaligned 2
3 0 RO LH stat_rx_aligned_err 1
4 0 RO LH stat_rx_hi_ber 1
5 0 RO LH stat_rx_remote_fault 3
16 0 RO LH stat_rx_local_fault
STAT_RX_BLOCK_LOCK_REG: 040C
3:0 1 RO LL stat_rx_block_lock
STAT_RX_LANE_SYNC_REG: 0410
3:0 1 RO LL stat_rx_synced
STAT_RX_LANE_SYNC_ERR_REG: 0414
3:0 0 RO LL stat_rx_synced_err
STAT_RX_AM_ERR_REG: 0418
3:0 0 RO LL stat_rx_mf_err
STAT_RX_AM_LEN_ERR_REG: 041C
3:0 0 RO LL stat_rx_mf_len_err
STAT_RX_AM_REPEAT_ERR_REG: 0420
3:0 0 RO LH stat_rx_mf_repeat_err
STAT_RX_LANE_DEMUXED: 0424
3:0 0 RO stat_rx_vl_demuxed
STAT_RX_PCS_LANE_NUM_REG1: 0428
1:0 0 RO stat_rx_vl_number_0
6:5 0 RO stat_rx_vl_number_1
11:10 0 RO stat_rx_vl_number_2
16:15 0 RO stat_rx_vl_number_3
STAT_RX_RSFEC_STATUS_REG: 043C
0 1 RO LH stat_rx_rsfec_lane_alignment_status
1 0 RO LH stat_rx_rsfec_lane_hi_ser
4 0 RO stat_rx_rsfec_am_lock0
5 0 RO stat_rx_rsfec_am_lock1
9:8 0 RO stat_rx_rsfec_lane_mapping
STAT_RX_RSFEC_LANE_FILL_REG1: 0440
13:0 0 RO stat_rx_rsfec_lane_fill_0
29:16 0 RO stat_rx_rsfec_lane_fill_1
STAT_RX_FEC_STATUS_REG: 0448
3:0 1 RO LL stat_fec_rx_lock
19:16 1 RO LL stat_fec_lock_error
STAT_TX_RSFEC_STATUS_REG: 044C
0 1 RO LL stat_tx_rsfec_lane_alignment_status
1 1 RO LL stat_tx_rsfec_block_lock
STAT_TX_FLOW_CONTROL_REG1: 0450
8:0 0 RO LH stat_tx_pause_valid
STAT_RX_FLOW_CONTROL_REG1: 0454
8:0 0 RO LH stat_rx_pause_req
17:9 0 RO LH stat_rx_pause_valid
STAT_AN_STATUS: 0458
0 0 RO stat_an_fec_enable
1 0 RO stat_an_rs_fec_enable
2 0 RO stat_an_autoneg_complete
3 0 RO stat_an_parallel_detection_fault
4 0 RO stat_an_tx_pause_enable
5 0 RO stat_an_rx_pause_enable
6 0 RO LH stat_an_lp_ability_valid
7 0 RO stat_an_lp_autoneg_able
8 0 RO stat_an_lp_pause
9 0 RO stat_an_lp_asm_dir
10 0 RO stat_an_lp_rf
11 0 RO stat_an_lp_fec_10g_ability
12 0 RO stat_an_lp_fec_10g_request
13 0 RO LH stat_an_lp_extended_ability_valid
17:14 0 RO stat_an_lp_ability_extended_fec
18 0 RO stat_an_lp_fec_25g_rs_request
19 0 RO stat_an_lp_fec_25g_baser_request
STAT_AN_ABILITY: 045C
0 0 RO stat_an_lp_ability_1000base_kx
1 0 RO stat_an_lp_ability_10gbase_kx4
2 0 RO stat_an_lp_ability_10gbase_kr
3 0 RO stat_an_lp_ability_40gbase_kr4
4 0 RO stat_an_lp_ability_40gbase_cr4
5 0 RO stat_an_lp_ability_100gbase_cr10
6 0 RO stat_an_lp_ability_100gbase_kp4
7 0 RO stat_an_lp_ability_100gbase_kr4
8 0 RO stat_an_lp_ability_100gbase_cr4
9 0 RO stat_an_lp_ability_25gbase_krcr_s
10 0 RO stat_an_lp_ability_25gbase_krcr
11 0 RO stat_an_lp_ability_2_5gbase_kx
12 0 RO stat_an_lp_ability_5gbase_kr
13 0 RO stat_an_lp_ability_50gbase_krcr
14 0 RO stat_an_lp_ability_100gbase_kr2cr2
15 0 RO stat_an_lp_ability_200gbase_kr4cr4
16 0 RO stat_an_lp_ability_25gbase_kr1
17 0 RO stat_an_lp_ability_25gbase_cr1
18 0 RO stat_an_lp_ability_50gbase_kr2
19 0 RO stat_an_lp_ability_50gbase_cr2
STAT_AN_LINK_CTL: 0460
1:0 0 RO stat_an_link_cntl_1000base_kx
3:2 0 RO stat_an_link_cntl_10gbase_kx4
5:4 0 RO stat_an_link_cntl_10gbase_kr
7:6 0 RO stat_an_link_cntl_40gbase_kr4
9:8 0 RO stat_an_link_cntl_40gbase_cr4
11:10 0 RO stat_an_link_cntl_100gbase_cr10
13:12 0 RO stat_an_link_cntl_100gbase_kp4
15:14 0 RO stat_an_link_cntl_100gbase_kr4
17:16 0 RO stat_an_link_cntl_100gbase_cr4
19:18 0 RO stat_an_link_cntl_25gbase_krcr_s
21:20 0 RO stat_an_link_cntl_25gbase_krcr
23:22 0 RO stat_an_link_cntl_2_5gbase_kx
25:24 0 RO stat_an_link_cntl_5gbase_kr
27:26 0 RO stat_an_link_cntl_50gbase_krcr
29:28 0 RO stat_an_link_cntl_100gbase_kr2cr2
31:30 0 RO stat_an_link_cntl_200gbase_kr4cr4
3:0 0 RO stat_lt_initialize_from_rx
19:16 0 RO stat_lt_preset_from_rx
STAT_LT_STATUS_REG2: 0468
3:0 0 RO stat_lt_training
19:16 0 RO stat_lt_frame_lock
STAT_LT_STATUS_REG3: 046C
3:0 0 RO stat_lt_signal_detect
19:16 0 RO stat_lt_training_fail
STAT_LT_STATUS_REG4: 0470
3:0 0 RO LH stat_lt_rx_sof
STAT_LT_COEFFICIENT0_REG: 0474
1:0 0 RO stat_lt_k_p1_from_rx0
3:2 0 RO stat_lt_k0_from_rx0
5:4 0 RO stat_lt_k_m1_from_rx0
7:6 0 RO stat_lt_stat_p1_from_rx0
9:8 0 RO stat_lt_stat0_from_rx0
11:10 0 RO stat_lt_stat_m1_from_rx0
17:16 0 RO stat_lt_k_p1_from_rx1
19:18 0 RO stat_lt_k0_from_rx1
21:20 0 RO stat_lt_k_m1_from_rx1
23:22 0 RO stat_lt_stat_p1_from_rx1
25:24 0 RO stat_lt_stat0_from_rx1
27:26 0 RO stat_lt_stat_m1_from_rx1
STAT_LT_COEFFICIENT1_REG: 0478
1:0 0 RO stat_lt_k_p1_from_rx2
3:2 0 RO stat_lt_k0_from_rx2
5:4 0 RO stat_lt_k_m1_from_rx2
7:6 0 RO stat_lt_stat_p1_from_rx2
9:8 0 RO stat_lt_stat0_from_rx2
11:10 0 RO stat_lt_stat_m1_from_rx2
17:16 0 RO stat_lt_k_p1_from_rx3
19:18 0 RO stat_lt_k0_from_rx3
21:20 0 RO stat_lt_k_m1_from_rx3
23:22 0 RO stat_lt_stat_p1_from_rx3
25:24 0 RO stat_lt_stat0_from_rx3
27:26 0 RO stat_lt_stat_m1_from_rx3
STAT_CORE_SPEED_REG: 047C
0 GUI RO stat_core_speed
Configured
1 GUI RO runtime_switchable 1
Configured
1. This register is available only for the 128-bit straddled AXI4-Stream data path
interface. Bits 1:0 are defined as:
00 Standalone 50G
01 Standalone 40G
10 Runtime Switchable 50G
11 Runtime Switchable 40G
STAT_GT_WIZ_REG: 04A0
Table: STAT_GT_WIZ_REG
0 0 RO gtwiz_reset_tx_done
1 0 RO gtwiz_reset_rx_done
1. This register indicates that the GT is out of reset and the recovered TX/RX clocks are
stable.
2. The user needs to first read 0x04A0 register (STAT_GT_WIZ_REG) and wait till the
value is 2'b11. Then, perform the next operations such as reading the Block Lock
register (0x040C).
STAT_AN_LINK_CTL2: 09F0
1:0 0 RO stat_an_lp_ability_25gbase_kr1
3:2 0 RO stat_an_link_cntl_25gbase_cr1
5:4 0 RO stat_an_link_cntl_50gbase_kr2
7:6 0 RO stat_an_link_cntl_50gbase_cr2
Statistics Counters
Counters are 48 bits and require two 32-bit address spaces. The following tables provide the
first address for each counter corresponding to the 32 LSBs and the next address contains the
remaining 16 bits of MSBs in bits [15:0].The default value for all counters is 0.
Counters are cleared when read by tick_reg (or pm_tick if so selected), but the register
retains its value.
Each counter saturates at FFFFFFFFFFFF (hex).
STATUS_CYCLE_COUNT_LSB: 0500
STATUS_CYCLE_COUNT_MSB: 0504
STAT_RX_BIP_ERR_0_LSB: 0508
STAT_RX_BIP_ERR_0_MSB: 050C
STAT_RX_BIP_ERR_1_LSB: 0510
STAT_RX_BIP_ERR_1_MSB: 0514
STAT_RX_BIP_ERR_2_LSB: 0518
STAT_RX_BIP_ERR_2_MSB: 051C
STAT_RX_BIP_ERR_3_LSB: 0520
STAT_RX_FRAMING_ERR_0_LSB: 05A8
STAT_RX_FRAMING_ERR_0_MSB: 05AC
STAT_RX_FRAMING_ERR_1_LSB: 05B0
STAT_RX_FRAMING_ERR_1_MSB: 05B4
STAT_RX_FRAMING_ERR_2_LSB: 05B8
STAT_RX_FRAMING_ERR_2_MSB: 05BC
STAT_RX_FRAMING_ERR_3_LSB: 05C0
STAT_RX_FRAMING_ERR_3_MSB: 05C4
STAT_RX_BAD_CODE_LSB: 0660
STAT_RX_BAD_CODE_MSB: 0664
STAT_RX_ERROR_LSB: 0668
STAT_RX_ERROR_MSB: 066C
STAT_RX_RSFEC_CORRECTED_CW_INC_LSB: 0670
STAT_RX_RSFEC_CORRECTED_CW_INC_MSB: 0674
STAT_RX_RSFEC_UNCORRECTED_CW_INC_LSB: 0678
STAT_RX_RSFEC_UNCORRECTED_CW_INC_MSB: 067C
STAT_RX_RSFEC_ERR_COUNT0_INC_MSB: 0684
STAT_RX_RSFEC_ERR_COUNT1_INC_LSB: 0688
STAT_RX_RSFEC_ERR_COUNT1_INC_LSB: 068C
STAT_TX_FRAME_ERROR_LSB: 06A0
STAT_TX_FRAME_ERROR_MSB: 06A4
STAT_TX_TOTAL_PACKETS_LSB: 0700
STAT_TX_TOTAL_PACKETS_MSB: 0704
STAT_TX_TOTAL_GOOD_PACKETS_LSB: 0708
STAT_TX_TOTAL_GOOD_PACKETS_MSB: 070C
STAT_TX_TOTAL_BYTES_LSB: 0710
STAT_TX_TOTAL_BYTES_MSB: 0714
STAT_TX_TOTAL_GOOD_BYTES_LSB: 0718
STAT_TX_TOTAL_GOOD_BYTES_MSB: 071C
STAT_TX_PACKET_64_BYTES_LSB: 0720
STAT_TX_PACKET_64_BYTES_MSB: 0724
STAT_TX_PACKET_65_127_BYTES_LSB: 0728
STAT_TX_PACKET_128_255_BYTES_LSB: 0730
STAT_TX_PACKET_128_255_BYTES_MSB: 0734
STAT_TX_PACKET_256_511_BYTES_LSB: 0738
STAT_TX_PACKET_256_511_BYTES_MSB: 073C
STAT_TX_PACKET_512_1023_BYTES_LSB: 0740
STAT_TX_PACKET_512_1023_BYTES_MSB: 0744
STAT_TX_PACKET_1024_1518_BYTES_LSB: 0748
STAT_TX_PACKET_1024_1518_BYTES_MSB: 074C
STAT_TX_PACKET_1519_1522_BYTES_LSB: 0750
STAT_TX_PACKET_1519_1522_BYTES_MSB: 0754
STAT_TX_PACKET_1523_1548_BYTES_LSB: 0758
STAT_TX_PACKET_1523_1548_BYTES_MSB: 075C
STAT_TX_PACKET_1549_2047_BYTES_LSB: 0760
STAT_TX_PACKET_1549_2047_BYTES_MSB: 0764
STAT_TX_PACKET_2048_4095_BYTES_LSB: 0768
STAT_TX_PACKET_2048_4095_BYTES_MSB: 076C
STAT_TX_PACKET_4096_8191_BYTES_MSB: 0774
STAT_TX_PACKET_8192_9215_BYTES_LSB: 0778
STAT_TX_PACKET_8192_9215_BYTES_MSB: 077C
STAT_TX_PACKET_LARGE_LSB: 0780
STAT_TX_PACKET_LARGE_MSB: 0784
STAT_TX_PACKET_SMALL_LSB: 0788
STAT_TX_PACKET_SMALL_MSB: 078C
STAT_TX_BAD_FCS_LSB: 07B8
STAT_TX_BAD_FCS_MSB: 07BC
STAT_TX_UNICAST_LSB: 07D0
STAT_TX_UNICAST_MSB: 07D4
STAT_TX_MULTICAST_LSB: 07D8
STAT_TX_MULTICAST_MSB: 07DC
STAT_TX_BROADCAST_LSB: 07E0
STAT_TX_BROADCAST_MSB: 07E4
STAT_TX_VLAN_LSB: 07E8
STAT_TX_PAUSE_LSB: 07F0
STAT_TX_PAUSE_MSB: 07F4
STAT_TX_USER_PAUSE_LSB: 07F8
STAT_TX_USER_PAUSE_MSB: 07FC
STAT_RX_TOTAL_PACKETS_LSB: 0808
STAT_RX_TOTAL_PACKETS_MSB: 080C
STAT_RX_TOTAL_GOOD_PACKETS_LSB: 0810
STAT_RX_TOTAL_GOOD_PACKETS_MSB: 0814
STAT_RX_TOTAL_BYTES_LSB: 0818
STAT_RX_TOTAL_BYTES_MSB: 081C
STAT_RX_TOTAL_GOOD_BYTES_LSB: 0820
STAT_RX_TOTAL_GOOD_BYTES_MSB: 0824
STAT_RX_PACKET_64_BYTES_LSB: 0828
STAT_RX_PACKET_64_BYTES_MSB: 082C
STAT_RX_PACKET_65_127_BYTES_LSB: 0830
STAT_RX_PACKET_65_127_BYTES_MSB: 0834
STAT_RX_PACKET_128_255_BYTES_MSB: 083C
STAT_RX_PACKET_256_511_BYTES_LSB: 0840
STAT_RX_PACKET_256_511_BYTES_MSB: 0844
STAT_RX_PACKET_512_1023_BYTES_LSB: 0848
STAT_RX_PACKET_512_1023_BYTES_MSB: 084C
STAT_RX_PACKET_1024_1518_BYTES_LSB: 0850
STAT_RX_PACKET_1024_1518_BYTES_MSB: 0854
STAT_RX_PACKET_1519_1522_BYTES_LSB: 0858
STAT_RX_PACKET_1519_1522_BYTES_MSB: 085C
STAT_RX_PACKET_1523_1548_BYTES_LSB: 0860
STAT_RX_PACKET_1523_1548_BYTES_MSB: 0864
STAT_RX_PACKET_1549_2047_BYTES_LSB: 0868
STAT_RX_PACKET_1549_2047_BYTES_MSB: 086C
STAT_RX_PACKET_2048_4095_BYTES_LSB: 0870
STAT_RX_PACKET_2048_4095_BYTES_MSB: 0874
STAT_RX_PACKET_4096_8191_BYTES_LSB: 0878
STAT_RX_PACKET_8192_9215_BYTES_LSB: 0880
STAT_RX_PACKET_8192_9215_BYTES_MSB: 0884
STAT_RX_PACKET_LARGE_LSB: 0888
STAT_RX_PACKET_LARGE_MSB: 088C
STAT_RX_PACKET_SMALL_LSB: 0890
STAT_RX_PACKET_SMALL_MSB: 0894
STAT_RX_UNDERSIZE_LSB: 0898
STAT_RX_UNDERSIZE_MSB: 089C
STAT_RX_FRAGMENT_LSB: 08A0
STAT_RX_FRAGMENT_MSB: 08A4
STAT_RX_OVERSIZE_LSB: 08A8
STAT_RX_OVERSIZE_MSB: 08AC
STAT_RX_TOOLONG_LSB: 08B0
STAT_RX_TOOLONG_MSB: 08B4
STAT_RX_JABBER_LSB: 08B8
STAT_RX_JABBER_MSB: 08BC
STAT_RX_BAD_FCS_MSB: 08C4
STAT_RX_PACKET_BAD_FCS_LSB: 08C8
STAT_RX_PACKET_BAD_FCS_MSB: 08CC
STAT_RX_STOMPED_FCS_LSB: 08D0
STAT_RX_STOMPED_FCS_MSB: 08D4
STAT_RX_UNICAST_LSB: 08D8
STAT_RX_UNICAST_MSB: 08DC
STAT_RX_MULTICAST_LSB: 08E0
STAT_RX_MULTICAST_MSB: 08E4
STAT_RX_BROADCAST_LSB: 08E8
STAT_RX_BROADCAST_MSB: 08EC
STAT_RX_VLAN_LSB: 08F0
STAT_RX_VLAN_MSB: 08F4
STAT_RX_PAUSE_LSB: 08F8
STAT_RX_PAUSE_MSB: 08FC
STAT_RX_USER_PAUSE_LSB: 0900
STAT_RX_INRANGEERR_LSB: 0908
STAT_RX_INRANGEERR_MSB: 090C
STAT_RX_TRUNCATED_LSB: 0910
STAT_RX_TRUNCATED_MSB: 0914
STAT_RX_TEST_PATTERN_MISMATCH_LSB: 0918
STAT_RX_TEST_PATTERN_MISMATCH_MSB: 091C
STAT_FEC_INC_CORRECT_COUNT_LSB: 0920
STAT_FEC_INC_CORRECT_COUNT_MSB: 0924
STAT_FEC_INC_CANT_CORRECT_COUNT_LSB: 0928
STAT_FEC_INC_CANT_CORRECT_COUNT_MSB: 092C
Each instance of the 40G/50G High Speed Ethernet subsystem created by the Vivado design
tool is delivered with an example design that can be implemented in a device and then
simulated. This design can be used as a starting point for your own design or can be used to
sanity-check your application in the event of difficulty. See the Example Design content for
information about using and customizing the example designs for the subsystem.
The AMD 40G/50G High Speed Ethernet subsystem designs are challenging to implement in
any technology, and the degree of difficulty is further influenced by:
All 40G/50G High Speed Ethernet subsystem implementations need careful attention to
system performance requirements. Pipelining, logic mapping, placement constraints, and logic
duplication are all methods that help boost system performance.
Registering Signals
To simplify timing and increase system performance in a programmable device design, keep
all inputs and outputs registered between the user application and the subsystem. This means
that all inputs and outputs from the user application should come from, or connect to, a flip-
flop. While registering signals might not be possible for all paths, it simplifies timing analysis
and makes it easier for the AMD tools to place and route the design.
The constraints provided with the example design identify the critical signals and timing
constraints that should be applied.
You should not modify the subsystem. Any modifications can have adverse effects on system
timing and protocol compliance. Supported user configurations of the subsystem can only be
made by selecting the options in the customization IP dialog box when the subsystem is
generated.
Clocking
This section describes the clocking for all the 40G/50G configurations at the component
support wrapper layer. There are three fundamentally different clocking architectures
depending on the functionality and options:
The clocking architecture for the 40G/50G PCS is illustrated below. There are three clock
domains in the datapath, as illustrated by the dashed lines in the following figure:
tx_mii_clk
The tx_mii_clk is an output which is the same as the tx_serdes_refclk. The entire TX
path is driven by this clock. You must synchronize the TX path mii bus to this clock output. All
TX control and status signals are referenced to this clock.
rx_serdes_clk
The rx_serdes_clk is derived from the incoming data stream within the GT block. The
incoming data stream is processed by the RX core in this clock domain.
rx_clk_out
The rx_clk_out output signal is presented as a reference for the RX control and status
signals processed by the RX core. It is the same frequency as the rx_serdes_clk.
rx_mii_clk
The rx_mii_clk input is required to be synchronized to the RX XLGMII/50GMII data bus. This
clock and the RX XLGMII/50GMII bus must be within 100 ppm of the required frequency,
which is 312.5 MHz for 40G and 390.625 MHz for 50G.
dclk
The dclk signal must be a convenient stable clock. It is used as a reference frequency for the
GT helper blocks which initiate the GT itself. In the example design, a typical value is 75 MHz,
which is readily derived from the 300 MHz clock available on the VCU107 evaluation board.
✎ Note: The actual frequency must be known to the GT helper blocks for proper operation.
40G/50G MAC with PCS/PMA Clocking
The clocking architecture for the 40/50G MAC with PCS/PMA clocking is illustrated below. This
version of the subsystem includes FIFOs in the RX. There are three clock domains in the data
tx_clk_out
This clock is used for clocking data into the TX AXI4-Stream Interface and it is also the
reference clock for the TX control and status signals. It is the same frequency as
tx_serdes_refclk.
rx_clk_out
The rx_clk_out output signal is presented as a reference for the RX control and status
signals processed by the RX core. It is the same frequency as the rx_serdes_clk.
rx_clk
The rx_clk is the input clk for the RX core. This rx_clk is available to you as rx_core_clk,
which you must drive from the example design. You should drive the rx_core_clk with a
frequency that is equal to the tx_clk. When FIFO is enabled, the most preferred mode of
operation for system side datapath is to connect the tx_clk_out to rx_core_clk. When
connected in this manner, the RX AXI4-Stream Interface and the TX AXI4-Stream Interface
are on the same clock domain.
dclk
The dclk signal must be a convenient stable clock. It is used as a reference frequency for the
GT helper blocks which initiate the GT itself. In the example design, a typical value is 75 MHz,
which is readily derived from the 300 MHz clock available on the VCU107 evaluation board.
✎ Note: The actual frequency must be known to the GT helper blocks for proper operation.
Low Latency 40G/50G MAC with PCS/PMA Clocking
The clocking architecture for the Low Latency 40/50G MAC with PCS/PMA clocking is
illustrated in the following figure. Low latency is achieved by omitting the RX FIFO, which
results in different clocking arrangement. There are two clock domains in the datapath, as
illustrated by the dashed lines in the following figure.
tx_clk_out
This clock is used for clocking data into the TX AXI4-Stream Interface and it is also the
reference clock for the TX control and status signals. It is the same frequency as
tx_serdes_refclk. Because there is no TX FIFO, you must respond immediately to the
tx_axis_tready signal.
rx_clk_out
The rx_clk_out output signal is presented as a reference for the RX control and status
signals processed by the RX core. It is the same frequency as the rx_serdes_clk. Because
there is no RX FIFO, this is also the clock which drives the RX AXI4-Stream Interface. In this
dclk
The dclk signal must be a convenient stable clock. It is used as a reference frequency for the
GT helper blocks which initiate the GT itself. In the example design, a typical value is 75 MHz,
which is readily derived from the 300 MHz clock available on the VCU107 evaluation board.
The actual frequency must be known to the GT helper blocks for proper operation.
The clocking architecture for the Auto-Negotiation and Link Training blocks are illustrated in
the following figure.
✎ Note: These blocks are not included unless the 50GBASE-KR or 50GBASE-CR feature is
selected.
The Auto-Negotiation and Link Training blocks function independently from the MAC and PCS,
and therefore they are on different clock domains.
tx_serdes_clk
The tx_serdes_clk drives the TX line side logic for the Auto-Negotiation and Link Training.
The DME frame is generated on this clock domain.
rx_serdes_clk
The rx_serdes_clk drives the RX line side logic for the Auto-Negotiation and Link Training.
AN_clk
The AN_clk drives the Auto-Negotiation state machine. All ability signals are on this clock
domain. The AN_clk can be any convenient frequency. In the example design, AN_clk is
connected to the dclk input, which has a typical frequency of 75 MHz. The AN_clk frequency
must be known to the Auto-Negotiation state machine because it is the reference for all timers.
Figure: Single Core (1x50G) - Asynchronous Clock Mode (GTY) (2x25G) for
UltraScale/UltraScale+ Device
Single Core (1x50G) - Asynchronous Clock Mode (GTY) (2x25G) for Versal
Adaptive SoC
Figure: Single Core (1x50G) - GTY (2x25G) for Versal Adaptive SoC
Figure: Single Core 40G GTY (4x10G)/Runtime Switching GTY (4x10G/2x25G) for Versal
Adaptive SoC
Figure: Multiple Cores (2x50G) - Asynchronous Clock Mode GTY (2x25G) for
UltraScale/UltraScale+ Device
Figure: Single Core (1x50G) - Asynchronous Clock Mode GTM UltraScale+ (1x50G)
Figure: Multiple Cores (2x50G) - Asynchronous Clock Mode GTM UltraScale+ (2x50G)
1. Two core options are also available, using two lanes of a single GTM Dual.
2. XLAUI-1 uses two GTM duals.
This section details the packet timestamping function of the 40G/50G Ethernet subsystem
when the MAC layer is included. The timestamping option must be specified at the time of
generating the subsystem from the IP catalog or ordering the IP core asynchronously. This
feature presently supports one-step and two-step IEEE PTP 1588 functionality. One-step
operation is described in this appendix for reference.
Ethernet frames are timestamped at both ingress and egress. The option can be used for
implementing all kinds of IEEE 1588 clocks: Ordinary, Transparent, and Boundary. It can also
be used for the generic timestamping of packets at the ingress and egress ports of a system.
While this feature can be used for a variety of packet timestamping applications, the rest of
this appendix assumes that you are also implementing the IEEE 1588 Precision Time Protocol
(PTP).
IEEE 1588 defines a protocol for performing timing synchronization across a network. A 1588
network has a single master clock timing reference, usually selected through a best master
clock algorithm. Periodically, this master samples its system timer reference counter, and
transmits this sampled time value across the network using defined packet formats. This timer
should be sampled (a timestamp) when the start of a 1588 timing packet is transmitted.
Therefore, to achieve high synchronization accuracy over the network, accurate timestamps
are required. If this sampled timer value (the timestamp) is placed into the packet that
triggered the timestamp, this is known as 1-step operation. Alternatively, the timestamp value
can be placed into a follow up packet; this is known as 2-step operation.
Other timing slave devices on the network receive these timing reference packets from the
network timing master and attempt to synchronize their own local timer references to it. This
mechanism relies on these Ethernet ports also taking timestamps (samples of their own local
timer) when the 1588 timing packets are received. Further explanation of the operation of
1588 is out of the scope of this document. It is assumed that the reader is familiar with the
IEEE 1588 specification for the rest of this section.
The 1588 timer provided to the subsystem and the consequential timestamping taken from it
are available in one of two formats which are selected during subsystem generation.
Egress
Figure: Egress
As seen on the diagram, timestamping logic exists in two locations depending on whether 1-
step or 2-step operation is desired. 1-step operation requires user datagram protocol (UDP)
checksum and FCS updates and therefore the FCS core logic is used.
The TS references are defined as follows:
TS2 always has a correction applied so that it is referenced to the TS2' plane. TS1 might or
might not have the TS2' correction applied, depending on the value of the signal
On the transmit side, a command field is provided by the client to the subsystem in parallel
with the frame sent for transmission. This indicates, on a frame-by-frame basis, the 1588
function to perform (either no-operation, 1-step, or 2-step) and also indicates, for 1-step
frames, whether there is a UDP checksum field to update.
If using the ToD format, for both 1-step and 2-step operation, the full captured 80-bit ToD
timestamp is returned to the client logic using the additional ports defined in the 1588v2 Port
List and Descriptions table. If using the Correction Field format, for both 1-step and 2-step
operation, the full captured 64-bit timestamp is returned to the client logic using the additional
ports defined in the 1588v2 Port List and Descriptions table (with the upper bits of data set to
zero as defined in the table).
If using the ToD format, for 1-step operation, the full captured 80-bit ToD timestamp is inserted
into the frame. If using the Correction Field format, for 1-step operation, the captured 64-bit
timestamp is summed with the existing Correction Field contained within the frame and the
summed result is overwritten into the original Correction Field of the frame.
Supported frame types for 1-step timestamping are:
Raw Ethernet
UDP/IPv4
UDP/IPv6
For 1-step UDP frame types, the UDP checksum is updated in accordance with IETF RFC
1624. For all 1-step frames, the Ethernet Frame Check Sequence (FCS) field is calculated
after all frame modifications are completed. For 2-step transmit operation, all Precision Time
Protocol (PTP) frame types are supported.
The operational mode of the egress timestamping function is determined by the settings on
the 1588 command port. The information contained within the command port indicates one of
the following:
For 1-step operation, following the frame modification, the CRC value of the frame should also
be updated/recalculated. For UDP IPv4 and IPv6 PTP formatted frames, the checksum value
in the header of the frame needs to updated/recalculated.
For 1-step UDP frame types, the UDP checksum is updated in accordance with IETF RFC
1624.
If using the ToD format, in order for this update function to work correctly, the original
checksum value for the frame sent for transmission should be calculated using a zero
value for the timestamp data. This particular restriction does not apply when using the
Correction Field format.
If using the Correction Field format, a different restriction does apply; the separation
between the UDP Checksum field and the Correction Field within the 1588 PTP frame
header is a fixed interval of bytes, supporting the 1588 PTP frame definition. This is a
requirement to minimize the latency through the MAC because both the checksum and
the correction field must both be fully contained in the MAC pipeline in order for the
checksum to be correctly updated. This particular restriction does not apply to the ToD
format because the original timestamp data is calculated as a zero value; consequently
the checksum and timestamp position can be independently located within the frame.
Related Information
1588v2 Port List and Descriptions
Ingress
Figure: Ingress
The ingress logic does not parse the ingress packets to search for 1588 (PTP) frames.
Instead, it takes a timestamp for every received frame and outputs this value to the user logic.
The feature is always enabled, but the timestamp output can be ignored if you are not
requiring this function.
Timestamps are filtered after the PCS decoder to retain only those timestamps corresponding
to an SOP. These 80-bit timestamps are output on the system side. The timestamp is valid
during the SOP cycle and when ena_out = 1.
The following table details the additional signals present when the packet timestamping
feature is included.
tx_ptp_tstamp_tag_out[15:0]
O Tag output corresponding to tx_clk_out
tx_ptp_tag_field_in[15:0]
ctl_tx_ptp_latency_adjust[10:0]
I This bus can be used to adjust the 1- tx_clk_out
step TX timestamp with respect to the 2-
step timestamp. The units of bits [10:3]
Related Information
IEEE 1588 TX/RX Interface Control/Status/Statistics Signals
Figure: Receive
Figure: Transmit
Performance
Clock Domain
In a practical sense, the system timer input is required to have a granularity of the SerDes
clock. Therefore, the clock domain crossing of the system timer input should be taken into
account. For example, if the SerDes clock has a frequency of 390 MHz, the system timer has
an actual granularity of 2.56 ns, which is also the clock which captures the timestamp. Hence
an additional variation of 2.56 ns can be expected.
Transceiver
The addition of a SerDes in the datapath does not impact the jitter performance of the 40G/
50G subsystem but might result in asymmetry.
In a 1588 clock application, the RX + TX SerDes latency becomes part of the loop delay and is
therefore measured by the 1588 protocol. For maximum accuracy of the slave clock it is
desirable to take loop asymmetry into account (the difference between the RX and TX SerDes
latencies). AMD can provide the transceiver latency for various settings of the SerDes specific
to your device. You need to contact the vendor of the other transceiver in a datapath if
necessary for its characteristics, if you wish to take asymmetry into account in your PTP
system.
AMD UltraScale™ and AMD UltraScale+™ transceivers have the ability to report the RX
latency. Variation of the RX transceiver latency is mainly due to the fill level of its internal
elastic buffer. Refer to the transceiver guide for more details.
The first step is to take a time average of the alignment buffer fill levels because the
granularity of these signals is one SerDes clock cycle. While the skew remains relatively
constant over time (for example, minutes or hours), the alignment buffer levels have short-
term fluctuations of SerDes clock cycles due to sampling quantization. Therefore the actual
skew can be obtained to a high degree of accuracy (for example, sub nanoseconds) by taking
a time average of each of the fill levels.
Assuming the fill levels are accurately determined as above, the following formula is used to
correct for skew:
RS-FEC Support
This section describes the optional RS-FEC function of the 50G Ethernet subsystem. The RS-
FEC option must be specified at the time of generating the subsystem from the IP catalog or
ordering the IP core asynchronously.
The RS-FEC block is positioned between the PCS and PMA as illustrated in 40G/50G MAC
with PCS/PMA Clocking.
With reference to the following diagram, the RS-FEC core clocks and resets are equivalent to
the transceiver signals, with the transceiver resets being active-High.
The 50G subsystem RS-FEC feature provides error correction capability according to 50G
FEC (Ethernet Consortium Schedule 3 specification, based on IEEE 802.3 Clause 91).
The feature requires the insertion of PCS alignment markers as defined in IEEE 802.3 Table
82-3. The number of words between the PCS alignment markers is 20,480.
It is possible to bypass the RS-FEC function by means of the enable signals. This bypasses
the RS-FEC function and connect the PCS directly to the transceiver, with the benefit of
reduced latency. Refer to the 50G IEEE 802.3 Reed-Solomon Forward Error Correction 50G
IEEE 802.3 Reed-Solomon Forward Error Correction LogiCORE IP Product Guide (PG234)
(registration required) for the latest latency performance data in the various bypass modes.
The following feature bypass modes are selectable.
FEC Bypass Correction: The decoder performs error detection without correction, (see
IEEE Std 802.3 section 91.5.3.3 [Ref 1]). The latency is reduced in this mode.
FEC Bypass Indication: In this mode there is correction of the data but no error
indication. An additional signal, rx_hi_ser, is generated in this mode to reduce the
likelihood that errors in a packet are not detected. The RS decoder counts the number of
symbol errors detected in consecutive non-overlapping blocks of codewords (see IEEE
Std 802.3 section 91.5.3.3 [Ref 1]). The latency is reduced in this mode.
Decoder Bypass: The RS decoder can be bypassed by setting the IEEE Error indication
Low when the correction bypass and indication are in bypass mode.
The following table describes the configuration and status ports when the RS-FEC feature is
included.
ctl_rsfec_ieee_error_indication_mode
I Changes only take effect after the rx_serdes_clk
reset. A new value is sampled on
the first cycle after reset.
Status/Control Interface
The Status/Control interface allows you to set up the 40G/50G High Speed Ethernet
Subsystem configuration and to monitor the status of the 40G/50G High Speed Ethernet
Subsystem. The following subsections describe in more detail some of the various Status and
Control signals.
The IEEE Std 802.3 defines the PCS Lane marker values, shown in the following table. BIP
fields are calculated in accordance with IEEE 802.3 Clause 82.2.8.
ctl_rx_vl_marker_id[0][63:0] 64'h90_76_47_BIP3_6F_89_B8_BIP7
ctl_tx_vl_marker_id[0][63:0]
ctl_rx_vl_marker_id[1][63:0] 64'hF0_C4_E6_BIP3_0F_3B_19_BIP7
ctl_tx_vl_marker_id[1][63:0]
ctl_rx_vl_marker_id[2][63:0] 64'hC5_65_9B_BIP3_3A_9A_64_BIP7
ctl_tx_vl_marker_id[2][63:0]
ctl_rx_vl_marker_id[3][63:0] 64'hA2_79_3D_BIP3_5D_86_C2_BIP7
ctl_tx_vl_marker_id[3][63:0]
The 40G/50G High Speed Ethernet Subsystem provides status bits to indicate the state of
word boundary synchronization and PCS lane alignment. All signals are synchronous with the
stat_rx_synced[3:0]
When a bit of this bus is 0, it indicates that word boundary synchronization of the
corresponding lane is not complete or that an error has occurred as identified by another
status bit.
When a bit of this bus is 1, it indicates that the corresponding lane is word boundary
synchronized and is receiving PCS Lane Marker Words as expected.
stat_rx_synced_err[3:0]
When a bit of this bus is 1, it indicates one of several possible failures on the corresponding
lane:
Word boundary synchronization in the lane was not possible using Framing bits [65:64]
After word boundary synchronization in the lane was achieved, errors were detected on
Framing bits [65:64]
After word boundary synchronization in the lane was achieved, a valid PCS Lane Marker
Word was never received
The bits of the bus remain asserted until word boundary synchronization occurs or until some
other error/failure is signaled for the corresponding lane.
stat_rx_mf_len_err[3:0]
When a bit of this bus is 1, it indicates that PCS Lane Marker Words are being received but
not at the expected rate in the corresponding lane. The transmitter and receiver must be
reconfigured with the same Meta Frame length.
The bits of the bus remain asserted until word boundary synchronization occurs or until some
other error/failure is signaled for the corresponding lane.
stat_rx_mf_repeat_err[3:0]
After word boundary synchronization is achieved in a lane, if a bit of this bus is a 1, it indicates
that four consecutive invalid PCS Lane Marker Words were detected in the corresponding
lane.
The bits of the bus remain asserted until resynchronization occurs or until some other error/
failure is signaled for the corresponding lane.
stat_rx_mf_err[3:0]
When stat_rx_aligned is a value of 1, all of the lanes are aligned/deskewed and the
receiver is ready to receive packet data.
stat_rx_aligned_err
When stat_rx_aligned_err is a value of 1, one of two things occurred:
stat_rx_misaligned
When stat_rx_misaligned is a value of 1, a valid PCS Lane Marker Word was not received
on all PCS lanes simultaneously.
This output is asserted for one clock period each time this error condition is detected.
stat_rx_framing_err_[3:0][3:0] and
stat_rx_framing_err_valid_[3:0]
This set of buses is intended to be used to keep track of sync header errors. There is a pair of
outputs for each PCS Lane. The stat_rx_framing_err_[PCSL_LANES-3:0] output bus
indicates how many sync header errors were received and it is qualified (that is, the value is
only valid) when the corresponding stat_rx_framing_err_valid_[PCSL_LANES-3:0] is
sampled as a 1.
stat_rx_vl_number[3:0][1:0]
Each bus indicates which PCS lane has its status reflected on specific status pins. For
example, stat_rx_vlane_number_0 indicates which PCS lane has its status reflected on pin
0 of the other status signals.
These buses can be used to detect if a PCS lane has not been found or if one has been
mapped to multiple status pins.
stat_rx_vl_demuxed[3:0]
After word boundary synchronization is achieved on each lane, if a bit of this bus is 1 it
indicates that the corresponding PCS lane was properly found and de-muxed.
stat_rx_block_lock[3:0]
Each bit indicates that the corresponding PCS lane has achieved sync header lock as defined
by the IEEE Std 802.3-2015. A value of 1 indicates block lock is achieved.
stat_rx_status
This output is set to a 1 when stat_rx_aligned is a 1 and stat_rx_hi_ber is a 0. This is as
defined by the IEEE Std 802.3-2015.
stat_rx_local_fault
This output is set to a 1 when stat_rx_received_local_fault or
stat_rx_internal_local_fault is asserted. This output is level sensitive.
RX Error Status
The 40G/50G High Speed Ethernet Subsystem provides status signals to identify 64b/66b
words and sequences violations and CRC32 checking failures.
All signals are synchronous with the rising-edge of clk and a detailed description of each
signal follows.
stat_rx_bad_fcs
When this signal is a value of 1, it indicates that the error detection logic has identified a
mismatch between the expected and received value of CRC32 in the received packet.
When a CRC32 error is detected, the received packet is marked as containing an error and is
sent with rx_errout asserted during the last transfer (the cycle with rx_eopout asserted)
unless ctl_rx_ignore_fcs is asserted.
This signal is asserted for one clock period each time a CRC32 error is detected.
stat_rx_bad_code[1:0]
This signal indicates how many cycles the RX PCS receive state machine is in the RX_E state
as defined by the IEEE Std 802.3-2015.
Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
Vivado Design Suite User Guide: Designing with IP (UG896)
Vivado Design Suite User Guide: Getting Started (UG910)
Vivado Design Suite User Guide: Logic Simulation (UG900)
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) and the
Vivado Design Suite User Guide: Getting Started (UG910).
Figures in this chapter are illustrations of the Vivado IDE. The layout depicted here might vary
from the current version.
AMD GT based IPs like Aurora, PCIe® , L Ethernet, and MRMAC provides Block Automation
in the IP integrator to enable you to connect multiple AMD parent IPs to GT Quad seamlessly.
IP Block Automation instantiates GT Quads and creates essential datapath, USRCLK, and GT
REFCLK connections.
Perform the following steps to connect multiple L Ethernet IPs using Block Automation:
Configuration Tab
General
Number of Cores 1 1
2
PCS/PMA Options
Control and Statistics Control and Status Vectors Control and Status Vectors
interface Include AXI4-Lite
1. The 128-bit Straddled AXI4-Stream is visible and option for Ethernet MAC+PCS/PMA
with 40G and 50G line rate options.
2. The 256-bit Regular AXI4-Stream is visible and option for Ethernet MAC+PCS/PMA
with 40G Line rate only.
3. The MII interface is visible and is the only option for the Ethernet PCS/PMA core.
4. Clause 74 (BASE-KR FEC) logic is not supported for Base-R.
5. Clause 91 (RS-FEC) is not supported for Base-R, 40G speed.
6. Clause 74 (BASE-KR FEC) and Clause 91 (RS-FEC) both can be selected in AMD
Vivado™ IDE but during functional operation only one can be enabled at a time using
the respective control signals.
7. GTM integrated hard FEC. Only applicable for Devices with GTM (Not applicable for
AMD Versal™ adaptive SoC).
8. The Statistics Counters are available in the register map only when you enable the
Include Statistics Counters option. Otherwise, the Statistics Counters are not
available.
9. Statistics Resource Type block RAM option is supported with Ethernet
MAC+PCS/PMA configuration.
10. There is only single core support for Versal adaptive SoC. Multi-core is not supported
as the example design has GT outside the core.
Flow Control
The GT Selection and Configuration tab enables you to configure the serial transceiver
features of the core.
GT Location
GT Clocks 3
161.1328125
195.3125
201.4160156
322.265625
312.5
156.25
Others
Enable Additional GT 0, 1 0
Control and Status Ports
1. This list provides frequencies used for the default configurations. See Vivado IDE in
the latest version of the tools for a complete list of supported clock frequencies for
different speeds.
2. Only applicable for GTM. For 40G GTM, two consecutive duals need to be selected.
3. Supported GT clocks:
a. 40G supports 156.25, 103.125, 128.90625, 156.25, 161.1328125, 206.25,
257.8125, 309.375, 312.5, and 322.265625 GT RefClk frequencies (in MHz).
b. 50G supports 161.1328125, 161.1328125, 156.25, 312.5, 195.3125,
201.4160156, 257.8125, 322.265625 GT RefClk frequencies (in MHz).
c. 50G GTM (UltraScale+ devices) supports 161.1328125, 156.25, 161.1328125,
195.3125, 201.4160156, 257.8125, 322.265625 GT RefClk frequencies (in
MHz).
d. Runtime switching feature supports 128.90625, 128.90625, 206.25, 257.8125,
156.25, 312.5, 161.1328125 and 322.265625 gt_refclk frequencies for Versal
devices and 161.1328125 gt_refclk frequency for non-Versal devices (in
MHz).
The Shared Logic tab enables you to use shared logic in either the core or the example
design.
Options Default
Configuration Spreadsheet
In addition to the IP catalog in the Vivado design tools, the 40G/50G Ethernet Subsystem can
be requested for a specific configuration using a customer-provided spreadsheet. You must
submit the completed spreadsheet to AMD Technical Support to obtain the target netlist. See
Synthesis and Implementation for a description of what is delivered and how to proceed with
the deliverables.
For a complete understanding of the core, consult the document corresponding to the core
and the device selected, such as the UltraScale Architecture GTH Transceivers User Guide
(UG576).
Related Information
Synthesis and Implementation
Output Generation
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896).
Required Constraints
This section is not applicable for this IP subsystem.
Clock Frequencies
This section is not applicable for this IP subsystem.
Clock Management
This section is not applicable for this IP subsystem.
Clock Placement
This section is not applicable for this IP subsystem.
Banking
This section is not applicable for this IP subsystem.
Transceiver Placement
This section is not applicable for this IP subsystem.
Simulation
For comprehensive information about AMD Vivado™ simulation components, as well as
information about using supported third-party tools, see the Vivado Design Suite User Guide:
Logic Simulation (UG900).
A demonstration simulation test bench is part of each release. Simulation is performed on the
included encrypted RTL. The test bench consists of a loopback from the TX side of the user
interface, through the TX circuit, looping back to the RX circuit, and checking the received
packets at the RX side of the user interface.
The loopback simulation includes a path through the transceiver. The simulation is run using
the provided Linux scripts for several common industry-standard simulators.
For more information, see Test Bench.
Simulation can take a long time to complete due to the time required to complete alignment. A
`define SIM_SPEED_UP is available to improve simulation time by reducing the PCS lane
Alignment Marker (AM) spacing to speed up the time the IP takes to achieve alignment.
Setting define SIM_SPEED_UP reduces CTL_TX_VL_LENGTH_MINUS1 and
CTL_RX_VL_LENGTH_MINUS1.
The SIM_SPEED_UP option can be used for simulation when in serial loopback or if the
Alignment Marker spacing can be reduced at both endpoints. This option is compatible with
the example design simulation which uses serial loopback.
✎ Note:
SIM_SPEED_UP is only available when running RTL simulation. It is not available when
running simulation with post synthesis or post implementation netlist.
Altering the value of CTL_TX_VL_LENGTH_MINUS1 and
CTL_RX_VL_LENGTH_MINUS1 from the default value violates the IEEE 802.3
specification.
Decreasing the AM spacing results in less bandwidth being available on the link. When
using the PCS only core, the TX core does not provide back pressure to the user logic
and the reduced bandwidth can cause stat_tx_fifo_error when transmitting larger back-
to-back packets.
This change can be made only in simulation. For a design to work in hardware, the
default IEEE value must be used.
Full rate simulation without the SIM_SPEED_UP option should still be run.
VCS
Use the vlogan option: +define+SIM_SPEED_UP.
ModelSim
Use the vlog option: +define+SIM_SPEED_UP.
Vivado Simulator
Use the xvlog option: -d SIM_SPEED_UP
Example Design
This chapter provides a brief explanation of the 40G/50G Ethernet Subsystem example
design.
The l_ethernet_0_pkt_gen_mon module is used to generate the data packets for sanity
testing. The packet generation and checking is controlled by a Finite State Machine (FSM)
module.
Descriptions of optional modules are as follows:
l_ethernet _0_trans_debug
This module is present in the example design when you enable the Additional GT Control
and Status Ports check box from the GT Selection and Configuration Tab in the AMD
Vivado™ Integrated Design Environment (IDE) or the Include GT subcore in example
design option in the GT Selection and Configuration tab or the Runtime Switchable mode
option in the in the Configuration Tab. This module brings out all the GT channel DRP
ports, and some control and status ports of the transceiver module out of the l_ethernet
core.
Retiming Registers
When you select the Enable Retiming Register option from the GT Selection and
Configuration Tab, it includes a single stage pipeline register between the core and the
GT to ease timing, using the gt_txusrclk2 and gt_rxusrclk2 for TX and RX paths
respectively. However, by default two-stage registering is done for the signals between
the GT and the core.
✎ Note: For Runtime Switchable, if Auto Negotiation/Link training is selected in Vivado
IDE, AN operation is performed only with the 40G data rate during switchings and LT is
performed in the mission mode.
The following figure shows the instantiation of various modules and their hierarchy for the
multiple core configuration of the l_ethernet_0 example design.
Figure: Single Core with GT in Example Design Hierarchy for Versal Adaptive SoC
The previous figure shows the instantiation of various modules and their hierarchy for a single
core configuration of the l_ethernet_0 example design when the GT (serial transceiver) is
outside the IP core, that is, in the example design. This hierarchical example design is
delivered when you select the Include GT subcore in the example design option from the GT
Selection and Configuration tab.
The l_ethernet_0_core_support.v is present in the hierarchy when you select the Include GT
subcore in example design option from the GT Selection and Configuration tab or the Include
Shared Logic in example design option from the Shared Logic tab. This instantiates the
l_ethernet_0_sharedlogic_wrapper.v module and the l_ethernet_0.v module for the Include
Shared Logic in example design option. The l_ethernet_0_gt_wrapper.v module is present
when you select the GT subcore in example design option.
The l_ethernet_0.v module instantiates the necessary the sync registers/retiming pipeline
registers for the synchronization of data between the core and the GT.
The l_ethernet_0_pkt_gen_mon module is used to generate the data packets for sanity
testing. The packet generation and checking is controlled by a Finite State Machine (FSM)
module.
The optional modules are described as follows:
l_ethernet _0_gt_wrapper
This module is present in the example design when you select the Include GT subcore in
example design option from the GT Selection and Configuration tab. This module
instantiates the GT along with various helper blocks. The clocking helper blocks are used
to generate the required clock frequency for the Core.
The following figure shows the instantiation of various modules and their hierarchy for the
multiple core configuration of the l_ethernet_0 example design when the GT is in the
example design.
For the AMD Versal™ platform, the gt_quad_base (GT wizard for Versal) is a part of the
example design only; the 40G/50G High Speed Ethernet IP and GT (serial transceiver) IP is
connected in the block design using the IP integrator (block automation).
The following figure is a block design, where the 40/50G Ethernet example design connected
in the IP integrator. See the Vivado Design Suite Tutorial: Designing IP Subsystems Using IP
Integrator (UG995) for more information on IP integrator.
When the 40G/50G High Speed Ethernet subsystem is added to AMD Vivado™ IP integrator
and Block Automation is run the IP/core and GT (serial transceivers) are connected with some
helper blocks as per the core configuration. There is a reset interface IP, internal to the
40G/50G High Speed Ethernet IP, used to release tx/rx mstreset to the Versal GT and
check for tx/rx mstresetdone status and reset sequencing to the GT.
✎ Note: Whenever there is a change in the 40G/50G High Speed Ethernet subsystem core
configuration, run the validate design and ensure that is passes. This confirms that all the
changes are applied/propagated to GT in IP integrator.
User Interface
The GPIOs in the following table are provided to control the example design.
gtwiz_reset_qpll0_reset_out_*
1 O QPLL0 lock reset output from the GT.
This port is available when the Include GT
subcore in core option is selected in the GT
Selection and Configuration tab and Include
Shared Logic in example design is selected in
the Shared Logic tab.
gtwiz_tx_datapath_reset_in_*
1 I gt_tx_reset signal from the user.
This port is available when the Control and
Statistics interface is selected from the
Configuration tab.
gtwiz_rx_datapath_reset_in_*
1 I gt_rx_reset signal from the user.
This port is available when Control and
Statistics interface is selected from the
Configuration tab.
TXOUTCLKSEL_IN_* 6/12 I This port is used to select the clock source for
the gtwizard TX output clock. This port is driven
with 6'b101101/12'b101101101101 as per
preset.
RXOUTCLKSEL_IN_* 6/12 I This port is used to select the clock source for
the gtwizard RX output clock. This port is driven
with 6'b101101/12'b101101101101 as per
preset.
gtwiz_rx_datapath_reset_in_*
1 I gt_rx_reset signal from the user.
✎ Note: For Versal devices only. This port is
available when you select Control and Statistics
interface from the Configuration tab.
gtm_out_txprgdivresetdone_*
1 O TX reset output from the core when the GT is
included in the core.
✎ Note: This port is available when the Include
GT subcore in core option is selected in the GT
Selection and Configuration tab and the Include
Shared Logic in example design option is
selected in the Shared Logic tab and GT type is
GTM.
gtm_out_rxprgdivresetdone_*
1 O RX reset output from the core when the GT is
included in the core.
✎ Note: This port is available when the Include
GT subcore in core option is selected in the GT
Selection and Configuration tab and the Include
Shared Logic in example design option is
selected in the Shared Logic tab and GT type is
GTM.
Ports under this section are available when Enable Additional GT Control/Status and DRP
Ports is selected and GT in Core option is selected from the GT Selection and Configuration
tab. Refer to the GT user guide for the port description.
gt_dmonitorout_* 34/68 O Port width: 34 bits for the 50G single core and
68 bits for 40G.
gt_eyescandataerror_* 2/4 O Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_eyescanreset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_eyescantrigger_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_pcsrsvdin_* 32/64 I Port width: 32 bits for the 50G single core and
64 bits for 40G.
gt_rxbufreset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxbufstatus_* 6/12 O Port width: 6-bit for the 50G single core and 12
bits for 40G.
gt_rxcdrhold_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxcommadeten_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxdfeagchold_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxdfelpmreset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxlatclk_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxlpmen_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxpcsreset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxpmareset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxpolarity_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxprbscntreset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxprbserr_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxprbssel_* 8/16 I Port width: 8-bit for the 50G single core and 16
bits for 40G.
gt_rxrate_* 6/12 I Port width: 6-bit for the 50G single core and 12
bits for 40G.
gt_rxslide_in_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_rxstartofseq_* 4/8 O Port width: 4-bit for the 50G single core and 8
bits for 40G.
gt_txbufstatus_* 4/8 O Port width: 4-bit for the 50G single core and 8
bits for 40G.
gt_txdiffctrl_* 10/20 I Port width: 10-bit for the 50G single core and 20
bits for 40G.
gt_txinhibit_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_txlatclk_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_txmaincursor_* 14/28 I Port width: 14-bit for the 50G single core and 28
bits for 40G.
gt_txpcsreset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_txpmareset_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_txpolarity_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_txpostcursor_* 10/20 I Port width: 10-bit for the 50G single core and 20
bits for 40G.
gt_txprbsforceerr_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_txprbssel_* 8/16 I Port width: 8-bit for the 50G single core and 16
bits for 40G.
gt_txprecursor_* 10/20 I Port width: 10-bit for the 50G single core and 20
bits for 40G.
gtwiz_reset_tx_datapath_* 2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gtwiz_reset_rx_datapath_*2/4 I Port width: 2 bits for the 50G single core and 4
bits for 40G.
gt_ch_drpclk_0 1 I
gt_ch_drpdo_0 16 O
gt_ch_drprdy_0 1 O
gt_ch_drpen_0 1 I
gt_ch_drpwe_0 1 I
gt_ch_drpaddr_0 10 I
gt_ch_drpdi_0 16 I
gt_ch_drpclk_1 1 I
gt_ch_drpdo_1 16 O
gt_ch_drprdy_1 1 O
gt_ch_drpen_1 1 I
gt_ch_drpwe_1 1 I
gt_ch_drpaddr_1 10 I
gt_ch_drpdi_1 16 I
Ports under this section are available when Include AXI4-Lite is selected from the
Configuration tab.
Ports under this section are available when Ethernet MAC+PCS/PMA with the 128-bit Straddle
Packet AXI4-Stream option is selected from the Configuration tab.
69 - tx_axis_tuser_err1
68:66 - tx_axis_tuser_mty1[2:0]
65 - tx_axis_tuser_eop1
64 - tx_axis_tuser_sop1
63 - tx_axis_tuser_ena1
62 - tx_axis_tuser_err0
61:59 - tx_axis_tuser_mty0[2:0]
58 - tx_axis_tuser_eop0
57 - tx_axis_tuser_sop0
56- tx_axis_tuser_ena0
55:0- tx_preamblein
69 - rx_axis_tuser_err1
68:66 - rx_axis_tuser_mty1[2:0]
65 - rx_axis_tuser_eop1
64 - rx_axis_tuser_sop1
63 - rx_axis_tuser_ena1
62 - rx_axis_tuser_err0
61:59 - rx_axis_tuser_mty0[2:0]
58 - rx_axis_tuser_eop0
57 - rx_axis_tuser_sop0
56 - rx_axis_tuser_ena0
55:0 - rx_preamblein
Ports under this section are available when Ethernet MAC + PCS/PMA with the 256-bit AXI4-
Stream option is selected from the Configuration tab.
Ports under this section are available when Ethernet PCS/PMA is selected from the
Configuration tab.
ctl_tx_custom_preamble_enable_*
1 I When asserted, this signal enables the use of
tx_preamblein as a custom preamble instead of
inserting a standard preamble.
This port is available when the AXI4-Lite
interface is not selected and core type is
Ethernet MAC+PCS/PMA and Include FIFO
Logic is disabled.
stat_tx_packet_65_127_bytes_*
1 O Increment for good and bad packets transmitted
that contain 65 to 127 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_128_255_bytes_*
1 O Increment for good and bad packets transmitted
that contain 128 to 255 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_256_511_bytes_*
1 O Increment for good and bad packets transmitted
that contain 256 to 511 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_512_1023_bytes_*
1 O Increment for good and bad packets transmitted
that contain 512 to 1,023 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_1024_1518_bytes_*
1 O Increment for good and bad packets transmitted
that contain 1,024 to 1,518 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_1519_1522_bytes_*
1 O Increment for good and bad packets transmitted
that contain 1,519 to 1,522 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_1523_1548_bytes_*
1 O Increment for good and bad packets transmitted
that contain 1,523 to 1,548 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_1549_2047_bytes_*
1 O Increment for good and bad packets transmitted
that contain 1,549 to 2,047 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_2048_4095_bytes_*
1 O Increment for good and bad packets transmitted
that contain 2,048 to 4,095 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_4096_8191_bytes_*
1 O Increment for good and bad packets transmitted
that contain 4,096 to 8,191 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_tx_packet_8192_9215_bytes_*
1 O Increment for good and bad packets transmitted
that contain 8,192 to 9,215 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
ctl_rx_custom_preamble_enable_*
1 I When asserted, this signal causes the preamble
to be presented on rx_preambleout.
This port is available when the AXI4-Lite
interface is not selected and core type is
Ethernet MAC+PCS/PMA and Include FIFO
Logic is disabled)
stat_rx_packet_65_127_bytes_*
1 O Increment for good and bad packets received
that contain 65 to 127 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_128_255_bytes_*
1 O Increment for good and bad packets received
that contain 128 to 255 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_256_511_bytes_*
1 O Increment for good and bad packets received
that contain 256 to 511 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_512_1023_bytes_*
1 O Increment for good and bad packets received
that contain 512 to 1,023 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_1024_1518_bytes_*
1 O Increment for good and bad packets received
that contain 1,024 to 1,518 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_1519_1522_bytes_*
1 O Increment for good and bad packets received
that contain 1,519 to 1,522 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_1523_1548_bytes_*
1 O Increment for good and bad packets received
that contain 1,523 to 1,548 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_1549_2047_bytes_*
1 O Increment for good and bad packets received
that contain 1,549 to 2,047 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_2048_4095_bytes_*
1 O Increment for good and bad packets received
that contain 2,048 to 4,095 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_packet_4096_8191_bytes_*
1 O Increment for good and bad packets received
that contain 4,096 to 8,191 bytes.
stat_rx_packet_8192_9215_bytes_*
1 O Increment for good and bad packets received
that contain 8,192 to 9,215 bytes.
This port is available when core type is Ethernet
MAC+PCS/PMA.
stat_rx_test_pattern_mismatch_*
2 O Test pattern mismatch increment. A nonzero
value in any cycle indicates how many
mismatches occurred for the test pattern in the
RX core. This output is only active when
ctl_rx_test_pattern is set to a 1. This output can
be used to generate MDIO register 3.43.15:0 as
defined in Clause 82.3. This output is pulsed for
one clock cycle.
This port is available when core type is Ethernet
MAC+PCS/PMA.
Ports under this section are available when Enable TX Flow Control Logic is selected from the
MAC Options tab and the CORE type is Ethernet MAC+PCS/PMA.
ctl_tx_pause_refresh_timer0
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer1
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer2
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer3
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer4
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer5
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer6
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
ctl_tx_pause_refresh_timer7
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
ctl_tx_pause_refresh_timer8
16 I This bus sets the retransmission time of pause
packets for each of the eight priorities in priority-
based pause operation and the global pause
operation. The value for
ctl_tx_pause_refresh_timer[8] is used for global
pause operation. All other values are used for
priority pause operation.
This port is available when the AXI4-Lite
interface is not selected.
Ports under this section are available when Enable RX Flow Control Logic is selected from the
MAC Options tab and CORE type is Ethernet MAC+PCS/PMA.
Ports under this section are available when Enable_Time_Stamping is selected from the MAC
Options tab.
ctl_tx_ptp_vlane_adjust_mode_*
1 I Sets the vlan adjust mode.
This port is available when Include AXI4-Lite is
not selected in the Configuration tab.
stat_tx_ptp_fifo_read_error_*
1 O Transmit PTP FIFO write error. A 1 on this
status indicates that an error occurred during
the PTP Tag write. A TX Path reset is required to
clear the error.
stat_tx_ptp_fifo_write_error_*
1 O Transmit PTP FIFO read error. A 1 on this status
indicates that an error occurred during the PTP
Tag read. A TX Path reset is required to clear
the error.
Ports under this section are available when Include AN/LT Logic is selected from the
Configuration tab.
ctl_an_fec_25g_baser_request_*
1 I This signal is used to signal the link partner that
the local station is requesting clause 74 FEC on
the 25Gb/s lane protocols.
This port is available when the AXI4-Lite
interface is not selected.
ctl_an_ability_40gbase_cr4_* 1 I
ctl_an_ability_100gbase_cr10_*
1 I
ctl_an_ability_100gbase_kp4_*1 I
ctl_an_ability_100gbase_kr4_*1 I
ctl_an_ability_100gbase_cr4_*1 I
ctl_an_ability_25gbase_krcr_s_*
1 I
ctl_an_ability_25gbase_krcr_* 1 I
ctl_an_ability_25gbase_kr1_* 1 I
ctl_an_ability_25gbase_cr1_* 1 I
ctl_an_ability_50gbase_kr2_* 1 I
ctl_an_ability_50gbase_cr2_* 1 I
ctl_lt_k_m1_to_tx0_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update field that is transmitted to the
link partner in the control block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
ctl_lt_stat_m1_to_tx0_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update status that is transmitted to
ctl_lt_k_m1_to_tx1_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update field that is transmitted to the
link partner in the control block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
ctl_lt_stat_m1_to_tx1_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update status that is transmitted to
the link partner in the status block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
ctl_lt_k_m1_to_tx2_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update field that is transmitted to the
link partner in the control block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
ctl_lt_stat_m1_to_tx2_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update status that is transmitted to
the link partner in the status block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
ctl_lt_k_m1_to_tx3_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update field that is transmitted to the
link partner in the control block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
ctl_lt_stat_m1_to_tx3_* 2 I This 2-bit field is used to set the value of the k-1
coefficient update status that is transmitted to
the link partner in the status block of the training
frame.
This port is available when the AXI4-Lite
interface is not selected.
stat_an_link_cntl_1000base_kx_*
2 O Link Control outputs from the auto-negotiation
controller for the various Ethernet protocols.
stat_an_link_cntl_10gbase_kx4_*
2 O
Settings are as follows:
stat_an_link_cntl_10gbase_kr_*
2 O
00: DISABLE; PCS is disconnected
stat_an_link_cntl_40gbase_kr4_*
2 O 01: SCAN_FOR_CARRIER; RX is
connected to PCS
stat_an_link_cntl_40gbase_cr4_*
2 O 10: Not Used
11: ENABLE; PCS is connected for
stat_an_link_cntl_100gbase_cr10_*
2 O
mission mode
stat_an_link_cntl_100gbase_kp4_*
2 O
stat_an_link_cntl_100gbase_kr4_*
2 O
stat_an_link_cntl_100gbase_cr4_*
2 O
stat_an_link_cntl_25gbase_krcr_s_*
2 O
stat_an_link_cntl_25gbase_krcr_*
2 O
stat_an_link_cntl_25gbase_kr1_*
2 O
stat_an_link_cntl_25gbase_cr1_*
stat_an_link_cntl_50gbase_kr2_*
stat_an_link_cntl_50gbase_cr2_*
stat_an_parallel_detection_fault_*
1 O Indicates a parallel detection fault during auto-
negotiation.
stat_an_start_an_good_check_*
1 O This signal is asserted during
auto-negotiation for one AN_CLK period to
signal the start of the AN_GOOD_CHECK
phase, when the selected protocol has been
enabled, and the circuit is awaiting
rx_pcs_status.
stat_an_lp_ability_1000base_kx_*
1 O These signals indicate the advertised protocol
from the link partner. They all become valid
stat_an_lp_ability_10gbase_kx4_*
1 O
when the output signal stat_an_lp_ability_valid
stat_an_lp_ability_10gbase_kr_*
1 O is asserted. A value of 1 indicates that the
protocol is advertised as supported by the link
stat_an_lp_ability_40gbase_kr4_*
1 O partner.
stat_an_lp_ability_40gbase_cr4_*
1 O
stat_an_lp_ability_100gbase_cr10_*
1 O
stat_an_lp_ability_100gbase_kp4_*
1 O
stat_an_lp_ability_100gbase_kr4_*
1 O
stat_an_lp_ability_100gbase_cr4_*
1 O
stat_an_lp_ability_25gbase_krcr_s_*
1 O
stat_an_lp_ability_25gbase_krcr_*
1 O
stat_an_lp_fec_25g_rs_request_*
1 O This signal indicates that the link partner is
requesting the clause 91 (or 108) rs FEC be
used for the 25 Gb/s lane protocols. It becomes
valid when the output signal
stat_an_lp_ability_valid is asserted.
stat_an_lp_fec_25g_baser_request_*
1 O This signal indicates that the link partner is
requesting the clause 74 FEC be used for the
25 Gb/s lane base-r protocols. It becomes valid
when the output signal stat_an_lp_ability_valid
is asserted.
stat_an_lp_ability_25gbase_kr1_*
1 O Indicates the advertised protocol from the link
partner. Becomes valid when the output signal
stat_an_lp_extended_ability_valid is asserted. A
value of 1 indicates that the protocol is
advertised as supported by the link partner.
stat_an_link_cntl_25gbase_cr1_*
1 O Indicates the advertised protocol from the link
partner. Becomes valid when the output signal
stat_an_lp_extended_ability_valid is asserted. A
value of 1 indicates that the protocol is
advertised as supported by the link partner.
stat_an_lp_ability_50gbase_kr2_*
1 O Indicates the advertised protocol from the link
partner. Becomes valid when the output signal
stat_an_lp_extended_ability_valid is asserted. A
value of 1 indicates that the protocol is
advertised as supported by the link partner.
stat_an_lp_ability_50gbase_cr2_*
1 O Indicates the advertised protocol from the link
partner. Becomes valid when the output signal
stat_an_lp_extended_ability_valid is asserted. A
value of 1 indicates that the protocol is
advertised as supported by the link partner.
stat_an_lp_ability_extended_fec_*
4 O This output indicates the extended FEC abilities.
stat_an_lp_extended_ability_valid_*
1 O When this bit is 1, it indicates that the detected
extended abilities are valid.
Ports under this section are available when Clause 74 (BASE-KR FEC) is selected from the
Configuration tab.
stat_fec_inc_cant_correct_count_*
4 O This signal is asserted roughly every 32
words, while the ctl_rx_fec_enable is
asserted, if the FEC decoder detected bit
errors in the frame that it was unable to
correct.
Ports under this section are available when Clause 91 (RS-FEC) is selected from the
Configuration tab.
1: Enable RS-FEC
0: Bypass RS-FEC
ctl_rsfec_ieee_error_indication_mode_*
1 I Changes only take effect after the reset.
New value is sampled on the first cycle
after reset.
0: unlocked
1: locked
stat_tx_rsfec_lane_alignment_status_*
1 O TX PCS frame alignment status
0: unaligned
1: aligned
0: unlocked
1: locked
0: unlocked
1: locked
stat_rx_rsfec_lane_alignment_status_*
1 O RX alignment status
0: unaligned
1: aligned
stat_rx_rsfec_uncorrected_cw_inc_*
1 O Uncorrected codeword count increment
Ports under this section are available when the Runtime switch is selected from the
Configuration tab.
Figure: State Transition Diagram for Run Time Switchable DRP Operation without AN/LT
Figure: State Transition Diagram for Run Time Switchable DRP Operation with AN/LT
✎ Note: Run Time Switchable section is applicable for UltraScale/UltraScale+ devices only.
For Versal Adaptive SoC, you need to request a speed change by writing 1 to the
SWITCH_CORE_SPEED_REG: 013C register.
When you select the Include GT subcore in example design option in the GT Selection
and Configuration tab.
When you select the Include Shared Logic in Example Design option in the Shared Logic
tab.
When the shared logic in the example design is selected, a new l_ethernet_*_core_support.v
module is instantiated between the l_ethernet_*_exdes.v and DUT (that is, l_ethernet_*.v).
This module contains all the sub modules that can be shared between multiple designs.
The following figure shows the implementation when shared logic is instantiated in the
example design for a single core.
Figure: Single Core Example Design Hierarchy with Shared Logic Implementation
Figure: Multiple Core Example Design Hierarchy with Shared Logic Implementation
*_clocking_wrapper
This module contains all the clk resource which can be shared with other designs.
*_common_wrapper
This module contains the GT common which can be shared with other designs.
*_reset_wrapper
This module contains all the reset logics for the user specified Vivado IDE configuration.
.h Header File
AXI4 register information such as register address, register name with bit position, mask
value, access type and their default values are provided in the header (.h) file format when the
IP core is generated with Include AXI4-Lite enabled in the Vivado Design Suite and the header
file can be found under the folder header_files of the project path.
The read and write through the AXI4-Lite slave module interface is controlled by a state
machine as shown in the following figure:
IDLE_STATE
By default, the FSM is in IDLE_STATE. When the user_read_req signal becomes High,
it moves to READ_STATE else if user_write_req signal is High, it moves to
WRITE_STATE else it remains in IDLE_STATE.
WRITE_STATE
You provide S_AXI_AWVALID, S_AXI_AWADDR, S_AXI_WVALID, S_AXI_WDATA, and
S_AXI_WSTRB in this state to write to the register map through AXI. When S_AXI_BVALID
and S_AXI_BREADY from AXI slave are High, it moves to ACK_STATE. If any write
operation happens in any illegal addresses, the S_AXI_BRESP[1:0] indicates 2'b10 that
asserts the write error signal.
READ_STATE
You provide S_AXI_ARVALID and S_AXI_ARADDR in this state to read from the register
map through AXI. When S_AXI_RVALID and S_AXI_RREADY are High, it moves to
ACK_STATE. If any read operation happens from any illegal addresses, the
S_AXI_RRESP[1:0] indicates 2'b10 that asserts the read error signal.
ACK_STATE
The state moves to IDLE_STATE.
S_AXI_WVALID 1 I AXI write data valid. This signal indicates that valid
write data and strobes are available.
The following figures show timing diagram waveforms for the AXI4-Lite interface.
Figure: AXI4-Lite User Side Write Transaction with Invalid Write Address
Figure: AXI4-Lite User Side Read Transaction with Invalid Read Address
This feature enables the IEEE Clause 91 RS-FEC soft IP component instantiated in between
the 50G core and the GT. The TX SerDes lines from the 50G core is input to the RS-FEC soft
IP for forward error correction encoding. The output from the RS-FEC module is fed to the GT.
Similarly, the RX SerDes lines from the GT is fed to the RS-FEC module for error correction
decoding and then to the 50G core.
Refer to the 50G IEEE 802.3 Reed-Solomon Forward Error Correction LogiCORE IP Product
Guide (PG234) (registration required) for IEEE clause 91 Reed-Solomon Forward Error
Correction for the AMD LogiCORE™ IP core and its functionality.
Test Bench
Each release includes a demonstration test bench that performs a loopback test on the
complete 40G/50G High Speed Ethernet Subsystem. The test program exercises the datapath
to check that the transmitted frames are received correctly. RTL simulation models for the
40G/50G High Speed Ethernet Subsystem are included. You must provide the correct path for
the transceiver simulation model according to the latest simulation environment settings in
your version of the AMD Vivado™ Design Suite.
Upgrading
The following sections describe the changes for each release.
Port Changes
Corrected port name from rx_serdes_resetn to rx_serdes_reset in figure in Port
Descriptions.
Added text about 2-step 1588 operation to tx_ptp_tstamp_out[80-1:0] and
tx_ptp_tstamp_out_* descriptions.
ctl_tx_ptp_latency_adjust[10:0] signal
Deleted sentence about 802 decimal clock mode value.
Updated axi_ctl_core_mode_switch to update 0x018C to 0x013C.
Changed name from restart_tx_rx_0 to restart_tx_rx_*
Ports Added
tx_ptp_upd_chksum_in
tx_ptp_pcslane_out
tx_ptp_chksum_offset_in
rx_ptp_pcslane_out
rx_lane_aligner_fill
rx_ptp_tstamp_valid_out
Ports Removed
tx_ptp_rxtstamp_in
tx_ptp_rxtstamp_in
Registers Added
STAT_CORE_SPEED_REG: 047C
user_reg0_*
RXOUTCLKSEL_IN_*
TXOUTCLKSEL_IN_*
Registers Deleted
USER_REG_1: 0188
CORE_SPEED_REG:180
Ports Added
Added gtpowergood_out_*.
Features Added
256-bit AXI4-Stream Packet interface for 40Gb/s MAC+PCS.
Features Updated
Auto-negotiation and Link Training with reduced resource utilization.
Ports Added
stat_tx_underflow_err
stat_tx_overflow_err
Ports Updated
tx_axis_tvalid
tx_mii_reset
rx_mii_clk
gt_refclk_out
tx_mii_d_*
tx_mii_c_*
rx_mii_d_*
rx_mii_c_*
axi_ctl_core_mode_switch
Register Added
STAT_STATUS_REG1: 0408
Ports Added
ctl_tx_ptp_1step_enable_*
ctl_tx_ptp_latency_adjust_*
ctl_tx_ptp_vlane_adjust_mode_*
ctl_ptp_transpclk_mode_*
tx_ptp_upd_chksum_in_*
tx_ptp_chksum_offset_in_*
tx_ptp_rxtstamp_in_*
stat_an_rxcdrhold_*
gt_drp_done_0
ctl_rate_mode_0
txpllclksel_in_0
rxpllclksel_in_0
txsysclksel_in_0
rxsysclksel_in_0
Rxafecfoken_0
Rxdfecfokfcnum_0
Speed_0
anlt_done_0
rxdata_out_0
txdata_in_0
Ports Added
ctl_gt_reset_all_*
ctl_gt_reset_*
ctl_gt_rx_reset_*
gt_reset_all_in_*
gt_tx_reset_in_*
gt_rx_reset_in_*
ctl_an_fec_25g_rs_request
ctl_an_fec_25g_baser_request
stat_an_lp_fec_25g_rs_request
stat_an_lp_fec_25g_baser_request
tx_ptp_rxtstamp_in
rx_ptp_pcslane_out_*
ctl_an_fec_25g_baser_request_*
Ports Removed
stat_tx_underflow_err
Port Changes
rx_serdes_reset_done_in_* to rx_serdes_reset_*.
SERDES_WIDTH with 64 for several I/O ports.
ctl_an_ability_25gbase_cr to ctl_an_ability_25gbase_krcr
ctl_an_ability_25gbase_kr to ctl_an_ability_25gbase_krcr_s
ctl_an_fec_request to ctl_an_fec_10g_request. Updated description.
stat_rx_errored_block_increment_valid to stat_rx_bad_code_valid
stat_rx_bad_sh_increment_0[3:0] to stat_rx_framing_err_0[3:0]
stat_rx_bad_sh_increment_1[3:0] to stat_rx_framing_err_1[3:0]
stat_rx_bad_sh_increment_2[3:0] to stat_rx_framing_err_2[3:0]
stat_rx_bad_sh_increment_3[3:0] to stat_rx_framing_err_3[3:0]
stat_rx_bad_sh_increment_valid_1 to stat_rx_valid_1
stat_rx_bad_sh_increment_valid_2 to stat_rx_valid_2
stat_rx_bad_sh_increment_valid_3 to stat_rx_valid_3
rx_axis_tuser_0 to rx_axis_tuser_*
Debugging
This appendix includes details about resources available on the AMD Support website and
debugging tools.
Documentation
This product guide is the main document associated with the subsystem. This guide, along
with documentation related to all products that aid in the design process, can be found on the
AMD Adaptive 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.
Answer Records
Product name
Tool message(s)
Summary of the issue encountered
A filter search is available after results are returned to further target the results.
Master Answer Record for the 40G/50G High Speed Ethernet Subsystem
AR 54690.
Technical Support
AMD Adaptive Computing provides technical support on the Community Forums for this AMD
LogiCORE™ IP product when used as described in the product documentation. AMD Adaptive
Computing cannot guarantee timing, functionality, or support if you do any of 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.
Debug Tools
There are many tools available to address 40G/50G High Speed Ethernet design issues. It is
important to know which tools are useful for debugging various situations.
Example Design
The High Speed Ethernet IP core is delivered with an example design netlist complete with
functional test benches. The design includes example transceivers and loopback tests for
common simulator programs.
The AMD Vivado™ Design Suite debug feature inserts logic analyzer and virtual I/O cores
directly into your design. The debug feature also allows you to set trigger conditions to capture
application and integrated block port signals in hardware. Captured signals can then be
analyzed. This feature in the Vivado IDE is used for logic debugging and validation of a design
running in AMD devices.
The Vivado logic analyzer is used to interact with the logic debug LogiCORE IP cores,
including:
See the Vivado Design Suite User Guide: Programming and Debugging (UG908).
Reference Boards
Various AMD development boards support the 40G/50G High Speed Ethernet core. These
boards can be used to prototype designs and establish that the core can communicate with
the system.
AMD UltraScale™ devices are recommended for optimum performance. Ensure that the board
transceivers support the required Ethernet bit rate. For example, the following board is suitable
for many AMD UltraScale™ implementations: UltraScale FPGA evaluation board, VCU108.
Simulation Debug
Each High Speed Ethernet IP core release includes a sample simulation test bench. This
typically consists of a loopback from the TX side of the user interface, through the TX circuit,
looping back to the RX circuit, and checking the received packets at the RX side of the user
interface.
Each release usually includes a sample instantiation of an AMD transceiver corresponding to
the device selected by the customer. The loopback simulation includes a path through the
transceiver.
If the simulator does not launch, you might not have a valid license. Ensure that the license is
up to date. It is also possible that your organization has a license available for one of the other
simulators, so try all the provided scripts.
Each simulation script calls up the required AMD library files. These are called by the
corresponding liblist* file in the bin directory of each release.
There can be an error message indicating that the simulator is unable to find certain library
files. In this case, the path to the library files might have to be modified. Check with your IT
administrator to ensure that the paths are correct.
Version Compatibility
Each release has been tested according the AMD tools version requested by customers. If the
simulation does not complete successfully, you should first ensure that a properly up-to-date
version of the AMD tools is used. The preferred version is indicated in the README file of the
release, and is also indicated in the simulation sample log file included with the release.
Slow Simulation
If the sample simulation fails or hangs before successfully completing, it is possible that a
timeout has occurred. Ensure that the simulator timeouts are long enough to accommodate
the waiting periods in the simulation, for example, during the lane alignment phase. See
Simulation for more details.
If the sample simulation completes with a failure, contact AMD technical support. Each release
is tested prior to shipment and normally completes successfully. Consult the sample simulation
log file for the expected behavior.
Hardware Debug
Hardware issues can range from link bring-up to problems seen after hours of testing. This
section provides debug steps for common issues. The AMD Vivado™ debug feature is a
valuable resource to use in hardware debug. The signal names mentioned in the following
individual sections can be probed using the debug feature for debugging the specific
problems.
Many of these common issues can also be applied to debugging design simulations. Details
are provided in the following sections:
General Checks
Transceiver Specific Checks
Ethernet Specific Checks
General Checks
Ensure that all the timing constraints for the core were properly incorporated from the example
design and that all constraints were met during implementation.
Does it work in post-place and route timing simulation? If problems are seen in hardware
but not in timing simulation, this could indicate a PCB issue. Ensure that all clock sources
are active and clean.
If using MMCMs in the design, ensure that all MMCMs have obtained lock by monitoring
the locked port.
If your outputs go to 0, check your licensing.
Ensure that the polarities of the txn/txp and rxn/rxp lines are not reversed. If they are,
these can be fixed by using the TXPOLARITY and RXPOLARITY ports of the transceiver.
Check that the transceiver is not being held in reset or still being initialized. The
RESETDONE outputs from the transceiver indicate when the transceiver is ready.
Place the transceiver into parallel or serial near-end loopback.
If correct operation is seen in the transceiver serial loopback, but not when loopback is
performed through an optical cable, it might indicate a faulty optical module.
If the core exhibits correct operation in the transceiver parallel loopback but not in serial
loopback, this might indicate a transceiver issue.
A mild form of bit error rate might be solved by adjusting the transmitter Pre-Emphasis
and Differential Swing Control attributes of the transceiver.
Several issues can commonly occur during the first hardware test of an Ethernet IP core.
These should be checked as indicated in the following subsections.
It is assumed that the Ethernet IP core has already passed all simulation testing which is being
implemented in hardware. This is a prerequisite for any kind of hardware debug.
The usual sequence of debugging is to proceed in the following sequence:
Signal Integrity
When bringing up a board for the first time and the High Speed Ethernet IP core does not
seem to be achieving lane alignment, the most likely issue is related to signal integrity.
‼ Important: Signal integrity issues must be addressed before any other debugging can take
place.
Even if lane alignment is achieved, if there are periodic bip-8 errors, signal integrity issues are
indicated. Check the bip-8 signals to assist with debug.
Signal integrity should be debugged independently from the High Speed Ethernet IP core. The
following procedures should be carried out.
✎ Note: It assumed that the PCB itself has been designed and manufactured in accordance
with the required trace impedances and trace lengths, including the requirements for skew set
out in the IEEE Standard for Ethernet (IEEE Std 802.3-2015).
Transceiver settings
Checking for noise
Bit error rate testing
If assistance is required for transceiver and signal integrity debugging, contact AMD technical
support.
Lane Swapping
In Ethernet, physical lanes can be swapped and the protocol aligns lanes correctly. Therefore,
lane swapping should not cause any problems.
✎ Note: Auto-Negotiation is only performed on one lane. Therefore, by convention, for multi-
lane Ethernet protocols, lane 0 is used for AN. AN protocol does not allow lanes to be
swapped, lane 0 must connect to lane 0 of the link partner.
If the positive and negative signals of a differential pair are swapped, data is not received
correctly on that lane. You should verify that each link has the correct polarity of each
differential pair.
Interface Debug
AXI4-Stream Interfaces
The High Speed Ethernet IP core user interface is called the AXI4-Stream. There are two
versions used — regular AXI4-Stream and straddled AXI4-Stream. 50 Gb/s operation allows
use of only straddled AXI4-Stream whereas 40 Gb/s operation provides an option of 256-bit
regular AXI4-Stream in addition to the 128-bit straddled interface. See the appropriate section
in this guide for a detailed description of each.
For a detailed description of the diagnostic signals which are available to debug the RX, see
Port Descriptions.
If the Ethernet packets are being transmitted properly according to IEEE Std 802.3-2015, there
should not be RX errors. However, the signal integrity of the received signals must be verified
first.
The stat_rx_bip_err signals provide a per-lane indicator of signal quality. The
stat_rx_hi_ber signal is asserted when the bit error rate is too high, according to IEEE Std
802.3-2015. The threshold is BER = 10–4.
To aid in debug, GT near-end PMA loopback can be performed with the gt_loopback_in
signal. This connects the TX SerDes to the RX SerDes, effectively bypassing potential signal
integrity problems. In this way, the received data can be checked against the transmitted
packets to verify that the logic is operating properly.
Related Information
Port Descriptions
Protocol Debug
To achieve error-free data transfers with the Ethernet IP core, the IEEE Std 802.3-2015 should
be followed. Signal integrity should always be ensured before proceeding to the protocol
debug.
According to IEEE Std 802.3-2015, the alignment marker spacing should be set to 16,383 for
both the TX and RX. Check that both ends of the link are programmed to this value.
Diagnostic Signals
There are many error indicators available to check for protocol violations. Carefully read the
description of each one to see if it is useful for a particular debugging problem.
The following is a suggested debug sequence.
Statistics Counters
When error-free communication has been achieved, the statistics indicators can be monitored
to ensure that traffic characteristics meet expectations. Some signals are strobes only, which
means that the counters are not part of the IP core. This is done so you can customize the
counter size. The counters are optional.
Auto-Negotiation
To enable auto-negotiation:
ctl_autoneg_enable = 1
ctl_autoneg_bypass = 0
Link Training
To enable link training set ctl_lt_training_enable to 1.
The core does not actually do any training. It only provides the control protocol required
by section 72.6.10. The training algorithm is a user responsibility.
The core does not monitor the RX eye nor does it send any presets, initializations, or
coefficient control requests to the link partner TX. It is recommended to set
ctl_lt_rx_trained to 1. Setting ctl_lt_rx_trained tells the link partner that your RX
training is completed, and that you do not send any more presets, initializations, or
coefficient changes.
The core does not adjust any of the GT TX amplitude or coefficient control settings in
response to any training messages received from the link partner. The example design
link training Place_Holder logic indicates that maximum limits are reached. This should
allow link training to complete.
Nonce
nonce_seed must be set to a non-zero value.
If connecting two ports with same nonce seed on the same board, resets must be
released at different times.
If the nonce_seed is changed, an an_reset is needed to load the new value. This
includes changing nonce_seed using the AXI4-Lite registers.
Next Pages
If the link partner sends next page, ctl_an_loc_np_ack must be set High to acknowledge the
next page and allow auto-negotiation to complete. This control signal can be set High after
next page is received or tied always High.
stat_fec_inc_cant_correct_count
stat_fec_lock_error
stat_fec_rx_lock
stat_fec_inc_correct_count
ctl_an_fec_10g_request
ctl_fec_rx_enable
ctl_fec_tx_enable
stat_an_fec_enable
stat_an_lp_fec_10g_ability
stat_an_lp_fec_10g_request
ctl_tx_rsfec_enable
ctl_rx_rsfec_enable
stat_rx_rsfec_am_lock
stat_an_rs_fec_enable
✎ Note: If the link partner sends next pages, the ctl_an_lo_np_ack signal must be set. This
port can be tied High.
Related Information
Displayed in the footer
Page 338 of 352
40G/50G High Speed Ethernet Subsystem Product Guide (PG211)
Displayed in the header
Board Testing of the 40G/50G High Speed Ethernet Using the AXI4-Lite Interface
To debug auto-negotiation and link training using the AXI4-Lite interface, see Board Testing of
the 40G/50G High Speed Ethernet Using the AXI4-Lite Interface.
TX Pause Generation
You can request a pause packet to be transmitted using the ctl_tx_pause_req[8:0] and
ctl_tx_pause_enable[8:0] input buses. Bit [8] corresponds to global pause packets and
bits [7:0] correspond to priority pause packets.
‼ Important: Requesting both global and priority pause packets at the same time results
inunpredictable behavior and must be avoided.
The contents of the pause packet are determined using the following input pins.
Global pause packets:
ctl_tx_da_gpp[47:0]
ctl_tx_sa_gpp[47:0]
ctl_tx_ethertype_gpp[15:0]
ctl_tx_opcode_gpp[15:0]
ctl_tx_pause_quanta8[15:0]
ctl_tx_da_ppp[47:0]
ctl_tx_sa_ppp[47:0]
ctl_tx_ethertype_ppp[15:0]
ctl_tx_opcode_ppp[15:0]
ctl_tx_pause_quanta0[15:0]
ctl_tx_pause_quanta1[15:0]
ctl_tx_pause_quanta2[15:0]
ctl_tx_pause_quanta3[15:0]
ctl_tx_pause_quanta4[15:0]
ctl_tx_pause_quanta5[15:0]
ctl_tx_pause_quanta6[15:0]
ctl_tx_pause_quanta7[15:0]
RX Pause Termination
The 40G/50G High Speed Ethernet Subsystem terminates global and priority pause frames
and provides a simple hand-shaking interface to allow user logic to respond to pause packets.
For step 1, the following pseudo code shows the checking function:
Where DA is the destination address, SA is the source address, OPCODE is the opcode, and
ETYPE is the ethertype/length field that are extracted from the incoming packet.
For step 2, the following pseudo code shows the checking function:
Where DA is the destination address, SA is the source address, OPCODE is the opcode, and
ETYPE is the ethertype/length field that are extracted from the incoming packet.
For step 3, the following pseudo code shows the checking function:
Where DA is the destination address, SA is the source address, OPCODE is the opcode, and
ETYPE is the ethertype/length field that are extracted from the incoming packet.
User Interface
A simple handshaking protocol is used to alert you of the reception of pause packets using the
ctl_rx_pause_enable[8:0], stat_rx_pause_req[8:0] and ctl_rx_pause_ack[8:0]
buses. For both buses, Bit [8] corresponds to global pause packets and bits [7:0] correspond
to priority pause packets.
The following steps occur when a pause packet is received:
If you do not set the appropriate bit of ctl_rx_pause_ack[8:0] back to 0, the 40G/50G High
Speed Ethernet Subsystem deems the operation complete after 32 clock cycles.
The preceding steps are demonstrated in the following figure with each step shown on the
waveform.
1 3
stat_rx_pause_req[n]
4
stat_rx_pause_ack[n]
5
2 X16602-080621
If at any time during step 2 to step 5 a new pause packet is received, the timer is loaded with
the newly acquired quanta value and the process continues.
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:
References
These documents provide supplemental material useful with this guide:
Revision History
The following table shows the revision history for this document.
Common Transceiver Ports for Versal Updated the table in the section.
Adaptive SoC
RX and TX PCS Lane Marker Values Updated the table in the section.
Overview Updated
Standards Updated
References Updated
Copyright
© Copyright 2016-2025 Advanced Micro Devices, Inc. AMD, the AMD Arrow logo, Artix, Kintex,
Kria, UltraScale, UltraScale+, Versal, Virtex, Vivado, Zynq, and combinations thereof are
trademarks of Advanced Micro Devices, Inc. AMBA, AMBA Designer, Arm, ARM1176JZ-S,
CoreSight, Cortex, PrimeCell, Mali, and MPCore are trademarks of Arm Limited in the US
and/or elsewhere. PCI, PCIe, and PCI Express are trademarks of PCI-SIG and used under
license. Other product names used in this publication are for identification purposes only and
may be trademarks of their respective companies.