Chapter 4 Testbed
4.5 Hardware Acquisition of Labeled Data
cates that the arithmetic syntonization is working sufficiently well, such that, in the course of a second, the RTC’s time count does not drift substantially. Ultimately, with the timestamping uncertainty and the syntonization error, the synchronization error remains mostly within±4ns.
An important parameter of the input PPS signal concerns its rise time, i.e., how fast its voltage changes from low to high. The adopted PPS signal has a rise time of nearly 9.42ns, according to measurements from the oscilloscope (shown in Fig. 4.3) running at20Gsps. This rise time is larger than the timestamp granularity of8ns. Thus, occasionally, the PPS detection can slip by one cycle. This phenomenon contributes to the overall uncertainty.
Lastly, note the given acquisition experiences two different temperature stability scenar- ios. It started around 7 PM and ran overnight, with nobody in the lab environment and air conditioning turned off (soon after its start). Around13 hours later, the air conditioning was turned back on, and co-workers started to arrive at the lab. From this point onward, the tem- perature fluctuations became higher, as confirmed by the frequency offset estimations shown in Fig. 4.6c. Notably, the time offset remained under the expected range despite the change of conditions after13h, although with higher variance, as shown in the scatter plot of Fig. 4.6d.
In the end, it can be stated that the PPS RTC synchronizes to the reference clock with an accuracy in the range of±1/fnom, namely±8ns. With the OCXO, this is a conservative spec- ification, as the observed accuracy is expected to be better. For example, the given experiment shows a time offset mostly within±4ns. Meanwhile, when the XO drives the PPS RTC, an ac- curacy within±8ns has been observed99.8% of the time. Ultimately, this accuracy determines the uncertainty associated with the dataset labels, described next.
Table 4.1:Example dataset entry corresponding to a PTP message exchange.
n t1[n] t2[n] t3[n] t4[n] t02[n] t03[n]
timestamps from its PPS RTC. As shown in Fig. 2.2, the two timestamps that are normally taken on the slave side aret2[n]andt3[n]. Correspondingly, the slave takes timestampst02[n]andt03[n]
from the PPS RTC at the exact clock cycle when it takest2[n]andt3[n]from the PTP RTC. In the end, then-th dataset entry contains the information in Table 4.1.
With the additional timestamps from the PPS RTC,t02[n]andt03[n], it becomes possible to compute the ground truth as follows:
´
x[n] =t2[n]−t02[n] (4.2) d´ms[n] =t02[n]−t1[n] (4.3) d´sm[n] =t4[n]−t03[n], (4.4) where x[n]´ represents the true slave time offset relative to the master, d´ms[n] represents the true m-to-s delay, andd´sm[n] represents the true s-to-m delay. The rationale is that the PPS RTC accurately represents the master time (because it is accurately synchronized). Thus, for example,t2[n]−t02[n]represents the difference between the slave timet2[n]upon the arrival of then-th PTP message (according to the PTP RTC) and the master timet02[n](according to the PPS RTC) precisely when the PTP arrival timestamp is taken. The error associated with such labels is the PPS synchronization error, which, as mentioned in Section 4.4.3.2, is up to±8ns.
The noteworthy aspect of this implementation is that there is no uncertainty on the match- ing between the timestamps from the PTP RTC (e.g.,t2[n]) and the PPS RTC (e.g.,t02[n]). The developed hardware drives the two RTCs using the same clock signal, as illustrated in Fig. 4.7.
Hence, the two RTCs reside in the same clock domain, and there is no need for clock domain crossing (CDC) circuitry between them. This choice avoids CDC timing uncertainties [132]
and, ultimately, allows the sampling of the two RTCs precisely at the same clock cycle.
Nevertheless, the actual timestamp matching mechanism is more intricate than merely sampling the two RTCs simultaneously. The EMAC is the only block capable of detecting a PTP event message arrival or departure. Hence, only the EMAC knows when to request a timestamp from the PTP RTC, and its IP (see [127, 128]) does not expose this timestamping trigger as an output signal to be used by external logic. Thus, there is no trigger signal in HW
Ethernet MAC
PTP RTC Timestamp
Collector
PPS RTC PPS In
PTP
Messages sec
ns
sec ns 125 MHz Driving
Clock Signal
~
Figure 4.7:Hardware used to collect PTP and PPS timestamps simultaneously.
Master Time
Slave’s PTP RTC Time Sync
SW-driven Snapshot Slave’s PPS
RTC Time
t1
t2
tr t′r
t′2
∆r ∆′r
Figure 4.8: Procedure used to match a PTP timestamp to the corresponding time at the PPS RTC.
to request a timestamp from the PPS RTC simultaneously with the PTP RTC.
Instead, the adopted timestamp matching mechanism relies on the Timestamp Collector HW block shown in Fig 4.7, which can take simultaneous snapshots of the two RTCs if re- quested by software. The procedure starts once the PTP event message’s arrival or departure is recognized in the SW stack. For reference, Fig. 4.8 illustrates the case of timestampt2[n], taken upon the Sync message’s arrival. Once the Sync arrival is recognized, the SW requests si- multaneous snapshots of the RTCs. The Timestamp Collector then returns the pair of reference timestampstr[n]andt0r[n], the former from the PTP RTC and the latter from the PPS RTC.
From the Sync arrival instant t2[n] to the SW-triggered reference timestamp tr[n], the PTP RTC advances by∆r[n]. The slave can compute this interval, and, more importantly, the corresponding number of clock cycles elapsed during the interval, as follows:
ncycles[n] = ∆r[n]
Tinc,ptp[n] = tr[n]−t2[n]
Tinc,ptp[n] , (4.5)
whereTinc,ptp[n]represents the PTP RTC’s increment value during thisn-th PTP exchange.
Next, because the same clock signal drives both the PTP and PPS RTCs, the two RTCs
experience exactly the same number of clock cycles over interval∆r[n]. Hence, it is possible to map interval∆r[n]to the corresponding time interval according to the PPS RTC, as follows:
∆0r[n] =ncycles[n]·Tinc,pps[n], (4.6) whereTinc,pps[n]represents the increment value of the PPS RTC.
Finally,t02[n]can be obtained as follows:
t02[n] =t0r[n]−∆0r[n]. (4.7) Note that this computation only works if the increment valuesTinc,ptp[n]and Tinc,pps[n]do not change during the whole process, which is guaranteed in the adopted implementation.
The implemented slave clock runs the referred timestamp matching procedure for every PTP timestamp taken locally (i.e.,t2[n]andt3[n]). With that, it continuously generates dataset entries in the format described in Table 4.1. After collecting each set of six timestamps, the slave serializes the set to a host PC through a universal asynchronous receiver-transmitter (UART) interface. Ultimately, the PC collects all sets of timestamps on a dataset (i.e., a file), which is cataloged with the relevant metadata (experimental configurations) and stored on a database.
Later on, these datasets are used for offline analysis.
As a final remark, note that the unique capabilities of the referred acquisition process stem from two main factors. The first is the slave’s ability to sample the time held by the PPS RTC at the exact clock cycle when the PTP RTC is sampled upon a message arrival or departure. As emphasized above, this is only possible because the two RTCs are in the same hardware and, more importantly, in the same clock domain. Meanwhile, the second factor is that the PPS RTC synchronizes independently and very accurately to the master clock. Hence, it serves as a proxy of the reference time within the slave hardware.
Both of these factors are enabled by using an FPGA-based implementation. In contrast, it would be more complex to accomplish the same results (or the same uncertainty level) using, e.g., commercial PTP clocks or a software-based implementation with PTP-capable network interface cards (NICs). For example, using Linux’s PTP hardware clock infrastructure [133], it becomes possible to convey timestamps taken in hardware by a compatible NIC up to user- space applications. Furthermore, some low-cost NICs such as the Intel i210 provide PPS input and output [137]. Nevertheless, there is no inherent mechanism to match a PTP timestamp with the corresponding time at the reference (or master) clock exactly when the PTP timestamping
occurs. Consequently, it becomes infeasible to obtain low-uncertainty labels regarding the true packet delay and time offset affecting each PTP packet ([64] demonstrates a similar problem).
Besides, the adopted FPGA design provides other essential features. For instance, it sup- ports the easy switching of the oscillator (between XO and OCXO) used on an acquisition, accomplished by simply reprogramming the FPGA’s bitstream. This feature would not be fea- sible using typical commercial PTP hardware (typically based on a single oscillator).