Receive AXI4-Stream Interface - 7.2 English

AXI 1G/2.5G Ethernet Subsystem Product Guide (PG138)

Document ID
PG138
Release Date
2023-11-15
Version
7.2 English

Unlike the transmit AXI4-Stream Control interface, the receive AXI4-Stream Status interface has only one format type (TAG/FLAG).

The receive interface has been designed to allow throttling on both the AXI4-Stream Status bus and the AXI4-Stream Data bus. After receiving the Ethernet data, the receive channel initiates transfer on the AXI4-Stream Status Interface before starting the transfer on AXI4-Stream Data Interface. The completion of the transfers on these interfaces depends on their throttling. See Figure 2 for a receive waveform diagram. This diagram shows what signals are required when connected to a core such as AXI_DMA. When connecting to a core such as AXI_FIFO_MM_S, a signal minimization can be made because the receive status bus information is not required.

In this case, the external core must actively drive the signals axi_str_rxs_aclk and axi_str_rxs_aresetn, axi_str_rxs_tready must be tied High, and all of the axi_str_rxs* inputs to the external core can be left open.

For the loopback of the receive AXI4-Stream to transmit AXI4-Stream to work, the receive AXI4-Stream Data bus is throttled by the transmit AXI4-Stream Data bus until the receive AXI4-Stream Status has been received by the transmit channel.

The receive AXI4-Stream Status frame always contains six 32-bit status words (words 0 to 5). The following figure and tables show the definitions of these words. Reserve fields do not have defined values. If the parameter C_RXCSUM is 0, the receive checksum offload function is not included in the build and receive AXI4-Stream Status word 4, bits 15-0 are always zero. If C_RXCSUM is 1, the raw checksum is calculated for every frame received and is placed in the receive AXI4-Stream Status word 4. For more information about using the receive raw checksum value, see Partial TCP/UDP Checksum Offload in Hardware .

Receive AXI4-Stream Status word 5, bits 15-0 always contains the number of bytes in length of the frame being sent across the receive AXI4-Stream Status interface.

The axi_str_rxd_strb(3:0) bus is used to indicate how many bytes in the last 32-bit word of the AXI4-Stream Data bus. A 1 is used to indicate valid bytes. For example, axi_str_rxd_strb(3:0) = “0001” indicates that only the first byte of the last word of the AXI4-Stream Data bus [axi_str_rxd_data(7:0) ] is valid and the remaining three bytes are unused. axi_str_rxd_strb(3:0) = “0011” would indicate that the first two bytes of the last word of the payload [axi_str_rxd_data(15:0)] are valid and the remaining two bytes are unused.

Figure 1. Receive AXI4-Stream Status Words
Table 1. Receive AXI4-Stream Status Word 0 – TAG
Bits Name Description
31–28 Flag 0x5 = Receive Status Frame
27–0 Reserved Undefined value.
Table 2. Receive AXI4-Stream Status Word 1 – APP0
Bits Name Description
31–16 Reserved Undefined value.
15–0 MCAST_ADR_U Multicast Address (47:32): These are the upper 16 bits of the multicast destination address of this frame. This value is only valid if the AXI4-Stream Status word 2, bit 0 is a 1. The address is ordered so the first byte received is the lowest positioned byte in the register; for example, an Ethernet MAC address of AA-BB-CC-DD-EE-FF would be stored in UnicastAddr(47:0) as 0xFFEEDDCCBBAA. This word would be 0xFFEE.
Table 3. Receive AXI4-Stream Status Word 2 – APP1
Bits Name Description
31–0 MCAST_ADR_L Multicast Address (31:0): These are the lower 32 bits of the multicast destination address of this frame. This value is only valid AXI4-Stream Status word 2, bit 0 is a 1. The address is ordered so the first byte received is the lowest positioned byte in the register; for example, an Ethernet MAC address of AA-BB-CC-DD-EE-FF would be stored in UnicastAddr(47:0) as 0xFFEEDDCCBBAA. This word would be 0xDDCCBBAA.
Table 4. Receive AXI4-Stream Status Word 3 – APP2
Bits Name Description
31 MII_ALIGN_ERR MII Alignment Error: Used in 10/100 MII mode. Asserted if the previous frame received has an incorrect FCS value and a misalignment occurs when the 4-bit MII data bus is converted to the 8-bit GMII data bus.
30 LEN_FIELD_ERR Length Field Error: Asserted if the LT field contains a length value that does not match the number of Ethernet MAC data bytes received. Also asserted High if the LT field indicates that the frame contains padding but the number of Ethernet MAC data bytes received is not equal to 64 bytes (minimum frame size). This bit is not defined when LT field error-checks are disabled or when received frames are less than the legal minimum length.
29 BAD_OPCODE Bad OP Code: Asserted if the previous frame is error free. Contains the special control frame identifier in the LT field, but contains an OPCODE unsupported by the Ethernet MAC (any OPCODE other than PAUSE).
28 PAUSE_FRAME Pause Frame: Asserted if the previous frame is error-free. Contains the special control frame identifier in the LT field. Contains a destination address matching either the Ethernet MAC control multicast address or the configured source address of the Ethernet MAC. Contains the supported PAUSE OPCODE and is acted upon by the Ethernet MAC.
27 VLAN_FRAME VLAN Frame: Asserted if the previous frame contains a VLAN identifier in the LT field when receiver VLAN operation is enabled.
26 MAX_LEN_ERR Maximum Length Error: Asserted if the previous frame exceeded the specified IEEE Std 802.3-2005 maximum legal length. This is only valid if jumbo frames are disabled.
25 CNTRL_FRAME Control Frame: Asserted if the previous frame contains the special control frame identifier in the LT field.
24–11 LENGTH_BYTES Length Bytes: The length of the previous frame in number of bytes. The count sticks at 16,383 for any jumbo frames larger than this value.
10 MULTIC_FRAME Multicast Frame: Asserted if the previous frame contains a multicast address in the destination address field.
9 BROADC_FRAME Broadcast Frame: Asserted if the previous frame contained the broadcast address in the destination address field.
8 FCS_ERR FCS Error: Asserted if the previous frame received has an incorrect FCS value or the Ethernet MAC detects error codes during frame reception.
7 BAD_FRAME Bad Frame: Asserted if the previous frame received contains errors.
6 GOOD_FRAME Good Frame: Asserted if the previous frame received is error-free.
5–3 RX_CS_STS Receive CSUM Status:
  • 000 = Neither the IP header nor the TCP/UDP checksums were checked.
  • 001 = The IP header checksum was checked and was correct.The TCP/UDP checksum was not checked.

  • 010 = Both the IP header checksum and the TCP checksum were checked and were correct.
  • 011 = Both the IP header checksum and the UDP checksum were checked and were correct.
  • 100 = Reserved
  • 101 = The IP header checksum was checked and was incorrect.The TCP/UDP checksum was not checked.

  • 110 = The IP header checksum was checked and is correct but the TCP checksum was checked and was incorrect.
  • 111 = The IP header checksum was checked and is correct but the UDP checksum was checked and was incorrect.
2 BCAST_FLAG Broadcast Frame Flag: This bit, when 1, indicates that the current frame is a Broadcast frame that has passed the hardware address filtering.
1 IP_MCAST_FLAG IP Multicast Frame Flag: This bit, when 1, indicates that the current frame is a multicast frame that appears to be formed from an IP multicast frame (the first part of the destination address is 01:00:5E) that has passed the hardware multicast address filtering.
0 MAC_MCAST_FLAG MAC Multicast Frame Flag: This bit, when 1, indicates that the current frame is an Ethernet MAC multicast frame that has passed the hardware multicast address filtering.
Table 5. Receive AXI4-Stream Status Word 4 – APP3
Bits Name Description
31–16 T_L_TPID Type Length VLAN TPID: This is the value of the 13th and 12th bytes of the frame (index starts at zero). If the frame is not VLAN type, this is the type/length field. If the frame is VLAN type, this is the value of the VLAN TPID field prior to any stripping, translation or tagging.
15–0 RX_CSRAW Receive Raw Checksum: This value is the raw receive checksum calculated over the entire Ethernet frame starting at byte 14 (index starts at zero). If the receive FCS stripping is not enabled, the FCS is included in the checksum and must be removed by the application.
Table 6. Receive AXI4-Stream Status Word 5 – APP4
Bits Name Description
31–16 VLAN_TAG VLAN Priority CFI and VID: This is the value of the 1fifth and 1fourth bytes of the frame (index starts at zero). If the frame is VLAN type, this is the value of the VLAN priority, CFI, and VID fields prior to any stripping, translation, or tagging. If the frame is not VLAN type, this is the first 2 bytes of the data field.
15–0 RX_BYTECNT Receive Frame Length (Bytes): This value is the number of bytes in the Ethernet frame which is in the receive AXI4-Stream data interface.