E-Tile Hard IP User Guide: E-Tile Hard IP for Ethernet and E-Tile CPRI PHY Intel® FPGA IPs

ID 683468
Date 7/23/2024
Public
Document Table of Contents

2.11.2. RX MAC Interface to User Logic

The E-Tile Hard IP for Ethernet Intel FPGA IP RX client interface in MAC+PCS variations employs the Avalon® streaming interface protocol. The Avalon® streaming interface 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 data you receive on this interface.
  • A valid signal qualifies signals from source to sink.

The RX MAC acts as a source and the client acts as a sink in the receive direction.

Table 30.  Signals of the Avalon® Streaming RX Client InterfaceAll interface signals are clocked by the RX clock. The signal names are standard Avalon® streaming interface signals with slight differences to indicate the variations. For example:
  • For variants with single 10GE/25GE channel: i_sl_rx_data
  • For variants with more than 1 channel: i_sl_rx_data[n-1:0]
  • For variants with single 100GE channel:i_rx_data

Name

Width

Description

i_sl_clk_rx

i_sl_clk_rx[n-1:0]

i_clk_rx

1 bit for each channel

The RX clock for the IP core that drives the channel.

o_sl_rx_data

o_sl_rx_data[n-1:0]

o_rx_data

64 bits for each channel (10G/25G)

512 bits (100G)

RX data. The highest order bit is the MSB and bit 0 is the LSB. Bytes are read in the usual left to right order. The IP core reverses the byte order to meet the requirements of the Ethernet standard.

o_sl_rx_valid

o_sl_rx_valid[n-1:0]

o_rx_valid

1 bit for each channel

When asserted, indicates that RX data is valid. Only valid between the SOP and EOP signals.

This signal might be deasserted between the assertion of the SOP and EOP signals.

o_sl_rx_empty

o_sl_rx_empty[n-1:0]

o_rx_empty

3 bits for each channel (10G/25G)

6 bits for each channel (100G)

Indicates the number of empty bytes on the RX data signal when EOP signal is asserted, starting from the least significant byte (LSB).

o_sl_rx_startofpacket

o_sl_rx_startofpacket[n-1:0]

o_rx_startofpacket

1 bit for each channel

When asserted, indicates that the RX data signal holds the first clock cycle of data in a packet (start of packet). The IP core asserts this signal for only a single clock cycle for each packet.

When the SOP signal is asserted, the MSB of the RX data signal drives the start of packet.

o_sl_rx_endofpacket

o_sl_rx_endofpacket[n-1:0]

o_rx_endofpacket

1 bit for each channel

When asserted, indicates that the RX data signal holds the final clock cycle of data in a packet (end of packet). The IP core asserts this signal for only a single clock cycle for each packet.

In the case of an undersized frame or in the case of a frame that is exactly 64 bytes long, the SOP and EOP signals might be asserted in the same clock cycle.

o_sl_rx_error

o_sl_rx_error[n-1:0]

o_rx_error

6 bits for each channel 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.

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.
  • Bit [1]: CRC error. If this bit has the value of 1, the IP core detected a CRC error or an Error character in the frame.
  • Bit [2]: undersized frame. If this bit has the value of 1, the frame size is between nine and 63 bytes, inclusive. In this case the IP core also sets o_rx_error[1] to signal a CRC error.

    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. If the preamble-passthrough and CRC forwarding settings cause the RX MAC to strip out bytes such that only eight bytes or less remain in the frame, the IP core also does not recognize the frame, and those cases are not reported here. If the frame is malformed, the case is not reported here. This bit is not applicable for 100GE.

  • Bit [3]: oversized frame. If this bit has the value of 1, the frame size is greater than the maximum frame size you specified as the value of the parameter editor RX Maximum Frame Size parameter or overwrote with the rx_max_frame_size RTL parameter.

    If the frame is malformed, the case is not reported here. This bit is not applicable for 100GE.

  • Bit [4]: payload length error. If this bit has the value of 1, the payload received in the frame is shorter than the length field value, and the value in the length field is less than or equal 1500 bytes. If the frame is oversized or undersized, the case is not reported here. If the frame is malformed, the case is not reported here.
  • Bit [5]: Reserved.

o_sl_rxstatus_valid

o_sl_rxstatus_valid[n-1:0]

o_rxstatus_valid

1 bit for each channel When asserted, indicates that o_rxstatus_data is driving valid data.

o_sl_rxstatus_data

o_sl_rxstatus_data[n-1:0]

o_rxstatus_data

40 bits for each channel

Specifies information about the received frame. The following fields are defined:

  • [Bit 39]: When asserted, indicates a PFC frame
  • [Bits 38:36]: Reserved
  • Bit[35]: When asserted, indicates a PAUSE frame
  • Bit[34]: When asserted, indicates a Control (Type is 0x8808) frame
  • Bit[33]: When asserted, indicates a VLAN frame
  • Bit[32]: When asserted, indicates a stacked VLAN frame
  • Bits[31:0]: Reserved

o_sl_rx_pause

o_sl_rx_pause[n-1:0]

o_rx_pause

1 bit for each channel When asserted, indicates the IP core received a PAUSE XOFF frame on the Ethernet link. The IP core deasserts this signal when the quanta count from the PAUSE XOFF request expires.

If you set the parameter editor Stop TX traffic when link partner sends pause parameter to the value of Yes, or overwrite it with the sfc or both value for the flow_control RTL parameter, the TX MAC stops traffic in response to the PAUSE XOFF frame. In this case, the quanta count decrements while the IP core stops traffic.

If the settings direct the TX MAC to not stop traffic in response to the PAUSE XOFF frame, the quanta counter decrements on every valid cycle on the TX MAC client interface. Each quanta represents 512 bits. Therefore, the counter decrements by one half in every valid clock cycle in 100G variations.

o_sl_rx_pfc

o_sl_rx_pfc[n-1:0]

o_rx_pfc

8 bits for each channel When a bit is asserted, indicates the IP core received a PFC XOFF frame on the Ethernet link for the corresponding priority queue. The IP core deasserts each bit when the XOFF frame's quanta count expires. The PFC quanta counters decrement on every valid cycle on the TX MAC client interface. Each quanta represents 512 bits. Therefore, the counter decrements by one half in every valid clock cycle in 100G variations. In summary, the width of the pulse indicates the length of the requested pause in traffic for the queue.
Figure 41. Receiving Data Using the RX MAC Client Interface

The figure above shows how to receive data using the RX MAC client interface. The interface complies with the Avalon® streaming interface specification.

  • Packets always start on the leftmost of the byte of o_rx_data (SOP aligned).
  • When the frame ends, o_rx_empty is set to the number of unused bytes in o_rx_data, starting from the right (byte 0).
    • In this example, o_rx_data on the last cycle of the packet has 5 empty bytes.
    • The minimum number of bytes on the last cycle is 1.
  • The framing and data ports are only valid when o_rx_data is high.
Note: The interface does not take direct backpressure
Table 31.  RX MAC Field Positions in o_rx_data with Preamble Passthrough Disabled
100G

i_tx_data

10G/25G

i_sl_tx_data

MAC Field Note
[511:504] [63:56]’ Dest Addr[47:40] The first octet of the Destination Address, follows Start Frame Delimiter (SFD).
[503:496] [55:48]’ Dest Addr[39:32]
[495:488] [47:40]’ Dest Addr[31:24]  
[495:480] [39:32]’ Dest Addr[23:16]  
[479:472] [31:24]’ Dest Addr[15:8]  
[471:464] [23:16]’ Dest Addr[7:0]  
[463:456] [15:8]’ Src Addr[47:40]  
[455:448] [7:0]’ Src Addr[39:32]  
[447:440] [63:56] Src Addr[31:24]  
[439:432] [55:48] Src Addr[23:16]  
[431:424] [47:40] Src Addr[15:8]  
[423:416] [39:32] Src Addr[7:0]  
[415:408] [31:24] Length/Type[15:0]
[407:400] [23:16] Length/Type[7:0]
[399:0] [15:0]
Figure 42. RX MAC Status and ErrorsThe figure shows how status and error information are presented with RX packets as they arrive.

The status valid port is provided for backward compatibility, but always asserts when o_rx_endofpacket is asserted and valid.