[time-nuts] PLL on FPGA

[Magnus Danielson]

From: "Pablo Alvarez Sanchez" <Pablo.Alvarez.Sanchez at cern.ch>
Subject: [time-nuts] PLL on FPGA
Date: Mon, 6 Aug 2007 17:32:26 +0200
Message-ID: <42A60383A3EA19429E22C122E276B2F48C4AFA at cernxchg44.cern.ch>

> Hi Everybody, 

Hi Pablo,

> Thanks a lot for your help concerning the Ethernet question. It seems we
> will stick to a custom made timing network for the moment. 

It might be a wise choice. If you can afford the dedicated cabling, it will
make the nodes much simpler for the same performance.

> In any case I would like to describe you the principles of the PLL we
> use in our timing system.
> 
> **First of all our timing signal nowadays consists of a data stream
> Manchester encoded at 500kB/s (1MHz carrier). Data are  always sent in
> packets of 4 bytes, with a preamble and codes violations at the
> beginning and the end to delimit the frames. Between frames we send a
> 500kHz clock to feed the pll. This the classic CERN timing signal that
> has been around since beginning of the 80s. 
> 
> 
> **The phase detector is fully implemented in the FPGA. The PHD waits for
> at least 3 ticks of the 1MHz carrier to perform a measurement. This way
> I remove the intersymbol interference in more or less reasonable way. To
> do this measurement I use a counter clocked by an external 44.736MHz
> free running oscillator. Then I do an average of 2048 samples and pass
> it to a PI.

What is the rate of messages/samlpes?

What does the messages overhear look like?

What is the detailed format?

> I have put some logic in the PHD to saturate in the extreme values, this
> way I can have very small bandwidths without any lock-in problem. 

As we need to have it.

> In theory if the 44.736MHz XO is uncorrelated with the 1MHZ then the
> noise introduced by it will be of
> 
>  NoisePHD~= (1/12)^.5*Txo/(Nsamples)^.5  ~22ns/3.4/(2048)^.5 ~140ps
> 
> 
> If you measure for one second then you get:
> 
> NoisePHD1sec~22ns/12/(1e6)^.5~ 7ps (this is ~7e-12 in only one second,
> which is not too bad)
> 
> This always relies on the "uncorrelation" of the 44.736MHz with the
> oscillators under test. I don't know if one can really assume this as a
> fact... 

No. You will find alot of discussions about hanging-bridges which is a form of
pseudo-synchronous behaviour which can occur between the local clock and 1 PPS
signals as the local oscillator goes near or crosses a multiple of 1 Hz.
However, the un-even frequency ratio of 44,736 MHz and 1 MHz helps to combat
this. You can however experience biases due to the drift in the XO over the
2048 samples which you either need to consider be below your tolerance (and
thus just disregard) or simply remove by locking the 44,736 MHZ oscillator to
your clock signal, which would be my personal preference. The sample rate is
therefore quite interesting for sake of analysis.

I think you can still use this basic signal structure, but adding the two-way
transfer mechanism. You will need to measure the received time and transfer
that measure in the other direction. Calculations is trivial as I have
indicated. Naturally this require the additional overhead.

> In any case, I guess this can be used as cheap way to compare frequency
> standards.
> 
> 
> **The control is a typical PI. The output is connected to 16 bit DAC
> which drives a TCXO (cft-125 by CMAC). The bandwidth of the loop is
> ~2Hz. When the PLL reference signal is disconnected I pass to the DAC an
> averaged value of the TCXO frequency over ~16 sec

Sounds reasnoble.

> The jitter I measured with a good scope is ~120ps between two modules
> for several minutes. 

Peak-to-Peak or RMS? For pure noise measures only use RMS values!!!

> The hold over I have obtained with the cft-125 is better than 5us for
> 30min (normally much better)

Cheers,
Magnus