High performance Sync Solution
for Cost Sensitive Devices

Introduction

Time as commodity This 4-layer module is a complete drop-in IEEE 1588 solution and measures only 24x45 mm, less than 1x2 inch.

About PTP

PTP is independent of network technology but assumes that the average path delay between nodes is equal in both directions. The Protocol Engine will automatically adjust for this delay and will tolerate changes of the delay caused by network reconfiguration. We assume that TCP/IP over Ethernet used. In a PTP network a Grandmaster (GM) is the node that defines what is the correct time. A GM normally has a highly stable oscillator and can have its clock locked to a built in GPS receiver. Thereby all clocks in the network can synchronize to a common reference such as TAI or UTC, which may be of value for legal reasons. In some applications a local time reference may be sufficient, e.g. in a group of machines without any critical coupling outside the group. Sometimes the speed of the clock, i.e. the frequency, is more important than time. PTP can here be used to accurately and at low cost keep a frequency at a nominal and stable value for synthesis of the correct radio frequencies in a radio base station. There may be several potential GMs in a PTP system, and the Protocol Engine software contains a mechanism, the Best Master Clock algorithm, that enables the clocks in the network to agree on the selection of the GM.

The standard describes how synchronization is done by the exchange of different messages between master and slave. The messages are described below (see fact box) with a diagram showing the interdependencies between the messages. Each message is a UDP packet, encapsulated in an Ethernet frame. Time stamping is done for some messages. Software in the slave performs the necessary computations, filters the phase and frequency error signals and adjusts the slave clock so the errors are kept within narrow tolerances. The algorithms must be such that the time to lock is short enough (usually less than a minute), but when steady state has been reached, the servo can utilize the fact that the source is very stable and the only source of error to neutralize (when the jitter has been averaged out) is the relatively slow inherent drift of the local clock.

A slave can also be a master for another slave and such clock is called a Boundary Clock (BC). A BC has a network port with slave functionality that controls a local clock and has one or more ports with master functionality that distributes the local clock’s time instead of forwarding PTP messages between its slave and master ports.

Version 2 of PTP introduces yet another type of clock called Transparent Clock (TC). A TC can replace a BC in network elements. A TC does not have its own clock, and it does not block PTP messages between the master and the slaves. However, it inserts data on its delay (residence time), and slaves “downstream” can take that into account in their computations. The residence time can be accumulated over several nodes, so a slave can adjust for the aggregated time delay in a chain of TCs.

Imsys slave clock implementation

Describing a slave clock is sufficient, since the master is similar and simpler, except for its stable reference source.

The block diagram illustrates roughly the organization of the system and how it is implemented. Green color is used for software, yellow for microcode, and blue for hardware. Everything is contained on the module described above. The customer application program can be developed in ANSI C, using Imsys Developer. The platform has a POSIX compliant RTOS, a flash file system, and several I/O interfaces in addition to Ethernet.

The Imsys processor architecture is built on extensive use of microcode – internal very low level, high speed, control code with wide microinstructions controlling the operations of every cycle with extreme flexibility in the combination of operations. Part of the microcode is writable, i.e. “soft” as software, which is unusual.

For accessing the network, the Imsys processor chip contains an Ethernet MAC, implemented partly in microcode and partly in on-chip logic.

A clock should basically have a high frequency oscillator and a counter, with adjustable frequency and phase (i.e. time). In the Imsys system system the local PTP clock can be adjusted without actually changing the oscillator frequency or the high-frequency counter. This will be described below.

On-chip timers

An on-chip configurable 8-channel timer system is used for the high-frequency timer and timestamp register, as well as for producing, under microprogram control, precise time signal output for use by embedded system hardware external to the chip.

Adjusting speed and phase of the local clock

A high-frequency oscillator drives a counter, but neither the oscillator nor the counter is adjustable. This counter measures “raw time” at the slave.

In the Ethernet MAC logic, the passage of the SFD byte to or from the PHY is detected. This event triggers the copying (capture) of the raw time counter contents to a register, and a microprogram IRQ is generated. The microprogram reads the register, as well as a continuation (more significant part) of the raw time counter that it keeps in its scratchpad, and stores this raw timestamp in a queue. However, it first checks that it is a PTP frame, or the timestamp is discarded.

When the raw time counter passes zero, it generates a microprogram IRQ, which triggers the microprogram to increment the continuation in the scratchpad.

Before the timestamps are delivered from the queue to the PTP software, they are converted to precise time according to the slave clock – which is virtual. The conversion is done by multiplication with a parameter A and addition of another parameter B.

The same conversion is done every time the software needs to read the current value of the precise time.

As mentioned above, the servo loop does not control the frequency or phase of the hardware counter. Instead it controls the parameters A and B. The actual slave precise time is not visible anywhere unless when it is calculated, which is only when needed. This saves energy.

Sync: This is a message from master to slaves, normally multicast. It is timestamped by both master and slave. It is sent at a sufficiently high frequency, e.g. once every second. The slaves timestamp the arrival and use these timestamps mostly to measure the frequency error, i.e. they calculate the time difference between successive sync messages according to the local slave clock, in order to compare that difference with the time difference observed at the master.

Follow_Up: This is also a message from the master. It follows immediately after a Sync message and contains in its payload the master’s timestamp for the sync message. The slave needs these timestamps for the calculation of the time difference mentioned above, but now measured with the master’s clock, and can thereby calculate the error in the slave clock’s frequency. This error is processed in order to arrive at a suitable correction, drift adjustment, of the frequency of the slave clock.

Delay_Req: This is a message from a slave to the master, sent at a lower frequency than that of the Sync and Follow_Up messages. It is timestamped by both slave and master.

Delay_Resp: This is sent from the master to a slave, as a response to the Delay_Req message from that slave. It transfers the master’s timestamp of the Delay_Req message. The slave can now calculate the apparent delay from slave to master. If the clocks are not perfectly synchronized the result will be affected by an error equal to the difference in phase between the two clocks. However, the corresponding calculation of the delay from master to slave, using the Sync message timestamps, will contain this same error but with opposite sign. Thus, by adding these calculated delay times together the errors cancel, and the sum is twice the actual delay time (provided it is the same in both directions). The servo software strives to advance or slow the slave clock until the delay time measured for the sync messages is equal to this calculated actual delay time.