Utilizing FPGAs in an IEEE 1588 Precision Time Control Implementation | Network Systems Designline




March 30, 2007

Utilizing FPGAs in an IEEE 1588 Precision Time Control Implementation

Network provides microsecond control

The IEEE 1588 Standard Precision Time Protocol (PTP) is being used by industrial automation applications for precise time synchronization (PTS) on Ethernet networks. PTS provides accurate time synchronization for distributed control nodes.

According to the ARC Industrial Ethernet Report of June 2005, the Industrial Ethernet market has a projected CAGR of 51.4 percent and is expected to reach 6.6 million units by 2009 propelled by the heavy adoption of the IEEE 1588 Standard. Prudent industrial system designers must carefully evaluate their options to cost-effectively and confidently implement this industrial standard as it makes greater inroads. And certainly, the selected design route must take into consideration the update to Rev. 2.0 of the IEEE 1588 Standard when it is completed this year.

A triple-speed Ethernet medium access control (MAC) is essential for supporting the IEEE 1588 Standard. Today, designers have a few implementation approaches at hand including FPGAs as a first step in the implementation process.

Getting A Handle On IEEE 1588

The IEEE 1588 PTP synchronizes an industrial control system to within less than a microsecond. This timing includes synchronizing local clocks in sensors, actuators, and other terminal devices using the same network that also transports process data. The 1588 clock is used in a sensor in one of two ways. It can generate a timestamp at the moment the data is acquired.

Or, it is used as a mechanism to generate the acquisition trigger. This is performed by comparing the time of the 1588 clock to a specified trigger time provided to the component as part of the application. Similarly in an actuator, the IEEE 1588 clock generates the actuation trigger by comparing the time of the 1588 clock to a specified trigger time provided to the component as part of the application.

Precise timing, therefore, provides a solid basis for real time Industrial Ethernet, whereas before, real time capability was only available as part of specially optimized systems. A system in relation to an application can be real time if the system meets all the application's timing requirements. For instance, a communications system must guarantee deterministic behavior if hard real time is to meet motion control application requirements. Like other protocols, PTP is also based on the best possible time matching between transmitted and received data. Unlike SNTP (simple network time protocol), the time when data is transmitted does not need to be transmitted in the synchronization packet, itself, but in a following packet.

In this way, transmission and measurement can be decoupled. The protocol was designed for small homogeneous and also heterogeneous local networks. Further, IEEE 1588 developers focused on low resource usage so that the IEEE 1588 protocol can also be used in low-end and low cost terminal devices. No special requirements are placed on memory or CPU performance, and only minimal network bandwidth is needed.

The IEEE 1588 PTP functions by organizing network clocks in a master-slave hierarchy. PTP identifies the master clock and then arranges for a two-way timing exchange, as shown in Figure 1. In this scheme, the master transmits messages to its slaves to initiate synchronization. Each slave then responds to synchronize itself to the master. This sequence is repeated throughout the specified network to achieve and maintain clock synchronization.


Figure 1. Synchronization process involves two steps.

Time difference between master and slave is corrected and delay measurement or clock skew correction determines delay between slave and master. credit: John Eidson, Agilent Technologies

Incoming and outgoing PTP-packets are time stamped at the start of frame (SOF) of the corresponding Ethernet packet, which is performed at each point in an IEEE 1588-enabled network.

The protocol then exchanges this information between master and slaves using five IEEE 1588 message types; SYNC, DELAY_REQUEST, FOLLOW_UP, DELAY_RESPONSE, and MANAGEMENT.

Protocol software uses these messages to calculate the offset and network delay between time stamps, applies filtering and smoothing, and adjusts the slave clock phase and frequency as needed. With the low demand on computing power, PTP is implemented using less than one percent of the computing resources found in an off-the-shelf communications processor.

IEEE 1588 networks are automatically configured and segmented. Each node uses the best master clock algorithm (BMC) to determine the best clock in the segment. In this process, BMC compares the properties of the communicating clocks, which include accuracy, layer, drift, and variance. From this information, the BMC derives the states for all local ports.

The current properties of the master clock are cyclically transmitted to the slaves in synchronization messages. The advantage here is that the states do not need to be negotiated, but are calculated individually on each node. This ensures that the PTP network is automatically configured into a tree structure, starting from the best clock available, the grandmaster.

IEEE 1588 also takes into account the need to override selection of clock states if necessary. This is performed using the management protocol so that clock parameters can be configured and read. This protocol makes it possible to exchange information with any other clock or all clocks at the same time.

PTP is based on IP multicast communication and is not restricted to Ethernet. It can be used on any bus system supporting multicasting. This type of communications offers the advantage of simplicity; IP address administration does not need to be implemented on the PTP nodes allowing scaling of the network.

Every slave port synchronizes the local clock for its node to the master clock by exchanging synchronization messages with the master. The actual synchronization process is divided into two phases.

First the time difference between master and slave is corrected. This is the offset measurement. During this correction, the master cyclically transmits a unique sync message to the related slave at defined intervals. This sync message contains an estimated value for the exact time the message was transmitted.

For highly accurate synchronization, a mechanism determines the time of transmission and reception of PTP messages as precisely and as closely as possible to the hardware over the network. This is a form of self-calibration. This precise time stamp allows protocol jitter to be eliminated.

The master measures the exact time of transmission, while the slaves measure the exact times of reception. The master then sends in a second message - the follow-up message " that contains the exact time of transmission of the corresponding sync message to the slaves.

When it receives the first sync message and the corresponding follow-up message, the slave calculates the correction (offset) in relation to the master taking into account the reception time stamp of the sync message. The slave clock must then be corrected by this offset. The second phase of the synchronization process is the delay measurement or clock skew correction. This determines the delay or latency between slave and master. The time difference between master and slave clocks is a combination of clock offset and message transmission delay. Hence, correcting clock skew is performed in two phases, offset correction and delay correction. The master clock initiates offset correction using sync and follow-up messages, as shown in Figure 2.


Figure 2. IEEE 1588 example shows offset and delay correction to synchronize clocks.

When a sync message is sent from the master, the slave uses the local clock to time stamp the arrival of the sync message and compares it to the actual sync transmission time stamp in the master clock's follow-up message.

The difference between the two time stamps represents the offset of the slave plus the message transmission delay. The slave clock then adjusts the local clock by this difference at point A.

To correct for the message transmission delay, the slave uses a second set of sync and follow-up messages with a corrected clock to calculate the master-to-slave delay at point B. The second set of messages is necessary to account for variations in network delays.

The slave then time stamps the sending of a delay request message. The master clock time stamps the arrival of the delay request message. A delay response message is then sent with the delay request arrival time stamp at point C.

The difference between time stamps is the slave-to-master delay. The slave averages the two directional delays and adjusts the clock by the delay to synchronize the two clocks. Because the master and slave clocks drift independently, periodically repeating offset correction and delay correction keeps the clocks synchronized.

The delay measurement is performed irregularly and at longer time intervals than the offset measurement. In this manner, network and terminal devices are not heavily overloaded.

But a symmetrical delay or same value for both directions between master and slave is crucial for delay measurement. The synchronization process eliminates temporal fluctuations in PTP elements and the latency time between master and slave.

As shown in Figure 3, an IEEE 1588 boundary clock is used on network infrastructure components such as switches and routers to compensate for the jitter introduced by those components.

Significant delay jitter is produced in switches, especially during overload conditions. Jitter of up to 120 microseconds (S) may occur even if only a single long packet arrives in the switch prior to the synchronization packet. A boundary clock guarantees that synchronization is efficiently performed over a physical connection even when transmission jitter is negligible.

The boundary clock also serves as a time transfer standard between the subnets defined by a router or other network device. The router or other device must be configured to block all IEEE 1588 messages. The boundary clock has a network connection to each of the subnets. When viewed from a subnet the boundary clock appears exactly like any other ordinary 1588 clock in the system.


Figure 3. Boundary clock compensates for jitter introduced by network infrastructure components.
Within a subnet, ordinary clocks and the portion of the boundary clock visible from the subnet synchronize as ordinary clocks. The boundary clock resolves all of the times of the several subnets by establishing a parent child hierarchy of clocks.

In a system with a single IEEE 1588 boundary clock, the boundary clock is at the root of this hierarchy and serves as the master clock for all clocks in each of the subnets. Aside from its synchronization functionality, an IEEE 1588 boundary clock provides for the appropriate re-transmission of 1588 management messages. A key aspect for the implementation is a clear interface definition. The IEEE 1588 PTP comprises both hardware and software elements. In the hardware element, the high precision time is generated while reading the time stamp on the synchronization packets in both transmit and receive directions. The message detector analyzes incoming and outgoing packets and detects synchronization packets based on specific values in the packet. For these packets, exact time and identification of the packet are saved.

Hardware and software suppliers have contributed their respective IEEE 1588 PTP implementations, however, as of this writing; a most efficient implementation is believed to be a MorethanIP 1588 Tri-Speed Ethernet MAC core, shown in Figure 4. Industrial control system designers can implement the IEEE 1588 standard with this IP core using either an Altera Stratix III or Cyclone III FPGA. FPGA reprogrammability, designs can be quickly updated when the next version of the standard is implemented.


Figure 4. IEEE 1588 Tri-Speed Ethernet MAC Core
The programmable 10/100/1000 Ethernet MAC with IEEE 1588 support from MorethanIP integrates a standard IEEE 802.3 Ethernet MAC with a time stamping module. It supports Ethernet applications requiring precise timing references for incoming and outgoing frames to implement the IEEE 1588 distributed time synchronization protocol.

The core can be seamlessly connected to any industry standard Gigabit Ethernet PHY device via a Gigabit Medium Independent Interface (GMII for 1000Mbps applications) or Medium Independent Interface (MII for 10/100Mbps applications). It can also be connected to a user application via a system-on-a-chip (SOC) interface providing seamless connectivity to any MorethanIP core interface or a third party module. This core is optionally delivered in generic synthesizable HDL code for use with an FPGA or ASIC or in an FPGA encrypted source format.

The IEEE 1588 PTP can also be implemented solely in software, while IEEE 1588 hardware time stamping can be performed by connecting an FPGA between the Ethernet PHY and MAC. The FPGA time stamps each incoming and outgoing SYNC and DELAY_REQUEST message. The software-only implementation provides industrial control designers with sub-100 microsecond range accuracy, similar to the software-implemented Network Time Protocol (NTP) and SNTP.

The downside is most applications demand the higher accuracy time stamping packets achieve at the PHY and MAC layers interface. This key interface is known as hardware time stamping, which improves accuracy from 50 to 100 nanoseconds (ns). This represents a significant improvement over NTP and SNTP methods.

Other IEEE 1588 design offerings are based on powerful processing and appear to provide design overkill. For example, one implementation combines legacy RISC-based 32-bit communications processor and companion Ethernet controller blocks to perform hardware time stamping. In this instance, a key feature of the processor engine is its ability to accelerate communications protocols. Supporting literature asserts that the processor engine provides integrated multi-protocol processing and internetworking at rates of up to 1.2Gbps. The IEEE 1588 PTP does not place special requirements on CPU performance. By implementing a legacy communications processor and Ethernet controller, industrial control designers add extra cost and are harnessed with unnecessary processing power.

About the Author Frank Hansen is Altera Corp.'s Market Development Manager Industrial Europe, based in Mnchengladbach, Germany. Telephone: +49 2161 57 37 91