[time-nuts] femtosecond jitter anyone?

[Chris Mack]

Hey Chris,

Thanks for the response...  notes below

On Apr 23, 2009, at 12:19 AM, Chris Caudle wrote:

> I'm a little late following up on this, but hopefully not too out of  
> context.
>
> On Wed, April 8, 2009 10:23 pm, Chris Mack wrote:
>> The box / design of interest has ADCs, DACs, and a 38.88MHz OCXO of
>> marginal performance coupled with the proposed DSP based PLLs
>> generating a local clock for the ADCs and DACs all on the same
>> circuit board in synch with external gear.
>
> This sounds like a very complicated way to avoid having to make a PLL.
> Why don't you just use a good quality VCXO in a PLL to sync to the  
> house
> clock, and a really low loop frequency, assuming your VCXO phase noise
> specs are better than the house clock phase noise at the PLL corner
> frequency?
>

The Silicon Labs DSPLL(TM) chip is a 3 port device... Ovenized xtal on  
the reference clock port (also clocks the DSP internally), input clock  
(house word clock or rubidium) port, and output clocked port (cleaned  
version of input clock).  The xtal reference port needs a low jitter  
clock as it will transfer its jitter to the output clock in a 1:1  
ratio.... The frequency is not as critical (long term) e.g., aging.   
If the input clock is a 10MHz rubidium that has some short term issues  
with close-in phase noise, the DSPLL will clean it as best it can  
compared to jitter on the ovenized reference port....

Yes, the DSPLL is a little bit of a different animal from conventional  
VCXO PLLs perhaps?

The DSPLL is a commercially available chip from Silicon Labs (drop it  
on the PCB, terminate differential or single ended I/O, decouple /  
filter power, and program over SPI), similar to National Semiconductor  
analogue PLL chips (LMK04000 family) except that this Silicon Labs  
chip uses a DSP (and a virtualized digitally controlled oscillator  
implemented in the DSP in a standard virtual PLL loop) internal to its  
inner workings.

I can also get every frequency I desire out of this Silicon Labs part  
no matter what I put into it for frequency to synch to (house word  
clock in the kHz range or rubidium at 10MHz), and the National  
Semiconductor could not get some frequencies with discrete and  
standard frequency valued VCXOs (according to their simulator, perhaps  
their numerator / divisor registers do not have enough resolution and  
would be sometimes out of range)...  And some frequency outputs of the  
National part had some phase noise issues as I recall.

I had trouble finding a proper VCXO for the National part for the  
frequencies of interest and it was in the $50 range where the Silicon  
Labs chip is in the $30 range with no need for a VCXO (albeit an  
ovenized oscillator, but as shown below the ovenized will provide a  
rock solid internal reference when not synchronized to an external  
clock)...

The Silicon Labs also provides great jitter specs for the SONET crowd  
in the femtosecond region (caveat BW of measurement)...

With these DSP based PLLs and clock distribution I am probably going  
to be somewhere just below 1ps of jitter....


>> This 38.88MHz is a DSP clock, essentially a microprocessor clock
>> (albeit a very nice microprocessor clock) where the DSP simulates a
>> PLL operating on an incoming clock source, and makes an output clock
>> of a different frequency, but synchronized to be within AES standards
>
> Yeah, but the out clock is an integer multiple of the in clock, so you
> don't really need to jump through synthesizer hoops when a simple  
> divider
> in a PLL will do.
>

Indeed, however,  it is a full fractional type DSP PLL and is  
approximately 0.000 ppm for the desired output frequencies compared to  
input frequencies in the frequency plan (as I recall... I haven't run  
the Silicon Labs simulator for the DSP PLL in a couple of months)...
The DSP PLL also has dividers on the clock outputs for integer related  
clocks (e.g., 11 / 22 MHz and 12 / 24MHz used for the oversampled  
44.1kHz and 48kHz that add some jitter I think... not too bad though  
as I recall)....

> I looked at something similar to see if you could save cost by  
> avoiding
> the need to have different VCXO's for 44.1k based and 48k based  
> material,
> and it is difficult to find off the shelf devices that have suitably  
> low
> phase noise and no spurs in the phase noise. I think in the end it
> probably ends up being simpler to get the performance you are  
> looking for
> by just buying a good VCXO, or two if you need to handle 44.1k and 48k
> based material.
>

I now have the design down to 2 PLLs from 3 PLLs and am now  
distributing the 256 and 128 x oversampled clock frequencies of  
11.2896 MHz and 12,288 MHz after the disclosure of some low jitter ECL  
distribution chips by Bruce (thanks Bruce)...

I still have one performance issue to *maybe* figure out and that is  
the rise time from the DSP PLL chips is slow; maybe 1.2 to 1.4 V/ns  
(74AC is faster I think?)... Even though they are ECL, LVPECL, LVDS  
etc. based clock outputs, they could use some sharpening themselves to  
take advantage of the input to output jitter rise time requirements  
for the LVPECL clock distribution chips...  The jitter with the slow  
rise time input is still somewhat acceptable and the jitter budget  
probably is fine enough to not need the extra sharpening... maybe... I  
dunno if I want to get into it and possibly run the risk of having to  
respin the design if I can't get the sharpening circuit to work and  
run the risk of not being able to get bang for the buck to test as  
much as possible on the first spin...

I did find a paper using step recovery diodes to sharpen edges  
(coupled with some filtering) which seems to be in alignment with the  
limiting and filtering approach mentioned by Bruce...

I wonder if there are additional ICs or methods to get sharper edges  
these days...

>> The incoming clock source (master house clock) to this box / design
>> of interest is in another rack mount box external to this design on
>
> Have you considered making your box the clock master?  It is easier to
> make a low jitter clock which is not pullable, so making everything  
> else
> sync to the converter is one way to just avoid a big range of clock
> cleaning work.
>

This is a good idea... I have thought about copying and distributing  
the 38.88MHz external to the box as a master clock for other DSPLL  
based boxes, but unfortunately all the other equipment is made by  
other manufacturers that adhere to the house word clock being the  
sample rate (e.g., 44.1kHz, 48kHz, 96kHz, up to 192kHz) all on 75 ohm  
BNC and with jitter in the ps range (they all do their own cleaning  
and PLL reclocking up to 12 / 24MHz or 11 / 22MHz depending on the  
internal oversampling frequencies desired by their converters or  
DSPs).... Any equipment I make in the future can use the 38.88MHz, so  
that I don't need an OCXO in each box I make, but the other stuff is  
not available to this without external clock making and cleaning to  
get it to the 44.1kHz or equivalent... hence probably this in the rest  
of the world with standard mfg practices for house word clock only:  <http://www.antelopeaudio.com/en/products_iso_ocx.html 
 >


>> Sounds like maybe some LCs to filter out the additional harmonics and
>> maybe attempt to get close into the carrier eh?
>
> If you are trying to clean up close in phase noise by using LC  
> filters,
> that seems like the wrong way to get there.
>
> Why are you even using an ovenized oscillator to begin with if you  
> have to
> synchronize to another clock?  It's not like you care about aging if  
> you
> are locking to house sync, your output frequency is just going to be a
> multiple of what comes in.  A good quality VCXO should be a lot  
> cheaper
> than the $250 you quoted for the ovenized units you were looking at.
>

The ovenized can also be the internal clock if there are no external  
clocks to synch to in a standalone application or if this box is the  
master.  It would still provide sub ps jitter for the internal  
converters with the required bit accuracy in the jitter department as  
part of this experiment.

The reference port on the DSPLL can also be used as the system clock  
for internal or master clocking mode...

>> The 12kHz is a figure for the DSP PLL and how they measure it
>
> Because that device is optimized for high bit rate data transfer
> applications, where you usually have a high corner frequency on the  
> clock
> recovery PLL so that you track source drift and get rid of jitter  
> caused
> by ISI.  Basically the opposite of what you want for audio  
> applications.
> This is a baseband sampling application, so phase noise on the  
> sampling
> clock is converted to sidebands on the output of the D/A converter, or
> encoded as sidebands in the digital output of the A/D converter.   
> Because
> of masking in the auditory system, the sensitivity to sidebands  
> becomes
> lower the closer to the fundamental the sidebands are spaced, so you  
> want
> very low phase noise from a few hundred Hz up to 30kHz or so, below  
> a few
> hundred Hz you care less and less, and above 30kHz you care less  
> until it
> causes aliasing in your ADC, but fortunately the phase noise typically
> decreases at farther offsets from carrier, so that problem sort of  
> solves
> itself.
>

Ah.. I've been wondering about this... I have only had brief exposure  
to the data transfer application of SONET in the 1990s during college  
as an intern....  The good news is that the jitter transfer on the  
Silicon Labs DSPLL decreases from the 1:1 the closer into the carrier  
below 12 kHz....  This information is somewhere around page 140 if I  
recall in the family reference doc for the part, rather than the data  
sheet proper.


>> sheet with all the other datapoints comes out to 1.3ps  (1Hz to
>> 20MHz) of jitter RMS.
>
> Look at 300Hz to 30kHz, that is what you care about.  The 300Hz  
> figure is
> arguable, some say as high as 500Hz, some as low as 100Hz.  You can  
> aim
> for low phase noise down to 50 Hz if you want to really knock yourself
> out.  The current state of the art seems to be the Grimm Audio  
> equipment,
> which has a phase noise spec of about -125dBc at 100Hz, and an  
> integrated
> noise floor of 2ps above 10Hz.  Not super low compared to some
> communications equipment, and that gear is getting raves for audio
> quality.
> When in slave mode the corner frequency on the PLL is really low, I  
> think
> around 0.1Hz.  The claim is that incoming jitter is attenuated 90dB at
> 10Hz offset, and 60dB/decade above that.
> The design still pullable +/-50ppm when in slave mode (meets class 2
> requirements for AES11).  Can you get much lower phase noise than  
> that and
> still pull across a 100ppm range?  Phase noise and pull range are
> inversely related, but I haven't worked out what the theoretical  
> limits
> should be for that pull range (I think you should be able to  
> calculate a
> limit based on the Q required to give that much pull range).
>

hmmm... this is a good question... the DSPLL has a frequency offset  
alarm that could trigger the host micro to perhaps try a re-lock;  
perhaps OK for varispeed, and individual session flexibility, but  
probably not good for drift during a session (although I don't think  
drift in a session would be too bad unless massive temperature changes  
on cheap gear / clocks)... I don't know if the alarm is useful for  
these purposes or if it is intended for SONET stuff and margins  
only...  I haven't got this far yet in the design... I am ultimately  
looking to use a rubidium for the real long term system reference and  
generate house word clocks (or AES) output from the box to drive other  
gear, so hopefully this wont be an issue...

Of course, the DSPLL filter BW can be changed by some SPI commands,  
but there is an ICAL that probably needs to be done which can take up  
to 1.2 seconds to complete (data sheet specified max)....


>> I still want to filter such as to distribute a sine...
>
> I didn't understand this.  Usually you want a very fast edge rate so  
> that
> the clock input is not affected by noise.  There are times that you  
> want
> to keep a sine moving around because you don't want to introduce a  
> lot of
> power supply noise from logic output stages switching, but using a  
> logic
> output and then filtering it doesn't help there.  I assume when you  
> say
> distribute you mean inside the box, right?  So at some point you are  
> going
> to have to square up the signal again when you get to the converter  
> chips,
> which expect a logic clock, not a sine wave.  What is the point of
> distributing as a sine instead of just a square wave?
>

Yah, I was originally going with a $33/each 2 layer PCB and didn't  
want the sharp edges running everywhere long distance for turning the  
box into a radio station.  I have bit the bullet and am now looking at  
a 4 layer board... the question is to embed or not to embed the clock  
into the PCB, with sharp edges for EMI purposes; then we get into  
blind and buried vias perhaps... on the cost front: yikes....   And I  
wonder the signal integrity issues... luckily I just upgraded to  
Altium from Protel for my PCB design CAD system with the newer  
functionality for signal integrity analysis...  It's been 10 years  
since I have used SpecctraQuest and I wonder what the new Altium  
signal integrity looks like...

The DSPLL chips can take a sine on any of the input ports and square  
it up for you internally.... However, it would be ideal to pass some  
fast and sharp edges, say above 2 or 3 V/ns perhaps to keep  
distribution jitter low on LVPECL buffers / splitters....

Thanks for the sounding wall opportunity...

Cheers,
-chris