The ingress logic does not parse the ingress packets to search for 1588 (PTP) frames. Instead, it takes a timestamp for every received frame and outputs this value to the user logic. The feature is always enabled, but the timestamp output can be ignored if you do not require this function.
Timestamps are filtered after the PCS decoder to retain only those timestamps corresponding to an Start of Packet (SoP). These 80-bit timestamps are output on the system side. The timestamp is valid during the SoP cycle.
The accuracy of the 1588 timestamping of Ethernet frames is dependent on several factors, some of which are outside of the scope of this IP core:
timestamp error = (10/25G IP Core 1588 timestamp error) + (external timestamp sampling error) + (error due to system clock jitter, transceiver uncertainty, other factors)
10/25G IP Core 1588 timestamp error:
- Ordinary Clock mode: +/- 1 ns (due to granularity of ToD format)
- Transparent Clock mode: +/- 1 SerDes clock bit time
Factors that influence timestamp accuracy:
- This IP core requires the user to sample the system timer input and to retime it to the specified clock domain (TX SerDes or RX SerDes). A simple sampling circuit will introduce a +/- 1 SerDes clock error. Greater accuracy can be achieved if the customer implements a custom synchronization design.
- No compensation for external delays (e.g., transceivers) is done inside the IP core. These delays can be determined and added as an offset.
- For IP cores with RSFEC, the timing plane is assumed to be outside the RSFEC, and so any variation due to transcoding and checksum insertion on TX is removed by the inverse function on RX. Refer to 802.3-2018 Clause 90.7.
- For MAC+PCS IP cores with RSFEC, the core compensates for the effects of rate adaptation due to AM insertion.
- 64b IP cores compensate for half block starts (64B/66B blocks with S4).
GT Transceiver Latency Adjustments
The latency through the GT transceivers can caused by static and dynamic delay.
- Static Delay
-
The static delay can be calculated using the information available for transceivers on Support. For example, latency estimates for the individual modules in UltraScale+ GTY Transceiver is mentioned in article 69011. A prerequisite to calculate latency is knowing the GT Transceiver internal modules that are used for your configuration. As the configuration of the transceiver might change based on the modes of the Ethernet IP, the other recommended approach is to use simulation to calculate latency.
In an example design simulations, you can observe timestamps at the points mentioned in the following diagram, where:- TA
- Timestamp at the input of GT Transceiver on transmit direction.
- TB
- Timestamp at the output of GT Transceiver on transmit direction.
- TC
- Timestamp at the input of GT Transceiver on receive direction
- TD
- Timestamp at the output of GT Transceiver on receive direction
- Dynamic Delay
-
The dynamic delay component in the GT transceivers is because of the use of elastic buffers for 64B/66B gearboxing. The delay in terms of UI can be calculated by reading the TXGBOX_FIFO_LATENCY and RXGBOX_FIFO_LATENCY DRP registers in the GT Transceivers and following the methods available on Support. The dynamic value changes for each system run and must be added to the static delay to adjust the total delay for transceivers.