IEEE-1588 Software Design and Multi-core

IEEE-1588 Software Design and Multi-core

From a high level, IEEE-1588 software design and multi-core design and implementations consist of time-stamping hardware, protocol parsing software and filtering and clock correcting algorithm. The prior article mainly dealt with how the time-stamps were exchanged between master and its various slaves while the next article would deal with the related algorithms. This section deals with how all this gets tied together as a complete system and solution that achieves synchronization.

In order to keep the operating-system and stack latencies from adding up, it is beneficial to time-stamp the packets as close to the hardware as possible i.e. when a PTP message leaves the master or when it reaches the slave. This requires a special time-stamping circuit with a Real Time Clock in the hardware. This hardware either has to understand the protocol (so as to insert the RTC value at the correct offset in the message), or otherwise, maintain a buffer or queue that the protocol parsing software can pick time-stamps  from, for each received or transmitted message.

Secondly, due to the above requirement, it becomes necessary for the hardware to be aware of messages that are PTP versus the other normal packets. This is because only PTP packets would need to be time-stamped. Such classified packets are separate from data-traffic and can then be switched to the 1588 protocol parsing software directly without requiring another slower classification at the software level.

Contrary to Sync-E, software plays the major role in IEEE 1588 while hardware lends a helping hand. The major responsibilities of the software are:

  1. Setting up the system based on the capability of the slave and advertisement by the master.
  2. Selecting the master clock by processing the Announce messages.
  3. Forming and maintaining the set of {t1, t2, t3, t4} time-stamps. These time-stamps, as we have seen before, come from different kinds of messages (t1, t2 from Sync message; t3, t4 from Delay response message). These messages have unique sequence numbers, so that the correct association can be formed. The parser also has to take care of the follow-up time-stamps if the master supports a two-step clock. In the real world scenarios, packet loss/re-ordering would render any set incomplete and such cases of packet-loss have to be handled gracefully by the software, as in such cases the rest of the collected time-stamps have to be discarded or re-arranged after a programmed time-out for each set.
  4. Processing the collected time-stamps and running the clock-correction algorithm to correct the DCO (Digitally controlled oscillator)
  5. Switch the hardware to locked, holdover or free-running states.
  6. Provide PTP system management and monitoring interface to the user through CLIs and APIs.

The 1588 Protocol stack is the full suite of message parsers and generators for all the defined message types in the 1588 PTP standard. The clock correction algorithms, on the other hand, only require the extracted time-stamps for processing to calculate the corrections for the Digital Clock Oscillator. Thus these two parts can work as separate threads doing their respective job with dedication and exchanging the necessary information through standard interfaces.

IEEE-1588 protocol suite

IEEE-1588 Software Design and Multi-core



The clock correction algorithm, as we will see further, is a continuous process of arriving at a greater accuracy with the streaming data, so it has to balance the accuracy it can achieve versus the time it may consume. Excess time for a set of data would lead to a back-pressure in the circular queue, leading to over-writing and loss. The protocol suite, on the other hand, is mostly event-driven, such that it only needs to do process a Sync Messages when it arrives and send a Delay Request message. Thus, the processing nature of these two blocks is different. Demand for a higher accuracy means a higher Sync message rate which leads to more events for the protocol suite and faster processing algorithms. Thus, we can map these two processes on two different cores on a multi-core processor. As it is obvious, the two cores would benefit by having their own set of specialized instructions, like the parser-core would benefit from special “move”, “load” etc the corrector-core would benefit from mathematical special instructions like “log”, “average”, “variance” etc. These two cores would need shared memory access with support for semaphores in order to provide arbitration mechanism between parser-core and corrector-core for a common circular queue as well as other data (holdover status, alarms, etc) that needs to be passed between them.

Listen to this article
Listen to
this article
Text to speech by Listencat
Text to speech
by Listencat

AV Chrono

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to top
You cannot copy content of this page