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