Reply by John Adair January 13, 20042004-01-13
The timing comment was general and I did not say slower. Timing changes with
process, temperature, voltage, humidity, packaging etc. The variances might
be small but you are unlikely to get exactly the same timing between 2
device on 2 boards even if they come from the same batch. If you are in the
area of race conditions then all these factors can make one board work and
another not. As usual check the minimum and maximum timings and ensure that
there are sufficient timing margin. If 10% of CPLD maximum works as a
reliable minimum then timing stability can be assessed however the source
device variance also needs to be checked.

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.



"Peter Alfke" <peter@xilinx.com> wrote in message
news:4002D330.6747ABB4@xilinx.com...
> > > guille wrote: > > Uh? That's the first time I heard about timing changing due to age > > > And hopefully you will nrvrt hear this kind of nonsense again. > Different from humans, silicon does not get slower with age, or more > tired. Doesn't get any smarter either. ;-) > It just stays the way it is, unless somebody overstresses it (mainly in > the I/O) > Peter Alfke, Xilinx > >
Reply by Peter Alfke January 12, 20042004-01-12

guille wrote:
> Uh? That's the first time I heard about timing changing due to age >
And hopefully you will nrvrt hear this kind of nonsense again. Different from humans, silicon does not get slower with age, or more tired. Doesn't get any smarter either. ;-) It just stays the way it is, unless somebody overstresses it (mainly in the I/O) Peter Alfke, Xilinx
>
Reply by guille January 12, 20042004-01-12
Peter,

Peter Alfke <peter@xilinx.com> wrote in message news:<3FFD91F8.5C4BA92A@xilinx.com>...
> 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.
Yes -- in fact the design _is_ done in such a way that it doesn't depend on the min delays. I just need to work them out in order to document them on the system's datasheet. The 10% rule is OK although while we're at it I may as well take zero ns for the propagation delay. As you say:
> You can always be sure that the min delay will never be less than zero.
Sure! ;)
> Peter Alfke, Xilinx
Thanks for your helpful answer! Regards, Guillermo Rodriguez
Reply by guille January 12, 20042004-01-12
"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
Reply by jim granville January 10, 20042004-01-10
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
Reply by Peter Alfke January 9, 20042004-01-09
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.
Reply by John_H January 9, 20042004-01-09
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.


Reply by Peter Alfke January 8, 20042004-01-08
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
Reply by Peter Alfke January 8, 20042004-01-08
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
Reply by Peter Alfke January 8, 20042004-01-08
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