Underestimated Delay in reportTimingExample When Path Crosses HDIO or GTY Columns

[gigaAlter]

Hi, I’ve encountered an issue with underestimated delay calculation.

I’m using the UltraScale+ KU5P device and running reportTimingExample.java on a routed DCP. When the timing path passes through HDIO or GTY columns, the reported delay appears to be smaller than expected.

After checking the TimingModel, I noticed that the distArray matrix might not contain values for the columns where these tile types (HDIO or GTY) are located. As a result, the d value in the delay formula seems to be underestimated, which causes the final delay to be too small.

Is this expected behavior?
Looking forward to your response — thank you!

[clavin-xlnx]

This is an interesting observation. The timing model in RapidWright is an approximate timing model and is not designed as a comprehensive timing solution, for example it does not calculate hold time. The timing results will vary from Vivado by a small amount.

Are you able to share an example of a specific path that exhibits this behavior? Or, are you willing to suggest any improvements to the timing model? It is quite possible that we simply aren't covering a specific scenario as well as we could, so we are open to improvements.