[time-nuts] PLL on FPGA
magnus at rubidium.dyndns.org
Mon Aug 6 14:49:17 EDT 2007
From: "Pablo Alvarez Sanchez" <Pablo.Alvarez.Sanchez at cern.ch>
Subject: RE: [time-nuts] PLL on FPGA
Date: Mon, 6 Aug 2007 18:49:23 +0200
Message-ID: <42A60383A3EA19429E22C122E276B2F48C4AFC at cernxchg44.cern.ch>
> > -----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.
Mmm, well almost.
> If the frequency was a perfect 44.736 then the sampling sequence would
> repeat every 125us.
This is what to expect since 44,736 MHz comes from the DS3/T3 Baudrate and
bitrate (it is a trinary system carrying a binary bitstream). 8 kHz being a
natural constant for all telecom equipment.
> 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.
Indeed. Since you are using an 40 MHz clock locally and steer it, and then a
44,736 MHz clock for interpolation measurements, it should not be very hard to
create a suitable locking. Considering the noise, you don't have to make the
44,736 MHz tweaked so it only makes an integer number of cycles over the 2048
samples, but a much lower number can be used and the noise will help with the
Is your sample/message rate that of 8 kHz?
If you use 125 Hz as your comparator frequency for the 44,736 MHz clock from
the 40 MHz clock, then the noise will be more than sufficient to smooth out
the quantization steps while the full 2048 samples integration would run over
even and synchronous cycles assuming the 8 kHz sample rate.
> The reference signal also has some jitter (1ns rms). This jitter is also
> quite helpful to remove noise from the PHD.
Indeed. Since you have long runs of static clock and then measure in the
preamble, most of the data-dependent jitter has been removed and you have only
remaining gaussian noise and possibly some hum.
> > > 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
It is high then. You should be able to get better performance.
More information about the time-nuts