Re: DCM question

On Wed, 08 Mar 2006 10:26:20 +0100, Zara <yozara@xxxxxxxx> wrote:

On 8 Mar 2006 00:32:52 -0800, "Marco" <marco@xxxxxxxxxxx> wrote:

for my project I'd like to use the same 25MHz clock signal (coming from
an external oscillator) for both the DSP and my Spartan3. A pll inside
the DSP creates the 600MHz clock from the 25MHz. I still don't know how
fast I'll let the FPGA work, so I was supposed to acquire the 25MHz
clock and through a DCM bring it to the level, i.e. 50MHz or 60Mhz,
that optimizes my design. In such a way I would have the same clock for
both my devices, syncronized and each with its proper frequency.
Can I do that or should I avoid this way of working?
Is it a common way to work?
Suggestions?

I don´t know the exact way the DSP creates the 600 MHz, but my best
suggestion would be to use the DCM to go up from 25MHz to 50 or 60 MHz
(whichever fits you best), and then output this signal to the DSP, so
that it derives its internal clock from the one generated by the FPGA.
You may even need to feedback the clock to the FPGA.

Thus way, you may have a better control of the phase between both
devices, and the inter-clock jitter will be limited to that coming
from the DSP, the other way you might get more jitter as both the
devices would put their own contribution.

Maybe there are better solutions, but you must first analyse the
synthesiser and DCM parameters, and how they will fit together.

It would be wise to check the jitter requirements for the DSP clock
input if doing it that way. Many clock inputs on processors (etc) are
designed with the assumption that the signal is coming straight from a
crystal oscillator.

A DCM will generate some hundreds of ps p-p of jitter. That is more
than enough to make some designs fail. Whether it matters for the
OP's problem can't be determined from the information presented.

Regards,
Allan
.

Relevant Pages

  • Re: DCM Jitter
    ... I've read that the DCM DLL function is actually very clean as far as phase ... A DCM does not reduce jitter under any circumstance ... As a delay line, the DCM does not have any oscillators. ... if you stop the input clock, you will need to re-lock the DCM ...
    (comp.arch.fpga)
  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... There has been information on the Xilinx tools that suggest that jitter ... The assumption here is that you have a low jitter clock presented to your ... I generated a verbose timing report, as you suggested, and every single path ...
    (comp.arch.fpga)
  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... There has been information on the Xilinx tools that suggest that jitter ... The assumption here is that you have a low jitter clock presented to your ... I generated a verbose timing report, as you suggested, and every single path ...
    (comp.arch.fpga)
  • Re: Virtex4 CLKX2 DCM Jitter
    ... here are some random thoughts on jitter troubleshooting. ... Try to distinguish whether the DCM input clock is ... affected when the I/O switches; ...
    (comp.arch.fpga)
  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... There has been information on the Xilinx tools that suggest that jitter from the DCMs - assuming the input jitter is clean to those devices - is included in the timing analysis. ... I'd suggest looking at the full timing report for a 200 MHz path and for a 50 MHz path. ... The assumption here is that you have a low jitter clock presented to your system for the DCMs to work from. ...
    (comp.arch.fpga)