Re: [time-nuts] Frequency multiplication
On 05/02/11 15:20, jimlux wrote:
I agree, but if you want the clock rate to be changeable/selectable,
driven arbitrarily by logic in the FPGA, you're kind of stuck.
There is always corner-cases. I quite intently left room for that as
well. The general recommendation is still to avoid it unless you can
show that there isn't a problem.
A typical scenario (which could be fixed by minimal external circuitry)
is turning the clock entirely off to save power in the DAC/ADC. Or where
you want to run the converters at a lower rate to save power when
processing a narrower band signal.
A single gate outside would solve these problems. Let the FPGA hold
state, and let minimal external HW handle the timing critical stuff.
For some applications you need to compromise, but if you don't need to
compromise there is no engineering challenge to be handled.
In the software radio area, we usually have at least two clocks in the
system.. a CPU clock running at something like 66 or 75MHz (or something
convenient) and a reference oscillator (used for generating the local
oscillators, etc., as well as the sampling clocks) at 50-100 MHz,
although the sampling might be divided down some from that. The CPU
clock is generally of lower quality (e.g. not a TCXO, not necessarily
good phase noise) and the reference oscillator is usually fairly good
(TCXO or OCXO, good phase noise since it's being multiplied up to
microwave frequencies, etc.)
A low parts count approach to meeting the overall need might be to have
a very small "clock FPGA" that is clocked ONLY by the external clock and
generates the needed DAC and ADC clocks, with whatever dividing, etc. At
least then, you don't have to deal with isolation from the CPU bus clock.
That is one solution.
That would be an alternative to adding a lot of external clock mux
logic, with dividers and such. You might even be able to use a suitable
onetime programmable FPGA in a small package to implement a "generic
clock source" with enough sophistication, but still with minimal
degradation.
For several designs you seem to be able to feed the clock separately
from the clock source to the ADC/DAC and the FPGA and get the length
matching work out. As soon as the data goes up on the chip it can be
reclocked to whatever suitable for further processing.
Cheers,
Magnus
You don't feed the ADC from the FPGA if you can avoid it.
especially if your ADC clock is a different frequency from the processor
clock that's being used for most of the other logic on the FPGA. I'd
give a ballpark estimate of 20-30 dB isolation between the two on a
Virtex 2.
I read and reread that part...
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...
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.
... if not I am probably missing something.
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. ;)
regards,
Fred
On 2/5/11 10:20 PM, Tijd Dingen wrote:
You don't feed the ADC from the FPGA if you can avoid it.
especially if your ADC clock is a different frequency from the processor
clock that's being used for most of the other logic on the FPGA. I'd
give a ballpark estimate of 20-30 dB isolation between the two on a
Virtex 2.
I read and reread that part...
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.
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.
I note that clock A could be a mighty fine clock too.. it's the clock
leakage.
... if not I am probably missing something.
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. ;)
yes..
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.
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)
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