40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide

Download PDF
ID 683114
Date 6/15/2022
Public
Document Table of Contents
Document Table of Contents x
Product Discontinuance Notification 1. About the 40- and 100-Gbps Ethernet MAC and PHY IP Core 2. Getting Started 3. Functional Description 4. Debugging the 40GbE and 100GbE Link A. 40-100GbE IP Core Example Design B. Address Map Changes for the 40-100GbE IP Core v12.0 Release C. 10GBASE-KR Registers D. Additional Information
1. About the 40- and 100-Gbps Ethernet MAC and PHY IP Core x
1.1. 40- and 100-Gbps Ethernet MAC and PHY IP Core Supported Features 1.2. 40-100GbE IP Core Device Family and Speed Grade Support 1.3. IP Core Verification 1.4. Performance and Resource Utilization 1.5. Release Information
1.2. 40-100GbE IP Core Device Family and Speed Grade Support x
1.2.1. Device Family Support 1.2.2. 40-100GbE IP Core Device Speed Grade Support
1.3. IP Core Verification x
1.3.1. Simulation Environment 1.3.2. Hardware Testing
1.4. Performance and Resource Utilization x
1.4.1. Resource Utilization for 40GbE IP Cores 1.4.2. Resource Utilization for 100GbE IP Cores
1.4.2. Resource Utilization for 100GbE IP Cores x
1.4.2.1. Resource Utilization for 100GbE CAUI–4 IP Cores
2. Getting Started x
2.1. Installing and Licensing Intel® FPGA IP Cores 2.2. Specifying the 40-100GbE IP Core Parameters and Options 2.3. IP Core Parameters 2.4. Files Generated for the 40-100GbE IP Core 2.5. Simulating the IP Core 2.6. Integrating Your IP Core in Your Design 2.7. 40-100GbE IP Core Testbenches 2.8. Simulating the 40‑100GbE IP Core With the Testbenches 2.9. Compiling the Full Design and Programming the FPGA 2.10. Initializing the IP Core
2.1. Installing and Licensing Intel® FPGA IP Cores x
2.1.1. Intel® FPGA IP Evaluation Mode
2.6. Integrating Your IP Core in Your Design x
2.6.1. Pin Assignments 2.6.2. External Transceiver Reconfiguration Controller Required in Stratix V Designs 2.6.3. Placement Settings for the 40-100GbE IP Core
2.7. 40-100GbE IP Core Testbenches x
2.7.1. Testbenches with Adapters 2.7.2. Testbenches without Adapters 2.7.3. Understanding the Testbench Behavior
2.8. Simulating the 40‑100GbE IP Core With the Testbenches x
2.8.1. Generating the Testbench 2.8.2. Simulating with the Modelsim Simulator 2.8.3. Simulating with the NCSim Simulator 2.8.4. Simulating with the VCS Simulator 2.8.5. Testbench Output Example: 40GbE IP Core with Adapters 2.8.6. Testbench Output Example: 100GbE IP Core with Adapters
3. Functional Description x
3.1. High Level System Overview 3.2. 40-100GbE MAC and PHY Functional Description 3.3. Signals 3.4. Software Interface: Registers 3.5. Ethernet Glossary
3.2. 40-100GbE MAC and PHY Functional Description x
3.2.1. IP Core TX Datapath 3.2.2. IP Core TX Data Bus Interfaces 3.2.3. 40-100GbE IP Core RX Datapath 3.2.4. IP Core RX Data Bus Interfaces 3.2.5. 40GbE Lower Rate 24.24 Gbps MAC and PHY 3.2.6. 100GbE CAUI–4 PHY 3.2.7. External Reconfiguration Controller 3.2.8. Congestion and Flow Control Using Pause Frames 3.2.9. Pause Control and Generation Interface 3.2.10. Pause Control Frame and Non‑Pause Control Frame Filtering and Forwarding 3.2.11. 40-100GbE IP Core Modes of Operation 3.2.12. Link Fault Signaling Interface 3.2.13. Statistics Counters Interface 3.2.14. MAC – PHY XLGMII or CGMII Interface 3.2.15. Lane to Lane Deskew Interface 3.2.16. PCS Test Pattern Generation and Test Pattern Check 3.2.17. Transceiver PHY Serial Data Interface 3.2.18. 40GBASE-KR4 IP Core Variations 3.2.19. Control and Status Interface 3.2.20. Clocks 3.2.21. Resets
3.2.1. IP Core TX Datapath x
3.2.1.1. Preamble, Start, and SFD Insertion 3.2.1.2. Address Insertion 3.2.1.3. Length/Type Field Processing 3.2.1.4. Frame Padding 3.2.1.5. Frame Check Sequence (CRC-32) Insertion 3.2.1.6. Inter‑Packet Gap Generation and Insertion
3.2.2. IP Core TX Data Bus Interfaces x
3.2.2.1. 40-100GbE IP Core User Interface Data Bus 3.2.2.2. 40-100GbE IP Core TX Data Bus with Adapters (Avalon-ST Interface) 3.2.2.3. 40-100GbE IP Core TX Data Bus Without Adapters (Custom Streaming Interface) 3.2.2.4. Bus Quantization Effects With Adapters 3.2.2.5. User Interface to Ethernet Transmission
3.2.2.5. User Interface to Ethernet Transmission x
3.2.2.5.1. 40GbE IP Core Without Adapters 3.2.2.5.2. 100GbE IP Core Without Adapters 3.2.2.5.3. Order of Transmission
3.2.3. 40-100GbE IP Core RX Datapath x
3.2.3.1. 40-100GbE IP Core RX Filtering 3.2.3.2. 40-100GbE IP Core Preamble Processing 3.2.3.3. 40-100GbE IP Core FCS (CRC-32) Removal 3.2.3.4. 40-100GbE IP Core CRC Checking 3.2.3.5. RX CRC Forwarding 3.2.3.6. RX Automatic Pad Removal Control 3.2.3.7. Address Checking 3.2.3.8. Inter-Packet Gap 3.2.3.9. Pause Ignore
3.2.4. IP Core RX Data Bus Interfaces x
3.2.4.1. 40-100GbE IP Core User Interface Data Bus 3.2.4.2. 40-100GbE IP Core RX Data Bus with Adapters (Avalon-ST Interface) 3.2.4.3. 40-100GbE IP Core RX Data Bus Without Adapters (Custom Streaming Interface) 3.2.4.4. 100GbE IP Core RX Client Interface Examples Example on RX Client Interface Without Preamble Pass-Through Example on RX Client Interface With Preamble Pass-Through 3.2.4.5. Error Conditions on the RX Datapath
3.2.8. Congestion and Flow Control Using Pause Frames x
3.2.8.1. Conditions Triggering XOFF Frame Transmission 3.2.8.2. Conditions Triggering XON Frame Transmission 3.2.8.3. Pause Transmission Logic
3.2.14. MAC – PHY XLGMII or CGMII Interface x
3.2.14.1. MAC to PHY Connection Interface
3.2.17. Transceiver PHY Serial Data Interface x
3.2.17.1. PCS BER Monitor
3.2.18. 40GBASE-KR4 IP Core Variations x
3.2.18.1. 40GBASE-KR4 Reconfiguration Interface 3.2.18.2. 40GBASE-KR4 Microprocessor Interface
3.3. Signals x
3.3.1. Signals of MAC and PHY Variations Without Adapters 3.3.2. Signals of MAC and PHY Variations With Adapters 3.3.3. Signals of 40-100GbE MAC‑Only IP Core Variations 3.3.4. Signals of 40-100GbE PHY‑Only IP Core Variations
3.4. Software Interface: Registers x
3.4.1. IP Core Registers 3.4.2. 40‑100GbE Example Design Registers
3.4.1. IP Core Registers x
3.4.1.1. Transceiver PHY Control and Status Registers 3.4.1.2. Lock Status Registers 3.4.1.3. Bit Error Flag Registers 3.4.1.4. PCS Hardware Error Register 3.4.1.5. BER Monitor Register 3.4.1.6. Test Mode Register 3.4.1.7. Test Pattern Counter Register 3.4.1.8. Link Fault Signaling Registers 3.4.1.9. MAC and PHY Reset Registers 3.4.1.10. PCS‑VLANE Registers 3.4.1.11. PRBS Registers 3.4.1.12. 40GBASE-KR4 Registers 3.4.1.13. MAC Configuration and Filter Registers 3.4.1.14. Pause Registers 3.4.1.15. MAC Hardware Error Register 3.4.1.16. CRC Configuration Register 3.4.1.17. MAC Feature Configuration Registers 3.4.1.18. MAC Address Registers 3.4.1.19. Statistics Registers
3.4.2. 40‑100GbE Example Design Registers x
3.4.2.1. PMD Registers 3.4.2.2. MDIO Registers 3.4.2.3. 2‑Wire Serial Interface Registers
C. 10GBASE-KR Registers x
C.1. 10GBASE-KR PHY Register Definitions
D. Additional Information x
D.1. 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide Revision History D.2. How to Contact Altera D.3. Typographic Conventions
Product Discontinuance Notification
1. About the 40- and 100-Gbps Ethernet MAC and PHY IP Core
2. Getting Started
3. Functional Description
4. Debugging the 40GbE and 100GbE Link
A. 40-100GbE IP Core Example Design
B. Address Map Changes for the 40-100GbE IP Core v12.0 Release
C. 10GBASE-KR Registers
D. Additional Information

3.2.4.4. 100GbE IP Core RX Client Interface Examples

Example on RX Client Interface Without Preamble Pass-Through

Figure 34. Typical Traffic on the RX Client Interface for 100GbE IP Core Without Adapters and with Preamble Pass-Through Turned Off

In the figure, dout_last_data is asserted in the second cycle, indicating the end of a packet. The dout_d signal returns to 0 (5’h1c = 5’b11100). The dout_c and dout_d busses are set to 1b’1 and 8’h07, respectively, to indicate idling. In the fourth cycle, dout_first_data is asserted and a short packet begins. This packet terminates successfully in the final cycle. Note that the first packet has a CRC error (dout_fcs_error = 1 and fcs_valid = 1).

The dout_first_data signal marks the first word of data. The first byte of data is always the most significant byte of the word. There are 5 legal starting positions for the 100GbE IP core and 2 legal starting positions for the 40GbE IP core. The dout_last_data signal marks the last data byte before the FCS (CRC). It can occur at any byte position.

The dout_runt_last_data signal indicates that the packet ending in this word is less than the minimum legal length of 64 bytes from first data to the last FCS byte inclusive. Runt frames of eight or fewer bytes cannot be legally represented in CGMII and trigger a decoding error rather than this flag.

The dout_fcs_error and dout_fcs_valid signals indicate the result of the CRC checking logic. dout_fcs_valid = 1 and dout_fcs_error = 1 indicate a corrupted frame. Note that the CRC checking network works correctly on runt frames of 40–63 bytes. Runt frames of less than 40 bytes may be incorrectly determined to have a proper CRC.

The dout_payload signal marks words that contain frame data payload. Words that contain data payload might also contain Idle or sequence control information, or preamble/frame delimiters. However, if the word contains any frame data, the dout_payload bit that corresponds to that word has the value of 1.

The dout_valid signal exists for clock rate compensation. This signal is almost always asserted. When dout_valid is deasserted all other dout signals should be ignored for one clock cycle.

Example on RX Client Interface With Preamble Pass-Through

Figure 35. Typical Traffic on the RX Client Interface for 100GbE IP Core Without Adapters and With Preamble Pass-Through

In the figure, the IP core is in preamble pass-through mode, and places the preamble sequence on the data bus dout_d. The dout_first_data signal marks the first word of data, including the full preamble sequence, beginning with the Start byte. The data in each packet begins with the Start byte (0x55), six-byte preamble (0x555555555555), and SFD (0xD5), and must align with one of the legal starting positions. The IP core asserts the dout_c signal high for the Start byte, and holds dout_c low for the remainder of the preamble, which is considered to be data. The dout_c signal is the only signal that distinguishes any part of the preamble sequence from data. The second and third packets in the example each begin in the first word of dout_d, with the preamble sequence. However, they could each legally begin at the start of any other word of dout_d; the start of each word is a legal starting position.

Level Two Title