Commit 4e0d9f47 authored by Javier Serrano's avatar Javier Serrano

Changes after review with Erik.

parent 819e4f96
......@@ -6,7 +6,11 @@
% best master clock algorithm 6.6.2.3
% domain number, profiles 7.1, annex J (p. 237)
% asymmetry 6.2.c, 7.4.2 (positive if t_MS > t_SM)
%
%
% TODO
% Give the values of different constants in tables.
% Use thicker line for combined state in wr state machine figure.
% Take cursor out of PTP state machine figure.
\documentclass[a4paper, 12pt]{article}
%\documentclass{article}
......@@ -56,19 +60,21 @@
\begin{document}
\title{White Rabbit Specification: \\Draft for Comments}
\author{Emilio G. Cota\\ Maciej Lipinski \\ Tomasz Wlostowski}
\author{Emilio G. Cota\\Maciej Lipinski\\Tomasz W\l{}ostowski\\Erik van der Bij\\Javier Serrano}
\date{September 2010}
\maketitle
\thispagestyle{empty}
\begin{figure}[ht!]
\centering
\vspace{1.3cm}
\includegraphics[width=0.50\textwidth]{fig/wr_logo.ps}
\label{fig:hybrid-network}
\label{fig:wr_logo}
\end{figure}
\newpage
\setcounter{page}{1}
\begin{center}
\large Revision History Table
\end{center}
......@@ -83,23 +89,31 @@
0.1 & 10/09/2010 & E.G., M.L. & First draft for comments. \\ \hline
0.2 & 7/09/2010 & T.W., M.L. & Added introduction about PTP. \\ \hline
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,\\
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,\\
& & & 2.~Changed WR managementIDs,\\
& & & 3.~Added authors, this rev. table, explanatory figures and descriptions.
\\ \hline
0.5 & 17/09/2010 & E.V.D.B., J.S.& 1.~Added Table of Contents. \\
& & & 2.~Re-ordered appendixes. \\
& & & 3.~Fixed some typos. \\
\hline
\end{tabular}
\label{tab:revHist}
\end{table}
\newpage
\tableofcontents
\newpage
\section{Introduction}
White Rabbit (WR) is a protocol developed to synchronize nodes in
a packet-based network with sub-ns accuracy. The protocol results
from the combination of IEEE1588-2008 (PTP)\cite{IEEE1588} with two further
requirements: precise knowledge of the link delay and clock
syntonization\footnote{The adjustment of two electronic circuits or devices in term of frequency.} over the physical layer.
syntonization\footnote{The adjustment of two electronic circuits or devices in terms of frequency.} over the physical layer.
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
......@@ -130,11 +144,10 @@ Multi-link WR networks are obtained by chaining WR links forming a
hierarchical topology. This hierarchy is imposed by the fact that
a frequency traceable to a common grandmaster must be distributed
over the physical layer, resulting in a \textit{cascade} of master
and slave nodes. As a result of this topology, WR~network consists of two kinds of WR network devices:
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 Timing Receivers), see section~\ref{sec:wrptpOverview}. It should be noted that the problem of non-linear
error accumulation of chained boundary clocks does not apply, or is at
least greatly diminished by the clock recovery mechanism.
error accumulation of chained boundary clocks is greatly diminished by the clock recovery mechanism.
\begin{figure}[ht!]
\centering
......@@ -169,8 +182,8 @@ The standard defines two kinds of messages which are exchanged between \textit{P
the time of reception of event messages are \textit{timestamped}. 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 \textit{two-step clock}) is used,
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.
......@@ -186,11 +199,11 @@ An \textit{Announce Message} is periodically broadcast by the PTP node which is
in the Master state. The message carries information about its originator and
the originator's clock source quality. This enables other PTP nodes receiving
the announce message to perform the Best Master Clock (BMC) Algorithm.
The algorithm defines the role of each PTP node in PTP network hierarchy;
This algorithm defines the role of each PTP node in the PTP network hierarchy;
the outcome of the algorithm is the recommended next state of the PTP node and
the node's synchronization source (grandparent). In other words, a PTP node
the node's synchronization source (grandmaster). In other words, a PTP node
decides to which other PTP node it should synchronize based on the information
provided in announce messages and using the BMC algorithm. A PTP node which is in
provided in the announce messages and using the BMC algorithm. A PTP node which is in
the SLAVE state synchronizes to the clock of another PTP node. A PTP node
which is in the MASTER state is regarded as a source of synchronization
for the other PTP nodes. The full PTP state machine with state descriptions
......@@ -205,14 +218,14 @@ and \textit{Delay\_Resp Messages} are used to send timestamps between Master
and Slave (in the case of a two-step clock).
\textit{Management Messages} are used only for configuration and
administrative purposes. They are not essential for the PTP synchronization.
administrative purposes. They are not essential for PTP synchronization.
The flow of events in the PTP delay request-response (two-step clock) mechanism is the following
(simplified overview):
\begin{enumerate}
\item The master sends periodically Announce messages.
\item The slave receives the Announce message, uses the BMC algorithm to establish its place in the network hierarchy.
\item The master sends periodically a Sync message (timestamped on transmission, $t_1$) followed by a Follow\_UP message which carries $t_1$.
\item The master sends Announce messages periodically.
\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$.
\item The slave receives the Sync message sent by the master (timestamped on reception, $t_2$).
\item The slave receives the Follow\_Up message sent by the master.
\item The slave sends a Delay\_Req message (timestamped on transmission, $t_3$).
......@@ -240,7 +253,7 @@ can be expressed as the sum
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
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
master can be decomposed as
......@@ -313,8 +326,7 @@ i.e.
\Delta = \Delta_{tx_m} + \Delta_{rx_s} + \Delta_{tx_s} + \Delta_{rx_m}
\end{equation}
The delay asymmetry as specified in section 7.4.2 of IEEE1588-2008
is expressed in our own notation by using equations \eqref{eq:delayms},
The delay asymmetry as specified in section 7.4.2 of the PTP standard is expressed in our own notation by using equations \eqref{eq:delayms},
\eqref{eq:delaysm} and \eqref{eq:mu} as follows:
\begin{align}
\eqdelay{ms} = \mu + \eqasymm
......@@ -357,15 +369,15 @@ The knowledge of fixed delays $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ is necessary
delay asymmetry \eqref{eq:aqasymm}. Such delays may be constant for the lifetime of the hardware,
its up-time or the duration of the link connection. Therefore, the method for obtaining fixed
delays is medium-specific and implementation-dependent. The delays are measured (if necessary)
and the information about its values is distributed across the link during the process of
and their values are distributed across the link during the process of
establishing the WR link, which is called \textit{WR Link Setup} in this document.
A WR~node participates in the measurement of another
WR node's reception fixed delay ($\Delta_{\{rx_m, rx_s\}}$) upon request, e.g. by sending
a calibration pattern in Gigabit Ethernet. Measurement of fixed delays during WR Link Setup
is optional. It is only required if a non-deterministic reception/transmission elements are used.
is optional. It is only required if non-deterministic reception/transmission elements are used.
An example implementation of the method to obtain fixed delays for non-deterministic Gigabit Ethernet PHY
is described in Appendix~\ref{sec:calibForGigbitE}.
is described in Appendix~\ref{sec:calibForGigbitE}. This fixed delay measurement is optional and in principle needed only once, while the WR link is being set up.
\newpage
......@@ -381,7 +393,7 @@ the White Rabbit extension to the PTP standard will be referred to as \textit{WR
It includes syntonization of the local clock over the physical layer, measurement of fixed delays (calibration)
and distribution of the information about fixed delays over the link. The WR extension takes advantage of the Link Delay Model
to obtain an accurate delay estimation, e.g. it uses the delay asymmetry equation \eqref{eq:aqasymm}
for Gigabit Ethernet over Fiber Optic. WRPTP extends the PTP messages and Data Sets (DS).
for Gigabit Ethernet over Fiber Optic. WRPTP extends the PTP messages and Data Sets (DS) to communicate parameters and state information between a master and a slave.
......@@ -389,7 +401,7 @@ for Gigabit Ethernet over Fiber Optic. WRPTP extends the PTP messages and Data S
\centering
% \vspace{-1.3cm}
\includegraphics[width=0.80\textwidth]{fig/wrptpMSGs.ps}
\caption{Simplified overview of a message flow in WRPTP. }
\caption{Simplified overview of the message flow in WRPTP.}
\label{fig:wrptpMSGs}
\end{figure}
......@@ -398,17 +410,17 @@ 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 (simplified overview):
\newpage
\begin{enumerate}
\item The WR Master sends periodically WR Announce message with the custom suffix.
\item The WR Master periodically sends WR Announce messages with a custom suffix.
\item The WR Slave receives an Announce message, recognizes it as the WR Announce message and uses the modified BMC algorithm to establish its place in the WR network hierarchy.
\item The WR Slave starts WR Link Setup by sending the SLAVE\_PRESENT WR Management message.
\item The WR Master starts sends the LOCK WR Management message to request the WR Slave to start syntonization.
\item The WR Slave sends LOCKED WR Management message as soon as the syntonization process is finished (notification from the hardware).
\item The WR Slave starts the WR Link Setup by sending the SLAVE\_PRESENT WR Management message.
\item The WR Master sends the LOCK WR Management message to request the WR Slave to start syntonization.
\item The WR Slave sends the LOCKED WR Management message as soon as the syntonization process is finished (notification from the hardware).
\item The WR Master sends the CALIBRATE WR Management message to request calibration of its reception fixed delay.
\item The WR Master sends the CALIBRATED WR Management message as soon as the calibration is finished (notification from hardware).
\item The WR Slave sends the CALIBRATE WR Management message to request calibration of its reception fixed delay.
\item The WR Slave sends the CALIBRATED WR Management message as soon as the calibration is finished (notification from hardware).
\item The WR Master sends the WR\_MODE\_ON WR Management message to indicate completion of the WR Link Setup process.
\item The WR Master sends periodically a Sync message (timestamped on transmission, $t_1$) followed by a Follow\_UP message which carries $t_1$.
\item The WR Master periodically sends a Sync message (timestamped on transmission, $t_1$) followed 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$).
......@@ -421,7 +433,7 @@ It results in the Slave's synchronization with the Master clock with sub-ns accu
\item Repeat 1, 11-18.
\end{enumerate}
Since the WR Link Setup is performed in the PTP UNCALIBRATED state, it is essential for a
The WR Link Setup is performed in the PTP UNCALIBRATED state, so it is essential for a
WR node to implement this state as specified in the PTP state machine (Appendix~\ref{ptpFSM}):
a transition state between the LISTENING or PRE\_MASTER or MASTER or PASSIVE state and the SLAVE state.
......@@ -437,8 +449,8 @@ is an ordinary clock with predefined WR Slave functionality (slave node). Proper
is ensured by connecting a WR Slave port to a WR Master port.
Figure~\ref{fig:hybrid-network} depicts the topology of a \emph{hybrid} WR/IEEE1588
network where optimal synchronization with grandmaster is
achieved by connecting a non-WR Slaves to WR Masters.
network where optimal synchronization with a grandmaster is
achieved by connecting non-WR Slaves to WR Masters.
\begin{figure}[ht!]
......@@ -459,7 +471,7 @@ achieved by connecting a non-WR Slaves to WR Masters.
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 requires additional DS fields to store the WR-specific
parameters. Table~\ref{tab:wrDS} defines and describes the additional required DS fields that are not a part of PTP standard.
parameters. Table~\ref{tab:wrDS} defines and describes the additional required DS fields that are not part of the PTP standard.
......@@ -497,7 +509,7 @@ grandmasterWrMode & parentDS & TRUE, FALSE & If TRUE, the
The Best Master Clock algorithm is used in PTP to compare local clocks, to determine which
clock is the \textit{"best"} and to recommend the next state of the PTP state machine (section 9.3, PTP).
It is required from modified BMC that the comparison of a WR Master with a WR Slave or
It is required from the modified BMC that the comparison of a WR Master with a WR Slave or
non-WR clock results in the WR Master being the \textit{"best"} clock. To ensure a proper
BMC outcome, the WR Master $clockClass$ value shall be in the range of 1 through 127
(recommended 6) and the WR Slave $clockClass$ shall be in the range of 128 through 255 (recommended 255).
......@@ -514,8 +526,7 @@ In particular, it adds a suffix to the Announce message, defines a \textit{WR Ty
(WR TLV) type, WR management action and management~IDs.
A White Rabbit Master node announces its presence by adding a WR TLV suffix to the Announce message.
The suffix is defined by PTP standard as a set of TLV entities (section 13.4, PTP),
unrecognized TLVs are ignored by standard PTP nodes (section 14.1, PTP), but read and interpreted by White Rabbit nodes.
The suffix is defined by the PTP standard as a set of TLV entities (section 13.4, PTP). Unrecognized TLVs are ignored by standard PTP nodes (section 14.1, PTP), but read and interpreted by White Rabbit nodes.
The information provided in the WRPTP Announce message is sufficient for a WR Slave to decide
whether the WR link can be established and maintained. The WR link is established through the WR Link
Setup process in the PTP UNCALIBRATED state. If a WR Link Setup is required, the WR Slave starts
......@@ -593,7 +604,7 @@ TLV stores the $wrFlags$ which are defined in Table~\ref{tab:wrFlags}.
\label{wrManagementMSG}
White Rabbit extends the default PTP management mechanism described in section 15.2 of PTP.
The extension conforms to the PTP management message format presented in Table~\ref{tab:wrManagemetnMSG}.
The extension conforms to the PTP management message format presented in Table~\ref{tab:wrManagementMSG}.
It uses the reserved range of \textit{actionField} values (Table 38, PTP) to define a
\textit{White Rabbit Command} (WRC) as described in Table~\ref{tab:wrActionField}.
WRC management messages trigger transitions in WR state machines. They are recognized by the \textit{managementId}
......@@ -621,14 +632,14 @@ exchanged only within one link connection (no forwarding), therefore the \textit
\multicolumn{8}{|c|}{reserved } & 1 & 47 \\ \hline
\multicolumn{8}{|c|}{managementTLV } & M & 48 \\ \hline
\end{tabular}
\label{tab:wrManagemetnMSG}
\label{tab:wrManagementMSG}
\end{table}
\begin{table}[ht]
\begin{table}[ht!]
\caption{White Rabbit value of the actionField}
\centering
\begin{tabular}{| c | p{7.9cm} | c |} \hline
......@@ -693,8 +704,8 @@ The message shall have the format specified in Table~\ref{tab:wrOtherTLV}.
\paragraph{CALIBRATE} Messages sent by the WR node entering the REQ\_CALIBRATION state (see section~\ref{wrFSM}). It informs the other node
whether sending calibration pattern (see section~\ref{sec:fixedDelays}) is required (defined by the value of \textit{calibrationSendPattern} flag).
\paragraph{CALIBRATE} Message sent by the WR node entering the REQ\_CALIBRATION state (see section~\ref{wrFSM}). It informs the other node
whether sending a calibration pattern (see section~\ref{sec:fixedDelays}) is required (defined by the value of \textit{calibrationSendPattern} flag).
If calibration is required, it carries a set of parameters describing
the calibration pattern to be sent. The message format and parameters are described in Table~\ref{tab:wrCalibrateTLV}.
......@@ -712,7 +723,7 @@ the calibration pattern to be sent. The message format and parameters are descri
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0xC, section 15.5.2.3 PTP.\\ \hline
\multicolumn{8}{|c|}{managementId } & 2 & 4 & CALIBRATE.\\ \hline
\multicolumn{8}{|c|}{calibrationSendPattern}& 2 & 6 & The value determines whether calibration pattern should be sent. If the value is 0x1, the calibration pattern is sent. If the value is 0x0, the calibration pattern is not sent. \\ \hline
\multicolumn{8}{|c|}{calibrationPeriod} & 4 & 8 & The value defines the time (in microseconds) for which the calibration pattern should be sent by receiving node.\\ \hline
\multicolumn{8}{|c|}{calibrationPeriod} & 4 & 8 & The value defines the time (in microseconds) for which the calibration pattern should be sent by the receiving node.\\ \hline
\multicolumn{8}{|c|}{calibrationPattern} & 4 & 12 & The value defines the calibration pattern which should be sent by the receiving node.\\ \hline
\multicolumn{8}{|c|}{calibrationPatternLen} & 2 & 14 & The value defines the number of bits of \textit{calibrationPattern} field which should be used as repeated pattern (starting with the LSB). \\\hline
\end{tabular}
......@@ -723,11 +734,11 @@ the calibration pattern to be sent. The message format and parameters are descri
\paragraph{CALIBRATED} Message sent by the WR node entering \textit{CALIBRATED} state.
\paragraph{CALIBRATED} Message sent by a WR node entering the \textit{CALIBRATED} state.
If preceded by the \textit{CALIBRATE} message with \textit{calibrationSendPattern} set to TRUE,
it indicates successful completion of the calibration. The message provides the other node with the
values of its fixed delays ($\Delta_{tx}$ and $\Delta_{rx}$).
The messages shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
The message shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\begin{table}[ht]
\caption{CALIBRATED WR Management TLV}
......@@ -741,7 +752,7 @@ The messages shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
\hline
\multicolumn{8}{|c|}{tlvType } & 2 & 0 & 0x2004, see \ref{sec:wrTLVtype}. \\ \hline
\multicolumn{8}{|c|}{lengthField } & 2 & 2 & 0x24, section 15.5.2.3 IEEE1588 \cite{IEEE1588}. \\ \hline
\multicolumn{8}{|c|}{managementId } & 2 & 4 & MASTER\_CALIBRATED.\\ \hline
\multicolumn{8}{|c|}{managementId } & 2 & 4 & CALIBRATED.\\ \hline
\multicolumn{8}{|c|}{deltaTx } & 16 & 6 & The value of $\Delta_{tx_m}$ measured in picoseconds and multiplied by ${2^{16}}$.\\ \hline
\multicolumn{8}{|c|}{deltaRx } & 16 & 22 & The value of $\Delta_{rx_m}$ measured in picoseconds and multiplied by ${2^{16}}$.\\ \hline
\end{tabular}
......@@ -755,8 +766,6 @@ The messages shall have the format specified in Table~\ref{tab:wrCalibratedTLV}.
the WR Link Setup process and requests the WR~Slave to enter WR~mode. The message shall have the
format specified in Table~\ref{tab:wrOtherTLV}.
\newpage
\subsection{White Rabbit State Machine}
\label{wrFSM}
......@@ -769,25 +778,25 @@ if the node is in WR Master mode). The WR FSM shall be
executed in the PTP UNCALIBRATED state, it is depicted in Figure~\ref{fig:wrFSM} and described in the rest of
this section.
A simplified flow of WR Management Message exchange between a WR Slave and a WR Master during WR Link Setup is presented
in Appedix~\ref{fig:wrFSMcommun}.
A typical flow of a complete WR Management Message exchange between a WR Slave and a WR Master during WR Link Setup is presented
in Appendix~\ref{ap:wr_lsu_flow}.
\subsubsection{Condition to start WR FSM by WR Slave}
\subsubsection{Condition to start the WR FSM by WR Slave}
\label{sec:wrSlaveFSMstart}
The WR FSM in WR Slave exits the IDLE state and starts execution by entering the \textit{PRESENT} state, only when the PTP state machine (Appendix~\ref{ptpFSM})
The WR FSM in a WR Slave exits the IDLE state and starts execution by entering the \textit{PRESENT} state, only when the PTP state machine (Appendix~\ref{ptpFSM})
is in the PTP UNCALIBRATED state and the following conditions are met:
\begin{itemize}
\item the node is WR Slave: \\ ($portDS.wrPortMode = WR\_SLAVE$) \textbf{AND}
\item the parent node is WR Master: \\ ($parentDS.grandmasterWrPortMode = WR\_MASTER$) \textbf{AND}
\item the node is a WR Slave: \\ ($portDS.wrPortMode = WR\_SLAVE$) \textbf{AND}
\item the parent node is a WR Master: \\ ($parentDS.grandmasterWrPortMode = WR\_MASTER$) \textbf{AND}
\item the node or parent node or both nodes are not in WR Mode: \\ (\textit{portDS.wrMode = FALSE OR parentDS.grandmasterWrMode = FALSE}).
\end{itemize}
\subsubsection{Condition to start WR FSM by WR Master}
\subsubsection{Condition to start the WR FSM by WR Master}
\label{sec:wrMasterFSMstart}
The WR Master node shall enter the PTP UNCALBRATED state, and start execution of the WR FSM by entering \textit{LOCK} state, when it receives a SLAVE\_PRESENT WR Management message (Table~\ref{tab:wrManagementId}).
The WR Master node shall enter the PTP UNCALIBRATED state, and start execution of the WR FSM by entering the \textit{LOCK} state, when it receives a SLAVE\_PRESENT WR Management message (Table~\ref{tab:wrManagementId}).
\newpage
......@@ -804,20 +813,20 @@ Table~\ref{tab:wrFSMdesc} specifies the WR states notation used in Figure~\ref{f
\textbf{PTP portState} & \textbf{Description} \\
& \\ \hline
\small
IDLE & WR FSM shall be in the IDLE state if the PTP FSM is in a state other than UNCALIBRATED. \\ \hline
PRESENT & Slave-only state. The WR Slave sends SLAVE\_PRESENT message to the WR Master and waits for the $LOCK$ message.\\ \hline
IDLE & The WR FSM shall be in the IDLE state if the PTP FSM is in a state other than UNCALIBRATED. \\ \hline
PRESENT & Slave-only state. The WR Slave sends a SLAVE\_PRESENT message to the WR Master and waits for the $LOCK$ message.\\ \hline
M\_LOCK & Master-only state. The WR master waits for the WR Slave to finish successfully the locking process. \\ \hline
S\_LOCK & Slave-only state. The WR Slave locks its logic to the frequency distributed over physical layer by the WR Master. \\ \hline
LOCKED & Slave-only state. The WR Slave is syntonized, it sends \textit{LOCKED} message to the WR Master and waits for the \textit{CALIBRATE} message. \\ \hline
LOCKED & Slave-only state. The WR Slave is syntonized, it sends a \textit{LOCKED} message to the WR Master and waits for the \textit{CALIBRATE} message. \\ \hline
REQ\_CALIBRATION & In this state, optional calibration of the node's reception fixed delay can be performed.
The node sends \textit{CALIBRATE} message to the other node. If the calibration is needed,
The node sends a \textit{CALIBRATE} message to the other node. If the calibration is needed,
(\textit{calibrated} is set to false), the \textit{calibrationSendPattern} flag in the \textit{CALIBRATE} message
is sent to TRUE (0x1). If the calibration is not needed, the \textit{calibrationSendPattern} flag is set to FALSE (0x0).
If calibration is not needed, next state is entered directly, otherwise an indication from the hardware
If calibration is not needed, the next state is entered directly, otherwise an indication from the hardware
that the calibration has been finished successfully is awaited. \\ \hline
CALIBRATED & The node sends \text{CALIBRATED} message with information about its fixed delays. \\ \hline
RESP\_CALIB\_REQ & The node's action in this state depends on the value of the \textit{calibrationSendPattern} flag received in the \textit{CALIBRATE} message. TRUE value of the flag
indicates that calibration pattern shall be enabled. The pattern shall be disabled after \textit{calibrationPeriod}
CALIBRATED & The node sends a \text{CALIBRATED} message with information about its fixed delays. \\ \hline
RESP\_CALIB\_REQ & The node's action in this state depends on the value of the \textit{calibrationSendPattern} flag received in the \textit{CALIBRATE} message. A TRUE value of the flag
indicates that the calibration pattern shall be enabled. The pattern shall be disabled after \textit{calibrationPeriod}
or on reception of the \textit{CALIBRATED} message. If the value of the \textit{calibrationSendPattern} flag is FALSE,
the \textit{CALIBRATED} message is awaited for a default timeout. On reception of the \textit{CALIBRATED} message, the next state is entered.\\ \hline
WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \textit{IDLE} state is entered. \\ \hline
......@@ -847,13 +856,13 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\begin{description}
\item[]
\item[POWERUP] Turning on power to the device or reseting.
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that WR Link Setup is required and WR FSM should be executed starting with
\item[WR LINK SETUP REQUIRED DECISION] (abrv. D\_WR\_SETUP\_REQ) Event indicating that a WR Link Setup is required and that the WR FSM should be executed starting at the
\textit{PRESENT} state, see section~\ref{sec:wrSlaveFSMstart}.
\item[LOCK MESSAGE] (abrv. M\_LOCK) WR $LOCK$ Management message which triggers frequency locking over the physical layer.
\item[LOCKED HARDWARE EVENT] (abrv. HW\_LOCKED) Indication from the hardware that frequency locking has been completed successfully.
\item[LOCKED MESSAGE] (abrv. M\_LOCKED) WR $LOCKED$ Management message which notifies the WR Master that frequency locking has been completed
successfully by the WR Slave.
\item[CALIBRATE MESSAGE] (abrv. M\_CALIBRATE) WR $CALIBRATE$ Management message. It request the recipient to enter
\item[CALIBRATE MESSAGE] (abrv. M\_CALIBRATE) WR $CALIBRATE$ Management message. It requests the recipient to enter the
\textit{RESP\_CALIB\_REQ} state, indicates whether sending of the calibration pattern is required and
provides calibration parameters.
\item[CALIBRATED HARDWARE EVENT] (abrv. HW\_CALIBRATE) Notification from the hardware indicating that calibration has been completed successfully.
......@@ -861,14 +870,13 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
If the \textit{CALIBRATED} message is received when the calibration pattern is being sent by the recipient,
sending of the pattern shall be disabled. The message carries information about fixed delays of the sending node.
\item[WR MODE ON] (abrv. M\_WR\_MODE\_ON) WR \textit{WR\_MODE\_ON} Management message. It indicates that the WR Master finished successfully
WR Link Setup and set the \text{wrMode} flag to TRUE. It requests the WR Slave to set the \text{wrMode} flag to TRUE.
\item[RETRY $n_{name}$] White Rabbit state machine waits in a given state for a transition event only for a limited time (\textit{TIMEOUT})
the WR Link Setup and set the \text{wrMode} flag to TRUE. It requests the WR Slave to set the \text{wrMode} flag to TRUE.
\item[RETRY $n_{name}$] The White Rabbit state machine waits in a given state for a transition event only for a limited time (\textit{TIMEOUT})
The states to which this rule applies are the following: \textit{M\_LOCK},
\textit{REQ\_CALIBRATEION}, \textit{CALIBRATED}, \textit{PRESENT}, \textit{S\_LOCK},
\textit{LOCKED}, \textit{RESP\_CALIB\_REQ}. After the \textit{TIMEOUT} expires, the state is re-entered for \\
$n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$ number of times.
\item[EXCEED TIMEOUT RETRIES] (abrv. EXC\_TIMEOUT\_RETRY) Indicates that the state has been re-entered for a set number of times ($n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$
and the \textit{TIMEOUT} has expired for the $n + 1$ time.
\item[EXCEED TIMEOUT RETRIES] (abrv. EXC\_TIMEOUT\_RETRY) Indicates that the state has been re-entered for a set number of times \\($n_{\{M\_LOCK, REQ\_CAL, CALIBed, PRESENT, S\_LOCK, LOCKED, RESP\_CALIB\_RESP\}}$) and the \textit{TIMEOUT} has expired for the $n + 1$ time.
\end{description}
......@@ -881,37 +889,6 @@ WR\_LINK\_ON & The value of \textit{wrMode} is set to TRUE and the \texti
\normalsize
\appendix
\section{Measurement of fixed delays for Gigabit Ethernet over Optic Fiber}
\label{sec:calibForGigbitE}
The variation of $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ delays is often caused by
the PHY's serializer / deserializer (SerDes), phase locked loop (PLL) or clock and
data recovery circuitry (CDR). The delay on the PHY can be measured by detecting
the phase shift between SerDes I/O and Tx/Rx clock. This can be done, in example, by sending
a repeated pattern of five "0" and five "1" (0000011111) over Gigabit Ethernet.
Such signal creates a 125~MHz clock on the SerDes I/O. Since the Tx/Rx clock
frequency is 125~MHz, the phase shift between the SerDes I/O and the Tx/Rx
clocks is equal to the fixed delay of the PHY (see Figure~\ref{fig:wrCalibration}).
The repeated pattern of five "0" and five "1" is an example of
\textit{calibration pattern} which is defined by the node requesting calibration.
The calibration pattern used to describe the methods is not compliant with 8b/10b encoding standard.
For the real-life implementation, a 8b/10b compliant pattern is preferable.
\begin{figure}[ht!]
\centering
\includegraphics[width=0.60\textwidth]{fig/calibrate.ps}
\caption{Measurement of fixed delays $\Delta_{\{tx, rx\}}$ in Gigabit Ethernet-based WR node with not full-deterministic PHY.}
\label{fig:wrCalibration}
\end{figure}
Measurement of fixed delays for Gigabit Ethernet over optic fiber, and any other medium, is optional.
It is not needed if deterministic PHYs or internal FPGA transceivers which can be internally
characterized \cite{Peek2010} are used. In such case, the information about the fixed delays is distributed across
the link without preceding measurement.
\newpage
\section{PTP State Machine}
\label{ptpFSM}
......@@ -959,18 +936,51 @@ UNCALIBRATED & \small One or more master ports have been detected in the
master port has been selected, and other implementation-specific activity. \\ \hline
SLAVE & \small The port is synchronizing to the selected master port. \\ \hline
\end{tabular}
\label{tab:wrManagementId}
\label{tab:ptp_port_state_def}
\end{table}
\newpage
\section{Flow of WR Management message exchange between a WR Master and a WR Slave (no exceptions) during WR Link Setup}
\section{Measurement of fixed delays for Gigabit Ethernet over Optic Fiber}
\label{sec:calibForGigbitE}
The variation of $\Delta_{\{tx_m, rx_s, tx_s, rx_m\}}$ delays is often caused by
the PHY's serializer / deserializer (SerDes), phase locked loop (PLL) or clock and
data recovery circuitry (CDR). The delay on the PHY can be measured by detecting
the phase shift between SerDes I/O and Tx/Rx clock. This can be done, for example, by sending
a repeated pattern of five "0" and five "1" (0000011111) over Gigabit Ethernet.
Such signal creates a 125~MHz clock on the SerDes I/O. Since the Tx/Rx clock
frequency is 125~MHz, the phase shift between the SerDes I/O and the Tx/Rx
clocks is equal to the fixed delay of the PHY (see Figure~\ref{fig:wrCalibration}).
The repeated pattern of five "0" and five "1" is an example of
\textit{calibration pattern} which is defined by the node requesting a calibration.
The calibration pattern used to describe the methods is not compliant with the 8b/10b encoding standard.
For real-life implementation, a 8b/10b compliant pattern is needed.
\begin{figure}[ht!]
\centering
\includegraphics[width=0.60\textwidth]{fig/calibrate.ps}
\caption{Measurement of fixed delays $\Delta_{\{tx, rx\}}$ in Gigabit Ethernet-based WR node with not fully-deterministic PHY.}
\label{fig:wrCalibration}
\end{figure}
Measurement of fixed delays for Gigabit Ethernet over optic fiber, and any other medium, is optional.
It is not needed if deterministic PHYs or internal FPGA transceivers which can be internally
characterized \cite{Peek2010} are used. In such case, the information about the fixed delays is distributed across
the link without preceding measurement.
\newpage
\section{Typical flow of WR Management message exchange}
\label{ap:wr_lsu_flow}
\begin{figure}[ht!]
\centering
% \vspace{-1.3cm}
\includegraphics[width=1.0\textwidth]{fig/wrMSGsExchangeFlow.ps}
\caption{Flow of events (no exceptions) during WR Link Setup.}
\caption{Typical flow of events (no exceptions) during WR Link Setup.}
\label{fig:wrFSMcommun}
\end{figure}
......
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