[time-nuts] PLL on FPGA

Pablo Alvarez Sanchez Pablo.Alvarez.Sanchez at cern.ch
Mon Aug 6 12:49:23 EDT 2007


 

> -----Original Message-----
> From: Magnus Danielson [mailto:magnus at rubidium.dyndns.org] 
> Sent: Monday, August 06, 2007 6:03 PM
> To: time-nuts at febo.com; Pablo Alvarez Sanchez
> Subject: Re: [time-nuts] PLL on FPGA
> 
> 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>

> > **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?
> 
You can have a look to the signal in the attached document. 
RS-485. The slaves never drive the cable.


> > 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.
>

You are right, that is why I chose 44.736MHz. This is the most
uncorrelated number I found respect to 1MHZ.
If the frequency was a perfect 44.736 then the sampling sequence would
repeat every 125us. Fortunately this is not true and
normally there is a 44.736XXX...

The ideal way to operate would be to take a 44.736 TCXO and connect its
voltage control to an extreme. Or even better, a combination of a DPLL
and an analogue PLL where you make always sure that the PHD oscillator
is always uncorrelated and never locked to the 1MHz. 

The reference signal also has some jitter (1ns rms). This jitter is also
quite helpful to remove noise from the PHD. 


> 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 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!!!


This is RMS 


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

Cheers 

Pablo 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TimingSignal.GIF
Type: image/gif
Size: 71283 bytes
Desc: TimingSignal.GIF
Url : http://www.febo.com/pipermail/time-nuts/attachments/20070806/8a98f138/attachment-0001.gif 


More information about the time-nuts mailing list