DCM does not do anything?

I just generated a design with XPS, using edk 6.3i.
It had a DDR controller, and a bus speed 4x lower than the 100Mhz CPU.

The problem is, when I try to simulate this design, nothing happens,
since the second DCM in the chain does not generate ANY output signals.
I cannot find any cause of this. I didn't modify any of the settings, I
just generated and then went straigt to simulation in modelsim.

The chain is as follows:

DCM1 : clk divider, from 100 to 25 mhz
DCM2 : clk shifter, generates shifted signals <= DOES NOT WORK
DCM3 : DDR feedback shifter (uses external feedback loop)

Any thoughts on this one? I put the simulation resolution on 1PS etc.
All other systems simulate just fine.

Thanks

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

<zoinks@mytrashmail.com> wrote in message 
news:1124791832.379516.148920@g44g2000cwa.googlegroups.com...
>I just generated a design with XPS, using edk 6.3i.
> It had a DDR controller, and a bus speed 4x lower than the 100Mhz CPU.
>
> The problem is, when I try to simulate this design, nothing happens,
> since the second DCM in the chain does not generate ANY output signals.
> I cannot find any cause of this. I didn't modify any of the settings, I
> just generated and then went straigt to simulation in modelsim.
>
> The chain is as follows:
>
> DCM1 : clk divider, from 100 to 25 mhz
> DCM2 : clk shifter, generates shifted signals <= DOES NOT WORK
> DCM3 : DDR feedback shifter (uses external feedback loop)
>
> Any thoughts on this one? I put the simulation resolution on 1PS etc.
> All other systems simulate just fine.
>
> Thanks
> 

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
100, but the parameter CLKIN_PERIOD is set accordingly...

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


zoinks@mytrashmail.com wrote:
> 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
> 100, but the parameter CLKIN_PERIOD is set accordingly...
>
> I read there are bugs with some values of CLKIN_PERIOD, could this be
> one of them?

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!

zoinks@mytrashmail.com wrote:
> I just generated a design with XPS, using edk 6.3i.
> It had a DDR controller, and a bus speed 4x lower than the 100Mhz CPU.
> 
> The problem is, when I try to simulate this design, nothing happens,
> since the second DCM in the chain does not generate ANY output signals.
> I cannot find any cause of this. I didn't modify any of the settings, I
> just generated and then went straigt to simulation in modelsim.
> 
> The chain is as follows:
> 
> DCM1 : clk divider, from 100 to 25 mhz
> DCM2 : clk shifter, generates shifted signals <= DOES NOT WORK
> DCM3 : DDR feedback shifter (uses external feedback loop)
> 

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.

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