Datasheet

IEEE 802.1AS is a subset of IEEE 1588. One difference is that IEEE 802.1AS uses the Ethernet multicast
address 0180C200000E for sync frame recognition whereas IEEE 1588 does not. GMAC is designed to
recognize sync frames with both IEEE 802.1AS and IEEE 1588 addresses and so can support both 1588
and 802.1AS frame recognition simultaneously.
Synchronization between master and slave clocks is a two stage process.
First, the offset between the master and slave clocks is corrected by the master sending a sync frame to
the slave with a follow up frame containing the exact time the sync frame was sent. Hardware assist
modules at the master and slave side detect exactly when the sync frame was sent by the master and
received by the slave. The slave then corrects its clock to match the master clock.
Second, the transmission delay between the master and slave is corrected. The slave sends a delay
request frame to the master which sends a delay response frame in reply. Hardware assist modules at
the master and slave side detect exactly when the delay request frame was sent by the slave and
received by the master. The slave will now have enough information to adjust its clock to account for
delay. For example, if the slave was assuming zero delay, the actual delay will be half the difference
between the transmit and receive time of the delay request frame (assuming equal transmit and receive
times) because the slave clock will be lagging the master clock by the delay time already.
The time-stamp is taken when the message time-stamp point passes the clock time-stamp point. This can
generate an interrupt if enabled (IER). However, MAC Filtering configuration is needed to actually ‘copy’
the message to memory. For Ethernet, the message time-stamp point is the SFD and the clock time-
stamp point is the MII interface. (The IEEE 1588 specification refers to sync and delay_req messages as
event messages as these require time-stamping. These events are captured in the registers TSSx, EFTx
and EFRx, respectively. Follow up, delay response and management messages do not require time-
stamping and are referred to as general messages.)
1588 version 2 defines two additional PTP event messages. These are the peer delay request
(Pdelay_Req) and peer delay response (Pdelay_Resp) messages. These events are captured in the
registers PEFTx and PEFRx, respectively. 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 whether they contain a master or
slave clock). The Pdelay_Resp message contains the time at which 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.
1588 version 2 introduces transparent clocks of which there are two kinds, peer-to-peer (P2P) and end-
to-end (E2E). Transparent clocks measure the transit time of event messages through a bridge and
amend a correction field within the message to allow for the transit time. P2P transparent clocks
additionally correct for the delay in the receive path of the link using the information gathered from the
peer delay frames. With P2P transparent clocks delay_req messages are not used to measure link delay.
This simplifies the protocol and makes larger systems more stable.
The GMAC recognizes four different encapsulations for PTP event messages:
1. 1588 version 1 (UDP/IPv4 multicast)
2. 1588 version 2 (UDP/IPv4 multicast)
3. 1588 version 2 (UDP/IPv6 multicast)
4. 1588 version 2 (Ethernet multicast)
Table 24-5. Example of Sync Frame in 1588 Version 1 Format
Frame Segment Value
Preamble/SFD 55555555555555D5
SAM D5x/E5x Family Data Sheet
GMAC - Ethernet MAC
© 2019 Microchip Technology Inc.
Datasheet
DS60001507E-page 498