Simple questions on IDELAYCTRL

As long as you run all the idelays on the same 200 MHz reference clock, and that reference clock runs continuously, you shouldn't need to separately reference the idelayctrl's, which means you can just put one at the top level of your design and run the idly_rdy to all instances of your idelays. If there is only one idelayctrl instantiated in your design, then the PAR tools automatically replicate it and you don't need to put any RLOCs on it. I believe the replication replicates it into all sites, and then map later trims out any that are in regions where there are no idelays used and the rdy pin is not used. If the rdy pin is used, the software instantiates an AND gate to combine all the RDY's into one signal, so if RDY is used, all the idelaysctrls remain in the circuit. This will lead to higher power consumption, but otherwise doesn't adversely affect the design. Xilinx does recommend using LOCs and explicitly placing these, but like you, I found that highly inconvenient. The only place I think you can get the locations is off FPGA editor, and those change depending on the particular device. Unless you are either a) concerned about every bit of power consumption, b) using the rdy's differently for different banks and can't live with waiting till all the idelayctrls come on line, or c) are doing something where you have different reference clocks (why would you do this?) or different resets for the idelayctrls, then I think the added power consumption and the big and gate are a very small price to pay for the simplicity of the un LOC'd instancing.

Try Jim Wu's free ADEPT-Tool:

There's a view where you can see the IDELAYCTRL-locations and the pins that are controlled by this specific IDELAYCTRL. This tools is really handy for other stuff as well (like seeing which IOs belong to which IO-Clock-Region and regional clock and things like that), and doesn't cost anything.

cu, Sean

ADEPT-Tool:

This is what I plan to do. I agree, it appears to trim out the unused ones anyway. Xilinx had a lot of notes about using the LOC, so it seemed like this was important, but maybe it's not so much an issue now.

So, I have a little prototype card I am using to evaluate the IDELAY. We placed an XC4VSX35FF668-12 on it. I have two clocks that I can drive the FPGA with. One is a 50MHZ CMOS type, the other an SMA that drives a LVPECL driver that goes to the FPGA. I see no problems using the IDELAY when I use the RF generator for the clock source. In this case I am running the input clock at 200MHz. However when I use the 50MHz clock and multiply it up to 200MHz with a DCM, the IDELAY does some strange things. I have a MICTOR on the board that I can use to look at some of the signals. Looking at the CLKFX output from the DCM, it appears normal and is running at 200MHz. I see both the DCM and IDELAYCRTL readys. What is strange is that when I program in a delayline, rather than seeing 75ps of delay, I see about 200ps per tap. I read Austin's note on using the DCM as a source and it seems like it should work. Another strange problem I am seeing is that certain pin that have the same number of taps selected give a different delay. Again, everything works fine when I drive the IDELAYCRTL without using the DCM.

I am at a loss.

MHz reference clock,

I tried the same tests setting the DCM to D=1 M=4, D=2 M=8 and setting the CLKIN_DIVIDE_BY_2 to TRUE then using D=1 and M=8. All seem to cause problems with the IDELAYCTRL.

I then took the RF generator (via the PECL driver) and used it to drive the DCM.

Running the RF generator at 200MHz and using the CLK0 to drive the IDELAYCTRL appears to work fine (delay per tap seems correct).

Running the RF generator at 50MHz and driving the DCM but using D=1 M=4 and the CLKFX out does not seem to work.

Running the RF generator at 100 MHz then using a D=1 M=2, CLKFX out appears to work.

Running the RF generator at 200 MHz then using a D=2 M=2, CLKFX out appears to work.

Austin had published a note about using a 66MHz clock with the DCM set to D=1 M=3 and having it work.

"The Ref Clock may be supplied from any +/- 10% 200 MHz source, including the DCM CLKFX output. For example, if there is a 66 MHz clock, a M=3, D=1 will provide you with a ~ 200 MHz output on CLKFX. There is no need to be concerned with the jitter from the CLKFX, as the analog locked loop which controls the delay is effectively a PLL which filters out the high frequency jitter components (jitter on Refclk is attenuated when transfered to the data lines)."

I tried this same test and it appears not to work (I see that same

It seems to be related to how many multiplier stages used in the DCM.

Has anyone else seen this?

Has anyone else seen the problem that snipped-for-privacy@chek.com talks about when using a DCM to multiply an input clock to create the 200MHz input clock to the IDELAYCTRL block?

My current design is planning to use a DCM to convert a 14.318MHz clock to a 200.4 MHz for the IDELAYCTRL clock. I don't want to fight problems with this if it is doomed to failure.

Any suggestions on DCM + IDELAYCTRL ?

Thanks!

John Providenza

snipped-for-privacy@chek.com wrote:

"johnp" schrieb im Newsbeitrag news: snipped-for-privacy@l12g2000cwl.googlegroups.com...

hm I am testing with 2 different DDR2 designs, using either 100 or 50 mhz input clock

the 200mhz for idelayctrl is derived from second DCM first dcm FX is used to get internal 200mhz

both designs seem to work somewhat, there are some problems but those are more likely fpga timing or board layout related.

in any case fx=200 from 50mhz input does work, eg memory tests on the DDR2 memory do pass all.

Antti

"I see no problems using the IDELAY when I use the RF generator for the clock source. In this case I am running the input clock at 200MHz. However when I use the 50MHz clock and multiply it up to 200MHz with a DCM, the IDELAY does some strange things. I have a MICTOR on the board that I can use to look at some of the signals. Looking at the CLKFX output from the DCM, it appears normal and is running at 200MHz. I see both the DCM and IDELAYCRTL readys. What is strange is that when I program in a delayline, rather than seeing 75ps of delay, I see about 200ps per tap."

Maybe Austin or Peter from Xilinx can comment on this?

John Providenza

Antti Lukats wrote:

John,

When we characterized the DCM DFS output for the IDELAY, we did not see any ill effects: the jitter from the CLKFX hardly affected the IDELAY at all, and as long as the frequency was close to 200 MHz (+/- 10 MHz) everything was just fine.

So, I am unsure why things are behaving the way they are reported.

Do you have a case open? Do you have a case number?

Austin

johnp wrote:

Austin -

I have not yet seen a problem , I'm just concerned that Lecroy7200 says he saw problems trying this type of DCM+IDELAYCTRL configuration.

I don't want to waste time on a known problem if it *really* exists.

John P

Aust> John,

John,

OK, I hear you. I have no idea what he was complaining about, that is why I did not post anything. I have heard at various times things about the software concerning IDELAY (wrong bits set, etc. back with 7.1i) but that is all fixed by subsequent service packs, and is easy to find on the web page by searching for IDELAY.

There are lots of answers, that give tips on usage, how many clocks to wait, simulation of the IDELAY, etc.

Austin

I had tried to call Xilinx during the time this was going on but it appears they were closed or something as I could only get their answering machine. I wasn't seeing any posts here and needed to get on with things.

I gave up on using this many stages and just added a 100MHz oscillator to the board and used only one DCM to get to 200. I added a 200Mhz oscillator to the final design to get around the problem. I ran the test board with the 100MHz oscillator for a few weeks and saw no problems with the idelay after makeing this change.

If there is a test you would like me to run or have any questions about the tests I ran, feel free to ask. It's not a cost sensitive design and I have room to add an oscillator just for the idelay so it's not a big problem for us. My only fear now is if it would act up at random.

Well,

Sorry about that, but the snowstorm in Colorado caused us to send those folks home before they were stranded. San Jose and Singapore took on the extra call volume, which may be why you could not get through.

When my lab tested the DCM CLKFX output to the IDELAY ref clock, we tested a number of M and D values, but did not test all possible combinations. It may be we needed to. The folks who are responsible for the data sheet only allowed a table of the M and D values we tested to be used by the product. So, what was your M and D value, and frequency of Clock IN? Were you using the DCM for anything else (any other outputs connected)? Was the CLKFB input used (it should not have been if all you needed was the CLKFX output, as using it would automatically turn on the DLL part of the DCM, and that might have created some issues (input clock frequency too low for the DLL in that mode). How soon after the DONE went high was the DCM reset released? It may be that the oscillator had not stabalized yet.

Aust>>Do you have a case open? Do you have a case number?

Austin schrieb:

Austin,

the simple question gets more and more interesting - I had the impression that Xilinx did give green on CLKFX useage for IDELAYCTRL - without any constraints

now it seems that CLKFX is OK, when

I have 2 differen V4 DDR2 boards where IDELAYCTRL is used, both boards have some trouble, in both cases CLKFX is used for 200mhz calibrate clock. I assumed that this cant be the issue, but now I cant rule this out anymore?

if an DDR2 memory controller has trouble because of mis-calibrated IDELAY then for the Xilinx customer its rather hard to troubeshoot!

Of course I am able to create some test cases to see if the calibrate works or not, but I would rather depend on reliable informatiom from Xilinx that allows me to design the calibrate clock circuit in the way that special troubleshooting is not needed.

Antti

Antti,

I seem to recall that the IO group would not generally endorse any M or D Fin combination of the DFS. Rather, the allowed ones were listed in the user's guide. I can't find it there, and I can't find it in the datasheet. I am looking in the app note... where there is quite a lengthy discussion starting on page 22.

The IC designers claim more than 700 ps p-p jitter may cause issues with the locking of the IDELAY ref clock. We will have to go back and look at this first week in January when I am back at work.

I will need to know: M, D, and Fin values that you are seeing problems with.

We did not use any other feature of the DCM: no connection to CLKFB, so the DLL part is not active.

Austin

All of the combinations I tested were listed in my original posts. No, the DCM was only used to create the clock. Other DCMs were being used for other functions but towards the end I removed all of this logic and focused on the idelay.

Seconds to minutes.

In my original post I write about monitoring the states. But, even if this were the case, the 200ps / tap I measured was constant. Strange problem, but using a dedicated 100 or 200MHz oscillator just for this function seems to work fine.

Got it,

M=14, D=1. Fin=14.318 MHz.

I also need to know: was CLKFB left unused, or was it somehow connected to something?

Austin

Austin -

I'm not the OP, but I'm the one using a 14.318MHz input with M=14, D=1.

CLKFB is not connected since this is not in a range that the DLL will work.

My internal frequency meter shows that the DCM is indeed outputing 20.4 MHz. I don't know if the IDELAY is working or not - I've not gotten to that point in my design debug. I'm just want to make sure that Lecroy's problem isn't going to nail me.

My reset circuitry is carefully done. I wait for the DCM to LOCK and also produce a stable / correct clock. I have an internal frequency meter in my design, so I wait for the DCM's FX output to be stable, then I release reset on the IDELAYCTRL block.

Thanks for your help!

Merry Christmas!

John Providenza

Aust> Got it,