Re: Problem cascading 2 DCMs

On Apr 29, 6:15 pm, Gabor <g...@xxxxxxxxxxx> wrote:
On Apr 29, 7:56 am, MNiegl <Michael.Ni...@xxxxxxx> wrote:



Hi everyone,

A quick update (I haven't been through everything yet, after all it's
supposed to be a weekend...):
I checked all the FX60 erratas, there are no (known) ones concerning
the DCMs.
I tried the same design on an identical board, showed exactly the same
behaviour, so there really is something wrong with the design and not
with the chip.
I checked my VHDL code over and over again, couldn't find any errors,
but I will do the same in FPGA editor as well, just to be sure.

Furthermore I will try to reset the first DCM after config is done and
see if that helps matters. And then I think I will admit defeat and
try to source the 200 MHz externally. I also opened a WebCase, maybe
that gets me some more information.

Nevertheless, big thanks already to everybody who helped.

Cheers,
Michael

It's been a while since I looked into this (Virtex II series) so
I'm not sure about V4. However in the other DCM's there
was a "high frequency" mode that needed to be specified
for the DLL to work at higher frequencies. The HF mode
also disabled the CLK2X output. Could it be you need
to use HF mode after some frequency (higher than
160 but less than 200 MHz)?

Another thought. If you wait for the first DCM to lock
before releasing GSR, do you really reset the second
DCM? How do you initialize the SRL16 to ensure
you get a minimum reset length if the first DCM
is locked after config? Normally without an INIT
attribute the SRL would come up all zeroes after
config. If your reset signal is active high you'd
want to init the SRL to all ones.

HTH,
Gabor

Hi,

About the Init of the SRL16, I make sure it is initialized to x"ffff".
I also checked the frequency ranges once again, they are all within
the specs. But a couple of minutes ago I made a discovery when I
wanted to create a similar file using the Core Generator. There in the
GUI it would only let me select an input freq betw 32 and 75 MHz for
the first DCM, saying only low-frequency DLL mode is supported. But in
the V4 DC specs paper it says that this mode has a range of 32 to 150
MHz, where my 100 would fall right in. So apparently my mode is simply
not possible and the DCMs are simply not as good as they should be
according to Xilinx own specification.
I'm now trying to source the 200 MHz externally and then use a sole
DCM for the 90 deg phase shift as well as a division by 4. I hope that
at least that will work...

Thanks and Cheers,
Michael

.

Relevant Pages

  • DCM lock - require clarification
    ... I am using the VirtexII DCM in my design to generate the master clock ... The input freq is 20.48 MHz and the ...
    (comp.arch.fpga)
  • timing constraint - XPower 9.2 problem
    ... I implemented a design which uses DCM in Virtex-II Pro XC2VP30-7. ... I put the timing constraint for DCM to be 10 ns. ... generated .VCD file as an input simulation file for XPower. ...
    (comp.arch.fpga)
  • Re: DCM lock - require clarification
    ... I am using the VirtexII DCM in my design to generate the master clock ... AND'ed with the system reset and given as reset to all the modules in ...
    (comp.arch.fpga)
  • Re: Problema when upgrading from Xilinx 8.1 to Xilinx 8.2
    ... When I upgrade the design to 8.2, the ... BRAM_BLOCK, DCM, OPB_INTC. ... The only apparent changes on the design are the nominal upgrading os ...
    (comp.arch.fpga)
  • Re: Xilinx DCM
    ... Or are you using the internal reset on startup? ... If you are not resetting intentionally some time after configuration is complete and the input clock is stable, it may be that the input glitches right as the part is trying to lock. ... The only way the DCM will not lock is if the input clock is glitching while it is trying to lock. ... If the output is correct for a while, and LOCK does go high, and then the DFS fails, that is a different issue which is caused by excessive input jitter. ...
    (comp.arch.fpga)