Simple questions on IDELAYCTRL

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.

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

lecroy7200@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

Thanks.

On Nov 21, 4:56 am, Sean Durkin <s...@despammed.com> wrote:
> lecroy7...@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

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...@andraka.com> wrote:
> lecroy7...@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.

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
200pS / tap).

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 lecroy7200@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

lecroy7200@chek.com wrote:
> 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
> 200pS / tap).
>
> It seems to be related to how many multiplier stages used in the DCM.
> 
> Has anyone else seen this?

"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
news:1166289684.160124.11030@l12g2000cwl.googlegroups.com...
> Has anyone else seen the problem that lecroy7200@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
>
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 

Antti -

Have you checked to see if the IDELAY taps have reasonable delay
operations?  The original post by Lecroy7200 said:

"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:
> "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag
> news:1166289684.160124.11030@l12g2000cwl.googlegroups.com...
> > Has anyone else seen the problem that lecroy7200@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
> >
> 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

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:
> Antti -
> 
> Have you checked to see if the IDELAY taps have reasonable delay
> operations?  The original post by Lecroy7200 said:
> 
> "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:
>> "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag
>> news:1166289684.160124.11030@l12g2000cwl.googlegroups.com...
>>> Has anyone else seen the problem that lecroy7200@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
>>>
>> 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
>