GTS Ethernet Hard IP User Guide: Agilex™ 5 FPGAs and SoCs
ID
817676
Date
8/04/2025
Public
1. Overview
2. Install and License the GTS Ethernet Hard IP
3. Configure and Generate Ethernet Hard IP variant
4. Integrate GTS Ethernet Hard IP into Your Application
5. Simulate, Compile, and Validate (MAC+PCS) - Single Instance
6. Simulate, Compile, and Validate (MII PCS Only/PCS66 OTN/PCS66 FlexE) - Single Instance
7. Simulate, Compile, and Validate SyncE - Single Instance
8. Simulate and Compile PTP1588 - Single Instance
9. Simulate, Compile, and Validate - Multiple Instance
10. Simulate, Compile, and Validate (Dynamically Reconfigurable Ethernet Mode)
11. Simulate, Compile, and Validate - Auto-Negotiation and Link Training
12. Troubleshoot and Diagnose Issues
13. Appendix A: Functional Description
14. Appendix B: Configuration Registers
15. Appendix C: Document Revision History for the GTS Ethernet Hard IP User Guide: Agilex™ 5 FPGAs and SoCs
4.1. Implement Required Clocking
4.2. Implement Required Resets
4.3. Connect the Status Interface
4.4. Connect the MAC Avalon Streaming Client Interface
4.5. Connect the MII PCS Only Client Interface
4.6. Connect the PCS66 Client Interface – FlexE and OTN
4.7. Connect the Precision Time Protocol Interface
4.8. Connect the Ethernet Hard IP Reconfiguration Interface
4.9. Connect the Auto-Negotiation and Link Training
4.10. Connect the Multirate Auto-Negotiation and Link Training
4.11. Connect the Dynamically Reconfigurable Ethernet Mode
4.1.1. Implement MAC Synchronous Clock Connections to Single Instance
4.1.2. Implement MAC Synchronous Clock Connections to Multiple Instances
4.1.3. Implement Clock Connections to MAC Asynchronous Operation
4.1.4. Implement Clock Connections in Synchronous Ethernet Operation (Sync-E)
4.1.5. Implement Clock Connections in PTP-Based Design
4.4.1.1. Drive the Ethernet Packet to the TX MAC Avalon Streaming Client Interface with Disabled Preamble Passthrough
4.4.1.2. Drive the Ethernet Packet on the TX MAC Avalon Streaming Client Interface with Enabled Preamble Passthrough
4.4.1.3. Use i_tx_skip_crc to Control Source Address, PAD, and CRC Insertion
4.4.1.4. Assert the i_tx_error to Invalidate a Packet
4.4.2.1. Receive Ethernet Frame on the RX MAC Avalon Streaming Client Interface with Preamble Passthrough Disabled
4.4.2.2. Receive Ethernet Frame with Preamble Passthrough Enabled
4.4.2.3. Receive Ethernet Frame with Remove CRC bytes Disabled
4.4.2.4. Monitor Status and Errors on the RX MAC Avalon Streaming Client Interface
11.1. Auto-Negotiation and Link Training for General Ethernet Mode
11.2. Multirate Auto-Negotiation and Link Training for Reconfigurable Mode AN/LT
11.3. Design Example Features
11.4. Design Example Components
11.5. Simulate the Design Example
11.6. Compile the Design Example
11.7. Validate the Design Example
4.3. Connect the Status Interface
The GTS Ethernet Hard IP core provides status signals to support visibility into the state of the IP core and the stability of IP core output clocks.
Figure 28. GTS Ethernet Hard IP Status Signals
Signal | Description |
---|---|
Input signals | |
i_stats_snapshot | Assert this signal to sample the current state of the statistics registers. Refer to Use i_stats_snapshot to Read Stats Counters for an example.
|
Output signals | |
o_rx_block_lock | Indicates 66-bit block alignment for non-FEC and Firecode FEC variant and indicates codeword alignment for RS-FEC variant. |
o_local_fault_status | Asserted when the RX MAC detects a local fault: the RX PCS detected a problem that prevents it from receiving data. |
o_remote_fault_status | Asserted when the RX MAC detects a remote fault: the remote link partner has sent remote fault ordered sets indicating that it is unable to receive data. |
o_rx_hi_ber | Asserted to indicate the RX PCS is in a High BER state. The IP core uses this signal in auto negotiation and link training. |
o_rx_pcs_fully_aligned | Asserted when RX PCS is ready to receive data. This signal is only valid in PCS66 and PCS modes |
Note: For the 2-port MAC with shared PTP in Agilex™ 5 D series device, the status interface signals are suffixed with _p0 and _p1 to distinguish between the two ports.
The diagram below shows the behavior of o_local_fault_status and o_remote_fault_status at startup.
Figure 29. Status Interface Behavior During Link Startup with Bidirectional Link FaultThe waveform displays the status signal behavior in the IP core at the startup.
Consider the following:
- o_sys_pll_locked qualifies all of the signals in the above diagram.
- o_tx_lanes_stable qualifies the following signals:
- o_local_fault_status
- o_remote_fault_status
- o_tx_ready or o_tx_mii_ready.
- The IP asserts o_local_fault_status and o_remote_fault_status at startup and keeps them high until both sides of the channel are ready.
- o_local_fault_status stays high until the RX PCS is ready to receive data.
- o_remote_fault_status stays high until the remote link partner indicates it can receive data.
- o_tx_ready and o_tx_mii_ready stay low until o_local_fault_status and o_remote_fault_status are asserted.
When the core is in PCS-Only mode, or Link Fault is set to Unidirectional or Off, the figure below shows how the status signal typically behaves at startup.
Figure 30. Status Interface Behavior during Link Startup with Unidirectional or Link Fault DisableThe waveform displays status signals behavior in the IP core at the startup.
Consider the following:
- o_sys_pll_locked qualifies all of the signals in the above timing diagram.
- o_tx_lanes_stable qualifies o_tx_ready or o_tx_mii_ready.
- o_tx_ready and o_tx_mii_ready do not wait for the status of the RX PCS.
Note: If link fault is set to Unidirectional mode, o_local_fault_status and o_remote_fault_status indicates the link fault status for the core, but the link fault status does not affect the TX channel.