From: lecroy7200@chek.com on
I can't seem to find a document that calls out the XY locations for the
IDELAYCTRL. Where is this information found?

When I don't use the LOC, the report for P&R says it has used 100% of
the IDELAYCTRLs. No surprize. When I look at the FPGA editor I would
expext to see all of them listed but instead I only see a small portion
of them. Why?

It appears that if I include an IDELAY that there is some sort of
requirement on where the IDELAYCTRL is located. Currently I don't use
the LOC, let the tool P&R then use the FPGA editor to see where it
placed it. Then I use the LOC. What a pain. There must be a simpler
way. I tell the tools where the IDELAY is to be used, why is it that
the tools can't place the controller automatically?

If I select the wrong location for the IDELAYCTRL, the tool does not
flag an error, the design just fails to work. You would think it would
be smart enough to know.

From: Ray Andraka on
lecroy7200(a)chek.com wrote:

> I can't seem to find a document that calls out the XY locations for the
> IDELAYCTRL. Where is this information found?
>
> When I don't use the LOC, the report for P&R says it has used 100% of
> the IDELAYCTRLs. No surprize. When I look at the FPGA editor I would
> expext to see all of them listed but instead I only see a small portion
> of them. Why?
>
> It appears that if I include an IDELAY that there is some sort of
> requirement on where the IDELAYCTRL is located. Currently I don't use
> the LOC, let the tool P&R then use the FPGA editor to see where it
> placed it. Then I use the LOC. What a pain. There must be a simpler
> way. I tell the tools where the IDELAY is to be used, why is it that
> the tools can't place the controller automatically?
>
> If I select the wrong location for the IDELAYCTRL, the tool does not
> flag an error, the design just fails to work. You would think it would
> be smart enough to know.
>


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.
From: Sean Durkin on
lecroy7200(a)chek.com wrote:
> I can't seem to find a document that calls out the XY locations for the
> IDELAYCTRL. Where is this information found?
Try Jim Wu's free ADEPT-Tool:
http://home.comcast.net/~jimwu88/tools/adept/

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
From: lecroy7200@chek.com on
Thanks.

On Nov 21, 4:56 am, Sean Durkin <s...(a)despammed.com> wrote:
> lecroy7...(a)chek.com wrote:
> > I can't seem to find a document that calls out the XY locations for the
> > IDELAYCTRL. Where is this information found?Try Jim Wu's free ADEPT-Tool:http://home.comcast.net/~jimwu88/tools/adept/
>
> 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

From: lecroy7200@chek.com on
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.





On Nov 20, 5:00 pm, Ray Andraka <r...(a)andraka.com> wrote:
> lecroy7...(a)chek.com wrote:
> > I can't seem to find a document that calls out the XY locations for the
> > IDELAYCTRL. Where is this information found?
>
> > When I don't use the LOC, the report for P&R says it has used 100% of
> > the IDELAYCTRLs. No surprize. When I look at the FPGA editor I would
> > expext to see all of them listed but instead I only see a small portion
> > of them. Why?
>
> > It appears that if I include an IDELAY that there is some sort of
> > requirement on where the IDELAYCTRL is located. Currently I don't use
> > the LOC, let the tool P&R then use the FPGA editor to see where it
> > placed it. Then I use the LOC. What a pain. There must be a simpler
> > way. I tell the tools where the IDELAY is to be used, why is it that
> > the tools can't place the controller automatically?
>
> > If I select the wrong location for the IDELAYCTRL, the tool does not
> > flag an error, the design just fails to work. You would think it would
> > be smart enough to know.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.