[time-nuts] Frequency multiplication

[Tijd Dingen]

> > Hopefully you mean this along the lines of: should you decide to feed two
> > different clocks into the Virtex-2, and use the dedicated global clocks, 
then
> > you guess the isolation between those 2 global clock lines to be on the 
order
> > of about 20-30 dB. So basically...

> No guessing.. I've measured it, albeit indirectly.  I feed a sine wave into 
the
> ADC being driven by one clock (from the FPGA) collect a bunch of samples, and 
>you
> can see the spurs from the clock jitter when you run a power spectrum.  The 
>spurs
> move as expected when you change either clock frequency.

Hey, that sounds like a fun & useful experiment to do! Not only to get an 
estimate
of the leakage between global clock lines, but also to see the influence of "hey 
what
if I turn this partical bit of functionality on/off". I think I'll try that 
later on.


> > Do NOT:
> > - feed crappy clock A into fpga
> > - feed precision clock B into fpga, let it go through the PLL, and route the
> >   resulting clock C outside the fpga again.
> > - use clock C as clock source for your precision DAC.

> > Do however:
> > - feed crappy clock A into fpga
> > - feed precision clock B into fpga, let it go through the PLL, and only use 
>it
> >   internally.
> > - use clock B as clock source  for your precision DAC.

> That would be the preferable approach, however, if you want to be able to 
>change
> the frequency of clock B (or turn it on and off) that gets tricky.

Controlling your external PLL/DDS/whatever from the fpga would be one 
approach...

> I note that clock A could be a mighty fine clock too.. it's the clock leakage.

Check.


> > Apart from that, with the push for higher and higher bitrates, even the 
>onboard
> > PLL's are now becoming "reasonable" for the less demanding applications. 
>However
> > I suspect that for the more demanding applications an external pll will 
still
> > remain the way to go for some time. For my DIY counter project I use a
> > spartan-6, which has a decent enough serdes (and the PLL that goes with 
>that),
> > but I won't let the fpga generate the higher clock rate. I'd rather do that 
>with
> > an external PLL. Maybe when the new 28 nm fpga's from xilinx/altera have 
good
> > availability in a year or two... Then again, ADI&  co won't sit still for 
>those
> > two years, so who knows. ;)

> In my particular world (space flight hardware), we tend not to use the latest
> and greatest components, so techniques that have been overtaken by events in
> the commercial world have a lot of value.

> We joke about getting questions in design reviews about why we're not using 
the
> tried and true and flight proven 12AX7 dual triode rather these new fangled
> transistor thingies.  After all, we've got the triodes in flight stores, ready
> for use.

:-)

Well, I can only imagine the levels of paranoia needed to shoot stuff into space
and actually have it reliably perform it's intended operation.

The analog to that in software country is along the lines of:

developer: "Hey, I have this new cool framework that I just put into the new 
build. :)"
me: "You want to put /what/ into production? Maybe we had better not do that."
developer: "*pout* Awwww, why not?"
me: "Do you want the list?"


> But really, we tend to run about 10 behind state of the art components (today 
>we're
> using Virtex IIs and AX2000s.... New designs are considering Virtex 4 and 5)

Well, look on the bright side! In about 12 years you'll get to work with these 
cool
28 nm parts too! ;->

regards,
Fred