Influence of temperature and manufacturing to propagation delay

Tom,

Increase the period constraint (reduce the time) by 1/2 the overall expected system jitter value.

If the clock input has 100 ps P-P, and the I/O switching adds 100 ps P-P, and a DCM CLKFX adds 400 ps P-P, one adds quadratically:

square root of [100 squared + 100 squared + 400 squared] to get the total peak to peak system jitter.

Take one half of that value and subtract it from the clock period for your constraint (worst clock pulse is shorter by half the P-P jitter).

Each generation of the tools has improved upon the automatic calculation of jitter, and constraining the period for you. We have not reached perfection yet in the prediction of total system jitter (all we account for is DCM jitter, and ask the customer for their "system jitter" as calculated above).

Austin

The added jitter is given as the rise / fall time within the indeterminate region of the input FF.

Let's assume the FF is TTL, then the indeterminate region is from 0.8V (max guaranteed low) to 2.0V (min guaranteed high). If your clock takes (again, as an arbitrary for instance) 250ps to traverse that region, then you should add that as a jitter factor.

Although the typical switching threshold in TTL mode is about 1.3V, it can (and will, depending on temperature and other things) switch at any point between the guaranteed input levels. CMOS is 1/3 -> 2/3 Vcc.

Cheers

PeteS

See my other posts. I assume jitter of the transition time through the indeterminate region and add it in. As I have noted, I still am responsible for adding those things in (because the tool can not possibly know about them).

In this case, I was referring to the tool itself. I expect it to give me something I can rely on *for the area it is supposed to be authoritive for*. I do not expect it to add in external clock jitter. I _do_ expect it to add in internal jitter in the FPGA, provided said jitter source is within the device. Failing that, guidance is helpful (as has actually been provided in another response on this thread).

It is indisputable that jitter and delay will be induced internally in the FPGA due to routing and loading (just as it would be for any other circuitry) - I simply want the tool to report what that is. If it must err on the conservative side, so be it.

Cheers

PeteS

Please don't take comments such as 'come now' personally. They are meant to open dialogue, not constrain it. Although I lived in the states for well over 20 years, there remain some language issues ;)

My only point was to say I want the tools to report what they *should* be able to report; not to be a replacement for solid engineering.

Cheers

PeteS

While I see that you found a solution by recompiling faster, I have a few "time-honored" solutions to this problem as well (Usually reserved for expensive, low volume systems that need to ship today (to get a paycheck next month)).

1) Check your input voltage for the power supply pins. Sometimes people will use a LPF on the power supplies, but the series resistance (probably not a precision resistor) tollerance may result in the power being within spec, but lower than normal. I like using an adjustable LDO to drive each FPGA power group (especially Vint). The other nice thing about that approach is that you can "tweak" up the power supply to the upper limit by piggybacking a parallel resistor on the ADJ pin. So, for instance instead of riding at 2.5V nominal you can make it 2.6V. The higher supply rail will help compensate for the temperature slow-down.

2) Use the static timing analyzer to look at the slowest paths. Then see if errors in these paths are a likely cause of the symptoms you are seeing. Usually they are and the recompile solution may work. Unfortunately in a lot of production systems recompiling results in a whole lot of requalification effort. In that event, trimming noted above is usually easier.

3) Get some air movement going. It doesn't take much air movement at all to make the junction temperature significantly lower. Touching it with your hand may not be a great test. If the device has a very higher thermal resistance, you won't feel anything, but it'll be cooking inside. (I saw a VAX catch fire this way many years ago ... and it was still booting).

Trevor

we are running in trouble with our curent design for a Xilinx Spartan 3 xc3s1500.

It does signal processing and it seems that sample got lost with increasing temperature. Immediately after power on all works well, some minutes later, if final temperatures is reach, some samples are missed. I hadn't a thermometer ready, but I can always touch the FPGA for a long time, it may be 50°C. It runs with a clock of 76.8 MHz, PAR states a maximum frequency of

78.777MHz, and logic utilization is about 60%.

One board works as expected and two other show the explained effect, the boards have the same layout but are made by different manufacturers. At least the not working are lead free.

Just now, we had a discusion to the influence of temperature to propagation delay. I don't believe that it influences clock lines and other logic resources in a (big) different way. Is It true or not?

I read the thread "Propagation delay sensitivity to temperature, voltage, and manufacturing", but the answers are very related to DCMs.

Tom