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.

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

"within the use model"

not without....

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

"austin" <austin@xilinx.com> wrote in message 
news:f9vr9h$g1q1@cnn.xilinx.com...
> 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
> 

On Aug 16, 3:28 am, "MikeJ" <mi...@fpgaarcade.nospam.com> wrote:
> 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
>
> "austin" <aus...@xilinx.com> wrote in message
>
> news:f9vr9h$g1q1@cnn.xilinx.com...
>
> > 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

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
http://home.comcast.net/~jimwu88/tools/

"MikeJ" <mikej@fpgaarcade.nospam.com> wrote in message 
news:n0Twi.6258$ZA.2931@newsb.telia.net...
> 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
>
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. 

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

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 

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

"MikeJ" <mikej@fpgaarcade.nospam.com> wrote in message 
news:RP%wi.6289$ZA.3062@newsb.telia.net...
>>>
>> 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.
>
> 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
> 

On Aug 16, 1:29 pm, "MikeJ" <mi...@fpgaarcade.nospam.com> wrote:
> > 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.
>
> 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.

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 (http://home.comcast.net/~jimwu88/tools/adept/). 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

Jim,
>
> 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 (http://home.comcast.net/~jimwu88/tools/adept/). 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.

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

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

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.