Stratum4E holdover

I'm working on a CT-bus (H100) implementation.
Can I use the SPARTAN3E DCM to (help to) generate the HOLDOVER
capability for the 8MHz clocks (CT_C8_A and CT_C8_B)? They must meet
Stratum4E (stability of 3.7x10^-7/day).
Austin, maybe you have an advice!

Luiz Carlos.

Luiz,

It has been almost eight years now....

But, How I solved similar problems was to choose a basic oscillator that 
had the necessary stability requirement (less than the 3.7E-7 drift per 
day), and then use a DDFS (direct digital frequency synthesizer) in the 
FPGA fabric to generate a frequency that tracks the incoming reference. 
  When the reference is lost, the DDFS value is no longer updated.

Then the output is whatever the last best guess of frequency and phase 
was, and you will drift within the specs of the oscillator.

Do not get a voltage controlled oscillator:  you will not use the 
adjustment, it cots more money, and it ruins the inherent stability of 
any oscillator.

Do get an oscillator that is at least 2X higher frequency than is needed 
(I used 8X higher).  Any frequency may be used, as the synthesizer can 
take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
you need.  I used for the 2E clocks, the raw rubidium output, which was 
50.2037(etc) MHz (basically every rubidium is shlightly different, but 
they don't drift very much <1E-12, and some don't drift at all! - tested 
them for 8 months with less than 1E-14 drift...).

I used a 48 bit synthesizer (each step was 3.5E-15 of the oscillator 
frequency).  For Stratum 4E, a smaller DDFS accumulator can be used, 
perhaps as few as 40 bits?  Since the logic is so small, it is effectly 
free.

The tracking algorithm needs some thought.  The phase detctor needs some 
thought.  The reasons to stop tracking needs a lot of though.  The 
reasons to start tracking again also needs thought.

There are many standards that must be met, as well.

It may be that 4E has to tracking requirement, but if you don't at least 
start with the last best guess of frequency, you will cause slips 
everywhere.  Just can't remember how featured 4E is.  I know 3E has 
tracking.  Stratum 4 has no tracking requirement, just a frequency accuracy.

Looking at the data sheets for commercial stratum clocks will give you 
an idea of what is needed for features, and performance levels.

Depending on how you implement your loop, there is a patent on the way I 
did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for 
'All digital locked loop'...).  If you do it that way, there is a 
company that owns it, and will not like it.

Austin


oen_no_spam@yahoo.com.br wrote:

> I'm working on a CT-bus (H100) implementation.
> Can I use the SPARTAN3E DCM to (help to) generate the HOLDOVER
> capability for the 8MHz clocks (CT_C8_A and CT_C8_B)? They must meet
> Stratum4E (stability of 3.7x10^-7/day).
> Austin, maybe you have an advice!
> 
> Luiz Carlos.
> 

Austin Lesea schrieb:


> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
> you need.  I used for the 2E clocks, the raw rubidium output, which was 
> 50.2037(etc) MHz (basically every rubidium is shlightly different, but 
> they don't drift very much <1E-12, and some don't drift at all! - tested 
> them for 8 months with less than 1E-14 drift...).
> 
> The tracking algorithm needs some thought.  The phase detctor needs some 
> thought.  The reasons to stop tracking needs a lot of though.  The 
> reasons to start tracking again also needs thought.

> Depending on how you implement your loop, there is a patent on the way I 
> did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for 

Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are 
your friends.
Plug & Play.

MFG
Falk

Falk,

Very good point!

Also check out ICS.

Austin

Falk Brunner wrote:

> Austin Lesea schrieb:
> 
> 
>> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
>> you need.  I used for the 2E clocks, the raw rubidium output, which 
>> was 50.2037(etc) MHz (basically every rubidium is shlightly different, 
>> but they don't drift very much <1E-12, and some don't drift at all! - 
>> tested them for 8 months with less than 1E-14 drift...).
>>
>> The tracking algorithm needs some thought.  The phase detctor needs 
>> some thought.  The reasons to stop tracking needs a lot of though.  
>> The reasons to start tracking again also needs thought.
> 
> 
>> Depending on how you implement your loop, there is a patent on the way 
>> I did it (uspto.gov, search on - Austin, Lesea, as inventor, and look for 
> 
> 
> Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are 
> your friends.
> Plug & Play.
> 
> MFG
> Falk

and,

IDT also has products.

Hard to beat when it is all done for you, and costs only ~$20 for the ASSP.

Austin

Austin Lesea wrote:

> Falk,
> 
> Very good point!
> 
> Also check out ICS.
> 
> Austin
> 
> Falk Brunner wrote:
> 
>> Austin Lesea schrieb:
>>
>>
>>> take a 20.000 MHz oscillator and generate exactly the 8 MHz reference 
>>> you need.  I used for the 2E clocks, the raw rubidium output, which 
>>> was 50.2037(etc) MHz (basically every rubidium is shlightly 
>>> different, but they don't drift very much <1E-12, and some don't 
>>> drift at all! - tested them for 8 months with less than 1E-14 drift...).
>>>
>>> The tracking algorithm needs some thought.  The phase detctor needs 
>>> some thought.  The reasons to stop tracking needs a lot of though.  
>>> The reasons to start tracking again also needs thought.
>>
>>
>>
>>> Depending on how you implement your loop, there is a patent on the 
>>> way I did it (uspto.gov, search on - Austin, Lesea, as inventor, and 
>>> look for 
>>
>>
>>
>> Maybe a ASSP is an easier solution. Zarlink (formerly Mitel) & Co are 
>> your friends.
>> Plug & Play.
>>
>> MFG
>> Falk

Falk,
I know the Zarlink parts, but I already have the FPGA for other
functions. So I want to use it. Thanks anyway.

Austin,
First, thankyou very much.

I was looking "Frequency Synthesis" by Austin Lesea (what a
coincidence, do You know him?) at Xcell 31.
I didn't understand how can I have a jitter reduction, synthetising a
higher frequency and then, dividing it down. The jitter will be the
period of the incoming clock, isn't it?
Now, let's say I have a 50MHz very stable clock. Using DDFS, I generate
a 8.192MHz clock. The size of the adder (number of bits) will be
related to the precision desired, but will not be related to the
jitter. The jitter, will be 20ns (1/50MHz).
To get a better jitter I can:
a) use one DCM at the input clock to generate a higher input clock
(N*50MHz),
b) use one DCM (the DLL part) at the output clock to filter it (I'm not
sure about this).

Can you comment on this?

Luiz Carlos

Sure,

The 20 ns will be there (in your example) and the only way to remove it 
is to filter it out.

Filters come in two forms:  a PLL, and also one can use a LC tank (with 
a Q>100).

The LC tank is very analog, but works great.  It is what I used:  MSB of 
DDFS into a 100K resistor into the LC tank, followed by a fast 
comparator.  Residual jitter was less than 1% from 10 Hz up.

A PLL with a long time constant is also very good.  I made them with 
VCXO's, an RC network to the voltage control, and a XOR phase detector.

Austin

oen_no_spam@yahoo.com.br wrote:

> Falk,
> I know the Zarlink parts, but I already have the FPGA for other
> functions. So I want to use it. Thanks anyway.
> 
> Austin,
> First, thankyou very much.
> 
> I was looking "Frequency Synthesis" by Austin Lesea (what a
> coincidence, do You know him?) at Xcell 31.
> I didn't understand how can I have a jitter reduction, synthetising a
> higher frequency and then, dividing it down. The jitter will be the
> period of the incoming clock, isn't it?
> Now, let's say I have a 50MHz very stable clock. Using DDFS, I generate
> a 8.192MHz clock. The size of the adder (number of bits) will be
> related to the precision desired, but will not be related to the
> jitter. The jitter, will be 20ns (1/50MHz).
> To get a better jitter I can:
> a) use one DCM at the input clock to generate a higher input clock
> (N*50MHz),
> b) use one DCM (the DLL part) at the output clock to filter it (I'm not
> sure about this).
> 
> Can you comment on this?
> 
> Luiz Carlos
> 

oen_no_spam@yahoo.com.br schrieb:
> Falk,
> I know the Zarlink parts, but I already have the FPGA for other
> functions. So I want to use it. Thanks anyway.

I see. And I know that you like the challenge. But from a economic point 
of view its a matter of part cost (Austin quoted 20 $) versus 
developlment (and verification) time. And its not done in an hour if you 
did'nt do it before and are a 100% pro in this sector.

> To get a better jitter I can:
> a) use one DCM at the input clock to generate a higher input clock
> (N*50MHz),

Yes.

> b) use one DCM (the DLL part) at the output clock to filter it (I'm not
> sure about this).

Nope.

Regards
Falk

Austin and Falk,  thankyou again.

I'm aware of the development costs. But there is the self-satisfaction,
and $20 is more than the price of the FPGA itself. Less one chip to
understand, less one chip in the BOM, less space on the PCB, less one
device on the JTAG chain... And I have some time.

I had another idea to diminish the jitter:
Let's suppose CLKA is the 8.192MHz clock that I want to track.
CLKB is a 8.192MHz clock generated by a stable oscilator.
CLKB will drift from CLKA at stable rate "R" (in radians/second).
So, using the DCM Phase Shifter at the "VARIABLE Phase Shift Mode", and
incrementing/decrementing the phase shift value at the correct rate
"R", it's possible to accomplish the holdover capability.
As the Phase Shifter can have 512 steps (for the whole 2*pi radians),
we can have a 1/8.192MHz/512=238ps jitter.
Multiplying CLKB by N (and after the Phase Shifter, dividing it by N),
the jitter will be divided by N.
Can it be done?

Luiz Carlos

oen_no_spam@yahoo.com.br schrieb:

> I had another idea to diminish the jitter:
> Let's suppose CLKA is the 8.192MHz clock that I want to track.
> CLKB is a 8.192MHz clock generated by a stable oscilator.
> CLKB will drift from CLKA at stable rate "R" (in radians/second).
> So, using the DCM Phase Shifter at the "VARIABLE Phase Shift Mode", and
> incrementing/decrementing the phase shift value at the correct rate
> "R", it's possible to accomplish the holdover capability.
> As the Phase Shifter can have 512 steps (for the whole 2*pi radians),
> we can have a 1/8.192MHz/512=238ps jitter.

> Multiplying CLKB by N (and after the Phase Shifter, dividing it by N),
> the jitter will be divided by N.

I doubt that you can savely multiply the 8.192 MHz clock using a DCM. 
The DCM is quite sensitive to incomming jitter. Its "only" designed to 
do multiplication/phase shift/whatever using almost crystal clear clocks 
comming from a XO or similar source. I think using a RC-oscillator as a 
clock source will make the DCM lose track.
Similar thing for the integrated PLLs from vendor A. ;-) But Iam a 
little bit confused. Should a PLL not have MUCH better jitter tolerance?

I would use a high quality (TC)XO, multiply this using a DCM and 
generate my 8.912 clock. If really necessary, use a LC-tank/analog 
PLL/whatever to clean up residual jitter.

Regards
Falk

P.S. I remember Ray asking for some properties of the phase shifter to 
do some similar tricks (fast setting of phase shift). AFAIK the answers 
from Xilins were rather disillusioning.