Virtex 4 IBUFG to DCM routing question

Hi all,

Question on the clock routing in a Virtex 4 LX 25 that I haven't found the answer to today.

I have an input clock, single ended, on a clock pin in the top half of the centre slice of the die. This clock has a IBUFG instantiated and is then connected to the clkin pins on two DCMs locked into the top half of the die and a BUFG which drives some clock monitor logic.

The routing from the input buffer to the BUFG is on nice global pink (in fpga_editor) clock net, but the route to my two DCMs is on a normal general purpose net which Ts off this. Normally it is pretty direct, but depending on the build it sometimes goes through a couple of switch boxes. I am trying to stop this!

I put a skew constraint on this net hoping to force it onto a global bus, but it just failed the constraint (~560 pS skew, 1.2nS delay to DCM pin if I remember correctly)

The clock phase is important as I am sampling a DDR input bus, and I discovered this variation when I put some offset constraints on the input pins relative to phase shifted DCM output clock generated from this net.

I thought the problem may be caused by having a BUFG on the same net, but removing this does not have any effect.

I thought the software would use a direct connect from the IBUFG to the DCM input, and then adjust the phase of the DCM to compensate for the delay. (I am using a variable phase DCM here to dynamically tune my timing, is the routing delay from the IBUF a fixed offset???)

If the routing is varing so much, is my input delay really being compensated? Perhaps it is the fact I am driving two DCMs which is breaking it, but I am a bit stuck with this?

Using ISE software 9.1 sp3.

Any thoughts anyone? Cheers, Mike.

Reply to
MikeJ
Loading thread data ...

Mike,

I think perhaps you have figured it out: driving two DCM's from the same IBUFG and a BUFG may not be possible.

Since you have FPGA_editor open, you should be able to see the direct path (only using IBUFG) to the DCM CLKIN pin. Are you able to place and route this path all by itself without issue? Obviously, this is the "normal" way of doing things, so this should work. Then see if you may add another CLKIN to that net (perhaps there is no way to do this -- FPGA_editor will show you the allowed control points....)

If this is something you must do, and you use a variable phase shift, then the problem will be chip to chip variation. The jump off into regular routing can not be compensated for. As long as you remain without the classic use models, the data sheet specifications apply for worst case phase error.

Austin

Reply to
austin

"within the use model"

not without....

Austin

Reply to
austin

Thanks Austin, as always.

I couldn't find anything in the documentation which said you couldn't directly drive two DCMs using the fast path, in fact Xilinx recommend driving the DCMs in parallel to avoid jitter accumulation. More editor playing required ....

I can live with this as long as I constrain the net between the IBUFG and the DCMs well enough, I have a fair margin on my input bus, the output is source-synchronous so I don't care.

If I move the DCMs to the BUFG side (so, IBUFG -> BUFG -> LOGIC + 2 DCMs) then I guess I will have to compensate for the BUFG delay in my DCM phase set up?

Regards, /Mike

Reply to
MikeJ

FWIW, I tried your configuration manually in fpga_editor and it works OK (i.e. dedicated routes to DCMs and BUFG). Below is the delay report in fpga_editor

Net "$NET_1": driver - comp.pin "$COMP_3.I", site.pin "B15.I" 1.255ns - comp.pin "$COMP_1.CLKIN", site.pin "DCM_ADV_X0Y2.CLKIN" 1.264ns - comp.pin "$COMP_2.CLKIN", site.pin "DCM_ADV_X0Y3.CLKIN" 0.835ns - comp.pin "$COMP_4.I1", site.pin "BUFGCTRL_X0Y31.I1"

Cheers Jim

formatting link

Reply to
Jim Wu

Hi Mike, This could be a job for 'Directed routing constraints'. In FPGA editor click Tools -> Directed Routing Constraints . You can select nets in your design that are routed as you want and get the tool to spit out a load of gobbledegook that you can cut-n-paste into your UCF file. This ensures (in the Xilinx software sense of the word) that your routing is the same every time. HTH., Syms.

Reply to
Symon

Jim, thanks very much for trying it, I managed to get the same result. I moved the locs on the DCM from 0,1 to 2,3 and removed a skew constraint on this clock which seems to be confusing the tools.

Now I get driver - comp.pin "laclk.I", site.pin "A10.I" 0.749ns - comp.pin "bufg_laclk.I0", site.pin "BUFGCTRL_X0Y25.I0" 1.213ns - comp.pin "/snip/DCM_ADV_INST.CLKIN", site.pin "DCM_ADV_X0Y5.CLKIN" 1.222ns - comp.pin "/snip/DCM_ADV_INST.CLKIN", site.pin "DCM_ADV_X0Y4.CLKIN"

Syms, excellent idea about the direct routine, it works nicely. Now I know it won't move again. I have also added some other constraints so I can pick it up if it does go wrong. Thanks for the help, Cheers, Mike

Reply to
MikeJ

um, of course that should say "directed routing" rather than "direct routine" Must learn to type...

Reply to
MikeJ

In 4vlx25, DCM_X0Y0,1,2 are in the bottom half and DCM_X0Y3,4,5,6,7 are in the top half. You can see this clearly from the "Component View" in ADEPT

formatting link
So locking DCMs to 0,1 or 2,3 will certainly cause the tool to use local routing resources from your clock input, which is in the top half of the device.

Cheers, Jim

Reply to
Jim Wu

Jim,

quite right, sorry I was posting from memory at home.

I moved the DCMs from 7,6 down to 5,4 so they were in the top half before - I moved them closer to the clock pin - but looking at the routing it goes up and then back down to the DCMs, I suspect to keep the delay length the same to them all. Clever.

I did not notice before DCM 3 is in the top half, I would have expected it to be down below.

Thanks for ADEPT, it is very useful. Interestingly I have just come back from supporting some Chinese customers, and they were also using ADEPT! We were using it to find and loc down the correct IDELAYCTRL blocks, something that is tricky in fpga_editor.

Cheers, Mike.

Reply to
MikeJ

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.