H-Tile Hard IP Ethernet Intel® FPGA IP User Guide: Stratix® 10 Devices

ID 683430
Date 4/09/2024
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

6.1. TX MAC Interface to User Logic

The H-Tile Hard IP for Ethernet IP core TX client interface in MAC+PCS variations employs the Avalon-ST protocol. The Avalon-ST protocol is a synchronous point-to-point, unidirectional interface that connects the producer of a data stream (source) to a consumer of data (sink). The key properties of this interface include:

  • Start of packet (SOP) and end of packet (EOP) signals delimit frame transfers.
  • The SOP must always be in the MSB, simplifying the interpretation and processing of incoming data.
  • A valid signal qualifies signals from source to sink.
  • The sink applies backpressure to the source by using the ready signal. The source typically responds to the deassertion of the ready signal from the sink by driving the same data until the sink can accept it. The readyLatency defines the relationship between assertion and deassertion of the ready signal, and cycles which are considered to be ready for data transfer.

The client acts as a source and the TX MAC acts as a sink in the transmit direction.

Table 14.  Signals of the Avalon-ST TX Client InterfaceAll interface signals are clocked by the i_clk_tx clock. The value you specify for Enter Ready Latency in the H-Tile Hard IP for Ethernet IP parameter editor is the Avalon-ST readyLatency value on this interface.

Signal Name

Description

i_clk_tx

The TX clock for the IP core is i_clk_tx. The frequency of this clock is 402.832 MHz.

i_tx_data[511:0]

TX data.

If the preamble pass-through feature is enabled, data begins with the preamble.

The H-Tile Hard IP for Ethernet IP core does not process incoming packets of less than nine bytes. You must ensure such frames do not reach the TX client interface. The IP core marks incoming packets of 9 to 13 bytes as error packets, by asserting the i_tx_error signal in the end-of-packet clock cycle.

You must send each TX data packet without intermediate IDLE cycles. Therefore, you must ensure your application can provide the data for a single packet in consecutive clock cycles. If data might not be available otherwise, you must buffer the data in your design and wait to assert i_tx_startofpacket when you are assured the packet data to send on i_tx_data is available or will be available on time.

i_tx_data[0] is LSB.

i_tx_valid

When asserted i_tx_data is valid. This signal must be continuously asserted between the assertions of i_tx_startofpacket and i_tx_endofpacket for the same packet.

i_tx_empty[5:0]

Indicates the number of empty bytes on i_tx_data when i_tx_endofpacket is asserted.

i_tx_startofpacket

When asserted, indicates that i_tx_data holds the first clock cycle of data in a packet (start of packet). Assert for only a single clock cycle for each packet.

When i_tx_startofpacket is asserted, the MSB of i_tx_data drives the start of packet.
i_tx_endofpacket When asserted, indicates that i_tx_data holds the final clock cycle of data in a packet (end of packet). Assert for only a single clock cycle for each packet.

For some legitimate packets, i_tx_startofpacket and i_tx_endofpacket are asserted on the same clock cycle.

o_tx_ready When asserted, indicates that the MAC can accept the data readyLatency clock cycles after the current cycle. The IP core asserts the o_tx_ready signal on clock cycle <n> to indicate that clock cycle <n + readyLatency> is a ready cycle. The client may only transfer data during ready cycles. If the IP core deasserts o_tx_ready during a packet transfer on the TX MAC client interface, the client must stall the data on i_tx_data.

The o_tx_ready signal indicates the MAC is ready to receive data in normal operational mode. However, the o_tx_ready signal might not be an adequate indication following reset. To avoid sending packets before the Ethernet link is able to transmit them reliably, you should ensure that the application does not send packets on the TX client interface until after the o_tx_lanes_stable signal is asserted.

i_tx_error When asserted in an EOP cycle (while i_tx_endofpacket is asserted), directs the IP core to insert an error in the packet before sending it on the Ethernet link.

This signal supports the client in selectively invalidating a packet. It is also a test and debug feature. In loopback mode, the IP core recognizes the packet upon return as a malformed packet.

i_tx_pause When asserted, directs the IP core to send a PAUSE XOFF frame on the Ethernet link. The rising edge triggers the request. You must maintain this signal at the value of 1 until you wish the IP core to end the PAUSE period. The IP core sends a PAUSE XOFF frame after it completes processing of the current in-flight TX packet, and periodically thereafter, until you deassert the i_tx_pause signal. When you deassert the i_tx_pause signal, the IP core sends a PAUSE XON frame on the Ethernet link.

This signal is functional only if standard Ethernet flow control is enabled.

Note: Standard Ethernet flow control is enabled if the value of the RTL parameter flow_control is one of sfc, sfc_no_xoff, both, or both_no_xoff. If you do not specify the value of the RTL parameter in your IP core instance, but you generate the IP core variation with the value of the Stop TX traffic when link partner sends pause set to Yes or No, pause flow control is also enabled.
i_tx_pfc[7:0] When a bit is asserted, directs the IP core to send a PFC XOFF frame on the Ethernet link for the corresponding priority queue. The rising edge triggers the request. You must maintain this signal at the value of 1 until you wish the IP core to end the pause period. The IP core sends a PFC XOFF frame after it completes processing of the current in-flight TX packet, and periodically thereafter, until you deassert the i_tx_pfc bit. When you deassert the bit, the IP core sends a PFC XON frame on the Ethernet link for the corresponding priority queue.

This signal is functional only if priority flow control is enabled.

Note: Priority flow control is enabled if the value of the RTL parameter flow_control is one of pfc, pfc_no_xoff, both, or both_no_xoff. If you do not specify the value of the RTL parameter in your IP core instance, but you generate the IP core variation with the value of the Stop TX traffic when link partner sends pause set to Yes or No, priority flow control is also enabled.
i_tx_skip_crc Specifies how the TX MAC should process the current TX MAC client interface packet. Use this signal to temporarily turn off source insertion for a specific packet and to override the default behaviors of padding to minimum packet size and inserting CRC.

If this signal is asserted, directs the TX MAC to not insert CRC, not add padding bytes, and not implement source address insertion. You can use this signal to indicate the data on i_tx_data includes CRC, padding bytes (if relevant), and the correct source address.

If this signal is not asserted, and source address insertion is enabled, directs the TX MAC to overwrite the source address. The MAC copies the new source address from the TXMAC_SADDR register.

If this signal is not asserted, whether or not source address insertion is enabled, the TX MAC inserts padding bytes if needed and inserts CRC in the packet.

The client must maintain the same value on this signal for the duration of the packet (from the cycle in which it asserts i_tx_startofpacket through the cycle in which it asserts i_tx_endofpacket, inclusive).

Below examples show the impact on transferred data due to the readyLatency.

Figure 22. TX Avalon-ST MAC Client Interface for H-Tile Hard IP for Ethernet IP Core with readyLatency = 1In this example, data rate is 100-Gbps and readyLatency is 1.
Figure 23. TX Avalon-ST MAC Client Interface for H-Tile Hard IP for Ethernet IP Core with readyLatency = 3This example shows the 100-Gbps data rate with readyLatency set to 3.