Skip to content

W
White Rabbit Standardization
Commit 54df63f8 authored by Maciej Lipinski's avatar Maciej Lipinski
Browse files
Options

WRSPEC: update

parent 0d2c075e
Hide whitespace changes
Inline Side-by-side
Showing with 631676 additions and 595740 deletions
src/fig/clocksHwSpec.ps 0 → 100644
View file @ 54df63f8
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/modifiedPtpFSM.ps
View file @ 54df63f8
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpAndWrFSMs.ps
View file @ 54df63f8
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/src/PTP_FSM.cdr
View file @ 54df63f8
No preview for this file type
src/fig/src/PTPmsgs.cdr
View file @ 54df63f8
No preview for this file type
src/fig/src/wrFSM.cdr
View file @ 54df63f8
No preview for this file type
src/fig/wrFSM.ps
View file @ 54df63f8
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/wrMSGsExchangeFlow.ps
View file @ 54df63f8
This source diff could not be displayed because it is too large. You can view the blob instead.
src/from_tomeks_msc.tex 0 → 100644
View file @ 54df63f8
\subsection{Coarse delay measurement}
\label{s:coarse_delay}
The coarse delay measurement produces a set of timestamps $t_{1} ... t_{4}$
which are obtained using the PTP End-to-End, two-way clock method as shown
in fig. \ref{fig:ptp_exchange}. The timestamps are generated in the hardware
with a circuit depicted in fig. \ref{fig:coarse_measurement}, guaranteeing
single-cycle timestamping accuracy, which is necessary for reliably merging the
coarse delay with the $phase_{MM}$ phase shift during fine delay calculation.
\begin{figure}[htb]
\centering
\includegraphics[width=17cm]{Tomeksdrawings/coarse_measurement.eps}
\caption{Structure of a WR timestamping unit (TSU)}
\label{fig:coarse_measurement}
\end{figure}
Timestamps in WR are taken when the PCS detects a Start-of-Frame Delimiter
(SFD) character in the incoming (RX timestamps) or outgoing (TX timestamps)
data stream (see \ref{s:ether_pcs}).
Let's first focus on the blocks marked blue in
fig. \ref{fig:coarse_measurement}. Each time an SFD character is detected,
the PCS produces a timestamp trigger pulse which causes the timestaming unit
to take a snapshot of the free running counter CNTR\us R with the D-type
register DREG\us R. The counter is counting from 0 to 124999999 which (given
the reference clock frequency of 125 MHz) gives a period of one full second.
The counter CNTR\us R works synchronously to the reference clock (master side,
signal 1 in fig. \ref{fig:link_model}) or the compensated clock (slave side,
signal 5). Since RX trigger pulses come from different clock domains (2 or
4), they need to be synchronized to the reference clock with a chain of
D flip-flops (SYNC). Single-cycle long trigger pulses are widened by the
pulse extender before going to the synchronizer chain to ensure that no
pulses are missed due to the metastability of synchronizer flip-flops. The
counter value is latched in register DREG\us R on the rising edge of the
synchronizer output. TX timestamp triggers, which are generated within the
reference clock domain (clocks 1 or 5) also pass through a synchronizer
chain to obtain identical trigger reaction latency.
Unfortunately, due to the jitter of clock signals, crossing clock domains
can make the gathered timestamps useless by causing a random $\pm 1$ LSB
error when the RX clock and the reference clocks are almost in phase. The
problem is illustrated in figure \ref{fig:ts_jitter} Dashed lines show
the transitions of ideal (jitter-free) clocks. If the jitter is neglected,
the reference clock transition should be slightly ahead of the RX clock
transition and the gathered timestamp should be equal to 2. However, if the
clocks are jittery, the transitions may sometimes occur in reverse order,
producing an erroneous timestamp of value 1.
\begin{figure}[htb]
\centering
\includegraphics[width=10cm]{drawings/ts_jitter.pdf}
\caption{Timestamping errors caused by clock jitter}
\label{fig:ts_jitter}
\end{figure}
One possible way of addressing this issue is to take RX timestamps on both
reference clock edges. The falling edge part of the TSU is marked pink in
\ref{fig:coarse_measurement}. It does not have an independent counter --
instead, the current value of the rising edge counter is latched in register
CNTR\us F on the falling edge of the reference clock, making the CNTR\us
F a copy of CNTR\us R delayed by a half of the clock period. This method
ensures that at least one of the timestamps is valid at any moment (see
\ref{fig:ts_dualedge}). The correct timestamp is chosen depending on the
current phase shift between clocks (see section \ref{s:fine_delay}).
\begin{figure}[htb]
\centering
\includegraphics[width=12cm]{drawings/ts_dualedge.pdf}
\caption{Dual-edge timestamping in WR}
\label{fig:ts_dualedge}
\end{figure}
In order to simplify the hardware design, the presented TSU can only measure
the sub-second part of PTP timestamps. The UTC part is appended in the
software using the algorithm shown in listing \ref{lst:utc_gen}.
\begin{lstlisting}[caption=Producing UTC timestamps,label=lst:utc_gen]
timestamp tstamp = get_hardware_timestamp();
time t = get_utc_time();
// check if there was a transition of the UTC counter between the
// generation of the timestamp and its readout by the software
if(t.milliseconds < tstamp.rising_edge)
tstamp.seconds = t.seconds - 1;
else
tstamp.seconds = t.seconds;
\end{lstlisting}
\subsection{Digital DMTD phase detector}
\label{s:dmtd}
The fine delay measurements in WR are based on a Dual Mixer Time Difference
(DMTD) phase detector. Therefore, in this section a short introduction to
DMTD technology will be presented.
\begin{figure}[htb]
\centering
\includegraphics[width=11cm]{drawings/analog_dmtd.pdf}
\caption{Structure of an analog DMTD phase detector}
\label{fig:analog_dmtd}
\end{figure}
Figure \ref{fig:analog_dmtd} shows an analog DMTD system \cite{allan90}. Let's
assume that its input clocks $a(t)$ and $b(t)$ have identical amplitudes and
frequencies equal to $f_{clk}$. The phases of both clocks are respectively
$\phi_{a}$ and $\phi_{b}$. The clocks are multiplied by the mixers with
the signal $c(t)$ of frequency $f_{offset}$ and phase $\phi_{offset}$. The
multiplication result can be expressed as:
\begin{eqnarray}
a(t) \cdot c(t) & = & cos(2\pi t f_{clk} + \phi_{a}) \cdot cos (2\pi t
f_{offset} + \phi_{offset}) \nonumber \\
\label{eq:mixing1}& = & \frac{1}{2} cos(2\pi t (f_{clk} + f_{offset}) +
\phi_a + \phi_{offset}) \\
\label{eq:mixing2}& + & \frac{1}{2} cos (2 \pi t (f_{clk} - f_{offset}) +
\phi_a - \phi_{offset})
\end{eqnarray}
Term \ref{eq:mixing1} has higher frequency than the multiplied signals and
it's removed by the low-pass filter, leaving only the low-frequency term
\ref{eq:mixing2}. The downconversion process changes the frequency of the
signals, but does not change their phase difference. Therefore, if the offset
frequency $f_{offset}$ is close to the input signal frequency $f_{clk}$,
the phase shift can be measured by counting the time between the rising
edges of the downconverted clocks. For example, a reference clock of 125
MHz and an offset clock of 124.99 MHz will produce an output signal of 10
kHz. At such frequencies, the phase shift can be very accurately measured
using a simple counter.
Analog DMTDs provide excellent resolution and linearity, at the cost of several
external discrete components (mixers and filters), which can be troublesome,
especially in multi-port applications such as the WR switch. Fortunately, the
analog mixing operation can be transformed into a digital sampling operation,
resulting in a digital DMTD detector, shown on fig. \ref{fig:digital_dmtd}
\begin{figure}[htb]
\centering
\includegraphics[width=12cm]{drawings/digital_dmtd.pdf}
\caption{Structure of a digital DMTD phase detector}
\label{fig:digital_dmtd}
\end{figure}
In a Digital DMTD (DDMTD) \cite{icalepcs09}, the input signals are square
waves, the mixers are replaced with simple D-type flip-flops and the offset
clock is generated with a PLL from one of the input clocks. The sampling
operation performed by the flip-flops can be mathematically proved to be
equivalent to analog mixing (\ref{eq:mixing2}), but the principle of a DDMTD
can be explained in a more intuitive way.
\begin{figure}[htb]
\centering
\includegraphics[width=15cm]{drawings/dmtd_vernier.pdf}
\caption{A vernier (a) and signals generated by DDMTD (b)}
\label{fig:dmtd_vernier}
\end{figure}
Figure \ref{fig:dmtd_vernier}a shows a vernier caliper. It has two scales -
the big millimeter scale and a small vernier scale, with the units slightly
smaller than the main scale. For a typical caliper, the vernier scale is split
into 10 intervals with 4.9 mm spacing. If the length of the measured object
has a fractional part, one of bars on the vernier scale will be in line with
one of bars from the main scale. Translating to the language of electronics,
the main scale is the input clock where each interval represents one cycle,
the vernier scale is the offset clock and the transitions in the DDMTD output
signals occur when bars on both scales are aligned. An example of signals
produced by a DDMTD with $N = 8$ is shown in fig. \ref{fig:dmtd_vernier}b. The
output phase shift is proportional to the input phase shift $\phi$ by a
factor of $(N+1)$. A general relation between the phase shift and the cycle
interval between the DMTD outputs can be expressed as:
\begin{equation}
\label{eq:dmtd1}
\phi \mbox{[ns]} = \frac{n_{cycles}}{N+1} \cdot \frac{1}{f_{in}}
\end{equation}
Digital DMTDs have all the advantages of their analog counterparts while
requiring only one external component (the oscillator producing the offset
clock) which is shared among all measurement channels. This opens the way
for low-cost FPGA implementations. If a picosecond-level accuracy is not
required, even a PLL integrated inside an FPGA can be used, eliminating all
external components.
\begin{figure}[htb]
\centering
\includegraphics[width=8cm]{drawings/dmtd_glitches.png}
\caption{Glitches in the DMTD output caused by clock jitter}
\label{fig:dmtd_glitches}
\end{figure}
In practical DDMTD implementations, the output signals need to be additionally
conditioned as the input clock jitter can introduce glitches, as shown
on fig. \ref{fig:dmtd_glitches}a. More details about the deglitching and
postprocessing algorithm can be found in section \ref{s:ddmtd_impl}.
\subsection{Fine delay measurement}
\label{s:fine_delay}
Having the knowledge of PTP timestamps and round-trip phase shift $phase_{MM}$,
we can calculate the precise round-trip delay $delay_{MM}$. The calculation
is performed in two steps:
\begin{itemize}
\item The accuracy of PTP timestamps $t_{2}$ and $t_{4}$ is enhanced beyond a
single clock cycle using the knowledge of the round-trip phase $phase_{MM}$
and the slave PLL setpoint $phase_{S}$. As a result, precise timestamps
$t_{2p}$ and $t_{4p}$ are obtained.
\item The fine round-trip delay is calculated using the standard PTP formula:
\begin{equation}
\label{eq:ptp_precise}
delay_{MM} = (t_{4p} - t_{1}) - (t_{3} - t_{2p})
\end{equation}
\end{itemize}
Only the reception timestamps need to be enhanced, as they are generated
within clock domains asynchronous to the reference (or compensated) clock
(see table \ref{tab:ts_domains}). Transmission timestamps are always integer
because packets are transmitted and timestamped using the same clock.
The flow graph of the algorithm used to merge PTP timestamps with
phase measurements is shown on fig. \ref{fig:merging_timestamps}. Figure
\ref{fig:merging_example} depicts sample measurements of inputs and results
of the enhancement algorithm for $t_{4p}$ timestamps, where the varying link
delay was simulated using the slave's phase shifter.
\begin{table}[htb]
\caption{Timestamping clock domains}
\centering
\begin{tabular}{|c|c|c|c|c|} \hline
Timestamp & Origin & Trigger clock & Timestamping clock & Correction \\
\hline \hline
$t_{1}$ & Master TX & reference (1) & reference (1) & 0 \\ \hline
$t_{2p}$ & Slave RX & slave recovered (2) & compensated (3) & $-phase_{S}$
\\ \hline
$t_{3}$ & Slave TX & compensated (3) & compensated (3) & 0 \\ \hline
$t_{4p}$ & Master RX & master recovered (4) & reference (1) & $+phase_{S}$
\\ \hline
\end{tabular}
\label{tab:ts_domains}
\end{table}
\begin{figure}[htb]
\centering
\includegraphics[width=13cm]{drawings/merging_timestamps.pdf}
\caption{Algorithm for enhancing coarse timestamps with DMTD phase.}
\label{fig:merging_timestamps}
\end{figure}
The first step of the algorithm addresses the problem of glitches in
RX timestamps, by choosing either the rising or falling edge timestamp
depending on the phase between the RX clock and the reference clock. The
key parameter of this step, $\phi_{trans}$ provides an approximate
value of $phase_{MM}$ at which a transition should occur in the value of
$t_{4r}$. In fig. \ref{fig:merging_example}, it is equal to 6.6 ns - it's
the approximate intersection point of $phase_{MM}$ (blue, sawtooth-like
trace) and the transition of the rising edge timestamp (red trace). The
value of $\phi_{trans}$ is a device-specific constant. It can be determined
once during the factory calibration of a WR device or measured upon every
startup by sweeping a full clock period using the built-in phase shifter
and searching for a transition in the RX timestamp value.
If the actual value of $phase_{MM}$ lies within a $\pm 25\% T_{ref}$
range from the transition point $\phi_{trans}$ (green zone in
\ref{fig:merging_example}), the algorithm will use $t_{4f}$ timestamp,
otherwise $t_{4r}$ timestamp will be taken (red zone). Note that because
$phase_{MM}$ is bounded to $\left[0, T_{ref}\right)$, the range checks must
be aware of the jump in the phase between $T_{ref}$ and $0$.
The second step checks if the $phase_{MM}$ value is ahead of the transition
point $\phi_{trans}$, and eventually increases the chosen timestamp by a full
cycle ($T_{ref}$). That ensures the transition in $t_{4}$ will always occur
when $phase_{MM} = \phi_{trans}$, eliminating the risk of transition glitches.
The last part of the algorithm simply adds the picosecond part (which is
the DMTD phase corrected with the transition offset $\phi_{trans}$) to
the coarse deglitched timestamp $t_{4}$. If the resulting picosecond part
($\phi$) is negative, an additional full cycle is added to the result. The
final output of the merging algorithm is shown in \ref{fig:merging_example}
as the thick navy trace.
\begin{figure}[htb]
\centering
\includegraphics[width=12cm]{drawings/merging_example.pdf}
\caption{Example of $t_{4p}$ timestamp enhancing.}
\label{fig:merging_example}
\end{figure}
The enhancement operation for $t_{2}$ timestamp is done in a very
similar way by replacing $t_{4}$ with $t_{2}$ and $phase_{MM}$ with
$phase_{S}$. Note that changing the slave's phase shift $phase_{S}$ will
result in a change of the values of both $t_{2p}$ and $t_{4p}$ (see table
\ref{tab:ts_domains}). Increasing $phase_{S}$ by a certain $\delta$ will
cause $t_{4p}$ to also increase by $\delta$ (assuming that the link delay
stays constant). Simultaneously, the value of $t_{2p}$ will be decreased by
the same amount, as for the slave's RX timestamps, the timestamping clock is
$phase_{S}$ ahead of the trigger clock (so if the phase shift is increased,
the timestamp value goes down). Therefore, the calculated fine delay is not
affected by the changes of $phase_{S}$:
\begin{equation}
\label{eq:ptp_precise2}
delay_{MM} = (t_{4p} - t_{1}) - (t_{3} - t_{2p}) = t_{4p} \cancel{+ phase_{S}}
- t_{1} - t_{3} + t_{2p} \cancel{-phase_{S}}
\end{equation}
\subsection{Link asymmetry estimation}
\label{s:asymmetry}
In order to compute an accurate master-slave offset, one must determine the
asymmetry of the link delay. This asymmetry cannot be measured directly (as
a difference between the overall M-S and S-M delays), as it would require
the nodes to be synchronized prior to the measurement. Therefore it is
only possible to estimate the asymmetry from round-trip delay $delay_{MM}$,
using the knowledge of the properties of the components constituting the link.
In the WR optical link model, the following sources of asymmetry were taken
into consideration:
\begin {itemize}
\item Propagation delays of electronic components and PCB traces (circuit
asymmetry),
\item Asymmetry of optical transceivers (SFPs),
\item Difference between TX and RX wavelengths in the fiber,
\item Internal structure and clocking of the PHY (SerDes) chips.
\end{itemize}
\begin{figure}[htb]
\centering
\includegraphics[width=\textwidth]{drawings/asymmetries.pdf}
\caption{Delay asymmetries in WR optical link.}
\label{fig:asymmetries}
\end{figure}
Figure \ref{fig:asymmetries} shows the reference asymmetry model used in WR
devices. The device's asymmetric delays (as shown in fig. \ref{fig:link_model})
are expressed as sums of circuit, SFP and PHY delays between the phase detector
inputs (the PD measuring $delta_{MM}$ on the master side and the PD in the
phase shifting PLL on the slave side) and the SFP optical input/output. The
fiber asymmetry is compensated separately in the slave's PTP servo.
\begin{eqnarray}
\Delta_{tx(m/s))} = \delta_{TX\us PHY(M/S)} + \delta_{TX\us CIR(M/S)} +
\delta_{TX\us SFP(M/S)}
\\
\Delta_{rx(m/s)} = \delta_{RX\us PHY(M/S)} + \delta_{RX\us CIR(M/S)} +
\delta_{RX\us SFP(M/S)} \nonumber
\label{eq:asym_delay}
\end{eqnarray}\\
\subsubsection{Circuit and SFP asymmetry}
Circuit asymmetry stems from differing PCB trace lengths, propagation delays
of the electronic components of the clock distribution system and FPGA logic
cell placement and routing delays. SFP asymmetry is a result of different
reception and transmit delays between the electrical and optical ports of
the SFP transceiver.
These asymmetries can vary with changes of the device's operating conditions
(i.e. temperature, supply voltage). Depending on the synchronization accuracy
requirements, they can be:
\begin{itemize}
\item Treated as time-invariant and measured once during factory setup.
\item Actively compensated, following the changes in temperature and/or supply
voltage read from built-in sensors (requires a model of delay vs. temperature
and voltage),
\item Eliminated by building a system where both master and slave have
identical (or zero) asymmetry and operate in similar conditions.
\end{itemize}
The last method is particularly useful for compensating the delays inside
the FPGA on the way between the PHY (oscillator) and the phase detector,
as they cannot be externally measured during the factory calibration
process. They are also significantly affected by temperature and voltage
changes. Therefore, the only practical way of dealing with the FPGA part
of the circuit asymmetry is to equalize the delays on all phase detector
inputs. This can be done by constraining the routing delays or manually
placing and routing the phase detector block. This approach also allows for
reducing the impact of the temperature-voltage changes on the asymmetry to
a negligible value, as two equal paths placed next to each other would have
very similar temperature/voltage delay coefficients.
SFP asymmetries can be compensated in a similar manner by choosing pairs
of SFP transceivers whose TX and RX delays differ by similar values
(i.e. $\delta_{TX\us SFPM} - \delta_{RX\us SFPM} = \delta_{TX\us SFPS} -
\delta_{RX\us SFPS}$). This can be done in a laboratory system where all
other asymmetric delays are already compensated by selecting SFPs that
together give minimum clock offset.
\subsubsection{WDM fiber asymmetry}
\label{s:wdm_asymmetry}
As mentioned in section \ref{s:physical_layer}, WR uses different wavelengths
for transmitting and receiving the data (for example 1550/1310 nm). Due
to chromatic dispersion of the fiber, the refractive indexes for these
wavelengths are slightly different, causing different propagation speeds
(and thus, different delays) between the master and the slave.
The refractive index at a given wavelength can be derived using Sellmeier's
equation \cite{saleh07} (\ref{eq:sellmeier}):
\begin{equation}
\label{eq:sellmeier}
n^2(\lambda) = 1 + \frac{B_{1} \lambda^2}{\lambda^2 - C_{1}} + \frac{B_{2}
\lambda^2}{\lambda^2 - C_{2}} + \frac{B_{3} \lambda^2}{\lambda^2 - C_{3}}
\end{equation}
where $B_{i}$ and $C_{i}$ are material-specific coefficients.
For a standard G.652 telecom fiber, the refractive indexes are respectively:
$n_{1550} = 1.467$ and $n_{1310} = 1.466$. In order to simplify the asymmetry
calculations in the hardware, the WR specification \cite{wr_spec} defines
a custom fiber asymmetry coefficient \ref{eq:fiber_alpha1} expressing the
ratio between the M-S and S-M fiber propagation delays:
\begin{equation}
\label{eq:fiber_alpha1}
\alpha = \frac{\delta_{ms}}{\delta_{sm}} - 1 = \frac{n_{1550}}{n_{1310}} - 1
\end{equation}
Unfortunately, refractive indexes may vary slightly between different fiber
manufacturers, making the direct calculation of $\alpha$ unreliable. WR
can solve this problem by characterizing the fiber asymmetry using
laboratory measurements of $delay_{MM}$ (done by PTP) and clock offset
$offset_{MS}$ (done using an oscilloscope). The measurements are performed
when all the other asymmetries are already compensated. The value of
$\alpha$ \ref{eq:fiber_alpha3} is calculated by solving equation system
\ref{eq:fiber_alpha2}:
\begin{equation}
\label{eq:fiber_alpha2}
\begin{cases}
delay_{MM} = \delta_{ms} + \delta_{sm} + \Delta \\
offset_{MS} = \frac{\delta_{ms} - \delta_{sm}}{2}
\end{cases}
\end{equation}
where $\Delta$ accounts for all fixed delays in the path (i.e. $\Delta_{txm}
+ \Delta_{rxs} + \Delta_{txs} + \Delta_{rxm}$). Substitution of $\delta_{ms}$
and $\delta_{sm}$ with the results of \ref{eq:fiber_alpha2} gives the final
value of $\alpha$:
\begin{equation}
\label{eq:fiber_alpha3}
\alpha = \frac{delay_{MM} - \Delta + 2\cdot offset_{MS}}{delay_{MM} -
\Delta - 2\cdot offset_{MS}}
\end{equation}
\subsubsection{Transceiver asymmetry}
\label{s:xcvr_asymmetry}
Transceiver asymmetry is a result of the internal structure of the SerDes's
circuitry. Most of the SerDes chips nowadays are optimized for low power
consumption and fast locking to the incoming data stream. Unfortunately,
because of these optimizations, PHYs may not keep constant transmit/receive
latencies. The problem is illustrated in fig. \ref{fig:phy_asymmetry}.
\begin{figure}[htb]
\centering
\includegraphics[width=11cm]{drawings/phy_asymmetry.pdf}
\caption{Random delays in gigabit SerDes devices (a) and blocks causing them
(b).}
\label{fig:phy_asymmetry}
\end{figure}
PHY asymmetry manifests itself as a random latency between the rising edge of
the TX/RX clock and the inter-symbol boundary in the transmitted (received)
serial data stream. In most PHYs, this latency can be different for each
PLL/CDR lock cycle, but once the PHY is locked, the delays shall remain
constant. PHYs whose TX/RX delays can change when the link is active are
unsuitable for WR devices.
In the PHYs which have been evaluated for usability in WR hardware (TLK1221
from Texas Instruments and Virtex-6/Spartan-6 GTP transceivers), the following
random delays were identified:
\begin{itemize}
\item RX alignment latency, observed in PHYs which do not correct the RX
clock phase when aligning to the inter-symbol boundary (red, observed for
Xilinx GTP),
\item RX latency resulting from the internal structure of the digital
oversampling CDR (green, observed for TLK1221),
\item TX latency caused by the clock divider between the internal PLL and
the parallel-to-serial register (blue, observed for TLK1221).
\end{itemize}
Alignment latency can be measured every time the link goes up by disabling
automatic comma alignment and bit-shifting the unaligned output data
until a valid 8B10B code sequence is detected (\textit{bitslip trick},
see \cite{jansweijer}). Compensation of the latter two latencies, however,
requires additional calibration logic. An example method (used in the WR
switch) is shown in fig. \ref{fig:phy_latency_measurement}.
\begin{figure}[htb]
\centering
\includegraphics[width=\textwidth]{drawings/phy_latency_measurement.pdf}
\caption{PHY latency measurement using calibration patterns.}
\label{fig:phy_latency_measurement}
\end{figure}
The PHY transmit path is fed with a sequence of K28.5 characters (1111100000),
effectively producing a 125 MHz square wave on the serial outputs. The phase
shift between the TX clock and the output bitstream can be measured using
a DDMTD phase detector, giving the value of the TX latency. The same method
can be used to measure the RX latency by commanding the link partner to send
the calibration pattern. Note that since the K28.5 character contains a comma
(5 consecutive ones), a burst of subsequent K28.5 symbols will cause improper
operation of the PHY's comma alignment unit. Therefore, comma alignment must
be disabled during the calibration process.
\subsection{Establishing and maintaining synchronization}
\label{s:estab_sync}
Having obtained the values of round-trip delay $delay_{MM}$ and link asymmetry,
we can calculate the one-way master to slave delay $delay_{MS}$ by solving
equation (\ref{eq:delaymm_full}):
\begin{equation}
delay_{MM} = \Delta + \delta_{ms} + \delta_{sm}
\label{eq:delaymm_full}
\end{equation}
where $\Delta = \Delta_{txm} + \Delta_{rxs} + \Delta_{txs} +
\Delta_{rxm}$. Substituting $\delta_{sm}$ with \ref{eq:fiber_alpha1}
and solving for $\delta_{ms}$, we obtain the one-way fiber delay
\ref{eq:delaymm_full_2}:
\begin{equation}
\delta_{ms} = \frac{1+\alpha}{2+\alpha} (delay_{MM} - \Delta)
\label{eq:delaymm_full_2}
\end{equation}
which after adding the circuit, SFP and PHY asymmetric delays present on the
master to slave path gives the final master-slave delay \ref{eq:delaymm_full_3}
and offset \ref{eq:offset_ms}:
\begin{eqnarray}
\label{eq:delaymm_full_3}delay_{MS} & = & \frac{1+\alpha}{2+\alpha} (delay_{MM}
- \Delta) + \Delta_{txm} + \Delta_{rxs} \\
\label{eq:offset_ms} offset_{MS} & = & t_{1} - t_{2p} - delay_{MS}
\end{eqnarray}
The value of $offset_{MS}$ is the input for the slave's offset adjustment
algorithm which controls the slave's clock servo. The flow diagram of the
algorithm is shown in fig. \ref{fig:adjustment_and_servo}a and an example
servo design can be found in fig. \ref{fig:adjustment_and_servo}b. The
algorithm assumes that the frequency has been already syntonized by means
of Sync-E and only the clock offset needs to be corrected. Offset correction
is split into 3 steps:
\begin{figure}[htb]
\centering
\includegraphics[width=\textwidth]{drawings/adjustment_and_servo.pdf}
\caption{WR slave offset adjustment (a) and clock servo (b)}
\label{fig:adjustment_and_servo}
\end{figure}
\begin{enumerate}
\item \textbf{UTC time adjustment}: the UTC counter in the servo is
increased (or decreased) by the number of full seconds \ref{eq:corr_utc}
in $offset_{MS}$:
\begin{equation}
corr_{utc} = \lfloor{\frac{offset_{MS}}{1 \mathrm{~s}}}\rfloor
\label{eq:corr_utc}
\end{equation}
\item \textbf{Clock cycle counter adjustment}: The reference clock cycle
counter, which produces the PPS signal is adjusted by the number of full
$T_{ref}$ (8 ns) cycles \ref{eq:corr_cnt}.
\begin{equation}
corr_{cnt} = \lfloor \frac{offset_{MS} - corr_{UTC}}{T_{ref}}\rfloor
\label{eq:corr_cnt}
\end{equation}
\item \textbf{Phase adjustment}: The slave's phase shifter is adjusted with
the remaining sub-cycle part of the offset \ref{eq:corr_phase}
\begin{equation}
corr_{phase} = offset_{MS} - [offset_{MS}]
\label{eq:corr_phase}
\end{equation}
\end{enumerate}
\emph{Voilà!} Now the slave's clock and PPS signals are synchronized to the
master with sub-nanosecond accuracy. Since the offset can vary with operating
conditions, it is measured at regular intervals and the difference between
subsequent measurements is added to slave's phase shift to compensate for
phase drift:
\begin{equation}
corr_{phase} = offset_{MS} - offset_{MS\us previous}
\label{eq:corr_phase2}
\end{equation}
Because the phase drift is mainly caused by temperature variations, the rate
of subsequent adjustments can be very low, even in the scale of a single
adjustment per hour.
Note that the way $corr_{phase}$ is calculated requires the phase shifter
to be able to change the phase relatively by any arbitrary value with
no "jumps" in the signal when the value of $corr_{phase}$ crosses the
inter-cycle boundary. For example, one can use a PLL with a phase detector
capable of handling wrap-around phase transitions, but not a programmable
delay line. An example design of such phase detector and PLL is described
in section \ref{s:main_pll}.
\section{Integration of White Rabbit into PTP}
\label{s:ptp_integration}
As mentioned in section \ref{s:ptp}, WR extends the PTP standard with
several custom messages to enable frequency syntonization and PHY delay
calibration. These messages utilize the user-definable Type-Length-Value
fields in the PTP version 2 Announce and Management messages. A WR master
is therefore fully compatible with any PTPv2-compliant device.
Figure \ref{fig:ptp_wr_flow} shows the order of the PTP message exchanges
during all the phases of the synchronization process, indicating which
messages are standard PTP (black) and WR-specific (red). Note that the
calibration stages involving the exchange of calibration patterns are only
required if the remote node's PHY has type 2 (CDR) asymmetry.
The drawing is intended to complement the synchronization flow described
in the chapter and give the reader an overview of the entire WR-PTP
synchronization process. A detailed description of the data flow, packet
formats and master's and slave's state machines falls out of the scope of
this thesis. A complete description of the protocol can be found in the WR
specification \cite{wr_spec}.
\begin{figure}[htb]
\centering
\includegraphics[width=\textwidth]{drawings/ptp_wr_flow.pdf}
\caption{PTP message flow during WR synchronization.}
\label{fig:ptp_wr_flow}
\end{figure}
src/wrspec.tex
View file @ 54df63f8
......@@ -26,6 +26,7 @@
\usepackage{amsmath}
\usepackage{times,mathptmx}
\usepackage{chngcntr}
%\usepackage{morefloats}
%\usepackage{amsfonts}
%\usepackage{amssymb}
......@@ -95,7 +96,7 @@
\end{center}
\begin{table}[ht]
\begin{table}[ht!]
%\caption{White Rabbit Specification Revision History Table }
\centering
\begin{tabular}{| c | c | c | p{8cm} |} \hline
......@@ -122,7 +123,18 @@
Power On. \\
& & & 6.~Mentioned (missing) modification to PTP FSM. \\
\hline
1.1 & 2/05/2011 & J.S.\& T.W.\& M.L. & Clarity and typos. \\
1.1 & 2/05/2011 & J.S., T.W., M.L. & Clarity and typos. \\
\hline
1.2 & 26/05/2011 & M.L. & Modifying according to J.E.'s feedback: . \\
& & & 1.~Clear distinction between HW and WRPTP (interface defined). \\
& & & 2.~Clarification of WR Messages' sending/receiving. \\
& & & 3.~WR Link Setup in PTP Master state on the WR Master. \\
& & & 4.~Added information about HW requirements and HW
implementation. \\
& & & 5.~WR Data Set fields' initialization defined and specified. \\
& & & Other cosmetic changes. \\
% , partly as a consequence of the feedback
% (e.g. WR FSM transition condition). \\
\hline
\end{tabular}
\label{tab:revHist}
......@@ -143,9 +155,11 @@ a packet-based network with sub-ns accuracy. The protocol results
from the combination of IEEE1588-2008 (PTP)\cite{IEEE1588} with two further
requirements: precise knowledge of the link delay and clock
syntonization\footnote{The adjustment of two electronic circuits or devices in terms of frequency.}
over the physical layer.
over the physical layer with Synchronous Ethernet (SyncE) \cite{SynchE}.
A WR link is formed by a pair of nodes, master and slave (Figure~\ref{fig:wrNodes}). The master
A WR link is formed by a pair of nodes, master and slave
%(Figure~\ref{fig:wrNodes})
. The master
node uses a traceable clock to encode data over the physical layer, while the slave
recovers this clock (syntonization) and bases its timekeeping on it. Absolute time
synchronisation between master and slave is achieved by adjusting
......@@ -157,19 +171,26 @@ The phase and offset adjustment is done through the two-way exchange of PTP sync
are corrected
to achieve sub-ns accuracy thanks to the precise knowledge of the link delay.
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=1.00\textwidth]{fig/clocks.ps}
\caption{Synchronization and syntonization in a White Rabbit link.}
\label{fig:wrNodes}
\end{figure}
% \begin{figure}[ht!]
% \centering
% % \vspace{-1.3cm}
% \includegraphics[width=1.00\textwidth]{fig/clocks.ps}
% \caption{Synchronization and syntonization in a White Rabbit link.}
% \label{fig:wrNodes}
% \end{figure}
%
%
% \newpage
In White Rabbit, the precise knowledge of the link delay is obtained by accurate hardware
timestamps (see section~\ref{sec:timestamps}) and calculation of the delay asymmetry (see
section~\ref{sec:delayAsymCal}) supported by knowledge of delays introduced by the hardware (see
section~\ref{sec:fixedDelays}).
\newpage
The precise knowledge of the link delay is obtained by accurate hardware
timestamps and calculation of the delay asymmetry (see section~\ref{sec:delayAsymCal}).
The White Rabbit protocol is complementary with an appropriate hardware. Therefore, the
hardware requirements and an overview of White Rabbit Hardware Support are presented in
section~\ref{sec:hw}. Additionally, details of a sample hardware implementation are presented in
Appendix~\ref{sec:sampleHW}.
The described single-link synchronization can be replicated.
Multi-link WR networks are obtained by chaining WR links forming a
......@@ -179,12 +200,13 @@ over the physical layer, resulting in a \textit{cascade} of master
and slave nodes. As a result of this topology, a WR~network consists of two kinds of WR network
devices:
\textit{WR boundary clocks} (WR Switches) and \textit{WR ordinary clocks}
(WR Nodes), see section~\ref{sec:definitions}.
(WR Nodes), see section~\ref{sec:definitions}. A WR boundary clocks distribute the frequency
and time retrieved from the upstream link to all the downstream links.
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.80\textwidth]{fig/wr_net_topology.ps}
\includegraphics[width=0.60\textwidth]{fig/wr_net_topology.ps}
\caption{White Rabbit network; it forms a hierarchical topology.}
\label{fig:wrNetwork}
\end{figure}
......@@ -396,24 +418,93 @@ The delay asymmetry can then be derived from equations \eqref{eq:delayms}, \eqre
\newpage
\section{Hardware Support}
\label{sec:hw}
This chapter gives a general overview of what is required of a hardware to support White Rabbit
protocol. An appropriate hardware is complementary to the protocol, therefore understand
hardware requirements is necessary to understanding the protocol itself.
The requirement for The White Rabbit Hardware Support are as follows:
\begin{itemize}
\item It shall distribute frequency over physical layer with SyncE.
\item It shall provide fixed delays - transmit/receipt latencies.
\item It shall provide timestamps with a sufficient precision.
\item It shall be able to generate calibration pattern
(RD+K28.7 code group, Appendix 36A.2 of \cite{IEEE802.3}).
\end{itemize}
Figure~\ref{fig:clocksHwSpec} (a) gives a general picture of the data flow in the WR
protocol, WR Hardware Support and the interface between these two.
Figure~\ref{fig:clocksHwSpec} (b) explains the WR synchronization and synchronization scheme.
A sample hardware implementation is described in details in the Appendix~\ref{sec:sampleHW}.
\begin{figure}[ht!]
\centering
\includegraphics[width=0.9\textwidth]{fig/clocksHwSpec.ps}
\caption{WR protocol and WR Hardware overview.}
\label{fig:clocksHwSpec}
\end{figure}
\subsection{Synchronous Ethernet}
\label{sec:syncE}
SyncE is responsible for clock synchronization (frequency transfer) in the White Rabbit Network.
In the SyncE scheme, the reference clock (125MHz) is used to encode the outgoing data
stream. The same clock is retrieved on the other side of the physical link.
Having the same frequency allows to use phase detector technologies as a means of evaluating
delays. The measurement of phase can be used for increasing the precision of timestamps
beyond the resolution allowed by the 125MHz clock (section~\ref{sec:timestamps}) and to obtain
the transmit/receive (Rx/Tx) fixed delays introduced by PHY (section~\ref{sec:fixedDelays}).
\section{Fixed delays}
\subsection{Fixed delays}
\label{sec:fixedDelays}
The knowledge of fixed delays $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ is necessary to calculate
delay asymmetry \eqref{eq:aqasymm}. Such delays may be constant for the lifetime of the hardware,
its up-time or the duration of the link connection. Therefore, the method for obtaining fixed
delays is medium-specific and implementation-dependent. The delays are measured (if necessary)
and their values are distributed across the link during the process of
establishing the WR link, which is called \textit{WR Link Setup} in this document.
delay asymmetry using WR Link Model (section~\ref{sec:delaymodel}). Such delays may be constant for
the lifetime of the hardware, its up-time or the duration of the link connection. Therefore,
the method for obtaining fixed delays is medium-specific and implementation-dependent.
The WR protocol requires the information about the fixed delays values and enables their
measurement, but does not specify how they shall be obtained.
The delays are measured (if necessary) and their values are distributed across the link during
the process of establishing the WR link, which is called \textit{WR Link Setup} in this document.
A WR~node participates in the measurement of another
WR node's reception fixed delay ($\Delta_{\{rx_m, rx_s\}}$) upon request, e.g. by sending
a calibration pattern in Gigabit Ethernet. Measurement of fixed delays during WR Link Setup
is optional and in principle needed only once, while the WR link is being set up.
It is only required if non-deterministic reception/transmission elements are used
It is only required if non-deterministic reception/transmission elements are used.
Figure~\ref{fig:clocksHwSpec} (a) presents a possible method of fixed delay measurement for
non-deterministic Gigabit Ethernet PHY -- detection of the signal phase difference on the input
and output of the PHY. The calibration pattern sent by WR nodes to measure fixed delays shall
be generated by a repeated transmission of RD+ K28.7 code-group. The details of this implementation
are presented in Appendix~\ref{sec:calibForGigbitE}.
\subsection{Timestamps}
\label{sec:timestamps}
The improvement of synchronization accuracy through WR Link Model requires precise timestamps.
The precision of timestamps shall be sufficient to take advantage of the calculated asymmetry
and is dictated by the required synchronisation accuracy.
In standard implementations of timestamping units the precision is limited by
the timestamping resolution (e.g. 8ns for 125MHz) and the $\pm$~1~LSB error.
In particular, the precision of the reception timestamps ($t_2$, $t_4$) needs to be enhanced.
This can be done by using the common notion of frequency distributed with SyncE to cast the
problem of timestamping into a phase detection measurement.
% For example, in order to achieve sub-nanosecond synchronisation accuracy, the precision of
% timestamps provided by the hardware shall be in a picoseconds range.
An overview of a possible solution enabling highly precise timestamping is ilustrated in
Figure~\ref{fig:clocksHwSpec}. The timestamping unit produces timestamps on both the rising
and falling edges of the clock. It is provided with the phase measurement of the rount-trip phase
($phase_{MM}$) in case of the Master, and the setpoint phase ($phase_{S}$) in case of the Slave.
The phase measurement is used by the timestamping unit to choose the correct edge timestamp and
enhance it to the precision allowed by the phase detector.
Details of the implementation of the presented solution are presented in
Appendix~\ref{sec:FineDelayMeasurement}.
The calibration pattern sent by WR nodes to measure fixed delays for non-deterministic Gigabit
Ethernet PHY shall be generated by repeated transmission of RD+ K28.7 code-group as described
in Appendix~\ref{sec:calibForGigbitE}.
......@@ -427,14 +518,17 @@ benefiting from PTP's synchronization, management and messaging mechanisms. From
document, the White Rabbit extension to the PTP standard will be referred to as \textit{WRPTP}.
WRPTP takes advantage of PTP's customization facilities, i.e. \textit{PTP profiles} and
\textit{Type-Length-Value} (TLV), and makes an extension to the
PTP standard which is out of the scope of these facilities. It also defines
\textit{implementation specific} functionalities (e.g. WR-specific fields of Data Sets,
hardware support) which are compatible with the PTP standard.
\textit{Type-Length-Value} (TLV).
%, and makes an extension to the PTP standard which is out of the scope of these facilities.
It also defines \textit{implementation specific} functionalities (e.g. WR-specific fields of
Data Sets, hardware support) which are compatible with the PTP standard.
For the sake of simplicity and clarity, this section explains all the mechanisms of WRPTP without
classifying them into PTP-profile, PTP-extension and implementation-specific. The distinction is
made in the last subsections, where the \textit{White Rabbit PTP profile} is defined and the
extensions to PTP are listed.
classifying them into PTP-profile
% , PTP-extension
and implementation-specific. The distinction is
made in the last subsection, where the \textit{White Rabbit PTP profile} is defined and
the implementation-specific recommendations are listed.
%and the extensions to PTP are listed.
\subsection{Overview}
\label{sec:wrptpOverview}
......@@ -456,7 +550,7 @@ of a \emph{hybrid} WR/IEEE1588 network with a grandmaster as a root.
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.80\textwidth]{fig/hybrid.ps}
\includegraphics[width=0.8\textwidth]{fig/hybrid.ps}
\caption{Hybrid WR/IEEE1588 network. White Rabbit nodes work
transparently with PTP nodes. WR ordinary clock 3 is more accurately
synchronised to the grandmaster than WR ordinary clock 2, which
......@@ -468,11 +562,12 @@ of a \emph{hybrid} WR/IEEE1588 network with a grandmaster as a root.
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.6\textwidth]{fig/wrptpMSGs.ps}
\includegraphics[width=0.99\textwidth]{fig/wrptpMSGs.ps}
\caption{Simplified overview of the message flow in WRPTP.}
\label{fig:wrptpMSGs}
\end{figure}
\newpage
The flow of events for standard PTP which is presented in section~\ref{sec:ptp} is extended
as depicted in Figure~\ref{fig:wrptpMSGs} and described below:
......@@ -515,16 +610,19 @@ It results in the Slave's synchronization with the Master clock with sub-ns accu
\item Repeat 1, 11-18.
\end{enumerate}
\newpage
\subsection{Definitions}
\label{sec:definitions}
The following definitions used in this document are introduced in Clause 3.1 of PTP:\\
The following definitions used in this document are based on Clause 3.1 of PTP:\\
\textbf{node}: A device that can issue or receive Precision Time Protocol (PTP) communications on a
network.\\
\textbf{boundary clock}: A clock that has multiple Precision Time Protocol (PTP) ports in a domain
and maintains the timescale used in the domain. It may serve as the source of time, i.e., be a
master clock, and may synchronize to another clock, i.e., be a slave clock.\\
master clock, and may synchronize to another clock, i.e., be a slave clock. The frequency retrieved
on the active slave port is distributed by the master port(s).\\
\textbf{ordinary clock}: A clock that has a single Precision Time Protocol (PTP) port in a domain
and maintains the timescale used in the domain. It may serve as a source of time, i.e., be a master
clock, or may synchronize to another clock, i.e., be a slave clock.\\
......@@ -536,7 +634,8 @@ or an ordinary clock.\\
ordinary clock which acts as a source of timing information for another White Rabbit enabled port of
a boundary or an ordinary clock.\\
\textbf{White Rabbit Slave (WR Slave)}: a WRPTP-enabled port of a boundary clock or an
ordinary clock which retrieves timing information sent over a link by a WR Master.\\
ordinary clock which retrieves the frequency and the timing information sent over a link by
the WR Master.\\
\textbf{White Rabbit Switch (WR Switch)}: a boundary clock implementing WRPTP, compatible with
standard PTP. \\
\textbf{White Rabbit Node (WR Node)}: an ordinary clock implementing WRPTP, compatible with
......@@ -559,98 +658,245 @@ operation of the protocol (section 8, PTP). WRPTP:
\subsubsection{New fields of PTP Data Sets}
Table~\ref{tab:wrDS} defines the additional DS fields required by WRPTP that are not part of
the PTP standard, described below.
the PTP standard (see Appendix~\ref{ap:wrDataTypes} for a definition of primitive data types).
\newpage
\begin{table}[ph!]
\caption{WRPTP Data Sets fields}
\centering
\begin{tabular}{| c | c | p{2.5cm} | c | } \hline
\begin{tabular}{| l | c | l | c | c | c | } \hline
\textbf{DS member} & \textbf{DS name}&\textbf{Values}& \textbf{D}ynamic or \textbf{S}tatic
\\
& & &
\\ \hline
wrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
WR\_M\_ONLY
WR\_M\_AND\_S &S \\ \hline
wrMode & portDS & NON\_WR,
WR\_SLAVE,
WR\_MASTER &D \\ \hline
wrModeON & portDS & TRUE, FALSE &D \\ \hline
wrPortState & portDS & Table~\ref{tab:wrFSMdesc} &D \\ \hline
calibrated & portDS & TRUE, FALSE &D \\ \hline
deltaTx & portDS & 64 bit value &D \\ \hline
deltaRx & portDS & 64 bit value &D \\ \hline
calPeriod & portDS & 32 bit value &S \\ \hline
%calPattern & portDS & 32 bit value &S \\ \hline
%calPatternLen & portDS & 16 bit value &S \\ \hline
%wrAlpha & portDS & 32 bit value &S \\ \hline \hline
\textbf{DS member} & \textbf{DS name}& \textbf{Allowed} & \textbf{Initialization}&
\textbf{D}ynamic & \textbf{Unit} \\
& & \textbf{values} &\textbf{values}&
or \textbf{S}tatic &
\\ \hline
wrConfig & portDS & NON\_WR, & - & S & - \\
& & WR\_S\_ONLY, & & & \\
& & WR\_M\_ONLY, & & & \\
& & WR\_M\_AND\_S & & & \\ \hline
wrMode & portDS & NON\_WR, & NON\_WR & D & - \\
& & WR\_SLAVE, & & & \\
& & WR\_MASTER & & & \\ \hline
wrModeON & portDS & TRUE, FALSE & FLASE & D & - \\ \hline
wrPortState & portDS & Table~\ref{tab:wrFSMdesc} & IDLE & D & - \\ \hline
knownDeltaTx & portDS & UInteger64 & - & S & [$2^{16}$ps]\footnotemark[2]\\ \hline
knownDeltaRx & portDS & UInteger64 & - & S & [$2^{16}$ps]\footnotemark[2]\\ \hline
deltasKnown & portDS & TRUE, FALSE & - & S & - \\ \hline
calibrated & portDS & TRUE, FALSE & deltasKnown & D & - \\ \hline
deltaTx & portDS & UInteger64 & knownDeltaTx & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
deltaRx & portDS & UInteger64 & knownDeltaRx & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
calPeriod & portDS & UInteger32\footnotemark[3],& - & S & [us]\\ \hline
wrStateTimeout & portDS & UInteger32 & - & S & [ms]\\ \hline
wrStateRetry & portDS & UInteger8 & - & S & - \\ \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
parentWrConfig & portDS & NON\_WR,
WR\_S\_ONLY,
WR\_M\_ONLY
WR\_M\_AND\_S &D \\ \hline
parentWrMode & portDS & NON\_WR,
WR\_SLAVE,
WR\_MASTER &D \\ \hline
parentWrModeON & portDS & TRUE, FALSE &D \\ \hline
parentDeltaTx & portDS & 64 bit value &D \\ \hline
parentDeltaRx & portDS & 64 bit value &D\\ \hline
parentCalPeriod & portDS & 32 bit value &S \\ \hline
%parentCalPattern & portDS & 32 bit value &S \\ \hline
%parentCalPatternLen & portDS & 16 bit value &S \\ \hline \hline
parentWrConfig & portDS & NON\_WR, & NON\_WR & D & - \\
& & WR\_S\_ONLY, & & & \\
& & WR\_M\_ONLY, & & & \\
& & WR\_M\_AND\_S & & & \\ \hline
parentWrMode & portDS & NON\_WR, & NON\_WR & D & - \\
& & WR\_SLAVE, & & & \\
& & WR\_MASTER & & & \\ \hline
parentWrModeON & portDS & TRUE, FALSE & FALSE & D & - \\ \hline
parentDeltaTx & portDS & UInteger64 & 0x0 & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
parentDeltaRx & portDS & UInteger64 & 0x0 & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
parentCalPeriod & portDS & UInteger32 & 0x0 & D & [us]\\ \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
primarySlavePortNumber & currentDS & 16 bits value &D \\ \hline
primarySlavePortNumber & currentDS & UInteger16 & 0x0 & D & - \\ \hline
\end{tabular}
\label{tab:wrDS}
\end{table}
\footnotetext[2]{The value of $\Delta_{tx_m,rx_s,rx_m,tx_s}$ measured in picoseconds and
multiplied by $2^{16}$.}
\footnotetext[3]{Maximum shall be smaller then AnnounceInterval (see PTP)}
\addtocounter{footnote}{2}
\newpage
\paragraph{wrConfig} Determines the predefined function of a WR port.
\paragraph{(Re-)Initialization}
\label{sec:initialization}
Initialization rules listed in PTP (clause 8.1.3) apply to WR fields.
In particular:
\begin{itemize}
\item Data set members shall be initialized before leaving PTP INITIALIZATION state,
\item Static members shall be initialized to the implementation-specific values meeting the
specifications for the member.
\end{itemize}
Additionally, the values of dynamic WR fields shall be set to initializing values on the occurrence
of the following events:
\begin{itemize}
\item exiting IDLE state of the WR State Machine.
\item EXCEED TIMEOUT RETRIES transition event.
\end{itemize}
The initialization values of dynamic WR fields are specified in Table~\ref{tab:wrDS}, while
the initialization values of static fields are implementation and configuration-specific
(if not defined by implementation, default values in Table~\ref{tab:wrDSdefault} shall be used).
\paragraph{wrMode} Contains the current WR-role of a WR port which is determined using the modified
BMC algorithm (section~\ref{sec:wrBMC}) by the conditions described in
the sections~\ref{sec:wrSlaveFSMstart}~and~\ref{sec:wrMasterFSMstart}.
\paragraph{wrModeON} If true, it indicates that the WR Link Setup has been performed successfully
and the WR port is synchronized using WRPTP, and that the role defined in wrMode is active.
\paragraph{wrPortState} Stores the current state of the WRPTP state machine (see chapter~\ref{wrFSM}).
\begin{table}[ph!]
\caption{Default values for static DS.}
\centering
\begin{tabular}{| l | c | c | } \hline
\textbf{DS member} & \textbf{DS name}& \textbf{Default value} \\
& & \\ \hline
wrConfig & portDS & WR\_M\_AND\_S \\ \hline
deltasKnown & portDS & FALSE \\ \hline
knownDeltaTx & portDS & 0 [$2^{16}$ps]\footnotemark[2] \\ \hline
knownDeltaRx & portDS & 0 [$2^{16}$ps]\footnotemark[2] \\ \hline
calPeriod & portDS & 3000 [us] \\ \hline
wrStateTimeout & portDS & 300 [ms] \\ \hline
wrStateRetry & portDS & 3 \\ \hline
\end{tabular}
\label{tab:wrDSdefault}
\end{table}
\paragraph{New Fields Description}
\subparagraph{wrConfig} Determines the predefined function of a WR Port. It defaults to WR\_M\_AND\_S,
however, it is forseen that a port might be configured to allow only WR\_MASTER or WR\_SLAVE mode,
or the WR protocol might be disabled. Such configuration can result from administrative
consideration or hardware limitations. Some implementations might auto-detect the port's
WR configuration.
\subparagraph{wrMode} Contains the current WR-role of a WR Port which is determined using the modified
BMC algorithm (section~\ref{sec:wrBMC}) by the conditions described in
the sections~\ref{sec:wrSlaveFSMstart}~and~\ref{sec:wrMasterFSMstart}.
The WR-role is recommended or active depending on the values of wrModeOn:
\begin{itemize}
\item wrMode is recommended when wrModeON is FALSE.
\item wrMode is active when wrModeON is TRUE.
\end{itemize}
A WR Port in WR\_SLAVE mode is called WR Slave. Similarly, a WR Port in WR\_MASTER mode is
called WR Master.
\paragraph{calibrated} If true, it indicates that the fixed delays of the given port are known.
\subparagraph{wrModeON}
\label{par:wrModeON}
If TRUE, it indicates that the WR Link Setup has been performed successfully
and the WR Port is synchronized using WRPTP, and that the role defined in wrMode is active.
\paragraph{deltaTx} Port's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$.
It is set to TRUE on successful completion of WR State Machine (WR WR\_LINK\_ON state,
section~\ref{wrFSM}).
\paragraph{deltaRx} Port's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$.
It is set to FALSE :
\begin{itemize}
\item when link-down is detected on the WR Port, section~\ref{sec:hwOutput},
\item on initialization and re-initialization as described in section~\ref{sec:initialization},
\item on occurrence of the WR\_MODE\_OFF event, section~\ref{sec:reestablishingWRLink}.
\end{itemize}
\paragraph{calPeriod} Calibration period in microseconds.
%\paragraph{calPattern} Medium specific calibration pattern.
\subparagraph{wrPortState}
Stores the current state of the WRPTP state machine (see section~\ref{wrFSM}).
\subparagraph{knownDeltaTx}
If a non-deterministic PHY is used (see \ref{sec:fixedDelays}), therefore
values of transmission delay needs to be measured, its value shall be 0x0. Otherwise, it shall store
the value of the known port's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$.
\subparagraph{knownDeltaRx}
If a non-deterministic PHY is used (see section~\ref{sec:fixedDelays}), therefore
values of reception delay needs to be measured, its value shall be 0x0. Otherwise, it shall store
the value of the known port's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$.
\subparagraph{deltasKnown}
TRUE if a deterministic PHY is used, the fixed delays are constant and their values are provided
in the knownDeltaTx and knownDeltaRx Data Set fields. Otherwise FALSE.
\subparagraph{calibrated}
\label{par:calibrated}
If true, it indicates that the fixed delays of the given port for the currently established WR Link
are known.
\subparagraph{deltaTx}
\label{par:deltaTx}
Port's $\Delta_{tx}$ measured in picoseconds and multiplied by ${2^{16}}$.
% If knownDeltaTx is not
% equal 0x0, the value shall be set to knownDeltaRx during initialization
% (section~\ref{sec:initialization}). Otherwise, it shall be measured during WR Link Setup.
\subparagraph{deltaRx}
\label{par:deltaRx}
Port's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$.
% If knownDeltaRx is not
% equal 0x0, the value shall be set to knownDeltaRx during initialization
% (section~\ref{sec:initialization}). Otherwise, it shall be measured during WR Link Setup.
\subparagraph{calPeriod}
\label{par:calPeriod}
Calibration period in microseconds. Its value shall be less than the
value of AnnounceInterval of PTP determined by the portDS.logAnnounceInterval
(see clause 15.5.3.7.2.1 of PTP). If its value is greater than 0x0, it defines timeouts for the
\textit{REQ\_CALIBRATEION} states of WR State Machine.
\subparagraph{wrStateTimeout}
\label{par:wrStateTimeout}
Determines the timeout (in microseconds) for an execution of a state of the WR State Machine.
\subparagraph{wrStateRetry}
\label{par:wrStateRetry}
Determines the number of times a state of WR State Machine is re-entered
(as a consequence of wrStateTimeout expiration) before the WR Link Setup is abandoned. If the
number of the given state execution retries equals wrStateRetry, the EXC\_TIMEOUT\_RETRY event is
generated (see \ref{sec:wrEventsAndConditions}).
%\paragraph{calPatternLen} Number of bits of calPattern to be repeated.
%\paragraph{wrAlpha} \textit{Relative delay coefficient} described in
% section~\ref{sec:singlefiber}.
\paragraph{primarySlavePortNumber} If 0, no Primary Slave is selected. 1, 2 ,...N --value of the
\subparagraph{primarySlavePortNumber}
If 0, no Primary Slave is selected. 1, 2 ,...N --value of the
portNumber (clause 7.5.2.3 PTP) selected as the Primary Slave, see section~\ref{sec:wrBMC}.
\paragraph{parentWrConfig} Stores the value of wrConfig of the parent port.
\subparagraph{parentWrConfig}
Stores the value of wrConfig of the parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}).
\subparagraph{parentWrMode}
Stores the value of wrMode of the parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}).
\paragraph{parentWrMode} Stores the value of wrMode of the parent port.
\subparagraph{parentWrModeON}
\label{par:parentWrModeON}
Stores the value of wrModeON of the parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}).
\paragraph{parentWrModeON} Stores the value of wrModeON of the parent port.
\subparagraph{parentCalibrated}
\label{par:parentCalibrated}
Stores the value of calibrated of the parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}).
\paragraph{parentCalibrated} Stores the value of calibrated of the parent port.
\subparagraph{parentDeltaTx}
\label{par:parentDeltaTx}
Stores the value of deltaTx of the parent port exchanged during the WR Link Setup. It is
sent in the WRPTP Signaling Message (section~\ref{wrSignalingMSG}).
\paragraph{parentDeltaTx} Stores the value of deltaTx of the parent port.
\subparagraph{parentDeltaRx}
\label{par:parentDeltaRx}
Stores the value of deltaRx of the parent port exchanged during the WR Link Setup. It is
sent in the WRPTP Signaling Message (section~\ref{wrSignalingMSG}).
\paragraph{parentDeltaRx} Stores the value of deltaRx of the parent port.
\subparagraph{parentCalPeriod}
\label{par:parentCalPeriod}
Stores the value of calPeriod parameter of the parent port. The value defines the time
(in microseconds) for which the calibration pattern should be sent by the receiving node.
It is exchanged during the WR Link Setup. It is sent in the WRPTP Signaling Message
(section~\ref{wrSignalingMSG}). If its value is greater than 0x0, it defines timeouts for the
\textit{RESP\_CALIB\_REQ} states of WR State Machine
\paragraph{parentCalPeriod} Stores the value of calPeriod parameter of the parent port.
%\paragraph{parentCalPattern} Stores the value of calPattern parameter of the parent port.
......@@ -659,7 +905,7 @@ portNumber (clause 7.5.2.3 PTP) selected as the Primary Slave, see section~\ref{
\subsubsection{backupParentDS data set specifications}
A boundary clock shall maintain an implementation-specific backupParentDS data set for the purpose
A boundary clock shall maintain an implementation-specific backupParentDS Data Set for the purpose
of qualifying redundant sources of synchronisation, i.e.:
\begin{itemize}
\item backup paths to the current grandmaster clock, or
......@@ -678,6 +924,8 @@ The implementation-specific backupParentDS set shall have a minimum capacity of
records. The order of the records is established using Data Set Comparison Algorithm as described
in the section~\ref{StadeDecisionAlg}.
The initialization rules stated in PTP (clause 8.1.3) apply to the backupParentDS Data Set.
%on $E_{rbest}$
%which are qualified as backup Masters by modified State Decision Algorithm, record number 0 being the
%best (described in the chapter~\ref{StadeDecisionAlg}).
......@@ -768,7 +1016,7 @@ The modifications to the rules governing the update of the data sets are twofold
the modifications in the SDA.
\end{itemize}
\begin{table}[ht!]
\begin{table}[tbp]
\caption{Modification to Table~13 of IEEE1588-2008: Update for state decision code M1 and M2.}
\centering
\begin{tabular}{| c | p{8cm} |} \hline
......@@ -782,7 +1030,7 @@ currentDS.primarySlavePortNumber & set to 0 \\ \hline
\label{tab:modifiedM1M2}
\end{table}
\begin{table}[ht!]
\begin{table}[tbp]
\caption{Modification to Table~16 of IEEE1588-2008: Update for state decision code S1.}
\centering
\begin{tabular}{| c | c |} \hline
......@@ -795,7 +1043,7 @@ currentDS.primarySlavePortNumber & portDS.portIdentity.portNumber \\ \hline
\label{tab:modifiedS1}
\end{table}
\begin{table}[ht!]
\begin{table}[tbp]
\caption{Update for state decision code S2}
\centering
\begin{tabular}{| c | c |} \hline
......@@ -818,21 +1066,24 @@ White Rabbit benefits from PTP's messaging facilities. It defines a \textit{WR T
(WR TLV) extension to exchange WR-specific information and uses the two-step clock delay
request-response mechanism for synchronization. In particular, it adds a suffix to the Announce
message to enable recognition of WR nodes and uses Signaling Messages to exchange WR-specific
information (Figure~\ref{fig:wrptpMSGs}).
information (Figure~\ref{fig:wrptpMSGs}). During the exchange of timestamps, their
fractional nanoseconds part is always included in the messages as defined in the PTP standard
(cause 9.5.10) and explained in Appendix~\ref{ap:computationsExplanation}.
A WR port in the $PTP\_MASTER$ state announces its presence by adding a suffix to the Announce message.
The suffix is defined by the PTP standard as a set of TLV entities (section 13.4, PTP).
A WR port in the $PTP\_MASTER$ state announces its presence by adding a suffix to the Announce
message. The suffix is defined by the PTP standard as a set of TLV entities (section 13.4, PTP).
Unrecognised TLVs are ignored by standard PTP nodes (section 14.1, PTP), but read and interpreted by
White Rabbit nodes.
The information provided in the WRPTP Announce message is sufficient for another WR port to decide
whether the WR link can be established and maintained. A WR port receiving a
WRPTP Announce message enters (if conditions in \ref{sec:wrSlaveFSMstart} are fulfilled)
the WR Slave mode and starts the Link Setup process (performed during $PTP\_UNCALIBRATED$ state.
see Appendix~\ref{ap:ptpAndWrFSMS}) It requests the sender of the WRPTP announce message to enter
the WR Master mode (see section \ref{sec:wrMasterFSMstart}) and start the Link Setup process.
During the WR Link Setup, communication between the WR Master and the WR Slave is performed using
PTP Signaling Messages carrying WR TLVs. Once the WR link has been established,
the WR nodes use a PTP delay request-response mechanism (section 11.3, PTP).
the WR Slave mode and starts the Link Setup process (performed during $PTP\_UNCALIBRATED$ state,
see Appendix~\ref{ap:ptpAndWrFSMS}). The WR Slave requests the sender of the WRPTP announce message
to enter the WR Master mode (see section \ref{sec:wrMasterFSMstart}) and start
the Link Setup process. During the WR Link Setup, communication between the WR Master and
the WR Slave is performed using PTP Signaling Messages carrying WR TLVs
(section~\ref{sec:communicationWRfsm}). Once the WR link has been established, the WR nodes use
a PTP delay request-response mechanism (section 11.3, PTP).
\subsubsection{WR Type-Length-Value}
......@@ -878,7 +1129,7 @@ The WR-specific TLVs are identified by wrMessageID which is defined in
Table~\ref{tab:wrMessageId}. The different types of WR messages are described in subsequent
sections.
\begin{table}[ht!]
\begin{table}[tbp]
\caption{White Rabbit Message ID values}
\centering
\begin{tabular}{| l | p{2.5cm} | c | c |} \hline
......@@ -895,6 +1146,8 @@ ANN\_SUFIX & 0x2000 & Announce \\ \hline
\label{tab:wrMessageId}
\end{table}
\newpage
\subsubsection{WRPTP Announce Message}
\label{sec:wrAnnounceMSG}
......@@ -903,7 +1156,7 @@ The standard PTP Announce Message is suffixed by one WR TLV entity.
The WRPTP Announce message has the structure defined in Table~\ref{tab:wrAnnounce}. The $dataField$
of the suffix WR TLV stores the $wrFlags$ defined in Table~\ref{tab:wrFlags}.
\begin{table}[h!]
\begin{table}[ht!]
\caption{White Rabbit Announce Message.}
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{4.5cm} |}
......@@ -940,9 +1193,15 @@ of the suffix WR TLV stores the $wrFlags$ defined in Table~\ref{tab:wrFlags}.
0 &2 & Announce & calibrated & TRUE if the source port
is calibrated.\\
\hline
0 &3 & Announce & wrModeON & The value of wrModeON
parameter of portDS.\\
\hline
0 &3 & Announce & wrModeON & The wrModeON value
(\ref{par:wrModeON}) of the
sending port which shall be
stored in parentWrModeON
(\ref{par:parentWrModeON})
of the receiving port.
% The value of wrModeON
% parameter of portDS.
\\ \hline
\end{tabular}
\label{tab:wrFlags}
\end{table}
......@@ -961,11 +1220,14 @@ Signaling Message transports a single WR TLV structure as defined in Section~\re
The \textit{targetPortIdentity} shall be always set to the \textit{clockIdentity} of the port
on the other side of the link (conveyed in the Announce Message).
Signaling Messages are used in WRPTP to trigger transitions in the WR state machine and exchange
WR-specific parameters. They are distinguished by the \textit{wrMessageId} field of \textit{WR TLV},
defined in Table~\ref{tab:wrMessageId}. Signaling Messages are exchanged only within a single
link connection (no forwarding) which is ensured by setting the targetPortId appropriately.
The rest of this subsection describes the WRPTP Signaling Messages in details.
The messages are used in WRPTP to trigger transitions in the WR State Machine and exchange
WR-specific parameters. They are sent on entering particular states of WR State Machine as
described in section~\ref{sec:communicationWRfsm}.
The distinction between WR Signaling Messages is made by the \textit{wrMessageId} field of
\textit{WR TLV}, defined in Table~\ref{tab:wrMessageId}. Signaling Messages are exchanged only
within a single link connection (no forwarding) which is ensured by setting the targetPortId
appropriately. The rest of this subsection describes the WRPTP Signaling Messages in details.
\begin{table}[h!]
\caption{PTP Signaling message fields (Table 33, PTP) }
......@@ -985,12 +1247,13 @@ The rest of this subsection describes the WRPTP Signaling Messages in details.
\end{table}
\paragraph{SLAVE\_PRESENT} Message sent by the WR Node which entered WR Slave mode to the WR Node
to become the WR Master. It initiates the WR Master mode and starts WR Link Setup process in
the WR Master. The message shall have the form specified in Table~\ref{tab:wrOtherTLV}.
\paragraph{SLAVE\_PRESENT} Message sent by the WR Port which became WR Slave (entered WR Slave mode)
to the link-partner WR Port. It initiates the WR Master mode (the port becomes WR Master)
on the link-partner WR Port which starts WR Link Setup. The message shall have the form specified
in Table~\ref{tab:wrOtherTLV}.
\paragraph{LOCK} Message sent by the WR Master to the WR Slave to request the start of frequency
locking. The message shall have the form specified in Table~\ref{tab:wrOtherTLV}.
\paragraph{LOCK} Message sent by the WR Master to the WR Slave to request
the start of frequency locking. The message shall have the form specified in Table~\ref{tab:wrOtherTLV}.
\paragraph{LOCKED} Message sent by the WR Slave to the WR Master. It indicates successful
completion of frequency locking. The message shall have the format specified in
......@@ -1022,7 +1285,7 @@ Table~\ref{tab:wrOtherTLV}.
\paragraph{CALIBRATE} Message sent by the WR port entering the REQ\_CALIBRATION state (see
section~\ref{wrFSM}). It informs the other port
whether sending a calibration pattern (see section~\ref{sec:fixedDelays}) is required (defined by
the value of \textit{calibrationSendPattern} flag). If calibration is required, it carries
the value of \textit{calSendPattern} flag). If calibration is required, it carries
the calibration period. The message format and parameters are described in
Table~\ref{tab:wrCalibrateTLV}.
......@@ -1043,14 +1306,19 @@ Table~\ref{tab:wrCalibrateTLV}.
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xABCD. \\ \hline
\multicolumn{8}{|c|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & CALIBRATE. \\ \hline
\multicolumn{8}{|c|}{calibrationSendPattern} & 2 & 12 & The value determines whether calibration
pattern should be sent. If the value
is 0x1, the calibration pattern is sent. If
the value is 0x0, the calibration pattern is
not sent. \\ \hline
\multicolumn{8}{|c|}{calibrationPeriod} & 4 & 14 & The value defines the time (in microseconds)
for which the calibration pattern should be
sent by the receiving node.\\ \hline
\multicolumn{8}{|c|}{calSendPattern} & 2 & 12 & The value determines whether calibration
pattern should be sent. If the value
is 0x1, the calibration pattern is sent.
If the value is 0x0, the calibration
pattern is not sent. The value shall be
based on the information provided by the
$calibration$ Data Set field
(\ref{par:parentCalibrated}).\\ \hline
\multicolumn{8}{|c|}{calPeriod (UInteger64)} & 4 & 14 & The calPeriod value (\ref{par:calPeriod})
of the sending port which shall be stored
in parentCalPeriod
(\ref{par:parentCalPeriod}) of
the receiving port.\\ \hline
% \multicolumn{8}{|c|}{calibrationPattern} & 4 & 18 & The value defines the calibration pattern
% which should be sent by the receiving
% node.\\ \hline
......@@ -1068,12 +1336,12 @@ Table~\ref{tab:wrCalibrateTLV}.
\paragraph{CALIBRATED} Message sent by a WR port entering the \textit{CALIBRATED} state.
If preceded by the \textit{CALIBRATE} message with \textit{calibrationSendPattern} set to TRUE,
If preceded by the \textit{CALIBRATE} message with \textit{calSendPattern} set to TRUE,
it indicates successful completion of the calibration. The message provides the other node with the
values of its fixed delays ($\Delta_{tx}$ and $\Delta_{rx}$).
The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\begin{table}[ht]
\begin{table}[tbp]
\caption{WR TLV for CALIBRATED Signaling Message.}
\centering
\begin{tabular}{| c | c | c | c | c | c | c | c | c | c | p{7.5cm} |}
......@@ -1089,12 +1357,20 @@ The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\multicolumn{8}{|c|}{magicNumber } & 2 & 7 & 0xABCD. \\ \hline
\multicolumn{8}{|c|}{versionNumber } & 1 & 9 & 0x01. \\ \hline
\multicolumn{8}{|c|}{wrMessageId } & 2 & 10 & CALIBRATED. \\ \hline
\multicolumn{8}{|c|}{deltaTx } & 16 & 12 & The value of $\Delta_{tx_m}$ measured in
picoseconds and multiplied by ${2^{16}}$.\\
\hline
\multicolumn{8}{|c|}{deltaRx } & 16 & 28 & The value of $\Delta_{rx_m}$ measured in
picoseconds and multiplied by ${2^{16}}$.\\
\hline
\multicolumn{8}{|c|}{deltaTx (UInteger64) } & 16 & 12 & The deltaTx value (\ref{par:deltaTx})
of the sending port which shall be stored
in parentDeltaTx (\ref{par:parentDeltaTx})
of the receiving port.
% The value of $\Delta_{tx_m}$ measured in
% picoseconds and multiplied by ${2^{16}}$.
\\ \hline
\multicolumn{8}{|c|}{deltaRx (UInteger64) } & 16 & 28 & The deltaRx value (\ref{par:deltaRx})
of the sending port which shall be stored
in parentDeltaRx (\ref{par:parentDeltaRx})
of the receiving port.
% The value of $\Delta_{rx_m}$ measured in
% picoseconds and multiplied by ${2^{16}}$.
\\ \hline
\end{tabular}
\label{tab:wrCalibratedTLV}
\end{table}
......@@ -1104,38 +1380,58 @@ The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\paragraph{WR\_MODE\_ON} Message sent by WR Master to WR Slave. It indicates successful completion
of the WR Link Setup process and requests the WR~Slave to validate its WR~mode (by setting wrModeON
to true). The message shall have the format specified in Table~\ref{tab:wrOtherTLV}.
to TRUE). The message shall have the format specified in Table~\ref{tab:wrOtherTLV}.
\newpage
\subsection{PTP State Machine}
\label{ptpStateMachine}
The WR Link Setup (WR state machine) is performed in the PTP\_UNCALIBRATED state of the PTP state
machine (see Appendix~\ref{ap:ptpAndWrFSMS}). Therefore it is essential for a WR port to implement
this state as specified in the PTP state machine (\textcolor{blue}{2} in
Figure~\ref{fig:modifiedPtpFSM}): a transition state
The WR Link Setup (WR State Machine) is performed in the PTP\_MASTER state of the PTP state machine
on a WR Port in WR Master mode (WR Master). On a WR Port in WR Slave mode (WR Slave),
the WR State Machine is executed in the PTP\_UNCALIBRATED state of the PTP state machine.
Therefore, it is essential for a WR port to implement PTP\_UNCALIBRATED state as specified in the
PTP state machine (\textcolor{blue}{1} in Figure~\ref{fig:modifiedPtpFSM}): a transition state
between the LISTENING or PRE\_MASTER or MASTER or PASSIVE state and the SLAVE state.
Additionally, WRPTP defines implementation-specific \textit{SYNCHRONIZATION\_FAULT} and \\
\textit{MASTER\_CLOCK\_SELECTED} PTP state transition event
% and introduces a new transition event \textit{CALIBRATION\_FORCED\_BY\_SLAVE}
, see Figure~\ref{fig:modifiedPtpFSM}.
\subsubsection{MASTER\_CLOCK\_SELECTED}
\label{sec:masterClockSelected}
On successful completion of WR State Machine execution (transition from WR\_LINK\_ON to the IDLE
state with wrModeON set to TRUE) on the port being in WR\_Slave mode and PTP\_UNCALIBRATED state,
the MASTER\_CLOCK\_SELECTED event (\textcolor{blue}{2} in Figure~\ref{fig:modifiedPtpFSM},
defined in Clause 9.2.6.13 of PTP) shall occur. Consequently, PTP\_SLAVE state shall be
entered.
WRPTP specifies an implementation-specific SYNCHRONIZATION\_FAULT PTP state transition event
(\textcolor{blue}{3} in Figure~\ref{fig:modifiedPtpFSM}, defined in Clause 9.2.6.12 of PTP).
The port being in WR\_Slave mode and PTP\_SLAVE state shall
evaluate values of two WR-specific parameters: $wrModeON$ and $parentWrModeON$. If the value
of at least one of the parameters is FALSE, the SYNCHRONIZATION\_FAULT event shall occur
and PTP\_UNCALIBRATED shall be entered. Consequently the WR Link Setup is performed.
\subsubsection{SYNCHRONIZATION\_FAULT}
\label{sec:synchronizationFault}
The port being in WR\_Slave mode and PTP\_SLAVE state shall evaluate values of two WR-specific
parameters: $wrModeON$ (\ref{par:wrModeON}) and $parentWrModeON$ (\ref{par:parentWrModeON}).
If the value of at least one of the parameters is FALSE, the SYNCHRONIZATION\_FAULT event
(\textcolor{blue}{3} in Figure~\ref{fig:modifiedPtpFSM}, defined in Clause 9.2.6.12 of PTP) shall
occur and PTP\_UNCALIBRATED shall be entered. Consequently the WR Link Setup is performed.
Such implementation enables forced re-calibration of WR ports which can be triggered by both,
WR Master and WR Slave.
WRPTP introduces a new state transition event to the original PTP state machine:
\textit{CALIBRATION\_FORCED\_BY\_SLAVE}. It is depicted in red (number \textcolor{blue}{2})
in Figure~\ref{fig:modifiedPtpFSM}. The event shall be instantiated by the reception of
the $SLAVE\_PRESENT$ Signaling Message on a WR-Master-enabled port (the value of portDS.wrConfig
is WR\_M\_AND\_S or WR\_M\_ONLY) in $PTP\_MASTER$ state.
This transition allows a WR Slave to start WR Master mode and trigger a WR Link Setup process in
another WR port.
% \subsubsection{CALIBRATION\_FORCED\_BY\_SLAVE}
%
% WRPTP introduces a new state transition event to the original PTP state machine:
% \textit{CALIBRATION\_FORCED\_BY\_SLAVE}. It is depicted in red (number \textcolor{blue}{2})
% in Figure~\ref{fig:modifiedPtpFSM}. The event shall be instantiated by the reception of
% the $SLAVE\_PRESENT$ Signaling Message on a WR-Master-enabled port (the value of portDS.wrConfig
% is WR\_M\_AND\_S or WR\_M\_ONLY) in $PTP\_MASTER$ state.
% This transition allows a WR Slave to start WR Master mode and trigger a WR Link Setup process in
% another WR port.
\newpage
\begin{figure}[ht!]
\centering
......@@ -1152,13 +1448,19 @@ another WR port.
\label{wrFSM}
The White Rabbit finite state machine (WR FSM) controls the process of establishing a White Rabbit
link between a WR Master and a WR Slave (WR Link Setup). It involves the recognition of two
link between a WR Master and a WR Slave (WR Link Setup). It shall be non-preemptive with regards
to the execution of PTP State Machine. It means that, once IDLE state of WR State Machine is
exited (WR State Machine execution started), no transitions on the PTP State Machine shall occur,
until WR State Machine finishes execution and returns to the IDLE state.
WR Link Setup involves the recognition of two
compatible WR nodes, syntonization over the physical layer, measurement of fixed delays and
exchange of their values across the link. The procedure differs between WR Master and WR Slave,
therefore three states are Slave-only (entered only if the node is in WR Slave mode) and one
state is Master-only (entered only if the node is in WR Master mode). The WR FSM shall be
executed in the PTP UNCALIBRATED state, it is depicted in Figure~\ref{fig:wrFSM} and described in
the rest of this section.
executed in the PTP UNCALIBRATED state on the WR Slave (WR Port in WR Slave mode) and in
the PTP MASTER state on the WR Master (WR Port in WR Master mode).
The WR FSM is depicted in Figure~\ref{fig:wrFSM} and described in the rest of this section.
A typical flow of a complete WR Signaling Message exchange between a WR Slave and a WR Master
during WR Link Setup is presented in Appendix~\ref{ap:wr_lsu_flow}. For clarity, the cooperation of
......@@ -1169,32 +1471,41 @@ PTP and WR state machines from power up is presented in Appendix~\ref{ap:ptpAndW
%The WR FSM in
A WRPTP-enabled port becomes a WR Slave (portDS.wrMode = WR\_SLAVE) and starts execution
A WR port becomes a WR Slave (portDS.wrMode = WR\_SLAVE) and starts execution
of WR FSM by entering the \textit{PRESENT} state, only when the following conditions are met:
\begin{itemize}
\item the port is WR Slave-enabled: \\
\textit{portDS.portWrConfig = ($WR\_S\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)} \textbf{AND}
\textit{portDS.wrConfig = ($WR\_S\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)}\\
\textbf{AND}
\item the PTP state machine enters the PTP UNCALIBRATED state as a result of \\
STATE\_DECISION\_EVENT:
Recommended State == BMC\_SLAVE (\textcolor{blue}{1} in Figure~\ref{fig:modifiedPtpFSM})
Recommended State == BMC\_SLAVE (\textcolor{blue}{1} in Figure~\ref{fig:modifiedPtpFSM})
\textbf{OR} SYNCHRONIZATION\_FAULT event\\
\textbf{AND}
\item the parent port is WR Master-enabled: \\
\textit{portDS.parentPortWrConfig = ($WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)} \textbf{AND}
\textit{portDS.parentWrConfig = ($WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)} \\
\textbf{AND}
\item at least one of the ports on the link is not in WR Mode: \\
\textit{portDS.portWrMode = FALSE \textbf{OR} portDS.ParentPortWrMode = FALSE}.
\textit{portDS.wrMode = FALSE \textbf{OR} portDS.ParentPortWrMode = FALSE}.
\end{itemize}
\newpage
\subsubsection{Conditions to enter WR Master mode and start the WR FSM}
\label{sec:wrMasterFSMstart}
A WRPTP-enabled port becomes a WR Master (portDS.wrMode = WR\_Master) and starts execution of WR FSM
A WR port becomes a WR Master (portDS.wrMode = WR\_Master) and starts execution of WR FSM
by entering the \textit{M\_LOCK} state only when the following conditions are met:
\begin{itemize}
\item the port is WR Master-enabled:\\
\textit{portDS.portWrConfig = $WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$} \textbf{AND}
\item the PTP state machine enters the a PTP\_UNCALIBRATED state as a result of
CALIBRATION\_FORCED\_BY\_SLAVE transition event (\textcolor{blue}{2} in
Figure~\ref{fig:modifiedPtpFSM})
\textit{portDS.wrConfig = $WR\_M\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$} \\
\textbf{AND}
\item the port is in PTP\_MASTER state \\
\textbf{AND}
\item the $SLAVE\_PRESENT$ Signaling Message has been received.
% \item the PTP state machine enters the a PTP\_UNCALIBRATED state as a result of
% CALIBRATION\_FORCED\_BY\_SLAVE transition event (\textcolor{blue}{2} in
% Figure~\ref{fig:modifiedPtpFSM})
\end{itemize}
......@@ -1208,7 +1519,8 @@ by entering the \textit{M\_LOCK} state only when the following conditions are me
\newpage
\paragraph{State Description}
%\paragraph{State Description}
\subsubsection{State Description}
Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{fig:wrFSM}.
......@@ -1220,41 +1532,45 @@ Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{f
& \\ \hline
\small
IDLE & The WR FSM shall be in the IDLE state if the PTP FSM is in a state other than
UNCALIBRATED. \\ \hline
PRESENT & Slave-only state. The WR Slave sends a SLAVE\_PRESENT message to the WR
Master and waits for the $LOCK$ message.\\ \hline
M\_LOCK & Master-only state. The WR master waits for the WR Slave to finish
successfully the locking process. \\ \hline
UNCALIBRATED or MASTER. \\ \hline
PRESENT & Slave-only state. Upon entering this state, the WR Slave sends a SLAVE\_PRESENT
message to the WR Master and waits for the $LOCK$ message.\\ \hline
M\_LOCK & Master-only state. Upon entering this state, the WR Master sends $LOCK$
message. In this state, the WR Master waits for the WR Slave to finish
successfully the locking process (reception of the $LOCKED$ message). \\ \hline
S\_LOCK & Slave-only state. The WR Slave locks its logic to the frequency distributed
over physical layer by the WR Master. \\ \hline
LOCKED & Slave-only state. The WR Slave is syntonized, it sends a \textit{LOCKED}
message to the WR Master and waits for the \textit{CALIBRATE} message. \\
\hline
LOCKED & Slave-only state. Upon entering this state, WR Slave sends $LOCKED$ message
to inform that it is syntonized, and waits for the \textit{CALIBRATE} message.
\\ \hline
REQ\_CALIBRATION & In this state, optional calibration of the node's reception fixed delay can
be performed.
The node sends a \textit{CALIBRATE} message to the other node. If the
calibration is needed,
(\textit{calibrated} is set to false), the \textit{calibrationSendPattern}
Upon entering this state, the WR Port sends a \textit{CALIBRATE} message to
the other WR Port. If the calibration is needed,
(\textit{calibrated} is set to false), the \textit{calSendPattern}
flag in the \textit{CALIBRATE} message
is sent to TRUE (0x1). If the calibration is not needed, the
\textit{calibrationSendPattern} flag is set to FALSE (0x0).
If calibration is not needed, the next state is entered directly, otherwise an
\textit{calSendPattern} flag is set to FALSE (0x0).
If calibration is not needed, the next state is entered, otherwise an
indication from the hardware
that the calibration has been finished successfully is awaited. \\ \hline
CALIBRATED & The node sends a \text{CALIBRATED} message with information about its fixed
delays. \\ \hline
RESP\_CALIB\_REQ & The node's action in this state depends on the value of the
\textit{calibrationSendPattern} flag received in the \textit{CALIBRATE}
CALIBRATED & Upon entering this state, the WR Port sends a \text{CALIBRATED} message with
information about its fixed delays. \\ \hline
RESP\_CALIB\_REQ & The WR Port's action in this state depends on the value of the
\textit{calSendPattern} flag received in the \textit{CALIBRATE}
message. A TRUE value of the flag
indicates that the calibration pattern shall be enabled. The pattern shall be
disabled after \textit{calibrationPeriod}
or on reception of the \textit{CALIBRATED} message. If the value of the
\textit{calibrationSendPattern} flag is FALSE,
the \textit{CALIBRATED} message is awaited for a default timeout. On
indicates that the calibration pattern shall be enabled while the WR State
Machine is in this state. The pattern shall be
disabled on exiting the state (after the timeout of \textit{calPeriod} or
on reception the of the \textit{CALIBRATED} message). If the value of the
\textit{calSendPattern} flag is FALSE,
the \textit{CALIBRATED} message is awaited for a default timeout. On the
reception of the \textit{CALIBRATED} message, the next state is entered.\\
\hline
WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \textit{IDLE} state is
entered. \\ \hline
WR\_LINK\_ON & Upon entering this state by the WR Master, it sends WR\_LINK\_ON message.
In this state, the value of \textit{wrModeON (\ref{par:wrModeON})} is set to
TRUE and the \textit{IDLE} state is entered unconditionally. The execution of
WR FSM is considered to be completed successfully. \\ \hline
\end{tabular}
\label{tab:wrFSMdesc}
\end{table}
......@@ -1273,60 +1589,228 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\newpage
\paragraph{WR FSM Transition Events and Conditions}
%\paragraph{WR FSM Transition Events and Conditions}
\subsubsection{WR FSM Transition Events and Conditions}
\label{sec:wrEventsAndConditions}
\begin{description}
\item[]
\item[POWERUP] Turning on power to the device or reseting.
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that a WR
Link Setup is required and that the WR FSM should be executed starting at the
\textit{PRESENT} state, see section~\ref{sec:wrSlaveFSMstart}.
\item[LOCK MESSAGE] (abrv. M\_LOCK) WR $LOCK$ Signaling message
which triggers frequency locking over the physical layer.
\item[LOCKED HARDWARE EVENT] (abrv. HW\_LOCKED) Indication from the hardware
that frequency locking has been completed successfully.
\item[LOCKED MESSAGE] (abrv. M\_LOCKED) WR $LOCKED$ Signaling
message which notifies the WR Master that frequency locking has been completed
successfully by the WR Slave.
\item[CALIBRATE MESSAGE] (abrv. M\_CALIBRATE) WR $CALIBRATE$ Signaling
message. It requests the recipient to enter the
\textit{RESP\_CALIB\_REQ} state, indicates whether sending of the calibration pattern is
required and provides calibration parameters.
\item[CALIBRATED HARDWARE EVENT] (abrv. HW\_CALIBRATE) Notification from the
hardware indicating that calibration has been completed successfully.
\item[CALIBRATED MESSAGE] (abrv. M\_CALIBRATED) WR \text{CALIBRATED}
Signaling message. It indicates that the node is calibrated. If the \textit{CALIBRATED}
message is received when the calibration pattern is being sent by the recipient,
sending of the pattern shall be disabled. The message carries information about fixed delays
of the sending node.
\item[WR MODE ON] (abrv. M\_WR\_MODE\_ON) WR \textit{WR\_MODE\_ON}
Signaling message. It indicates that the WR Master finished successfully the WR Link Setup
and set the \text{wrMode} flag to TRUE. It requests the WR Slave to set the \text{wrMode} flag
to TRUE.
\textit{PRESENT} state, occurs when conditions presented in section~\ref{sec:wrSlaveFSMstart}
are fulfilled.
\item[SLAVE PRESENT MESSAGE] (abrv. M\_SLAVE\_PRESENT) Event triggered by the
reception of the WR $SLAVE\_PRESENT$ Signaling message. It requests the recipient to enter
the \textit{M\_LOCK} state.
\item[LOCK MESSAGE] (abrv. M\_LOCK) Event triggered by the
receoption of the WR $LOCK$ Signaling message.
% which triggers frequency locking over the physical layer.
\item[LOCKED HARDWARE EVENT] (abrv. HW\_LOCKED) Event triggered by the
reception of the hardware notification that frequency locking has been completed successfully.
\item[LOCKED MESSAGE] (abrv. M\_LOCKED) Event triggered by the
reception of the WR $LOCKED$ Signaling message which notifies the WR Master that frequency
locking has been completed successfully by the WR Slave.
\item[CALIBRATE MESSAGE] (abrv. M\_CALIBRATE) Event triggered by the
reception of the WR $CALIBRATE$ Signaling message. It requests the recipient to enter the \\
\textit{RESP\_CALIB\_REQ} state.
% , indicates whether sending of the calibration pattern is
% required and provides calibration parameters.
% \item[CALIBRATED HARDWARE EVENT] (abrv. HW\_CALIBRATED) Notification from the
% hardware indicating that calibration has been completed successfully.
\item[CALIBRATED MESSAGE] (abrv. M\_CALIBRATED) Event triggered by the
reception of the WR \text{CALIBRATED} Signaling message. It indicates that the node is
calibrated. If the \textit{CALIBRATED} message is received when the calibration pattern is
being sent by the recipient, sending of the pattern shall be disabled.
% The message carries information about fixed delays
% of the sending node.
\item[WR MODE ON] (abrv. M\_WR\_MODE\_ON) Event triggered by the
reception of the WR \textit{WR\_MODE\_ON} Signaling message. It indicates that the WR Master
finished successfully the WR Link Setup and set the \text{wrModeON} flag to TRUE.
% It requests the WR Slave to set the \text{wrModeON} flag to TRUE.
\item[RETRY $n_{name}$] The White Rabbit state
machine waits in a given state for a transition event only for a limited time
(\textit{TIMEOUT}) The states to which this rule applies are the following: \textit{M\_LOCK},
\textit{REQ\_CALIBRATEION}, \textit{CALIBRATED}, \textit{PRESENT}, \textit{S\_LOCK},
\textit{LOCKED},\textit{RESP\_CALIB\_REQ}. After the \textit{TIMEOUT} expires, the state is
re-entered for \\ $n_{\{M\_LOCK, REQ\_CAL,
CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$ number of times.
machine waits in a given state for a transition event only for a limited time, called timeout.
The timeout for the following states is defined by \textit{wrStateTimeout}
(\ref{par:wrStateTimeout}): \textit{M\_LOCK}, \textit{CALIBRATED}, \textit{PRESENT},
\textit{S\_LOCK}, \textit{LOCKED},
The timeout for the \textit{REQ\_CALIBRATEION} state shall be defined by the
calPeriod (\ref{par:calPeriod}), if its value is greater than 0x0. Otherwise
\textit{wrStateTimeout} shall be used.
The timeout for the \textit{RESP\_CALIB\_REQ} shall be defined by the parentCalPeriod
(\ref{par:parentCalPeriod}), if its value is greater than 0x0. Otherwise
\textit{wrStateTimeout} shall be used.
After the timeout expires, the state is re-entered. A state can be re-entered for a maximum
number of \\
$n_{\{M\_LOCK, REQ\_CAL,CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$ times defined
by \\wrStateRetry parameter (\ref{par:wrStateRetry}).
\item[EXCEED TIMEOUT RETRIES] (abrv. EXC\_TIMEOUT\_RETRY) Indicates that the state
has been re-entered for a set number of times \\($n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT,
S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$) and the \textit{TIMEOUT} has expired for the $n + 1$
has been re-entered for a set number of times (wrStateRetry, \ref{par:wrStateRetry}) and
the \textit{wrStateTimeout} (\ref{par:wrStateTimeout}) has expired for the $n + 1$
time.
\end{description}
\newpage
\subsection{Communication between WR State Machines}
\label{sec:communicationWRfsm}
This section clarifies the communication of the WR State Machines executed on different WR Ports
on the same link during the WR Link Setup. The communication is performed using WR Singaling Messages
(section~\ref{wrSignalingMSG}). In particular, each WR Signaling Message is sent by a WR Port
upon entering a particular state of WR State Machine. The same message received on the other WR~Port
triggers transition in the WR State Machine (section~\ref{sec:wrEventsAndConditions}).
Table~\ref{tab:wrMsgVsEvents} lists the WR Signaling Messages associating them with the moment
of their transmission and the event they trigger on the reception. It also specifies the WR Mode
of the sending port.
\begin{table}[tbp]
\caption{Communication between WR State Machines on different Boundary Clocks.}
\centering
\begin{tabular}{| l | c | p{2.5cm} | c |} \hline
\textbf{WR Message} &\textbf{Sent on entering WR state} & \textbf{Sent by port} &
\textbf{Triggers event} \\
& & \textbf{in wrMode} & \\ \hline
SLAVE\_PRESENT & PRESENT & WR Slave & M\_SLAVE\_PRESENT \\ \hline
LOCK & M\_LOCK & WR Master & M\_LOCK \\ \hline
LOCKED & LOCKED & WR Slave & M\_LOCKED \\ \hline
CALIBRATE & REQ\_CALIBRATION & WR Slave or & M\_CALIBRATE \\
& & WR Master & \\ \hline
CALIBRATED & CALIBRATED & WR Slave or & M\_CALIBRATED \\
& & WR Master & \\ \hline
WR\_MODE\_ON & WR\_LINK\_ON & WR Master & M\_WR\_MODE\_ON \\ \hline
\end{tabular}
\label{tab:wrMsgVsEvents}
\end{table}
\newpage
\subsection{Communication between WR State Machine and the hardware}
White Rabbit extends the standard PTP communication with the hardware which includes
transmission/reception of messages and retrieval of timestamps.
The WR communication with the hardware is needed during the WR Link Setup process
(by the WR State Machine) to control syntonization and fixed delays measurement and retrieve
their values. Additionally, an instant detection of the link-down is necessary outside
the WR Link Setup process (throughout the normal operation of the PTP State Machine).
\subsubsection{Input to hardware}
The information to the hardware by the WR State Machine is inputted on the exiting or entering
a state of this machine, as described in the Table~\ref{tab:inputWrCommWithHW}. The inputs notify
the hardware about a need to start/stop a process (i.e. syntonisation, pattern transmission).
\begin{table}[tbp]
\caption{Input to hardware.}
\centering
\begin{tabular}{| c | p{1.6cm} | p{4.5cm} | c |} \hline
\textbf{Hardware input} & \textbf{Type } & \textbf{Sent on } & \textbf{Sent by port} \\
& & & \textbf{in wrMode} \\ \hline
HW\_ENABLE\_LOCKING & event notification & entering
S\_LOCK WR State & WR Slave \\ \hline
% HW\_DISABLE\_LOCKING & event notification & exiting
% S\_LOCK WR State & WR Slave \\ \hline
HW\_ENABLE\_PATTERN & event notification & entering
RESP\_CALIB\_REQ WR State & WR Slave and WR Master \\ \hline
HW\_DISABLE\_PATTERN & event notification & exiting
RESP\_CALIB\_REQ WR State & WR Slave and WR Master \\ \hline
% $phase_{MM}$ & Integer64 & reception of
% event PTP message if WR Mode
% is active ($wrModeON=TRUE$)& WR Slave \\ \hline
\end{tabular}
\label{tab:inputWrCommWithHW}
\end{table}
\newpage
\subsubsection{Output from hardware}
\label{sec:hwOutput}
The hardware shall communicate two types of information to the WR State Machine
\begin{itemize}
\item event notification, i.e. termination of fixed delays measurement, completion of phase locking or
disconnection of the cable.
\item parameter value, i.e. fixed delays.
\end{itemize}
An event notification shall be evaluated in a particular state of the WR State Machine (defined in
Table~\ref{tab:outputWrCommWithHW}) by the means of polling or interrupt. Its occurrence in other state
then defined in Table~\ref{tab:outputWrCommWithHW} shall be ignored.
The hardware output of a parameter value (i.e. deltaTx, deltaRx) shall be evaluated on the
occurrence of an event notification (i.e. HW\_CALIBRATED) and its value shall be stored
in the local Data Set, as defined in Table~\ref{tab:outputWrCommWithHW}.
\begin{table}[tbp]
\caption{Input to hardware.}
\centering
\begin{tabular}{| p{3.4cm} | p{1.8cm} | p{4cm} | p{2cm} | p{3.2cm} |} \hline
\textbf{Hardware output}
&\textbf{Type}& \textbf{Evaluated} & \textbf{Evaluated by port} & \textbf{Action} \\
& & & \textbf{in wrMode} & \\ \hline
HW\_CALIBRATED & event notification & in REQ\_CALIBRATION
WR~State & WR~Slave and WR~Master& $calibrated$ Data Set field is set to TRUE, consequently WR State Machine transition is triggered\\ \hline
HW\_LOCKED & even notification & in S\_LOCK~WR State & WR~Slave& Triggers transition in WR State Machine\\ \hline
HW\_LINK\_DOWN & even notification & always & WR~Slave and WR~Master & Set wrModeON to FALSE, and wrMode to NON\_WR \\ \hline
$deltaTx$ & UInteger64 & on reception of
HW\_CALIBRATED & WR~Slave and WR~Master& Save the value in deltaTx data field on evaluation\\ \hline
$deltaRx$ & UInteger64 & on reception of
HW\_CALIBRATED & WR~Slave and WR~Master& Save value in deltaTx data field on evaluation \\ \hline
% $t_{1}$ & Integer64 & on sending Sync message& WR~Master & Send in FollowUp (nanosecond part in correctionField)\\ \hline
% $t_{p2}$ & Integer64 & on receiving Sync message & WR~Slave & Save\\ \hline
% $t_{3}$ & Integer64 & on sending Delay\_Req message & WR~Slave & Save\\ \hline
% $t_{p4}$ & Integer64 & on receiving Delay\_Req message & WR~Master & Send in Delay\_Resp (nanosecond part in correctionField)\\ \hline
\end{tabular}
\label{tab:outputWrCommWithHW}
\end{table}
\subsubsection{Re-establishing WR Link}
\label{sec:reestablishingWRLink}
It shall be possible for an external event (user demand, management message) which occurs on
a WR Ports in an active WR Mode to enforce re-establishing of WR Link, i.e. by performing
WR Link Setup.
The WR\_MODE\_OFF event instantiation is WR-implementation-specific. This event should be
instantiated whenever a WR Port is in the IDLE state of WR State Machine (regardless of the
PTP state) and the implementation detects implementation circumstances that require re-establishing
of WR Link.
The WR\_MODE\_OFF event results in setting wrModeON Data Set field of a given WR Port to FALSE.
\newpage
\subsection{White Rabbit PTP Profile Summary}
\subsubsection{Identification}
\begin{table}[ht!]
\begin{table}[tbp]
\caption{Profile print form (clause 19.3.3 of PTP)}
\centering
\begin{tabular}{| c | c |} \hline
......@@ -1348,6 +1832,8 @@ the attributes as follows:
\item portDS.logSyncInterval: The default initialization value shall be 0. The configuration range
shall be -1 to 6.
\item defaultDS.priority1: The default initialization value shall be 64.
\item defaultDS.domainNumber: The default initialization value shall be 0. Only the default
domain is allowed.
\end{itemize}
\subsubsection{PTP Options}
......@@ -1363,10 +1849,11 @@ document (Modified BMC).
The delay request-response mechanism shall be the only path delay measurement mechanism.
\\
The TLV mechanism described in Chapter~\ref{sec:wrMSG} shall be supported.
\\
\subsection{WRPTP Extension to PTP}
WRPTP extends PTP by adding the state transition event defined in section~\ref{ptpStateMachine}.
% \subsection{WRPTP Extension to PTP}
%
% WRPTP extends PTP by adding the state transition event defined in section~\ref{ptpStateMachine}.
\subsection{Implementation-specific additions to PTP required by WRPTP}
......@@ -1375,10 +1862,12 @@ WRPTP shall implement the following implementation-specific features:
\item issuing PTP messages with a WR TLV (i.e. suffixed Announce and Signaling messages),
as described in section~\ref{sec:wrAnnounceMSG},
\item proper handling of these messages as described in \ref{sec:wrAnnounceMSG},
\item WR state machine as defined in \ref{wrFSM},
\item a non-preemptive WR state machine as defined in \ref{wrFSM},
\item WR data set and additional WR-specific fields to PTP data sets as defined in
\ref{sec:wrDS},
\item SYNCHRONIZATION\_FAULT state transition as defined in \ref{ptpStateMachine}.
\item SYNCHRONIZATION\_FAULT state transition as defined in \ref{sec:synchronizationFault}.
\item MASTER\_CLOCK\_SELECTED state transition as defined in \ref{sec:masterClockSelected}.
\end{itemize}
......@@ -1394,7 +1883,7 @@ WRPTP shall implement the following implementation-specific features:
\begin{figure}[ht!]
\centering
\includegraphics[width=0.85\textwidth]{fig/ptpFSM.ps}
\includegraphics[width=0.8\textwidth]{fig/ptpFSM.ps}
\caption{State machine for a full implementation of PTP (Figure 23, IEEE1588).}
\label{fig:ptpFSM}
\end{figure}
......@@ -1468,18 +1957,38 @@ SLAVE & \small The port is synchronizing to the selected master po
\newpage
\section{Sample White Rabbit Hardware Support Implementation}
\label{sec:sampleHW}
% \include{from_tomeks_msc}
\section{Measurement of fixed delays for Gigabit Ethernet over Optic Fiber}
\subsection{Measurement of fixed delays for Gigabit Ethernet over Optic Fiber}
\label{sec:calibForGigbitE}
The variation of $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ delays is often caused by
the PHY's serializer / deserializer (SerDes), phase locked loop (PLL) or clock and
data recovery circuitry (CDR). The delay on the PHY can be measured by detecting
the phase shift between SerDes I/O and Tx/Rx clock. This be done in WR by sending
a repeated pattern of five "0" and five "1" (0000011111) over Gigabit Ethernet.
the phase shift between SerDes I/O and Tx/Rx clock. Such methods can by applied to the
PHYs whose maximum ($\Delta_{max}$) and minimum ($\Delta_{min}$) delays are known
(provided in the datasheet) and the delay's variation is
\begin{equation}
\label{eq:fixedDelayVariation}
\Delta_{variable} \in \langle 0 : \Delta_{max} - \Delta_{min} \rangle
\end{equation}
e.g. below 10 bit times in case of Gigabit Ethernet.
Therefore, a fixed delay can be expressed as a sum of a constant value
($\Delta_{min}$) and a variable part ($\Delta_{variable}$) which needs to be measured:
\begin{equation}
\label{eq:fixedDelay}
\Delta_{\{tx_m, rx_s, tx_s, rx_m\}} = \Delta_{min\_\{tx_m, rx_s, tx_s, rx_m\}} + \Delta_{variable\_\{tx_m, rx_s, tx_s, rx_m\}}
\end{equation}
In White Rabbit, the measurement of fixed delay's variable part ($\Delta_{variable}$) is done by
sending a repeated pattern of five "0" and five "1" (0000011111) over Gigabit Ethernet.
Such signal creates a 125~MHz clock on the SerDes I/O. Since the Tx/Rx clock
frequency is 125~MHz, the phase shift between the SerDes I/O and the Tx/Rx
clocks is equal to the fixed delay of the PHY (see Figure~\ref{fig:wrCalibration}).
clocks is equal to $\Delta_{variable}$ of the PHY (see Figure~\ref{fig:wrCalibration}).
The repeated pattern of five "0" and five "1" is defined by the IEEE 802.3 standard \cite{IEEE802.3}
......@@ -1500,6 +2009,12 @@ It is not needed if deterministic PHYs or internal FPGA transceivers which can b
characterized \cite{Peek2010} are used. In such case, the information about the fixed delays is
distributed across the link without preceding measurement.
\newpage
\subsection{Fine Delay Measurement}
\label{sec:FineDelayMeasurement}
\newpage
\section{Typical flow of WR Signaling message exchange}
......@@ -1527,6 +2042,34 @@ distributed across the link without preceding measurement.
\newpage
\section{Primitive data types}
\label{ap:wrDataTypes}
\begin{table}[tbp]
\caption{Primitive data types}
\centering
\begin{tabular}{| c | c |} \hline
\textbf{Data type } & \textbf{Definition} \\ \hline
& \\ \hline
UInteger8 & 8-bit unsigned integer \\ \hline
UInteger16 & 16-bit unsigned integer \\ \hline
UInteger32 & 32-bit unsigned integer \\ \hline
Integer64 & 64-bit integer \\ \hline
UInteger64 & 64-bit unsigned integer \\ \hline
\end{tabular}
\label{tab:wrPtpProfile}
\end{table}
\section{Computations using the two-step delay request-response mechanism with asymmetry correction}
\label{ap:computationsExplanation}
Quite a challenge
\newpage
\begin{thebibliography}{9}
......@@ -1546,6 +2089,12 @@ Control Systems}.
IEEE Computer Society, New York,
2008.
\bibitem{SynchE}
ITU-T G.8262/Y.1362
\emph{Timing characteristics of a synchronous
Ethernet equipment slave clock}.
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU,
07/2010.
\bibitem{Peek2010}
P.P.M. Jansweijer, H.Z. Peek,
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment