Problem cascading 2 DCMs

Hi everyone,

I have a problem that is bugging me for 2 days now and I was hoping
someone here might be able to help me out.
The problem is as follows:
I want to implement a DDR2 RAM Controller in a Xilinx Virtex 4 FX FPGA
on the Xilinx ML410 eval board. It's supposed to run at 200 MHz, which
I want to derive from the on-board 100 MHz oscillator. For this I need
to use 2 DCMs cascaded (1 to get to 200 MHz, and the second one for
all the other frequencies the RAM controller [generated with MIG 1.6]
needs (main problem is the 200 MHz shifted by 90 deg). The first one
works perfectly fine, only the second one never locks. Even in a
module with just the 2 DCMs and Clock Buffers it fails to work. All
the clocks fall well within the ranges of the modes I use and
everything is connected as recommended by Xilinx. I use the CLK2X
output of the first one to specifically avoid excessive jitter, I
delay the config done flag until the first one has locked, I use the
inverted lock output of the first one to reset the second one with a
shift register in between. I already tried to manually place the DCMs
at specific locations and impose timing constraints on the signal in
between.
The interesting thing is that the CLKFX output seems to work fine, I
checked that on a scope, only the others fail to work. And even more
interesting, 1 week ago I implemented a DDR RAM Controller in which I
used exactly the same structure except that it was running at 160 MHz
and I didn't have any problems at all. If I try to do same now, it
still doesn't work!!
So after about 20 hours of trying I just ran out of ideas. Maybe
someone of you has another idea.

Cheers,
Michael

MNiegl <Michael.Niegl@cern.ch> wrote:

>Hi everyone,
>
>I have a problem that is bugging me for 2 days now and I was hoping
>someone here might be able to help me out.
>The problem is as follows:
>I want to implement a DDR2 RAM Controller in a Xilinx Virtex 4 FX FPGA
>on the Xilinx ML410 eval board. It's supposed to run at 200 MHz, which
>I want to derive from the on-board 100 MHz oscillator. For this I need
>to use 2 DCMs cascaded (1 to get to 200 MHz, and the second one for
>all the other frequencies the RAM controller [generated with MIG 1.6]
>needs (main problem is the 200 MHz shifted by 90 deg). The first one
>works perfectly fine, only the second one never locks. Even in a
>module with just the 2 DCMs and Clock Buffers it fails to work. All
>the clocks fall well within the ranges of the modes I use and
>everything is connected as recommended by Xilinx. I use the CLK2X
>output of the first one to specifically avoid excessive jitter, I
>delay the config done flag until the first one has locked, I use the
>inverted lock output of the first one to reset the second one with a
>shift register in between. I already tried to manually place the DCMs
>at specific locations and impose timing constraints on the signal in
>between.
>The interesting thing is that the CLKFX output seems to work fine, I
>checked that on a scope, only the others fail to work. And even more
>interesting, 1 week ago I implemented a DDR RAM Controller in which I
>used exactly the same structure except that it was running at 160 MHz
>and I didn't have any problems at all. If I try to do same now, it
>still doesn't work!!
>So after about 20 hours of trying I just ran out of ideas. Maybe
>someone of you has another idea.

Check the device's errata sheets to see if there is something wrong
with the DCMs in certain batches.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Do not cascade the DCMs. Drive both in parallel from the 100 MHz
oscillator.
Peter Alfke

On Apr 27, 11:07 am, MNiegl <Michael.Ni...@cern.ch> wrote:
> Hi everyone,
>
> I have a problem that is bugging me for 2 days now and I was hoping
> someone here might be able to help me out.
> The problem is as follows:
> I want to implement a DDR2 RAM Controller in a Xilinx Virtex 4 FX FPGA
> on the Xilinx ML410 eval board. It's supposed to run at 200 MHz, which
> I want to derive from the on-board 100 MHz oscillator. For this I need
> to use 2 DCMs cascaded (1 to get to 200 MHz, and the second one for
> all the other frequencies the RAM controller [generated with MIG 1.6]
> needs (main problem is the 200 MHz shifted by 90 deg). The first one
> works perfectly fine, only the second one never locks. Even in a
> module with just the 2 DCMs and Clock Buffers it fails to work. All
> the clocks fall well within the ranges of the modes I use and
> everything is connected as recommended by Xilinx. I use the CLK2X
> output of the first one to specifically avoid excessive jitter, I
> delay the config done flag until the first one has locked, I use the
> inverted lock output of the first one to reset the second one with a
> shift register in between. I already tried to manually place the DCMs
> at specific locations and impose timing constraints on the signal in
> between.
> The interesting thing is that the CLKFX output seems to work fine, I
> checked that on a scope, only the others fail to work. And even more
> interesting, 1 week ago I implemented a DDR RAM Controller in which I
> used exactly the same structure except that it was running at 160 MHz
> and I didn't have any problems at all. If I try to do same now, it
> still doesn't work!!
> So after about 20 hours of trying I just ran out of ideas. Maybe
> someone of you has another idea.
>
> Cheers,
> Michael

MNiegl,

Well, it seems that if you are doing everything right, and it worked
last time at 160 MHz, it has no excuse but to work this time.

When I am faced with these kinds of problems, I go back and check
absolutely everything:  it is likely the mistake is right there in front
of you, and you are not seeing it.

Have you looked at the DCM in FPGA Editor?  Sometimes you immediately
see that the code you wrote is doing exactly what it is supposed to (and
not what you want).

Peter is fond of saying, "when your car dies on the road, do you first
check to see if the spark plug gap is correct?  No, you check the most
likely cause - are you out of gas..."

Austin

> Hi everyone,
> 
> I have a problem that is bugging me for 2 days now and I was hoping
> someone here might be able to help me out.
> The problem is as follows:
> I want to implement a DDR2 RAM Controller in a Xilinx Virtex 4 FX FPGA
> on the Xilinx ML410 eval board. It's supposed to run at 200 MHz, which
> I want to derive from the on-board 100 MHz oscillator. For this I need
> to use 2 DCMs cascaded (1 to get to 200 MHz, and the second one for
> all the other frequencies the RAM controller [generated with MIG 1.6]
> needs (main problem is the 200 MHz shifted by 90 deg). The first one
> works perfectly fine, only the second one never locks. Even in a
> module with just the 2 DCMs and Clock Buffers it fails to work. All
> the clocks fall well within the ranges of the modes I use and
> everything is connected as recommended by Xilinx. I use the CLK2X
> output of the first one to specifically avoid excessive jitter, I
> delay the config done flag until the first one has locked, I use the
> inverted lock output of the first one to reset the second one with a
> shift register in between. I already tried to manually place the DCMs
> at specific locations and impose timing constraints on the signal in
> between.
> The interesting thing is that the CLKFX output seems to work fine, I
> checked that on a scope, only the others fail to work. And even more
> interesting, 1 week ago I implemented a DDR RAM Controller in which I
> used exactly the same structure except that it was running at 160 MHz
> and I didn't have any problems at all. If I try to do same now, it
> still doesn't work!!
> So after about 20 hours of trying I just ran out of ideas. Maybe
> someone of you has another idea.
> 
> Cheers,
> Michael
> 

On Apr 27, 8:18 pm, n...@puntnl.niks (Nico Coesel) wrote:
> MNiegl <Michael.Ni...@cern.ch> wrote:
> >Hi everyone,
>
> >I have a problem that is bugging me for 2 days now and I was hoping
> >someone here might be able to help me out.
> >The problem is as follows:
> >I want to implement a DDR2 RAM Controller in a Xilinx Virtex 4 FX FPGA
> >on the Xilinx ML410 eval board. It's supposed to run at 200 MHz, which
> >I want to derive from the on-board 100 MHz oscillator. For this I need
> >to use 2 DCMs cascaded (1 to get to 200 MHz, and the second one for
> >all the other frequencies the RAM controller [generated with MIG 1.6]
> >needs (main problem is the 200 MHz shifted by 90 deg). The first one
> >works perfectly fine, only the second one never locks. Even in a
> >module with just the 2 DCMs and Clock Buffers it fails to work. All
> >the clocks fall well within the ranges of the modes I use and
> >everything is connected as recommended by Xilinx. I use the CLK2X
> >output of the first one to specifically avoid excessive jitter, I
> >delay the config done flag until the first one has locked, I use the
> >inverted lock output of the first one to reset the second one with a
> >shift register in between. I already tried to manually place the DCMs
> >at specific locations and impose timing constraints on the signal in
> >between.
> >The interesting thing is that the CLKFX output seems to work fine, I
> >checked that on a scope, only the others fail to work. And even more
> >interesting, 1 week ago I implemented a DDR RAM Controller in which I
> >used exactly the same structure except that it was running at 160 MHz
> >and I didn't have any problems at all. If I try to do same now, it
> >still doesn't work!!
> >So after about 20 hours of trying I just ran out of ideas. Maybe
> >someone of you has another idea.
>
> Check the device's errata sheets to see if there is something wrong
> with the DCMs in certain batches.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U opwww.adresboekje.nl

Thanks for the quick suggestions. First of all Peter, I would love to
use them in parallel I just don't know how I can get a 90-deg phase-
shifted 200 MHz clk without a lot of other twiddling. The DCMs provide
that output only for the CLK0 and that is in parallel only 100 MHz.
Other than that, I will check the erratas, thanks for that

Cheers,
Michael

On Apr 27, 8:22 pm, Austin Lesea <aus...@xilinx.com> wrote:
> MNiegl,
>
> Well, it seems that if you are doing everything right, and it worked
> last time at 160 MHz, it has no excuse but to work this time.
>
> When I am faced with these kinds of problems, I go back and check
> absolutely everything:  it is likely the mistake is right there in front
> of you, and you are not seeing it.
>
> Have you looked at the DCM in FPGA Editor?  Sometimes you immediately
> see that the code you wrote is doing exactly what it is supposed to (and
> not what you want).
>
> Peter is fond of saying, "when your car dies on the road, do you first
> check to see if the spark plug gap is correct?  No, you check the most
> likely cause - are you out of gas..."
>
> Austin
>
> > Hi everyone,

Hi Austin,

Actually, at the moment I'm heavily banking on my own stupidity and
hope that it's only one small mistake I just can't find.
Until now I only checked the DCM locations in FPGA Editor, I'll look
at that some more intensively.
And I love that quote from Peter, it's so true but sometimes so hard
to obey.

Cheers,
Michael

"MNiegl" <Michael.Niegl@cern.ch> wrote in message
news:1177698983.194188.262100@o40g2000prh.googlegroups.com...
> On Apr 27, 8:22 pm, Austin Lesea <aus...@xilinx.com> wrote:
> > MNiegl,
> >
> > Well, it seems that if you are doing everything right, and it worked
> > last time at 160 MHz, it has no excuse but to work this time.
> >
> > When I am faced with these kinds of problems, I go back and check
> > absolutely everything:  it is likely the mistake is right there in front
> > of you, and you are not seeing it.
> >
> > Have you looked at the DCM in FPGA Editor?  Sometimes you immediately
> > see that the code you wrote is doing exactly what it is supposed to (and
> > not what you want).
> >
> > Peter is fond of saying, "when your car dies on the road, do you first
> > check to see if the spark plug gap is correct?  No, you check the most
> > likely cause - are you out of gas..."
> >
> > Austin
> >
> > > Hi everyone,
>
> Hi Austin,
>
> Actually, at the moment I'm heavily banking on my own stupidity and
> hope that it's only one small mistake I just can't find.
> Until now I only checked the DCM locations in FPGA Editor, I'll look
> at that some more intensively.
> And I love that quote from Peter, it's so true but sometimes so hard
> to obey.
>
> Cheers,
> Michael

Michael,

Do you reset the second DCM after the first one has locked (a disturbed DCM
doesn't get to it's senses without some help)?
I agree that 2 DCMs in parallel would be better in this case, you only have
to calculate the phase offset for the second one.

Alvin.

On Apr 28, 1:01 am, "Alvin Andries"
<Alvin_Andries.no_s...@no.spam.versateladsl.be> wrote:
> "MNiegl" <Michael.Ni...@cern.ch> wrote in message
>
> news:1177698983.194188.262100@o40g2000prh.googlegroups.com...
>
>
>
> > On Apr 27, 8:22 pm, Austin Lesea <aus...@xilinx.com> wrote:
> > > MNiegl,
>
> > > Well, it seems that if you are doing everything right, and it worked
> > > last time at 160 MHz, it has no excuse but to work this time.
>
> > > When I am faced with these kinds of problems, I go back and check
> > > absolutely everything:  it is likely the mistake is right there in front
> > > of you, and you are not seeing it.
>
> > > Have you looked at the DCM in FPGA Editor?  Sometimes you immediately
> > > see that the code you wrote is doing exactly what it is supposed to (and
> > > not what you want).
>
> > > Peter is fond of saying, "when your car dies on the road, do you first
> > > check to see if the spark plug gap is correct?  No, you check the most
> > > likely cause - are you out of gas..."
>
> > > Austin
>
> > > > Hi everyone,
>
> > Hi Austin,
>
> > Actually, at the moment I'm heavily banking on my own stupidity and
> > hope that it's only one small mistake I just can't find.
> > Until now I only checked the DCM locations in FPGA Editor, I'll look
> > at that some more intensively.
> > And I love that quote from Peter, it's so true but sometimes so hard
> > to obey.
>
> > Cheers,
> > Michael
>
> Michael,
>
> Do you reset the second DCM after the first one has locked (a disturbed DCM
> doesn't get to it's senses without some help)?
> I agree that 2 DCMs in parallel would be better in this case, you only have
> to calculate the phase offset for the second one.
>
> Alvin.

Yes, I use the inverted Lock output of the first one to reset the
second one. I even inserted a SRL16 in between as suggested by Xilinx
in an Answer Record to have a bit of a delay in there.
About the parallel implementation, I'd be more than happy to use it if
anyone has an idea for an easy implementation of a stable 90 degree
phase shift.

Cheers,
Michael

"MNiegl" <Michael.Niegl@cern.ch> wrote in message 
news:1177697266.037429.124990@n35g2000prd.googlegroups.com...
> Hi everyone,
>
> I have a problem that is bugging me for 2 days now and I was hoping
> someone here might be able to help me out.
> The problem is as follows:
> still doesn't work!!
> So after about 20 hours of trying I just ran out of ideas. Maybe
> someone of you has another idea.
>
> Cheers,
> Michael
>
Hi Michael,
Can you reset the first DCM once everything has settled down after config? 
It might not be locking 'properly' at the first power on.
Cheers, Syms.
p.s. Peter's saying reminds me of No. 19. in the "You are wrong because" 
series.
Reaching Bizarre Conclusions Without Any Information:
Example: The car won't start. I'm certain the spark plugs have been stolen 
by rogue clowns. 

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