Clock multiplication without using the Xilinx DCM's

Mar 27, 2006 14 Replies

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



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

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

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

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

Did you bother with the basic step of actually read>

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:

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

...

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 . This idea is not limited to just flipflops. You may also extend it easily to dual-edge state machines.

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

Thanks to all those providing these ideas. It occurs to me that I only need the optical bitstream to run at 2x rate - I don't need the whole FPGA design to run at the doubled rate. So any of these "clever/tricky" schemes could be isolated to just a small part of the design which makes them more palletable.

I already need to implement a DPLL at the far end of the optical link so it may not require much more design time to use this technique also(although it will use up more FPGA logic resources than the other techniques).

To answer Ralphs questions: The 22M clock is the xDSL chipsets local clock generated from a crystal so its fixed. The 8M clock generated by the xDSL PLL is its max. The PLL can generate nx64kHz but 8.192M is the upper limit.

Thansks again. Regards Andrew

Ralf Hildebrandt wrote:

Do you need to provide both clock and data, or just a data stream, to the TX optical interface?

If you need to provide the clock, can that portion of the optical interface be modified to accept an 8.192 MHz clock with 16.384 Mbps DDR data?

Is the jitter performance of the 8.192 MHz clock sufficient for your system link budget at a 2x data rate?

Is the 8.192 Mhz clock close to 50% duty cycle?

Is the chipset datsheet available online?

Brian

Its just a data stream(8b/10b coded). The clock is embedded in the data as it were. Hence the need for a DPLL at the far end to recover the clock.

I think I finally get the DDR idea. You are saying clock the DDR IOB with 8M, and the IOB will clock data out on +ve and -ve clock edges because its a DDR IOB. Which effectively has doubled the data rate. Without going too deeply into it, yes I think this could work. Quite like it actually...

Don't know is the short answer.

OK; so if the 8.192 MHz input clock has decent duty cycle and jitter, then using the DDR I/O should work for you since you don't need to actually create an external 2x clock.

Right, the Spartan-3's have the dual edge I/O, like Ralf described, already built in to the IOBs.

If you're unfamiliar with those I/O features, I've included some pointers to documentation and examples below.

OK; if the link already works for you at 8.192 MHz, that's a start; I'd ask the manufacturer for more info, and measure it yourself.

Brian

Spartan3 Dual Data Rate I/O information:

- Spartan3 datasheet, Section 2: Functional Description DS099-2 (v1.4) pages 2-4, Double-Data-Rate Transmission

- local clock DDR inversion XAPP462 (v1.1) figure 28

- Libraries Guide, DDR output components OFDDRCPE, OFDDRRSE, OFDDRTCPE, OFDDRTRSE

- DDR serializer app. note example XAPP514 (v2.0) figure 2-6, page 40

- DDR clock forwarding example using DIFF_OUT clock buffer (which would be overkill at 8.192 MHz )

formatting link

Additional Cheap Clock Multiplier Suggestions:

If you do eventually need to create an external multiplied clock, besides the PLL and frequency doubler suggestions already made, at these clock rates you can also build simple x5 harmonic multipliers out of CMOS gates and a few discretes, see:

formatting link

A divide-by-two times five would get you to 20.48 MHz, with no worries about input duty cycle. Make sure you treat the gates in such a harmonic multiplier as precision analog parts, using good bypass and layout practices.

PCB is being routed as we speak so can't measure it right now. But, even if I could measure it, and even if I got some jitter transfer function info from the manufacturer, I expect the 8M jitter will still be pretty dependent on the upstream DSL equipment, HDSL link quality etc....

At the end of the day, the xDSL signal can't be jittered so badly that the xDSL framer can't sync up and recover data....

Brian Davis wrote:

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required