Pad to Setup, Clock to Pad

I am new to FPGA design so I'm sure this is a very basic question. Is there a rule of thumb when using these constraints? For example If I have a 50 mhz clock with a 20 ns period is there a general rule as to what my pad to setup and clock to pad should be in order to keep things in sync with the system clock? Any help would be appreciated.

Yes, the rule of thumb is to thumb through the data sheets for the device(s) to which your FPGA will be communicating. If a device requires a 5 ns setup time of one signal relative to some other signal than the clock to output delay of those two signals coming out of your FPGA must meet that requirement. Repeat this for every signal that enters or exits your FPGA design. Most of these constraints can be directly coded as constraints to your FPGA synthesis tool Ones that can not must still be guaranteed to be met by your design and you must verify that they are.

As a general guideline setup times of an external device will translate into clock to output delay requirement for the FPGA. Clock to output delays of an external device will translate into input setup time requirements for the FPGA. Both of these will translate in roughly the following manner:

Tsu (requirement) = Clock Period - Tco (specification) - Clock Skew - PCB prop delays differences

The actual clock cycle is not relevant to how you go about performing the task.

KJ

On a (hopefully) related issue, how do you handle the Tco jitter between different IO pads.

Lets say, the FPGA outputs clock and data to an external chip with some Tsu requirement.

Lets say, the Tco calculated for all outputs is in the range 10-12 ns, to my understanding, this is a maximum time. Is it safe to assume that any deviation from this timing will affect all outputs the same ? Is it possible that the clock signal goes out in a 20% (or 80%) of the calculated maximum Tco while some other output needs the full 100% of the maximum calculated Tco ? I would tend to think it is not possible, but I must account for some margin here (?)

Am I missing some other timing constraint ?

Thank you

Josep Duran

If there is a timing requirement between these two outputs that must be met then generally you must not allow them to change on the same edge of the same clock cycle. Two methods of doing this are:

- Take an extra clock cycle, say set one of the outputs on clock cycle 1, the other signal on the next clock cycle holding the first one constant on this clock cycle. This is generally the preferred approach and would be an example of preventing the signals from changing on 'the same clock cycle'

- Clock the two signals on opposite edges of the clock. On paper it seems to give you a built-in half a clock cycle skew between the two but when you account for duty cycle variation (clocks are never 50%) and the fact that sometimes you have no control over the clock (like if it comes from an external part) this method loses some of it's luster. This would be an example of not allowing them to change on 'the same edge'.

Controlling address, data and the write signal between an FPGA and an async SRAM is a good example of such a case. The SRAM specs generally spec requirements of 0ns of setup time for address relative to write falling and

0 hold time of data after the rising edge of write....but 0 is not negative. Work through such a design and you'll find yourself using one of the two above approaches in order to guarantee proper behaviour.

Usually that is the case, sometimes a minimum time is also available. If not assume Tmin = 0.

No.

Timing between pins is not guaranteed behaviour, it also changes over temperature ranges and sometimes internal activity. Counting on it will lead to 'mystery' problems like, the board works (or doesn't work) when you first turn it on but then after it warms up it doesn't work (or does). You'll start pulling out heat guns and cold spray marveling at the supposed thermal problem...it's not thermal, it's a timing problem.

Not really missing but just assuming things that are not guaranteed. If you count on them in your design it will let you down in a not too friendly manner.

KJ

Thank you. You have confirmed the worse of my fears. :-)

Best regards

Josep Duran

That assumes that hold requirements are guaranteed by design. Often that assumption is corrrect but sometimes it isn't. In later case you have to specify hold conditions too:

Th(requirement) = Tmin_tco (specification) - Clock Skew; Tmin_tco(requirement) = Th(specification) - Clock Skew;

Or use built-in PLLs in order to provide phase shift between the clocks at resolution finer than 180 degrees.

Besides, newer FPGAs have programmable delay elements in the IO cells so sometimes you could drive the strobe and data signals on the same clock edge. Just specify Tco(min) requirements for data signals and Tco(max) for a strobe in way that meets Th spec of the device you are talking to. The fitter is supposed to do the rest. Of course, for that to work both strobe and data have to be driven by good low-scew clock and hold time requirements of external device should be rather liberal - around (-1.5) ns.