Hard Processor System Technical Reference Manual: Agilex™ 5 SoCs

ID 814346
Date 4/01/2024
Public
Document Table of Contents

5.1.6.9.3. Clock Types

The EMAC supports the following clock types defined in the IEEE 1588-2008:
  • Ordinary clock
  • Boundary clock
  • End-to-End transparent clock
  • Peer-to-Peer transparent clock

Ordinary clock

The ordinary clock in a domain supports a single copy of the protocol. The ordinary clock has a single PTP state and a single physical port. In typical industrial automation applications, an ordinary clock is associated with an application device such as a sensor or an actuator. In telecom applications, the ordinary clock can be associated with a timing demarcation device.

The ordinary clock can be a grandmaster or a receiver clock. It supports the following features:

  • Sends and receives PTP messages. The timestamp snapshot can be controlled as described in MAC_Timestamp_Control register description.
  • Maintains the data sets such as timestamp values.
The following table shows the messages for which you can take the timestamp snapshot on the receive side for time transmitter and time receiver nodes.
Table 155.  Ordinary Clock: PTP Messages for Snapshot
Time Transmitter Time Receiver
Delay_Req SYNC

For an ordinary clock, you can take the snapshot by setting the TSVER2ENA bit and selecting the snapshot mode in the MAC_Timestamp_Control register.

Boundary Clock

The boundary clock typically has several physical ports communicating with the network. The messages related to synchronization, host and subordinate hierarchy, and signaling terminate in the protocol engine of the boundary clock and such messages are not forwarded. The PTP message type status given by the MAC helps you to identify the type of message and take appropriate action.

The boundary clock is similar to the ordinary clock except for the following features:
  • The clock data sets are common to all ports of the boundary clock.
  • The local clock is common to all ports of the boundary clock.

End-to-End Transparent Clock

The end-to-end transparent clock supports the end-to-end delay measurement mechanism between the subordinate clocks and the source clock. The end-to-end transparent clock forwards all messages like normal bridge, router, or repeater. The residence time of a PTP packet is the time taken by the PTP packet from the ingress port to the egress port.

The residence time of a SYNC packet inside the end-to-end transparent clock is updated in the correction field of the associated Follow_Up PTP packet before it is transmitted. Similarly, the residence time of a Delay_Req packet, inside the end-to-end transparent clock, is updated in the correction field of the associated Delay_Resp PTP packet before it is transmitted. Therefore, the snapshot needs to be taken at both ingress and egress ports only for the messages mentioned in the table below. You can take the snapshot by setting the SNAPTYPSEL bits to 10 in the MAC_Timestamp_Control register.

Table 156.  End-to-End Transparent Clock: PTP Messages for Snapshot
PTP Messages
SYNC
Delay_Req

Peer-to-Peer Transparent Clock

The peer-to-peer transparent clock differs from the end-to-end transparent clock in the way it corrects and handles the PTP timing messages. In all other aspects, it is identical to the end-to-end transparent clock. In the peer-to-peer transparent clock, the computation of the link delay is based on an exchange of Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages with the link peer. The residence time of the Pdelay_Req and the associated Pdelay_Resp packets is added and inserted into the correction field of the associated Pdely_Resp_Followup packet. Therefore, support for taking snapshot for the event messages related to Pdelay is added as shown in the table below.

Table 157.  Peer-to-Peer Transparent Clock: PTP Messages for Snapshot
PTP Messages
SYNC
Pdelay_Req
Pdelay_Resp