predictable timing for xilinx cpld?

Hi all,

I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
from different devices (e.g. a CPU), go through the cpld, and end on
the system's expansion bus. I need to derive the timings for all the
signals on this expansion bus, which depend on the timing of the
signals at the CPU and on the prop. delays of the cpld.

The datasheet says this device has "predictable and deterministic
timing". What does this mean exactly? For example, take the pad to pad
delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
a maximum value, or can I rely in the delay being 10 ns?

e.g. take the following signal from the CPU:

CE0# assert delay from rising edge of CLK:  min 2 ns, typ 8 ns, max 10
ns.

The CLK signal does not go through the cpld, but CE0# does. The timing
report indeed says propagation delay for CE0# is 10 ns. Can I assume
that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
relative to the rising edge of CLK? Or are the figures specified by
xilinx _maximum_ times only?

Thanks.

guille wrote:

> Hi all,
>
> I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> from different devices (e.g. a CPU), go through the cpld, and end on
> the system's expansion bus. I need to derive the timings for all the
> signals on this expansion bus, which depend on the timing of the
> signals at the CPU and on the prop. delays of the cpld.
>
> The datasheet says this device has "predictable and deterministic
> timing". What does this mean exactly?

Umm, hmm, I think that may be marketing-speak for "not subject to
variations in routing (wire) delay like those FPGAs". But I shouldn't say
to much or I might not be invited to any of their parties ;-)

> For example, take the pad to pad
> delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> a maximum value,

Yup. See below.

> or can I rely in the delay being 10 ns?
>
> e.g. take the following signal from the CPU:
>
> CE0# assert delay from rising edge of CLK:  min 2 ns, typ 8 ns, max 10
> ns.
>
> The CLK signal does not go through the cpld, but CE0# does. The timing
> report indeed says propagation delay for CE0# is 10 ns. Can I assume
> that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> relative to the rising edge of CLK? Or are the figures specified by
> xilinx _maximum_ times only?
>
> Thanks.

Unless otherwise noted the times shown in the timing report or datahseet
for our CPLDs would be worst-case values. That means the lowest allowable
operating voltage, hottest allowable temperature, and a device built on a
Friday before a holiday ;-) . Assuming that you stay within the allowable
operating conditions, no device that you get from Xilinx should exhibit
worse delay behavior than this, and the vast majority will be faster.

Make sure that you take a look at the static timing report produced by iSE
when you implement your design. It's generated from the actual
implementation of your design, and is more of a final word than the
datasheet.

Speaking for myself and not for Xilinx,

Dennis McCrohan

Hi Dennis,

Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > from different devices (e.g. a CPU), go through the cpld, and end on
> > the system's expansion bus. I need to derive the timings for all the
> > signals on this expansion bus, which depend on the timing of the
> > signals at the CPU and on the prop. delays of the cpld.
> >
> > The datasheet says this device has "predictable and deterministic
> > timing". What does this mean exactly?
> 
> Umm, hmm, I think that may be marketing-speak for "not subject to
> variations in routing (wire) delay like those FPGAs".

oops.. then my approach to timing calculations will be wrong..

> > For example, take the pad to pad
> > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > a maximum value,
> 
> Yup. See below.
> 
> > or can I rely in the delay being 10 ns?
> >
> > e.g. take the following signal from the CPU:
> >
> > CE0# assert delay from rising edge of CLK:  min 2 ns, typ 8 ns, max 10
> > ns.
> >
> > The CLK signal does not go through the cpld, but CE0# does. The timing
> > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > relative to the rising edge of CLK? Or are the figures specified by
> > xilinx _maximum_ times only?
> >
> > Thanks.
> 
> Unless otherwise noted the times shown in the timing report or datahseet
> for our CPLDs would be worst-case values. That means the lowest allowable
> operating voltage, hottest allowable temperature, and a device built on a
> Friday before a holiday ;-)

:)

> . Assuming that you stay within the allowable
> operating conditions, no device that you get from Xilinx should exhibit
> worse delay behavior than this, and the vast majority will be faster.

I see.

But then there's something I don't quite understand. I looked at white
paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
are several examples on how to derive the 'external' timing parameters
from the internal parameters. All of these examples seem to assume the
internal timing parameters are always fixed values. Take for example, Tsu
(setup time for data at pad to clock at pad). This is derived as follows:

Tsu = Tin + Tlogi + Tsui - Tgck

Tin   = Input buffer delay (for data)
Tlogi = Internal logic delay
Tsui  = Internal register setup time
Tgck  = Global clock buffer delay


The XCR3256XL datasheet says that for a -10 device:

Tin    = max 3.3 ns
Tlogi1 = max 2.5 ns (assuming single p-term)
Tsui   = min 1.0 ns
Tgck   = max 1.3 ns

And indeed the same datasheet says that for 1 p-term, Tsu is:

Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns


Now my question is this: If we must take all the internal timing values
as worst case values, then the above equation could be wrong. For example,
Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.

Actually, the correct worst case equation should then be something like
this:

Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min

With no known value for Tgck_min one would need to assume a minimum 0 ns
for this parameter, which would yield a worst case Tsu of 6.8 ns.

Isn't this correct?

Thanks for your help!

Guillermo Rodriguez

Guillermo, you are concerned about what we call "tracking".
Almost all timing specs are guaranteed max values.
The min time is not specified, and a conscientious engineer might be
tempted to assume zero.
In reality, it is impossible for a small piece of silicon to be
simultaneously slow and ultra-fast.

Years ago, I defined a tracking factor: If any parameter is actually
at its max value (it cannot be any longer), then all other timing
parameters are between 70% and 100% of their guaranteed max values.
But if the chip is inherently fast, and is cold, and has high Vcc,
then all delays will be short, but the above relationship still holds:
They all track with a max 30% error between them.

This method of calculating was unchallenged until recently, when some
of the FPGA parameters started using soghisticated compensation
techniques ( like in the DCM) and hardly changed at all, while the
traditional delays showed their ususal temperature dependence ( +0.35%
for ever degree C) and voltage dependence ( 1% faster for every 1%
increse in Vcc ).

These things cannot be guaranteed in writing, since there always are
exceptions (metal delays are more stable than transistor delays, etc),
but they can serve as a guideline. And they have done that over the
past fifteen years. (You can find these explanations in old Xilinx
data books prior to 1994.)

Peter Alfke, Xilinx Applications.
========================================
guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> Hi Dennis,
> 
> Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > > from different devices (e.g. a CPU), go through the cpld, and end on
> > > the system's expansion bus. I need to derive the timings for all the
> > > signals on this expansion bus, which depend on the timing of the
> > > signals at the CPU and on the prop. delays of the cpld.
> > >
> > > The datasheet says this device has "predictable and deterministic
> > > timing". What does this mean exactly?
> > 
> > Umm, hmm, I think that may be marketing-speak for "not subject to
> > variations in routing (wire) delay like those FPGAs".
> 
> oops.. then my approach to timing calculations will be wrong..
> 
> > > For example, take the pad to pad
> > > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > > a maximum value,
> > 
> > Yup. See below.
> > 
> > > or can I rely in the delay being 10 ns?
> > >
> > > e.g. take the following signal from the CPU:
> > >
> > > CE0# assert delay from rising edge of CLK:  min 2 ns, typ 8 ns, max 10
> > > ns.
> > >
> > > The CLK signal does not go through the cpld, but CE0# does. The timing
> > > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > > relative to the rising edge of CLK? Or are the figures specified by
> > > xilinx _maximum_ times only?
> > >
> > > Thanks.
> > 
> > Unless otherwise noted the times shown in the timing report or datahseet
> > for our CPLDs would be worst-case values. That means the lowest allowable
> > operating voltage, hottest allowable temperature, and a device built on a
> > Friday before a holiday ;-)
>  
> :)
>  
> > . Assuming that you stay within the allowable
> > operating conditions, no device that you get from Xilinx should exhibit
> > worse delay behavior than this, and the vast majority will be faster.
> 
> I see.
> 
> But then there's something I don't quite understand. I looked at white
> paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
> are several examples on how to derive the 'external' timing parameters
> from the internal parameters. All of these examples seem to assume the
> internal timing parameters are always fixed values. Take for example, Tsu
> (setup time for data at pad to clock at pad). This is derived as follows:
> 
> Tsu = Tin + Tlogi + Tsui - Tgck
> 
> Tin   = Input buffer delay (for data)
> Tlogi = Internal logic delay
> Tsui  = Internal register setup time
> Tgck  = Global clock buffer delay
> 
> 
> The XCR3256XL datasheet says that for a -10 device:
> 
> Tin    = max 3.3 ns
> Tlogi1 = max 2.5 ns (assuming single p-term)
> Tsui   = min 1.0 ns
> Tgck   = max 1.3 ns
> 
> And indeed the same datasheet says that for 1 p-term, Tsu is:
> 
> Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns
> 
> 
> Now my question is this: If we must take all the internal timing values
> as worst case values, then the above equation could be wrong. For example,
> Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> 
> Actually, the correct worst case equation should then be something like
> this:
> 
> Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> 
> With no known value for Tgck_min one would need to assume a minimum 0 ns
> for this parameter, which would yield a worst case Tsu of 6.8 ns.
> 
> Isn't this correct?
> 
> Thanks for your help!
> 
> Guillermo Rodriguez

guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> Now my question is this: If we must take all the internal timing values
> as worst case values, then the above equation could be wrong. For example,
> Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> 
> Actually, the correct worst case equation should then be something like
> this:
> 
> Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> 
> With no known value for Tgck_min one would need to assume a minimum 0 ns
> for this parameter, which would yield a worst case Tsu of 6.8 ns.
> 
> Isn't this correct?

Perhaps it would be a worthwhile exercise to code up your CPLD, let
the tools have at it, and see what the static timing analyzer says?

--a

Hi Peter,

Thanks for your valuable explanation. Some comments below.

palfke@earthlink.net (Peter Alfke) wrote in message news:<e9ba0b8.0312271425.1639a8ed@posting.google.com>...
> Guillermo, you are concerned about what we call "tracking".
> Almost all timing specs are guaranteed max values.
> The min time is not specified, and a conscientious engineer might be
> tempted to assume zero.
> In reality, it is impossible for a small piece of silicon to be
> simultaneously slow and ultra-fast.

I understand. I just picked 0 ns for lack of a better estimation --
like
the 70% factor you mention below.

> Years ago, I defined a tracking factor: If any parameter is actually
> at its max value (it cannot be any longer), then all other timing
> parameters are between 70% and 100% of their guaranteed max values.
> But if the chip is inherently fast, and is cold, and has high Vcc,
> then all delays will be short, but the above relationship still holds:
> They all track with a max 30% error between them.

I see. That is very useful to know, but even then, wouldn't this mean
that the 5.5 ns value listed in the datasheet is not completely
correct?
i.e. in the Tsu1 calculation, and assuming a worst case scenario, Tin,
Tlogi1 and Tsui would be at their maximum values and Tgck would be 70%
of its maximum value, which would yield:

Tsu1 = 3.3 + 2.5 + 1 - 0.7 * 1.3 = min 5.9 ns approx.

Is this right?

> 
> This method of calculating was unchallenged until recently, when some
> of the FPGA parameters started using soghisticated compensation
> techniques ( like in the DCM) and hardly changed at all, while the
> traditional delays showed their ususal temperature dependence ( +0.35%
> for ever degree C) and voltage dependence ( 1% faster for every 1%
> increse in Vcc ).

So this would mean that the above would not be valid anymore? In this
case, what would be the right thing to do? Should I go back to the 0
ns assumption for all values for which there's no guaranteed minimum?
Or
is there a better way to do it?

> 
> These things cannot be guaranteed in writing, since there always are
> exceptions (metal delays are more stable than transistor delays, etc),
> but they can serve as a guideline. And they have done that over the
> past fifteen years. (You can find these explanations in old Xilinx
> data books prior to 1994.)

Yes, I understand completely.. However I still need to derive some
timing calculations for signals that go through a cpld. At this moment
I don't even know if I can use the external parameters listed in the
datasheet, due to my concerns expressed above. Can you recommend an
approach to this problem?

Your help is appreciated!

Guillermo Rodriguez

> 
> Peter Alfke, Xilinx Applications.
> ========================================
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > Hi Dennis,
> > 
> > Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > > > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > > > from different devices (e.g. a CPU), go through the cpld, and end on
> > > > the system's expansion bus. I need to derive the timings for all the
> > > > signals on this expansion bus, which depend on the timing of the
> > > > signals at the CPU and on the prop. delays of the cpld.
> > > >
> > > > The datasheet says this device has "predictable and deterministic
> > > > timing". What does this mean exactly?
> > > 
> > > Umm, hmm, I think that may be marketing-speak for "not subject to
> > > variations in routing (wire) delay like those FPGAs".
> > 
> > oops.. then my approach to timing calculations will be wrong..
> > 
> > > > For example, take the pad to pad
> > > > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > > > a maximum value,
> > > 
> > > Yup. See below.
> > > 
> > > > or can I rely in the delay being 10 ns?
> > > >
> > > > e.g. take the following signal from the CPU:
> > > >
> > > > CE0# assert delay from rising edge of CLK:  min 2 ns, typ 8 ns, max 10
> > > > ns.
> > > >
> > > > The CLK signal does not go through the cpld, but CE0# does. The timing
> > > > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > > > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > > > relative to the rising edge of CLK? Or are the figures specified by
> > > > xilinx _maximum_ times only?
> > > >
> > > > Thanks.
> > > 
> > > Unless otherwise noted the times shown in the timing report or datahseet
> > > for our CPLDs would be worst-case values. That means the lowest allowable
> > > operating voltage, hottest allowable temperature, and a device built on a
> > > Friday before a holiday ;-)
>  
> > :)
>  
> > > . Assuming that you stay within the allowable
> > > operating conditions, no device that you get from Xilinx should exhibit
> > > worse delay behavior than this, and the vast majority will be faster.
> > 
> > I see.
> > 
> > But then there's something I don't quite understand. I looked at white
> > paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
> > are several examples on how to derive the 'external' timing parameters
> > from the internal parameters. All of these examples seem to assume the
> > internal timing parameters are always fixed values. Take for example, Tsu
> > (setup time for data at pad to clock at pad). This is derived as follows:
> > 
> > Tsu = Tin + Tlogi + Tsui - Tgck
> > 
> > Tin   = Input buffer delay (for data)
> > Tlogi = Internal logic delay
> > Tsui  = Internal register setup time
> > Tgck  = Global clock buffer delay
> > 
> > 
> > The XCR3256XL datasheet says that for a -10 device:
> > 
> > Tin    = max 3.3 ns
> > Tlogi1 = max 2.5 ns (assuming single p-term)
> > Tsui   = min 1.0 ns
> > Tgck   = max 1.3 ns
> > 
> > And indeed the same datasheet says that for 1 p-term, Tsu is:
> > 
> > Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns
> > 
> > 
> > Now my question is this: If we must take all the internal timing values
> > as worst case values, then the above equation could be wrong. For example,
> > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > 
> > Actually, the correct worst case equation should then be something like
> > this:
> > 
> > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > 
> > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > 
> > Isn't this correct?
> > 
> > Thanks for your help!
> > 
> > Guillermo Rodriguez

Andy,

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>...
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > Now my question is this: If we must take all the internal timing values
> > as worst case values, then the above equation could be wrong. For example,
> > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > 
> > Actually, the correct worst case equation should then be something like
> > this:
> > 
> > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > 
> > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > 
> > Isn't this correct?
> 
> Perhaps it would be a worthwhile exercise to code up your CPLD, let
> the tools have at it, and see what the static timing analyzer says?

Not a problem, the design is already fully implemented and I do have
the output from the timing analyzer.

However this doesn't help too much, the analyzer internally just uses
the same procedure which is outlined in whitepaper 122 from Xilinx --
i.e. all timings are derived from the internal timing parameters, using
the maximum values for all parameters as listed in the datasheet.

This is how it is documented to work and I've experimentally verified
that it is indeed what it does.

Guillermo Rodriguez

guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312281413.4024503@posting.google.com>...
> Andy,
> 
> Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>...
> > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > > Now my question is this: If we must take all the internal timing values
> > > as worst case values, then the above equation could be wrong. For example,
> > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > > 
> > > Actually, the correct worst case equation should then be something like
> > > this:
> > > 
> > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > > 
> > > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > > 
> > > Isn't this correct?
> > 
> > Perhaps it would be a worthwhile exercise to code up your CPLD, let
> > the tools have at it, and see what the static timing analyzer says?
> 
> Not a problem, the design is already fully implemented and I do have
> the output from the timing analyzer.
> 
> However this doesn't help too much, the analyzer internally just uses
> the same procedure which is outlined in whitepaper 122 from Xilinx --
> i.e. all timings are derived from the internal timing parameters, using
> the maximum values for all parameters as listed in the datasheet.
> 
> This is how it is documented to work and I've experimentally verified
> that it is indeed what it does.

So, then, what's your problem?

--a

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312282207.39878411@posting.google.com>...
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312281413.4024503@posting.google.com>...
> > Andy,
> > 
> > Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>...
> > > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > > > Now my question is this: If we must take all the internal timing values
> > > > as worst case values, then the above equation could be wrong. For example,
> > > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > > > 
> > > > Actually, the correct worst case equation should then be something like
> > > > this:
> > > > 
> > > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > > > 
> > > > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > > > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > > > 
> > > > Isn't this correct?
> > > 
> > > Perhaps it would be a worthwhile exercise to code up your CPLD, let
> > > the tools have at it, and see what the static timing analyzer says?
> > 
> > Not a problem, the design is already fully implemented and I do have
> > the output from the timing analyzer.
> > 
> > However this doesn't help too much, the analyzer internally just uses
> > the same procedure which is outlined in whitepaper 122 from Xilinx --
> > i.e. all timings are derived from the internal timing parameters, using
> > the maximum values for all parameters as listed in the datasheet.
> > 
> > This is how it is documented to work and I've experimentally verified
> > that it is indeed what it does.
> 
> So, then, what's your problem?

As I said in my first mail, the procedure outlined in whitepaper 122
always takes the maximum value for all internal parameters when deriving
other (external) parameters, which may not be correct in all situations.
See the comments from Peter Alfke too.

Since the analyzer internally just applies the same procedure outlined
in whitepaper 122, the timing report it produces doesn't help.

Guillermo Rodriguez

>As I said in my first mail, the procedure outlined in whitepaper 122
>always takes the maximum value for all internal parameters when deriving
>other (external) parameters, which may not be correct in all situations.
>See the comments from Peter Alfke too.

>Since the analyzer internally just applies the same procedure outlined
>in whitepaper 122, the timing report it produces doesn't help.

I think this is one of those cases where you have to read between
the lines a bit.

What are you trying to do?  Understand the data sheet or justify
running the chip slightly over spec?

Peter's 70% rule-of-thumb seems like a reasonable estimate.  So the
clock delay can't be much faster than worst case if the rest of the
parameters are all close to worst case.

What can they actually test?  They probably test what you really
want to know rather than the smaller pieces.  If you just want to
run the chip at full speed like everybody else, I'd just go for it.

If you are trying to cheat and push things a bit, please tell us more.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.