31.6.3.3 Receive AXI Buffers
Received frames, optionally including FCS, are written to receive AXI buffers stored in memory. The receive buffer depth is programmable in the range of 64 Bytes to 16 KBytes through the DMA Configuration register (DCFGR), with the default being 128 Bytes.
The start location for each receive AXI buffer is stored in memory in a list of receive buffer descriptors at an address location pointed to by the receive buffer queue pointer. The base address for the receive buffer queue pointer is configured in software using the Receive Buffer Queue Base Address register (RBQB).
Each list entry consists of two words. The first is the address of the receive AXI buffer and the second the receive status.
If the length of a receive frame exceeds the AXI buffer length, the status word for the used buffer is written with zeroes except for the “Start of Frame” bit, which is always set for the first buffer in a frame.
Bit zero of the address field is written to 1 to show that the buffer has been used. The receive buffer manager then reads the location of the next receive AXI buffer and fills that with the next part of the received frame data. AXI buffers are filled until the frame is complete and the final buffer descriptor status word contains the complete frame status. See the following table for details of the receive buffer descriptor list.
Bit | Function |
---|---|
Word 0 | |
31:2 | Address of beginning of buffer |
1 | Wrap—marks last descriptor in receive buffer descriptor list. |
0 | Ownership—needs to be zero for the ETH to write data to the receive
buffer. The ETH sets this to one once it has successfully written a
frame to memory. Software has to clear this bit before the buffer can be used again. |
Word 1 | |
31 | Global all ones broadcast address detected |
30 | Multicast hash match |
29 | Unicast hash match |
28 | – |
27 | Specific Address Register match found, bit 25 and bit 26 indicate which Specific Address Register causes the match. |
26:25 | Specific Address Register match. Encoded as follows: 00: Specific Address Register 1 match 01: Specific Address Register 2 match 10: Specific Address Register 3 match 11: Specific Address Register 4 match If more than one specific address is matched only one is indicated with priority 4 down to 1. |
24 | This
bit has a different meaning depending on whether RX checksum offloading
is enabled. With RX checksum offloading disabled: (bit 24 clear in Network Configuration Register) Type ID register match found, bit 22 and bit 23 indicate which type ID register causes the match. With RX checksum offloading enabled: (bit 24 set in Network Configuration Register) 0: The frame was not SNAP encoded and/or had a VLAN tag with the Canonical Format Indicator (CFI) bit set. 1: The frame was SNAP encoded and had either no VLAN tag or a VLAN tag with the CFI bit not set. |
23:22 | This
bit has a different meaning depending on whether RX checksum offloading
is enabled. With RX checksum offloading disabled: (bit 24 clear in Network Configuration) Type ID register match. Encoded as follows: 00: Type ID register 1 match 01: Type ID register 2 match 10: Type ID register 3 match 11: Type ID register 4 match If more than one Type ID is matched only one is indicated with priority 4 down to 1. With RX checksum offloading enabled: (bit 24 set in Network Configuration Register) 00: Neither the IP header checksum nor the TCP/UDP checksum was checked. 01: The IP header checksum was checked and was correct. Neither the TCP nor UDP checksum was checked. 10: Both the IP header and TCP checksum were checked and were correct. 11: Both the IP header and UDP checksum were checked and were correct. |
21 | VLAN tag detected—type ID of 0x8100. For packets incorporating the stacked VLAN processing feature, this bit will be set if the second VLAN tag has a type ID of 0x8100 |
20 | Priority tag detected—type ID of 0x8100 and null VLAN identifier. For packets incorporating the stacked VLAN processing feature, this bit will be set if the second VLAN tag has a type ID of 0x8100 and a null VLAN identifier. |
19:17 | VLAN priority—only valid if bit 21 is set. |
16 | Canonical format indicator (CFI) bit (only valid if bit 21 is set). |
15 | End of frame—when set the buffer contains the end of a frame. If end of frame is not set, then the only valid status bit is start of frame (bit 14). |
14 | Start of frame—when set the buffer contains the start of a frame. If both bits 15 and 14 are set, the buffer contains a whole frame. |
13 | This
bit has a different meaning depending on whether jumbo frames and ignore
FCS modes are enabled. If neither mode is enabled this bit will be
zero. With jumbo frame mode enabled: (bit 3 set in Network Configuration Register) Additional bit for length of frame (bit[13]), that is concatenated with bits[12:0] With ignore FCS mode enabled and jumbo frames disabled: (bit 26 set in Network Configuration Register and bit 3 clear in Network Configuration Register) This indicates per frame FCS status as follows: 0: Frame had good FCS 1: Frame had bad FCS, but was copied to memory as ignore FCS enabled. |
12:0 | These
bits represent the length of the received frame which may or may not
include FCS depending on whether FCS discard mode is enabled. With FCS discard mode disabled: (bit 17 clear in Network Configuration Register) Least significant 12 bits for length of frame including FCS. If jumbo frames are enabled, these 12 bits are concatenated with bit[13] of the descriptor above. With FCS discard mode enabled: (bit 17 set in Network Configuration Register) Least significant 12 bits for length of frame excluding FCS. If jumbo frames are enabled, these 12 bits are concatenated with bit[13] of the descriptor above. |
Each receive AXI buffer start location is a word address. The start of the first AXI buffer in a frame can be offset by up to three Bytes, depending on the value written to bits 14 and 15 of the Network Configuration register (NCFGR). If the start location of the AXI buffer is offset, the available length of the first AXI buffer is reduced by the corresponding number of Bytes.
To receive frames, the AXI buffer descriptors must be initialized by writing an appropriate address to bits 31:2 in the first word of each list entry. Bit 0 must be written with zero. Bit 1 is the wrap bit and indicates the last entry in the buffer descriptor list.
The start location of the receive buffer descriptor list must be written with the receive buffer queue base address before reception is enabled (receive enable in the Network Control register NCR). Once reception is enabled, any writes to the Receive Buffer Queue Base Address register (RBQB) are ignored. When read, it will return the current pointer position in the descriptor list, though this is only valid and stable when receive is disabled.
If the filter block indicates that a frame should be copied to memory, the receive data DMA operation starts writing data into the receive buffer. If an error occurs, the buffer is recovered.
An internal counter within the ETH represents the receive buffer queue pointer and it is not visible through the CPU interface. The receive buffer queue pointer increments by two words after each buffer has been used. It re-initializes to the receive buffer queue base address if any descriptor has its wrap bit set.
As receive AXI buffers are used, the receive AXI buffer manager sets bit zero of the first word of the descriptor to logic one indicating the AXI buffer has been used.
Software should search through the “used” bits in the AXI buffer descriptors to find out how many frames have been received, checking the start of frame and end of frame bits.
When the DMA is configured in the packet buffer Partial Store And Forward mode, received frames are written out to the AXI buffers as soon as enough frame data exists in the packet buffer. For both cases, this may mean several full AXI buffers are used before some error conditions can be detected. If a receive error is detected the receive buffer currently being written will be recovered. Previous buffers will not be recovered. As an example, when receiving frames with cyclic redundancy check (CRC) errors or excessive length, it is possible that a frame fragment might be stored in a sequence of AXI receive buffers. Software can detect this by looking for start of frame bit set in a buffer following a buffer with no end of frame bit set.
To function properly, a 10/100 Ethernet system should have no excessive length frames or frames greater than 128 Bytes with CRC errors. Collision fragments will be less than 128 Bytes long, therefore it will be a rare occurrence to find a frame fragment in a receive AXI buffer, when using the default value of 128 Bytes for the receive buffers size.
When in packet buffer full store and forward mode, only good received frames are written out of the DMA, so no fragments will exist in the AXI buffers due to MAC receiver errors. There is still the possibility of fragments due to DMA errors, for example used bit read on the second buffer of a multi-buffer frame.
If bit zero of the receive buffer descriptor is already set when the receive buffer manager reads the location of the receive AXI buffer, the buffer has been already used and cannot be used again until software has processed the frame and cleared bit zero. In this case, the “buffer not available” bit in the receive status register is set and an interrupt triggered. The receive resource error statistics register is also incremented.
When the DMA is configured in the packet buffer full store and forward mode, a receive overrun condition occurs when the receive SRAM-based packet buffer is full, or because HRESP was not OK. In all other modes, a receive overrun condition occurs when either the AXI bus was not granted quickly enough, or because HRESP was not OK, or because a new frame has been detected by the receive block, but the status update or write back for the previous frame has not yet finished. For a receive overrun condition, the receive overrun interrupt is asserted and the buffer currently being written is recovered. The next frame that is received whose address is recognized reuses the buffer.
In any packet buffer mode, writing a '1' to the Flush Next Package bit in the NCR register (NCR.FNP) will force a packet from the external SRAM-based receive packet buffer to be flushed. This feature is only acted upon when the RX DMA is not currently writing packet data out to AXI, i.e., it is in an IDLE state. If the RX DMA is active, NCR.FNP=1 is ignored.