get in sync! - microchip technologyww1.microchip.com/downloads/en/appnotes/get in sync.pdf · get...

Get In Sync!

Confidential 1 March 22 2012

Get In Sync!IEEE1588v2 Transparent Clock Benefits for Industrial

Control Distributed Networks

By Mike JonesSenior Product Marketing Manager

Micrel Inc.

Micrel, Inc. • 2180 Fortune Drive • San Jose, CA 95131 • USA • tel + 1 (408) 944-0800 • fax 1 (408) 474-1000 • http://www.micrel.com

Get In Sync!


Introduction

The demand for cost effective, time synchronized networks continues to increase with the growth

of data acquisition and control applications. From industrial automation to Audio-Video streaming

in the home, the need for each network node to be synchronized is essential. Traditionally, timing

information was distributed via a dedicated network, separate from main application, such as real-

time distribution protocols like IRIG-B. More recently, the market has seen a shift to a single

converged data and distributed timing network based on standard Ethernet communications

supporting IEEE 1588 Precision Time Protocol (PTP). IEEE 1588 PTP offers a method for

distributed network synchronization with sub-microsecond performance.

PTP is not particularly a new protocol; it was developed at the turn of the century and initially

standardized by the IEEE back in 2002. However, it was not really until 2008 with the release of

version 2 (known as IEEE 1588v2 or IEEE 1588-2008) has the method become widespread for

time-sensitive distributed networking solutions.

This article examines the key differences between versions 1 and 2 and demonstrates the need for

version support in distributed topology network, such as industrial control automation.

What is IEEE 1588 PTP? How does it work?

IEEE 1588 PTP is a message-based protocol designed to distribute both time and frequency across

a packet-based network, such as Ethernet. The path delay between the Master and each Slave in

the network is determined and used to adjust the local clock at each slave node. This enables each

node in the network to operate from a local clock synchronized to each other and hence, also to the

master system reference clock.

IEEE 1588 PTP utilizes UDP (User Datagram Protocol) packets over IP to synchronization the

network providing a local clock output source, typically 1pps.

To achieve synchronization with the rest of the network, each node must determine which clocking

source it should use i.e., The Master Clock. All nodes perform the ‘Best Master Clock’ algorithm

(BMCA) to select timing. If the node is to be a Master Clock, then a high precision reference

source, such as GPS, is typically used. If the node is not designated as a master then it will extract

timing from the network using PTP. Failure to extract timing from the network will result in using

the on-board local oscillator. BCMA is continually run to adapt to any changed in the network

configuration.

Get In Sync!


The synchronization messaging process is divided into two phases; Offset and Delay, as shown in

Figure 1. In Phase 1 the offset time between the master and slave is calculated and corrected. To

perform this function, the master continuously transmits a unique message to the slave at defined

intervals, usually every second, as follows;

1. Master sends a Sync message to the slave and time-stamps on departure; TM1.

2. On arrival the Slave time-stamps the incoming Sync message; TS1

The egress time-stamp TM1 is delivered to the slave by one of two methods;

o One-Step – inserted in the initial Sync message sent by the Master

o Two-Step – inserted in a second ‘Follow up message’

One-step offset synchronization will usually require hardware assistance to insert the master egress

time-stamp, on-the-fly, into the Sync message. Two-step synchronization is less efficient,

requiring additional network bandwidth and CPU overhead to support the Follow up message.

PHY

MACIP

UDPPTP

MasterClock

PHY

MACIP

UDPPTP

SlaveClock

HardwareSoftware

Master SlaveTM1

Sync MessageTS1

Follow up Message*TM1

TS2

TM2

Delay Response TM2

Delay Request

Time-stamp

Time-stamp

* 2-Step mode only (no follow up message required in 1-step)

Figure 1. Example of IEEE 1588 PTP Synchronization.

Get In Sync!


The second phase of the synchronization process is the delay measurement. The slave will send a

‘delay request’ to the master that is returned and the round trip delay calculated.

1. Slave sends a Delay Request message to the Master and time-stamps on departure; TS2

2. On arrival the Master time-stamps the incoming Delay Req message; TM2

3. Master sends a Delay Response message to Slave with time-stamp value TM2 embedded.

Following this exchange the Master-to-Slave clock offset and delay can be calculated.

Note the above calculations assume that the delay between master and slave is always

symmetrical.

Non-Deterministic Switch Latency

The slave clock synchronization accuracy is heavily dependent upon a known and constant path

delay experienced by the Sync message, between Master and Slave. Any non-deterministic delay

latencies within this path will equate to an error in the offset and delay PTP calculations, degrading

the synchronization accuracy, unless compensated for.

Ethernet switches implemented today are based upon a ‘Store and Forward’ architecture, rather

than ‘Cut through’ mechanism deployed by the older Ethernet Repeater hubs. Ethernet switches

will store the complete packet then process prior to forwarding. By analyzing the complete packet,

a host of features are possible, such as IEEE 802.1q VLAN (Virtual LAN), IEEE 802.1p Priority

Classification and CRC error checking. The consequence of ‘Store and Forward’ architecture is

non-deterministic latency behaviour, which will consequently increase timing jitter.

The total packet latency within an Ethernet switch is derived from two components, packet size

and the internal forwarding delay, and can be calculated as below:

Total Latency = (Packet size x 8) / rate + Forwarding delay.

The variable packet size (64 Bytes to 1518 Bytes) equates to a packet latency delay between

5.12us to 121.44us and variation in forwarding delays can differ by up to 200ns. Switching delays

Delay = (TS1 –TM1) + (TS2 -TM2)2

Offset = (TS1 –TM1) - (TS2 - TM2)2

Get In Sync!


can be fixed by fixing packet size. However, variations in forwarding delays cannot be influenced

and are a consequence of ‘Store and Forward’ architecture.

A potentially more significant result of variable switching delay is that of congestion. Congestion

will occur during high traffic demand, increasing latency with the need for additional packet

buffering. Although IEEE 802.1p Priority queuing goes some way to ensuring a network quality

of service (QoS) and can minimise the PTP packet switch latency, the overall variation still cannot

be tolerated.

Resolving the issue of variable switch latency is one of the significant areas where versions 1 and 2

of the IEEE1588 standard differ. Compensation is achieved with the introduction of two special

switches, Boundary Clock (version 1) and Transparent Clock (version 2). IEEE 1588 version 2,

published in 2008 also provides key enhancements to the version 1, including;

o Increased accuracy to achieve sub nanosecond clock jitter

o Faster synchronization with sync rates > 1 per second

o Shorter messages for reduced network bandwidth

o 1-step mode (eliminating the need for follow-up message)

o Transparent Clock mode

Figure 2 shows a typical example of a distributed (daisy-chain) network using IEEE 1588 version

1 PTP implementation for clock synchronization. This is a commonly used topology utilized in

Industrial Control Automation, to simplify the cable management.

Grandmaster Clock

The Grandmaster clock provides the absolute time reference for the network. Grandmaster clocks

usually have a high-precision source, such as a GPS or atomic clock, although not compulsory. If

syntonization only is required then the grandmaster clock can also free run off a local oscillator.

Boundary Clock (PTPv1)

Version 1 of the IEEE 1588 specification defines the method for removing the effects of non-

deterministic switch delay (known as residence time) using Boundary clocks. A boundary clock

can be configured as Master or Slave depending upon the result of the Best Master Clock

Algorithm. Boundary clocks acts as an interface (boundary) between separate synchronization

clock domains.

Get In Sync!


As shown in Figure 2, the two network ports of the switch act to segment the synchronization

domains using master to slave clock. The result in a distributed (daisy-chain) network topology is

a series of cascaded control loops. Each hop will result in the control loop error adding to the

clock jitter, which restricts the PTPv1 Boundary clock method to a minimal number of switches in

the network chain.

Transparent Clock (PTPv2)

Figure 3 shows the same distributed network topology implemented with IEEE 1588v2

Transparent clock method. Transparent clocks were introduced in version 2 of the IEEE 1588

specification to improve synchronization accuracy within distributed (daisy-chain) topologies.

Rather than creating a different synchronization clock domain at each node, the transparent clock

method will update the time-interval field within the PTP message. This method measures the

switch delay in hardware between the two network ports − known as the residence time (time

between packet arriving at the ingress network port and it leaving at the egress network port) −

and corrects the PTP message. This correction can either be inserted into the PTP message on-the-

Figure 2. Distributed Synchronization Network using IEEE 1558 v1 Boundary Clock.

Slave

HostHost

SC

MC

BC

SC

Master ClockBoundary Clock

Slave Clock

GMC Grand Master Clock

GPS

Grand MasterClock

MC

MC

Slave

HostHost

SC

BC BC BC

Slave Slave Slave

BC BC BC BC

HostHost

SC

HostHost

SC

HostHost

SC

BC BC BC

Master - Slave Master - Slave Master - Slave

SlaveSlave

HostHost

SCSC

MC

BC

SC


Slave Clock

GMC Grand Master ClockMCMC

BCBC

SCSC


Slave Clock

GMCGMC Grand Master Clock

GPS

Grand MasterClock

MC

MC

SlaveSlave

HostHost

SCSC

BCBC BC BCBCBC BCBC

SlaveSlave SlaveSlave SlaveSlave

BC BCBCBC BCBC BC BCBCBC BCBC

HostHost

SC

HostHost

SCSC

HostHost

SC

HostHost

SCSC

HostHost

SC

HostHost

SCSC

BC BCBCBC BCBC BCBC

Master - Slave Master - Slave Master - Slave

Get In Sync!


fly (1-Step) or inserted into the associated follow up message (2-Step), as demonstrated in Figure

1.

This method, to measure and correct for the switch residence delay in the time-interval field of the

PTP message, make the network switches appear transparent to Master and all the Slave nodes.

The accuracy of the residence time measurement and insertion into the PTP message has a direct

consequence to the synchronization accuracy and thus requires hardware assistance.

There are two types of Transparent clock available, End-to-End and Peer-to-Peer, both have their

merits. End-to-End (E2E) Transparent clock mode updates the time interval field based only on

the switch residence time. Peer-to-Peer (P2P) Transparent clock mode corrections, however, are

based on the ingress path propagation delay in addition to switch residence time. E2E

configuration is relatively simpler but is less efficient as it generates greater PTP traffic to the

master. P2P mode has the benefit of adapting more quickly to network configuration changes but

is less accurate for distributed networks, which typically opt for E2E mode.

Figure 3. Distributed Synchronization Network using IEEE 1558 v2 Transparent Clock.

Slave

HostHost

SC

MC

BC

SC


Slave Clock

GMC Grand Master Clock

GPS

Grand MasterClock

MC

MC

Slave

HostHost

SC

TC TC TC

Slave Slave Slave

TC TC TC TC

HostHost

SC

HostHost

SC

HostHost

SC

TC TC TC

Transparent Clock (TC) compensates for switch delays bycorrecting timestamp on-the-fly

SlaveSlave

HostHost

SCSC

MC

BC

SC


Slave Clock

GMC Grand Master ClockMCMC

BCBC

SCSC


Slave Clock

GMCGMC Grand Master Clock

GPS

Grand MasterClock

MC

MC

SlaveSlave

HostHost

SCSC

TCTC TC TCTCTC TCTC

SlaveSlave SlaveSlave SlaveSlave

TC TCTCTC TCTC TC TCTCTC TCTC

HostHost

SC

HostHost

SCSC

HostHost

SC

HostHost

SCSC

HostHost

SC

HostHost

SCSC

TC TCTCTC TCTC TCTC

Transparent Clock (TC) compensates for switch delays bycorrecting timestamp on-the-fly

Get In Sync!


Transparent and Boundary Clock Synchronization Accuracy

IEEE 1588v1 Boundary Clock implementation is less effective, as we will discover when the

number of hops in a distributed (daisy-chain) network increases, due to the cascaded nature of the

control loops at each node (Ethernet switch). This has been demonstrated in the white paper

‘Precision Clock Synchronization – IEEE1588’ published by Hirschmann. The paper compares

the network synchronization accuracy (jitter) between Transparent (PTPv2) and an optimized

Boundary clock (PTPv1) methods, as the number of cascaded nodes in the network increases. The

results are visualised in the graph below.

Interpolation of Clock Jitter per Network Node for Tranparent andBoundary clocks

0

200

400

600

800

1000

1200

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Number of Cascaded Network Nodes

Max

Syn

chro

niza

tion

Jitt

er(n

s) Tranparent ClockBoundary Clock

The Transparent clock method of resolving non-deterministic nature of switches shows a 4X to 5X

improvement in the resulting synchronization accuracy for a distributed topology network.

In addition to improved synchronization accuracy, transparent clocks also offer further benefits

over version 1 Boundary clocks;

o Less host CPU usage required

o Faster time to initialize and reconfigure if network topology changes

o Less interoperability problems from BMC algorithm implementation

Get In Sync!


EtherSynch™ TechnologyThe key to driving time-critical market is to realize synchronization performance, ease of use and

cost benefits with the availability of off-the-shelf silicon. Presently, an Ethernet 1588v2

attachment is typically costly, implemented using an FPGA, with external Ethernet PHY

Transceivers. In addition PTP software stack license fees are also incurred. Micrel’s new

EtherSynch™ product family introduction provides systems designers with the most highly

integrated IEEE 1588v2 network attachment devices available, significantly reducing size, power

consumption, as well as overall BOM costs. EtherSynch™ technology dramatically reduces both

cost and complexity of IEEE1588 enabling an Ethernet node.

Highest Integration

This Industrial-grade platform represents a single chip, highly integrated 1588v2 Ethernet

attachment, shown in Figure 4 below.

o Wire-speed, fully managed 3-port 10/100 Mbps switch

o Embedded Dual, ultra-low-power 10/100Base-TX PHYs, with fixed delay feature

o 100Base-FX optical transceiver support

o Dual IEEE 1588v2 time stamp units

o Support for Grand Master, Ordinary, Master, Slave, and Transparent Clock modes

o 1-step & 2-Step Synchronization support with 100% Hardware implemented Transparent

Clock mechanism

o P2P and E2E support

o Synchronized Precision Clock GPIO facility

o Ultra-low Power consumption (sub 300mW total circuit)

o Advanced power management including IEEE 802.3az Energy Efficient Ethernet (EEE)

o Compact size through a single-chip design (10 mm x 10 mm) and integrated line

termination

o Industrial temperature operating range (-40oC - +85oC).

Get In Sync!


Figure 4: KSZ84xx EtherSynch™ IEEE 1588-Enabled 3-Port Switch Architecture.

Highest Performance, Reduced CPU Overheads

Synchronization jitter performance is shown to be of the order of 100 ns or less (reference Figure

5), even during 100 percent network loading and the use of low cost +/-50ppm local crystal

oscillators. Such performance is attained through positioning the time stamp units between the on-

chip PHY and the MAC, as close as possible to the PHY. In doing so, any variable latency in the

MAC layer and is eliminated. Further enhancements to synchronization accuracy can be realised

using a higher accuracy/lower jitter crystal (for example, TCXO) or by increasing the

synchronization rate to greater than 1 per second, used in this test.

Programmable I/OProgrammable I/O

Switch FabricSwitch Fabric

Integrated PHYsIntegrated PHYs

LEDControl

10/100MAC 310/100MAC 3

10/100MAC 210/100MAC 2

10/100PHY 210/100PHY 2

AddressLookup

QueueMgmt.

FrameBuffers

BufferMgmt.

MIBCounters

Pack

et P

roce

ssin

gVL

AN

, Prio

rity,

Flo

wC

tl., e

tc.

Pack

et P

roce

ssin

gVL

AN

, Prio

rity,

Flo

wC

tl., e

tc.

10/100MAC 110/100MAC 1

10/100PHY 110/100PHY 1

ControlRegisters

GPIO

SPI

IEEE

158

8 Ti

me

Stam

pIE

EE 1

588

Tim

e St

amp

MII / RMIIor

Host Interface

Programmable I/OProgrammable I/O

Switch FabricSwitch Fabric

Integrated PHYsIntegrated PHYs

LEDControl

10/100MAC 310/100MAC 3

10/100MAC 210/100MAC 2

10/100PHY 210/100PHY 2

AddressLookupAddressLookup

QueueMgmt.QueueMgmt.

FrameBuffersFrameBuffers

BufferMgmt.BufferMgmt.

MIBCounters

MIBCounters

Pack

et P

roce

ssin

gVL

AN

, Prio

rity,

Flo

wC

tl., e

tc.

Pack

et P

roce

ssin

gVL

AN

, Prio

rity,

Flo

wC

tl., e

tc.

10/100MAC 110/100MAC 1

10/100PHY 110/100PHY 1

ControlRegisters

GPIO

SPI

IEEE

158

8 Ti

me

Stam

pIE

EE 1

588

Tim

e St

amp

MII / RMIIor

Host Interface

Get In Sync!


Figure 5. Sub 100ns Synchronization Jitter with KSZ84xx EtherSynch™ Family.

Switch residence time delay is measured and corrected on-the-fly by the support of 1-step

Transparent Clocks mechanism, implemented 100 percent in hardware. Hardware-assisted PTP

operations (Transparent Clock corrections) are not only more efficient, but more importantly,

conserve scarce Host CPU resources which can otherwise be dedicated to applications processing.

Non-Deterministic PHY Delay

Another significant effect contributing to asymmetrical and variable delays in IEEE 1588 networks

is the behaviour of the clock recovery unit in most commercially available 10/100Base-TX

Ethernet PHY Transceivers. As we previously highlighted, any variable path delay in a network

results directly in reduced synchronization accuracy. As this variation resides inside the PHY

itself, prior to the time-stamping engine, it cannot be compensated for by the Transparent Clock

mechanism.

IEEE 1588v2 Jitter < 1,000 ns

4x OutputSlave Clocks

(SC)

Jitter < 58 ns

Get In Sync!


Figure 6. Example Ethernet PHY Timing.

Figure 6 shows the basic blocks of the Ethernet PHY architecture. In the transmit direction, data is

synchronised to the local 25MHz oscillator and shows a fixed delay Ts. However, in the receive

direction, a variable delay, ∆Tr2, is typically exhibited, due to the locking mechanism of the Clock

Recovery circuitry, in addition to the fixed decoding delay Tr1. This variable delay is due to the

alignment, in one of the 5 possible phases; 0ns, 8ns, 16ns, 24ns or 32ns of the generated 25MHz

MII RXC clock, with respect to the recovered 125MHz Line Clock. The result is a shift in the

receive direction delay every time the link is re-established. This common effect has been

recognised by Micrel with the integrated PHY transceivers utilized in the EtherSynch™ product

family always providing a fixed phase recovered clock.

The Precision GPIO facility enables multiple devices to share a single Ethernet 1588v2

attachment, all synchronized to the network master clock. Precision GPIO is highly flexible and

configurable to support a diverse set of device-layer needs.

o Reference clock output (1Hz to 12.5MHz)

o Waveform output generator

o Output up to 32-bit control word

o Input clock for local synchronization

o Edge & Pulse monitor/sensor

TX+ / TX-

4

RX+ / RX-

25MHz

MII TXD

MII RXD

MII RXCRecovered LineClock

44B / 5BEncoder

DescramblerSerial / Parallel4B / 5B Decoder

Clock & DataRecovery

NRZ / NRZIMLT3 Decoder

Parallel –Serial

Conversion

ScramblerNRZ / NRZI

MLT3 Encoder

5

Ts

Tr1 ∆Tr1

Get In Sync!


Pre-qualified PTP software stack is available from Micrel free of charge (following End User

License Agreement). This considerably reduces development costs and time to market for

customers, avoiding expensive license fee, often in excess of $100k. The software has been

specifically developed by OnTime Networks, who have in excess of 10 years Time

Synchronization development experience. In addition, any IEEE 1588v2 PTP stack software can

be utilized (and optimised) to work with the KSZ84xx platform.

Conclusion

The introduction of IEEE 1588 version 2 has brought major benefits to distributed synchronized

networks, including; faster synchronization, improved efficient use of network bandwidth and

reduced host CPU overheads. However, the most significant enhancement has been the

introduction of Transparent clocks for correcting non-deterministic switch residence time delays.

Synchronization accuracy in distributed networks, achieved by Transparent clock methods, have

shown to be vastly superior to the alternative; version 1 Boundary clocks.

Transparent clock implementation is essential for any distributed synchronized network topology,

commonly utilized in applications such as Industrial Automation and Control.

Micrel’s EtherSynch™ product family provides the most highly integrated IEEE 1588v2 network

attachment devices available. Size, power consumption, CPU overheads and overall BOM costs

are significantly reduced, whilst offering superior synchronization performance.

EtherSynch™ technology dramatically reduces both cost and complexity of ‘IEEE1588 enabling’

an Ethernet node. It is ‘IEEE1588v2 made simple’.

For further details, contact your Micrel representative or visit: www.ethersynch.com.

KSZ8463MLI 3-Port 10/100Mbps Ethernet Switch with MII

KSZ8463RLI 3-Port 10/100Mbps Ethernet Switch with RMII

KSZ8462HLI 2-Port 10/100Mbps Ethernet Switch with Host interface

KSZ8441HLI Single-Port 10/100Mbps Ethernet MAC/PHY Controller with Host interface

Note: EtherSynch™ is a trademark of Micrel, Inc.

get in sync! - microchip technologyww1.microchip.com/downloads/en/appnotes/get in sync.pdf · get...

Documents