added results of clock-recovery jitter measurement, mt

diff --git a/trb3/SyncMediaInterface.tex b/trb3/SyncMediaInterface.tex
index 010dbd0da256e5e20baa6722d77049674634ba7f..c07b8e49df43e262c1e17bca0eb10e3f1b2b4d45 100644 (file)
--- a/trb3/SyncMediaInterface.tex
+++ b/trb3/SyncMediaInterface.tex
@@ -6,6 +6,46 @@
  \item Links toward the read-out run in clock-synchronous mode only, i.e. the round-trip time for a packet can be measured with one word length (currently 5 ns) precision only.
 \end{itemize*}
 
+\subsection{Clock Measurements}
+To check the limits of the clock recovery circuitry of the FPGAs a system
+consiting of 5 TRB3 was setup. One master TRB3 with the TRBHub design in one
+peripheral FPGA, 4 slaves, where 3 of the slaves were in one chain, and the
+4th slave was connected to the master as a single board. So, each slave
+reveived the clock of the level above in the central FPGA (FPGA5) where the
+clock was recovered. This clock is then used to communicate to the peripheral
+FPGA, where again a HUB-design was running. This peripheral FPGA again
+recovered the clock. And so on.
+
+This means the clock-recover and transmit was done for each FPGA, so in total
+6 times on the chain with the 3 TRB3.
+
+The measurement shows the following:
+\begin{itemize*}
+\item the scope *shows* the clock itself with a jitter of 10ps. In reality it
+  is known that the jitter is several hundred femto seconds, so this is
+  the offset of the measurement. The analysis was done with the installed ``Advanced
+  Jitter Software'' on a Tektronix-Scope.
+\item after the first clock recovery of the SERDES clock we measure a
+  clock jitter of 30ps sigma
+\item after 6 recoveries in a chain we measure 40ps sigma.
+\item The recovered clocks of the two branches, one with one TRB3 as a leaf
+  and the other with a chain of 3 TRB3s show the are phase locked.
+\item The transmission of data didn't show any transmission errors for a full
+  day.
+\end{itemize*}
+
+All done without jitter cleaner.
+
+The time-trend analysis of the measured deviations of the recovered clock to
+the ideal clock shows already after the first recovery that there is very
+small random jitter, but a dominant sinodial time deviation with a frequency
+of 4MHz. This suggests that a jitter cleaner (if the time constants are too
+short) will not help a lot and that the jitter comes from the power-supply of
+the FPGAs-PLL-circuitry. The DC/DC-converters on the TRB3 run with 4MHz, which
+can be a coincidence, but directly points to them as the source of the
+deterministic ``jitter'' (period length oscillation). This has to be
+investigaed further to be understood in detail.
+
 
 \subsection{Media Interfaces}