2.11.1. TX 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 7/23/2024

Version

Public

Visible to Intel only — GUID: oga1519645575547

Ixiasoft

View Details

2.11.1. TX MAC Interface to User Logic

The E-Tile Hard IP for Ethernet Intel® FPGA IP TX 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 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 Ready latency 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 28. Signals of the Avalon® Streaming TX Client InterfaceAll interface signals are clocked by the TX 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_tx_data`

For variants with more than 1 channel: `i_sl_tx_data[n-1:0]`

For variants with single 100GE channel: `i_tx_data`
Signal Name	Width	Description
`i_sl_clk_tx` `i_sl_clk_tx[n-1:0]` `i_clk_tx`	1 bit for each channel	The TX clock for the IP core that drives the channel.
`i_sl_tx_data` `i_sl_tx_data[n-1:0]` `i_tx_data`	64 bits (10G/25G) 512 bits (100G)	TX data. The E-Tile Hard IP for Ethernet Intel® FPGA IP 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 errored, by adding Error Control bytes to the packet upon transmission. 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 the SOP signal when you are assured the packet data to send on the TX data is available or can be available on time.
`i_sl_tx_valid` `i_sl_tx_valid[n-1:0]` `i_tx_valid`	1 bit for each channel	When asserted, the TX data signal is valid. This signal must be continuously asserted between the assertions of the start of packet and end of packet signals for the same packet.
`i_sl_tx_empty` `i_sl_tx_empty[n-1:0]` `i_tx_empty`	3 bits for each channel (10G/25G) 6 bits (100G)	Indicates the number of empty bytes on the TX data when the EOP signal is asserted.
`i_sl_tx_startofpacket` `i_sl_tx_startofpacket[n-1:0]` `i_tx_startofpacket`	1 bit for each channel	When asserted, indicates that the 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 the SOP signal is asserted, the MSB of the TX data drives the start of packet.
`i_sl_tx_endofpacket` `i_sl_tx_endofpacket[n-1:0]` `i_tx_endofpacket`	1 bit for each channel	When asserted, indicates that the 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, the SOP and EOP signals are asserted on the same clock cycle.
`o_sl_tx_ready` `o_sl_tx_ready[n-1:0]` `o_tx_ready`	1 bit for each channel	When asserted, indicates that the MAC can accept the data Ready latency clock cycles after the current cycle. The IP core asserts the ready signal on clock cycle <`n`> to indicate that clock cycle <`n` + Ready latency> is a ready cycle. The client may only transfer data during ready cycles. If the IP core deasserts the ready during a packet transfer on the TX MAC client interface, the client must stall the data on the TX data. The ready signal indicates the MAC is ready to receive data in normal operational mode. However, the 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_sl_tx_error` `i_sl_tx_error[n-1:0]` `i_tx_error`	1 bit for each channel	When asserted in an EOP cycle (while the EOP signal 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_sl_tx_pause` `i_sl_tx_pause[n-1:0]` `i_tx_pause`	1 bit for each channel	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 want 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. Note: For 10G/25G channels, you should hold the `i_sl_tx_pause` signal more than 205 ns to get the request captured by the MAC. 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_sl_tx_pfc` `i_sl_tx_pfc[n-1:0` `i_tx_pfc`	8 bits for each channel	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 want 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. Note: For 10G/25G channels, you should hold the `i_sl_tx_pfc` signal more than 205 ns to get the request captured by the MAC. 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_sl_tx_skip_crc` `i_sl_tx_skip_crc[n-1:0]` `i_tx_skip_crc`	1 bit for each channel	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 the TX data signal 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 the SOP signal through the cycle in which it asserts the EOP signal, inclusive).

Figure 38. Transmitting Data Using the TX Avalon® Streaming MAC Client Interface

Note: The transmit operations for the single lane ports (i_sl_*) are equivalent to the multi-lane ports.

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

Data valid (i_sl_tx_valid) must be held high from the start to end of a packet, and must be low outside of a packet.
Packets always start on the leftmost of the byte of i_tx_data (SOP aligned).
You can set the Ready latency through the parameter editor.
- When o_tx_ready deasserts, i_tx_data must be paused for as many cycles as o_tx_ready is deasserted, starting Ready latency cycles later. In this example, Ready latency is 1. So the cycle after o_tx_ready deasserts for 1 cycle, i_tx_data is paused for 1 cycle.
When the frame ends, i_tx_empty is set to the number of unused bytes in i_tx_data, starting from the right (byte 0).
- In this example, i_tx_data on the last cycle of the packet has 3 empty bytes.
- The minimum number of bytes on the last cycle is 1.

Figure 39. Fields and Frame Boundaries in an Ethernet PacketWhen you turn off Preamble Passthrough in the parameter editor, i_tx_data must be written as shown below for the first cycle of data presented to the MAC.

Note: For 10G/25G channels, multiple cycles are required to write the header data.

Table 29. TX MAC Field Positions in i_tx_data with Preamble Passthrough Disabled10G/25G requires multiple transfer cycle for header data. The (') symbol in the **10G/25G i_sl_tx_data** column represents transfer on the subsequent cycle.
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]	When you turn on Source Address Insertion, contents are replaced by txmac_saddr unless `i_tx_skip_crc` is high.
[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]'	…

The i_tx_error or i_sl_tx_error port allows packets to be marked as errored when they are complete.

Figure 40. Using i_tx_error

Because the core uses a cut-through interface, the core starts transmitting the packet data it is given as soon as possible. If the core discovers an error after the packet starts, e.g. in a bridging system where the receiver also uses a cut-through interface, you can use i_tx_error to invalidate the packet. You can also use i_tx_error for testing, to generate errored packets, and confirm that the other end of the link is able to reject the errored packets.

To invalidate an errored frame, end it with i_tx_endofpacket and assert i_tx_error. If the frame is good, deassert i_tx_error.

Note: Using i_tx_error does not provide a robust test of the remote CRC, because it uses MII Error Control bytes to indicate error, rather than relying on corrupted CRC bits.

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.1. TX MAC Interface to User Logic