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

Reply to
MNiegl
Loading thread data ...

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
Reply to
Nico Coesel

Reply to
Peter Alfke

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

Reply to
Austin Lesea

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

Reply to
MNiegl

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

Reply to
MNiegl

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.

Reply to
Alvin Andries

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

Reply to
MNiegl

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.

Reply to
Symon

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

Reply to
MNiegl

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

Reply to
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

Reply to
MNiegl

[snip]

Hi,

I had all kinds of problems (DCMs not locking was one of them) with MIG

1.6 and a Virtex4FX 100. I'd strongly advise you upgrade to MIG 1.7.

Rob

Reply to
Rob Dimond

Hi,

In the meantime I found a work-around using a FX20 as a "clock generator". I basically just moved the first of the 2 DCMs into the other FPGA and now feed an LVDS 200 MHz coming from a DCM into the bigger FPGA. Surprisingly, now the second one immediately locked. We'll see if the rest of the RAM controller does so as well. I still might try an update to MIG 1.7, I have just been a bit reluctant to do so as this would also mean migrating to ISE 9.1 and I don't want to switch software versions while working on a single project (which I'm doing since about 8 months now) if not absolutely necessary. This might be a point where it is absolutely necessary though.

Cheers, Michael

Reply to
MNiegl

Michael,

Did you turn offf autocalibration macro on the DCM? If not see this post:

formatting link

IIRC the autocalibration macro breaks around 200MHz... it is inserted automatically.

Regards, Erik.

--
Erik Widding
President
 Click to see the full signature
Reply to
Erik Widding

Any qualifications on this statement? "don't cascade DCMs, full stop"? Or "don't do it if you don't have to, at high clock frequencies"?

The reason I ask is that almost every design generated by the EDK Base System Builder tool cascade DCMs, in the same basic structure:

  1. input DCM to up/down sample board clock

  1. DCM to generate phases of DDR clock

  2. DCM to generate phase shifted DDR feedback clock

(2) is always cascaded directly from (1), with the lock -> reset lines hooked up directly (inverted).

Only time this has ever given me problems is in simulation, due to a hardcoded requirement in the simlibs DCM model for 3 input clock cycles before releasing DCM reset. Never had any problems on actual boards, up to about 125 MHz.

Regards,

John

Reply to
John Williams

John,

We generally try to discourage cascading, as the jitter only increases.

That said, we do expressly prohibit a cascade of the CLKFX output to the input of another DCM (not supported).

So, we do support the DLL outputs, to the next DCM input type of cascade.

In V5, with the PLL, we can now do whatever cascading you want, as long as there is a PLL between the DCMs (any output to PLL, PLL to input of next DCM).

Since customers have such a hard time characterizing their jitter, it is simpler to generally recommend against cascading.

It is also true that a single DCM can provide a great deal of functionality, and all of its outputs can be used (potentially).

Often a cascade DCM design can be done by two DCMs in parallel.

Like a PLL, the DCM only fails one way: it fails to lock, or loses lock. That said, the causes are those which I have already detailed: too much jitter, input frequency changing while trying to lock, frequency changing after lock, missing pulses.

Austin

Reply to
austin

Hi,

aside from that, I have some good news, as I finally got my cascade running. I inserted another counter after config done to hold the first DCM in reset for a bit longer period and this did the trick. So now I get exactly the frequencies I want to get without any problems. I still don't quite understand why it behaved so much different than in the last design, but oh well, at least it works ;-)

Many thanks to everyone who helped with ideas and suggestions!

Cheers, Michael

Reply to
MNiegl

How long did you have to wait? (clock cycles and frequency, or time)

What is being used in first DCM (phase shift takes longer to lock)?

Was this in V2, V2P, S3, S3E, V4 or V5?

If V4, is the "auto-cal" DCM enabled (the NBTI fix)?

Austin

Reply to
austin

Everything concerns a XCV4FX60 ES. Actually, I don't think that the first DCM needs longer to lock (I only use CLK2X, no phase shift), there just seem to be some kind of synchronization problems between setting the lock out and having an actually high-quality output clk when the DCM comes right out of the config phase. Therefore the first one gets his lock later on, while the second one gets released from the reset state too soon and can't achieve lock anymore. At least that's what it looks like to me. In the current system the auto-cal is disabled as I first wanted to see if that would influence things (it didn't). I will try it with the reset included and the auto-cal enabled and report back to you if it still works.

Cheers, Michael

Reply to
MNiegl

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.