2.11.2. RX MAC Interface to User Logic

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

Download PDF

ID 683468

Date 8/30/2022

Version

Public

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

Visible to Intel only — GUID: kwm1519648656215

Ixiasoft

View Details

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 40. 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 41. 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.

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

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

2.11.2. RX MAC Interface to User Logic