When using TCP or UDP Ethernet protocols, data integrity is maintained by calculating and verifying checksum values over the TCP and UDP frame data. Normally this checksum functionality is handled by the protocol stack software which can be relatively slow and uses significant processor power for large frames at high Ethernet data rates. An alternative is to offload some of this transmit checksum generation and receive checksum verification in hardware. This is possible by including checksum offloading in the subsystem using the C_TXCSUM and C_RXCSUM parameters. Including the checksum offload functions are a trade-off between using more FPGA resources and achieving higher Ethernet performance while freeing up processor use for other functions.
When using the TCP/UDP checksum offload function, checksum information is passed between the software and the subsystem, using the AXI4-Stream Control and AXI4-Stream Status interfaces. These interfaces are described in AXI4-Stream Interface and the tables in this section show the checksum offload fields.
The use of the TCP/ UDP checksum offload function requires that the AXI DMA is connected to the AXI Ethernet Subsystem through the AXI4-Stream Control and AXI4-Stream data interfaces. SeeMapping AXI DMA IP Buffer Descriptor Fields to AXI4-Stream Fields for more information.
TX_CSBEGIN is the beginning offset and points to the first byte that needs to be included in the checksum calculation. The first byte is indicated by a value of zero. The beginning position must be 16-bit aligned. With TCP and UDP, set this value to skip over the Ethernet frame header as well as the IP datagram header. This allows the checksum calculation to start in the correct place of the TCP or UDP segment. Operating systems might provide functions to calculate this value as it is normally based on the variable IP datagram header size. In all cases, the TX_CSBEGIN value must be 14 or larger to be valid.
TX_CSINSERT is the offset which points to the location where the checksum value should be written into the TCP or UDP segment header. This value must be 16-bit aligned and cannot be in the first 8 bytes of the frame. Again, operating systems might provide functions to calculate this value as it is normally variable based on the variable IP datagram header size.
TX_CSCNTRL is a 16-bit field; however, only the least significant bit is defined. This bit controls the insertion of the checksum into the frame data. If set to a 1, the checksum value is written into the transmit frame; otherwise the frame is not modified.
TX_CSINIT is a 16-bit seed that can be used to insert the TCP or UDP pseudo header into the checksum calculation. In many cases the protocol stack calculates the pseudo header checksum value and places it in the header checksum field of the transmit frame. In those cases this field should be zeroed.
If the protocol stack does not provide the pseudo header checksum in the header checksum field location of the transmit frame, then that field should be zeroed and the pseudo header checksum value must be calculated and placed in the TX_CSINIT field of the buffer descriptor.
In order for the transmit checksum to be calculated correctly, the transmit Ethernet FCS must not be provided as part of the transmit data and the transmit FCS calculation and insertion must be enabled in the AXI Ethernet Subsystem.
There is a special case for checksums of UDP datagrams as specified in . If the computed checksum is zero, it is transmitted as all ones (the equivalent in ones complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that do not care).
If the frame encapsulates a UDP datagram, and if the resulting checksum is zero, a value of all ones is used. This case does not exist for TCP because a checksum of zero is legal. However, the partial checksum logic does not have any way of knowing if the datagram is TCP or UDP.
For both cases, if the computed checksum is zero, a value of all ones is used instead. If a TCP datagram computed checksum is zero, this can result in the packet being dropped by the receiver.
RX_CSRAW is the raw receive checksum calculated over the entire Ethernet payload. It is calculated starting at byte 14 of the Ethernet frame with the count starting at zero, not one (the byte following the Type/Length field) and continues until the end of the Ethernet frame. If the receive Ethernet FCS stripping is not enabled in the subsystem, the FCS is also included in the checksum. The application is required to calculate the checksum of the fields which should not have been included to subtract them from the RAW checksum value. In most cases, the protocol software that allows receive checksum offloading requires a pass or fail indication. The application has to compare the adjusted raw checksum value with the checksum field of the TCP or UDP header and provide the pass or fail indication.