As seen in the preceding figure, timestamping logic exists in two locations depending on whether 1-step or 2-step operation is desired. 1-step operation requires the user datagram protocol (UDP) checksum and FCS updates and therefore the FCS core logic is used.
The TS references are defined as follows:
- TS1
- The output timestamp signal when a 1-step operation is selected.
- TS2
- The output timestamp signal when a 2-step operation is selected.
- TS2'
- The plane to which both timestamps are corrected.
TS2 always has a correction applied so that it
is referenced to the TS2' plane. TS1 might or might not have the TS2' correction
applied, depending on the value of the signal ctl_tx_ptp_latency_adjust[10:0].
Based on rate and clock mode (Ordinary or
Transparent), the suggested default values of the ctl_tx_ptp_latency_adjust[10:0] signal are as follows:
- 25G Ordinary Clock = 370
- 25G Transparent Clock = 449
- 10G Ordinary Clock = 925
- 10G Transparent Clock = 1132
On the transmit side, a command field is provided by the client to the subsystem in parallel with the frame sent for transmission. This indicates, on a frame-by-frame basis, the 1588 function to perform (either no-operation, 1-step, or 2-step) and also indicates, for 1-step frames, whether there is a UDP checksum field to update.
If using the ToD format, then for both 1-step and 2-step operation, the full captured 80-bit ToD timestamp is returned to the client logic using the additional ports defined in Port Descriptions.
If using the Correction Field format, then for both 1-step and 2-step operation, the full captured 64-bit timestamp is returned to the client logic using the additional ports defined in Port Descriptions (with the upper bits of data set to zero as defined in the table).
If using the ToD format, then for 1-step operation, the full captured 80-bit ToD timestamp is inserted into the frame. If using the Correction Field format, then for 1-step operation, the captured 64-bit timestamp is summed with the existing Correction Field contained within the frame and the summed result is overwritten into the original Correction Field of the frame. Supported frame types for 1-step timestamping are:
- Raw Ethernet
- UDP/IPv4
- UDP/IPv6 For 1-step UDP frame types, the UDP checksum is updated in accordance with IETF RFC 1624. For all 1-step frames, the Ethernet Frame Check Sequence (FCS) field is calculated after all frame modifications have been completed. For 2-step transmit operation, all Precision Time Protocol (PTP) frame types are supported.
Frame-by-Frame Timestamping Operation
The operational mode of the egress timestamping function is determined by the settings on the 1588 command port. The information contained within the command port indicates one of the following:
- No operation: the frame is not a PTP frame and no timestamp action should be taken.
- Two-step operation is required and a tag value (user-sequence ID) is provided as part of the command field; the frame should be timestamped, and the timestamp made available to the client logic, along with the provided tag value for the frame. The additional MAC transmitter ports provide this function.
- 1-step operation is required.
- For the ToD timer and timestamp format a timestamp offset value is provided as part of the command port; the frame should be timestamped, and the timestamp should be inserted into the frame at the provided offset (number of bytes) into the frame.
- For the Correction Field format, a Correction Field offset value is provided as part of the command port; the frame should be timestamped, and the captured 64-bit Timestamp is summed with the existing Correction Field contained within the frame and the summed result is overwritten into original Correction Field of the frame. For 1-step operation, following the frame modification, the cyclic redundancy check (CRC) value of the frame should also be updated/recalculated. For UDP IPv4 and IPv6 PTP formatted frames, the checksum value in the header of the frame needs to be updated/recalculated.
- For 1-step UDP frame types, the UDP
checksum is updated in accordance with IETF RFC 1624.
- If using the ToD format, in order for this update function to work correctly, the original checksum value for the frame sent for transmission should be calculated using a zero value for the timestamp data. This particular restriction does not apply when using the Correction Field format.
- If using the Correction Field format, a different restriction does apply; the separation between the UDP Checksum field and the Correction Field within the 1588 PTP frame header is a fixed interval of bytes, supporting the 1588 PTP frame definition. This is a requirement to minimize the latency through the MAC since both the checksum and the correction field must both be fully contained in the MAC pipeline in order for the checksum to be correctly updated. This particular restriction does not apply to the ToD format because the original timestamp data is calculated as a zero value; consequently the checksum and timestamp position can be independently located within the frame.