min propagation delay in xilinx cpld

[guille]

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

 

[John Adair]

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

 

[Peter Alfke]

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

 

[Peter Alfke]

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

 

[Peter Alfke]

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

 

[Peter Alfke]

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

 

[John_H]

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.

 

[Peter Alfke]

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.

 

[jim granville]

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

 

[guille]

"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

 

[guille]

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

 

[Peter Alfke]

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
>

 

[John Adair]

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