Skip to content

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

wrspec.v2: last corrections

parent 33439826
Hide whitespace changes
Inline Side-by-side
Showing with 281769 additions and 343120 deletions
src/fig/clocksHwSpec.ps
View file @ bcbcb98d
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpAndWrFSMs.ps
View file @ bcbcb98d
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/wrFSM.ps
View file @ bcbcb98d
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/wrptpMSGs.ps
View file @ bcbcb98d
This source diff could not be displayed because it is too large. You can view the blob instead.
src/from_tomeks_msc.tex
View file @ bcbcb98d
% \def\us{\char`\_}
\def\us{\char`\_}
\subsection{WR link model}
\label{s:link_model}
Knowledge of the physical model of links connecting the clocks is a
Knowledge of the physical model of the links connecting the clocks is a
prerequisite for achieving the required synchronization accuracy. The model
of a WR optical link is depicted in Figure~\ref{fig:link_model}.
\begin{figure}[ht!]
......@@ -55,14 +55,14 @@ and $T_{ref}$ is the period of Gigabit Ethernet 125 MHz reference clock (8 ns).
The goal of the presented model is to calculate the precise value of
master-to-slave offset $offset_{MS}$ by combining a coarse timestamp-based
round-trip delay \ref{eq:meanPath} with precise phase measurement
round-trip delay \eqref{eq:meanPath} with precise phase measurement
$phase_{MM}.$ Once the offset is computed, the WR slave can phase-shift its
recovered clock (deriving $phase_{S}$ from $offset_{MS}$) to match the phase
of the master clock, completing the synchronization.
\begin{figure}[ht!]
\centering
\includegraphics[width=15cm]{fig/tomeksDrawings/sync_flow.eps}
\caption{WR synchronization flow}
\caption{WR synchronization flow (DMTD is explained in Appendix~\ref{s:dmtd})}
\label{fig:sync_flow}
\end{figure}
Determining the precise offset, however, is not a trivial task. Figure
......@@ -99,7 +99,7 @@ following sequence:
\begin{enumerate}
\item The master starts broadcasting \textit{ANNOUNCE} messages to look for
a WR slave,
\item Eventually, the slave will respond with a \textit{SLAVE\us PRESENT}
\item Eventually, the slave will respond with a \textit{SLAVE\_PRESENT}
message, indicating that it supports WR. If no response has been received
within a predefined time, the master assumes that the slave is not WR
compatible and aborts the synchronization process,
......@@ -132,18 +132,18 @@ data stream (see section 3.2.2 \cite{tomekMSC}).
Let's first focus on the blocks marked blue in
Figure~\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
to take a snapshot of the free running counter CNTR\_R with the D-type
register DREG\_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,
The counter CNTR\_R works synchronously to the reference clock (master side,
signal 1 in Figure~\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
counter value is latched in register DREG\_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.
......@@ -167,8 +167,8 @@ 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
CNTR\_F on the falling edge of the reference clock, making the CNTR\us
F a copy of CNTR\_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 Figure~\ref{fig:ts_dualedge}). The correct timestamp is chosen depending on the
current phase shift between clocks (see section \ref{s:fine_delay}).
......@@ -235,7 +235,7 @@ 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}
resulting in a digital DMTD detector, shown on fig. \ref{fig:digital_dmtd}.
\begin{figure}[ht!]
\centering
\includegraphics[width=12cm]{fig/tomeksDrawings/digital_dmtd.eps}
......@@ -288,7 +288,7 @@ external components.
\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
on fig. \ref{fig:dmtd_glitches}. More details about the deglitching and
postprocessing algorithm can be found in section 4.3.5 of \cite{tomekMSC}.
\subsection{Fine delay measurement}
......@@ -355,8 +355,8 @@ 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
\ref{fig:merging_example}), the algorithm will use the $t_{4f}$ timestamp,
otherwise the $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$.
......@@ -377,7 +377,7 @@ as the thick navy trace.
\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
The enhancement operation for the $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
......@@ -495,7 +495,7 @@ 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 defines
a custom fiber asymmetry coefficient \ref{eq:fiber_alpha1} expressing the
a custom fiber asymmetry coefficient \eqref{eq:fiber_alpha1} expressing the
ratio between the M-S and S-M fiber propagation delays:
\begin{equation}
......@@ -584,7 +584,7 @@ PHYs whose maximum ($\delta_{PHY(M/S)_{max}}$) and minimum ($\delta_{PHY(M/S)_{m
\label{eq:fixedDelayVariation}
\delta_{\{TX, RX\}\_PHY(M/S)_{variable}} \in \langle 0 :\delta_{PHY(M/S)_{max}} - \delta_{PHY(M/S)_{min}} \rangle
\end{equation}
e.g. below 10 bit times in case of Gigabit Ethernet.
e.g. below 10 bit times in the case of Gigabit Ethernet.
Therefore, a fixed delay can be expressed as a sum of a constant value
($\delta_{\{TX, RX\}\_PHY(M/S)_{min}}$) and a variable part ($\delta_{\{TX, RX\}\_PHY(M/S)_{variable}}$) which needs to be measured:
\begin{equation}
......@@ -673,10 +673,10 @@ 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
\emph{Voil\`{a}!} 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
subsequent measurements is added to the slave's phase shift to compensate for
phase drift:
\begin{equation}
corr_{phase} = offset_{MS} - offset_{MS\us previous}
......
src/wrspec.tex
View file @ bcbcb98d
......@@ -72,8 +72,8 @@
\begin{document}
\title{White Rabbit Specification: \\Draft for Comments\\\normalsize {version 2}\\\small{(03-07-2011)}}
\author{Emilio G. Cota\\Maciej Lipinski\\Tomasz W\l{}ostowski\\Erik van der Bij\\Javier Serrano}
\title{White Rabbit Specification: \\Draft for Comments\\\normalsize {version 2.0}\\\small{(06-07-2011)}}
\author{Emilio G. Cota\\Maciej Lipi\'{n}ski\\Tomasz W\l{}ostowski\\Erik van der Bij\\Javier Serrano}
\date{July 2011}
\maketitle
\thispagestyle{empty}
......@@ -116,7 +116,7 @@
0.3 & 8/09/2010 & J.S., M.L. & Language\&Style-related corrections, reference to Peter's paper.
\\ \hline
0.4 & 14/09/2010 & E.V.D.B., M.L.& 1.~Merged the FSM of the Slave and the FSM of the Master into
single and linear FSM,\\
a single and linear FSM,\\
& & & 2.~Changed WR managementIDs,\\
& & & 3.~Added authors, this rev. table, explanatory figures and
descriptions. \\ \hline
......@@ -124,26 +124,26 @@
& & & 2.~Re-ordered appendixes. \\
& & & 3.~Fixed some typos. \\
\hline
1.0 & 26/04/2011 & M.L. & 1.~Including feedback from comments. \\
1.0 & 26/04/2011 & M.L. & 1.~Included feedback from comments. \\
& & & 2.~Created WR PTP Profile. \\
& & & 3.~Added modification to BMC. \\
& & & 4.~Enabled WR Switch to be "real" Boundary Clock. \\
& & & 4.~Enabled WR Switch to be a "real" Boundary Clock. \\
& & & 5.~Added figure clarifying WRPTP vs. PTP FSMs operation from
Power On. \\
& & & 6.~Mentioned (missing) modification to PTP FSM. \\
\hline
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.2 & 26/05/2011 & M.L. & Modified according to John Eidson's feedback: . \\
& & & 1.~Clear distinction between HW and WRPTP (interface defined). \\
& & & 2.~Clarification of WR Messages' sending/receiving. \\
& & & 2.~Clarification of WR Message 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. \\
& & & 5.~WR Data Set field initialization defined and specified. \\
& & & Other cosmetic changes. \\
\hline
1.3 & 7/06/2011 & M.L. & Added Appendices: \\
1.3 & 7/06/2011 & M.L. & Added Appendixes: \\
& & & 1.~Extract from Tomek's MSc. \\
& & & 2.~WR computation of offset and delay with asymmetry correction.\\
\hline
......@@ -164,12 +164,12 @@
& & & 1.~Name changed: REQ\_CALIBRATION to CALIBRATION.\\
& & & 2.~Included Tx calibration into the CALIBRATION.\\
& & & 3.~Added Link Down event description.\\
& & & 4.~Specified additional wrModeON's re-setting.\\
& & & 4.~Specified additional wrModeOn's re-setting.\\
& & & 5.~Re-modified BMC, completed DS Update tables.\\
& & & 6.~Added fields to DS: calRetry and otherPortCalRetry.\\
& & & 7.~Added calRetry field to WR TLV CALIBRATE Signaling Message.\\
% , partly as a consequence of the feedback
% (e.g. WR FSM transition condition). \\
\hline
2.0 & 04/07/2011 & J.S. & Clarity and typos (version 2.0 release). \\
\hline
\end{tabular}
\label{tab:revHist}
......@@ -194,30 +194,16 @@ 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
recovers this clock (synchronization) and bases its timekeeping on it. Absolute time
synchronization between master and slave is achieved by adjusting
the clock phase and offset of the slave to that of the master.
The \textit{offset} refers to the clock (e.g. time defined in Coordinated Universal Time or
International Atomic Time standards),
while the \textit{phase} refers to the clock signal (e.g. 125 MHz clock signal).
The phase and offset adjustment is done through the two-way exchange of PTP sync messages, which
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}
%
%
% \newpage
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
are time-stamped
to achieve sub-ns accuracy thanks to hardware support such as described in section~\ref{sec:hw}.
Details of a sample hardware implementation are presented in
Appendix~\ref{sec:sampleHW}.
In White Rabbit, the precise knowledge of the link delay is obtained by accurate hardware
......@@ -233,7 +219,7 @@ 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}. A WR boundary clock distribute the frequency
(WR Nodes), see section~\ref{sec:definitions}. A WR boundary clock distributes the frequency
and time retrieved from the upstream link to all the downstream links.
\begin{figure}[ht!]
......@@ -245,9 +231,9 @@ and time retrieved from the upstream link to all the downstream links.
\end{figure}
Some applications need WR and IEEE1588-2008 nodes to coexist. Examples
of this are networks where the need for highly accurate time synchronisation is concentrated on a
certain group of nodes. For this purpose the WR protocol enables WR nodes to defer to IEEE1588
behaviour when not connected to another WR node.
of this are networks where the need for highly accurate time synchronization is concentrated on a
certain group of nodes. For this purpose the WR protocol enables WR Nodes or Switches
to defer to IEEE1588 behavior when not connected to another WR Node or Switch.
......@@ -259,19 +245,20 @@ behaviour when not connected to another WR node.
The IEEE1588-2008 standard, known as Precision Time Protocol (PTP),
is repeatedly referenced in this document. Knowledge of basic PTP concepts is
required to read this specification, therefore they are explained in this section.
required to read this specification. Therefore, they are explained in this section.
PTP is a packet-based protocol designed to synchronize devices in distributed systems.
The standard defines two kinds of messages which are exchanged between \textit{PTP nodes}:
\textit{event messages} and \textit{general messages}. Both, the time of transmission and
the time of reception of event messages are \textit{timestamped}. General messages
the time of reception of event messages are \textit{recorded}. General messages
are used by PTP nodes to identify other PTP nodes, establish clock hierarchy and
exchange data, e.g.~timestamps, settings or parameters. PTP defines several methods
for node synchronization. Figure~\ref{fig:wrPTPmsgs} presents the messages used when
the \textit{delay request-response mechanism} (with a \textit{two-step clock}) is used,
which is the case in White Rabbit. For simplicity reasons, a PTP node is
considered an \textit{ordinary clock} in the remainder of this section; such clocks
have only one port.
which is the case in White Rabbit.
% For simplicity reasons, a PTP node is
% considered an \textit{ordinary clock} in the remainder of this section; such clocks
% have only one port.
\begin{figure}[ht!]
\centering
......@@ -298,7 +285,7 @@ is included in Appendix~\ref{ptpFSM}.
\textit{Sync Messages} and \textit{Delay\_Req Messages} are timestamped
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$) and these timestamps are used to calculate
the offset and the delay between the nodes exchanging the messages. \textit{Follow\_UP Messages}
the offset and the link delay between the nodes exchanging the messages. \textit{Follow\_Up Messages}
and \textit{Delay\_Resp Messages} are used to send timestamps between Master
and Slave (in the case of a two-step clock).
......@@ -315,17 +302,17 @@ The flow of events in the PTP delay request-response (two-step clock) mechanism
\item The slave receives the Announce message and uses the BMC algorithm to establish its place in
the network hierarchy.
\item The master periodically sends a Sync message (timestamped on transmission, $t_1$) followed by
a Follow\_UP message which carries $t_1$.
a Follow\_Up message which carries $t_1$.
\item The slave receives the Sync message sent by the master (timestamped on reception, $t_2$).
\item The slave receives the Follow\_Up message (which carries timestamp of Sync transmission time,
\item The slave receives the Follow\_Up message (which carries the Sync transmission time,
$t_1$) sent by the master .
\item The slave sends a Delay\_Req message (timestamped on transmission, $t_3$).
\item The master receives the Delay\_Req message sent by the slave (timestamped on reception,
$t_4$).
\item The master sends the Delay\_Resp message which carries $t_4$.
\item The slave receives the Delay\_Resp.
\item The slave adjusts its clock using the offset and the delay calculated with timestamps
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$). It results in the Slave's synchronization with the
\item The slave adjusts its clock using the clock offset and the link delay calculated with timestamps
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$). This results in the Slave's synchronization with the
Master clock.
\item Repeat 1-10.
\end{enumerate}
......@@ -336,7 +323,7 @@ The flow of events in the PTP delay request-response (two-step clock) mechanism
\section{Link Delay Model}
\label{sec:delaymodel}
The delay of a message travelling from master to slave (see Figure~\ref{fig:delaymodel})
The delay of a message traveling from master to slave (see Figure~\ref{fig:delaymodel})
can be expressed as the sum
\begin{equation}
......@@ -348,7 +335,7 @@ where $\Delta_{tx_m}$ is the fixed delay due to the master's transmission
circuitry, $\delta_{ms}$ is the variable delay incurred in the
transmission medium and $\Delta_{rx_s}$ is the fixed delay due to the
slave's reception circuitry.
In a similar fashion, the delay of a message travelling from slave to
In a similar fashion, the delay of a message traveling from slave to
master can be decomposed as
\begin{equation}
......@@ -384,9 +371,9 @@ this document by the \textit{relative delay coefficient} ($\alpha$).
Its origin is highly implementation-dependent. Thus this document just assumes that it exists
and is known.
\subsubsection{1000base-X over a Single-mode Optical Fibre}
\subsubsection{1000base-X over a Single-mode Optical Fiber}
\label{sec:singlefiber}
When a single-mode fibre is used as bi-directional communication medium,
When a single-mode fiber is used as bi-directional communication medium,
it can be shown that both variable delays are related by an equation of
the form \cite{Peek2010}:
\begin{equation}
......@@ -458,23 +445,21 @@ The delay asymmetry can then be derived from equations \eqref{eq:delayms}, \eqre
\label{sec:hw}
This section 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 understanding
hardware requirements is necessary to comprehend the protocol itself.
The requirement for the White Rabbit Hardware Support are as follows:
This section gives a general overview of hardware requirements to support the White Rabbit protocol.
Hardware supporting WR must fulfill the following requirements:
\begin{itemize}
\item It shall distribute frequency over physical layer with SyncE.
\item It shall provide fixed delays - transmit/receipt latencies.
\item It shall feature constant rx/tx latencies during operation and inform higher layers
about these latencies.
\item It shall provide timestamps with a sufficient precision.
\item It shall be able to generate calibration pattern
\item It shall be able to generate the WR 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.
protocol, WR Hardware Support and the interface between theme
Figure~\ref{fig:clocksHwSpec} (b) explains the WR synchronization and synchronization scheme.
A sample hardware implementation is described in details in Appendix~\ref{sec:sampleHW}.
An example hardware implementation is described in detail in Appendix~\ref{sec:sampleHW}.
\begin{figure}[ht!]
\centering
......@@ -486,59 +471,59 @@ A sample hardware implementation is described in details in Appendix~\ref{sec:sa
\subsection{Synchronous Ethernet}
\label{sec:syncE}
SyncE is responsible for clock synchronization (frequency transfer) in the White Rabbit Network.
SyncE is responsible for clock syntonization (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.
The retrieved frequency can be further distributed and is always looped back to the sender.
Having the same frequency allows to use phase detector technologies as a means of evaluating
Having the same frequency allows the use of 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}).
the transmit/receive (Rx/Tx) fixed delays introduced by the PHY (section~\ref{sec:fixedDelays}).
\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 using WR Link Model (section~\ref{sec:delaymodel}). They might include circuit,
The knowledge of all fixed delays $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ is necessary to calculate
the delay asymmetry using the WR Link Model (section~\ref{sec:delaymodel}). They might include circuit,
components (e.g. PHY, SFP) and FPGA internal latencies (Appendix~\ref{s:asymmetry} describes
fixed delays in WR optical link model). Such delays may be constant for
fixed delays in the WR optical link model). 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 PHY's delays
The WR protocol requires the fixed delay values and enables PHY delay
measurement, but does not specify how they shall be obtained.
The PHY's 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
WR node's reception fixed delays ($\Delta_{\{rx_m, rx_s\}}$) upon request, e.g. by sending
a calibration pattern in Gigabit Ethernet. The calibration pattern sent by WR nodes to measure
fixed delays shall be generated by a repeated transmission of RD+ K28.7 code-group.
fixed delays shall be generated by a repeated transmission of the RD+ K28.7 code-group.
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.
elements (i.e. with latencies varying after each power cycle or lock) are used.
Figure~\ref{fig:clocksHwSpec} (a) presents a possible method of fixed delay measurement for
non-deterministic Gigabit Ethernet PHY -- detection of the clock signal's phase difference on
Figure~\ref{fig:clocksHwSpec} (a) presents a possible method of fixed delay measurement for a
non-deterministic Gigabit Ethernet PHY -- detection of the clock signal's phase difference between
the input and output of the PHY (detailed description in Appendix~\ref{sec:calibForGigbitE}).
\subsection{Timestamps}
\label{sec:timestamps}
The improvement of synchronization accuracy through WR Link Model requires precise timestamps.
WR 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.
and is dictated by the required synchronization 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.
the timestamping resolution (e.g. 8ns for 125MHz).
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
% For example, in order to achieve sub-nanosecond synchronization 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
An overview of a possible solution enabling highly precise timestamping is illustrated 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
and falling edges of the clock. It is provided with the phase measurement of the round-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.
......@@ -560,7 +545,7 @@ WRPTP takes advantage of PTP's customization facilities, i.e. \textit{PTP profil
\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.
Data Sets and hardware support requirements) 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
......@@ -586,7 +571,7 @@ WRPTP is compliant with standard PTP. Figure~\ref{fig:hybrid-network} depicts th
of a \emph{hybrid} WR/IEEE1588 network with a grandmaster as a root.
WRPTP protocol cannot be performed over a non-WR network device (i.e. switches, repeaters, routers).
In example, if a non-WR device is connected between two WR-compatible nodes,
For example, if a non-WR device is connected between two WR-compatible nodes,
the standard PTP protocol will be used for synchronization.
......@@ -596,8 +581,8 @@ the standard PTP protocol will be used for synchronization.
\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
is below a PTP boundary clock.}
synchronized to the grandmaster than WR ordinary clock 2, which
is below a standard PTP boundary clock.}
\label{fig:hybrid-network}
\end{figure}
......@@ -616,40 +601,40 @@ The flow of events for standard PTP which is presented in section~\ref{sec:ptp}
as depicted in Figure~\ref{fig:wrptpMSGs} and described below:
\newpage
\begin{enumerate}
\item The \textbf{WR Node A} which is in PTP\_MASTER state periodically sends WR Announce messages with
\item \textbf{WR Node A} which is in PTP\_MASTER state periodically sends WR Announce messages with
a custom suffix.
\item The \textbf{WR Node B} receives Announce message(s), recognizes the WR Announce message and
\item \textbf{WR Node B} receives Announce message(s), recognizes the WR Announce message and
uses the modified BMC algorithm (section~\ref{sec:wrBMC}) to establish its place in the WR
network hierarchy.
\item The \textbf{WR Node B} enters WR Slave mode (based on the conditions in
\item \textbf{WR Node B} enters WR Slave mode (based on the conditions in
\ref{sec:wrSlaveFSMstart}) and starts the WR Link Setup by sending the SLAVE\_PRESENT
WR Signaling message.
\item The \textbf{WR Node A} enters WR Master mode (based on the conditions in
\item \textbf{WR Node A} enters WR Master mode (based on the conditions in
\ref{sec:wrMasterFSMstart}) and sends the LOCK WR Signaling message to request the WR Slave
to start syntonization.
\item The WR Slave sends the LOCKED WR Signaling message as soon as the syntonization process is
finished (notification from the hardware).
\item The WR Master sends the CALIBRATE WR Signaling message to request calibration pattern.
\item The WR Master sends the CALIBRATE WR Signaling message to request the calibration pattern.
It calibrates its transmission and reception fixed delay.
\item The WR Master sends the CALIBRATED WR Signaling message as soon as the calibration is
finished (notification from hardware).
\item The WR Slave sends the CALIBRATE WR Signaling message tto request calibration pattern.
\item The WR Slave sends the CALIBRATE WR Signaling message to request the calibration pattern.
It calibrates its transmission and reception fixed delay.
\item The WR Slave sends the CALIBRATED WR Signaling message as soon as the calibration is
finished (notification from hardware).
\item The WR Master sends the WR\_MODE\_ON WR Signaling message to indicate completion of the WR
Link Setup process.
\item The WR Master periodically sends a Sync message (timestamped on transmission, $t_1$) followed
by a Follow\_UP message which carries $t_1$.
by a Follow\_Up message which carries $t_1$.
\item The WR Slave receives the Sync message sent by the master (timestamped on reception, $t_2$).
\item The WR Slave receives the Follow\_Up message sent by the master.
\item The WR Slave sends a Delay\_Req message (timestamped on transmission, $t_3$).
\item The WR Master receives the Delay\_Req message sent by the slave (timestamped on reception, $t_4$).
\item The WR Master sends a Delay\_Resp message which carries $t_4$.
\item The WR Slave receives the Delay\_Resp.
\item The WR Slave adjusts its clock using the offset and the delay calculated with the timestamps
($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$) corrected due to the precise knowledge of the link delay.
It results in the slave's synchronization with the master clock with sub-ns accuracy.
\item The WR Slave adjusts its clock using the clock offset and the link delay calculated with
the timestamps ($t_{1}$, $t_{2}$, $t_{3}$, $t_{4}$). This results in the slave's synchronization
with the master clock with sub-ns accuracy.
\item Repeat 1, 11-18.
\end{enumerate}
......@@ -724,7 +709,7 @@ wrConfig & portDS & NON\_WR, & - & S & - \\
wrMode & portDS & NON\_WR,\footnotemark[2] & NON\_WR & D & - \\
& & WR\_SLAVE, & & & \\
& & WR\_MASTER & & & \\ \hline
wrModeON & portDS & TRUE, FALSE & FLASE & D & - \\ \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[3]\\ \hline
knownDeltaRx & portDS & UInteger64 & - & S & [$2^{16}$ps]\footnotemark[3]\\ \hline
......@@ -747,7 +732,7 @@ parentWrConfig & portDS & NON\_WR, & NON\_WR & D & - \\
parentWrMode & portDS & NON\_WR, & NON\_WR & D & - \\
& & WR\_SLAVE, & & & \\
& & WR\_MASTER & & & \\ \hline
parentWrModeON & portDS & TRUE, FALSE & FALSE & D & - \\ \hline
parentWrModeOn & portDS & TRUE, FALSE & FALSE & D & - \\ \hline
parentCalibrated & portDS & TRUE, FALSE & FALSE & D & - \\ \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
otherPortDeltaTx & portDS & UInteger64 & 0x0 & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
......@@ -765,7 +750,7 @@ primarySlavePortNumber & currentDS & UInteger16 & 0x0
\footnotetext[2]{Not re-initialized on exiting IDLE state of WR State Machine.}
\footnotetext[3]{The value of $\Delta_{tx_m,rx_s,rx_m,tx_s}$ measured in picoseconds and
multiplied by $2^{16}$.}
\footnotetext[4]{Maximum shall be smaller then AnnounceInterval (see PTP).}
\footnotetext[4]{Maximum shall be smaller than AnnounceInterval (see PTP).}
\footnotetext[5]{Maximum shall be 32.}
\addtocounter{footnote}{4}
......@@ -777,7 +762,7 @@ multiplied by $2^{16}$.}
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 Data set members shall be initialized before leaving the PTP INITIALIZATION state,
\item Static members shall be initialized to the implementation-specific values meeting the
specifications for the member.
\end{itemize}
......@@ -789,7 +774,7 @@ of the following events:
\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).
(if not defined by implementation, the default values in Table~\ref{tab:wrDSdefault} shall be used).
......@@ -817,11 +802,11 @@ wrStateRetry & portDS & 3 \\ \hline
\subparagraph{wrConfig} Determines the predefined function of a WR Port:
\begin{itemize}
\item WR\_M\_AND\_S shall be a default on boundary and non-slave-only ordinary clocks.
\item WR\_SLAVE shall be default on WR Node which is a slave-only ordinary clock.
\item WR\_M\_AND\_S shall be the default on boundary and non-slave-only ordinary clocks.
\item WR\_SLAVE shall be the default on a WR Node which is a slave-only ordinary clock.
\item WR\_MASTER shall be default on a WR Node (ordinary clock) which is, by design,
supposed to be always connected to a primary source of time, so-called master-only.
\item NON\_WR might be used on any kind of clock to disable WRPTP protocol on a given port.
\item NON\_WR might be used on any kind of clock to disable the WRPTP protocol on a given port.
Such configuration can result from administrative constraints or requirements.
\end{itemize}
......@@ -829,24 +814,24 @@ wrStateRetry & portDS & 3 \\ \hline
\label{par: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:
sections~\ref{sec:wrSlaveFSMstart}~and~\ref{sec:wrMasterFSMstart}.
The WR-role is recommended or active depending on the value of wrModeOn:
\begin{itemize}
\item wrMode is recommended when wrModeON is FALSE.
\item wrMode is active when wrModeON is TRUE.
\item wrMode is \textit{recommended} when wrModeOn is FALSE.
\item wrMode is \textit{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
A WR Port in WR\_SLAVE mode is called a WR Slave. Similarly, a WR Port in WR\_MASTER mode is
called WR Master.
The wrMode field shall be re-setted to NON\_WR on the reception of HW\_LINK\_DOWN hardware
event notification (see \ref{sec:hwOutput}) and on reception ANNOUNCE\_RECEIPT\_TIMEOUT\_EXPIRES
event on the WR Slave.
The wrMode field shall be reset to NON\_WR on the reception of HW\_LINK\_DOWN hardware
event notification (see \ref{sec:hwOutput}) and on reception of an
ANNOUNCE\_RECEIPT\_TIMEOUT\_EXPIRES event on the WR Slave.
\subparagraph{wrModeON}
\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, consequently the role defined in wrMode is active.
It is set to TRUE on successful completion of WR State Machine (WR\_LINK\_ON state,
It is set to TRUE on successful completion of the WR State Machine (WR\_LINK\_ON state,
section~\ref{wrFSM}).
It is set to FALSE :
......@@ -854,7 +839,7 @@ It is set to FALSE :
\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}.
\item on exiting PTP\_SLAVE state.
\item on exiting the PTP\_SLAVE state.
\end{itemize}
......@@ -910,18 +895,19 @@ generated (see \ref{sec:wrEventsAndConditions}).
\subparagraph{calPeriod}
\label{par:calPeriod}
Calibration period in microseconds required to perform measurement of deltaTx and deltaRx fixed
delays (see \ref{sec:fixedDelays}). Its value shall be less than the
value of AnnounceInterval of PTP determined by the portDS.logAnnounceInterval
Calibration period in microseconds required to perform the measurement of the deltaTx and deltaRx
fixed delays (see \ref{sec:fixedDelays}). Its value shall be less than the
value of the 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 overwrites wrStateTimeout
for the \textit{CALIBRATION} state of WR State Machine.
It is distributed to the partner-port to determine timeout of its \textit{RESP\_CALIB\_REQ} state.
for the \textit{CALIBRATION} state of the WR State Machine.
It is distributed to the partner-port to determine the timeout of its \textit{RESP\_CALIB\_REQ}
state.
\subparagraph{calRetry}
\label{par:calRetry}
If grater then 0x0, it overwrites wrStateRetry (\ref{par:wrStateRetry}) for
the \textit{CALIBRATION} state of WR State Machine. It is distributed to
the partner port and used to overwrites wrStateRetry for the \textit{RESP\_CALIB\_REQ} state.
If greater then 0x0, it overwrites wrStateRetry (\ref{par:wrStateRetry}) for
the \textit{CALIBRATION} state of the WR State Machine. It is distributed to
the partner port and used to overwrite wrStateRetry for the \textit{RESP\_CALIB\_REQ} state.
The maximum allowed value is 32.
\subparagraph{primarySlavePortNumber}
......@@ -936,10 +922,10 @@ Stores the value of wrConfig of the parent port which is sent in the Announce Me
Stores the value of wrMode of the parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}).
\subparagraph{parentWrModeON}
\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}). It shell be set to TRUE in WR\_LINK\_ON state on the WR Slave.
Stores the value of wrModeOn of the parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}). It shall be set to TRUE in the WR\_LINK\_ON state on the WR Slave.
\subparagraph{parentCalibrated}
\label{par:parentCalibrated}
......@@ -958,23 +944,26 @@ sent in the WRPTP Signaling Message (section~\ref{wrSignalingMSG}).
\subparagraph{otherPortCalPeriod}
\label{par:otherPortCalPeriod}
Stores the value of calPeriod parameter of link-partner port.
Stores the value of the calPeriod parameter of the link-partner port which is
sent in the CALIBRATE message (\ref{par:CALIBRATE}).
If greater than 0, the value defines the time (in microseconds) for which the calibration pattern
should be sent by the receiving port -- it overwrites wrStateTimeout (\ref{par:wrStateTimeout})
for the \textit{RESP\_CALIB\_REQ} state of WR State Machine on the receiving port. It is exchanged
should be sent by the port which received the message -- it overwrites wrStateTimeout
(\ref{par:wrStateTimeout}) for the \textit{RESP\_CALIB\_REQ} state of the WR State Machine
on the receiving port. It is exchanged
during the WR Link Setup by the WRPTP Signaling Message (section~\ref{wrSignalingMSG}).
\subparagraph{otherPortCalRetry}
\label{par:otherPortCalRetry}
Stores the value of calRetry parameter of the link-partner port.
If greater then 0x0, it overwrites the wrStateRetry (\ref{par:wrStateRetry}) for
the \textit{RESP\_CALIB\_REQ} state of WR State Machine on the receiving port.
Stores the value of the calRetry parameter of the link-partner port which is
sent in the CALIBRATE message (\ref{par:CALIBRATE}).
If greater than 0x0, it overwrites the wrStateRetry (\ref{par:wrStateRetry}) for
the \textit{RESP\_CALIB\_REQ} state of the WR State Machine on the receiving port.
\subparagraph{otherPortCalSendPattern}
\label{par:otherPortCalSendPattern}
Stores the value of calSendPattern sent by the WRPTP Signaling Message
(section~\ref{wrSignalingMSG}) which indicates whether sending of calibration pattern is
(section~\ref{wrSignalingMSG}) which indicates whether sending of the calibration pattern is
required.
%\paragraph{parentCalPattern} Stores the value of calPattern parameter of the parent port.
......@@ -985,7 +974,7 @@ required.
\subsubsection{backupParentDS data set specifications}
A boundary clock shall maintain an implementation-specific backupParentDS Data Set for the purpose
of qualifying redundant sources of synchronisation, i.e.:
of qualifying redundant sources of synchronization, i.e.:
\begin{itemize}
\item backup paths to the current grandmaster clock, or
\item paths to alternative grandmaster clock(s).
......@@ -994,14 +983,14 @@ Each entry of the data set contains:
\begin{itemize}
\item backupParentDS.secondarySlavePortNumber - the number of the port on which the Announce
message from backup parent has been received (Secondary Slave port),
message from a backup parent has been received (Secondary Slave port),
\item backupParentDS.backupParentSourcePortIdentity - the portIdentity of the port on the backup
master.
\end{itemize}
The implementation-specific backupParentDS set shall have a minimum capacity of three backup parent
records. The order of the records is established using Data Set Comparison Algorithm as described
in the section~\ref{StadeDecisionAlg}.
records. The order of the records is established using the Data Set Comparison Algorithm as described
in section~\ref{StadeDecisionAlg}.
The initialization rules stated in PTP (clause 8.1.3) apply to the backupParentDS Data Set.
......@@ -1019,7 +1008,7 @@ The Best Master Clock (BMC) algorithm is used in PTP to compare clocks (determin
clock is the \textit{best}) and to recommend the next state of the PTP state machine (Clause 9.3
of PTP). The BMC is used to prune the physical network topology to obtain logical tree(s) with the
\textit{best} clock, the grandmaster (preferably the one synchronized to a primary reference time
source), as a root. In the case when more then one clock in a network is synchronized to a primary
source), as a root. In the case when more than one clock in a network is synchronized to a primary
reference time source, the BMC produces disjoint logic trees. Each tree has a single grandmaster.
As a result of BMC, no more than one port of a Boundary Clock can be in the PTP\_SLAVE state. Such a
......@@ -1038,25 +1027,25 @@ SLAVE ports as mentioned in \cite{Takahide}.
The BMC algorithm includes the State Decision Algorithm (SDA) and the Data Set Comparison
Algorithm (DCA) and defines which fields of Data Sets should be updated depending on the outcome of
the SDA. The modifications to the BMC are detailed below. the DCA is not modified, therefore it is not
mentioned.
the SDA. The modifications to the BMC are detailed below. The DCA is not modified, therefore it is not
discussed.
\subsubsection{State Decision Algorithm (SDA)}
\label{StadeDecisionAlg}
The original SDA is depicted in Figure~26 of the PTP standard. The modified SDA, depicted in
Figure~\ref{fig:modifiedSDA}, enforces $BMC\_SLAVE$ state instead of $BMC\_PASSIVE$ state on the
clocks with Class field value greater then 127 (block-13 of Figure~\ref{fig:modifiedSDA}).
A port being in a $PTP\_SLAVE$ state as a result of SDA modification (block-13) is considered
Figure~\ref{fig:modifiedSDA}, enforces the $BMC\_SLAVE$ state instead of the $BMC\_PASSIVE$ state
on the clocks with Class field value greater than 127 (block-13 of Figure~\ref{fig:modifiedSDA}).
A port being in a $PTP\_SLAVE$ state as a result of the SDA modification (block-13) is considered
a Secondary SLAVE port. The port which enters
the $PTP\_SLAVE$ state based on the decision at block-11, is considered the Primary SLAVE port.
It means that:
This means that:
\begin{itemize}
\item the Primary SLAVE port and the Secondary SLAVE port(s) are synchronized to the same
grandmaster clock but the connection of the Primary SLAVE port is possibly better by path, or
\item the Primary SLAVE port and the Secondary SLAVE port(s) are synchronized to different
grandmaster clocks of the same clockClass range (1-127 or 128-255,see Table~5 of PTP)
but grandmaster clock connected to the Primary SLAVE port is better or better by path.
but the grandmaster clock connected to the Primary SLAVE port is better or better by path.
\end{itemize}
The best qualified Announce messages ($E_{rbest}$, see Clause 9.3.2.3 of PTP) from all Secondary
......@@ -1064,7 +1053,7 @@ SLAVE ports shall be compared with the DCA to determine the "second best master"
masters. The sequence of events is as follows (the idea originated from \cite{Takahide}):
\begin{itemize}
\item The best master is computed with the BMC -- the Primary SLAVE port established (block-11 of
Figure~\ref{fig:modifiedSDA}) and parentDS data set updated (S1), the port's number is
Figure~\ref{fig:modifiedSDA}) and the parentDS data set updated (S1). The port number is
stored in currentDS.primarySlavePortNumber.
\item If the recommended state is $BMC\_SLAVE$ at block-13, the master is considered
a second best master and its data is stored in $E_{srbest}$.
......@@ -1109,7 +1098,7 @@ currentDS.primarySlavePortNumber & set to 0 \\ \hline
\multicolumn{2}{|c|}{portDS} \\ \hline
portDS.parentWrConfig & portDS.wrConfig \\ \hline
portDS.parentWrMode & portDS.wrMode \\ \hline
portDS.parentWrModeON & portDS.wrModeON \\ \hline
portDS.parentWrModeOn & portDS.wrModeOn \\ \hline
portDS.parentCalibrated & portDS.calibrated \\ \hline
\end{tabular}
......@@ -1158,12 +1147,12 @@ fractional nanoseconds part is always included in the messages as defined in the
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 by standard PTP nodes WR TLVs are ignored(section 14.1, PTP),
Unrecognized by standard PTP nodes WR TLVs are ignored(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 in $PTP\_UNCALIBRATED$ state,
the WR Slave mode and starts the Link Setup process (performed in the $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 as well. During the WR Link Setup, communication between the WR Master and
......@@ -1179,7 +1168,7 @@ All PTP messages can be extended by means of a standard \textit{type, length, va
extension mechanism. White Rabbit uses the \textit{ORGANIZATION\_EXTENSION} TLV type \\
(tlvType=0x0003) which is defined in clause 14.3 of PTP. TLVs represented by this type
are designated for vendors and standard organizations to extend the protocol for specific needs.
The organization-specific TLV fields for WR extension are defined and described in
The organization-specific TLV fields for the WR extension are defined and described in
Table~\ref{tab:wrTLVtype}.
\begin{table}[h!]
......@@ -1198,7 +1187,7 @@ Table~\ref{tab:wrTLVtype}.
octets. \\ \hline
\multicolumn{8}{|c|}{OrganizatinId } & 3 & 4 & 0x080030 & OUI owned by CERN. \\
\hline
\multicolumn{8}{|c|}{organizationSubType} & 2 & 7 & magicNumber & e.g.: 0xABCD - identifies WRPTP
\multicolumn{8}{|c|}{organizationSubType} & 2 & 7 & magicNumber & 0xABCD - identifies WRPTP
within protocols identified by CERN's OUI. \\
\cline{9-12} %\hline
\multicolumn{8}{|c|}{} & 1 & 9 & versionNumber& 0x01 - WRPTP version.\\
......@@ -1279,10 +1268,10 @@ 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 wrModeON value
0 &3 & Announce & wrModeOn & The wrModeOn value
(\ref{par:wrModeON}) of the
sending port which shall be
stored in parentWrModeON
stored in parentWrModeOn
(\ref{par:parentWrModeON})
of the receiving port.
% The value of wrModeON
......@@ -1307,13 +1296,13 @@ The \textit{targetPortIdentity} shall be always set to the \textit{clockIdentity
on the other side of the link (conveyed in the Announce Message).
The Signaling Messages are used in WRPTP to trigger transitions in the WR State Machine and exchange
WR-specific parameters. Each message is sent on entering particular states of WR State Machine as
WR-specific parameters. Each message is sent on entering particular states of the WR State Machine as
described in section~\ref{sec:communicationWRfsm}.
The distinction between WR Signaling Messages is made by the \textit{wrMessageId} field of
The distinction between WR Signaling Messages is made by the \textit{wrMessageId} field of the
\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.
within a single link connection (no forwarding). This is ensured by setting the targetPortId
appropriately. The rest of this subsection describes the WRPTP Signaling Messages in detail.
\begin{table}[h!]
\caption{PTP Signaling message fields (Table 33, PTP) }
......@@ -1335,13 +1324,13 @@ appropriately. The rest of this subsection describes the WRPTP Signaling Message
\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
on the link-partner WR Port which starts the 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{LOCKED} Message sent by the WR Slave to the WR Master. It indicates successful
\paragraph{LOCKED} Message sent by the WR Slave to the WR Master. It indicates the successful
completion of frequency locking. The message shall have the format specified in
Table~\ref{tab:wrOtherTLV}.
......@@ -1368,7 +1357,9 @@ Table~\ref{tab:wrOtherTLV}.
\paragraph{CALIBRATE} Message sent by the WR port entering the \textit{CALIBRATION} state (see
\paragraph{CALIBRATE}
\label{par:CALIBRATE}
Message sent by the WR port entering the \textit{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{calSendPattern} flag). If calibration is required, it carries
......@@ -1392,14 +1383,14 @@ 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|}{calSendPattern} & 1 & 12 & The value determines whether calibration
\multicolumn{8}{|c|}{calSendPattern} & 1 & 12 & The value determines whether the 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
$calibrated$ Data Set field
(\ref{par:calibrated}), it shall be
(\ref{par:calibrated}) It shall be
stored in otherPortCalSendPattern
(\ref{par:otherPortCalSendPattern}).
\\ \hline
......@@ -1474,8 +1465,8 @@ 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
\paragraph{WR\_MODE\_ON} Message sent by the WR Master to the WR Slave. It indicates the 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}.
\newpage
......@@ -1486,10 +1477,10 @@ to TRUE). The message shall have the format specified in Table~\ref{tab:wrOtherT
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
Therefore, it is essential for a WR port to implement the 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 \\
Additionally, WRPTP defines the implementation-specific \textit{SYNCHRONIZATION\_FAULT} and \\
\textit{MASTER\_CLOCK\_SELECTED} PTP state transition events, see Figure~\ref{fig:modifiedPtpFSM}.
......@@ -1497,16 +1488,16 @@ Additionally, WRPTP defines implementation-specific \textit{SYNCHRONIZATION\_FAU
\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 the WR Slave mode and PTP\_UNCALIBRATED state,
state with wrModeOn set to TRUE) on the port being in the 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
defined in Clause 9.2.6.13 of PTP) shall occur. Consequently, the PTP\_SLAVE state shall be
entered.
\subsubsection{SYNCHRONIZATION\_FAULT}
\label{sec:synchronizationFault}
The port being in the WR Slave mode and PTP\_SLAVE state shall evaluate values of two WR-specific
parameters: $wrModeON$ (\ref{par:wrModeON}) and $parentWrModeON$ (\ref{par:parentWrModeON}).
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.
......@@ -1541,25 +1532,25 @@ WR Master and WR Slave.
\subsection{White Rabbit State Machine}
\label{wrFSM}
The White Rabbit finite state machine (WR FSM) controls the process of establishing a White Rabbit
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 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.
to the execution of the PTP State Machine. This means that, once the IDLE state of the WR State Machine is
exited (WR State Machine execution started), no transitions on the PTP State Machine shall occur
until the WR State Machine finishes execution and returns to the IDLE state.
WR Link Setup involves the recognition of two
compatible WR ports, syntonization over the physical layer, optional measurement of fixed delays and
exchange of their values across the link. The procedure differs between WR Master and WR Slave,
therefore three states of the WR FSM are Slave-only (entered only if the port is in WR Slave mode)
exchange of their values across the link. The procedure differs between WR Master and WR Slave.
Therefore three states of the WR FSM are Slave-only (entered only if the port is in WR Slave mode)
and one state is Master-only (entered only if the port is in WR Master mode). The WR FSM shall be
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.
Successful completion of WR FSM results in the validation (\textit{wrModeON} set to TRUE)
of recommended WR mode (\textit{wrMode}) and WRPTP synchronization. If EXC\_TIMEOUT\_RETRY
Successful completion of WR FSM results in the validation (\textit{wrModeOn} set to TRUE)
of the recommended WR mode (\textit{wrMode}) and WRPTP synchronization. If EXC\_TIMEOUT\_RETRY
(section \ref{sec:wrEventsAndConditions}) occurs, it means that WR Link Setup failed,
WRPTP synchronisation cannot be established and standard PTP is performed.
WRPTP synchronization cannot be established and standard PTP is performed.
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
......@@ -1571,7 +1562,7 @@ PTP and WR state machines from the power up is presented in Appendix~\ref{ap:ptp
%The WR FSM in
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:
of the 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.wrConfig = ($WR\_S\_ONLY$ \textbf{OR} $WR\_M\_AND\_S$)}\\
......@@ -1615,14 +1606,13 @@ by entering the \textit{M\_LOCK} state only when the following conditions are me
%igure~\ref{fig:modifiedPtpFSM}).
\newpage
%\paragraph{State Description}
\subsubsection{State Description}
Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{fig:wrFSM}.
\newpage
\begin{table}[hp!]
\caption{WR state definition}
\centering
......@@ -1633,16 +1623,16 @@ Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{f
\small
% IDLE & The WR FSM shall be in the IDLE state if the PTP FSM is in a state other than
% UNCALIBRATED or MASTER. \\ \hline
IDLE & The WR FSM shall be in the IDLE state when WR Link Setup is not performed.
IDLE & The WR FSM shall be in the IDLE state while WR Link Setup is not being performed.
\\ \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$
M\_LOCK & Master-only state. Upon entering this state, the WR Master sends the $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. Upon entering this state, WR Slave sends $LOCKED$ message
S\_LOCK & Slave-only state. The WR Slave locks its clock signal to the frequency distributed
over the physical layer by the WR Master. \\ \hline
LOCKED & Slave-only state. Upon entering this state, the WR Slave sends the $LOCKED$ message
to inform that it is syntonized, and waits for the \textit{CALIBRATE} message.
\\ \hline
CALIBRATION & In this state, optional calibration of the port's reception and/or
......@@ -1650,12 +1640,12 @@ CALIBRATION & In this state, optional calibration of the port's reception a
Upon entering this state, the WR Port sends a \textit{CALIBRATE} message to
the other WR Port. If the calibration of reception fixed delay is needed,
the \textit{calSendPattern} flag in the \textit{CALIBRATE} message
is sent to TRUE (0x1). If the calibration is not needed, the
is set to TRUE (0x1). If the calibration is not needed, the
\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 & Upon entering this state, the WR Port sends a \text{CALIBRATED} message with
CALIBRATED & Upon entering this state, the WR Port sends a \text{CALIBRATED} message with the
values of 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}
......@@ -1663,22 +1653,22 @@ RESP\_CALIB\_REQ & The WR Port's action in this state depends on the value of
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
on reception of the \textit{CALIBRATED} message). If the value of the
\textit{calSendPattern} flag is FALSE,
the \textit{CALIBRATED} message is awaited for a timeout of calPeriod or
wrStateTimeout (if calPeriod is 0x0). On the
wrStateTimeout (if calPeriod is 0x0). On
reception of the \textit{CALIBRATED} message, the next state is entered.\\
\hline
WR\_LINK\_ON & Upon entering this state, the WR Master sends WR\_LINK\_ON message.
In this state, the values of \textit{wrModeON (\ref{par:wrModeON})} and
\textit{parentWrModeON (\ref{par:parentWrModeON})} are set to
WR\_LINK\_ON & Upon entering this state, the WR Master sends the WR\_LINK\_ON message.
In this state, the values of \textit{wrModeOn (\ref{par:wrModeON})} and
\textit{parentWrModeOn (\ref{par:parentWrModeON})} are set to
TRUE\footnotemark[6] and the \textit{IDLE} state is entered unconditionally.
The execution of WR FSM is considered to be completed successfully. \\ \hline
The execution of the WR FSM is considered to be completed successfully. \\ \hline
\end{tabular}
\label{tab:wrFSMdesc}
\end{table}
\footnotetext[6]{Depending on the implementation, it might be necessary to update the wrModeON
\footnotetext[6]{Depending on the implementation, it might be necessary to update the wrModeOn
field of the best Foreign Master record (clause 9.3.2.4.1 of PTP).}
\addtocounter{footnote}{1}
......@@ -1700,31 +1690,31 @@ WR\_LINK\_ON & Upon entering this state, the WR Master sends WR\_LINK\_ON
\subsubsection{WR FSM Transition Events and Conditions}
\label{sec:wrEventsAndConditions}
\begin{description}
\item[POWERUP] Turning on power to the device or reseting.
\item[POWERUP] Turning on power to the device or resetting.
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that a WR
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that a
Link Setup is required and that the WR FSM should be executed starting at the
\textit{PRESENT} state, occurs when the condition presented in
\textit{PRESENT} state. It occurs when the condition presented in
section~\ref{sec:wrSlaveFSMstart} is 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
reception of the $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
reception of the WR $LOCK$ Signaling message.
reception of the $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 even notification (\ref{tab:outputWrCommWithHW}) indicating
reception of the hardware event notification (Table~\ref{tab:outputWrCommWithHW}) indicating
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
reception of the $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 \\
reception of the $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.
......@@ -1733,23 +1723,23 @@ WR\_LINK\_ON & Upon entering this state, the WR Master sends WR\_LINK\_ON
% 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 port is
reception of the \text{CALIBRATED} Signaling message. It indicates that the port 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 port.
\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.
reception of the \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, called timeout.
The default 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}, \textit{CALIBRATEION} and \textit{RESP\_CALIB\_REQ}.\\
The timeout for the \textit{REQ\_CALIBRATEION} state shall be overwritten by the
\textit{S\_LOCK}, \textit{LOCKED}, \textit{CALIBRATION} and \textit{RESP\_CALIB\_REQ}.\\
The timeout for the \textit{CALIBRATION} state shall be overwritten 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 overwritten by the otherPortCalPeriod
......@@ -1757,7 +1747,7 @@ WR\_LINK\_ON & Upon entering this state, the WR Master sends WR\_LINK\_ON
\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, CALIB, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_REQ\}}$ times.\\
$n_{\{M\_LOCK, CALIBRATION, CALIBRATED, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_REQ\}}$ times.\\
The default maximum number of state re-entering (retries) is defined by \textit{wrStateRetry}
(\ref{par:wrStateRetry}). The number of $n_{CALIB}$ shall be overwritten by \textit{calRetry}
(\ref{par:calRetry}) and $n_{RESP\_CALIB\_REQ}$ shall be overwritten by otherPortCalRetry
......@@ -1766,7 +1756,7 @@ WR\_LINK\_ON & Upon entering this state, the WR Master sends WR\_LINK\_ON
\item[EXCEED TIMEOUT RETRIES] (abrv. EXC\_TIMEOUT\_RETRY) Indicates that a state
has been re-entered for a maximum number of times \\
($n_{\{M\_LOCK, CALIB, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_REQ\}}$) and
($n_{\{M\_LOCK, CALIBRATION, CALIBRATED, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_REQ\}}$) and
the $n^{th}$ timeout has expired.
\end{description}
......@@ -1777,10 +1767,10 @@ WR\_LINK\_ON & Upon entering this state, the WR Master sends WR\_LINK\_ON
\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
on the same link during the WR Link Setup. The communication is performed using WR Signaling 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}).
triggers a 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 WR Port.
......@@ -1807,48 +1797,24 @@ WR\_MODE\_ON & WR\_LINK\_ON & WR Master & M\_WR\_MODE\_ON \
\label{tab:wrMsgVsEvents}
\end{table}
\newpage
\subsection{Communication between WR State Machine and the hardware}
\subsection{Communication between the WR State Machine and the hardware}
\label{sec:communicationWithHW}
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
(by the WR State Machine) to control syntonization and fixed delay measurement and to retrieve
their values. Additionally, outside of the WR Link Setup process (throughout the normal operation
of the PTP State Machine) an instant detection of the link-down event is necessary.
of the PTP State Machine) a quick detection of the link-down event is necessary.
\subsubsection{Input to hardware}
\label{sec:inputHW}
The information to the hardware by the WR State Machine is inputted on the exiting or entering
The information to the hardware by the WR State Machine is sent 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\_START\_LOCKING & event notification & entering
S\_LOCK WR State & WR Slave \\ \hline
HW\_START\_CALIBRATION\footnotemark[7]
& event notification & entering CALIBRATION
State & WR Slave and WR Master \\ \hline
HW\_ENABLE\_PATTERN & event notification & entering CALIBRATION and
RESP\_CALIB\_REQ WR States & WR Slave and WR Master \\ \hline
HW\_DISABLE\_PATTERN & event notification & exiting CALIBRATION and
RESP\_CALIB\_REQ WR States & WR Slave and WR Master \\ \hline
\end{tabular}
\label{tab:inputWrCommWithHW}
\end{table}
\footnotetext[7]{Calibration is optional and implementation specific.}
\addtocounter{footnote}{1}
\newpage
the hardware about the need to start/stop a process (i.e. syntonization, pattern transmission).
\subsubsection{Output from hardware}
\label{sec:hwOutput}
......@@ -1861,34 +1827,60 @@ The hardware shall communicate two types of information to the WR State Machine
\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.
Table~\ref{tab:outputWrCommWithHW}) by means of polling or interrupt. Its occurrence in other
state than 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 associated event notification (i.e. HW\_CALIBRATED)
and its value shall be stored in the local Data Set, as defined in Table~\ref{tab:outputWrCommWithHW}.
\newpage
\begin{table}[ht!]
\caption{Input to hardware.}
\centering
\begin{tabular}{| p{5.1cm} | p{2cm} | p{5.5cm} | p{2.6cm} |} \hline
\begin{table}[tbp]
\textbf{Hardware input} & \textbf{Type } & \textbf{Sent on } & \textbf{Sent by port} \\
& & & \textbf{in wrMode} \\ \hline
\small
HW\_START\_LOCKING & event notification & entering the
S\_LOCK State & WR Slave \\ \hline
HW\_START\_CALIBRATION\footnotemark[7]
& event notification & entering the CALIBRATION
State & WR Slave and WR Master \\ \hline
HW\_ENABLE\_PATTERN & event notification & entering the CALIBRATION and
RESP\_CALIB\_REQ States & WR Slave and WR Master \\ \hline
HW\_DISABLE\_PATTERN & event notification & exiting the CALIBRATION and
RESP\_CALIB\_REQ States & WR Slave and WR Master \\ \hline
\end{tabular}
\label{tab:inputWrCommWithHW}
\end{table}
\footnotetext[7]{Calibration is optional and implementation specific.}
\addtocounter{footnote}{1}
\begin{table}[ht!]
\caption{Output to hardware.}
\centering
\begin{tabular}{| p{3.4cm} | p{2cm} | p{4cm} | p{2cm} | p{3.2cm} |} \hline
\begin{tabular}{| p{5.1cm} | p{2cm} | p{3.5cm} | p{1.7cm} | p{2.4cm} |} \hline
\textbf{Hardware output}
&\textbf{Type}& \textbf{Evaluated} & \textbf{Evaluated by port} & \textbf{Action} \\
& & & \textbf{in wrMode} & \\ \hline
\small
HW\_CALIBRATED\footnotemark[7]
& event notification & in 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
& event notification & in the CALIBRATION
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 the S\_LOCK State & WR~Slave& Triggers transition in WR State Machine\\ \hline
HW\_LINK\_DOWN & even notification & always & WR~Slave and WR~Master & Defined in \ref{sec:LinkDown}.\\ \hline
%Set wrModeON to FALSE, and wrMode to NON\_WR \\ \hline
$deltaTx$\footnotemark[7]
& UInteger64~\footnotemark[4] & on reception of
& UInteger64~\footnotemark[8] & on reception of
HW\_CALIBRATED & WR~Slave and WR~Master& Save the value in deltaTx DS field.\\ \hline
$deltaRx$\footnotemark[7]
& UInteger64~\footnotemark[4] & on reception of
& UInteger64~\footnotemark[8] & on reception of
HW\_CALIBRATED & WR~Slave and WR~Master& Save the value in deltaRx DS field. \\ \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
......@@ -1900,10 +1892,12 @@ $deltaRx$\footnotemark[7]
\label{tab:outputWrCommWithHW}
\end{table}
\footnotetext[4]{The value of $\Delta_{tx_m,rx_s,rx_m,tx_s}$ measured in picoseconds and
\footnotetext[8]{The value of $\Delta_{tx_m,rx_s,rx_m,tx_s}$ measured in picoseconds and
multiplied by $2^{16}$.}
\addtocounter{footnote}{1}
\newpage
\subsection{Link Down}
\label{sec:LinkDown}
......@@ -1912,29 +1906,29 @@ detection of link down does not mean instant break in the operation of the PTP p
action is taken only after a timeout expires (i.e. PTP State Machine transition and
Data Sets updates).
In WR, any loss of connection on a link performing WRPTP results in syntonization failure
and requires re-establishing of WR Link. Therefore, on reception of HW\_LINK\_DOWN hardware event
and requires re-establishing the WR Link. Therefore, on reception of the HW\_LINK\_DOWN hardware event
notification (\ref{sec:hwOutput}), the following actions shall be performed:
\begin{itemize}
\item wrModeON (\ref{par:wrModeON}) shall be set to the initialization value (Table~\ref{tab:wrDS}).
\item wrModeOn (\ref{par:wrModeON}) shall be set to the initialization value (Table~\ref{tab:wrDS}).
\item wrMode (\ref{par:wrMode}) shall be set to the initialization value (Table~\ref{tab:wrDS}).
\item calibrated (\ref{par:calibrated}) shall be set to the initialization value (Table~\ref{tab:wrDS}).
\item the record of Foreign Masters on the port on which the event occurred shall be cleared.
\end{itemize}
\subsection{Re-establishing WR Link}
\subsection{Re-establishing the 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.
a WR Port in an \textit{active} WR Mode (wrModeOn=TRUE, section~\ref{par:wrMode})
to enforce re-establishing of the WR Link, i.e. by performing the 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
instantiated whenever a WR Port is in the IDLE state of the WR State Machine (regardless of the
PTP state) and the implementation circumstances are detected that require re-establishing
of WR Link.
the WR Link.
The WR\_MODE\_OFF event results in setting wrModeON DS field of a given WR Port to FALSE.
The WR\_MODE\_OFF event results in setting the wrModeOn DS field of a given WR Port to FALSE.
% \subsection{Master-only WR ordinary clocks}
% \label{sec:masterOnly}
......@@ -2100,12 +2094,12 @@ SLAVE & \small The port is synchronizing to the selected master po
\newpage
\section{Sample White Rabbit Hardware Support Implementation}
\section{Example White Rabbit Hardware Support Implementation}
\label{sec:sampleHW}
%\subsection{Introduction}
A White Rabbit switch, described in Tomasz's Wlostowski Master Thesis \cite{tomekMSC},
A White Rabbit switch, described in Tomasz W\l{}ostowski's Master Thesis \cite{tomekMSC},
implements WRPTP and WR Hardware Support for Gigabit Ethernet over fiber.
The most important fragments of the document are cited below (with necessary modifications).
The citation is approved by the author.
......@@ -2230,11 +2224,11 @@ UInteger64 & 64-bit unsigned integer \\ \hline
\section{Computations using the two-step delay request-response mechanism with asymmetry correction}
\label{ap:computationsExplanation}
The method of incorporating asymmetry obtained using WR Link Model by the WR Slave
The method of incorporating asymmetry obtained using the WR Link Model by the WR Slave
is WRPTP-implementation specific. Below, a summary of PTP offset ($<offsetFromMaster>$)
and mean delay ($<meanDelayPath>$) calculations are presented. They are followed by
two methods of including WR asymmetry, with the later being recommended.
The method used might vary between WR Slaves.
The method used might vary among WR Slaves.
\subsection{Overview of PTP offset and mean path delay calculations}
\label{ap:ptpComputations}
......@@ -2351,7 +2345,7 @@ The two-step delay request-response for a boundary or ordinary clock,:
\subsection{WR asymmetry as PTP communication path asymmetry}
The asymmetry obtained using WR Link Model ($asymmetry$, section \ref{sec:delayAsymCal})
The asymmetry obtained using the WR Link Model ($asymmetry$, section \ref{sec:delayAsymCal})
can be seen as a communication path asymmetry $delayAsymmetry$ as defined in 7.4.2
of \cite{IEEE1588}
\begin{equation}
......@@ -2363,31 +2357,31 @@ equations \eqref{eq:Sync_rx} and \eqref{eq:follow_up_rx}.
\subsubsection{Solution for Ethernet over a Single-mode Optical Fiber}
In case of the solution for Ethernet over a single-mode Optic Fiber
In the case of the solution for Ethernet over a single-mode Optic Fiber
(section\ref{sec:EthernetOverSingleModeFiber}), it can be calculated using directly
the equation~\eqref{eq:aqasymm}, where $\mu$ is $<meanDelayPath>$ obtained using
equation~\eqref{eq:aqasymm}, where $\mu$ is $<meanDelayPath>$ obtained using
equation~\eqref{eq:meanPathDelay}:
\begin{equation}
\label{eq:delayAsymmetry}
delayAsymmetry= \Delta_{tx_m} + \Delta_{rx_s} - \frac{\Delta - \alpha * <meanDelayPath>
+ \alpha * \Delta}{2 + \alpha}
\end{equation}
It needs to be noted, that the $delayAsymmetry$ used in calculation of $<meanDelayPath>$ and
$<offsetFromMaster>$ is computed based on a previous measurement of the $<meanDelayPath>$.
It needs to be noted, that the $delayAsymmetry$ used in calculation of $<meanDelayPath>$ and\\
$<offsetFromMaster>$ is computed based on a previous measurement of the \\$<meanDelayPath>$.
This is because the standard \cite{IEEE1588} seems to assume that, if available, the
$delayAsymmetry$ is constant and known in advance.
Therefore, a direct incorporation of the asymmetry calculated using WR Link Model into
Therefore, a direct incorporation of the asymmetry calculated using the WR Link Model into
$<meanDelayPath>$ and $<offsetFromMaster>$ is recommended.
\subsection{Direct WR asymmetry incorporation into PTP computations}
The asymmetry obtained using WR Link Model ($asymmetry$, section \ref{sec:delayAsymCal})
The asymmetry obtained using the WR Link Model ($asymmetry$, section \ref{sec:delayAsymCal})
can be incorporated directly into the computation
of $<meanDelayPath>$ and $<offsetFromMaster>$. In such case, the $delayAsymmetry$ as defined
in 7.4.2 of \cite{IEEE1588}, is set to 0x0 (equations \eqref{eq:Sync_rx} and
\eqref{eq:follow_up_rx}). The $<meanDelayPath>$ value is calculated using \eqref{eq:meanPathDelay}
and corrected with $asymmetry$ to obtain $<pathDelay_{MS}>$
and corrected with $asymmetry$ to obtain $<pathDelay_{MS}>$,
\begin{equation}
\label{eq:pathDelayMS}
<pathDelay_{MS}>= <meanDelayPath> + asymmetry
......@@ -2407,8 +2401,7 @@ which is used to compute $<offsetFromMaster>$ using \eqref{eq:offset}:
\subsubsection{Solution for Ethernet over a Single-mode Optical Fiber}
A WR Slave, which assumed communication path asymmetry to be 0 ($delayAsymmetry=0$) and measured
timestamps $t_2$ and $t_3$, can calculate the timestamps measured by the WR Master
and send with PTP messages as follows:
timestamps $t_2$ and $t_3$, can assemble the timestamps received from the WR Master follows:
\begin{align}
\label{eq:t1}
t_1 &= Follow\_Up.preciseOriginTimestamp \\
......@@ -2422,7 +2415,7 @@ and
\end{align}
Having all timestamps ($t_1$, $t_2$, $t_3$, $t_4$), the fixed delays
($\Delta_{txm}$,$\Delta_{rxs}$, $\Delta_{txs}$, $\Delta_{rxm}$) and relative delay coefficient
($\alpha$), the WR Link Model can be combined with PTP computation to obtain directly the
($\alpha$), the WR Link Model can be combined with the PTP computation to obtain directly the
correct values of $<delayPath_{MS}>$ and $<offsetFromMaster>$ :
\begin{eqnarray}
<delayPath_{MS}> & = & \frac{1+\alpha}{2+\alpha}
......@@ -2464,7 +2457,7 @@ Control Systems}.
07/2010.
\bibitem{tomekMSC}
Tomasz Wlostowski
Tomasz W\l{}ostowski
\emph{Precise time and frequency transfer in a White Rabbit network}.
Warsaw University of Technology,
05/2011.
......@@ -2491,7 +2484,7 @@ Control Systems}.
1990.\\
\bibitem{icalepcs09}
J. Serrano, P. Alvarez, M. Cattin, E. G. Cota, J. H. Lewis, P. Moreira, T. Wlostowski
J. Serrano, P. Alvarez, M. Cattin, E. G. Cota, J. H. Lewis, P. Moreira, T. W\l{}ostowski
and others,
\emph{The White Rabbit Project}.
ICALEPCS TUC004,
......
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