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.14.6. 1588 PTP Interface Signals

Table 26.  Signals of the 1588 Precision Time Protocol InterfaceSignals are clocked by clk_rxmac or clk_txmac, as specified. All 64-bit output signals are in the Altera 64-bit TOD format, and you are expected to drive all 64-bit input signals in this format.

Signal Name

Direction

Description

PTP Interface to TOD module
tx_time_of_day_96b_data[95:0] Input Current V2-format (96-bit) TOD in clk_txmac clock domain. Connect this signal to the external TOD module.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

tx_time_of_day_64b_data[63:0] Input Current 64-bit TOD in clk_txmac clock domain. Connect this signal to the external TOD module.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

rx_time_of_day_96b_data[95:0] Input Current V2-format (96-bit) TOD in clk_rxmac clock domain. Connect this signal to the external TOD module.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

rx_time_of_day_64b_data[63:0] Input Current 64-bit TOD in clk_rxmac clock domain. Connect this signal to the external TOD module.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

PTP Interface to Client
TX Signals Related to One Step Processing
tx_etstamp_ins_ctrl_timestamp_insert Input Indicates the current packet on the TX client interface is a 1588 PTP packet, and directs the IP core to process the packet in one-step processing insertion mode. In this mode, the IP core overwrites the timestamp of the packet with the timestamp when the packet appears on the TX Ethernet link.

The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet.

If the TX client asserts this signal simultaneously with either of tx_etstamp_ins_ctrl_residence_time_update or tx_egress_timestamp_request_valid, the results are undefined.

tx_etstamp_ins_ctrl_residence_time_update Input Indicates the current packet on the TX client interface is a 1588 PTP packet, and directs the IP core to process the packet in one-step processing correction mode. In this mode, the IP core adds the latency through the IP core (residence time) to the current contents of the timestamp field.

The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet.

If the TX client asserts this signal simultaneously with either of tx_etstamp_ins_ctrl_timestamp_insert or tx_egress_timestamp_request_valid, the results are undefined.

tx_etstamp_ins_ctrl_ingress_timestamp_96b[95:0] Input

Iindicates the V2-format TOD when the packet entered the system.

The TX client must ensure this signal is valid in each TX SOP cycle when it asserts tx_etstamp_ins_ctrl_residence_time_update. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. This signal is useful only in transparent clock mode when the TX client asserts tx_etstamp_ins_ctrl_residence_time_update.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

tx_etstamp_ins_ctrl_ingress_timestamp_64b[63:0] Input

Indicates the TOD (in Altera 64-bit format) when the packet entered the system.

The TX client must ensure this signal is valid in each TX SOP cycle when it asserts tx_etstamp_ins_ctrl_residence_time_update. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. This signal is useful only in transparent clock mode when the TX client asserts tx_etstamp_ins_ctrl_residence_time_update.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

tx_etstamp_ins_ctrl_timestamp_format Input Specifies the timestamp format (V1 or V2 format) for the current packet if the TX client simultaneously asserts tx_etstamp_ins_ctrl_timestamp_insert. Values are:
  • 1'b0: 96-bit timestamp format (V2)
  • 1'b1: 64-bit timestamp format (V1)

The TX client must maintain the desired value on this signal while the TX SOP signal is asserted.

If the client specifies the V1 format, you read and write the V1 format TOD (32 bits of seconds and 32 bits of nanoseconds) in bits [79:16] of the 96-bit timestamp and TOD signals.

Note: If you do not turn on the Enable 96b Time of Day Format parameter, the results of asserting tx_etstamp_ins_ctrl_timestamp_insert are undefined. Therefore, the timestamp in either case maps to the 96-bit signals.
tx_etstamp_ins_ctrl_residence_time_calc_format Input Specifies the TOD format (Altera 64-bit TOD format or the V2 96-bit format) for the current packet if the TX client simultaneously asserts tx_etstamp_ins_ctrl_residence_time_update. Values are:
  • 1'b0: 96-bit TOD format (V2)
  • 1'b1: 64-bit TOD format

The TX client must maintain the desired value on this signal while the TX SOP signal is asserted.

If you turned on Enable 96b Time of Day Format and the client specifies the 64-bit format, the IP core maps the 64-bit TOD format time-of-day (32 bits of seconds and 32 bits of nanoseconds) as is in bits [79:16] of the 96-bit timestamp and TOD signals.

If you turned off Enable 96b Time of Day Format and the client specifies the 96-bit format (V2), the results are undefined.

tx_etstamp_ins_ctrl_offset_timestamp[15:0]

Input

Specifies the byte offset of the timestamp information in the current packet if the TX client simultaneously asserts tx_etstamp_ins_ctrl_timestamp_insert. The IP core overwrites the value at this offset. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted.

If the packet supports V2 format, the timestamp has 96 bits. In this case, the IP core inserts ten bytes (bits [95:16]) of the timestamp at this offset and the remaining two bytes (bits [15:0]) of the timestamp at the offset specified in tx_etstamp_ins_ctrl_offset_correction_field.

The offset must support inclusion of the entire timestamp in the first 256 bytes of the packet.

The TX client must ensure that the timestamp bytes and the UDP checksum bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined.

tx_etstamp_ins_ctrl_offset_correction_field[15:0] Input If the TX client simultaneously asserts tx_etstamp_ins_ctrl_residence_time_update, this signal specifies the byte offset of the correction field in the the current packet.

If the TX client simultaneously asserts tx_etstamp_ins_ctrl_timestamp_insert and deasserts (sets to the value of 0) the tx_etstamp_ins_ctrl_timestamp_format signal, this signal specifies the byte offset of bits [15:0]] of the timestamp.

The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. The offset must support inclusion of the entire timestamp in the first 256 bytes of the packet.

The TX client must ensure that the correction field bytes and the UDP checksum bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined.

tx_etstamp_ins_ctrl_checksum_zero Input The TX client asserts this signal during a TX SOP cycle to tell the IP core to zero the UDP checksum in the current packet.

If the TX client asserts the tx_etstamp_ins_ctrl_checksum_correct signal, it cannot assert this signal. This signal is meaningful only in two-step clock mode.

A zeroed UDP checksum indicates the checksum value is not necessarily correct. This information is useful to tell the application to skip checksum checking of UDP IPv4 packets. This function is illegal for UDP IPv6 packets.

tx_etstamp_ins_ctrl_offset_checksum_field[15:0] Input Indicates the byte offset of the UDP checksum in the current packet. The TX client must ensure this signal has a valid value during each TX SOP cycle when it also asserts the tx_etstamp_ins_ctrl_checksum_zero signal. Holds the byte offset of the two bytes in the packet that the IP core should reset. This signal is meaningful only in two-step clock mode.

The TX client must ensure that the UDP checksum bytes and the timestamp bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined.

tx_etstamp_ins_ctrl_checksum_correct Input The TX client asserts this signal during a TX SOP cycle to tell the IP core to update (correct) the UDP checksum in the current packet.

If the TX client asserts the tx_etstamp_ins_ctrl_checksum_zero signal, it cannot assert this signal. This signal is meaningful only in two-step clock mode.

The application must assert this signal for correct processing of UDP IPv6 packets.

tx_etstamp_ins_ctrl_offset_checksum_correction[15:0] Input Indicates the byte offset of the UDP checksum in the current packet. The TX client must ensure this signal has a valid value during each TX SOP cycle when it also asserts the tx_etstamp_ins_ctrl_checksum_correct signal. Holds the byte offset of the two bytes in the packet that the IP core should correct. This signal is meaningful only in two-step clock mode.

The TX client must ensure that the UDP checksum bytes and the timestamp bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined.

tx_egress_asymmetry_update Input Indicates the IP core should include the value in the TX_PTP_ASYM_DELAY register in its correction calculations. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted.

This option is useful in two-step correction mode.

TX Signals Related to Two Step Processing
tx_egress_timestamp_request_valid Input Indicates the current packet on the TX client interface is a 1588 PTP packet, and directs the IP core to process the packet in two-step processing mode. In this mode, the IP core outputs the timestamp of the packet when it exits the IP core, and does not modify the packet timestamp information.

The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet.

If the TX client asserts this signal simultaneously with either of tx_etstamp_ins_ctrl_timestamp_insert or tx_etstamp_ins_ctrl_residence_time_update, the results are undefined.

tx_egress_timestamp_96b_data[95:0]

Output

Provides the V2-format timestamp when a 1588 PTP frame begins transmission on the Ethernet link. Value is valid when the tx_egress_timestamp_96b_valid signal is asserted. This signal is meaningful only in two-step clock mode.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

tx_egress_timestamp_96b_valid Output Indicates that the tx_egress_timestamp_96b_data and tx_egress_timestamp_96b_fingerprint signals are valid in the current clk_txmac clock cycle. This signal is meaningful only in two-step clock mode.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

tx_egress_timestamp_64b_data[63:0]

Output

Provides the timestamp when a V1-format 1588 PTP frame begins transmission on the Ethernet link. Value is valid when the tx_egress_timestamp_64b_valid signal is asserted. This signal is meaningful only in two-step clock mode.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

tx_egress_timestamp_64b_valid Output Indicates that the tx_egress_timestamp_64b_data and tx_egress_timestamp_64b_fingerprint signals are valid in the current clk_txmac clock cycle. This signal is meaningful only in two-step clock mode.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

tx_egress_timestamp_request_fingerprint[(W–1):0]

where W is the value between 1 and 16, inclusive, that you specify for the Timestamp fingerprint width parameter

Input Fingerprint of the current packet.

The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet.

tx_egress_timestamp_96b_fingerprint[(W–1):0]

where W is the value between 1 and 16, inclusive, that you specify for the Timestamp fingerprint width parameter

Output Provides the fingerprint of the V2-format 1588 PTP frame currently beginning transmission on the Ethernet link. Value is valid when the tx_egress_timestamp_96b_valid signal is asserted.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

tx_egress_timestamp_64b_fingerprint[(W–1):0]

where W is the value between 1 and 16, inclusive, that you specify for the Timestamp fingerprint width parameter

Output Provides the fingerprint of the V1-format 1588 PTP frame currently beginning transmission on the Ethernet link. Value is valid when the tx_egress_timestamp_64b_valid signal is asserted.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

RX Signals
rx_ingress_timestamp_96b_data[95:0]

Output

Whether or not the current packet on the RX client interface is a 1588 PTP packet, indicates the V2-format timestamp when the IP core received the packet on the Ethernet link. The IP core provides a valid value on this signal in the same cycle it asserts the RX SOP signal for 1588 PTP packets.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

rx_ingress_timestamp_96b_valid

Output

Indicates that the rx_ingress_timestamp_96b_data signal is valid in the current cycle. This signal is redundant with the RX SOP signal for 1588 PTP packets.

This signal is available only if you turn on the Enable 96b Time of Day Format parameter.

rx_ingress_timestamp_64b_data[63:0]

Output

Whether or not the current packet on the RX client interface is a 1588 PTP packet, indicates the 64-bit TOD (in Altera 64-bit format) when the IP core received the packet on the Ethernet link. The IP core provides a valid value on this signal in the same cycle it asserts the RX SOP signal for 1588 PTP packets.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

rx_ingress_timestamp_64b_valid

Output

Indicates that the rx_ingress_timestamp_64b_data signal is valid in the current cycle. This signal is redundant with the RX SOP signal for 1588 PTP packets.

This signal is available only if you turn on the Enable 64b Time of Day Format parameter.

Level Two Title