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

Reply to
Andrew FPGA
Loading thread data ...

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

Reply to
JustJohn

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

Reply to
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

Reply to
Brian Davis

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

Reply to
Brian Davis

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

Reply to
Brian Davis

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
Reply to
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

Reply to
Brian Davis

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

Reply to
Falk Brunner

...

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

Reply to
Ralf Hildebrandt

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:

Reply to
Andrew FPGA

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

Reply to
Brian Davis

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.

Reply to
Andrew FPGA

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.

Reply to
Brian Davis

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:

Reply to
Andrew FPGA

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.