Clock multiplication without using the Xilinx DCM's

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

Andrew FPGA wrote:
> 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.

 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?

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

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

 Is the chipset datsheet available online?

Brian

 >Do you need to provide both clock and data, or just a
>data stream, to the TX optical interface?
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.

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

>>Is the jitter performance of the 8.192 MHz clock sufficient for
>>your system link budget at a 2x data rate?
Don't know is the short answer.

 >>Is the 8.192 Mhz clock close to 50% duty cycle?
I would have thought so, but it is not specified.

 >>Is the chipset datsheet available online?
No, we have it under NDA.

Andrew FPGA wrote:
>
> Its just a data stream(8b/10b coded). The clock is embedded in the data
> as it were.
>
 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.

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

>
> >>Is the jitter performance of the 8.192 MHz clock sufficient for
> >>your system link budget at a 2x data rate?
> Don't know is the short answer.
>
>  >>Is the 8.192 Mhz clock close to 50% duty cycle?
> I would have thought so, but it is not specified.
>
 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 )
   http://groups.google.com/group/comp.arch.fpga/msg/90e445167a1fb49a


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:

    http://www.wenzel.com/pdffiles/hcmos.pdf

   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.

>  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.
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:
> Andrew FPGA wrote:
> >
> > Its just a data stream(8b/10b coded). The clock is embedded in the data
> > as it were.
> >
>  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.
>
> >
> > 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...
> >
>  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.
>
> >
> > >>Is the jitter performance of the 8.192 MHz clock sufficient for
> > >>your system link budget at a 2x data rate?
> > Don't know is the short answer.
> >
> >  >>Is the 8.192 Mhz clock close to 50% duty cycle?
> > I would have thought so, but it is not specified.
> >
>  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 )
>    http://groups.google.com/group/comp.arch.fpga/msg/90e445167a1fb49a
>
>
> 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:
>
>     http://www.wenzel.com/pdffiles/hcmos.pdf
>
>    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.