Datasheet

• The frame has an ARP operation field of 0x0001 (bytes 21 and 22)
•
The least significant 16 bits of the frame's ARP target protocol address (bytes 41 and 42) match the value
programmed in bits[15:0] of the Wake on LAN register
The decoding of the ARP fields adjusts automatically if a VLAN tag is detected within the frame. The reserved value
of 0x0000 for the Wake on LAN target address value will not cause an ARP request event, even if matched by the
frame.
A specific address 1 filter match event will occur if all of the following are true:
• Specific address 1 events are enabled through bit 18 of the Wake on LAN register
• The frame's destination address matches the value programmed in the Specific Address 1 registers
A multicast filter match event will occur if all of the following are true:
• Multicast hash events are enabled through bit 19 of the Wake on LAN register
• Multicast hash filtering is enabled through bit 6 of the Network Configuration register
• The frame destination address matches against the multicast hash filter
• The frame destination address is not a broadcast
38.6.14 IEEE 1588 Support
IEEE 1588 is a standard for precision time synchronization in local area networks. It works with the exchange of
special Precision Time Protocol (PTP) frames. The PTP messages can be transported over IEEE 802.3/Ethernet,
over Internet Protocol Version 4 or over Internet Protocol Version 6 as described in the annex of IEEE P1588.D2.1.
The GMAC indicates the message time-stamp point (asserted on the start packet delimiter and de-asserted at end of
frame) for all frames and the passage of PTP event frames (asserted when a PTP event frame is detected and de-
asserted at end of frame).
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 (GMAC_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 GMAC_EFTx and GMAC_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 GMAC_PEFTx and
GMAC_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.
SAM E70/S70/V70/V71 Family
GMAC - Ethernet MAC
© 2019 Microchip T
echnology Inc.
Datasheet
DS60001527D-page 592