Hi,
not a senior, but I also had to wrap my head around that recently...
Input delay:
- So the FPGA receives a clock, and some signal launched on that clock. It needs to latch that signal. In order not to violate the FPGA's tSU/tH, the timing must be known
- What's the time, relative to the clock the FPGA sees, when the data signal can change? Well, that's the delay from the oscillator to the external device (cd_ext), plus the time the external device needs (tco_ext), plus the time the signal needs from the external device. But wait, the FPGA doesn't see the oscillator clock - it sees it delayed, as the clock must propagate from the oscillator to the FPGA as well! That's why you subtract that delay (cd_altr)
- Now it's obvious that you need to do worst-case calculations. Okay, the earliest time the FPGA might see a change on the signal is when the external device's timing is minimal, and the propagation delay from the oscillator is maximal. That's the second formula. Do the analogous calculation for the latest time the FPGA might see a change on the signal (first formula)
Output delay:
- Now the FPGA launches a signal, which the external device must latch. If you don't want to violate the external device's tSU/tH, the timing must be known again
- When is it safe for the FPGA to launch (i.e. change) the signal? Well, you must not violate the setup time of the external device, so you start there (tsu_ext). That's how long before the latch clock the signal must be stable at the external device (we're looking at the externa device now, so we're talking about the latch clock). Okay, but way, the signal must be stable even longer before tSU, because it needs to propagate to there first! So that's the delay from the oscillator to the FPGA (cd_altr) and from the FPGA to the external device (dd). And don't forget the clock-to-out delay of the FPGA itself - but fortunately, the timing analyzer knows that time and takes it into account. Now one last thing: the external device's latch clock is a delayed version of the oscillator clock - that's why you must subtract that propagation delay (cd_ext)
- Next question, when is it safe for the FPGA to change the signal after the launch clock? No, that's not the same as the previous question, as tCO of the FPGA might be a small range; and you have jitter probably. So again, similar calculation, but this time with the hold time of the external register (th_ext), but the signs (except for the hold time, of course) are the same (even though the 2nd formula has more parentheses, for no apparent reason)
- Bonus: why are the signs of tsu_ext and th_ext opposite? Well, that's simply because tSU happens before the clock, and tH happens after the clock
I have to admit, it's not easy. Try to draw some timing diagrams. I read tons of examples (and not few of them were ambiguous or plain wrong; I don't even claim that what I wrote here late at night is error-free), and it still took me quite a while to understand everything.
One more note: when you constrain this, you actually only tell the timing analyzer "that's the facts". And the timing analyzer can then tell you if that works or not. In case it works, good for you. In case it doesn't work... well, two options: either the fitter fixes that for you by adding I/O-pad delays, or that also doesn't work, and you'll get a critical warning that your timing specs are not met. Then you have to fiddle with the clock. Often inverting the clock at the FPGA helps (i.e. add 180 degree phase), or you have to add a PLL in the FPGA to shift the clock to a point where it works.
Best regards,
GooGooCluster
Honored Contributor
