Clock Skew doubt

Hi AA,

I am going to work tomorrow and may not be free to post. So I will add some info about io timing to complete the RTL chain:

How does io timing come into the scene?

The fpga input registers are at the mercy of the outputs from the external input device signals. Similarly, the input registers of the external output device are at mercy of fpga output signals. These two sets of nodes are no less important than fpga internal RTL chain. Here, designers are on their own to get it right by reporting correct figures to the tool.

At the very start, you need to allocate responsibility of io timing closure; is it the fpga responsibility or the external devices or shared?

Let us first assume that fpga is responsible for both ends.

For fpga input register timing, the designer must know the input data relationship to its clock (tCO of external device as well as board delays). In essence they need to know data/clock relationship at input pins of fpga. If such information is not available then the timing tool is unable to report on the paths to these registers (and does not give warnings).

For the external device input register timing, the designer needs to get information about their requirements and board delays. Many devices have tSU/tH requirements (figures apply to their pins rather than internal registers). Some modern devices do not have these requirements because they have opted for automating clock tracking features but then they still require minimum skew of the received data bus.

If the fpga input registers timing is not the responsibility of fpga then the external input device needs to know fpga tSU/tH at pins and board delays. Similarly if the external output device takes over responsibility then it needs to know tCO of fpga and board delays or perhaps just the fpga data skew range.

To my understanding, the above discussion is the basis of TimeQuest system-centric Versus fpga-centric methods. System centric implies fpga is responsible for the system. Fpga centric implies external device is responsible (not fpga).

Thus fpga centric approach reports the tSU/tH of fpga input pins just like say a DAC chip does. And it reports on FPGA output pins tCO just like an ADC chip does. It does not take responsibility of system timing.

Therefore, it is no surprise that these two methods give different results and they are not alternatives that you can simply choose whichever at will.

edit: having said that, the fpga centric approach can be adapted to meet external device requirement i.e. knowing the external device information you may opt to calculate best tSU/tH or tCO to match instead of system centric approach.