predictable timing for xilinx cpld?

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 ;-)

Yup. See below.

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,

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

:)

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

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?

Hi Peter,

Thanks for your valuable explanation. Some comments below.

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

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?

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?

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

Andy,

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

So, then, what's your problem?

example,

might

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

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.

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

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.

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.

Not the case...

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

Peter,

Yes, that one was clear :)

Yes.

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

And also:

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.