Skip to content

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

wrspec.v2: modifications based on feedback from ptpx implementation

parent b46bf27b
Hide whitespace changes
Inline Side-by-side
Showing with 175217 additions and 178425 deletions
src/fig/SDA.ps
View file @ 3040362e
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/ptpAndWrFSMs.ps
View file @ 3040362e
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/src/SDA.cdr
View file @ 3040362e
No preview for this file type
src/fig/src/wrFSM.cdr
View file @ 3040362e
No preview for this file type
src/fig/wrFSM.ps
View file @ 3040362e
This source diff could not be displayed because it is too large. You can view the blob instead.
src/fig/wrMSGsExchangeFlow.ps
View file @ 3040362e
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 @ 3040362e
......@@ -31,7 +31,7 @@ transferred between the master and the slave according to the following scheme:
output and then extracted from the data stream at the slave's receiver. The
recovered clock (2) is a copy of clock (1) delayed by $delay_{MS}$, where
\begin{equation}
\label{eq:delayms}
\label{eq:delayms2}
delay_{MS} = \Delta_{txm} + \delta_{ms} + \Delta_{rxs}
\end{equation}
expresses the master-to-slave latency introduced by the transceivers and
......
src/wrspec.tex
View file @ 3040362e
......@@ -54,6 +54,8 @@
{-3.25ex\@plus -1ex \@minus -.2ex}%
{0.0001pt \@plus .2ex}%
{\normalfont\normalsize\bfseries}}
%\renewcommand{\thefootnote}{\fnsymbol{footnote}}
\renewcommand{\thefootnote}{\alph{footnote}}
\counterwithin{paragraph}{subsubsection}
\counterwithin{subparagraph}{paragraph}
......@@ -70,9 +72,9 @@
\begin{document}
\title{White Rabbit Specification: \\Draft for Comments}
\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}
\date{May 2011}
\date{July 2011}
\maketitle
\thispagestyle{empty}
......@@ -103,6 +105,7 @@
\begin{table}[ht!]
%\begin{table}[tbp]
%\caption{White Rabbit Specification Revision History Table }
\centering
\begin{tabular}{| c | c | c | p{8cm} |} \hline
......@@ -139,14 +142,38 @@
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
1.3 & 7/06/2011 & M.L. & Added Appendices: \\
& & & 1.~Extract from Tomek's MSc. \\
& & & 2.~WR computation of offset and delay with asymmetry correction.\\
\hline
\end{tabular}
\label{tab:revHist}
\end{table}
\newpage
\begin{table}[ht!]
%\begin{table}[tbp]
%\caption{White Rabbit Specification Revision History Table }
\centering
\begin{tabular}{| c | c | c | p{8cm} |} \hline
\textbf{Version} & \textbf{Date} & \textbf{Authors} & \textbf{Description} \\
& & \textcolor{white}{E.V.D.B., J.S} &\\ \hline
1.4 & 02/07/2011 & M.L. & Changes based on ptpx daemon implementation: \\
& & & 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.\\
& & & 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
\end{tabular}
\label{tab:revHist}
\end{table}
\newpage
......@@ -188,16 +215,16 @@ to achieve sub-ns accuracy thanks to the precise knowledge of the link delay.
%
% \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}).
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}.
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}).
The described single-link synchronization can be replicated.
Multi-link WR networks are obtained by chaining WR links forming a
hierarchical topology. This hierarchy is imposed by the fact that
......@@ -206,7 +233,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 clocks distribute the frequency
(WR Nodes), see section~\ref{sec:definitions}. A WR boundary clock distribute the frequency
and time retrieved from the upstream link to all the downstream links.
\begin{figure}[ht!]
......@@ -432,10 +459,10 @@ The delay asymmetry can then be derived from equations \eqref{eq:delayms}, \eqre
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 understand
hardware requirements is necessary to understanding the protocol itself.
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:
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.
......@@ -447,7 +474,7 @@ The requirement for The White Rabbit Hardware Support are as follows:
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}.
A sample hardware implementation is described in details in Appendix~\ref{sec:sampleHW}.
\begin{figure}[ht!]
\centering
......@@ -462,6 +489,7 @@ A sample hardware implementation is described in details in the Appendix~\ref{se
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.
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
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
......@@ -471,8 +499,8 @@ the transmit/receive (Rx/Tx) fixed delays introduced by PHY (section~\ref{sec:fi
\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,
components (ex. PHY, SFP) and FPGA internal latencies (see Appendix~\ref{s:asymmetry}
for fixed delays in WR optical link model). Such delays may be constant for
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
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
......@@ -482,15 +510,16 @@ The PHY's delays are measured (if necessary) and their values are distributed ac
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.
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.
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.
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}.
non-deterministic Gigabit Ethernet PHY -- detection of the clock signal's phase difference on
the input and output of the PHY (detailed description in Appendix~\ref{sec:calibForGigbitE}).
\subsection{Timestamps}
\label{sec:timestamps}
......@@ -513,8 +542,7 @@ and falling edges of the clock. It is provided with the phase measurement of the
($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{s:fine_delay}.
Details of the implementation of the presented solution are included in Appendix~\ref{s:fine_delay}.
......@@ -557,6 +585,10 @@ PTP messaging facilities.
WRPTP is compliant with standard PTP. Figure~\ref{fig:hybrid-network} depicts the tree topology
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,
the standard PTP protocol will be used for synchronization.
\begin{figure}[ht!]
\centering
......@@ -597,12 +629,12 @@ as depicted in Figure~\ref{fig:wrptpMSGs} and described below:
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 of its
reception fixed delay.
\item The WR Master sends the CALIBRATE WR Signaling message to request 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 to request calibration of its
reception fixed delay.
\item The WR Slave sends the CALIBRATE WR Signaling message tto request 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
......@@ -612,12 +644,12 @@ 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 master (timestamped on reception, $t_4$).
\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.
It results in the slave's synchronization with the master clock with sub-ns accuracy.
\item Repeat 1, 11-18.
\end{enumerate}
......@@ -631,21 +663,23 @@ 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. The frequency retrieved
on the active slave port is distributed by the master port(s).\\
and maintains the timescale used in the domain. It may serve as the source of time and frequency,
i.e., be a master clock, and may synchronize and syntonize to another clock,
i.e., be a slave clock. The frequency retrieved by the slave clock is re-distributed
to syntonize other slave clocks connected to its ports.\\
\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.\\
and maintains the timescale used in the domain. It may serve as a source of time and frequency,
i.e., be a master clock, or may synchronize and syntonize to another clock,
i.e., be a slave clock.\\
\\
This document introduces the following definitions:\\
\textbf{White Rabbit Port (WR Port)}: a WRPTP-enabled port of a boundary clock
or an ordinary clock.\\
\textbf{White Rabbit Master (WR Master)}: a WRPTP-enabled port of a boundary clock or an
ordinary clock which acts as a source of timing information for another White Rabbit enabled port of
ordinary clock which acts as a source of time and frequency 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 the frequency and the timing information sent over a link by
ordinary clock which retrieves time and frequency sent over a link by
the WR Master.\\
\textbf{White Rabbit Switch (WR Switch)}: a boundary clock implementing WRPTP, compatible with
standard PTP. \\
......@@ -660,7 +694,7 @@ standard PTP. \\
\label{sec:wrDS}
The PTP standard defines data sets (DS) to store the static and dynamic variables needed for the
operation of the protocol (section 8, PTP). WRPTP:
operation of the protocol (clause 8, PTP). WRPTP:
\begin{itemize}
\item adds fields to the DSs defined in the PTP standard to store the WR-specific parameters,
\item defines a new DS: backupParentDS.
......@@ -687,23 +721,23 @@ wrConfig & portDS & NON\_WR, & - & S & - \\
& & WR\_S\_ONLY, & & & \\
& & WR\_M\_ONLY, & & & \\
& & WR\_M\_AND\_S & & & \\ \hline
wrMode & portDS & NON\_WR, & NON\_WR & D & - \\
wrMode & portDS & NON\_WR,\footnotemark[2] & 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
knownDeltaTx & portDS & UInteger64 & - & S & [$2^{16}$ps]\footnotemark[3]\\ \hline
knownDeltaRx & portDS & UInteger64 & - & S & [$2^{16}$ps]\footnotemark[3]\\ \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
deltaTx & portDS & UInteger64 & knownDeltaTx & D & [$2^{16}$ps]\footnotemark[3]\\ \hline
deltaRx & portDS & UInteger64 & knownDeltaRx & D & [$2^{16}$ps]\footnotemark[3]\\ \hline
wrStateTimeout & portDS & UInteger32 & - & S & [ms]\\ \hline
wrStateRetry & portDS & UInteger8 & - & S & - \\ \hline
calPeriod & portDS & UInteger32\footnotemark[4]& - & S & [us]\\ \hline
calRetry & portDS & UInteger8\footnotemark[5]& - & S & -\\ \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
parentWrConfig & portDS & NON\_WR, & NON\_WR & D & - \\
......@@ -714,10 +748,13 @@ 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
parentCalibrated & portDS & TRUE, FALSE & FALSE & D & - \\ \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
otherPortDeltaTx & portDS & UInteger64 & 0x0 & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
otherPortDeltaRx & portDS & UInteger64 & 0x0 & D & [$2^{16}$ps]\footnotemark[2]\\ \hline
otherPortCalPeriod & portDS & UInteger32 & 0x0 & D & [us]\\ \hline
otherPortCalRetry & portDS & UInteger8 & 0x0 & D & - \\ \hline
otherPortCalSendPattern & portDS & TRUE, FALSE & FALSE & D & - \\ \hline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
primarySlavePortNumber & currentDS & UInteger16 & 0x0 & D & - \\ \hline
......@@ -725,10 +762,12 @@ primarySlavePortNumber & currentDS & UInteger16 & 0x0
\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
\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[3]{Maximum shall be smaller then AnnounceInterval (see PTP)}
\addtocounter{footnote}{2}
\footnotetext[4]{Maximum shall be smaller then AnnounceInterval (see PTP).}
\footnotetext[5]{Maximum shall be 32.}
\addtocounter{footnote}{4}
\newpage
......@@ -745,7 +784,7 @@ In particular:
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 exiting IDLE state of the WR State Machine (except for wrMode).
\item EXCEED TIMEOUT RETRIES transition event.
\end{itemize}
The initialization values of dynamic WR fields are specified in Table~\ref{tab:wrDS}, while
......@@ -766,7 +805,8 @@ 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
calRetry & portDS & port number + 2 \\ \hline
wrStateTimeout & portDS & 1000 [ms] \\ \hline
wrStateRetry & portDS & 3 \\ \hline
\end{tabular}
......@@ -775,13 +815,19 @@ wrStateRetry & portDS & 3 \\ \hline
\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{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\_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.
Such configuration can result from administrative constraints or requirements.
\end{itemize}
\subparagraph{wrMode} Contains the current WR-role of a WR Port which is determined using the modified
\subparagraph{wrMode}
\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:
......@@ -791,13 +837,16 @@ The WR-role is recommended or active depending on the values of wrModeOn:
\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.
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.
\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.
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 WR\_LINK\_ON state,
It is set to TRUE on successful completion of WR State Machine (WR\_LINK\_ON state,
section~\ref{wrFSM}).
It is set to FALSE :
......@@ -805,6 +854,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.
\end{itemize}
......@@ -812,24 +862,26 @@ It is set to FALSE :
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}}$.
If the transmission fixed delay ($\Delta_{tx}$) is not known a priori (i.e. a non-deterministic
PHY is used, see \ref{sec:fixedDelays}), it shall be set to 0x0.
Otherwise, it stores the value of $\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}}$.
If the reception fixed delay ($\Delta_{rx}$) is not known a priori (i.e. a non-deterministic
PHY is used, see \ref{sec:fixedDelays}), it shall be set to 0x0.
Otherwise, it stores the value of $\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.
TRUE if the fixed delays are known a priori (a deterministic PHY is used) 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.
If TRUE, it indicates that the fixed delays of the given port are currently known (measured and
stored in deltaTx/deltaRx DS fields).
\subparagraph{deltaTx}
\label{par:deltaTx}
......@@ -845,31 +897,35 @@ Port's $\Delta_{rx}$ measured in picoseconds and multiplied by ${2^{16}}$.
% 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
Determines the default 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}).
generated (see \ref{sec:wrEventsAndConditions}).
%\paragraph{calPatternLen} Number of bits of calPattern to be repeated.
\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
(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.
%\paragraph{wrAlpha} \textit{Relative delay coefficient} described in
% section~\ref{sec:singlefiber}.
\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.
The maximum allowed value is 32.
\subparagraph{primarySlavePortNumber}
If 0, no Primary Slave is selected. 1, 2 ,...N --value of the
Zero value indicates that no Primary Slave is selected. 1, 2 ,...N -- values indicate the
portNumber (clause 7.5.2.3 PTP) selected as the Primary Slave, see section~\ref{sec:wrBMC}.
\subparagraph{parentWrConfig}
......@@ -883,31 +939,43 @@ Stores the value of wrMode of the parent port which is sent in the Announce Mess
\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}).
(section~\ref{sec:wrAnnounceMSG}). It shell be set to TRUE in WR\_LINK\_ON state on the WR Slave.
\subparagraph{parentCalibrated}
\label{par:parentCalibrated}
Stores the value of calibrated of the parent port which is sent in the Announce Message
Stores the value of calibrated of the link-parent port which is sent in the Announce Message
(section~\ref{sec:wrAnnounceMSG}).
\subparagraph{parentDeltaTx}
\label{par:parentDeltaTx}
Stores the value of deltaTx of the parent port exchanged during the WR Link Setup. It is
\subparagraph{otherPortDeltaTx}
\label{par:otherPortDeltaTx}
Stores the value of deltaTx of the link-partner port exchanged during the WR Link Setup. It is
sent in the WRPTP Signaling Message (section~\ref{wrSignalingMSG}).
\subparagraph{parentDeltaRx}
\label{par:parentDeltaRx}
Stores the value of deltaRx of the parent port exchanged during the WR Link Setup. It is
\subparagraph{otherPortDeltaRx}
\label{par:otherPortDeltaRx}
Stores the value of deltaRx of the partner port exchanged during the WR Link Setup. It is
sent in the WRPTP Signaling Message (section~\ref{wrSignalingMSG}).
\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
\subparagraph{otherPortCalPeriod}
\label{par:otherPortCalPeriod}
Stores the value of calPeriod parameter of link-partner port.
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
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.
\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
required.
%\paragraph{parentCalPattern} Stores the value of calPattern parameter of the parent port.
......@@ -920,7 +988,7 @@ A boundary clock shall maintain an implementation-specific backupParentDS Data S
of qualifying redundant sources of synchronisation, i.e.:
\begin{itemize}
\item backup paths to the current grandmaster clock, or
\item paths to alternate grandmaster clock(s).
\item paths to alternative grandmaster clock(s).
\end{itemize}
Each entry of the data set contains:
......@@ -977,9 +1045,10 @@ mentioned.
\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. A port being
in a $PTP\_SLAVE$ state as a result of SDA modification (block-8 and block-13 of
Figure~\ref{fig:modifiedSDA}) is considered a Secondary SLAVE port. The port which enters
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
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:
\begin{itemize}
......@@ -987,7 +1056,7 @@ It means that:
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 the connection of the Primary SLAVE port is possibly better by path.
but 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
......@@ -997,10 +1066,11 @@ masters. The sequence of events is as follows (the idea originated from \cite{Ta
\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
stored in currentDS.primarySlavePortNumber.
\item If the recommended state is $BMC\_SLAVE$ at block-8 or block-13, the master is considered
\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}$.
\item The BMC algorithm is executed on all the $E_{srbest}$.
\item The best master selected is considered second best master.
\item The best master selected is considered second best master and its reception port is
considered the best Secondary SLAVE port.
\item The BMC is repeated excluding $E_{srbest}$ of the best master until the set of $E_{srbest}$
is empty.
\end{itemize}
......@@ -1030,12 +1100,17 @@ The modifications to the rules governing the update of the data sets are twofold
\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
\begin{tabular}{| p{7.5cm} | p{7.5cm}|} \hline
\textbf{Update this field} &
\textbf{From the indicated field of the defaultDS data set of the clock unless otherwise stated} \\
& \\ \hline
currentDS & \\ \hline
\multicolumn{2}{|c|}{currentDS} \\ \hline
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.parentCalibrated & portDS.calibrated \\ \hline
\end{tabular}
\label{tab:modifiedM1M2}
......@@ -1044,10 +1119,10 @@ currentDS.primarySlavePortNumber & set to 0 \\ \hline
\begin{table}[tbp]
\caption{Modification to Table~16 of IEEE1588-2008: Update for state decision code S1.}
\centering
\begin{tabular}{| c | c |} \hline
\begin{tabular}{| p{7.5cm} | p{7.5cm}|} \hline
\textbf{Update this field} & \textbf{From the indicated source} \\
& \\ \hline
currentDS & \\ \hline
\multicolumn{2}{|c|}{currentDS} \\ \hline
currentDS.primarySlavePortNumber & portDS.portIdentity.portNumber \\ \hline
\end{tabular}
......@@ -1057,10 +1132,10 @@ currentDS.primarySlavePortNumber & portDS.portIdentity.portNumber \\ \hline
\begin{table}[tbp]
\caption{Update for state decision code S2}
\centering
\begin{tabular}{| c | c |} \hline
\begin{tabular}{| p{8.5cm} | p{6.5cm}|} \hline
\textbf{Update this field} & \textbf{From the indicated source} \\
& \\ \hline
backupParentDS & \\ \hline
\multicolumn{2}{|c|}{backupParentDS} \\ \hline
backupParentDS.secondarySlavePortNumber & portDS.portIdentity.portNumber \\ \hline
backupParentDS.backupParentSourcePortIdentity & sourcePortIdentity of $E_{rbest}$ \\ \hline
......@@ -1083,15 +1158,15 @@ 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 TLVs are ignored by standard PTP nodes (section 14.1, PTP), but read and interpreted by
White Rabbit nodes.
Unrecognised 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 during $PTP\_UNCALIBRATED$ state,
see Appendix~\ref{ap:ptpAndWrFSMS}). The WR Slave requests the sender of the WRPTP announce message
the WR Slave mode and starts the Link Setup process (performed in $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 Link Setup process as well. 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).
......@@ -1144,7 +1219,7 @@ sections.
\caption{White Rabbit Message ID values}
\centering
\begin{tabular}{| l | p{2.5cm} | c | c |} \hline
\textbf{managementId name} & \textbf{wrMessageId value (hex)} & \textbf{Sent in message type} \\
\textbf{WR Message Name} & \textbf{wrMessageId value (hex)} & \textbf{Sent in message type} \\
& & \\ \hline
SLAVE\_PRESENT & 0x1000 & Signaling \\ \hline
LOCK & 0x1001 & Signaling \\ \hline
......@@ -1231,8 +1306,8 @@ 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).
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
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
described in section~\ref{sec:communicationWRfsm}.
The distinction between WR Signaling Messages is made by the \textit{wrMessageId} field of
......@@ -1293,7 +1368,7 @@ Table~\ref{tab:wrOtherTLV}.
\paragraph{CALIBRATE} Message sent by the WR port entering the REQ\_CALIBRATION state (see
\paragraph{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
......@@ -1312,23 +1387,33 @@ Table~\ref{tab:wrCalibrateTLV}.
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \\
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x0003, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x14. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x0E. \\ \hline
\multicolumn{8}{|c|}{OrganizationId } & 3 & 4 & 0x080030. \\ \hline
\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} & 2 & 12 & The value determines whether calibration
\multicolumn{8}{|c|}{calSendPattern} & 1 & 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})
$calibrated$ Data Set field
(\ref{par:calibrated}), it shall be
stored in otherPortCalSendPattern
(\ref{par:otherPortCalSendPattern}).
\\ \hline
\multicolumn{8}{|c|}{calRetry (UInteger8)} & 1 & 13 & The calRetry value
(\ref{par:calRetry})
of the sending port which shall be stored
in otherPortCalRetry
(\ref{par:otherPortCalRetry}) of
the receiving port.\\ \hline
\multicolumn{8}{|c|}{calPeriod (UInteger32)} & 4 & 14 & The calPeriod value
(\ref{par:calPeriod})
of the sending port which shall be stored
in parentCalPeriod
(\ref{par:parentCalPeriod}) of
in otherPortCalPeriod
(\ref{par:otherPortCalPeriod}) of
the receiving port.\\ \hline
% \multicolumn{8}{|c|}{calibrationPattern} & 4 & 18 & The value defines the calibration pattern
% which should be sent by the receiving
......@@ -1363,21 +1448,21 @@ The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & & \textbf{Offset} & \textbf{Content} \\
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x0003, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x28. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x18. \\ \hline
\multicolumn{8}{|c|}{OrganizationId } & 3 & 4 & 0x080030. \\ \hline
\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 (UInteger64) } & 16 & 12 & The deltaTx value (\ref{par:deltaTx})
\multicolumn{8}{|c|}{deltaTx (UInteger64) } & 8 & 12 & The deltaTx value (\ref{par:deltaTx})
of the sending port which shall be stored
in parentDeltaTx (\ref{par:parentDeltaTx})
in otherPortDeltaTx (\ref{par:otherPortDeltaTx})
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})
\multicolumn{8}{|c|}{deltaRx (UInteger64) } & 8 & 20 & The deltaRx value (\ref{par:deltaRx})
of the sending port which shall be stored
in parentDeltaRx (\ref{par:parentDeltaRx})
in otherPortDeltaRx (\ref{par:otherPortDeltaRx})
of the receiving port.
% The value of $\Delta_{rx_m}$ measured in
% picoseconds and multiplied by ${2^{16}}$.
......@@ -1405,16 +1490,14 @@ Therefore, it is essential for a WR port to implement PTP\_UNCALIBRATED state as
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}.
\textit{MASTER\_CLOCK\_SELECTED} PTP state transition events, 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,
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
entered.
......@@ -1422,7 +1505,7 @@ entered.
\subsubsection{SYNCHRONIZATION\_FAULT}
\label{sec:synchronizationFault}
The port being in WR\_Slave mode and PTP\_SLAVE state shall evaluate values of two WR-specific
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}).
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
......@@ -1465,10 +1548,10 @@ exited (WR State Machine execution started), no transitions on the PTP State Mac
until 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, measurement of fixed delays and
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 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
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.
......@@ -1480,7 +1563,7 @@ WRPTP synchronisation 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
PTP and WR state machines from power up is presented in Appendix~\ref{ap:ptpAndWrFSMS}.
PTP and WR state machines from the power up is presented in Appendix~\ref{ap:ptpAndWrFSMS}.
\subsubsection{Conditions to enter WR Slave mode and start the WR FSM}
\label{sec:wrSlaveFSMstart}
......@@ -1543,12 +1626,15 @@ Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{f
\begin{table}[hp!]
\caption{WR state definition}
\centering
\begin{tabular}{| c | p{11cm} |} \hline
\begin{tabular}{| c | p{12.2cm} |} \hline
\textbf{PTP portState} & \textbf{Description} \\
& \\ \hline
%& \\
\hline
\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 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.
\\ \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$
......@@ -1559,19 +1645,18 @@ S\_LOCK & Slave-only state. The WR Slave locks its logic to the freq
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 port's reception fixed delay can
be performed.
CALIBRATION & In this state, optional calibration of the port's reception and/or
transmission fixed delays can be performed.
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
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
\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
information about its fixed delays. \\ \hline
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}
message. A TRUE value of the flag
......@@ -1580,20 +1665,23 @@ RESP\_CALIB\_REQ & The WR Port's action in this state depends on the value of
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
the \textit{CALIBRATED} message is awaited for a timeout of calPeriod or
wrStateTimeout (if calPeriod is 0x0). On the
reception of the \textit{CALIBRATED} message, the next 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
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
TRUE\footnotemark[6] 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}
\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}
\begin{figure}[ht!]
\centering
......@@ -1616,22 +1704,23 @@ WR\_LINK\_ON & Upon entering this state by the WR Master, it sends WR\_LI
\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, occurs when conditions presented in section~\ref{sec:wrSlaveFSMstart}
are fulfilled.
\textit{PRESENT} state, 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
the \textit{M\_LOCK} state.
\item[LOCK MESSAGE] (abrv. M\_LOCK) Event triggered by the
receoption of the WR $LOCK$ Signaling message.
reception 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.
reception of the hardware even notification (\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 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
......@@ -1655,28 +1744,30 @@ WR\_LINK\_ON & Upon entering this state by the WR Master, it sends WR\_LI
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
\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 timeout for the following states is defined by \textit{wrStateTimeout}
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},
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{S\_LOCK}, \textit{LOCKED}, \textit{CALIBRATEION} and \textit{RESP\_CALIB\_REQ}.\\
The timeout for the \textit{REQ\_CALIBRATEION} 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 defined by the parentCalPeriod
(\ref{par:parentCalPeriod}), 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
(\ref{par:otherPortCalPeriod}), 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 (wrStateRetry, \ref{par:wrStateRetry}) and
the \textit{wrStateTimeout} (\ref{par:wrStateTimeout}) has expired for the $n + 1$
time.
$n_{\{M\_LOCK, CALIB, CALIBed, 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
(\ref{par:otherPortCalRetry}) if their values are greater then 0x0. Otherwise,
\textit{wrStateRetry} shall be used.
\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
the $n^{th}$ timeout has expired.
\end{description}
......@@ -1692,11 +1783,11 @@ upon entering a particular state of WR State Machine. The same message received
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.
of their transmission and the event they trigger on the reception WR Port.
It also specifies the WR Mode of the sending port.
\begin{table}[tbp]
\begin{table}[ph!]
\caption{Communication between WR State Machines on different Boundary Clocks.}
\centering
\begin{tabular}{| l | c | p{2.5cm} | c |} \hline
......@@ -1716,18 +1807,19 @@ 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}
\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
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).
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.
\subsubsection{Input to hardware}
\label{sec:inputHW}
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
......@@ -1740,23 +1832,22 @@ the hardware about a need to start/stop a process (i.e. syntonisation, pattern t
\textbf{Hardware input} & \textbf{Type } & \textbf{Sent on } & \textbf{Sent by port} \\
& & & \textbf{in wrMode} \\ \hline
HW\_ENABLE\_LOCKING & event notification & entering
HW\_START\_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
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
\subsubsection{Output from hardware}
......@@ -1770,31 +1861,35 @@ 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 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}.
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}.
\begin{table}[tbp]
\caption{Input to hardware.}
\caption{Output to hardware.}
\centering
\begin{tabular}{| p{3.4cm} | p{2cm} | 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
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
HW\_LINK\_DOWN & even notification & always & WR~Slave and WR~Master & Set wrModeON to FALSE, and wrMode to NON\_WR \\ \hline
$deltaTx$ & UInteger64~\footnotemark[4] & on reception of
HW\_CALIBRATED & WR~Slave and WR~Master& Save the value in deltaTx data field on evaluation\\ \hline
$deltaRx$ & UInteger64~\footnotemark[4] & on reception of
HW\_CALIBRATED & WR~Slave and WR~Master& Save value in deltaTx data field on evaluation \\ \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
HW\_CALIBRATED & WR~Slave and WR~Master& Save the value in deltaTx DS field.\\ \hline
$deltaRx$\footnotemark[7]
& UInteger64~\footnotemark[4] & 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
% $t_{3}$ & Integer64 & on sending Delay\_Req message & WR~Slave & Save\\ \hline
......@@ -1809,6 +1904,24 @@ $deltaRx$ & UInteger64~\footnotemark[4] & on reception of
multiplied by $2^{16}$.}
\addtocounter{footnote}{1}
\subsection{Link Down}
\label{sec:LinkDown}
Standard PTP can accommodate a temporary connection loss on a link performing the protocol. Therefore
detection of link down does not mean instant break in the operation of the PTP protocol. Appropriate
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
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 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}
\label{sec:reestablishingWRLink}
......@@ -1818,18 +1931,29 @@ 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
PTP state) and the implementation circumstances are detected 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.
The WR\_MODE\_OFF event results in setting wrModeON DS field of a given WR Port to FALSE.
% \subsection{Master-only WR ordinary clocks}
% \label{sec:masterOnly}
%
% A WR Node may be designated to be a master-only. A master-only WR Node shall be a WR-compatible
% non-slave-only (as defined in PTP) ordinary clock with the following changes to a default WR
% configuration:
% \begin{itemize}
% \item wrConfig = WR\_M\_ONLY.
% \item clockClass = 70 (see \ref{sec:wrptpProfile}).
% \end{itemize}
\newpage
\subsection{White Rabbit PTP Profile Summary}
\subsubsection{Identification}
\label{sec:wrptpProfile}
\begin{table}[tbp]
\begin{table}[ph!]
\caption{Profile print form (clause 19.3.3 of PTP)}
\centering
\begin{tabular}{| c | c |} \hline
......@@ -1879,14 +2003,14 @@ The TLV mechanism described in section~\ref{sec:wrMSG} shall be supported.
WRPTP shall implement the following implementation-specific features:
\begin{itemize}
\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},
as described in section~\ref{sec:wrMSG},
\item proper handling of PTP messages with a WR TLV as described in \ref{sec:wrMSG},
\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{sec:synchronizationFault}.
\item MASTER\_CLOCK\_SELECTED state transition as defined in \ref{sec:masterClockSelected}.
\item SYNCHRONIZATION\_FAULT state transition as defined in \ref{sec:synchronizationFault},
\item MASTER\_CLOCK\_SELECTED state transition as defined in \ref{sec:masterClockSelected},
\item communication with hardware as described in \ref{sec:communicationWithHW}.
\end{itemize}
......@@ -1984,6 +2108,7 @@ SLAVE & \small The port is synchronizing to the selected master po
A White Rabbit switch, described in Tomasz's Wlostowski 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.
% Figure \ref{fig:ptp_wr_flow} shows the order of the PTP message exchanges
% during all the phases of the synchronization process, indicating which
......@@ -2090,7 +2215,7 @@ The most important fragments of the document are cited below (with necessary mod
\caption{Primitive data types}
\centering
\begin{tabular}{| c | c |} \hline
\textbf{Data type } & \textbf{Definition} \\ \hline
\textbf{Data type } & \textbf{Definition} \\
& \\ \hline
UInteger8 & 8-bit unsigned integer \\ \hline
UInteger16 & 16-bit unsigned integer \\ \hline
......@@ -2109,7 +2234,7 @@ The method of incorporating asymmetry obtained using WR Link Model by the WR Sla
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 can vary between WR Slaves.
The method used might vary between WR Slaves.
\subsection{Overview of PTP offset and mean path delay calculations}
\label{ap:ptpComputations}
......@@ -2260,7 +2385,7 @@ $<meanDelayPath>$ and $<offsetFromMaster>$ is recommended.
The asymmetry obtained using 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 be 0 (equations \eqref{eq:Sync_rx} and
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}>$
\begin{equation}
......
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