Xilinx Versal: Precise synchronization within a single chip

[Guide]From finance, telecommunications, industry, consumer to aerospace and defense, and automobiles, the concept of “synchronization” is now ubiquitous in all industries. Many applications are completely inseparable from synchronization; this article will discuss some of them and share the concept of synchronization based on these examples.
In addition, the second part of this article will discuss two key technical indicators of synchronization: precision and accuracy and integration. Starting from these two indicators, I will introduce the specific functions of the Versal™ series as an ideal synchronization platform, and help readers understand this revolutionary programmable and adaptive platform that changes the rules of the game from a new and unique perspective.
Sync everywhere
Without synchronization, many applications simply cannot exist. Why do you say that? This paragraph will use two representative examples to support this assertion.
In this article, the terms clock (clock), time, and time of day (TOD) are synonymous.
Specifically, for synchronization, the clock is not a periodic waveform (Figure 1).
Xilinx Versal: Precise synchronization within a single chip
Figure 1-Defining the clock in the synchronization scenario.
In our daily life (Example 1), we often say “see you tomorrow at 2 o’clock in the afternoon”. This simple statement contains numerous assumptions about synchronization:
● It assumes that the people invited to the meeting have the same concept of time. If you are in Central Europe, this sentence assumes that both parties use UTC +1[1]
● UTC time is maintained by the metrology laboratory located in London and is also the time routinely used in the world. Our mobile phone runs a copy of UTC time and periodically synchronizes with UTC in the background to ensure that the two stay in sync.Our computer also performs the same operation[2].
The simple statement “we see you at 2 pm” assumes that there is a complex infrastructure behind it, and we subconsciously refer to it.
Example 2 considers a “significantly” different situation: geolocation via GNSS[3].
The mobile phone receives the time (that is, the clock) from multiple different satellites, and each satellite sends one at the same time. The mobile phone is not at the same distance from all satellites, so it can measure the phase difference between clocks sent by different sources. If the satellite’s position is known a priori, the GNSS receiver can easily recalculate its position.
The above two examples have many similarities: the two parties invited to the conference have the same concept of time, just like the satellite in Example 2. In addition, both parties and the satellite maintain a copy of the public time they/they refer to. They/they do not directly share the same time source because they/they are geographically far away from each other.
Synchronization is a technique that keeps a copy of the local clock (slave time) consistent with a public reference (master time) over time. This is the definition we are looking for.
In the above two examples, any synchronization error will affect the performance of the final application. In the first example, if the invitee’s own clock is slow (for example), he will be late for the meeting.
In the second example, if the satellite’s local clock copy has errors, the GNSS receiver will calculate the wrong position.
Although the two applications have many similarities, there is a fundamental difference between the two, that is, the accuracy required by the application is different. In the first example, if the clock is 1 second slower, no one will complain, because a delay of 1 second is generally tolerable for the meeting. For the GNSS receiver, an error of 1 second will result in the calculation of the wrong position, directly rendering the application useless.
This tells us that although these two applications rely on the same technology (synchronization), the acceptance criteria are completely different. In fact, the acceptance criteria are only related to the application. Although accuracy is one of the most important acceptance criteria, it is by no means the only criterion. Safety, availability, accuracy, integration, etc. are examples of other acceptance criteria.
Before we continue the discussion, it is necessary to briefly introduce the background of UTC. UTC uses atomic clocks to ensure that the time unit of seconds is correctly defined. The rotation of the earth can be used as a time reference, but unfortunately, its accuracy is not good because it changes by a few seconds every year. After a long period of time, accumulated errors may cause UTC to be completely out of sync with Earth time. For example, after many years, it should be noon, but UTC time is night. In order to solve this potential long-term misalignment problem, the London Metrology Laboratory compensates UTC by selectively adding or subtracting 1 second periodically. This is usually done at the end of June and December each year.These corrections are called leap seconds[4].
The time allocated by the Global Positioning System (GPS) uses the same second definition as UTC, but does not use leap seconds. Therefore, at the beginning of 2021, the difference between GPS time and UTC time is 18 seconds. This number will change in the future.
As users, we don’t have to worry about these corrections. Our mobile phones and computers will be synchronized to UTC in the background, even if there are leap seconds, they can be consistent.
In order to propagate UTC at times and places without data coverage, UTC time is also propagated in long waves through the German DCF77 radio station[5].
You may find it quite surprising, but the accuracy of the atomic clock is far better than the rotation of the earth.
Synchronization indicators in Versal
The term synchronization represents a general technology, while the acceptance criteria are strictly related to the application. In the following, I will focus on two specific indicators of Versal Adaptive Computing Acceleration Platform (ACAP):
● Accuracy and precision.
● Integration: The scope of applications generally goes far beyond synchronization. It is the right approach to choose a platform for all the software blocks and hardware blocks required for integration.
Versal has performed well on these two indicators, and I will explain why.
Accuracy and precision
The first question readers may want to know is: accuracy and precision, are they the same thing?
From the perspective of measurement theory, precision and accuracy have different meanings and are independent of each other. We now understand in detail.
If the results obtained by repeatedly measuring the same object are similar to each other (even if incorrect), then this measurement system is “high precision”.
If the average value of the results obtained by repeatedly measuring the same object is correct, this measurement system is “high accuracy”.
To gain a deeper understanding of the above definition, the reader should consider Figure 2. In this system, the position of the object (red dot) is in a two-dimensional space, and we want to measure its position.
I have two instruments (blue and green) that can measure the position of an object. The five blue dots are the measurements made by the blue instrument. The five green dots are the measurements made by the green instrument.
Xilinx Versal: Precise synchronization within a single chip
Figure 2-Accuracy and accuracy comparison.
According to the above definition, green instruments are more accurate than blue instruments, and blue instruments are more accurate than green instruments. It is now easy to understand that accuracy and precision are independent concepts. Readers can easily generate a variety of measurement value sets, which can be neither accurate nor accurate, or both accurate and accurate.
In other words, we can see that as long as the measurement system is accurate, averaging is a good way to improve our knowledge of the location of this object.
If the measurement system is not accurate, calibration is the only solution we can consider.
One of the most important factors that cause the local clock copy of the clock to be inaccurate is the Electronic circuit, especially the FIFO of the transceiver:
● The delay of the transceiver FIFO will change every time it is started
● There are PVT related delays in the transceiver FIFO[6]
The above two factors need to be considered separately because they affect accuracy in different ways.
The first factor directly affects accuracy: if the receiver and transmitter have different start-up delays, the IEEE1588 mechanism will not be able to detect this difference. Any imbalance will directly affect accuracy. Even averaging cannot be alleviated. For the case shown in Figure 3, the reader will notice that the two measured value sets are biased.
Surprisingly, the second factor has no effect on accuracy. In fact, the time delay changes caused by environmental conditions (voltage and temperature) will apply to both receivers and transmitters, and the IEEE1588 mechanism will offset them. Before we continue the discussion, I think we should consider the above statement in more detail.
Does this imply that the time transfer is only performed once after the start? The answer is no.
If we only calibrate it once, despite the symmetry between RX and TX, the delay change will still cause the slave clock error, and this error will continue to accumulate with temperature/power supply drift. The countermeasure for this situation is to resynchronize faster than the temperature/power supply changes.
Let’s review what we have so far: Influencing factor 1 requires us to understand the delays of RX and TX at startup. Influencing factor 2 requires us to resynchronize the slave clock with a fast enough speed over time.
Versal transceivers provide different alternative methods to measure and control time delay, both at startup and during operation. These methods can be divided into the following two types:
Xilinx Versal: Precise synchronization within a single chip
Figure 3-Delay variation between starts.
● Buffer bypass.
● FIFO delay measurement.
Buffer bypass allows bypassing the FIFO in the RX and TX directions. By establishing a precise clock scheme, it can process data across clock domains and avoid timing errors[7],[8][i]. Needless to say, the delay of buffer bypass is minimal. Although this “side effect” may have nothing to do with synchronous applications, it is critical for other industries such as high-frequency trading (HFT).
Buffer bypass can solve the problem by setting the transceiver delay to a fixed value, and another method worth paying attention to is to focus on the delay measurement itself. If the time delay at any given point in time is known, it can be easily reused to mathematically correct the time of day (TOD) value.
This method is meaningful for synchronous applications because it can provide a natural upgrade path for all IPs (Ethernet first) without modifying the clock architecture of the IP itself.
Accuracy is achieved by two types of methods at the same time, because accuracy depends on:
● The hard-coded analog phase detector built into the transceiver and
● User-controlled analog phase interpolator. Users can easily step or retreat the clock phase in picosecond increments.
Although this may seem worthy of attention, how accurate is it? The typical cause of misalignment is the time delay variation between starts, which is caused by the random phase of the frequency divider after reset.
Versal can measure or set the time delay at startup. This initial calibration phase helps to ensure that all sources of misalignment in the transceiver have been removed.
As we mentioned before, the delay change that occurs during operation is symmetrical to RX and TX and can be compensated by the PTP mechanism itself. I think it is necessary to elaborate on this final statement. If PTP can compensate for this type of delay change, what are the advantages of delay measurement over time?
In many cases, the delay change is asymmetric between RX and TX. Readers can consider the case of inherent asymmetric protocols, such as PON[9].
In other cases, the RX path and the TX path can be on different physical devices: this is typical on test equipment. Different devices may have different temperatures, different processes and different power supplies. The combination of all these reasons will cause the delay between RX and TX to evolve over time, leading to inaccuracy.
The above example is just to support the view that the delay between RX and TX does not always change together.
Although many platforms can correctly implement the PTP protocol, the Versal platform allows you to use your professional knowledge and ideas in your work to win this accuracy battle. This is a standard product that helps you turn your ideas into reality.
From the typical nanosecond architecture clock to the picosecond clock provided by the hard-coded analog phase interpolator in Versal, Versal ACAP can be regarded as a revolutionizer in terms of transceiver delay control and delay measurement.
Single chip system
In the previous part, we have learned why Versal excels in accuracy and precision, as well as the key factors when developing synchronization applications.
I hope that readers will now focus on the meaning of “synchronized applications”: any application that uses this feature to transfer TOD between network nodes falls into this category. Needless to say, it depends heavily on the specific user. Under normal circumstances, this requires a processor with proprietary software, computing logic and various interfaces. In most cases, it even requires a high-speed ADC or DAC and/or DSP engine.
Versal is an adaptive computing application platform (ACAP). All the building blocks mentioned above are integrated in the same package on a single chip.
System architects and designers will be able to use their professional knowledge to implement their own applications on a single device. This is the easiest and fastest way to implement your ideas.
This is just a different perspective on Versal ACAP: running on a single chip and accurately synchronizing the complete application.
in conclusion
This article introduces the same revolutionary Versal platform from two perspectives: From one perspective, we understand a complete application running a custom programmable engine equipped with a wire interface and a wireless interface from a macro perspective.
Another angle reveals how each interface provides support for extremely accurate time propagation at the microscopic level.
At the core of the Versal platform is the programmable logic needed to build your own applications.
Accurately synchronize the complete application on a single device.
About the Author
Paolo is Xilinx’s chief engineer, responsible for providing technical support to strategic customers in Europe, the Middle East, and Africa. His main research areas include burst data recovery circuits, network timing synchronization, over-sampling technology and low-latency transmission architecture. He is a member of the Steering Committee of the International Time and Synchronization Forum (ITSF).
Paolo obtained a master’s degree in microelectronics from the Politecnico di Milano and holds 19 authorized patents.
[1]Coordinated Universal Time (UTC). UTC is based on the average of multiple atomic clocks around the world.
[2]By using Network Time Protocol (NTP)
[3]Global Navigation Satellite System. The most well-known example of GNSS is the GPS owned by the United States. In addition, there are now Galileo (owned by the European Union), GLONASS (owned by Russia) and Beidou (owned by China), which are just a few of the most famous navigation satellite systems. All modern GNSS receivers in our mobile phones can use multiple GNSS systems to improve operation accuracy.
[4]For more information, please refer to https://en.wikipedia.org/wiki/Leap_second. This page not only provides all the leap seconds used since 1972, but also introduces this method.
[5]For further information, please refer to: https://en.wikipedia.org/wiki/DCF77
[6]PVT refers to power consumption, voltage and temperature.
[7]UltraScale Architecture GTY Transceiver User Guide
[8]”White paper “Xilinx: The Best Platform for PTP Accuracy” https://www.xilinx.com/support/documentation/white_papers/wp524-1588-platform.pdf
[9]For more information, please visit: https://en.wikipedia.org/wiki/Passive_optical_network

The Links:   LP150X10-A3 LM150X06

Bookmark the permalink.

Comments are closed.