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

Download PDF
ID 683628
Date 12/28/2017
Public
Document Table of Contents
Document Table of Contents x
1. About the Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP Core 2. Getting Started 3. Functional Description 4. Debugging the Link A. Arria 10 10GBASE-KR Registers B. Differences Between Low Latency 40-100GbE IP Core and 40-100GbE IP Core v15.1 C. Additional Information
1. About the Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP Core x
1.1. Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP Core Supported Features 1.2. Low Latency 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. Low Latency 40-100GbE IP Core Device Family and Speed Grade Support x
1.2.1. Device Family Support 1.2.2. Low Latency 40-100GbE IP Core Device Speed Grade Support
1.3. IP Core Verification x
1.3.1. Simulation Environment 1.3.2. Compilation Checking 1.3.3. Hardware Testing
1.4. Performance and Resource Utilization x
1.4.1. Stratix V Resource Utilization for Low Latency 40-100GbE IP Cores 1.4.2. Arria 10 Resource Utilization for Low Latency 40-100GbE IP Cores
2. Getting Started x
2.1. Installation and Licensing for LL 40-100GbE IP Core for Stratix V Devices 2.2. Licensing IP Cores 2.3. Specifying the Low Latency 40-100GbE IP Core Parameters and Options 2.4. IP Core Parameters 2.5. Files Generated for Stratix V Variations 2.6. Files Generated for Arria 10 Variations 2.7. Integrating Your IP Core in Your Design 2.8. Low Latency 40-100GbE IP Core Testbenches 2.9. Simulating the Low Latency 40‑100GbE IP Core With the Testbenches 2.10. Compiling the Full Design and Programming the FPGA 2.11. Initializing the IP Core
2.2. Licensing IP Cores x
2.2.1. OpenCore Plus IP Evaluation
2.7. Integrating Your IP Core in Your Design x
2.7.1. Pin Assignments 2.7.2. External Transceiver Reconfiguration Controller Required in Stratix V Designs 2.7.3. Transceiver PLL Required in Arria 10 Designs 2.7.4. External Time-of-Day Module for Variations with 1588 PTP Feature 2.7.5. Clock Requirements for 40GBASE-KR4 Variations 2.7.6. External TX MAC PLL 2.7.7. Placement Settings for the Low Latency 40-100GbE IP Core
2.8. Low Latency 40-100GbE IP Core Testbenches x
2.8.1. Low Latency 40-100GbE IP Core Testbench Overview 2.8.2. Understanding the Testbench Behavior
2.9. Simulating the Low Latency 40‑100GbE IP Core With the Testbenches x
2.9.1. Generating the Low Latency 40-100GbE Testbench 2.9.2. Optimizing the Low Latency 40‑100GbE IP Core Simulation With the Testbenches 2.9.3. Simulating with the Modelsim Simulator 2.9.4. Simulating with the NCSim Simulator 2.9.5. Simulating with the VCS Simulator 2.9.6. Testbench Output Example: Low Latency 40-100GbE IP Core
3. Functional Description x
3.1. High Level System Overview 3.2. Low Latency 40-100GbE MAC and PHY Functional Description 3.3. Signals 3.4. Software Interface: Registers 3.5. Ethernet Glossary
3.2. Low Latency 40-100GbE MAC and PHY Functional Description x
3.2.1. Low Latency 40-100GbE IP Core TX Datapath 3.2.2. Low Latency 40-100GbE IP Core TX Data Bus Interfaces 3.2.3. Low Latency 40-100GbE IP Core RX Datapath 3.2.4. Low Latency 40-100GbE IP Core RX Data Bus Interface 3.2.5. Low Latency 100GbE CAUI–4 PHY 3.2.6. External Reconfiguration Controller 3.2.7. External Transceiver PLL 3.2.8. External TX MAC PLL 3.2.9. Congestion and Flow Control Using Pause Frames 3.2.10. Pause Control and Generation Interface 3.2.11. Pause Control Frame Filtering 3.2.12. Link Fault Signaling Interface 3.2.13. Statistics Counters Interface 3.2.14. 1588 Precision Time Protocol Interfaces 3.2.15. PHY Status Interface 3.2.16. Transceiver PHY Serial Data Interface 3.2.17. Low Latency 40GBASE-KR4 IP Core Variations 3.2.18. Control and Status Interface 3.2.19. Arria 10 Transceiver Reconfiguration Interface 3.2.20. Clocks 3.2.21. Resets
3.2.1. Low Latency 40-100GbE 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.1.7. Error Insertion Test and Debug Feature
3.2.2. Low Latency 40-100GbE IP Core TX Data Bus Interfaces x
3.2.2.1. Low Latency 40-100GbE IP Core User Interface Data Bus 3.2.2.2. Low Latency 40-100GbE IP Core TX Data Bus with Adapters (Avalon-ST Interface) 3.2.2.3. Low Latency 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. Order of Transmission
3.2.3. Low Latency 40-100GbE IP Core RX Datapath x
3.2.3.1. Low Latency 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. LL 40-100GbE IP Core Malformed Packet Handling 3.2.3.6. RX CRC Forwarding 3.2.3.7. Inter-Packet Gap 3.2.3.8. Pause Ignore 3.2.3.9. Control Frame Identification
3.2.4. Low Latency 40-100GbE IP Core RX Data Bus Interface x
3.2.4.1. Low Latency 40-100GbE IP Core User Interface Data Bus 3.2.4.2. Low Latency 40-100GbE IP Core RX Data Bus 3.2.4.3. Low Latency 40-100GbE IP Core RX Data Bus Without Adapters (Custom Streaming Interface)
3.2.9. Congestion and Flow Control Using Pause Frames x
3.2.9.1. Conditions Triggering XOFF Frame Transmission 3.2.9.2. Conditions Triggering XON Frame Transmission
3.2.13. Statistics Counters Interface x
3.2.13.1. OctetOK Count Interface
3.2.14. 1588 Precision Time Protocol Interfaces x
3.2.14.1. Implementing a 1588 System That Includes a LL 40-100GbE IP Core 3.2.14.2. PTP Receive Functionality 3.2.14.3. PTP Transmit Functionality 3.2.14.4. External Time-of-Day Module for 1588 PTP Variations 3.2.14.5. PTP Timestamp and TOD Formats 3.2.14.6. 1588 PTP Interface Signals
3.3. Signals x
3.3.1. Low Latency 40-100GbE IP Core Signals
3.4. Software Interface: Registers x
3.4.1. Low Latency 40-100GbE IP Core Registers 3.4.2. LL 40‑100GbE Hardware Design Example Registers
3.4.1. Low Latency 40-100GbE IP Core Registers x
3.4.1.1. PHY Registers 3.4.1.2. Link Fault Signaling Registers 3.4.1.3. LL 40GBASE-KR4 Registers 3.4.1.4. Low Latency 40-100GbE IP Core MAC Configuration Registers 3.4.1.5. Pause Registers 3.4.1.6. TX Statistics Registers 3.4.1.7. RX Statistics Registers 3.4.1.8. 1588 PTP Registers
3.4.2. LL 40‑100GbE Hardware Design Example Registers x
3.4.2.1. Packet Client Registers
4. Debugging the Link x
4.1. Creating a SignalTap II Debug File to Match Your Design Hierarchy
A. Arria 10 10GBASE-KR Registers x
A.1. 10GBASE-KR PHY Register Definitions
C. Additional Information x
C.1. Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide Archives C.2. Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide Revision History C.3. How to Contact Altera C.4. Typographic Conventions
1. About the Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP Core
2. Getting Started
3. Functional Description
4. Debugging the Link
A. Arria 10 10GBASE-KR Registers
B. Differences Between Low Latency 40-100GbE IP Core and 40-100GbE IP Core v15.1
C. Additional Information

3.2.4.3. Low Latency 40-100GbE IP Core RX Data Bus Without Adapters (Custom Streaming Interface)

The RX bus without adapters consists of four 8-byte words, or 256 bits, operating at a frequency of 390.625. for the 100GbE IP core or two 8‑byte words, or 128 bits, for the 40GbE IP core, nominally at 312.5 MHz. This bus drives data from the RX MAC to the RX client.

Figure 26. RX MAC to Client Interface Without Adapters The custom streaming interface bus width varies with the IP core variation. In the figure, <w> = 2 for the 40GbE IP core and <w> = 4 for the 100GbE IP core.
Table 21.  Signals of the RX Client Interface Without AdaptersIn the table, <w> = 2 for the 40GbE IP core and <w> = 4 for the 100GbE IP core. The signals are clocked by clk_rxmac.

Signal Name

Direction

Description

dout_d[<w>*64-1:0]

Output

Received data and Idle bytes. In RX preamble pass-through mode, this bus also carries the preamble.

dout_c[<w>*8-1:0]

Output

Indicates control bytes on the data bus. Each bit of dout_c indicates whether the corresponding byte of dout_d is a control byte. A bit is asserted high if the corresponding byte on dout_d is an Idle byte or the Start byte, and has the value of zero if the corresponding byte is a data byte or, in preamble pass-through mode, a preamble or SFD byte.

dout_sop[<w>-1:0]

Output

Indicates the first data word of a frame, in the current clk_rxmac cycle. In RX preamble pass-through mode, the first data word is the word that contains the preamble. When the RX preamble pass-through feature is turned off, the first data word is the first word of Ethernet data that follows the preamble. This signal is one-hot encoded.

dout_eop[<w>–1:0]

Output

Indicates the final word of a frame in the current clk_rxmac cycle. If CRC removal is disabled, this signal indicates the word with the final CRC byte. If CRC removal is enabled, this signal indicates the final word with data. This signal is one-hot encoded.

dout_eop_empty[<w>*3-1:0] Output

Indicates the number of empty (invalid) bytes in the end-of-packet byte in the word indicated by dout_eop.

If dout_eop[z] has the value of 0, then the IP core sets the value of dout_eop_empty[(z+2):z] to 0. However, if dout_eop[z] has the value of 1, then you must use the value of dout_eop_empty[(z+2):z] to determine the number of empty (invalid) bytes in the end-of-packet word (and therefore, the end-of-packet byte).

For example, if you have a 100GbE IP core and you observe that in the current clk_rxmac clock cycle, dout_eop has the value of 4'b0100 and dout_eop_empty has the value of 12'b000_110_000_000, you can conclude that byte 6 in word 2 of dout_d is an end-of-packet byte.

dout_idle[<w>-1:0] Output

Indicates the words in dout_d that hold Idle bytes or control information rather than Ethernet data. This signal is one-hot encoded.

rx_error[5:0] Output Reports certain types of errors in the Ethernet frame whose contents are currently being transmitted on the client interface. This signal is valid in EOP cycles only. To ensure you can identify the corresponding packet, you must turn on Enable alignment EOP on FCS word in the LL 40-100GbE parameter editor.

The individual bits report different types of errors:

  • Bit [0]: Malformed packet error. If this bit has the value of 1, the packet is malformed. The IP core identifies a malformed packet when it receives a control character that is not a terminate character, while receiving the packet.
  • Bit [1]: CRC error. If this bit has the value of 1, the IP core detected a CRC error in the frame.

    If you turn on Enable alignment EOP on FCS word , this bit and the rx_fcs_error signal behave identically.

  • Bit [2]: undersized payload. If this bit has the value of 1, the frame size is between nine and 63 bytes, inclusive. The IP core does not recognize an incoming frame of size eight bytes or less as a frame, and those cases are not reported here.
  • Bit [3]: oversized payload. If this bit has the value of 1, the frame size is greater than the maximum frame size programmed in the MAX_RX_SIZE_CONFIG register at offset 0x506.
  • Bit [4]: payload length error. If this bit has the value of 1, the payload received in the frame did not match the length field value, and the value in the length field is less than 1536 bytes. This bit only reports errors if you set bit [0] of the CFG_PLEN_CHECK register at offset 0x50A to the value of 1.
  • Bit [5} Reserved.
rx_fcs_error

Output

The current or most recent EOP byte is part of a frame with an incorrect FCS (CRC-32) value. By default, the IP core asserts rx_fcs_error in the same cycle as the dout_eop signal. However, if you turn off Enable alignment EOP on FCS word in the LL 40-100GbE parameter editor, the rx_fcs_error signal might lag the dout_eop signal for the frame.

Runt frames always force an FCS error condition. However, if a packet is eight bytes or smaller, it is considered a decoding error and not a runt frame, and the IP core does not flag it as a runt.

rx_fcs_valid

Output

When set, indicates that rx_fcs_error has a valid value in the current clock cycle..

rx_status[2:0] Output Indicates the IP core received a control frame on the Ethernet link. This signal identifies the type of control frame the IP core is passing through to the client interface.

This signal is valid in EOP cycles only. To ensure you can identify the corresponding packet, you must turn on Enable alignment EOP on FCS word in the LL 40-100GbE parameter editor.

The individual bits report different types of received control frames:

  • Bit [0]: Indicates the IP core received a standard flow control frame. If the IP core is in standard flow control mode and the cfg_fwd_ctrl bit of the RX_PAUSE_FWD register has the value of 0, this bit maintains the value of 0.
  • Bit [1]: Indicates the IP core received a priority flow control frame. If the IP core is in priority flow control mode and the cfg_fwd_ctrl bit of the RX_PAUSE_FWD register has the value of 0, this bit maintains the value of 0.
  • Bit [2]: Indicates the IP core received a control frame that is not a flow control frame.
dout_valid

Output

The dout_d bus contents are valid. This signal is occasionally deasserted due to clock crossing.

clk_rxmac

Output

RX MAC clock. The clock frequency should be 312.5 MHz in LL 40GbE IP cores, and 390.625 MHz in LL 100GbE IP cores. The clk_rxmac clock is derived from the recovered CDR clock.

The data bytes use 100 Gigabit Media Independent Interface (CGMII-like) encoding. For packet payload bytes, the dout_c bit is set to 0 and the dout_d byte is the packet data. You can use this information to transmit out-of-spec data such as customized preambles when implementing non-standard variants of the IEEE 802.3ba-2010 100G Ethernet Standard.

In RX preamble pass-through mode, dout_c has the value of 1 while the start byte of the preamble is presented on the RX interface, and dout_c has the value of 0 while the remainder of the preamble sequence (six-byte preamble plus SFD byte) is presented on the RX interface.

Related Information
Level Two Title