Clock multiplication without using the Xilinx DCM's

Hi,
We are developing a product that passes data between an xDSL interface
and a proprietory optical interface. We are using a Spartan 3 FPGA. The
xDSL chipset generates an 8.192MHz clock that is recovered from the DSL
line. (The xDSL chipset uses a digital phase locked loop for this). The
current FPGA design uses this clock internally, and uses it to clock
the optical interface also. Single clock domain, nice.

However, there is now a requirement to clock the optical interface at a
higher rate. How to generate this clock? Xilinx DCM Frequncy
Synthesizer would seem to be the obvious choice. However the DCM jitter
tolerance requirements are the order of +-1ns period jitter and +-300ps
cycle-cycle jitter. I'm very worried the xDSL 8.192MHz clock will
exceed this jitter tolerance. The xDSL chipset doesn't specify any
jitter characteristics, and anyhow its likely dependent on the
characteristics of upstream DSL equipment. So I have ruled out this
path as too risky. The DCM jitter tolerance feels like quite a
limitation of the DCM so probably I'm not understanding how I can make
use of the DCM's in my application.

Does anyone have any hints of practicle FPGA techniques for generating
a higher clock? A doubling of the clock frequency would be enough. Just
the name of a technique would be enough to get me googling...

The xdsl chipset also has a local oscillator at 22MHz - but it just
free runs of course...I could invisage a plesiosynchronous scheme where
the optical link runs at 22MHz and I bit stuff to get the required data
rate. But it feels too complex, overkill. And then I have to think more
carefully about the optical link clock recovery at the far end.

(Keeping the number of clock domains to a minimum is of course a
desireable goal).

Regards
Andrew

Andrew FPGA wrote:
> Does anyone have any hints of practicle FPGA techniques for generating
> a higher clock? A doubling of the clock frequency would be enough. Just
> the name of a technique would be enough to get me googling...
>
> Regards
> Andrew

Look for Peter Alfke's tech note "Five easy pieces" or "Nine easy.." or
whatever, I think he has a simple clock doubler in there (generates a
short pulse for each edge of the source clock), or look through this
group some more. You'll find a bit of discussion on that circuit. If
you're worried about jitter on your generated clock though, it will be
at least as much as your input clock...

John

It's "six easy pieces" in TechXclusives, but:
That is just a differentiator of the two clock edges, with a bit of
smarts thrown in.
The output jitter is the input jitter plus anything due to duty cycle
difference from 50%.

There are of course external PLL circuits (I have used ICS, but there
are many suppliers).
That means an external part plus extra money...
Peter Alfke

Andrew wrote:
>
>Does anyone have any hints of practicle FPGA techniques for generating
>a higher clock? A doubling of the clock frequency would be enough. Just
>the name of a technique would be enough to get me googling...
>
 If the 8.192 clock were differential, and the duty cycle good,
you could feed it into one of the differential input buffers and use
the DIFF_OUT buffer feature to generate an internal complementary
8.192 MHz clock suitable for DDR I/O operation.

 You'd then forward the DDR clock and DDR data to the
optical interface, which would need to accept a half rate clock.

 If the clock source is single ended and fixed rate, a simple
RC +/- 45 degree phase shifter could probably get you a
differential version cheaply, or just use a single-gate
CMOS-in LVDS-out driver chip.

Brian

I wrote:
>
>  If the clock source is single ended and fixed rate, a simple
> RC +/- 45 degree phase shifter could probably get you a
> differential version cheaply, or just use a single-gate
>CMOS-in LVDS-out driver chip.

 Ooops, that'd make 90 instead of 180 degrees; I think
you can get there with a narrowband LC balun, but the
LVDS driver may be simpler.

Brian

 I wrote:
>
>  Ooops, that'd make 90 instead of 180 degrees; I think
> you can get there with a narrowband LC balun, but the
> LVDS driver may be simpler.

 As further evidence that I shouldn't type late at night, at
those data rates the local DDR IOB clock inversion would
work just fine for generating 16.384 Mbps DDR data.

   So if  you can tweak your optical interface to accept a
half rate clock with DDR data, you should be OK with your
present FPGA clocking setup.

Brian

Brian, if you start with sn 8 MHz signal with a duty cycle significntly
different from 50%, there is no way (in hell) to generate a low-jitter
16 MHz output, without using a DLL or PLL or other complicated timing
circuit. That's really basic.
Peter Alfke

Peter Alfke wrote:
> Brian, if you start with sn 8 MHz signal with a duty cycle significntly
> different from 50%, there is no way (in hell) to generate a low-jitter
> 16 MHz output, without using a DLL or PLL or other complicated timing
> circuit. That's really basic.

 Did you bother with the basic step of actually reading my
first post before composing that silly dig at me?

The very first line of my very first post on the thread said:
>
> If the 8.192 clock were differential, and the duty cycle good,
>

 Andrew didn't reference the exact spec sheet to determine
the output duty cycle, but his concern was not that the jitter
was too bad to generate the output data stream data, but
rather that it exceeded the input jitter specs of your DCM's.

 So I suggested using DDR I/O, with no DCM, to generate
a 2x output data stream- a perfectly valid notion if the
input duty cycle is OK at the slow 8.192 MHz clock rate.

Brian

  p.s. And as for your claim that "there's no way in hell", if the
fundamental is clean but just has poor duty cycle, a simple filter
and doubler would work fine to generate a 2x clock

Andrew FPGA schrieb:

> Does anyone have any hints of practicle FPGA techniques for generating
> a higher clock? A doubling of the clock frequency would be enough. Just
> the name of a technique would be enough to get me googling...

It depends on your output jitter requirements. Some time ago, I did a 
DPLL inside a Spartan 3, generation a 8192 kHz signal locked to a 8 kHz 
reference clock (we are telecom guys, are we ;-)
This DPLL was running at 131.072 MHz (4x 32.768 MHz). As you can easy 
see, this results in a jitter of about 0.12 UI.
If you generate twice the frequncy, you will get 0.24 UI jitter, pretty 
much right now.
This DPLL can be pushed up to 200MHz, with some tricks maybe to 300-400 
(effective clock rate using DDR stuff).

But the question is, is this really worth it? At 16 Mhz, even the good 
old 4046 will work and give you much less then 0.1 UI jitter. For a dollar.

Regards
Falk

Andrew FPGA wrote:
> Hi,
> We are developing a product that passes data between an xDSL interface
> and a proprietory optical interface. We are using a Spartan 3 FPGA. The
> xDSL chipset generates an 8.192MHz clock that is recovered from the DSL
> line. (The xDSL chipset uses a digital phase locked loop for this). The
> current FPGA design uses this clock internally, and uses it to clock
> the optical interface also. Single clock domain, nice.
...
> A doubling of the clock frequency would be enough. Just
> the name of a technique would be enough to get me googling...

If you don't need the doubled clock as an output, but want to operate at 
the doubled frequency, you could use both clock edges. A way to get 
fully synthesizable dual-edge behavior I've described in 
<http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf>. This 
idea is not limited to just flipflops. You may also extend it easily to 
dual-edge state machines.


> The xdsl chipset also has a local oscillator at 22MHz - but it just
> free runs of course...I could invisage a plesiosynchronous scheme where
> the optical link runs at 22MHz and I bit stuff to get the required data
> rate. But it feels too complex, overkill. And then I have to think more
> carefully about the optical link clock recovery at the far end.

Does this oscillator run fixed at 22MHz or is it it's maximum and it is 
modified by the PLL? If it is modified by the PLL, would it be an option 
to let the PLL generate the doubled clock, divide it by two, feed it 
back and synchronize this divided clock?


Ralf