The Low Latency (LL) Ethernet 10G (10GbE) Media Access Controller (MAC) Intel^® FPGA IP core is a configurable component that implements the IEEE 802.3-2008 specification. To build a complete Ethernet subsystem in an Intel FPGA device and connect it to an external device, you can use the LL 10GbE Intel^® FPGA IP core with an Intel FPGA PHY IP core or any of the supported PHYs.

The following figure shows a system with the LL 10GbE MAC Intel^® FPGA IP core.

This Intel^® FPGA IP core is designed to the IEEE 802.3–2008 Ethernet Standard available on the IEEE website (www.ieee.org). All LL 10GbE Intel^® FPGA IP core variations include MAC only and are in full-duplex mode. These Intel^® FPGA IP core variations offer the following features:

• MAC features:
  • Full-duplex MAC in eight operating modes: 10G, 1G/10G, 1G/2.5G, 1G/2.5G/10G, 10M/100M/1G/2.5G/5G/10G (USXGMII), 10M/100M/1G/10G, 10M/100M/1G/2.5G, and 10M/100M/1G/2.5G/10G.
  • Three variations for selected operating modes: MAC TX only block, MAC RX only block, and both MAC TX and MAC RX block.
  • 10GBASE-R register mode on the TX and RX datapaths, which enables lower latency.
  • Programmable promiscuous (transparent) mode.
  • Unidirectional feature as specified by IEEE 802.3 (Clause 66).
  • Priority-based flow control (PFC) with programmable pause quanta. PFC supports 2 to 8 priority queues.
• Interfaces:
  • Client-side—32-bit Avalon^® streaming interface.
  • Management—32-bit Avalon^® memory-mapped interface.
  • PHY-side—32-bit XGMII for 10 GbE, 16-bit GMII for 2.5 GbE, 8-bit GMII for 1 GbE, or 4-bit MII for 10M/100M.
• Frame structure control features:
  • Virtual local area network (VLAN) and stacked VLAN tagged frames decoding (type 'h8100).
  • Cyclic redundancy code (CRC)-32 computation and insertion on the TX datapath. Optional CRC checking and forwarding on the RX datapath.
  • Deficit idle counter (DIC) for optimized performance with average inter-packet gap (IPG) for LAN applications.
  • Supports programmable IPG.
  • Ethernet flow control using pause frames.
  • Programmable maximum length of TX and RX data frames up to 64 Kbytes (KB).
  • Preamble passthrough mode on TX and RX datapaths, which allows user defined preamble in the client frame.
  • Optional padding insertion on the TX datapath and termination on the RX datapath.
• Frame monitoring and statistics:
  • Optional CRC checking and forwarding on the RX datapath.
  • Optional statistics collection on TX and RX datapaths.

• Optional timestamping as specified by the IEEE 1588v2 standard for the following configurations:
  • 10GbE MAC with 10GBASE-R PHY IP core
  • 1G/10GbE MAC with 1G/10GbE PHY IP core
  • 1G/2.5GbE MAC with 1G/2.5G Multi-rate Ethernet PHY IP core
  • 1G/2.5G/10GbE MAC with 1G/2.5G/10G (MGBASE-T) Multi-rate Ethernet PHY IP core
  • 10M/100M/1G/10GbE MAC with 10M-10GbE PHY IP core
  • 10M/100M/1G/2.5G/5G/10G (USXGMII) MAC with 1G/2.5G/5G/10G Multi-rate Ethernet PHY Intel^® FPGA IP core

The TX and RX latency values are based on the following definitions and assumptions:

• TX latency is the time taken for the data frame to move from the Avalon^® streaming interface to the PHY-side interface.
• RX latency is the time taken for the data frame to move from the PHY-side interface to the Avalon^® streaming interface.
• No backpressure on the Avalon^® streaming TX and RX interfaces.
• All options under Legacy Ethernet 10G MAC interfaces, that allow compatibility with the legacy MAC are disabled.

This chapter provides a general overview of the Intel^® FPGA IP core design flow to help you quickly get started with LL Ethernet 10G MAC.

The Intel^® Quartus^® Prime software installation includes the Intel^® FPGA IP library. Integrate optimized and verified Intel^® FPGA IP cores into your design to shorten design cycles and maximize performance. The Intel^® Quartus^® Prime software also supports integration of IP cores from other sources. Use the IP Catalog (Tools > IP Catalog) to efficiently parameterize and generate synthesis and simulation files for your custom IP variation. The Intel^® FPGA IP library includes the following types of IP cores:

This document provides basic information about parameterizing, generating, upgrading, and simulating stand-alone IP cores in the Intel^® Quartus^® Prime software.

The Intel^® Quartus^® Prime software installs IP cores in the following locations by default:

The Intel^® Quartus^® Prime software provides integration with many simulators and supports multiple simulation flows, including your own scripted and custom simulation flows. Whichever flow you choose, IP core simulation involves the following steps:

1. Generate simulation model, testbench (or example design), and simulator setup script files.
2. Set up your simulator environment and any simulation scripts.
3. Compile simulation model libraries.
4. Run your simulator.

For this IP, the Generate Example Design button in IP parameter editor produces RTL, C, and MATLAB files for simulation. The use of these files in each environment is described in the following sub-sections.

The Intel^® Quartus^® Prime software alerts you when your IP core is not upgraded to the current version. Click Project > Upgrade IP Components to identify and upgrade the IP cores. To successfully upgrade the IP core, you must ensure that the file structure of your project that was generated by an older version of the software is preserved. Failure to upgrade IP cores can result in a mismatch between the IP core variation and the current supporting libraries.

Intel verifies that the current version of the Intel^® Quartus^® Prime software compiles the previous version of each IP core. The Intel^® FPGA IP Release Notes reports any verification exceptions. Intel does not verify the compilation of IP cores older than the previous release.

Figure 7. Upgrading IP Components in Project Navigator

Most of the configuration registers in the MAC IP core must not be programmed when the MAC is in operation. As such, they are not synchronized to reduce resource usage. These registers are all in the set_false_path constraint.

The working principle of the clock crosser is to let the crossed-over data stabilize first before indicating that the data is valid in the latched clock domain. Using such structure, the data bits must not skew for more than one latched clock period. The timing constraint file applies a common timing check over all the clock crossers irrespective of their latched clock domain. This is over-pessimistic for signals crossing into the CSR clock, but there are no side-effects, like significant run-time impact and false violations, during the internal testing. If your design runs into clock crosser timing violation paths within the IP and the latched clock domain is csr_clk, you can dismiss the violation manually or by editing the .sdc file if the violation is less than one csr_clk period.

The timing constraint file uses the set_net_delay to constraint the fitter placement and set_max_skew to perform timing check on the paths. For a project with very high device utilization, Intel recommends that you implement addition steps like floor planning or Logic Lock to aid the place-and-route process. The additional steps can give a more consistent timing closure along these paths instead of only relying on the set_net_delay.

A caveat of using set_max_skew is that it does not analyze whether the insertion delay of the path in concern exceeds a limit. In other words, a path could meet skew requirement but have longer than expected insertion delay. If this is not checked, it may cause functional failure in certain latency-sensitive paths. Therefore, a custom script (alt_em10g32_clock_crosser_timing_info.tcl) is available for you to check that the round-trip clock crosser delay is within expectation. To use this script, manually add it to the user flow and run it. To ensure that the IP core operates correctly, the results must be positive (no error).

The timing constraint file uses the set_net_delay to constraint the fitter placement and set_max_skew to perform timing check on the paths. For a project with very high device utilization, Intel recommends that you implement addition steps like floor planning or Logic Lock to aid the place-and-route process. The additional steps can give a more consistent timing closure along these paths instead of only relying on the set_net_delay.

To minimize jitter, the advanced transmit (ATX) PLL and the fractional PLL (fPLL) can source the input reference clock directly from the reference clock buffer without passing through the reference clock network. You must ensure that a location constraint is added to your design to achieve a correct placement on the device.

The implementation of the LL Ethernet 10G MAC Intel^® FPGA IP core on hardware requires additional components specific to the targeted device.

For detailed information about the LL Ethernet 10G MAC Intel^® FPGA IP design examples, refer to Low Latency Ethernet 10G MAC Intel^® Stratix^® 10 FPGA IP Design Example User Guide.

For detailed information about the LL Ethernet 10G MAC Intel^® FPGA IP design examples, refer to Low Latency Ethernet 10G MAC Intel^® Arria^® 10 FPGA IP Design Example User Guide.

For detailed information about the LL Ethernet 10G MAC Intel^® FPGA IP design examples, refer to Low Latency Ethernet 10G MAC Intel^® Cyclone^® 10 GX FPGA IP Design Example User Guide.

The Low Latency (LL) Ethernet 10G MAC Intel^® FPGA IP core handles the flow of data between a client and an Ethernet network through an Ethernet PHY. On the transmit path, the MAC IP core accepts client frames and constructs Ethernet frames by inserting various control fields, such as checksums before forwarding them to the PHY. Similarly, on the receive path, the MAC accepts Ethernet frames via a PHY, performs checks, and removes the relevant fields before forwarding the frames to the client. You can configure the MAC IP core to collect statistics on both transmit and receive paths.

The LL Ethernet 10G MAC Intel^® FPGA IP core is a composition of the following blocks: MAC receiver (MAC RX), MAC transmitter (MAC TX), configuration and status registers, and clock and reset.

The MAC IP core supports the following frame types:

• Basic Ethernet frames, including jumbo frames.
• VLAN and stacked VLAN frames.
• Control frames, which include pause and PFC frames.

The MAC TX receives the client payload data with the destination and source addresses, and appends various control fields depending on the MAC configuration.

By default, the MAC TX inserts padding bytes (0x00) into TX frames to meet the following minimum payload length:

• 46 bytes for basic frames
• 42 bytes for VLAN tagged frames
• 38 bytes for stacked VLAN tagged frames

Ensure that CRC-32 insertion is enabled when padding bytes insertion is enabled.

You can disable padding bytes insertion by setting the tx_pad_control register to 0. When disabled, the MAC IP core forwards the frames to the PHY-side interface without padding. Ensure that the minimum payload length is met; otherwise the current frame may get corrupted. You can check for undersized frames by referring to the statistics collected.

By default, the MAC TX retains the source address received from the client. You can configure the MAC TX to replace the source address with the primary MAC address specified in the tx_addrins_macaddr0 and tx_addrins_macaddr1 registers by setting the bit tx_src_addr_override[0] to 1.

By default, the MAC TX computes and inserts CRC-32 checksum into TX frames. The MAC TX computes the CRC-32 checksum over frame bytes that include the source address, destination address, length, data, and padding bytes. The computation excludes the preamble and SFD bytes. The MAC TX then inserts the CRC-32 checksum into the TX frame. Bit 31^st of the checksum occupies the least significant bit of the first byte in the CRC field.

You can disable this function by setting the tx_crc_control[1] register bit to 0.

The following figure shows the timing diagram on the Avalon^® streaming data interfaces where CRC insertion is enabled on transmit and CRC removal is disabled on receive. The frame from the client is without CRC-32 checksum. The MAC TX inserts the CRC-32 checksum (4EB00AF4) into the frame. The frame is then looped back to the RX datapath with the CRC-32 checksum.

The following figure shows the timing diagram on the Avalon^® streaming data interfaces where CRC insertion is disabled on transmit and CRC removal is disabled on receive. The MAC TX receives the frame from the client with a CRC-32 checksum (4EB00AF4). The frame with the same CRC-32 checksum is then looped back to the RX datapath.

By default, the MAC TX inserts 7-byte preamble, 1-byte SFD and 1-byte EFD (0xFD) into frames received from the client.

The MAC TX also supports custom preamble in 10G operations. To use custom preamble, set the tx_preamble_control register to 1. Behavior of the MAC TX in custom preamble mode:

• The MAC TX accepts the first eight bytes in the frame from the client as custom preamble.
• The MAC TX inserts 1-byte EFD (0xFD) into the frame.
• The MAC TX replaces the first byte of the preamble with 1-byte START (0xFB).
• The MAC TX converts the eighth byte of the preamble to a 1-byte SFD (0xD5).

An underflow could occur on the Avalon^® streaming TX interface. An underflow occurs when the avalon_st_tx_valid signal is deasserted in the middle of frame transmission. When this happens, the 10GbE MAC TX inserts an error character |E| into the frame and forwards the frame to the XGMII.

The MAC TX maintains an average IPG between TX frames as required by the IEEE 802.3 Ethernet standard. The average IPG is maintained at 96 bit times (12 byte times) using the deficit idle count (DIC). The MAC TX inserts or deletes idle bytes depending on the value of the DIC; the DIC must be between 9 to 15 bytes. Averaging the IPG ensures that the MAC utilizes the maximum available bandwidth.

For 10M/100M/1G/2.5G operations, however, the MAC TX maintains a minimum IPG of 12 bytes time.

On the XGMII, the MAC TX performs the following:

• Aligns the first byte of the frame to lane 0 of the interface.
• Performs endian conversion. Transmit frames received from the client on the Avalon^® streaming interface are big endian. Frames transmitted on the XGMII are little endian; the MAC TX therefore transmits frames on this interface from the least significant byte.

The following figure shows the timing on the Avalon^® streaming TX data interface and XGMII. The least significant byte of the value in D5 is transmitted first on the XGMII.

The MAC TX implements the unidirectional feature as specified by clause 66 in the IEEE802.3 specification. This is an optional feature supported only in 10G operations. When you enable this feature, two output ports—unidirectional_en, unidirectional_remote_fault_dis— and two register fields—UniDir_En (Bit 0), UniDirRmtFault_Dis (Bit 1)— are accessible to control the TX XGMII interface.

An underflow happens in the middle of a frame that results in a premature termination on the XGMII. The remaining data from the Avalon^® streaming transmit interface is still received after the underflow but the data is dropped. The transmission of the next frame is not affected by the underflow.

The MAC RX receives Ethernet frames from the XGMII and forwards the payload with relevant frame fields to the client after performing checks and filtering invalid frames. Some frame fields are optionally removed from the frame before MAC RX forwards the frame to the client.

The following figure shows the typical flow of frame through the MAC RX.

The MAC RX expects the first byte of receive packets to be in lane 0, xgmii_rx_data[7:0]. If the 32-bit/64-bit adapter on the XGMII is present, the first byte of receive packets must be in lane 0 or lane 4, xgmii_rx_data[39:32]. Receive packets must also be preceded by a column of idle bytes or an ordered set such as a local fault. Packets that do not satisfy these conditions are invalid and the MAC RX drops them.

By default, the MAC RX only accepts packets that begin with a 1-byte START, 6-byte preamble, and 1-byte SFD. Packets that do not satisfy this condition are invalid and the MAC RX drops them.

When you enable the preamble passthrough mode (rx_preamble_control register = 1), the MAC RX only checks packets that begin with a 1-byte START. In this mode, the MAC RX does not remove the START and custom preamble, but passes the bytes along with the frame to the client.

After examining the packet header bytes in the correct order, the MAC IP retrieves the frame data from the packet. If the frame data starting from the destination address field is less than 17 bytes, the MAC IP may or may not drop the frame. If the erroneous frame is not dropped but forwarded, an undersized error is flagged to the external logic to drop the frame. If the frame is more than 17 bytes, the MAC forwards the frame as normal and flags error whenever applicable.

The MAC RX computes the CRC-32 checksum over frame bytes received and compares the computed value against the CRC field in the receive frame. If the values do not match, the MAC RX marks the frame invalid by setting avalon_st_rx_error[1] to 1 and forwards the receive frame to the client. When the CRC error indicator is asserted, the external logic is expected to drop the frame bytes.

The MAC RX can accept frames with the following address types:

• Unicast address—bit 0 of the destination address is 0.
• Multicast address—bit 0 of the destination address is 1.
• Broadcast address—all 48 bits of the destination address are 1.

The MAC RX always accepts broadcast frames. By default, the MAC RX also receives all unicast and multicast frames unless configured otherwise in the EN_ALLUCAST and EN_ALLMCAST bits of the rx_frame_control register.

When the EN_ALLUCAST bit is set to 0, the MAC RX filters unicast frames received. The MAC RX accepts only unicast frames with a destination address that matches the primary MAC address specified in the primary_mac_addr0 and primary_mac_addr1 registers. If any of the supplementary address bits are set to 1 (EN_SUPP0/1/2/3 in the rx_frame_control register), the MAC RX also checks the destination address against the supplementary addresses in the rx_frame_spaddr*_* registers.

When the EN_ALLMCAST bit is set to 0, the MAC RX drops all multicast frames. This condition does not apply to global multicast pause frames.

The MAC RX checks the length/type field to determine the frame type:

• Length/type < 0x600—The field represents the payload length of a basic Ethernet frame. The MAC RX continues to check the frame and payload lengths.
• Length/type >= 0x600—The field represents the frame type.
  • Length/type = 0x8100—VLAN or stacked VLAN tagged frames (up to a total of two tags with value 0x8100). The MAC RX continues to check the frame and payload lengths.
  • Length/type = 0x8808—Control frames. The next two bytes are the Opcode field which indicates the type of control frame. For pause frames (Opcode = 0x0001) and PFC frames (Opcode = 0x0101), the MAC RX proceeds with pause frame processing. By default, the MAC RX drops all control frames. If configured otherwise (FWD_CONTROL bit in the rx_frame_control register = 1), the MAC RX forwards control frames to the client.
  • For other field values, the MAC RX forwards the receive frame to the client.

The MAC RX checks the frame and payload lengths of basic, VLAN tagged, and stacked VLAN tagged frames. The MAC RX does not drop frames with invalid length but sets the error bits accordingly.

The frame length must be at least 64 (0x40) bytes and not exceed the following maximum value for the different frame types:

• Basic—The value in the rx_frame_maxlength register.
• VLAN tagged—The value in the rx_frame_maxlength register plus four bytes when the rx_vlan_detection[0] register bit is 0; or the value in the rx_frame_maxlength register when the rx_vlan_detection[0] register bit is set to 1.
• Stacked VLAN tagged—The value in the rx_frame_maxlength register plus eight bytes when the rx_vlan_detection[0] register bit is 0; or the value in the rx_frame_maxlength register when the rx_vlan_detection[0] register bit is set to 1.

The following error bits represent frame length violations:

• avalon_st_rx_error[2]—undersized frames.
• avalon_st_rx_error[3]—oversized frames.

The MAC IP core checks the payload length for frames other than control frames when the VLAN and stacked VLAN detection is disabled. The MAC RX keeps track of the actual payload length upon receiving a frame and checks the actual payload length against the length/type or client length/type field. The payload length must be between 46 (0x2E) and 1500 (0x5DC). For VLAN and stacked VLAN frames, the minimum payload length is 42 (0x2A) or 38 (0x26) respectively and not exceeding the maximum value of 1500 (0x5DC).

For an invalid payload length, the MAC RX sets the avalon_st_rx_error[4] bit to 1. This error occurs when the actual payload length is less than the value of the length/type field. If the actual payload length is more than the value of the length/type field, the MAC RX assumes that the frame contains excessive padding and does not set this error bit to 1. If the value of the length/type field is more than the actual payload length, the MAC RX sets the avalon_st_rx_error[4] bit to 1, and the packet content will not be accurate.

By default, the MAC RX forwards receive frames to the client without removing the CRC field and padding bytes from the frames. You can configure the MAC RX to remove the CRC field by setting the rx_padcrc_control register to 1. To remove both the CRC field and padding bytes, set the rx_padcrc_control register to 3.

When enabled, the MAC RX removes padding bytes from receive frames whose payload length is less than the following values for the different frame types:

• 46 bytes for basic frames
• 42 bytes for VLAN tagged frames
• 38 bytes for stacked VLAN tagged frames

The MAC RX removes padding bytes only when the VLAN and stacked VLAN detection is enabled (rx_vlan_detection[0] = 0). Otherwise, the MAC RX does not remove padding bytes even if padding bytes removal is enabled.

When an overflow occurs on the client side, the client can backpressure the Avalon^® streaming receive interface by deasserting the avalon_st_rx_ready signal. If an overflow occurs, the MAC RX sets the error bit, avalon_st_rx_error[5], to 1 to indicate an overflow. The MAC RX drops subsequent frames if the overflow condition persists. The MAC RX then continues to receive data when the overflow condition ceases.

The MAC IP core implements the following flow control mechanisms:

• IEEE 802.3 flow control—implements the IEEE 802.3 Annex 31B standard to manage congestion. When the MAC IP core experiences congestion, the core sends a pause frame to request its link partner to suspend transmission for a given period of time. This flow control is a mechanism to manage congestion at the local or remote partner. When the receiving device experiences congestion, it sends an XOFF pause frame to the emitting device to instruct the emitting device to stop sending data for a duration specified by the congested receiver. Data transmission resumes when the emitting device receives an XON pause frame (pause quanta = zero) or when the timer expires.
• Priority-based flow control (PFC)—implements the IEEE 802.1Qbb standard. PFC manages congestion based on priority levels. It supports up to 8 priority queues. When the receiving device experiences congestion on a priority queue, it sends a PFC frame requesting the emitting device to stop transmission on the priority queue for a duration specified by the congested receiver. When the receiving device is ready to receive transmission on the priority queue again, it sends a PFC frame instructing the emitting device to resume transmission on the priority queue.

To use the IEEE 802.3 flow control, set the following registers:

• On the TX datapath:
  • Set tx_pfc_priority_enable[7:0] to 0 to disable the PFC. The rest of the bits are unused.
  • Set tx_pauseframe_enable[0] to 1 to enable the IEEE 802.3 flow control.

• On the RX datapath:
  • Set rx_pfc_control[7:0] to 1 to disable the PFC. The rest of the bits are mostly unused.
  • Set the IGNORE_PAUSE bit in the rx_frame_control register to 0 to enable the IEEE 802.3 flow control.

When the MAC receives an XOFF pause frame, it stops transmitting frames to the remote partner for a period equal to the pause quanta field of the pause frame. If the MAC receives a pause frame in the middle of a frame transmission, the MAC finishes sending the current frame and then suspends transmission for a period specified by the pause quanta. The MAC resumes transmission when it receives an XON pause frame or when the timer expires. The pause quanta received overrides any counter currently stored. When the remote partner sends more than one pause quanta, the MAC sets the value of the pause to the last quanta it received from the remote partner. You have the option to configure the MAC to ignore pause frames and continue transmitting frames by setting the IGNORE_PAUSE bit in the rx_frame_control register to 1.

Use one of the following methods to trigger pause frame transmission:

• avalon_st_pause_data signal (tx_pauseframe_enable[2:1] set to 0)—You can connect this 2-bit signal to a FIFO buffer or a client. Bit setting:
  • avalon_st_pause_data[1]: 1—triggers the transmission of XOFF pause frames.
  • avalon_st_pause_data[0]: 1—triggers the transmission of XON pause frames. The transmission of XON pause frames only trigger for one time after XOFF pause frames regardless of how long the avalon_st_pause_data[0] signal is asserted.
  If pause frame transmission is triggered when the MAC is generating a pause frame, the MAC ignores the incoming request and completes the generation of the pause frame. Upon completion, if the avalon_st_pause_data signal remains asserted, the MAC generates a new pause frame and continues to do so until the signal is deasserted. You can also configure the gap between successive XOFF requests for using the tx_pauseframe_quanta register. XON pause frames will only be generated if the MAC generates XOFF pause frames.
• tx_pauseframe_control register (tx_pauseframe_enable[2:0] set to 0x1)—A host (software) can set this register to trigger pause frames transmission. Setting tx_pauseframe_control[1] to 1 triggers the transmission of XOFF pause frames; setting tx_pauseframe_control[0] to 1 triggers the transmission of XON pause frames. The register clears itself after the request is executed.

You can configure the pause quanta in the tx_pauseframe_quanta register. The MAC sets the pause quanta field in XOFF pause frames to this register value.

The following figure shows the transmission of an XON pause frame. The MAC sets the destination address field to the global multicast address, 01-80-C2-00-00-01 (0x010000c28001) and the source address to the MAC primary address configured in the tx_addrins_macaddr0 and tx_addrins_madaddr1 registers.

When the MAC RX receives a PFC frame from the remote partner, it asserts the avalon_st_rx_pfc_pause_data[n] signal if Pause Quanta n is valid (Pause Quanta Enable [n] = 1) and greater than 0. The client suspends transmission from the TX priority queue n for the period specified by Pause Quanta n. If the MAC RX asserts the avalon_st_rx_pfc_pause_data[n] signal in the middle of a client frame transmission for the TX priority queue n, the client finishes sending the current frame and then suspends transmission for the queue.

When the MAC RX receives a PFC frame from the remote partner, it deasserts the avalon_st_rx_pfc_pause_data[n] signal if Pause Quanta n is valid (Pause Quanta Enable [n] = 1) and equal to 0. The MAC RX also deasserts this signal when the timer expires. The client resumes transmission for the suspended TX priority queue when the avalon_st_rx_pfc_pause_data[n] signal is deasserted.

When the remote partner sends more than one pause quanta for the TX priority queue n, the MAC RX sets the pause quanta n to the last pause quanta received from the remote partner.

PFC frame generation is triggered through the avalon_st_tx_pfc_gen_data signal. Set the respective bits to generate XOFF or XON requests for the priority queues.

For XOFF requests, you can configure the pause quanta for each priority queue using the pfc_pause_quanta_n registers. For an XOFF request for priority queue n, the MAC TX sets bit n in the Pause Quanta Enable field to 1 and the Pause Quanta n field to the value of the pfc_pause_quanta_n register. You can also configure the gap between successive XOFF requests for a priority queue using the pfc_holdoff_quanta_n register.

For XON requests, the MAC TX sets the pause quanta to 0. You must generate a XOFF request before generating a XON request.

The MAC IP core consists of the following reset domains:

• CSR reset—global reset,
• MAC TX reset, and
• MAC RX reset.

These resets are asynchronous events. When the MAC or any part of it goes into reset, the user application must manage possible asynchronous changes to the states of the MAC interface signals. The MAC does not guarantee any reset sequence. Intel recommends the sequence shown in the following diagram and table for CSR reset, and TX and RX datapaths reset respectively.

You can connect the LL 10GbE MAC IP core to a PHY IP core using XGMII, GMII, or MII interfaces.

To connect the MAC IP core to 64-bit PHYs, ensure that you enable the Use legacy Ethernet 10G MAC XGMII Interface option.

The MAC IP core supports this feature for use with the Intel^® Arria^® 10, Intel^® Cyclone^® 10 GX, and Intel^® Stratix^® 10 Transceiver Native PHY IP core preset configurations. When operating in this mode, the round-trip latency for the MAC and PHY is reduced to 140 ns (for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices) or 168 ns (for Intel^® Stratix^® 10 devices) with a slight increase in resource count and clock frequencies.

When you enable this feature, the MAC IP core implements two additional signals to determine the validity of the data on the TX and RX XGMII. These signals, xgmii_tx_valid and xgmii_rx_valid, ensure that the effective data rate of the MAC is 10 Gbps. You must also observe the following guidelines when using the register mode:

• For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, the selected preset is 10GBASE-R Register Mode.
• For Intel^® Stratix^® 10 devices, the selected preset is 10GBASE-R 1588.
• The PHY must expose the TX and RX parallel clocks.
• The PHY must expose data valid signals, with MAC/PHY TX/RX interfaces in register mode, as in the IEEE 1588v2 configuration.
• The MAC and PHY run at the parallel clock frequency of 322.265625 MHz (the PCS/PMA width equals to 32).

The LL Ethernet 10G MAC supports link fault generation and detection.

When the MAC RX receives a local fault, the MAC TX starts sending remote fault status (0x0200009c) on the XGMII. If the packet transmission was in progress at the time, the remote fault bytes will override the packet bytes until the fault condition ceases.

When the MAC RX receives a remote fault, the MAC TX starts sending IDLE bytes (0x07070707) on its XGMII. If packet transmission was in progress at the time, the IDLE bytes will override the packet bytes until the fault condition ceases.

The MAC considers the link fault condition has ceased if the client and the remote partner both receive valid data in more than 127 columns.

When you instantiate the MAC RX only variation, connect the link_fault_status_xgmii_rx_data signal to the corresponding RX client logic to handle the link fault. Similarly, when you instantiate the MAC TX only variation, connect the link_fault_status_xgmii_tx_data signal to the corresponding TX client logic.

The IEEE 1588v2 option provides time stamp for receive and transmit frames in the LL Ethernet 10G MAC IP core designs. The feature consists of Precision Time Protocol (PTP). PTP is a protocol that accurately synchronizes all real time-of-day clocks in a network to a master clock.

The IEEE 1588v2 option has the following features:

• Supports 4 types of PTP clock on the transmit datapath:
  • Master and slave ordinary clock
  • Master and slave boundary clock
  • End-to-end (E2E) transparent clock
  • Peer-to-peer (P2P) transparent clock
• Supports PTP with the following message types:
  • PTP event messages—Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp.
  • PTP general messages—Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Announce, Management, and Signaling.
• Supports simultaneous 1-step and 2-step clock synchronizations on the transmit datapath.
  • 1-step clock synchronization—The MAC function inserts accurate timestamp in Sync PTP message or updates the correction field with residence time.
  • 2-step clock synchronization—The MAC function provides accurate timestamp and the related fingerprint for all PTP message.
• Supports the following PHY operating speed random error:
  • 10 Gbps—Timestamp accuracy of ± 1 ns
  • 5 Gbps—Timestamp accuracy of ± 2 ns
  • 2.5 Gbps—Timestamp accuracy of ± 2 ns
  • 1 Gbps—Timestamp accuracy of ± 2 ns
  • 100 Mbps—Timestamp accuracy of ± 5 ns
• Supports static error of ± 3 ns across all speeds.
  Note: The static error for Intel^® Stratix^® 10 devices is ± 4 ns.
• Supports IEEE 802.3, UDP/IPv4, and UDP/IPv6 protocol encapsulations for the PTP packets.
• Supports untagged, VLAN tagged, and Stacked VLAN Tagged PTP packets, and any number of MPLS labels. The packet classifier under user control parses the packet (Ethernet packet or MPLS packet) and gives the IP core the required offset, at which either the Time of Day (ToD) or correction factor (CF) update can happen.
• Supports configurable register for timestamp correction on both transmit and receive datapaths.
• Supports ToD clock that provides streams of 64-bit and 96-bit timestamps. The 64-bit timestamp is for transparent clock devices and the 96-bit timestamp is for ordinary clock and boundary clock devices.

The IEEE 1588v2 feature supports 1-step and 2-step clock synchronizations on the TX datapath.

• For 1-step clock synchronization,
  • Timestamp insertion depends on the PTP device and message type.
  • The MAC function inserts a timestamp in the PTP packet when the client specifies the Timestamp field offset and asserts Timestamp Insert Request.
  • Depending on the PTP device and message type, the MAC function updates the residence time in the correction field of the PTP packet when the client asserts tx_etstamp_ins_ctrl_residence_time_update and Correction Field Update. The residence time is the difference between the egress and ingress timestamps.
  • For PTP packets encapsulated using the UDP/IPv6 protocol, the MAC function performs UDP checksum correction using extended bytes in the PTP packet.
  • The MAC function recomputes and reinserts CRC-32 into PTP packets each time the timestamp or correction field is updated, even when CRC insertion is disabled using the tx_crc_control[1] register bit.
  • The format of timestamp supported includes 1588v1 and 1588v2.
  • The MAC function updates tx_egress_p2p_val[45:0] into correction field of PTP packet when the client asserts tx_egress_p2p_update.
  • The MAC function updates asymmetry value into correction field of PTP packet when the client asserts tx_egress_asymmetry_update. The asymmetry value is retrieved from configuration registers.
• For 2-step clock synchronization, the MAC function returns the timestamp and the associated fingerprint for all TX frames when the client asserts tx_egress_timestamp_request_valid.

The following table summarizes the timestamp and correction field insertions for various PTP messages in different PTP clocks.

In the RX datapath, the IEEE 1588v2 feature provides a timestamp for all receive frames. The timestamp is aligned with the avalon_st_rx_startofpacket signal.

The MAC function, with the IEEE 1588v2 feature, supports PTP packet transfer for the following transport protocols:

• IEEE 802.3
• UDP/IPv4
• UDP/IPv6

The LL Ethernet 10G MAC Intel^® FPGA IP core provides a total of 4Kb register space that is accessible via the Avalon^® memory-mapped interface. Each register is 32 bits wide. Access only registers that apply to the variation of the MAC IP core you are using and enabled features. For example, if you are using the MAC RX only variation, avoid accessing registers specific to the MAC TX only variation. Accessing reserved registers or specific registers to variations that you are not using may produce non-deterministic behavior.