From 4f07a6edadffd2a021fd77464e6dc6cf544e28dc Mon Sep 17 00:00:00 2001 From: Hades DAQ Date: Thu, 7 Feb 2013 23:22:12 +0100 Subject: [PATCH] added results of clock-recovery jitter measurement, mt --- trb3/SyncMediaInterface.tex | 40 +++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/trb3/SyncMediaInterface.tex b/trb3/SyncMediaInterface.tex index 010dbd0..c07b8e4 100644 --- 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} -- 2.43.0