There are a lot of FPGAs used in DSP applications where the clock to the
front end ADC is critical.  So I'd expect there would be some in-house
knowledge about this area.  It may be that all the help you will get is
"Don't do that."

I think Altera uses PLLs.

Xilinx uses DLLs, D for delay, a long chain of gates with an adjustable tap.
So the output signal will jump in time when the tap switches.

FPGAs are designed for digital logic rather than clock hacking.  I remember
some story from years ago about clocking troubles being traced back to input
threshold changes due to nearby outputs switching.  I forget the details.  I
think that particular problem was solved by moving all the output pins away
from the clock input pin.

The smaller FPGAs are not expensive.  It might make sense to dedicate a whole
chip to something like a clock mux.

You could always use an external PLL and put the digital dividers in a FPGA.

--
These are my opinions, not necessarily my employer's.  I hate spam.

FPGA's do not have good jitter performance.  Both Altera and Xilinx have
app notes and specs on what to expect for jitter performance.

Particularly when using high speed DACs (like the ADI AD9739) the
technique used is to drive the DAC with a good quality clock, then the
DAC drives the FPGA.  With high speed dac's like this there is often a
DLL used to optimize the data edges with respect to the clock.

Similar techniques are used in the other direction ADC ._ FPGA.  The
good clock is given to the DAC which presents the clock to the FPGA.

The clock out of an FPGA may be good enough depending on what you are
using it for but check carefully!

On Wed, 2011-02-02 at 10:47 -0800, Hal Murray wrote:

On 02/02/11 19:47, Hal Murray wrote:

You don't feed the ADC from the FPGA if you can avoid it.

That is oversimplifying the answer, Xilinx now have both. They have had
both for quite some time.

Xilinx have been using DLLs for logic clocking, but for MGTs and GTPs
they have used PLLs for ages as it is needed for low BER values. They
have also included it for logic clocking.

You can also avoid going through DLLs if you have the right clocks. Does
not always work. Most of the logic will work well. It's usually external
timing requirements which causes problems.

Trivial. Just avoid falling into the charge-pump tar-pit...

Cheers,
Magnus

On 2/4/2011 1:18 PM, Magnus Danielson wrote:

Curious what you mean by that?

On 04/02/11 22:50, Rex wrote:

If you have the combination of a charge-pump with a dead-band (such as
4046) and a too low comparator frequency... you can get fairly long
periods of quite followed by correction spikes. Not nice.

There are good charge-pumps and good uses of them. But I avoid them like
plague. There is usually simpler alternatives available.

Cheers,
Magnus

On 2/4/11 1:18 PM, Magnus Danielson wrote:

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.

On 05/02/11 04:33, jimlux wrote:

If you do it naively. You can do better, but it is not worth the time in
most cases.

FPGAs is a lovely sea of logic. The
MGT/GTP/whatever-high-speed-I/O-is-called-this-week has much better
timing. FPGAs are perfect for taking care of the data and processing.
Just do the timing sufficiently isolated from the FPGA. Once size
doesn't fit all. FPGAs is there to fit the need of relative high speed
and relative high integration of logic. It has taken more and more of
the full custom market, but will not take the full ASIC or full-custom
market.

Cheers,
Magnus

On 2/5/11 3:04 AM, Magnus Danielson wrote:

And where in-situ changes in the signal processing are needed (e.g. in a
software defined radio), the reprogrammable FPGA is a good fit.  But
there is a tradeoff.. you might want to give the downstream
users/programmers the ability to change sample rates, prompting the idea
of driving the data converter from the FPGA, without needing to add
external components to provide that function.

It has taken more and more of

On 05/02/11 12:13, jimlux wrote:

The FPGA can be a part of that solution, with DDSes, programmable
dividers etc, but the actual clock should preferably not go through the
FPGA before hitting ADCs and DACs.

Cheers,
Magnus

On 2/5/11 3:54 AM, Magnus Danielson 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.

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.

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 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.