www.ti.com
EMAC Functional Architecture
2.10.5Host Free Buffer Tracking
The host must track free buffers for each enabled channel (including unicast, multicast, broadcast, and promiscuous) if receive QOS or receive flow control is used. Disabled channel free buffer values are don’t cares. During initialization, the host should write the number of free buffers for each enabled channel to the appropriate RXnFREEBUFFER register. The EMAC decrements the appropriate channel’s free buffer value for each buffer used. When the host reclaims the frame buffers, the host should write the channel free buffer register with the number of reclaimed buffers (write to increment). There are a maximum of 65 535 free buffers available. The RXnFREEBUFFER registers only need to be updated by the host if receive QOS or flow control is used.
2.10.6Receive Channel Teardown
The host commands a receive channel teardown by writing the channel number to the RXTEARDOWN register. When a teardown command is issued to an enabled receive channel, the following occurs:
∙Any current frame in reception completes normally.
∙The TDOWNCMPLT flag is set in the next buffer descriptor in the chain, if there is one.
∙The channel head descriptor pointer is cleared.
∙A receive interrupt for the channel is issued to the host.
∙The corresponding RXnCP register contains the value FFFF FFFCh.
∙The host should acknowledge a teardown interrupt with an FFFF FFFCh acknowledge value.
Channel teardown may be commanded on any channel at any time. The host is informed of the teardown completion by the set teardown complete buffer descriptor bit. The EMAC does not clear any channel enables due to a teardown command. A teardown command to an inactive channel issues an interrupt that software should acknowledge with an FFFF FFFCh acknowledge value to RXnCP (note that there is no buffer descriptor in this case). Software may read RXnCP to determine if the interrupt was due to a commanded teardown. The read value is FFFF FFFCh if the interrupt was due to a teardown command.
2.10.7Receive Frame Classification
Received frames are proper, or good, frames if they are between 64 and RXMAXLEN in length (inclusive) and contain no code, align, or CRC errors.
Received frames are long frames if their frame count exceeds the value in the RXMAXLEN register. The RXMAXLEN register default reset value is 5EEh (1518 in decimal). Long received frames are either oversized or jabber frames. Long frames with no errors are oversized frames; long frames with CRC, code, or alignment errors are jabber frames.
Received frames are short frames if their frame count is less than 64 bytes. Short frames that address match and contain no errors are undersized frames; short frames with CRC, code, or alignment errors are fragment frames. If the frame length is less than or equal to 20, then the frame CRC is passed regardless of whether the RXPASSCRC bit is set or cleared in the RXMBPENABLE register.
A received long packet always contains RXMAXLEN number of bytes transferred to memory (if the RXCEFEN bit is set in RXMBPENABLE) regardless of the value of the RXPASSCRC bit. Following is an example with RXMAXLEN set to 1518:
∙If the frame length is 1518, then the packet is not a long packet and there are 1514 or 1518 bytes transferred to memory depending on the value of the RXPASSCRC bit.
∙If the frame length is 1519, there are 1518 bytes transferred to memory regardless of the RXPASSCRC bit value. The last three bytes are the first three CRC bytes.
∙If the frame length is 1520, there are 1518 bytes transferred to memory regardless of the RXPASSCRC bit value. The last two bytes are the first two CRC bytes.
∙If the frame length is 1521, there are 1518 bytes transferred to memory regardless of the RXPASSCRC bit value. The last byte is the first CRC byte.
∙If the frame length is 1522, there are 1518 bytes transferred to memory. The last byte is the last data byte.
52 | Ethernet Media Access Controller (EMAC)/Management Data Input/Output (MDIO) | SPRU975B |
