Precision Timestamp Unit

Versal Adaptive SoC Technical Reference Manual (AM011)

Document ID
AM011
Release Date
2023-10-05
Revision
1.6 English

The timestamp unit (TSU) supports the IEEE Std 1588 for precision time synchronization in local area networks. The TSU works with the exchange of special precision time protocol (PTP) frames. The PTP messages can be transported over IEEE Std 802.3/Ethernet, over Internet Protocol Version 4, or over Internet Protocol Version 6 as described in the annex of IEEE Std P1588.D2.1.

Note: The TSU clock must be active for the GEM controller to operate regardless of whether the TSU is used or not; the TSU clock impacts the transmit scheduler.

TSU Clock Sources

There are several sources for the TSU clock as shown in the GEM I/O Block Diagram. When the TSU clock is sourced from the LPD clock controller, the clock frequency is controlled by the CRL GEM_TSU_REF_CTRL register, see the Reference Clock Frequency Dividers and System-Level Registers sections for more information on the TSU clock.

Synchronization of Source and Destination Clocks

The controller detects when the PTP event messages sync, delay_req, pdelay_req, and pdelay_resp are transmitted and received. Synchronization between clocks is a two stage process.

The offset between the source and destination clocks is corrected by the source sending a sync frame to the destination with a follow-up frame containing the exact time the sync frame was sent. The GEM controller assist modules on the source and destination side detect exactly when the sync frame was sent by the source and received by the destination. The destination then corrects its clock to match the source clock.

The transmission delay between the source and destination is corrected. The destination sends a delay request frame to the source, which sends a delay response frame in reply. The controller assists modules to detect exactly when the delay request frame was sent by the destination and received by the transaction host. The destination then has enough information to adjust its clock to account for delay.

See the IEEE 1588 v1/v2 or 802.1AS standards for more detailed information on how the software calculates the delay based on this information. When GEM is a PTP destination, its timer can be adjusted with this delay. See the Timer Adjustment section below.

Sync and Delay_Req Messages

For TSU assist, it is necessary to timestamp when sync and delay_req messages are sent and received. The timestamp is taken when the message timestamp point passes the clock timestamp point. The message timestamp point is the SFD and the clock timestamp point is the MII. The MAC samples the TSU timer value synchronous to MAC TX/TX clock domains at the MII/GMII boundary.

The MAC inserts the timestamp into the transmitted PTP sync frames (if the one step sync feature is enabled) for capture in the TSU_TIMER_MSB_SEC, TSU_TIMER_NSEC, TSU_TIME_SEC registers, or to pass to the DMA to insert into TX or RX descriptors. For each of these, the SOF event, which is captured in the tx_clk and rx_clk domains, respectively, is synchronized to the tsu_clk domain, and the resulting signal is used to sample the TSU count value. This value is kept stable for an entire frame, or specifically for at least 64 TX/RX clock cycles, because the minimum frame size in Ethernet is 64 bytes and worst case is a transfer rate of 1 byte per cycle. It is used as the source for all the various components within the GEM that require the timestamp value. The IEEE Std 1588 specification refers to sync and delay_req messages as event messages, as these require timestamping. Follow up, delay response, and management messages do not require timestamping and are referred to as general messages.

Peer Delay Request and Response Messages

The IEEE Std 1588 version 2 defines two new PTP event messages that replace the delay request/response messages. These are the peer delay request (pdelay_Req) and peer delay response (pdelay_Resp) messages. These messages are used to calculate the delay on a link. Nodes at both ends of a link send both types of frames (regardless of the clock source). The pdelay_resp message contains the time where a pdelay_req was received and is itself an event message. The time at which a pdelay_resp message is received is returned in a pdelay_resp_follow_up message.

PTP Event Message Encapsulation

The controller recognizes four different encapsulations for PTP event messages:

  • IEEE Std 1588 version 1 (UDP/IPv4 multicast)
  • IEEE Std 1588 version 2 (UDP/IPv4 multicast)
  • IEEE Std 1588 version 2 (UDP/IPv6 multicast)
  • IEEE Std 1588 version 2 (Ethernet multicast)
Note: Only multicast packets are supported.

Timer Adjustment

The TSU consists of a timer with seconds + nanoseconds + sub nanoseconds registers, increment and adjust registers, and these are accessible through the APB programming interface. The initial value of the timer is written through the tsu_timer_msb_sec, tsu_timer_sec, and tsu_timer_nsec registers. The amount the timer increments by each clock cycle is set by the tsu_timer_incr and tsu_timer_incr_sub_nsec registers. The timer can be adjusted by adding or subtracting an integral number of nanoseconds in a one-off write to the tsu_timer_adjust register. Alternatively, the tsu_timer_incr and tsu_timer_incr_sub_nsec can also be adjusted to tune a destination's timer minutely based on the delay. See the register descriptions for more information.

PTP Event Packet Timestamping

The TSU consists of a timer and registers to capture the time at which PTP event frames cross the message timestamp point. These are accessible memory-mapped through the APB programming interface. An interrupt is issued when a capture register is updated.

The MAC provides timestamp registers that capture the departure time (for transmit) or arrival time (for receive) of PTP event packets (sync and delay request), and peer event packets (peer delay request or peer delay response). Interrupts are optionally generated upon timestamp capture.

Note: The UDP v4 is not check summed again after the timestamp is inserted by the hardware into the PTP one-step sync frame. Consequently, PTP one-step sync is only supported with L2 frames.