Dear Peter,

You wrote:
> 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.

And also:
> Timing analysis is easy when you just have to add values. The
> worst-case max is the sum of the worst-case maxes.
> Trouble starts when you must subtract. Then the worst-case total max
> must use the min value of the subtracted parameter.
> That's where the tracking rules come in.

One last question if I may, just to be sure I understood correctly.

I have the impression that the timing analyzer from Xilinx does _not_
use this 70% tracking factor. In other words even when it needs to
subtract (e.g. for setup and hold times) it will always use the nominal
values as specified in the data sheets to derive all timings:

For example in order to derive Tsu the equation is:

Tsu = Tin + Tlogi + Tsui - Tgck

As you say above in the worst case Tsu would need to be calculated
using Tgck_min, but since that's not available one would need to
either assume 0 ns or use the 70% rule you mentioned. However I
believe that the timing report generated by the Xilinx tools ignores
this and happily uses the nominal Tgck value. Can you confirm this?

Also in the datasheet, the "AC Electrical Characteristics" (aka
external timing parameters, derived from the internal parameters
using the procedures outlined in white paper 122 from Xilinx) seem
to ignore both this 70% rule and the more conservative "0 ns min"
approach...

Thanks for your time,

G.

Peter,

palfke@earthlink.net (Peter Alfke) wrote in message news:<e9ba0b8.0312292009.7ac13004@posting.google.com>...
> Timing analysis is easy when you just have to add values. The
> worst-case max is the sum of the worst-case maxes.

Yes, that one was clear :)

> Trouble starts when you must subtract. Then the worst-case total max
> must use the min value of the subtracted parameter.

Yes.

> That's where the tracking rules come in.
> These things have not changed in 15 years ( you can read explanations
> in the 1989 Xilinx data book.) As I mentioned, the 70% rule has served
> us well, but don't use it blindly for unrelated parameters that might
> depend on different physical phenomena, or involve deliberately and
> cleverly stabilized parameters.

Thanks a lot for that, this is very useful. I had missed that you
were referring to FPGAs only and not to CPLDs when you mentioned
the compensation techniques.

The only question left is why the device datasheet (and the output
from the timing analyzer) lists external parameters which have been
derived by adding and substracting max values always, without using
this 70% rule... I can imagine this could lead to problems in some
designs.

I think I will derive all my timings from the internal parameters
only -- seems to be the safest bet.

Your help is very much appreciated!

Guillermo Rodriguez

I said "in modern FPGAs".  To the best of my knowledge, CPLDs do not
use these fancy compensation schemes. CPLDs are much simpler than
FPGAs, so they do not need sophisticated clock management, etc.
Peter Alfke

guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312291808.3eac24b@posting.google.com>...
> hmurray@suespammers.org (Hal Murray) wrote in message news:<vv0r59qpb4bu45@corp.supernews.com>...
> > >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?
> 
> None of the two.
> 
> I already explained in my first mail, I have a system where some
> signals go through a CPLD and end up in an expansion bus. Example,
> imagine a CE# signal coming from a CPU, going through the CPLD,
> then ending up on an expansion bus. I have to derive the timing
> specs for those signals in the expansion bus, for which I need to
> know the delays and timing relationships of signals going through
> the CPLD.
> 
> 
> > 
> > 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.
> 
> That was a nice rule of thumb but in the next paragraph of his
> mail Peter himself said this method was no longer valid for many
> parameters in recent CPLDs.
> 
> > 
> > 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.
> 
> Not the case...
> 
> Guillermo Rodriguez

Timing analysis is easy when you just have to add values. The
worst-case max is the sum of the worst-case maxes.
Trouble starts when you must subtract. Then the worst-case total max
must use the min value of the subtracted parameter.
That's where the tracking rules come in.
These things have not changed in 15 years ( you can read explanations
in the 1989 Xilinx data book.) As I mentioned, the 70% rule has served
us well, but don't use it blindly for unrelated parameters that might
depend on different physical phenomena, or involve deliberately and
cleverly stabilized parameters.

Peter Alfke
===================
Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3FF07CC3.90902@flukenetworks.com>...
> guille wrote:
> 
>  > 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.
> 
> 
> Consider using synchronous design techniques
> and the fpga's global clock distribution network.
> 
> This will allow you to verify timing
> without requiring any MIN specifications at all.
> 
> In fact, the place and route software
> will do this "static timing analysis" for you.
> 
>   -- Mike Treseler

hmurray@suespammers.org (Hal Murray) wrote in message news:<vv0r59qpb4bu45@corp.supernews.com>...
> >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?

None of the two.

I already explained in my first mail, I have a system where some
signals go through a CPLD and end up in an expansion bus. Example,
imagine a CE# signal coming from a CPU, going through the CPLD,
then ending up on an expansion bus. I have to derive the timing
specs for those signals in the expansion bus, for which I need to
know the delays and timing relationships of signals going through
the CPLD.


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

That was a nice rule of thumb but in the next paragraph of his
mail Peter himself said this method was no longer valid for many
parameters in recent CPLDs.

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

Not the case...

Guillermo Rodriguez

guille wrote:

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


Consider using synchronous design techniques
and the fpga's global clock distribution network.

This will allow you to verify timing
without requiring any MIN specifications at all.

In fact, the place and route software
will do this "static timing analysis" for you.

  -- Mike Treseler

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

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

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

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