PLL tricks

[rickman]

On 9/14/2014 4:41 AM, Jan Panteltje wrote:

On a sunny day (Sat, 13 Sep 2014 14:28:39 -0700) it happened John Larkin
jlarkin@highlandtechnology.com> wrote in
44d91adte3vc7jipnapet6okglevfn40qm@4ax.com>:

You can't do any better than the phase comparator. So I can see why he
want's that as good as possible. But the delays introduced *after* the
phase comparator will not produce phase errors. That delay is only of
consequence to the loop stability.

Right. The dflop phase detector has such high equivalent gain that the
downstream lowpass won't add significant time error.

John, I was thinking last night about this problem,
but I quickly, for the 1 ps jitter case, got curious about your 10 MHz reference.
For sure that needs to be 'better'.
Is it a sinewave? A symmetrical square wave? Rise times?

The flip-flop phase comparators are noisy by themselves,
in precise nanosecond locking systems I have worked with, you first lock to
frequency with a simple phase comparator, and then after frequency lock
switch to a second more precise phase comparator, and sometimes even a third.
I have never done a pico second accurate lock.
Anyway after frequency lock you switch to the normal PID lock, I have used sample and hold
on a ramp for that, so you are in linear range and no 'bang bang' noise is present.
If the system is knocked out of lock, then you go back to frequency comparator etc.
For the PID case you can set gain and I and D compensation and you like.

I just read John's post where he said the reference clock will have 10's
of ps jitter or that he can add it, so what is the point of a 1 ps
accurate PD?

--

Rick

 

[John Larkin]

On Sun, 14 Sep 2014 07:58:17 +0100, "Kevin Aylward"
<ExtractkevinRemove@kevinaylward.co.uk> wrote:

"John Larkin" wrote in message
news:1h291ahulit12anamhhlu27hrapque4mai@4ax.com...


Why not go out and buy a 9.7200MHz +/-10ppm crystal, and lock your
155.52MHz VCXO to that via a divide-by-sixteen counter?

You'll have to have your eight crystals ground to give exactly the right
frequencies, but there are small businesses that make a living out of
producing bespoke crystals.

Ahmmmm..... 155.52 Mhz is so bog standard that every xtal/oscillator
company
under the sun has xtals and oscillators in the golden range of 10MHz to 50
Mhz that can be multiplied exactly up. e.g. 38.88Mhz and 19.44MHz. I know,
because my company has then in stock, and my current asic design uses them!

"19.44 MHz crystal" gets 2800 hits

I was going to suggest this right off the bat, but assumed they was some
system reason why he cant do that.
My box will receive a 10 MHz reference from the customer, from some
expensive Symmetrix GPS-disciplined thing. I'll also get a 1 PPS pulse
from that, and time-of-day data over Ethernet. It's my job to make
OC3-like optical data frames, at 155.52 MHz, that are exact in real
time to picoseconds.

Frequency locking isn't difficult. Time locking to picoseconds is.
http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

What I will say though, is multiplying up by harmonic selection from LC
tanks gives orders of lower phase noise/jitter than a PLL.

PLL are useful when you want programmability in frequency and no inductors,
but 80 year old LC tank technology blows PLL away in terms of noise
performance. For example, meeting -150 dBc (30fs jitter) flat band phase
noise at 2.5GHz is, essentially, not achievable with PLL techniques, not
that I am giving anything away on one of my current projects...

Kevin Aylward
www.kevinaylward.co.uk
www.anasoft.co.uk - SuperSpice

The problem with LCs is the temperature coefficient of delay. I'm in
the time business here, not the frequency business.





--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[George Herold]

On Saturday, September 13, 2014 5:28:39 PM UTC-4, John Larkin wrote:

On Sat, 13 Sep 2014 01:55:27 -0400, rickman <gnuarm@gmail.com> wrote:
big snip.
I did analyze the one at 77 MHz, making some simplifying assumptions,
but the 80 KHz comparison frequency is scary. I was hoping a
discussion would suggest a cute way to improve it.

I've enjoyed this, and understood maybe half of it.
(I think this has already been suggested)
Could you divide by N on negative edges,
and then alternate on the positive edges between, M and L.
With three numbers maybe there is some higher common factor?

George H.

The fact that a phase detector operating at 80kHz could have a 1psec relative stability misses the point that dividing the 155.52MHz down to 80kHz introduces more than a 1psec of phase shift, as does dividing 10MHz down to 80kHz.



What I read was that John would divide one of the frequencies to

determine which edge of the clock to compare, but the comparison would

be done between the two clocks, not the divided clock. The divided

clock would be used as an enable on the phase comparison in effect.



Actually, I only need to divide one of the clocks to 80 KHz; then the

Dflop can compare that to the un-divided other one. I'll divide in an

FPGA but resync with an Eclips flipflop, so the division will add

sub-ps jitter to the overall loop.







Insisting on 1psec absolute cycle to cycle stability in the phase detector, ignores all of that, and the delays through the filtering after the phase detector which is absolutely necessary if the noise on the phase detector output isn't going to produce phase noise on the sine wave coming out of the VCXO.



You can't do any better than the phase comparator. So I can see why he

want's that as good as possible. But the delays introduced *after* the

phase comparator will not produce phase errors. That delay is only of

consequence to the loop stability.



Right. The dflop phase detector has such high equivalent gain that the

downstream lowpass won't add significant time error.





--



John Larkin Highland Technology, Inc



jlarkin att highlandtechnology dott com

http://www.highlandtechnology.com

 

[John Larkin]

On Sun, 14 Sep 2014 15:18:39 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 2:59 PM, John Larkin wrote:
On Sun, 14 Sep 2014 01:09:38 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/13/2014 11:17 PM, John Larkin wrote:
On Sat, 13 Sep 2014 23:00:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/13/2014 10:20 PM, John Larkin wrote:

On 14/09/2014 01:13, rickman wrote:
On 9/13/2014 7:34 PM, Phil Hobbs wrote:

Understood. Anecdotally, as I say, two stages of resynchronization
exhibit usefully less jitter than one. YMMV.

I believe Phil's point is that metastability is a problem no matter how
it is perceived. I don't think you can analyze this circuit to come up
with a number of MTBF of the synchronizer FF. John said in an earlier
post that 100's of ps of metastability won't be a problem, but the
nature of metastability is that you can't predict the duration. The
best you can hope for is to characterize the average frequency of
failure and in this case the feedback will be pushing the circuit to the
point of failure.

In fact, that is the difference between this circuit and one built to
test the metastability characteristics of a device... that circuit would
have a reproducible and defined distribution of the edges being
coincident while this one is hard to characterize and is actually trying
to maximize metastability.

Adding a second FF to reclock the output of the first *will* greatly
improve your MTBF and cost next to nothing relative to the rest of the
design. But then the impact of a failure may be insignificant. What
happens to the filtered output if the output of the FF is in a random
state or even oscillates for some time between the 80 kHz samples?

Metastability is not a problem for the dflop phase detector. Bring it
on!

You sound like you are off your meds again

Care to explain yourself? I wonder if you fully understand metastability.

The only time the dflop phase detector might go metastable is when the
VCO and reference edges are exactly aligned.

"Exactly"? What does that mean?

Circular definition: It means the the clock and data transition so
closely in time that the flop goes metastable, teasing the setup/hold
boundary within some number of femtoseconds.

Ok, yes, that is a circular definition. The circuit will go metastable
when the clock edges are close enough to cause metastability. Duh!

Where did you get the femtoseconds number? I thought elsewhere you said
the metastable window was 1 ps??? This is a very important aspect of
proper operation. If this window is large it will greatly increase the
noise of the PD output even at very low frequencies below your filter
cutoff.

I don't recall quantifying a metastability window. But I'd expect it
to be pretty small for an 10EP52. It doesn't matter.

There is no such thing as exact, only
exact to within some spec.

I'm an engineer; I don't let philosophical arguments keep me from
building and selling stuff.

Yes, I know, you build lots of stuff, you are just poor at discussing it
in technical terms.


In this case this window is *exactly* the
source of your jitter isn't it? The input transitions at some close
time of the clock and instead of being always seen as a '1' is sometimes
seen as a '0'. Or is there another source of jitter having to do with
fluctuations in the timing of the internal circuit?

The ideal, noiseless bangbang PLL, with an integrator in the filter
path, will have the phase detector flop alternate 1/0 as the phase
alternates early/late, at successive sample shots. The dflop phase
alternation then sets the loop jitter. DC plus 40 KHz ripple into the
VCO.

But all real clocks have noise, so the PD flop output will in fact be
a stream of random binary bits, at 80K bps, that servo to 50% duty
cycle, with the rare metastability event. The binary noise stream gets
processed by the loop filter into a DC level with some noise spectrum,
and that goes into the VCO input of the 155 MHz VCXO.

But the metastable may not be so rare. It pushes the VCXO in the
opposite direction you want it to go.

It does not. If the two clock edges are so close in time that the flop
goes metastable, then it didn't matter whether the flop resolved to 1
or 0 on that shot. Metastability is the brass ring in this game.

Interesting loop. Sorta delta-sigma.




In that case, we don't
care whether the flop output goes to 1 or 0, so it may as well flail
around for a few ns. At 80 KHz, there's gobs of time for an ECL flop
to resolve.

I expect with all the filtering it may well not matter much. The 80 kHz
doesn't matter so much since you aren't clocking the output. The
filtering is what prevents it from affecting the VCCXO.


ECL flops resolve fast, and don't do stupid oscillatory stuff like old
TTL. 74LS could take many microseconds to settle, and would usually
oscillate to boot. Metastability events would make clicks on a nearby
FM radio.

What is different about the ECL stuff that it wouldn't oscillate? My
understanding is that the FF contains what amounts to a ring oscillator
if it is put into an unstable condition of a '1' on part of the circuit
and a '0' on another they chase each other around. Eventually one
catches up with the other and the oscillations stop since the circuit is
inherently stable.

ECL tends to have extended prop delay on metastability events, maybe a
plateau on the output edge, sometimes even a brief glitch in the wrong
(non-ultimate) direction. Of course, there are different parts and
families and manufacturers, but ECL in general doesn't do the
many-cycle oscillation that TTL tended to do; probably a consequence
of TTL being saturating logic and ECL being non-saturating. In my
application, it wouldn't matter anyhow. If the clock edges are that
well aligned, let it oscillate for a while.

"In general"? So it does oscillate.

ECL generally doesn't oscillate, but it wouldn't matter if it did.
Each individual clocking event has a small influence on the input to
the VCXO, and the resulting phase shift before the next clock.

You're unusually crabby today.


--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[John Larkin]

On Sun, 14 Sep 2014 15:00:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 5:00 AM, Bill Sloman wrote:
On Sunday, 14 September 2014 13:17:17 UTC+10, John Larkin wrote:

The only time the dflop phase detector might go metastable is when the
VCO and reference edges are exactly aligned. In that case, we don't
care whether the flop output goes to 1 or 0, so it may as well flail
around for a few ns. At 80 KHz, there's gobs of time for an ECL flop
to resolve.

ECL flops resolve fast, and don't do stupid oscillatory stuff like old
TTL. 74LS could take many microseconds to settle, and would usually
oscillate to boot. Metastability events would make clicks on a nearby
FM radio.

But the circuit - as described - is deliberately designed to maximise the chance that the ECL bistable will go into a metastable state.

And, as I said, it doesn't matter anyhow.

So John is fooling himself. Presumably it happens rarely enough not to matter much, if his 77MHz to 155.52MHz synchroniser works.

John may be glossing over some aspects of what happens when ECL goes
metastable and how often it might happen, but I'm not convinced it will
be a problem when it does happen.

The normal output of the ECL FF will be a 1 or a 0 for 12.5 us at a
time. If the FF goes metastable it will either be in the wrong state or
will do some funny analog stuff like output an intermediate voltage or
even oscillate. Since the output is being treated as analog and
filtered, the worst case will be the wrong value for one sample period.

If the edges are so well time-aliged that the flop goes metastable,
there is no "wrong value."

I have to assume the filter and gain will result in a minimal impact
from this. If the clock edges are so close the FF goes metastable which
polarity is "wrong" anyway?

The worst I can see is that the circuit won't let the phase cross the
boundary between positive and negative. Each time the phase delta gets
close to zero and metastability gives a "wrong" polarity it "bounces"
off the crossing and remains the same polarity. Not sure this is a
problem either.

It's not.

--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[John Larkin]

On Sun, 14 Sep 2014 15:22:10 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 4:41 AM, Jan Panteltje wrote:
On a sunny day (Sat, 13 Sep 2014 14:28:39 -0700) it happened John Larkin
jlarkin@highlandtechnology.com> wrote in
44d91adte3vc7jipnapet6okglevfn40qm@4ax.com>:

You can't do any better than the phase comparator. So I can see why he
want's that as good as possible. But the delays introduced *after* the
phase comparator will not produce phase errors. That delay is only of
consequence to the loop stability.

Right. The dflop phase detector has such high equivalent gain that the
downstream lowpass won't add significant time error.

John, I was thinking last night about this problem,
but I quickly, for the 1 ps jitter case, got curious about your 10 MHz reference.
For sure that needs to be 'better'.
Is it a sinewave? A symmetrical square wave? Rise times?

The flip-flop phase comparators are noisy by themselves,
in precise nanosecond locking systems I have worked with, you first lock to
frequency with a simple phase comparator, and then after frequency lock
switch to a second more precise phase comparator, and sometimes even a third.
I have never done a pico second accurate lock.
Anyway after frequency lock you switch to the normal PID lock, I have used sample and hold
on a ramp for that, so you are in linear range and no 'bang bang' noise is present.
If the system is knocked out of lock, then you go back to frequency comparator etc.
For the PID case you can set gain and I and D compensation and you like.

I just read John's post where he said the reference clock will have 10's
of ps jitter or that he can add it, so what is the point of a 1 ps
accurate PD?

To fire things on time. My PLL can clean up jitter on the 10 MHz
reference.


--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Jan Panteltje]

On a sunny day (Sun, 14 Sep 2014 12:09:47 -0700) it happened John Larkin
<jlarkin@highlandtechnology.com> wrote in
<0ipb1ad6rdrm88kdekdrgb7924rbesedp7@4ax.com>:

I'd also want the whole circuit temperature stabilised!

It would need to be, if I used an analog s/h. The ECL flops, with
differential data and clock inputs, are impressively stable with
temperature. I've done this before, at 77 MHz sample rate, and got the
entire instrument below 1 ps per degree C, with a bit of overall TC
compensation.

If you have frequency lock, then an analog delay line (varicaps + L)
can be used to 'reposition' the edge, if it is the edge that must be
positioned relative to some other edge...
A controlled delay line that is.
This reminds me of the sixties Ampex video recorders,
to give some loops over loops:
Rotating video head at 250 revolutions per second,
video (color, chroma) needs to be within say 12 nS.
So the way this was done is
1) frequency detector to get the head up to speed.
2) phase detector (after frequency lock) to position the head exactly at the right place in time on the tape,
3) 'Amtec' time element compensator (whole 19 inch rack full of transistors and analog delay lines) to get to sub microsecond
to compensate for timing errors (after the phase lock).
4) 'Colortec' color timing compensator, an other controlled delay line to get to a few ns relative to the reference.
Also a whole 19 inch rack full.
That was standard quadruplex studio equipment.
http://en.wikipedia.org/wiki/Quadruplex_videotape#mediaviewer/File:Ampex-Am-Tech-Color-Tech-Proc-Amp.jpg
from
http://en.wikipedia.org/wiki/Quadruplex_videotape

Anyways 50 years old technology.
But it had a reference, everything in the studio is locked to it.

You can have a noisy reference, and make an almost jitter free RF signal,
but you cannot have a jitter free RF signal if you align with the edges of a noisy reference.

So question is what do you want?
For a sine wave reference as you say I see plenty of 'alignment' problems [1],
So it seems then that you just want the average frequency and that jitter free.
But of some laser has to trigger on the 'edge' of the reference, the delay line method comes back into play.

[1] zero crossings would suck, FM limiter?

Well just a bit of old days and philosophy.
Especially as I am watching a startrek movie were Kirk just got sucked out into space.

 

[John Larkin]

On Sun, 14 Sep 2014 20:06:44 GMT, Jan Panteltje <panteltje@yahoo.com>
wrote:

On a sunny day (Sun, 14 Sep 2014 12:09:47 -0700) it happened John Larkin
jlarkin@highlandtechnology.com> wrote in
0ipb1ad6rdrm88kdekdrgb7924rbesedp7@4ax.com>:

I'd also want the whole circuit temperature stabilised!

It would need to be, if I used an analog s/h. The ECL flops, with
differential data and clock inputs, are impressively stable with
temperature. I've done this before, at 77 MHz sample rate, and got the
entire instrument below 1 ps per degree C, with a bit of overall TC
compensation.

If you have frequency lock, then an analog delay line (varicaps + L)
can be used to 'reposition' the edge, if it is the edge that must be
positioned relative to some other edge...
A controlled delay line that is.
This reminds me of the sixties Ampex video recorders,
to give some loops over loops:
Rotating video head at 250 revolutions per second,
video (color, chroma) needs to be within say 12 nS.
So the way this was done is
1) frequency detector to get the head up to speed.
2) phase detector (after frequency lock) to position the head exactly at the right place in time on the tape,
3) 'Amtec' time element compensator (whole 19 inch rack full of transistors and analog delay lines) to get to sub microsecond
to compensate for timing errors (after the phase lock).
4) 'Colortec' color timing compensator, an other controlled delay line to get to a few ns relative to the reference.
Also a whole 19 inch rack full.
That was standard quadruplex studio equipment.
http://en.wikipedia.org/wiki/Quadruplex_videotape#mediaviewer/File:Ampex-Am-Tech-Color-Tech-Proc-Amp.jpg
from
http://en.wikipedia.org/wiki/Quadruplex_videotape

Anyways 50 years old technology.
But it had a reference, everything in the studio is locked to it.

You can have a noisy reference, and make an almost jitter free RF signal,
but you cannot have a jitter free RF signal if you align with the edges of a noisy reference.

So question is what do you want?
For a sine wave reference as you say I see plenty of 'alignment' problems [1],
So it seems then that you just want the average frequency and that jitter free.
But of some laser has to trigger on the 'edge' of the reference, the delay line method comes back into play.

[1] zero crossings would suck, FM limiter?

Well just a bit of old days and philosophy.
Especially as I am watching a startrek movie were Kirk just got sucked out into space.

How come the Enterprise, no matter how badly it was shot up, never
lost pressurization and never lost its artificial gravity generator?

And why did they always beam into derelict spaceships and alien
planets that had breathable atmospheres and Earth-level gravity?

Why were no babies ever born on the Enterprise? Why did nobody ever
bleed or vomit? Did they have unisex rest rooms? Did they have
bathtubs? Where were the trash cans? Were snacks not allowed on the
bridge?


--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Phil Hobbs]

On 9/14/2014 2:59 PM, John Larkin wrote:

On Sun, 14 Sep 2014 01:09:38 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/13/2014 11:17 PM, John Larkin wrote:
On Sat, 13 Sep 2014 23:00:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/13/2014 10:20 PM, John Larkin wrote:

On 14/09/2014 01:13, rickman wrote:
On 9/13/2014 7:34 PM, Phil Hobbs wrote:

Understood. Anecdotally, as I say, two stages of resynchronization
exhibit usefully less jitter than one. YMMV.

I believe Phil's point is that metastability is a problem no matter how
it is perceived. I don't think you can analyze this circuit to come up
with a number of MTBF of the synchronizer FF. John said in an earlier
post that 100's of ps of metastability won't be a problem, but the
nature of metastability is that you can't predict the duration. The
best you can hope for is to characterize the average frequency of
failure and in this case the feedback will be pushing the circuit to the
point of failure.

In fact, that is the difference between this circuit and one built to
test the metastability characteristics of a device... that circuit would
have a reproducible and defined distribution of the edges being
coincident while this one is hard to characterize and is actually trying
to maximize metastability.

Adding a second FF to reclock the output of the first *will* greatly
improve your MTBF and cost next to nothing relative to the rest of the
design. But then the impact of a failure may be insignificant. What
happens to the filtered output if the output of the FF is in a random
state or even oscillates for some time between the 80 kHz samples?

Metastability is not a problem for the dflop phase detector. Bring it
on!

You sound like you are off your meds again

Care to explain yourself? I wonder if you fully understand metastability.

The only time the dflop phase detector might go metastable is when the
VCO and reference edges are exactly aligned.

"Exactly"? What does that mean?

Circular definition: It means the the clock and data transition so
closely in time that the flop goes metastable, teasing the setup/hold
boundary within some number of femtoseconds.

There is no such thing as exact, only
exact to within some spec.

I'm an engineer; I don't let philosophical arguments keep me from
building and selling stuff.

In this case this window is *exactly* the
source of your jitter isn't it? The input transitions at some close
time of the clock and instead of being always seen as a '1' is sometimes
seen as a '0'. Or is there another source of jitter having to do with
fluctuations in the timing of the internal circuit?

The ideal, noiseless bangbang PLL, with an integrator in the filter
path, will have the phase detector flop alternate 1/0 as the phase
alternates early/late, at successive sample shots. The dflop phase
alternation then sets the loop jitter. DC plus 40 KHz ripple into the
VCO.

But all real clocks have noise, so the PD flop output will in fact be
a stream of random binary bits, at 80K bps, that servo to 50% duty
cycle, with the rare metastability event. The binary noise stream gets
processed by the loop filter into a DC level with some noise spectrum,
and that goes into the VCO input of the 155 MHz VCXO.

Interesting loop. Sorta delta-sigma.




In that case, we don't
care whether the flop output goes to 1 or 0, so it may as well flail
around for a few ns. At 80 KHz, there's gobs of time for an ECL flop
to resolve.

I expect with all the filtering it may well not matter much. The 80 kHz
doesn't matter so much since you aren't clocking the output. The
filtering is what prevents it from affecting the VCCXO.


ECL flops resolve fast, and don't do stupid oscillatory stuff like old
TTL. 74LS could take many microseconds to settle, and would usually
oscillate to boot. Metastability events would make clicks on a nearby
FM radio.

What is different about the ECL stuff that it wouldn't oscillate? My
understanding is that the FF contains what amounts to a ring oscillator
if it is put into an unstable condition of a '1' on part of the circuit
and a '0' on another they chase each other around. Eventually one
catches up with the other and the oscillations stop since the circuit is
inherently stable.

ECL tends to have extended prop delay on metastability events, maybe a
plateau on the output edge, sometimes even a brief glitch in the wrong
(non-ultimate) direction. Of course, there are different parts and
families and manufacturers, but ECL in general doesn't do the
many-cycle oscillation that TTL tended to do; probably a consequence
of TTL being saturating logic and ECL being non-saturating. In my
application, it wouldn't matter anyhow. If the clock edges are that
well aligned, let it oscillate for a while.

Resynchronizing to the 10 MHz clock after the phase detector would fix
it if it were a problem, anyway. That won't add any significant phase
delay in an 80-kHz comparison.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 9/14/2014 3:10 PM, rickman wrote:

On 9/14/2014 8:19 AM, Mike Perkins wrote:
On 14/09/2014 09:10, Bill Sloman wrote:

snip

John does claim to have avoided metastability, so he presumably has
done something equally clever. One can't entirely discount the
possibility that he's fooling himself, but it's kinder to give him
the benefit or the doubt.

I feel you haven't understood what John is trying to do.

He wants metastability, but in a controlled way that he claims he gets
with these device. Where the output goes essentially from logic 0 to
logic 1 depending on whether these clocks are early or late by 1ps in a
gradual and monotonic manner.

That is an important point. Metastability will have a *major* impact on
the *monotonicity* of the phase detector. If he wants to keep the two
clocks to within 1 ps and the metastable window is 1 ps, he is doomed.
Instead of being monotonic the phase detector may end up a random bit
generator. This depends on the details of the window size and the
behavior within that window. Normally metastable behavior is considered
to be chaotic, not monotonic.

I think that's a problem calling for measurement, rather than
speculation. As arguments go, saying that A is "considered" B is about
as weak as it gets.

Interesting thread, anyway.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 9/13/2014 8:23 PM, Bill Sloman wrote:

On Sunday, 14 September 2014 09:34:27 UTC+10, Phil Hobbs wrote:
On 9/13/2014 7:25 PM, John Larkin wrote:
On Sat, 13 Sep 2014 18:18:58 -0400, Phil Hobbs
hobbs@electrooptical.net> wrote:
On 9/13/2014 5:28 PM, John Larkin wrote:
On Sat, 13 Sep 2014 01:55:27 -0400, rickman
gnuarm@gmail.com> wrote:
On 9/13/2014 12:44 AM, Bill Sloman wrote:

The PPL loop that ties the 155.52MHz VCXO output to the
10MHz reference output stops long term phase shift
between the two, but control only the relative
phase-shift, not the absolute phase shift.

I don't follow this at all. What is the difference between
the two in this case? There will be a relative measurement
and that will be brought to zero by the loop. So what is
the "absolute" phase shift? Or
are you talking about the short term phase shift of the VCXO?

Short term phase jitter inside the PLL feedback path
doesn't matter, so long as it long-term averages to less
than a picosecond - or whatever - before it can build up
enough to shift the phase of the 155.52MHz VCXO.

That is not clear to me. "Build up" is not something I can
picture in this circuit. Any deviation will result in
noise and phase shift of the VCXO output. The question is
just how large that deviation is. I guess.

The standard PLL architecture - its just one of the possibilities
that Floyd Gardner discussed, but it's ubiquitous in reality - is a
second order loop with the error signal from the phase detector being
fed into an integrator whose output controls the frequency of the
VCO.

The integrator isn't a perfect integrator - as Gardner discusses,
that would make the loop unstable - and in analog implementation this
means a resistor in series with the integrating capacitor which
breaks the 90 degree phase lag in the integrator at some appropriate
low frequency.

The output of an integrator does "build up". With the "fractional N"
approach you have to make sure that it doesn't build up enough to
shift the phase more than 1psec in the 12.5usec it would take for the
"fractional N" collection of cancelling timing errors to repeat
themselves

you are saying that the filter can average out the
deviations well
enough. John seems to think that can cause other problems or maybe
he just doesn't have confidence in this idea because he hasn't
played with it yet. He admits he is not a math guy and prefers to
test and simulate.

I did the ECL bang-bang thing to recover the clock from the
155.52 MHz data stream, but the flop was clocked at 77.76
MHz. But my new problem is to generate that data stream, and
I'm given a 10 MHz source to lock to.

As far as math goes, analyzing the bang-bang PLL is messy.
I've only
seen a couple of papers on the subject, not very helpful, and most
PLL texts don't even mention the technique.

I did analyze the one at 77 MHz, making some simplifying
assumptions, but the 80 kHz comparison frequency is scary. I
was hoping a discussion would suggest a cute way to improve
it.

The fact that a phase detector operating at 80kHz could
have a 1psec relative stability misses the point that
dividing the 155.52MHz down to 80kHz introduces more than
a 1psec of phase shift, as does dividing 10MHz down to
80kHz.

What I read was that John would divide one of the
frequencies to determine which edge of the clock to
compare, but the comparison would be done between the two
clocks, not the divided clock. The divided clock would be
used as an enable on the phase comparison in effect.

Actually, I only need to divide one of the clocks to 80 KHz;
then the D-flop can compare that to the un-divided other one.
I'll divide in anFPGA but resync with an Eclips flipflop, so
the division will add sub-ps jitter to the overall loop.

Anecdotally, double resynchronizers in different packages are
betterthan single ones, but I don't have measurements to back
that up.

Understood. Anecdotally, as I say, two stages of resynchronization
exhibit usefully less jitter than one. YMMV.

Two-stage phase lock loops - which use one set of hardware to get
into synch and another to maintain synch are certainly mentioned in
Floyd Gardner's book, though in rather general terms, and he also
mentions the "lock detector" which would be a third set of hardware
which tells you whether you should be looking for synchronisation or
maintaining it.

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated. Second,
all the worries about metastability can be got rid of by putting a
second DFF after the phase detector, and clocking it from the 10 MHz.

Or in John's case, whether he should be letting his psec-accurate
time detector adjust the the phase of the 155.52MHz clock.

Cheers

Phil Hobbs



--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 9/13/2014 7:40 PM, Bill Sloman wrote:

On Sunday, 14 September 2014 04:44:39 UTC+10, Phil Hobbs wrote:
On 9/13/2014 9:05 AM, Mike Perkins wrote:
On 12/09/2014 18:32, John Larkin wrote:
On Fri, 12 Sep 2014 03:31:49 +0100, Mike Perkins
spam@spam.com> wrote:
On 11/09/2014 11:20, Mike Perkins wrote:
On 10/09/2014 00:54, John Larkin wrote:

If you mean a 4046 PC2 lookalike, then these will have either an
overlap (hysteresis) or no output for low phase error where you
80kHz clock edges are near conincident.

John's using an ECLiPS D-flop as a bang-bang phase detector. Very
high gain over a very narrow range (< 1ps apparently), as opposed
to the 4046 type, whose gain is VDD/(2 pi). Since the decision
time is so short, and its tempco narrow, other perturbations hardly
matter.

Unless they coincide with decision period. The nightmare situation is
some non-synchronous perturbation on the rails that kicks the
155.52MHz oscillator out of phase (obviously not by much) whenever
the perturbation drifts through the decision window.

I agree that just hanging the PD D-flop on some noisy digital rail isn't
a terrific idea. OTOH I sort of suspect that there's not that much ECL
on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

The rail might bounce a bit due to load fluctuations, but one of the
great virtues of ECL is that there's very little data-dependence of
supply current.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 9/14/2014 2:02 PM, Kevin Aylward wrote:

"Gerhard Hoffmann" wrote in message
news:c7l84fFsqprU1@mid.individual.net...

What I will say though, is multiplying up by harmonic selection from LC
tanks gives orders of lower phase noise/jitter than a PLL.

PLL are useful when you want programmability in frequency and no
inductors,
but 80 year old LC tank technology blows PLL away in terms of noise
performance. For example, meeting -150 dBc (30fs jitter) flat band
phase
noise at 2.5GHz is, essentially, not achievable with PLL techniques,
not
that I am giving anything away on one of my current projects...

http://cds.linear.com/docs/en/datasheet/6948f.pdf

shows only -100dBc/Hz on its performance curves.

???
on page 8 I see the 3 and 4 GHz units break the -150 dBc/Hz
at 10 MHz offset, still linearly sinking towards the flat
noise floor.

Ah... I should add... flat band noise with a multiplication of times 9.
Multiplying up has an inherent theoretical noise increase of 20.log(mult
ratio), so a times 9 is going to increase the basic oscillator phase
noise by around 20dB, irrespective of any added noise of the processing.

But not the jitter. The reason the phase noise goes up is that the
jitter stays more or less the same, but the period goes down by a factor
N, so the phase fluctuations increase by N times.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 9/14/2014 8:22 AM, Mike Perkins wrote:

On 14/09/2014 07:58, Kevin Aylward wrote:
"John Larkin" wrote in message
news:1h291ahulit12anamhhlu27hrapque4mai@4ax.com...


Why not go out and buy a 9.7200MHz +/-10ppm crystal, and lock your
155.52MHz VCXO to that via a divide-by-sixteen counter?

You'll have to have your eight crystals ground to give exactly the
right
frequencies, but there are small businesses that make a living out of
producing bespoke crystals.

Ahmmmm..... 155.52 Mhz is so bog standard that every xtal/oscillator
company
under the sun has xtals and oscillators in the golden range of 10MHz
to 50
Mhz that can be multiplied exactly up. e.g. 38.88Mhz and 19.44MHz. I
know,
because my company has then in stock, and my current asic design uses
them!

"19.44 MHz crystal" gets 2800 hits

I was going to suggest this right off the bat, but assumed they was
some
system reason why he cant do that.
My box will receive a 10 MHz reference from the customer, from some
expensive Symmetrix GPS-disciplined thing. I'll also get a 1 PPS pulse
from that, and time-of-day data over Ethernet. It's my job to make
OC3-like optical data frames, at 155.52 MHz, that are exact in real
time to picoseconds.

Frequency locking isn't difficult. Time locking to picoseconds is.
http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

What I will say though, is multiplying up by harmonic selection from LC
tanks gives orders of lower phase noise/jitter than a PLL.

Won't LC tanks have horrendous temperature coefficients?

Yup.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 9/14/2014 8:43 AM, upsidedown@downunder.com wrote:

On Sun, 14 Sep 2014 13:22:23 +0100, Mike Perkins <spam@spam.com
wrote:

Frequency locking isn't difficult. Time locking to picoseconds is.
http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

What I will say though, is multiplying up by harmonic selection from LC
tanks gives orders of lower phase noise/jitter than a PLL.

Won't LC tanks have horrendous temperature coefficients?

Not that bad after all. Assuming a LC Q-factor of 100, you will have a
1 % -3 dB bandwidth. That would allow a 10000 ppm drift across the
temperature range (100 ppm/C across 100 C). After all, you are
interested in the harmonics of the crystal oscillator, not the filter
performance.

In the words of Rudyard Kipling, "Not so, but far otherwise." For a
single section the phase shift across the width of the resonance is on
the order of 1 radian, so in terms of phase, a filter with a Q of 100
magnifies the component tempcos by roughly 100 times. A time shift of 1
ps is about a milliradian at 155 MHz. Typical inductor tempcos of +100
ppm/C will give you a phase shift of something like

dPhi/dT ~ Q * dL/dT

or 0.01 radian/K, i.e. 10 ps/K.

Cheers

Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[rickman]

On 9/14/2014 3:41 PM, John Larkin wrote:

On Sun, 14 Sep 2014 15:18:39 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 2:59 PM, John Larkin wrote:
On Sun, 14 Sep 2014 01:09:38 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/13/2014 11:17 PM, John Larkin wrote:
On Sat, 13 Sep 2014 23:00:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/13/2014 10:20 PM, John Larkin wrote:

On 14/09/2014 01:13, rickman wrote:
On 9/13/2014 7:34 PM, Phil Hobbs wrote:

Understood. Anecdotally, as I say, two stages of resynchronization
exhibit usefully less jitter than one. YMMV.

I believe Phil's point is that metastability is a problem no matter how
it is perceived. I don't think you can analyze this circuit to come up
with a number of MTBF of the synchronizer FF. John said in an earlier
post that 100's of ps of metastability won't be a problem, but the
nature of metastability is that you can't predict the duration. The
best you can hope for is to characterize the average frequency of
failure and in this case the feedback will be pushing the circuit to the
point of failure.

In fact, that is the difference between this circuit and one built to
test the metastability characteristics of a device... that circuit would
have a reproducible and defined distribution of the edges being
coincident while this one is hard to characterize and is actually trying
to maximize metastability.

Adding a second FF to reclock the output of the first *will* greatly
improve your MTBF and cost next to nothing relative to the rest of the
design. But then the impact of a failure may be insignificant. What
happens to the filtered output if the output of the FF is in a random
state or even oscillates for some time between the 80 kHz samples?

Metastability is not a problem for the dflop phase detector. Bring it
on!

You sound like you are off your meds again

Care to explain yourself? I wonder if you fully understand metastability.

The only time the dflop phase detector might go metastable is when the
VCO and reference edges are exactly aligned.

"Exactly"? What does that mean?

Circular definition: It means the the clock and data transition so
closely in time that the flop goes metastable, teasing the setup/hold
boundary within some number of femtoseconds.

Ok, yes, that is a circular definition. The circuit will go metastable
when the clock edges are close enough to cause metastability. Duh!

Where did you get the femtoseconds number? I thought elsewhere you said
the metastable window was 1 ps??? This is a very important aspect of
proper operation. If this window is large it will greatly increase the
noise of the PD output even at very low frequencies below your filter
cutoff.

I don't recall quantifying a metastability window. But I'd expect it
to be pretty small for an 10EP52. It doesn't matter.



There is no such thing as exact, only
exact to within some spec.

I'm an engineer; I don't let philosophical arguments keep me from
building and selling stuff.

Yes, I know, you build lots of stuff, you are just poor at discussing it
in technical terms.


In this case this window is *exactly* the
source of your jitter isn't it? The input transitions at some close
time of the clock and instead of being always seen as a '1' is sometimes
seen as a '0'. Or is there another source of jitter having to do with
fluctuations in the timing of the internal circuit?

The ideal, noiseless bangbang PLL, with an integrator in the filter
path, will have the phase detector flop alternate 1/0 as the phase
alternates early/late, at successive sample shots. The dflop phase
alternation then sets the loop jitter. DC plus 40 KHz ripple into the
VCO.

But all real clocks have noise, so the PD flop output will in fact be
a stream of random binary bits, at 80K bps, that servo to 50% duty
cycle, with the rare metastability event. The binary noise stream gets
processed by the loop filter into a DC level with some noise spectrum,
and that goes into the VCO input of the 155 MHz VCXO.

But the metastable may not be so rare. It pushes the VCXO in the
opposite direction you want it to go.

It does not. If the two clock edges are so close in time that the flop
goes metastable, then it didn't matter whether the flop resolved to 1
or 0 on that shot. Metastability is the brass ring in this game.

Hardly.

Interesting loop. Sorta delta-sigma.




In that case, we don't
care whether the flop output goes to 1 or 0, so it may as well flail
around for a few ns. At 80 KHz, there's gobs of time for an ECL flop
to resolve.

I expect with all the filtering it may well not matter much. The 80 kHz
doesn't matter so much since you aren't clocking the output. The
filtering is what prevents it from affecting the VCCXO.


ECL flops resolve fast, and don't do stupid oscillatory stuff like old
TTL. 74LS could take many microseconds to settle, and would usually
oscillate to boot. Metastability events would make clicks on a nearby
FM radio.

What is different about the ECL stuff that it wouldn't oscillate? My
understanding is that the FF contains what amounts to a ring oscillator
if it is put into an unstable condition of a '1' on part of the circuit
and a '0' on another they chase each other around. Eventually one
catches up with the other and the oscillations stop since the circuit is
inherently stable.

ECL tends to have extended prop delay on metastability events, maybe a
plateau on the output edge, sometimes even a brief glitch in the wrong
(non-ultimate) direction. Of course, there are different parts and
families and manufacturers, but ECL in general doesn't do the
many-cycle oscillation that TTL tended to do; probably a consequence
of TTL being saturating logic and ECL being non-saturating. In my
application, it wouldn't matter anyhow. If the clock edges are that
well aligned, let it oscillate for a while.

"In general"? So it does oscillate.

ECL generally doesn't oscillate, but it wouldn't matter if it did.
Each individual clocking event has a small influence on the input to
the VCXO, and the resulting phase shift before the next clock.

You're unusually crabby today.

And you are the same as always... thick. You say it doesn't "generally"
oscillate which means it *does* oscillate. The qualifier is a waffle
word. The fact that you run the output through a filter doesn't mean it
won't oscillate.

--

Rick

 

[John Larkin]

On Sun, 14 Sep 2014 17:39:21 -0400, Phil Hobbs
<hobbs@electrooptical.net> wrote:

On 9/13/2014 7:40 PM, Bill Sloman wrote:
On Sunday, 14 September 2014 04:44:39 UTC+10, Phil Hobbs wrote:
On 9/13/2014 9:05 AM, Mike Perkins wrote:
On 12/09/2014 18:32, John Larkin wrote:
On Fri, 12 Sep 2014 03:31:49 +0100, Mike Perkins
spam@spam.com> wrote:
On 11/09/2014 11:20, Mike Perkins wrote:
On 10/09/2014 00:54, John Larkin wrote:

If you mean a 4046 PC2 lookalike, then these will have either an
overlap (hysteresis) or no output for low phase error where you
80kHz clock edges are near conincident.

John's using an ECLiPS D-flop as a bang-bang phase detector. Very
high gain over a very narrow range (< 1ps apparently), as opposed
to the 4046 type, whose gain is VDD/(2 pi). Since the decision
time is so short, and its tempco narrow, other perturbations hardly
matter.

Unless they coincide with decision period. The nightmare situation is
some non-synchronous perturbation on the rails that kicks the
155.52MHz oscillator out of phase (obviously not by much) whenever
the perturbation drifts through the decision window.


I agree that just hanging the PD D-flop on some noisy digital rail isn't
a terrific idea. OTOH I sort of suspect that there's not that much ECL
on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

The rail might bounce a bit due to load fluctuations, but one of the
great virtues of ECL is that there's very little data-dependence of
supply current.

Right. ECL is remarkably indifferent to supply voltage, or even to the
voltage applied to external pulldown resistors. But of course I'll
have good supplies; that's easy.


--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Gerhard Hoffmann]

on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

Since you are mentioning really clean supplies:
I have built a preamp to verify the noise on supplies and Vtune lines:

< http://www.hoffmann-hochfrequenz.de/downloads/lono.pdf >

and used it to measure the noise of batteries, simply because they are
probably the hardest test objects.

<
http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf
>

It's not yet accesible from the rest of the website, you must know
the exact address since I'm not yet happy with the results. I see
much more 1/f noise than F.Walls from NIST, and partly 30 dB/decade.

I have used an old Avantek wideband amplifier with 57 dB gain and mixed
down the noise @100 MHz with a signal generator, ring mixer & low pass
to AF, and it was as flat as could be down to 0.1 Hz. So if it's
flat, the system shows it as flat. wierd.

regards, Gerhard

 

[Phil Hobbs]

On 9/14/2014 6:30 PM, Gerhard Hoffmann wrote:

on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

Since you are mentioning really clean supplies:
I have built a preamp to verify the noise on supplies and Vtune lines:

http://www.hoffmann-hochfrequenz.de/downloads/lono.pdf

and used it to measure the noise of batteries, simply because they are
probably the hardest test objects.


http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf


It's not yet accesible from the rest of the website, you must know
the exact address since I'm not yet happy with the results. I see
much more 1/f noise than F.Walls from NIST, and partly 30 dB/decade.

I have used an old Avantek wideband amplifier with 57 dB gain and mixed
down the noise @100 MHz with a signal generator, ring mixer & low pass
to AF, and it was as flat as could be down to 0.1 Hz. So if it's
flat, the system shows it as flat. wierd.

regards, Gerhard

Nice. If you make two amplifiers, take the cross-spectrum of their
outputs, and average for awhile, you can get rid of the amplifier
voltage noise pretty well. (The current noise adds, of course.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[rickman]

On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided clock
is not an issue? It is not being used to clock anything. It is only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

BTW, the FF has to be clocked by the same clock that is being divided
down. Otherwise you get 1 full clock cycle of jitter in the enable when
you sync it to the other clock.

--

Rick