Upload
others
View
21
Download
1
Embed Size (px)
Citation preview
1588 System Level Overview
IEEE 1588 v2 (IEEE Standards Association, 2008) is standard that defines a precision timing protocol
(PTP) used in packet networking to precisely synchronize the real time-of-day (ToD) clocks and
frequency sources in a distributed system to a master ToD clock, which in turn is synchronized to a
global clock source. Traditionally, better synchronization has been achieved in TDM (Time Division
Multiplexing) networks due to their control on timing with their precise frequency and clocking
hierarchy. However, with the advent of 1588 v2, synchronization to the tune of nanoseconds has also
become a possibility within packet networks, enabling low-cost phase and frequency synchronization in
applications such as wireless, mobile backhaul, wireline and industrial instrumentation potentially
replacing the costlier TDM networks used for similar purposes.
The following diagram illustrates the 1588 solution at a system level and positioning of Altera’s Ethernet
MAC and PCS+PMA with 1588 hardware IP (Low Latency 10G, Triple Speed Ethernet), capable of time-
stamping PTP packets with very high accuracy down to a few nanoseconds. Though the complete 1588
solution can be implemented in software, the hardware assisted 1588 solution achieves very high
accuracy needed in some applications such as mobile backhaul. The 10M-10G Ethernet low-latency MAC
and PCS+PMA (Phy) 1588 solution from Altera supports a static error of +/- 3ns across the throughputs
of 10Gbps, 1Gbps & 100Mbps with the random error of +/- 1ns, +/- 2ns, and +/- 5ns from the Phy for the
throughputs of 10Gbps, 1Gbps & 100Mbps respectively.
Ethernet Driver Software with 1588 PTP API
PTP Stack
L1/Physical Layer
L2-L5 Parsing/TimeStamping
Firmware
Software supporting OC, BC, TC
1588 Hardware
Ethernet MACAltera 1588 IP
PTP Packet Parser and User Logic
High Quality APLL
PCS+PMA (Phy)
Altera FPGA
External PMD
Timing Servo Control SoftwareMaintains & Controls local ToD
& clock source
CPU Subsystem
Ethernet Switch (Optional)
Figure 1: A typical 1588 v2 system solution
Figure 2 below (same as Figure 5 that explains functional flow), depicts system level block diagram
involving Altera Ethernet+1588 IP. Some of the major building blocks are described below.
CPU
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
Packet Packet
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacketPacket
FPGA-OC Master
CPU
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
PacketPacket
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacket Packet
FPGA-OC Slave
Cable
Altera 1588 IPAltera 1588 IP
T1
T2
T3
T4
ToD ToD
Figure 2: An example of Altera 1588 hardware IP in OC-master and OC-slave in a 1588 system
ToD: The ToD (Time of Day) module is a counter responsible for generating the current real time of day
locally. CPU and Timing Servo Control Software update the ToD counter, typically via fine-grain
adjustments in terms of phase and frequency corrections through relevant registers detailed in the user
guides. The ToD can provide both a 64-bit time useful for the correction field used in TC and a full 96-bit
time useful for ordinary and boundary clocks.
MAC 1588 block: The transmit-subblock adds the Phy transmit path delay to the timestamp, places the
net timestamp value at the byte offset given by the packet parser and recalculates the CRC for the
packet before the packet is sent to the Phy. The receive-subblock timestamps the incoming packet,
subtracts Phy receive path delay from the timestamp and sends the net timestamp value to the user
logic. For more details, the user guides (Low Latency 10G, Triple Speed Ethernet), may be referred to.
Packet Parser: In the transmit direction, the Packet Parser is used to determine the type of packet being
sent, determine the appropriate location for the time stamp field and provide this information via a
command to the Ethernet MAC transmitter for further processing. In the receive direction, this block
checks whether the local timestamp of the packet received on the Ethernet MAC receiver is indeed for a
PTP packet. As an example, the 1588 PTP packet’s timestamp field location relative to the start of packet
(SOP) is different for a PTP packet encapsulated over Ethernet versus for a PTP packet encapsulated over
UDP over IPv6 over Ethernet.
CPU: The CPU is responsible for running timer servo control software, PTP stack, Ethernet driver
software and appropriate control logic and filtering to update the ToD in addition to the 1588 network
management software.
FIFO or CAM: A CAM (content addressable memory) or a FIFO is used to associate a PTP event with a
timestamp for later retrieval .For example, in a two-step operation, the CAM will be used to remember
the time that a packet has gone out so that it can be looked up and retrieved at the time that the CPU is
ready to send out the follow-up response. Though the 1588 protocol is a slow protocol with 128 frames
per second, the 1588 packets can be bursty in nature or many contexts such as simultaneous flows or
many PTP domains can coexist in a single clock device. Hence, a CAM or a CAM simulator is sometimes
required depending on the system performance requirements in 2-step operation. Similarly, in 1-step
operation, the timestamp T3 (and optionally T2) needs to be collected by the PTP stack through a CAM
or a FIFO. The use cases are an Ordinary Clock-Master in 2-step, Boundary Clock-Master in 2-step,
Ordinary Clock-Slave in both 1-step and 2-step, Boundary Clock-Slave in both 1-step and 2-step &
Transparent Clock (TC) in 2step. A typical size of the CAM/FIFO required is a network parameter, which
can approximately range from 64 to 256 entrees.
It is possible to use a FIFO in place of a CAM if the CPU can read the timestamps in an orderly fashion.
This simplifies the hardware design as well as CPU processing. The FIFO stores the timestamp along with
the signature of the packet for the CPU to read the timestamp later. The CPU can match the
timestamp’s signature with its signature of the packet before accepting the timestamp. Just in case, the
timestamp is read in an out of order turn, the CPU can keep a shadow copy of the entry to match with
other signatures and read the FIFO for the packet in context. The FIFO is more efficient than the CAM if
the CPU is fine with the ordered read of the timestamps from the FIFO.
Altera Ethernet IP with 1588 feature provides the following IP cores and building blocks.
A 1588 capable Ethernet MAC and PHY, capable of very precise time stamping of packets with
ToD value and an indication on the time-stamp offset. This time stamping achieves equal
accuracy in both 1-step and 2-step operations.
A ToD clock module that supports loading of real ToD value and fine-grain update of its value
and frequency.
Clear-text packet parser that can be used to detect PTP packet types and then tell the Ethernet
MAC the time-field offset for the following packet types: UDP over IPv4, UDP over IPv6, stacked
VLAN. This block is made available in clear-text so that the user can easily augment the code to
cover other packet types the users may need such as MPLS or MAC-in-MAC.
ToD synchronizer to synchronize different ToDs running in different clock domains; for example,
in a system of network line cards to a system master ToD.
These building blocks can be put together in a useful system combined with the user provided CPU and
software stack to create a high-quality 1588 solution. It is the responsibility of the software stack, which
the user either creates or obtains from a third-party, to implement the overall 1588 stack, including the
corresponding logic to support 1-step versus 2-step, etc.
To implement a typical Altera Ethernet MAC-based 1588 system, the user should do the following:
Instantiate a master ToD that is used for time-stamping the transmitted and the received
packets. Typically, one ToD can be shared across MACs. The 64-bit field is needed if you are
supporting TC; otherwise you need the 96-bit field.
Use the ToD synchronizer’s to coordinate from a single master ToD to various slave ToDs as the
case may be (master ToD in a high-quality PTP clock domain and slave ToDs in their respective
MAC clock domains etc).
The Transmit path needs to know the offset of the timestamp and whether there is an IPv6 UDP
correction field that needs update. This can be provided by either the Altera Packet parser or
the user.
1588 Overview
Different PTP clocks
The Figure 3 shows different PTP clocks in a networked distributed system, where Altera’s Ethernet MAC
with 1588 hardware IP can be used. The subsequent sections detail the packet flow in these different
PTP clock systems and the hardware IP’s role facilitating the high-accuracy 1588 synchronization. While
Altera hardware IP supports both 1-step mechanism and 2-step mechanism involving follow-up
messages, the accuracy of hardware IP time stamping remains the same across both the mechanisms.
A networked device configured as an ordinary clock (OC) can be either a master clock or a slave clock
and it is a single port in a 1588 clock domain network.
A networked device configured as a transparent clock (TC) is a device that updates the PTP messages
with the time taken by them to traverse through the network device from an ingress Ethernet port to an
egress Ethernet port. In other words, the TC device updates the PTP event messages with their
residence delay in the devices before the messages are transmitted out. The TC has two modes: end-to-
end and peer-to-peer. The end-to-end TC uses the end-to-end delay measurement mechanism between
slave clocks and the master clock. The peer-to-peer TC involves link delay correction using peer-to-peer
delay measurement mechanism, in addition to the residence delay correction.
A networked device configured as a boundary clock (BC) has multiple ports in a 1588 clock domain with
one slave clock port and possibly more than one master clock port. The BC maintains the same timescale
for the slave clock port and possibly multiple master clock ports. A BC helps to avoid the long chain of
transparent clocks between the network 1588 grandmaster and slave, leading to higher inaccuracy in
the slave’s ToD synchronization. The BC also helps to divide a larger 1588 network as shown below, thus
reducing the traffic going all the way back to the original 1588 master.
OC-M OC-STC (EE) TC(PP)BC
OC-M: Ordinary Clock MasterTC(EE): Transparent Clock in end-to-end mode
BC: Boundary ClockTC(PP): Transparent Clock in peer-to-peer mode
OC-S: Ordinary Clock Slave
Sync
Delay_Req
Delay_Resp
Sync
Pdelay_ReqPdelay_Req
Pdelay_Resp Pdelay_Resp
Sync
Pdelay_Resp_follow_up
Pdelay_Resp_follow_up
Follow_up
Figure 3: Different PTP clocks defined in 1588 v2
The event messages communicated between master and slave clock nodes are shown above. The
follow-up messages are meant for 2-step mechanism and are not required for 1-step mechanism. For
more details on the above, the 1588 v2 protocols may be referred to.
In addition to the above clock nodes, there exists management node communicating management
messages to query and update the PTP datasets maintained by the above clock nodes for the purposes
of initialization and fault management. This node typically resides in a CPU.
Synchronization Process
The synchronization process involves ToD (Time of Day) offset correction and frequency correction
between a master clock and a slave clock. The slave clock collects necessary data to synchronize its clock
with master’s clock through event messages.
OC-Master OC-Slave
Sync
Delay_Req
Delay_Resp
Sync
Follow_up
T1
T2
T3
T4
Slave data
T1, T2
T1, T2, T3
T1, T2, T3, T4
T5
T6
MeanPathDelay(mpd) = ((T2-T1)+(T4-T3))/2
ToD Offset = T6-T5-mpd
Frequency offset = (Fo- Fr)/Fr
where Fr = 1/(T5-T1) & Fo = 1/(T6-T2)
Figure 4: Synchronization between master and slave clocks
As shown above, the slave collects the timestamps [T1, T2, T3, T4] through the event messages: Sync,
Delay_Req, and Delay_Resp and calculates the mean path delay (mpd). At the next sync message, the
slave calculates the ToD offset by subtracting the mpd from (T6-T5) and adjusts its ToD counter
accordingly. Further, the slave clock calculates frequency offset as shown above by comparing the
observed time difference between two successively received sync messages with reference time
difference between two successive sync messages transmitted from the master clock. The slave clock
calculates ToD offset and frequency offset continually to maintain its ToD counter corresponding to the
master clock to the best possible accuracy. This is most often accomplished through frequent
syntonization offset adjustments after the initial ToD offset adjustment and occasional ToD offset
adjustments.
The TC nodes add the residence delays of the PTP event messages to the correction factor (a field in the
PTP message header) to increase the accuracy of synchronization. The BC device helps to break a long
chain of TC nodes, which otherwise increase the inaccuracy of synchronization. The BC device has a
slave clock port synchronizing to one master and more than one master port, which take the slave clock
port’s timescale as the master clock. The 1588 v2 protocol may be referred to, for more details.
As can be readily seen from the above calculations, high accurate timestamps will lead to better overall
system accuracy. Altera IP with its fractional arithmetic capability can provide highest accuracy (ranging
from 4ns to 8ns for Ethernet throughputs from 10Gbps to 100Mbps) facilitating synchronization
required even for stringent applications such as telecom and mobile backhaul. Further, the IP facilitates
visual demonstration or debug of the achieved synchronization through PPS (pulse per second) output.
By observing the PPS output from the master clock and the slave clock on an oscilloscope, we can
perceive the efficacy of synchronization between the two clocks.
Altera’s 1588 Hardware IP in different PTP clocks
Functional flow in 1588 OC master/slave mode involving Altera IP
The Figure 5 illustrates an example of a system implemented with Altera’s Ethernet IP with 1588 feature
as ordinary clock (OC), where this IP is used at both ends of the system as OC master and slave clocks.
The packet flow is as follows.
1. The CPU acting as an OC-master sends a Sync packet via its user logic such as a switching unit or
DMA.
2. The packet parser block after decoding the PTP packet generates a fingerprint (an ID for the PTP
packet) so that a CAM can store the correspondence between this packet and its timestamp and
sends the fingerprint to the MAC block along with the packet.
3. The 1588 logic updates the Sync packet with the timestamp T1 before sending it to the Phy in
one step mechanism as shown in Figure 5.
4. In case of two step mechanism, the transmitting MAC generates the timestamp T1 before
sending it to the Phy and stores the timestamp T1 along with its fingerprint in the CAM.
CPU
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
Packet Packet
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacketPacket
FPGA-OC Master
CPU
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
PacketPacket
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacket Packet
FPGA-OC Slave
Cable
Altera 1588 IPAltera 1588 IP
T1
T2
T3
T4
ToD ToD
Figure 5: An example of Altera 1588 hardware IP in OC-master and OC-slave in a 1588 system
5. The CPU acting as OC-master after knowing that the CAM is non-empty via interrupt or polling
mechanism then queries the CAM with the fingerprint & the response from the CAM after
matching the fingerprint from the CPU with the fingerprint in the CAM contains the timestamp
T1.
6. The CPU then sends a Follow-up message to the Sync packet sent in step 1. The dotted arrows in
OC-master indicate the blocks involved in 2-step mechanism.
Note: Typically, only one mechanism of 1-step or 2-step is operational in a 1588 setup and chosen at the
system setup instant. Thus, either step 3 or steps: 4-6 occur during 1588 operation.
7. The FPGA hosting the OC-slave clock receives the packet and the receiving MAC generates the
timestamp T2.
8. The packet parser validates the incoming packet as a PTP packet and stores the timestamp T2
along with its fingerprint in the CAM. The timestamps for the non-PTP packets are ignored.
9. The CPU receives the PTP packet via user logic and generates the fingerprint for the received
PTP packet. At this point, the CPU acting as the OC-slave has collected the timestamp T1 from
the received PTP packet.
10. The CPU then queries the CAM with the fingerprint and the response from the CAM after
matching the fingerprint from the CPU with the fingerprint in the CAM contains the timestamp
T2.
11. The CPU acting as the OC-slave sends Delay_Req packet via its user logic such as a switching unit
or DMA.
12. The packet parser block after decoding the PTP packet generates a fingerprint (an ID for the PTP
packet) and sends it to the MAC block along with the packet.
13. The 1588 logic in the transmitting MAC of the OC-slave clock generates the timestamp T3 before
sending it to the Phy and stores the timestamp along with its fingerprint in the CAM.
14. The CPU acting as the OC-slave after knowing that the CAM is non-empty via interrupt or polling
mechanism repeats the step 10 to obtain the timestamp T3.
15. The FPGA hosting the OC-master clock receives the packet and the receiving MAC generates the
timestamp T4.
16. The packet parser validates the incoming packet as a PTP packet and stores the timestamp T4
along with its fingerprint in the CAM.
17. The CPU receives the PTP packet via user logic and generates the fingerprint for the received
PTP packet.
18. The CPU then queries the CAM with the fingerprint and the response from the CAM after
matching the fingerprint from the CPU with the fingerprint in the CAM contains the timestamp
T4.
19. The CPU acting as the OC-master sends a Delay_Response packet containing the timestamp T4
via its user logic such as a switching unit or DMA.
20. The packet parser block after decoding the PTP packet instructs the MAC not to timestamp the
packet, as it already contains T4.
21. The 1588 logic in the transmitting MAC of the OC-master sends the packet as is.
22. The FPGA hosting the OC-slave clock receives the packet.
23. The receiving MAC timestamps the packet.
24. The packet parser block, however, notes that the packet type is Delay_Response and sends the
packet further to the user logic ignoring its timestamp.
25. The CPU receives PTP packet via user logic and collects the timestamp T4 from the received PTP
packet.
26. At this point, the stack in the OC-slave is in possession of all the timestamps T1, T2, T3, & T4
from which the mean path delay (mpd) is calculated.
27. The OC-slave after receiving the next Sync packet collects the timestamps T5 & T6 as detailed
earlier in the steps 1 to 10, and calculates the ToD offset as described in the section
‘Synchronization Process’.
28. Further taking the time difference between two successive Sync packets, the stack in the OC-
slave calculates the frequency offset as described in the section ‘Synchronization Process’.
29. The stack residing in the OC-slave CPU supplies the calculated ToD offset and frequency offset to
Servo algorithm, which can either adjust the PLL settings supplying the PTP clock to the ToD or
program the registers in the 1588 IP to synchronize the slave’s ToD with master’s ToD.
30. The process of synchronization through adjustment of the settings for slave’s ToD with the
calculated ToD offset and frequency offset is continual with the repetition of steps 1 to 29.
31. Visually, the PPS pulse outputs (provided by Altera’s IP) from the OC-master and the OC-slave
can be observed on an oscilloscope to appreciate the efficacy of synchronization process.
Note: The correction field (CF) in the PTP header might be updated in any of the above PTP packets for
any fractional arithmetic residue or asymmetry.
Functional flow in 1588 TC mode involving Altera IP
The Figure 6 captures 1588 system involving a transparent clock (TC). The purpose of the TC is to
calculate the residence delays of the PTP packets inside various networking elements between a master
clock and a slave clock so that the offset of slave clock from master clock can be calculated more
accurately.
The typical TC flow as captured above involves capturing the ingress timestamp of the incoming PTP
packet, and capturing the egress timestamp of the packet. In 1-step mechanism, the Altera IP updates
the packet leaving an egress port of the networking element by adding the residence delay (the
difference between egress and ingress timestamps) to the correction field (CF) in the packet’s header. In
case of a 2-step mechanism, the residence delays need to be stored in a CAM with appropriate
signatures, which are matched after the reception of follow-up packets. The follow-up packets are
captured and sent to the CPU of the device hosting the CPU. The CPU updates the follow-up packets
with the corresponding residence delays and sends the packets out.
OC-Master OC-Slave
Sync
Delay_Req
Delay_Resp
Sync
Follow_up
T1
T2
T3
T4
Slave data
T1, T2
T1, T2, T3
T1, T2, T3, T4
T5
T6
MeanPathDelay(mpd) = ((T2-T1-CF)+(T4-T3-CF’))/2
ToD Offset = T6-T5-CF’’-mpd
Frequency offset = (Fo- Fr)/Fr
where Fr = 1/(T5-T1) & Fo = 1/(T6-T2)
TC
Ti1
Te1
Ti2Te2
CF’ = Te2-Ti2
CF = Te1-Ti1
CF’’
Figure 6: 1588 system involving a transparent clock
From Altera IP perspective, the TC accuracy remains the same in both 1-step and 2-step mechanism.
Further the TC can implement 1-step mechanism though the 2-step mechanism exists between master
and slave as long as the stack in slave clock knows where from it can collect the CFs for offset
calculations (whether from Sync or follow-up). The protocol may be referred to, for more details.
The Figure 7 captures how Altera’s IP can be used in the 1588 system involving transparent clocks. The
FPGA acts as a transparent clock (TC) with two ports, where the PTP packets entering into one port and
leaving another port are accounted for their residence delay. The packet flow is as follows.
1. The PTP packet enters into the FPGA through the port on the left and and the Altera 1588 IP
timestamps the packet at Ti1.
2. On Rx, all packets get timestamped in the Altera 1588 IP. Hence, a packet parser validates the
PTP packet and further sends the packet into the user logic along with its timestamp. The
timestamps for the non-PTP packets are ignored.
3. When the packet reaches egress port, the packet parser validates the PTP packet and sends the
packet along with ingress timestamp into the MAC and required command.
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
Mac Rx1588
Phy
Packet+Ti2
Packet
TimeStamp
Packet
Packet+Ti1
FPGA-TC
Cable
Altera 1588 IP Ti1
Te2ToD
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
Mac Rx1588
Phy
Packet+Ti1
Packet
TimeStamp
Packet
Packet+Ti2
Altera 1588 IPTi2
Te1ToD
Cable
Ti2 Ti1
CF’ = CF+Te2-Ti2 CF’ = CF+Te1-Ti1
Figure 7: Altera 1588 IP usage in TC mode
4. The MAC timestamps the packet (Te1) and updates the field ‘correction factor’ (CF) in the
header of the packet with the residence delay calculated as Te1-Ti1. The new correction factor
in the packet is CF’ = CF + Te1-Ti1. The Phy transmits the PTP packet out to the network.
5. Similar flow as in the steps: 1 to 4, is observed for the PTP packet entering into the FPGA
through the port on the right and leaving the FPGA through the port on the left. Here, the
packet is updated with CF’ = CF + Te2-Ti2.
6. In a 2-step mechanism, the CPU collects ingress and egress timestamps when the PTP packet
traverses through the ingress and egress ports, via the CAMs as described in the previous
section. However, the PTP packet is unchanged while traversing through.
7. The incoming follow-up packet is timestamped but the timestamp is ignored by the packet
parser after decoding the packet as a follow-up packet. The packet is further sent to the CPU via
user logc.
8. The CPU updates the follow-up packet after matching the fingerprints with the new correction
field CF’ = CF + Te-Ti and sends the packet to the egress port.
As shown above, the ingress port and the egress port may have different ToDs or a single ToD. The
following care is taken in the IP to ensure high accuracy.
In the case of a single ToD, the ToD runs on the transmit clock so that the residence delay
(difference between two timestamps) is calculated using a single clock.
In case of two ToDs, appropriate synchronizing mechanism is used between the two ToDs so
that the residence delay still appears to be from a single clock.
The system can further increase the accuracy by syntonizing the ToD with a standard reference clock
(such as a GPS PPS or GM itself) to reduce the drift effect on the accuracy of residence delay. Also, the
system can calibrate the frequency offset of the TC with respect to GM so that the slave clock before
calculating the offsets corrects all the CFs accordingly. The future version of the IP is expected to contain
logic that helps achieve syntonization in an effective way.
Functional flow in 1588 BC mode involving Altera IP
The key purpose of a boundary clock is to terminate a long chain of transparent clocks leading to higher
inaccuracy and maintain a single timescale for extending the PTP domain further with higher accuracy.
Also, when the system requires connecting subsystems involving transparent clocks of different types
(Peer to Peer TC subsystem and End to End TC subsystem) as shown in Figure 1, a boundary clock is the
accepted mechanism. The typical application devices include routers, gateways, bridges etc.
A boundary clock usually contains a slave clock port and at least one port as a master clock port.
However, the boundary clock has all the ports in one domain and maintains the timescale used in the
domain. The slave port synchronizes to a master clock external to the boundary clock (BC) as shown in
Figure 1. The master ports in the boundary clock act as individual sources of time for their respective
slave clocks. The master ports in the BC use the timescale maintained by the slave clock (synchronized to
an external master clock) in the same BC.
The following figure 8 captures a BC implementation in an FPGA with one slave port and two master
ports (the master ports can be even higher in number).
Here the packet flow is as follows.
1. As shown above, the slave port takes part in the synchronization process with an external grand
master clock not shown in the figure.
2. The masters taking the timescale of the slave synchronized to the external grand master, source
timing information to the slaves visible to them. In other words, they do not need to maintain
their own ToDs. However, if they have to maintain their own ToDs, then the ToDs need to be in
sync with slave’s ToD, which is the reference timescale for the whole BC.
3. In both the cases, the packet flow is similar to the one described in the section ‘Functional Flow
in 1588 OC master/slave mode involving Altera IP’ in their respective master-slave setup. In
other words, the timestamps shown in the diagram T1, T2, T3, T4 do not form a set for any
offset computation. The slave clock’s T2, T3 timestamps correspond to its own external
grandmaster and the master clocks’ T1, T4 timestamps to their own external slave clocks.
4. The FPGA CPU hosts the independent stacks for the slave clock and the two master clocks with
the common timescale of the slave clock.
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
Packet Packet
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacketPacket
BC Master0
CPU
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
PacketPacket
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacket Packet
BC Slave
Altera 1588 IP Altera 1588 IP
T1
T2
T3
T4
ToD
User Logic
User Logic
Packet Parser
Packet Parser
Mac Tx1588
CAM
Mac Rx1588
CAM
Phy
Packet Packet
Packet
FingerPrint
FingerPrint + TimeStamp
FingerPrint + TimeStamp
CAM query
CAM query
CAM response
CAM response
TimeStamp
PacketPacketPacket
BC Master1
Altera 1588 IP
T1
T4
FPGA-BC
Cable Cable
Cable
Figure 8: A boundary clock with one slave port and two master ports.
References
1. IEEE Standards Association. (2008). 1588-2008-IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control Systems. Retrieved from IEEE
standards website: http://standards.ieee.org/findstds/standard/1588-2008.html
2. Low Latency 10G (support 10G only, or 10M-10G):
http://www.altera.com/literature/ug/ug_32b_10g_ethernet_mac.pdf
3. Triple Speed Ethernet (10M-1G): http://www.altera.com.my/literature/ug/ug_ethernet.pdf