Datasheet
24.3.9.3 CRC Replacement
The software can use the CRC replacement feature to instruct the MAC to replace the FCS field in
the transmit frame with the CRC computed by the MAC. This feature works on a per-frame basis.
The CRC replacement control field in the Transmit Descriptor Word 0 (TDES0) can be programmed
to enable this for a frame. This feature is valid only when the Disable CRC control (Bit 27 of TDES0)
is enabled. If SA or VLAN insertion control is enabled, the MAC appends or replaces the FCS field
with the computed CRC when Disable CRC Control is enabled or disabled, respectively.
Table 24-32. CRC Replacement Based on Bit 27 and Bit 24 of TDES0
DescriptionBit 24 (CRCR)Bit 27 (DC)
Append CRC
When DC= 0, the MAC appends the computed CRC irrespective of the
CRCR setting.
X0
Replace CRC11
No operation (user has appended CRC)01
24.3.10 Checksum Offload Engine
Communication protocols such as TCP and UDP implement checksum fields, which help determine
the integrity of data transmitted over a network. Because the most widespread use of Ethernet is
to encapsulate TCP and UDP over IP datagrams, the MAC Checksum Offload Engine (COE) supports
checksum calculation and insertion in the transmit path, and error detection in the receive path.
24.3.10.1 Transmit Checksum Offload Engine
The checksum for TCP, UDP, or ICMP is calculated over a complete frame, and then inserted into
its corresponding header field. Because of this requirement this function is enabled only when the
TX FIFO is configured for the store-and-forward mode (the TSF bit is set in the EMACDMAOPMODE
register).
Note: The TX FIFO must be deep enough to store a complete frame before the frame is transferred
to the MAC when the checksum offload is being used. If space is not available to accept
the programmed burst length of data, the TX/RX Controller starts reading to avoid deadlock.
When reading starts, the checksum offload fails and the consequently all succeeding frames
may be corrupted because of improper recovery. Therefore, checksum insertion must only
be enabled in frames that are less than [2048-((PBL+3)*4)] bytes in size, where PBL is the
Programmable Burst Length field in the EMACDMABUSMOD register.
24.3.10.2 IP Header Checksum Engine
In IPv4 datagrams, the integrity of the header fields is indicated by the 16-bit Header Checksum
field (the eleventh and twelfth bytes of the IPv4 datagram). The checksum offload engine detects
an IPv4 datagram when the Ethernet frame's Type field has the value 0x0800 and the IP datagram's
Version field has the value 0x4. The input frame's checksum field is ignored during calculation and
replaced with the calculated value. IPv6 headers do not have a checksum field. Therefore, the
checksum offload does not modify the IPv6 header fields.
The result of this IP header checksum calculation is indicated by the IP Header Error status bit in
the Transmit status (Bit 16 in TDES0). This status bit is set whenever the values of the Ethernet
Type field and the IP header's Version field are not consistent, or when the Ethernet frame does
not have enough data, as indicated by the IP header Length field. In other words, this bit is set when
an IP header error is asserted under the following circumstances:
December 13, 20131642
Texas Instruments-Advance Information
Ethernet Controller