PLL tricks

[rickman]

On 9/13/2014 7:34 PM, 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
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
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.

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

Cheers

Phil Hobbs

The bang-bang PLL bears a remarkable similarity to the circuit that's
used in IC testing to force metastability.

Resyncing the FPGA divider has no hazards, because we can provide safe
setup and hold times.


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?

--

Rick

 

[Mike Perkins]

On 14/09/2014 01:13, rickman wrote:

On 9/13/2014 7:34 PM, 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
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
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.

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

Cheers

Phil Hobbs

The bang-bang PLL bears a remarkable similarity to the circuit that's
used in IC testing to force metastability.

Resyncing the FPGA divider has no hazards, because we can provide safe
setup and hold times.


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?

I was thinking along similar lines but with thermal considerations,
where thresholds are likely to change and be dependant on the previous
clock timings. That could then induce oscillations from one sample to
the next.

I presume any form of ECL is more immune to thermal effects than other
logic families?


--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[rickman]

On 9/10/2014 4:54 AM, Gerhard Hoffmann wrote:

Am 10.09.2014 um 01:54 schrieb John Larkin:

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.

Dividing EXACTLY with a DDS can be surprisingly hard, one could
find that one is always off by 2e-32 or 2e-48 or whatever
but one is never exactly on the spot, never really synchronous.

That is only true if you don't control both your step size and your
modulus. No one ever said you had to use 2^n as a modulus.

Once, there was a BCD coded DDS from Stanford IIRC that
could get it exact for easy-to-write decimal numbers.

Yes, they picked a modulus that worked for them.

Today one could put it into an FPGA. A BCD based adder
is easy. I have put a VHDL-only sine table on opencores.org
that should also be easy to modify.

BCD or any other combination of divisors. One I designed used an
oddball divisor in the lower portion of the accumulator and then a
binary counter in the top. This allowed an exact match to all of the
audio rates needed. Programming the step size used a simple conversion
in software.

--

Rick

 

[rickman]

On 9/13/2014 10:54 PM, Bill Sloman wrote:

On Sunday, 14 September 2014 11:51:46 UTC+10, Phil Hobbs wrote:
On 9/13/2014 8:13 PM, rickman wrote:
On 9/13/2014 7:34 PM, 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 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.

It produces zero ps of phase shift in the clocks because the divided
signal is not used to clock anything. It is used to *enable* the FF
that is clocked by one clock and samples the other clock on the D input.

John has said the 80 kHz will be resync'ed to the clock because it comes
from the FPGA with a considerable delay, but as long as that delay puts
it outside of the setup/hold window the delay has no bearing on the
circuit.

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.

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

The bang-bang PLL bears a remarkable similarity to the circuit that's used in IC testing to force metastability.

Resyncing the FPGA divider has no hazards, because we can provide safe
setup and hold times.

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.

As John says, if you can meet the specified setup and hold times for the part, you won't get meta-stability.

You can't do that until the 155.52MHz clock is locked to your 10MHz clock and you can pick the occasional clock edge pair - one every 12.5 usec - which is exactly lined up, for which he'll probably need a two-stage - acquire lock then synchronise - process, but if you do do this can you can avoid metastability by careful design.

You seem to be missing the point of the phase detector. It will be
sampling one clock with the other. When the two are in sync the clock
edges will be nearly coincident and the FF will be as close as possible
to metastability at all times... by design. The goal of the circuit is
to put the two clock edges within 1 ps of one another.

--

Rick

 

[rickman]

On 9/13/2014 10:57 PM, Gerhard Hoffmann wrote:

Am 14.09.2014 um 02:48 schrieb rickman:
On 9/10/2014 4:54 AM, Gerhard Hoffmann wrote:
Am 10.09.2014 um 01:54 schrieb John Larkin:

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.

Dividing EXACTLY with a DDS can be surprisingly hard, one could
find that one is always off by 2e-32 or 2e-48 or whatever
but one is never exactly on the spot, never really synchronous.

That is only true if you don't control both your step size and your
modulus. No one ever said you had to use 2^n as a modulus.

You have snipped too much context. I was the first to propose
just that, and that my sin/cos function on opencores.org
would be easy to adopt. There even are some TODOs in the VHDL
source code already.

Once, there was a BCD coded DDS from Stanford IIRC that
could get it exact for ateasy-to-write decimal numbers.

Yes, they picked a modulus that worked for them.

exactly.


And I always see here "1 ps jitter" without any qualification.
That makes as much sense as "my car consumes 8 liters of Diesel".
From here to work? per 100 Km? One hefty accelleration?

Jitter needs measurement bandwidth. When I said that telecom ps
are easy, I meant exactly that. They start integrating their
phasenoise at 12 KHz or so. All of the 1/f region is therefore
ignored, and that is the lion's share.


A friend of mine had made systematic phase noise characterizations
when he built frequency synthesizers for avionics and found
that ECL in Mosaic 3 process was about the worst that industry
had to offer, noisewise.

I find it hard to believe that Mosaic's grand children
are suddenly on the other end of the scale. Along with the
ultrafast switching comes ultrawide noise bandwidth where one must
integrate over many harmonics from DC to daylight.

I'm not sure of all the ramifications of this, but I can tell you that
John is just looking at one aspect of the ECL circuit, the timing window
in which a transition on the input results in an uncertain output. This
is often called the metastable window. John is not worried about the
output being metastable. He is concerned by the fact that it would
"add" jitter to the sampling process.

I think you are talking about other aspects of ECL jitter such as the
timing of the output edge. Turns out that this is not important. He is
just trying to sample the two clocks with as little added jitter as
possible. Remember, this ECL FF is not used as a clock, it is treated
as analog, filtered and used to control the VCXO.

All people I know who are seriously in timing use Schottky ring
mixers as phase detectors and that must have a reason or two.


That does not mean that I dislike ECL. I was an early adoptor
of 10KH and 100K, and right now there are many 100EP51 on this
table


I would not pin my hopes to high that one could transfer much
phase noise cleanliness (is that a word?) from the 10MHz ref to
155MHz. From 10 to 100 MHz the noise goes up 20 dB by principle,
from 100 to 150 abt. another 3 dB - and your ref must be better by
this, without your self-indroduced errors. It is best to leave the
oscillator alone, trying to regulate it is phasenoise-wise an
invitation to desaster, as I could see this spring on the
E5052B. That thing is a real eye opener. Every change must
be slooooow.


And with regard to metastability, IIRC I heard Peter Alfke of Xilinx
say something like "The speed you see in an FPGA nowadays is wiring.
The speed of the decision loop inside a FF is so fast that metastability
just won't happen. One sychronizer stage is enough."
I think the sentence contained "lifetime of the universe", also.
That was in the Virtex-4 time frame, not now with 13 GBit/s I/O.

I have quoted Peter on this issue before as well, but it seems some of
the newer families of FPGAs have fallen backwards in that regards. It
was not from someone as authoritative as Peter, but they were talking
about FPGA families Peter never saw so I can't dispute them.

BCD or any other combination of divisors. One I designed used an
oddball divisor in the lower portion of the accumulator and then a
binary counter in the top. This allowed an exact match to all of the
audio rates needed. Programming the step size used a simple conversion
in software.

LIKE

Thanks. Sometimes I can find interesting solutions to interesting
problems.

I didn't snip anything this time.

--

Rick

 

[rickman]

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? There is no such thing as exact, only
exact to within some spec. 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?

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.

--

Rick

 

[rickman]

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.

--

Rick

 

[rickman]

On 9/11/2014 5:11 AM, Gerhard Hoffmann wrote:

Am 11.09.2014 um 07:40 schrieb josephkk:


The DDS concept is an integer divide system, binary or BCD makes no
difference.


No, it's neither an integer divide system nor does BCD make no difference.

A counter is an integer divide system.

The frequency resolution of a 48 bit DDS is f_clock/2**48 which is
anything but integer and you can get only multiples of the
resolution out. You may be very close to your intended frequency
but microHz away and that gives you a constant phase creep.

That makes the assumption that your phase accumulator rolls over at
2^48. The phase accumulator can be any modulus you want and can even be
programmable.

With a BCD DDS your step size can be f_clock / 10e6 and that
that is an advantage if you need a frequency that can be
exactly written in a few decimal digits.

Yes. A DDS can have an equation of f_clock * step_size/counter_modulus
with counter_modulus being any integer you want.

--

Rick

 

[Phil Hobbs]

On 9/13/2014 8:13 PM, rickman wrote:

On 9/13/2014 7:34 PM, 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
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
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.

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

Cheers

Phil Hobbs

The bang-bang PLL bears a remarkable similarity to the circuit that's
used in IC testing to force metastability.

Resyncing the FPGA divider has no hazards, because we can provide safe
setup and hold times.


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?

I'm pretty confident that John's earlier experience with picosecond
bang-bang loops is sufficient for the purpose at hand. My experience
with ECLiPS D flipflops as phase detectors is, *ahem*, limited (read,
nonexistent).

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

 

[John Larkin]

On Sun, 14 Sep 2014 01:29:15 +0100, Mike Perkins <spam@spam.com>
wrote:

On 14/09/2014 01:13, rickman wrote:
On 9/13/2014 7:34 PM, 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
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
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.

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

Cheers

Phil Hobbs

The bang-bang PLL bears a remarkable similarity to the circuit that's
used in IC testing to force metastability.

Resyncing the FPGA divider has no hazards, because we can provide safe
setup and hold times.


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!

I was thinking along similar lines but with thermal considerations,
where thresholds are likely to change and be dependant on the previous
clock timings. That could then induce oscillations from one sample to
the next.

I presume any form of ECL is more immune to thermal effects than other
logic families?

EclipsLite, driven differentially, has a delay or setup/hold tempco
below 1 ps per degree C. A fast CMOS flop might be 10 or so.


--

John Larkin Highland Technology, Inc

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

 

[Gerhard Hoffmann]

Am 14.09.2014 um 02:48 schrieb rickman:

On 9/10/2014 4:54 AM, Gerhard Hoffmann wrote:
Am 10.09.2014 um 01:54 schrieb John Larkin:

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.

Dividing EXACTLY with a DDS can be surprisingly hard, one could
find that one is always off by 2e-32 or 2e-48 or whatever
but one is never exactly on the spot, never really synchronous.

That is only true if you don't control both your step size and your
modulus. No one ever said you had to use 2^n as a modulus.

You have snipped too much context. I was the first to propose
just that, and that my sin/cos function on opencores.org
would be easy to adopt. There even are some TODOs in the VHDL
source code already.

Once, there was a BCD coded DDS from Stanford IIRC that
could get it exact for ateasy-to-write decimal numbers.

Yes, they picked a modulus that worked for them.

exactly.


And I always see here "1 ps jitter" without any qualification.
That makes as much sense as "my car consumes 8 liters of Diesel".
From here to work? per 100 Km? One hefty accelleration?

Jitter needs measurement bandwidth. When I said that telecom ps
are easy, I meant exactly that. They start integrating their
phasenoise at 12 KHz or so. All of the 1/f region is therefore
ignored, and that is the lion's share.


A friend of mine had made systematic phase noise characterizations
when he built frequency synthesizers for avionics and found
that ECL in Mosaic 3 process was about the worst that industry
had to offer, noisewise.

I find it hard to believe that Mosaic's grand children
are suddenly on the other end of the scale. Along with the
ultrafast switching comes ultrawide noise bandwidth where one must
integrate over many harmonics from DC to daylight.


All people I know who are seriously in timing use Schottky ring
mixers as phase detectors and that must have a reason or two.


That does not mean that I dislike ECL. I was an early adoptor
of 10KH and 100K, and right now there are many 100EP51 on this
table


I would not pin my hopes to high that one could transfer much
phase noise cleanliness (is that a word?) from the 10MHz ref to
155MHz. From 10 to 100 MHz the noise goes up 20 dB by principle,
from 100 to 150 abt. another 3 dB - and your ref must be better by
this, without your self-indroduced errors. It is best to leave the
oscillator alone, trying to regulate it is phasenoise-wise an
invitation to desaster, as I could see this spring on the
E5052B. That thing is a real eye opener. Every change must
be slooooow.


And with regard to metastability, IIRC I heard Peter Alfke of Xilinx
say something like "The speed you see in an FPGA nowadays is wiring.
The speed of the decision loop inside a FF is so fast that metastability
just won't happen. One sychronizer stage is enough."
I think the sentence contained "lifetime of the universe", also.
That was in the Virtex-4 time frame, not now with 13 GBit/s I/O.

BCD or any other combination of divisors. One I designed used an
oddball divisor in the lower portion of the accumulator and then a
binary counter in the top. This allowed an exact match to all of the
audio rates needed. Programming the step size used a simple conversion
in software.

LIKE

regards, Gerhard

 

[John Larkin]

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

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


--

John Larkin Highland Technology, Inc

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

 

[Bill Sloman]

On Sunday, 14 September 2014 13:08:01 UTC+10, rickman wrote:

On 9/13/2014 10:54 PM, Bill Sloman wrote:
On Sunday, 14 September 2014 11:51:46 UTC+10, Phil Hobbs wrote:
On 9/13/2014 8:13 PM, rickman wrote:
On 9/13/2014 7:34 PM, 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 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.

It produces zero ps of phase shift in the clocks because the divided
signal is not used to clock anything. It is used to *enable* the FF
that is clocked by one clock and samples the other clock on the D input.

John has said the 80 kHz will be resync'ed to the clock because it comes
from the FPGA with a considerable delay, but as long as that delay puts
it outside of the setup/hold window the delay has no bearing on the
circuit.

That needs thinking about. When I did a similar trick with TTL pulse stream and a 200MHz clock, the propagation delay from the original 200MHz clock was potentially quite a bit longer than 5nsec, and the difference between least delay and worst case delay was more than 5nsec, so I had to allow the user to pick the edge of the 200MHz clock that was furthest away from the actual TTL transitions.

FPGA's tend to be fast than TTL these days, and synchronous dividers using look-ahead carry can have minimal propagation delays from the clock, but 6.43 nsec doesn't give you a lot of propagation time. It's a little more than a metre of coax cable (shades of the faster than light neutrinos).

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.

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

The bang-bang PLL bears a remarkable similarity to the circuit that's used in IC testing to force metastability.

Resyncing the FPGA divider has no hazards, because we can provide safe
setup and hold times.

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.

As John says, if you can meet the specified setup and hold times for the part, you won't get meta-stability.

You can't do that until the 155.52MHz clock is locked to your 10MHz clock and you can pick the occasional clock edge pair - one every 12.5 usec - which is exactly lined up, for which he'll probably need a two-stage - acquire lock then synchronise - process, but if you do do this can you can avoid metastability by careful design.

You seem to be missing the point of the phase detector. It will be
sampling one clock with the other. When the two are in sync the clock
edges will be nearly coincident and the FF will be as close as possible
to metastability at all times... by design. The goal of the circuit is
to put the two clock edges within 1 ps of one another.

No. It's to locate two clock edges within 1 psec of one another.

It's like the type 2 phase detector in the 4046, which has a dead band around perfect synchronisation, so you need to deliberately run it so that it normally sits outside the dead-band. Philips improved it in the 9046

http://www.nxp.com/documents/data_sheet/74HCT9046A.pdf

as described in page 9,10 and 11.

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.

--
Bill Sloman, Sydney

 

[Bill Sloman]

On Sunday, 14 September 2014 16:58:17 UTC+10, Kevin Aylward wrote:

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

<snip>

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

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

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

http://www.analog.com/static/imported-files/data_sheets/AD9915.pdf

does have curves that go lower, but only above about 1MHz frequency offset (whatever that means).

John Larkin does have an aversion to inductors, though a useful inductance at 2.5GHz could look very like a spiral track on a PCB.

Making a varactor-tuned 2.41056 GHz external LC oscillator for an AD9915 might be a neat way of getting a tolerably good synthesised 155.52MHz waveform - with 15.5 samples per 6.43nsec cycle it wouldn't take much low pass filtering to get the output looking sinusoidal.

A second AD9915 would be one - rather expensive - way of getting an 10MHz output to lock to the 10MHz reference clock

--
Bill Sloman, Sydney

 

[Bill Sloman]

On Sunday, 14 September 2014 13:17:17 UTC+10, 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. 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.

--
Bill Sloman, Sydney

 

[Bill Sloman]

On Sunday, 14 September 2014 19:00:03 UTC+10, Bill Sloman wrote:

On Sunday, 14 September 2014 16:58:17 UTC+10, Kevin Aylward wrote
"John Larkin" wrote in message
news:1h291ahulit12anamhhlu27hrapque4mai@4ax.com...

<snip>

http://www.analog.com/static/imported-files/data_sheets/AD9915.pdf

does have curves that go lower, but only above about 1MHz frequency offset (whatever that means).

John Larkin does have an aversion to inductors, though a useful inductance at 2.5GHz could look very like a spiral track on a PCB.

Making a varactor-tuned 2.41056 GHz external LC oscillator for an AD9915 might be a neat way of getting a tolerably good synthesised 155.52MHz waveform - with 15.5 samples per 6.43nsec cycle it wouldn't take much low pass filtering to get the output looking sinusoidal.

Actually, an external RF oscillator for the AD9915 can present any frequency from 500MHz to 2.5GHz. A 2.33288GHz oscillator would give exactly 15 DAC outputs per cycle - it would need low pass filtering, but there wouldn't be any cycle to cycle jitter.

A 1.39968GHz oscillator - 9 times 155.552MHz isn't quite 140 times 10MHz, but it's very close. The DAC values in a 10MHz waveform synthesised from that would creep very slowly.

--
Bill Sloman, Sydney

 

[Bill Sloman]

On Sunday, 14 September 2014 20:14:38 UTC+10, Gerhard Hoffmann wrote:

Am 14.09.2014 um 11:00 schrieb Bill Sloman:

On Sunday, 14 September 2014 16:58:17 UTC+10, Kevin Aylward wrote:

"John Larkin" wrote in message

news:1h291ahulit12anamhhlu27hrapque4mai@4ax.com...



snip



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



looks like you need 2-way time transfer via DLLs and pseudo noise.

My current customer does just that from ground to space & back.





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.

As I've said, I haven't a clue what those curves mean, and I was deliberately fishing for a tutorial ...

John Larkin talks about keeping his jitter inside 1 psec which isn't the same kind of unit at all.

--
Bill Sloman, Sydney

 

[Kevin Aylward]

"Bill Sloman" wrote in message
news:d61371cc-f3b6-4819-9fae-d43abfce7e98@googlegroups.com...

On Sunday, 14 September 2014 03:31:51 UTC+10, Kevin Aylward wrote:

"Bill Sloman" wrote in message
news:e1fabdfb-c4a0-42a0-89b5-66f788ca3cb6@googlegroups.com...
On Wednesday, 10 September 2014 09:54:53 UTC+10, John Larkin wrote:

If I hypothetically had a 10 MHz reference and wanted to lock a 155.52
MHz VCXO to it, the obvious way would be to divide both down to 80 KHz
(the GCD) and drive a phase detector back into the VCXO. But that's a
pretty low frequency to run the PD at; to get picosecond stability, an
ordinary analog phase detector would need better than 1 PPM analog
accuracy, which ain't gonna happen.

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!

Farnell doesn't have them. Digikey does. I searched both for 9.720MHz and a
couple of other multiples before I posted.

I'm aware that 10MHz is a sweet spot frequency for crystal oscillators.
9.720MHz is close enough to 10MHz that the physics is going to be the same.

Actually, there is nothing special about 10 MHz, other than it's a round
number. Around 25 Mhz generally results in around the "best" frequency for
xtal oscillators. One wants as high a frequency as possible, but higher
frequencies have xtal and circuit issues. Its a trade off on best xtal
mechanics and circuit characteristics, e.g. pulling, ps sensitivity, power,
noise, etc. Hint: I have spent a LOT of time running phase noise simulations
on designs over a range of frequencies, over a range of topologies.

19.44MHz is further away, but I'm happy to believe that it's still close
enough.

9.92Mhz is not a good choice. The standard high performance oscillator xtals
are typically design specified for > 10Mhz < 50Mhz They are some speced
lower, but this limits choice.

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

 

[Kevin Aylward]

"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

 

[Jan Panteltje]

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.