Forums

min propagation delay in xilinx cpld

Started by guille January 8, 2004
Hi all,

I have a signal that originates at a given device with known timing
with respect to the rising edge of a clock: 2 ns min, 8 ns typ, 20
ns max.

This signal goes through a Xilinx XCR3256XL-10 CPLD and is delayed
by the internal CPLD logic. So the timing after going through the
CPLD relative to clock (clock does not go through the CPLD) would
be like this:

tmin =  2 + min(CPLD prop. delay)
ttyp =  8 + typ(CPLD prop. delay)
tmax = 20 + max(CPLD prop. delay)

The Xilinx datasheet specifies propagation delay in this case and
for this device to be 10 ns maximum in total, including input and
output buffer delays. However no minimum or typical times are given.

I do understand typical times are of limited usefulness but minimum
I'd need to know. Right now I can only take 0 ns as minimum but I
assume there must be a better way.

Does anyone know whether this data is available in any of Xilinx's
white papers or ANs (haven't found anything so far) or available on
demand, or can anyone suggest what's the best way to handle this
case?

Thanks,
Guillermo Rodriguez
Generally you won't get minimum times. I have seen many customers fall over
this aspect of CPLDs with their designs failing in the field after years of
product production. Usually the timing of CPLDs change due to ageing,
silicon process changes (usually faster) etc etc.

Best to register signals using a high speed clock to set minimum delays use
rising or falling edges as best suits your design. Alternatively you can
positively skew signal timing by altering pcb trace lengths.This usually
gives a fairly stable result once you have got it sorted but can be a bit of
fiddle as speed down traces depends on loading.

John Adair
Enterpoint Ltd.

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.

"guille" <guillerodriguez@terra.es> wrote in message
news:5d891e95.0401080116.646d069a@posting.google.com...
> Hi all, > > I have a signal that originates at a given device with known timing > with respect to the rising edge of a clock: 2 ns min, 8 ns typ, 20 > ns max. > > This signal goes through a Xilinx XCR3256XL-10 CPLD and is delayed > by the internal CPLD logic. So the timing after going through the > CPLD relative to clock (clock does not go through the CPLD) would > be like this: > > tmin = 2 + min(CPLD prop. delay) > ttyp = 8 + typ(CPLD prop. delay) > tmax = 20 + max(CPLD prop. delay) > > The Xilinx datasheet specifies propagation delay in this case and > for this device to be 10 ns maximum in total, including input and > output buffer delays. However no minimum or typical times are given. > > I do understand typical times are of limited usefulness but minimum > I'd need to know. Right now I can only take 0 ns as minimum but I > assume there must be a better way. > > Does anyone know whether this data is available in any of Xilinx's > white papers or ANs (haven't found anything so far) or available on > demand, or can anyone suggest what's the best way to handle this > case? > > Thanks, > Guillermo Rodriguez
Existing silicon does NOT get slower due to ageing, but newer processes
tend to be faster than old ones. So it is not age that matters, but
rather "date of birth".  Do NOT  worry that your existing board might
loose its speed over time...
Peter Alfke, Xilinx
===============
John Adair wrote:
> > Generally you won't get minimum times. I have seen many customers fall over > this aspect of CPLDs with their designs failing in the field after years of > product production. Usually the timing of CPLDs change due to ageing, > silicon process changes (usually faster) etc etc. > > Best to register signals using a high speed clock to set minimum delays use > rising or falling edges as best suits your design. Alternatively you can > positively skew signal timing by altering pcb trace lengths.This usually > gives a fairly stable result once you have got it sorted but can be a bit of > fiddle as speed down traces depends on loading. > > John Adair > Enterpoint Ltd. > > This message is the personal opinion of the sender and not that necessarily > that of Enterpoint Ltd.. Readers should make their own evaluation of the > facts. No responsibility for error or inaccuracy is accepted. > > "guille" <guillerodriguez@terra.es> wrote in message > news:5d891e95.0401080116.646d069a@posting.google.com... > > Hi all, > > > > I have a signal that originates at a given device with known timing > > with respect to the rising edge of a clock: 2 ns min, 8 ns typ, 20 > > ns max. > > > > This signal goes through a Xilinx XCR3256XL-10 CPLD and is delayed > > by the internal CPLD logic. So the timing after going through the > > CPLD relative to clock (clock does not go through the CPLD) would > > be like this: > > > > tmin = 2 + min(CPLD prop. delay) > > ttyp = 8 + typ(CPLD prop. delay) > > tmax = 20 + max(CPLD prop. delay) > > > > The Xilinx datasheet specifies propagation delay in this case and > > for this device to be 10 ns maximum in total, including input and > > output buffer delays. However no minimum or typical times are given. > > > > I do understand typical times are of limited usefulness but minimum > > I'd need to know. Right now I can only take 0 ns as minimum but I > > assume there must be a better way. > > > > Does anyone know whether this data is available in any of Xilinx's > > white papers or ANs (haven't found anything so far) or available on > > demand, or can anyone suggest what's the best way to handle this > > case? > > > > Thanks, > > Guillermo Rodriguez
Existing silicon does NOT get slower due to ageing, but newer processes
tend to be faster than old ones. So it is not age that matters, but
rather "date of birth".  Do NOT  worry that your existing board might
loose its speed over time...
Peter Alfke, Xilinx
===============
John Adair wrote:
> > Generally you won't get minimum times. I have seen many customers fall over > this aspect of CPLDs with their designs failing in the field after years of > product production. Usually the timing of CPLDs change due to ageing, > silicon process changes (usually faster) etc etc. > > Best to register signals using a high speed clock to set minimum delays use > rising or falling edges as best suits your design. Alternatively you can > positively skew signal timing by altering pcb trace lengths.This usually > gives a fairly stable result once you have got it sorted but can be a bit of > fiddle as speed down traces depends on loading. > > John Adair > Enterpoint Ltd. > > This message is the personal opinion of the sender and not that necessarily > that of Enterpoint Ltd.. Readers should make their own evaluation of the > facts. No responsibility for error or inaccuracy is accepted. > > "guille" <guillerodriguez@terra.es> wrote in message > news:5d891e95.0401080116.646d069a@posting.google.com... > > Hi all, > > > > I have a signal that originates at a given device with known timing > > with respect to the rising edge of a clock: 2 ns min, 8 ns typ, 20 > > ns max. > > > > This signal goes through a Xilinx XCR3256XL-10 CPLD and is delayed > > by the internal CPLD logic. So the timing after going through the > > CPLD relative to clock (clock does not go through the CPLD) would > > be like this: > > > > tmin = 2 + min(CPLD prop. delay) > > ttyp = 8 + typ(CPLD prop. delay) > > tmax = 20 + max(CPLD prop. delay) > > > > The Xilinx datasheet specifies propagation delay in this case and > > for this device to be 10 ns maximum in total, including input and > > output buffer delays. However no minimum or typical times are given. > > > > I do understand typical times are of limited usefulness but minimum > > I'd need to know. Right now I can only take 0 ns as minimum but I > > assume there must be a better way. > > > > Does anyone know whether this data is available in any of Xilinx's > > white papers or ANs (haven't found anything so far) or available on > > demand, or can anyone suggest what's the best way to handle this > > case? > > > > Thanks, > > Guillermo Rodriguez
Existing silicon does NOT get slower due to ageing, but newer processes
tend to be faster than old ones. So it is not age that matters, but
rather "date of birth".  Do NOT  worry that your existing board might
loose its speed over time...
Peter Alfke, Xilinx
===============

John Adair wrote:
> > Generally you won't get minimum times. I have seen many customers fall over > this aspect of CPLDs with their designs failing in the field after years of > product production. Usually the timing of CPLDs change due to ageing, > silicon process changes (usually faster) etc etc. > > Best to register signals using a high speed clock to set minimum delays use > rising or falling edges as best suits your design. Alternatively you can > positively skew signal timing by altering pcb trace lengths.This usually > gives a fairly stable result once you have got it sorted but can be a bit of > fiddle as speed down traces depends on loading. > > John Adair > Enterpoint Ltd. > > This message is the personal opinion of the sender and not that necessarily > that of Enterpoint Ltd.. Readers should make their own evaluation of the > facts. No responsibility for error or inaccuracy is accepted. > > "guille" <guillerodriguez@terra.es> wrote in message > news:5d891e95.0401080116.646d069a@posting.google.com... > > Hi all, > > > > I have a signal that originates at a given device with known timing > > with respect to the rising edge of a clock: 2 ns min, 8 ns typ, 20 > > ns max. > > > > This signal goes through a Xilinx XCR3256XL-10 CPLD and is delayed > > by the internal CPLD logic. So the timing after going through the > > CPLD relative to clock (clock does not go through the CPLD) would > > be like this: > > > > tmin = 2 + min(CPLD prop. delay) > > ttyp = 8 + typ(CPLD prop. delay) > > tmax = 20 + max(CPLD prop. delay) > > > > The Xilinx datasheet specifies propagation delay in this case and > > for this device to be 10 ns maximum in total, including input and > > output buffer delays. However no minimum or typical times are given. > > > > I do understand typical times are of limited usefulness but minimum > > I'd need to know. Right now I can only take 0 ns as minimum but I > > assume there must be a better way. > > > > Does anyone know whether this data is available in any of Xilinx's > > white papers or ANs (haven't found anything so far) or available on > > demand, or can anyone suggest what's the best way to handle this > > case? > > > > Thanks, > > Guillermo Rodriguez
Guille,
your source promises a min delay that is 10% of its max delay. You are
safe in assuming a similar ratio for the CPLD. That means max 10 ns, min
1.0 ns.
This seemingly ridiculously loose specification is the result of many factors:
Processing tolerances including "down-binning" where the manufacturer
marks a faster ( and more valuable) part as a slower speed grade,
because therehappens to be more demand for that grade.
Then temperature ( cold is faster) and Vcc tolerances ( high is faster).
Plus additional guardband, since the min parameter is not actually
tested ( the max value is ), plus a lot of tester guardband if it were tested.

But 10% is a safe value, as long as you do not retrofit five years from
now, when you might get surprised by a much faster part...

It is always safer to design in sucha way that min delays values do not matter.
You can always be sure that the min delay will never be less than zero.
Peter Alfke, Xilinx

guille wrote:
> > Hi all, > > I have a signal that originates at a given device with known timing > with respect to the rising edge of a clock: 2 ns min, 8 ns typ, 20 > ns max. > > This signal goes through a Xilinx XCR3256XL-10 CPLD and is delayed > by the internal CPLD logic. So the timing after going through the > CPLD relative to clock (clock does not go through the CPLD) would > be like this: > > tmin = 2 + min(CPLD prop. delay) > ttyp = 8 + typ(CPLD prop. delay) > tmax = 20 + max(CPLD prop. delay) > > The Xilinx datasheet specifies propagation delay in this case and > for this device to be 10 ns maximum in total, including input and > output buffer delays. However no minimum or typical times are given. > > I do understand typical times are of limited usefulness but minimum > I'd need to know. Right now I can only take 0 ns as minimum but I > assume there must be a better way. > > Does anyone know whether this data is available in any of Xilinx's > white papers or ANs (haven't found anything so far) or available on > demand, or can anyone suggest what's the best way to handle this > case? > > Thanks, > Guillermo Rodriguez
Because of the "down-binning," using timing relative to the fastest speed
grade may be the "safe" way to go.

From an earlier communication with the fine Apps folks at Xilinx:

]  To get a path minimum, a rule of thumb is to look at the fastest speed
]  grade part for the given density and find the maximum specification in
]  the datasheet. Then a minimum should be no less than 1/4 of the maximum
]  value.
]
]  Example:
]  You are concerned about the clock-to-out path for a CoolRunner-II 384
]  macrocell device in a -10 speed grade.
]
]  1. Open the XC2C384 datasheet and look for Tco (clock to out)
]  2. Look up Tco for the fastest speed grade (-7 is fastest in this
]  density)
]  3. Multiply this value by 0.25 to find the minimum value for Tco
]
]  The reason that you must use the fastest speed grade is because a part
]  may be sorted into a slow speed grade due to only one timing path not
]  meeting the faster speed requirements. As a result, 99% of the device
]  could be a faster speed grade so we must assume the part is the fastest
]  speed grade.

If 10% is a "better" number than this rule of thumb, I'd love to know.


I think that "25% of the max value of the fastest part" is not
conservative enough. I prefer 10%. This difference ( of perhaps a single
ns!) may just indicate different degrees of conservativism ( or
experience, or grey hair.
I have plenty of those. ) I also like to sleep at night, with a good conscience...

Peter Alfke
======================
John_H wrote:
> > Because of the "down-binning," using timing relative to the fastest speed > grade may be the "safe" way to go. > > From an earlier communication with the fine Apps folks at Xilinx: > > ] To get a path minimum, a rule of thumb is to look at the fastest speed > ] grade part for the given density and find the maximum specification in > ] the datasheet. Then a minimum should be no less than 1/4 of the maximum > ] value. > ] > ] Example: > ] You are concerned about the clock-to-out path for a CoolRunner-II 384 > ] macrocell device in a -10 speed grade. > ] > ] 1. Open the XC2C384 datasheet and look for Tco (clock to out) > ] 2. Look up Tco for the fastest speed grade (-7 is fastest in this > ] density) > ] 3. Multiply this value by 0.25 to find the minimum value for Tco > ] > ] The reason that you must use the fastest speed grade is because a part > ] may be sorted into a slow speed grade due to only one timing path not > ] meeting the faster speed requirements. As a result, 99% of the device > ] could be a faster speed grade so we must assume the part is the fastest > ] speed grade. > > If 10% is a "better" number than this rule of thumb, I'd love to know.
John_H wrote:
> Because of the "down-binning," using timing relative to the fastest speed > grade may be the "safe" way to go. > > From an earlier communication with the fine Apps folks at Xilinx: > > ] To get a path minimum, a rule of thumb is to look at the fastest speed > ] grade part for the given density and find the maximum specification in > ] the datasheet. Then a minimum should be no less than 1/4 of the maximum > ] value. > ] > ] Example: > ] You are concerned about the clock-to-out path for a CoolRunner-II 384 > ] macrocell device in a -10 speed grade. > ] > ] 1. Open the XC2C384 datasheet and look for Tco (clock to out) > ] 2. Look up Tco for the fastest speed grade (-7 is fastest in this > ] density) > ] 3. Multiply this value by 0.25 to find the minimum value for Tco > ] > ] The reason that you must use the fastest speed grade is because a part > ] may be sorted into a slow speed grade due to only one timing path not > ] meeting the faster speed requirements. As a result, 99% of the device > ] could be a faster speed grade so we must assume the part is the fastest > ] speed grade.
This sounds a little skewed in the non digital logic sense ? Speed skew across a die has to be negligable, and whilst one path MAY just miss a notch as they say (even by 100ps), it will not cause a 'bump in speed' grade on other paths. A far more realistic reason is that all devices come from the same wafer, and fast/slow is largely a marketing/labeling [Price] exercise, the more so away from the very, very fastest speed grade. We've tested CPLD's with different 'speed labels', using ring osc test patterns, and found < 1% variation in supposedly widely different speed grades. If the data sheet suggests a different process/recipe, then it can get more interesting : IIRC, there is a recent coolrunner 'spin' that has worse Iq specs, in order to get faster Tpd specs A failure on that selection, can not quite be tagged slower, as that would violate Iq's. -jg
"John Adair" <newsreply@loseinspace.co.uk> wrote in message news:<u_9Lb.154$M4.82@newsr2.u-net.net>...
> Generally you won't get minimum times. I have seen many customers fall over > this aspect of CPLDs with their designs failing in the field after years of > product production. Usually the timing of CPLDs change due to ageing,
Uh? That's the first time I heard about timing changing due to age (unless you mean old technology is slower than new technology :)
> silicon process changes (usually faster) etc etc. > > Best to register signals using a high speed clock to set minimum delays use > rising or falling edges as best suits your design. Alternatively you can > positively skew signal timing by altering pcb trace lengths.This usually > gives a fairly stable result once you have got it sorted but can be a bit of > fiddle as speed down traces depends on loading.
Good advice, thanks. However the design is closed at this stage and no changes are possible -- I just need to derive the timing for the current implementation. Thanks anyway, Guillermo Rodriguez