DCM does not do anything?

are there any warnings about unmapped blocks in modelsim? I had it once where it failed to wire up one of the primitives because i'd not read the Xilinx doc properly. Ben

No, no errors whatsoever, except some warnings about X/U/W/Z's in arithmetic operands, but those are only the first few ns.

The only difference with other ocm systems I made is that this is the first time I use clock divider, so I'm running on 25Mhz, instead of

I read there are bugs with some values of CLKIN_PERIOD, could this be one of them?

Hi, Have you tried resetting the 2nd DCM while the 2nd DCM has a valid input clock? I'm not claiming that user logic resetting the DCM is mandatory, but trying this may give you some more information. (I had a simulation issue recently where i needed to reset the DCM to get it running again - I was mucking around with the DCM input clock though so its probably not surprising...)

If you are using modelsim you can use your testbench to "force" a reset on the DCM input. This means you don't have to modify the DUT design. See below.

library modelsim_lib; use modelsim_lib.util.all;

signal_force( "/toptb/dut/Reset", "1", force_type => freeze);

Obviously you will need to replace "/toptb...."

REgards Andrew

snipped-for-privacy@mytrashmail.com wrote:

I'll try that, thanks.

It's really annoying, it's the final simulation for my thesis and now I get these problems, with only a week to go :)

I can't believe it, but it actually works! yay!

Thank you all very much for your help!

Assuming that the clk shifter is getting clkin from the divider (which would be normal), then you should take the locked signal from the clock divider, invert it, and use that to reset the clk shifter. The result is that the clock shifter is held in reset until the divider has locked.

Although I have used the DCMs on Spartan-3, I haven't had any experience of cascading them yet. However, I do remember that when cascading CLKDLL primitives in Spartan-2, it was recommended to delay the release from reset of a subsequent DLL until some clock cycles after the preceding one had locked, perhaps feeding the /LOCKED signal through an SRL16.

While I'm pretty sure that this was a workaround for an errata in the Spartan-II and should not necessarily be required here, it is worth bearing in mind if you have any difficulties (and one or two spare LUTs!)

Richard.

The cascading used in my design was generated by XPS, so I guess it wasn't supposed to happen :)

It's still a weird bug, imho.

The cascading used in my design was generated by XPS, so I guess it wasn't supposed to happen :)

It's still a weird bug, imho.