PLL tricks

[Gerhard Hoffmann]

Am 15.09.2014 um 20:29 schrieb John Larkin:

Right. I need a 10 MHz bandpass filter with really small delay vs
temperature behavior. Another annoyance, designing a filter and
analyzing its sensitivities and compensating inductors with NTC caps,
or something. Probably I'll measure ambient temp and let the uP tweak
overall delay to nominally zero. That sort of thing will typically
result in a 5:1, maybe even 10:1, TC reduction. I don't want to
temperature cycle units in production, so the slope compensation would
be determined on the first unit and applied to all the rest, if
possible.

Inductors of the type we'd use here seem to have TCs in the (roughly)
+120 PPM/K sort of range.

A filter that is _resonant_ on 10 MHz will have +-45° at the -3 dB
points if it is well behaved. So, a really low working Q helps.

Probably it will turn out to be hipass/lowpass with corners in due
distance from 10 MHz. Multiple poles are probably not so desastrous
then, but at 10 MHz the Hi/Lo-passes must be as flat as can be.


Also, I see that the 1pps goes directly into the high speed compartment
in the block diagramm. 1pps out of a GPS receiver is usually just a
port bit of the CPU. It is precise only if you can average many of these
pulses. If you are lucky there is a register in the GPS where you can
see how far off it was, after the fact.


Cheers, Gerhard

(excellent, that Rioja!)

 

[John Larkin]

On Mon, 15 Sep 2014 02:03:12 +0200, Dimitrij Klingbeil
<nospam@no-address.com> wrote:

On 15.09.2014 01:02, rickman wrote:
On 9/14/2014 3:49 PM, John Larkin wrote:
On Sun, 14 Sep 2014 15:22:10 -0400, rickman <gnuarm@gmail.com
wrote:

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

A very vague explanation. You are using a 1 ps accurate rifle to
hit a target that is moving around by 10's of ps. Then you want to
determine where the target is by watching the rifle.

I think you can have a rifle that is not so good as 1 ps and still
get the same result. It all runs through the same filter.

Well, John did not say what exactly he's trying to fire, but it looks
like he means the "rifle" with the 500 TW. That's a highly distributed
"rifle" with 192 "chambers" being fired synchronously. John's probably
building the "mechanism" responsible for the action of each "pin".

(John, correct me if I'm wrong ...)

Yes, this is for NIF. Some years back, we designed the VME modules
that receive the OC3 fiberoptic master timing signals and fire devices
all over the facility. We phase-lock a 155.52 MHz XO to the data
stream, and decode timing packets.

Now I'm looking into building the other end, the data generator.

http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

The one thing that strikes me as really odd, is that they want the thing
to be synchronized to a 10MHz signal over coax lines. The use of a
higher frequency and fiber optics would likely provide a much better
distribution of the timing signal.

Maybe John should consider running his own ovenized "master oscillator"
at a suitable (higher) frequency and PLLing it to the incoming 10 MHz
with a very long time constant (some people on the well-known Time Nuts
mailing list temperature-stabilize the ovens of their own GPSDOs to
millikelvins and then run the PLLs with filter time constants on the
order of hours or even days in order to keep ADEV as low as they can,
but then they only have a PPS signal to start from). Having 10 MHz to
start from is obviously much better than 1 PPS, so there's no need for
hours or days of PLL stabilization time, but still, using a more short
term stable (translate: less jittery) internal reference is probably
something to consider, before starting to synthesize the 155 MHz.

I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have a
10 MHz SRS OCXO (replacement for an old HP can) that has a couple ps
RMS jitter a full second out. I could discipline that at a very low
loop bandwidth, so an 80 KHz phase detector would be no problem. But
the really good SC-cut crystals run in the low MHz range.



--

John Larkin Highland Technology, Inc

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

 

[Gerhard Hoffmann]

On 9/15/2014 2:40 PM, Jan Panteltje wrote:

I think this is nice:
http://www.arrl.org/files/file/Technology/ard/rohde94.pdf
I always use JFET oscillators.

I almost never do. Bipolars are much more predictable.

And as to cables adding phase noise due to vibration or even gravity:
http://www.ieee-uffc.org/frequency-control/learning/Tutorial_Rev_Q.PDF

This Mr. Driscoll of Northrop/Grumman is the one with the Driscoll
oscillator. It is highly rewarding to read his publications.

regards, Gerhard

 

[Bill Sloman]

On Tuesday, 16 September 2014 11:21:09 UTC+10, John Larkin wrote:

On Tue, 16 Sep 2014 00:51:53 +0200, Dimitrij Klingbeil
nospam@no-address.com> wrote:
On 16.09.2014 00:26, John Larkin wrote:

I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have
a 10 MHz SRS OCXO (replacement for an old HP can) that has a couple
ps RMS jitter a full second out. I could discipline that at a very
low loop bandwidth, so an 80 KHz phase detector would be no problem.
But the really good SC-cut crystals run in the low MHz range.

a recent posting on the Time Nuts mailing list mentioned a GHz range
VCXO (with what seems a rather complex internal multiplier and filter
structure) that's supposed to have noise in the picosecond range.

http://www.jackson-labs.com/index.php/products/uln_1g

There are some phase noise graphs, but it's far out of my range of
experience to interpret them, so this thing may be in the ballpark of
what you are looking for - or it it may not.

The pulling range is +/- 50 kHz @ 1GHz nominal and the range of
available nominal frequencies is from 800 MHz to 1.2 GHz. Two
frequencies in that range that will divide exactly to 155.52 MHz
(x6 and x7), many more will with a fractional PLL.

The module looks decidedly non-cheap (at least from appearance, no idea
what it really costs), but who knows, if might be worth an inquiry.

Fox and SciLabs make tiny surface-mount synthesized (any frequency you
want) VCXOs with PECL outputs and claimed sub-ps RMS jitter. The
question is, over what time span is the jitter that low?

If you ask, they will probably tell you.

You aren't interested in longer periods, because eventually you are going use their voltage input to lock the frequency to the 10MHz reference which you are given as part of your site services, and to which you are obliged to lock your 155.52MHz frequency source.

The time constant around the phase-locked loop that eventually locks your 155.52MHz output is a design choice, and one that should reflect the characteristics of the VXCO from which you generate your 155.5.2MHz.

In fact the obvious SciLab part

http://www.silabs.com/Support%20Documents/TechnicalDocs/si550.pdf

will give you anything from 10 to 945MHz and selected outputs up to 1.4GHz.

If you wanted something to divide down to 10MHz and 155.52MHz, choosing 933..12MHz and feeding it into a pair of AD9915's - as an external reference clock - might be a neat solution. A value of 1.9968GHz is just inside the 1.4GHz limit, and quite close to an exact multiple of 10MHz.

--
Bill Sloman, Sydney

 

[Dimitrij Klingbeil]

On 16.09.2014 00:26, John Larkin wrote:

I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have
a 10 MHz SRS OCXO (replacement for an old HP can) that has a couple
ps RMS jitter a full second out. I could discipline that at a very
low loop bandwidth, so an 80 KHz phase detector would be no problem.
But the really good SC-cut crystals run in the low MHz range.

John,

a recent posting on the Time Nuts mailing list mentioned a GHz range
VCXO (with what seems a rather complex internal multiplier and filter
structure) that's supposed to have noise in the picosecond range.

http://www.jackson-labs.com/index.php/products/uln_1g

There are some phase noise graphs, but it's far out of my range of
experience to interpret them, so this thing may be in the ballpark of
what you are looking for - or it it may not.

The pulling range is +/- 50 kHz @ 1GHz nominal and the range of
available nominal frequencies is from 800 MHz to 1.2 GHz. Two
frequencies in that range that will divide exactly to 155.52 MHz
(x6 and x7), many more will with a fractional PLL.

The module looks decidedly non-cheap (at least from appearance, no idea
what it really costs), but who knows, if might be worth an inquiry.

Regards
Dimitrij

 

[Tom Miller]

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:k9pe1a1ak6jciebmt9o6rsb85pn5cverig@4ax.com...

On Mon, 15 Sep 2014 02:03:12 +0200, Dimitrij Klingbeil
nospam@no-address.com> wrote:

On 15.09.2014 01:02, rickman wrote:
On 9/14/2014 3:49 PM, John Larkin wrote:
On Sun, 14 Sep 2014 15:22:10 -0400, rickman <gnuarm@gmail.com
wrote:

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

A very vague explanation. You are using a 1 ps accurate rifle to
hit a target that is moving around by 10's of ps. Then you want to
determine where the target is by watching the rifle.

I think you can have a rifle that is not so good as 1 ps and still
get the same result. It all runs through the same filter.

Well, John did not say what exactly he's trying to fire, but it looks
like he means the "rifle" with the 500 TW. That's a highly distributed
"rifle" with 192 "chambers" being fired synchronously. John's probably
building the "mechanism" responsible for the action of each "pin".

(John, correct me if I'm wrong ...)


Yes, this is for NIF. Some years back, we designed the VME modules
that receive the OC3 fiberoptic master timing signals and fire devices
all over the facility. We phase-lock a 155.52 MHz XO to the data
stream, and decode timing packets.

Now I'm looking into building the other end, the data generator.

http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf


The one thing that strikes me as really odd, is that they want the thing
to be synchronized to a 10MHz signal over coax lines. The use of a
higher frequency and fiber optics would likely provide a much better
distribution of the timing signal.

Maybe John should consider running his own ovenized "master oscillator"
at a suitable (higher) frequency and PLLing it to the incoming 10 MHz
with a very long time constant (some people on the well-known Time Nuts
mailing list temperature-stabilize the ovens of their own GPSDOs to
millikelvins and then run the PLLs with filter time constants on the
order of hours or even days in order to keep ADEV as low as they can,
but then they only have a PPS signal to start from). Having 10 MHz to
start from is obviously much better than 1 PPS, so there's no need for
hours or days of PLL stabilization time, but still, using a more short
term stable (translate: less jittery) internal reference is probably
something to consider, before starting to synthesize the 155 MHz.

I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have a
10 MHz SRS OCXO (replacement for an old HP can) that has a couple ps
RMS jitter a full second out. I could discipline that at a very low
loop bandwidth, so an 80 KHz phase detector would be no problem. But
the really good SC-cut crystals run in the low MHz range.



--

Can you get an AT cut 17.28 MHz xtal (maybe in an oven?) and multiply it by
9X to get the 155.52 signal? I know that will also multiply the jitter but
if it starts clean enough, it might meet your spec.

Also, I have seen Rubidium clock oscillators that have a DDS output that is
user selectable. I wonder if it would be clean enough?

 

[rickman]

On 9/15/2014 6:12 PM, John Larkin wrote:

On Mon, 15 Sep 2014 16:52:42 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 3:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 14:46:27 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:24 AM, Phil Hobbs wrote:
On 9/14/2014 11:31 PM, rickman wrote:
On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
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.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


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.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Where is the output?

From the VCXO.

Ok, so how much does the resync FF add to the jitter? It seems there is
no concern with the actual delay, just the jitter.

I'd guess that the FPGA divide-by-1944 might have 5 or 10 ps RMS
jitter, and will have a ghastly TC, 10s of ps per degree C. The ECL
resync flop cleans all that up.

That doesn't answer the question. How much jitter does the resynch FF
add to the VCXO clock jitter? Do you have a number or at least an order
of magnitude?


The MC10EP52 has a data sheet typical random jitter of 200 fs RMS, 1
ps max. I can't measure that low. Our best scope is about 1.5 ps RMS.

Ok, so you are using your entire jitter budget time in this one part, 1
ps. By using two your max jitter is 2 ps. Now how much will the rest
of the system add to that? Obviously you won't be able to claim a 1 ps
jitter spec on your output. I guess you will work with an an RMS number
rather than a max though, then you might be able to keep it in the 1 ps
range.

--

Rick

 

[Phil Hobbs]

On 9/15/2014 7:05 PM, Tom Miller wrote:

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:k9pe1a1ak6jciebmt9o6rsb85pn5cverig@4ax.com...
On Mon, 15 Sep 2014 02:03:12 +0200, Dimitrij Klingbeil
nospam@no-address.com> wrote:

On 15.09.2014 01:02, rickman wrote:
On 9/14/2014 3:49 PM, John Larkin wrote:
On Sun, 14 Sep 2014 15:22:10 -0400, rickman <gnuarm@gmail.com
wrote:

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

A very vague explanation. You are using a 1 ps accurate rifle to
hit a target that is moving around by 10's of ps. Then you want to
determine where the target is by watching the rifle.

I think you can have a rifle that is not so good as 1 ps and still
get the same result. It all runs through the same filter.

Well, John did not say what exactly he's trying to fire, but it looks
like he means the "rifle" with the 500 TW. That's a highly distributed
"rifle" with 192 "chambers" being fired synchronously. John's probably
building the "mechanism" responsible for the action of each "pin".

(John, correct me if I'm wrong ...)


Yes, this is for NIF. Some years back, we designed the VME modules
that receive the OC3 fiberoptic master timing signals and fire devices
all over the facility. We phase-lock a 155.52 MHz XO to the data
stream, and decode timing packets.

Now I'm looking into building the other end, the data generator.

http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf


The one thing that strikes me as really odd, is that they want the thing
to be synchronized to a 10MHz signal over coax lines. The use of a
higher frequency and fiber optics would likely provide a much better
distribution of the timing signal.

Maybe John should consider running his own ovenized "master oscillator"
at a suitable (higher) frequency and PLLing it to the incoming 10 MHz
with a very long time constant (some people on the well-known Time Nuts
mailing list temperature-stabilize the ovens of their own GPSDOs to
millikelvins and then run the PLLs with filter time constants on the
order of hours or even days in order to keep ADEV as low as they can,
but then they only have a PPS signal to start from). Having 10 MHz to
start from is obviously much better than 1 PPS, so there's no need for
hours or days of PLL stabilization time, but still, using a more short
term stable (translate: less jittery) internal reference is probably
something to consider, before starting to synthesize the 155 MHz.

I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have a
10 MHz SRS OCXO (replacement for an old HP can) that has a couple ps
RMS jitter a full second out. I could discipline that at a very low
loop bandwidth, so an 80 KHz phase detector would be no problem. But
the really good SC-cut crystals run in the low MHz range.



--

Can you get an AT cut 17.28 MHz xtal (maybe in an oven?) and multiply it
by 9X to get the 155.52 signal? I know that will also multiply the
jitter but if it starts clean enough, it might meet your spec.

It won't multiply the jitter. The phase noise goes up because the
period goes down, so a given number of picoseconds amounts to more radians.

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 Mon, 15 Sep 2014 19:15:10 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 6:12 PM, John Larkin wrote:
On Mon, 15 Sep 2014 16:52:42 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 3:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 14:46:27 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:24 AM, Phil Hobbs wrote:
On 9/14/2014 11:31 PM, rickman wrote:
On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
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.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


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.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Where is the output?

From the VCXO.

Ok, so how much does the resync FF add to the jitter? It seems there is
no concern with the actual delay, just the jitter.

I'd guess that the FPGA divide-by-1944 might have 5 or 10 ps RMS
jitter, and will have a ghastly TC, 10s of ps per degree C. The ECL
resync flop cleans all that up.

That doesn't answer the question. How much jitter does the resynch FF
add to the VCXO clock jitter? Do you have a number or at least an order
of magnitude?


The MC10EP52 has a data sheet typical random jitter of 200 fs RMS, 1
ps max. I can't measure that low. Our best scope is about 1.5 ps RMS.

Ok, so you are using your entire jitter budget time in this one part, 1
ps. By using two your max jitter is 2 ps.

A) My entire jitter budget is not 1 ps

B) Random jitter adds as the square root of the summed squares, not
linearly.


--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Mon, 15 Sep 2014 15:39:51 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

Den tirsdag den 16. september 2014 00.26.41 UTC+2 skrev John Larkin:
On Mon, 15 Sep 2014 02:03:12 +0200, Dimitrij Klingbeil

nospam@no-address.com> wrote:



On 15.09.2014 01:02, rickman wrote:

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

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

wrote:



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

reference.



A very vague explanation. You are using a 1 ps accurate rifle to

hit a target that is moving around by 10's of ps. Then you want to

determine where the target is by watching the rifle.



I think you can have a rifle that is not so good as 1 ps and still

get the same result. It all runs through the same filter.



Well, John did not say what exactly he's trying to fire, but it looks

like he means the "rifle" with the 500 TW. That's a highly distributed

"rifle" with 192 "chambers" being fired synchronously. John's probably

building the "mechanism" responsible for the action of each "pin".



(John, correct me if I'm wrong ...)





Yes, this is for NIF. Some years back, we designed the VME modules

that receive the OC3 fiberoptic master timing signals and fire devices

all over the facility. We phase-lock a 155.52 MHz XO to the data

stream, and decode timing packets.



Now I'm looking into building the other end, the data generator.



http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf





The one thing that strikes me as really odd, is that they want the thing

to be synchronized to a 10MHz signal over coax lines. The use of a

higher frequency and fiber optics would likely provide a much better

distribution of the timing signal.



Maybe John should consider running his own ovenized "master oscillator"

at a suitable (higher) frequency and PLLing it to the incoming 10 MHz

with a very long time constant (some people on the well-known Time Nuts

mailing list temperature-stabilize the ovens of their own GPSDOs to

millikelvins and then run the PLLs with filter time constants on the

order of hours or even days in order to keep ADEV as low as they can,

but then they only have a PPS signal to start from). Having 10 MHz to

start from is obviously much better than 1 PPS, so there's no need for

hours or days of PLL stabilization time, but still, using a more short

term stable (translate: less jittery) internal reference is probably

something to consider, before starting to synthesize the 155 MHz.



I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have a

10 MHz SRS OCXO (replacement for an old HP can) that has a couple ps

RMS jitter a full second out. I could discipline that at a very low

loop bandwidth, so an 80 KHz phase detector would be no problem. But

the really good SC-cut crystals run in the low MHz range.


first hit on google, http://www.accusilicon.com/155.52MHz.htm

-Lasse

I've seen that. I'd have to convert the phase noise curve to jitter.
If I had a 10 Hz loop, I'd be running at the -73 dB point, whatever
that means. Their fs jitter spec is (probably?) cycle to cycle.

But I should investigate further. Thanks.




--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Tue, 16 Sep 2014 00:51:53 +0200, Dimitrij Klingbeil
<nospam@no-address.com> wrote:

On 16.09.2014 00:26, John Larkin wrote:

I'd love to buy a 155.52 MHz VCXO that has really low jitter. I have
a 10 MHz SRS OCXO (replacement for an old HP can) that has a couple
ps RMS jitter a full second out. I could discipline that at a very
low loop bandwidth, so an 80 KHz phase detector would be no problem.
But the really good SC-cut crystals run in the low MHz range.

John,

a recent posting on the Time Nuts mailing list mentioned a GHz range
VCXO (with what seems a rather complex internal multiplier and filter
structure) that's supposed to have noise in the picosecond range.

http://www.jackson-labs.com/index.php/products/uln_1g

There are some phase noise graphs, but it's far out of my range of
experience to interpret them, so this thing may be in the ballpark of
what you are looking for - or it it may not.

The pulling range is +/- 50 kHz @ 1GHz nominal and the range of
available nominal frequencies is from 800 MHz to 1.2 GHz. Two
frequencies in that range that will divide exactly to 155.52 MHz
(x6 and x7), many more will with a fractional PLL.

The module looks decidedly non-cheap (at least from appearance, no idea
what it really costs), but who knows, if might be worth an inquiry.

Regards
Dimitrij

Fox and SciLabs make tiny surface-mount synthesized (any frequency you
want) VCXOs with PECL outputs and claimed sub-ps RMS jitter. The
question is, over what time span is the jitter that low?




--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:11 PM, John Larkin wrote:
On Mon, 15 Sep 2014 19:15:10 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 6:12 PM, John Larkin wrote:
On Mon, 15 Sep 2014 16:52:42 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 3:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 14:46:27 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:24 AM, Phil Hobbs wrote:
On 9/14/2014 11:31 PM, rickman wrote:
On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
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.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


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.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Where is the output?

From the VCXO.

Ok, so how much does the resync FF add to the jitter? It seems there is
no concern with the actual delay, just the jitter.

I'd guess that the FPGA divide-by-1944 might have 5 or 10 ps RMS
jitter, and will have a ghastly TC, 10s of ps per degree C. The ECL
resync flop cleans all that up.

That doesn't answer the question. How much jitter does the resynch FF
add to the VCXO clock jitter? Do you have a number or at least an order
of magnitude?


The MC10EP52 has a data sheet typical random jitter of 200 fs RMS, 1
ps max. I can't measure that low. Our best scope is about 1.5 ps RMS.

Ok, so you are using your entire jitter budget time in this one part, 1
ps. By using two your max jitter is 2 ps.

A) My entire jitter budget is not 1 ps

B) Random jitter adds as the square root of the summed squares, not
linearly.

That is RMS, I was quoting peak (max). See above in the text you quoted...

The 10EP52 data sheet is available online, at OnSemi.

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

"Peak jitter" has no meaning.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.


--

John Larkin Highland Technology, Inc

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

 

[rickman]

On 9/15/2014 11:08 PM, John Larkin wrote:

On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

--

Rick

 

[ChesterW]

On 9/15/14, 4:55 PM, Phil Hobbs wrote:
<snip>

*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Cheers

Phil Hobbs

It's elegant, but it seems counter-intuitive that the rather tough specs
can be met when throwing away over 99% of the phase comparison
information (1-1/125).

ChesterW

For a constant loop bandwidth, you should get some noise averaging by
doing the phase comparison faster, I agree. However, since you have to
crank down the BW to filter out the gross amounts of ripple from a
bang-bang phase detector, I expect that it won't be that different
inside the BW.

Of course, losing all that loop bandwidth does mean that the VCXO has to
be a lot better than it would with a 10 MHz comparison frequency.

Using local feedback, i.e. a DDS-based or fractional-N loop (wide loop
BW but probably fairly horrible drift) inside an 80-kHz bang-bang loop
would relax the requirements on the VCXO proper.

This is all such fun that I may have to try building something like that.

Cheers

Phil Hobbs

Yes, John Larkin gets the prize for the most interesting project of the
week. Lucky dog.

Here's a possible idea for evaluating the feasibility of different
schemes. Calculate the entropy of the 155.52 MHz signal. Estimate the
frequency drift of the VCXO and represent it as the number of bits of
information lost per 12.5 us update period. Then the feedback needs to
supply at least this number of bits of information to be a possible
solution. If the required feedback SNR is too high, then you know you
need to use the information from more phase comparisons, not just the
easy 12.5 us ones.

ChesterW

 

[Bill Sloman]

On Tuesday, 16 September 2014 15:21:44 UTC+10, ChesterW wrote:
> On 9/15/14, 4:55 PM, Phil Hobbs wrote:

<snip>

Yes, John Larkin gets the prize for the most interesting project of the
week. Lucky dog.

Not exactly lucky. He sold the same mob quite a lot of hardware when they first set up their 192 precisely synchronised lasers.

He's been carving a niche for himself in that kind of high-speed gear for quite some time now. Interesting that he doesn't seem to know as much about it as Phil Hobbs and Keven Alyward, who haven't. Getting stuff to work does seem to steal time from thinking about how it works.

--
Bill Sloman, Sydney

<snipped dubious idea>

 

[John Larkin]

On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:11 PM, John Larkin wrote:
On Mon, 15 Sep 2014 19:15:10 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 6:12 PM, John Larkin wrote:
On Mon, 15 Sep 2014 16:52:42 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 3:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 14:46:27 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:24 AM, Phil Hobbs wrote:
On 9/14/2014 11:31 PM, rickman wrote:
On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
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.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


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.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Where is the output?

From the VCXO.

Ok, so how much does the resync FF add to the jitter? It seems there is
no concern with the actual delay, just the jitter.

I'd guess that the FPGA divide-by-1944 might have 5 or 10 ps RMS
jitter, and will have a ghastly TC, 10s of ps per degree C. The ECL
resync flop cleans all that up.

That doesn't answer the question. How much jitter does the resynch FF
add to the VCXO clock jitter? Do you have a number or at least an order
of magnitude?


The MC10EP52 has a data sheet typical random jitter of 200 fs RMS, 1
ps max. I can't measure that low. Our best scope is about 1.5 ps RMS.

Ok, so you are using your entire jitter budget time in this one part, 1
ps. By using two your max jitter is 2 ps.

A) My entire jitter budget is not 1 ps

B) Random jitter adds as the square root of the summed squares, not
linearly.

That is RMS, I was quoting peak (max). See above in the text you quoted...

The 10EP52 data sheet is available online, at OnSemi.

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

"Peak jitter" has no meaning.


--

John Larkin Highland Technology, Inc

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

 

[josephkk]

On Tue, 16 Sep 2014 00:21:17 +0200, Gerhard Hoffmann
<ghf@hoffmann-hochfrequenz.de> wrote:

Am 15.09.2014 um 20:29 schrieb John Larkin:


Right. I need a 10 MHz bandpass filter with really small delay vs
temperature behavior. Another annoyance, designing a filter and
analyzing its sensitivities and compensating inductors with NTC caps,
or something. Probably I'll measure ambient temp and let the uP tweak
overall delay to nominally zero. That sort of thing will typically
result in a 5:1, maybe even 10:1, TC reduction. I don't want to
temperature cycle units in production, so the slope compensation would
be determined on the first unit and applied to all the rest, if
possible.

Inductors of the type we'd use here seem to have TCs in the (roughly)
+120 PPM/K sort of range.

A filter that is _resonant_ on 10 MHz will have +-45° at the -3 dB
points if it is well behaved. So, a really low working Q helps.

Probably it will turn out to be hipass/lowpass with corners in due
distance from 10 MHz. Multiple poles are probably not so desastrous
then, but at 10 MHz the Hi/Lo-passes must be as flat as can be.


Also, I see that the 1pps goes directly into the high speed compartment
in the block diagramm. 1pps out of a GPS receiver is usually just a
port bit of the CPU. It is precise only if you can average many of these
pulses. If you are lucky there is a register in the GPS where you can
see how far off it was, after the fact.


Cheers, Gerhard

(excellent, that Rioja!)

Unlikely. The 1 PPS copes out of the GPS chipset directly and has some
pretty interesting specifications. Look them up some time.

?-)

 

[josephkk]

On Sun, 14 Sep 2014 20:58:33 -0400, Phil Hobbs <hobbs@electrooptical.net>
wrote:

On 9/14/2014 8:53 PM, josephkk wrote:
On Sun, 14 Sep 2014 17:53:42 -0400, Phil Hobbs <hobbs@electrooptical.net
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

I am not so sure about that. It seems to me that you have used native LC
tank phase noise when a forcing function version is more appropriate.

?-)


How so? I didn't mention phase noise, just tempco.

Cheers

Phil Hobbs

My bad on switching dimensions incorrectly. I think my question still
applies to tempco.

?-)

 

[rickman]

On 9/15/2014 9:11 PM, John Larkin wrote:

On Mon, 15 Sep 2014 19:15:10 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 6:12 PM, John Larkin wrote:
On Mon, 15 Sep 2014 16:52:42 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 3:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 14:46:27 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:24 AM, Phil Hobbs wrote:
On 9/14/2014 11:31 PM, rickman wrote:
On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
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.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


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.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Where is the output?

From the VCXO.

Ok, so how much does the resync FF add to the jitter? It seems there is
no concern with the actual delay, just the jitter.

I'd guess that the FPGA divide-by-1944 might have 5 or 10 ps RMS
jitter, and will have a ghastly TC, 10s of ps per degree C. The ECL
resync flop cleans all that up.

That doesn't answer the question. How much jitter does the resynch FF
add to the VCXO clock jitter? Do you have a number or at least an order
of magnitude?


The MC10EP52 has a data sheet typical random jitter of 200 fs RMS, 1
ps max. I can't measure that low. Our best scope is about 1.5 ps RMS.

Ok, so you are using your entire jitter budget time in this one part, 1
ps. By using two your max jitter is 2 ps.

A) My entire jitter budget is not 1 ps

B) Random jitter adds as the square root of the summed squares, not
linearly.

That is RMS, I was quoting peak (max). See above in the text you quoted...

--

Rick

 

[rickman]

On 9/15/2014 10:33 PM, John Larkin wrote:

On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:11 PM, John Larkin wrote:
On Mon, 15 Sep 2014 19:15:10 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 6:12 PM, John Larkin wrote:
On Mon, 15 Sep 2014 16:52:42 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 3:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 14:46:27 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 9:24 AM, Phil Hobbs wrote:
On 9/14/2014 11:31 PM, rickman wrote:
On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
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.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


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.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Where is the output?

From the VCXO.

Ok, so how much does the resync FF add to the jitter? It seems there is
no concern with the actual delay, just the jitter.

I'd guess that the FPGA divide-by-1944 might have 5 or 10 ps RMS
jitter, and will have a ghastly TC, 10s of ps per degree C. The ECL
resync flop cleans all that up.

That doesn't answer the question. How much jitter does the resynch FF
add to the VCXO clock jitter? Do you have a number or at least an order
of magnitude?


The MC10EP52 has a data sheet typical random jitter of 200 fs RMS, 1
ps max. I can't measure that low. Our best scope is about 1.5 ps RMS.

Ok, so you are using your entire jitter budget time in this one part, 1
ps. By using two your max jitter is 2 ps.

A) My entire jitter budget is not 1 ps

B) Random jitter adds as the square root of the summed squares, not
linearly.

That is RMS, I was quoting peak (max). See above in the text you quoted...

The 10EP52 data sheet is available online, at OnSemi.

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

"Peak jitter" has no meaning.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

--

Rick