We are getting the following message "Design requires adding a large amount of routing delay".

[PGigl]

We are getting the following message "Design requires adding a large amount of routing delay". We have examined the paths with this issue and they are clock crossings. We have put in false paths on this crossings, but we are sill seeing routing used to adjust the hold time.

[KhaiChein_Y_Intel]

Hi,

The Fitter has detected that the minimum routing delays required for some paths to satisfy hold requirements are difficult to achieve because of excessive routing resource demand. To facilitate successful routing in a timely fashion, the hold margin is sacrificed. Excessive routing demand may be caused by incorrect timing constraints, such as multicycles, or the use of gated clocks.

Verify that timing constraints, especially multicycles, are set properly. Avoid using gated clocking. Also consider reducing the routing demands of this design by using Standard Fit, increasing the PLACEMENT_EFFORT_MULTIPLIER, and/or enabling FITTER_AGGRESSIVE_ROUTABILITY_OPTIMIZATION (even though this option may hurt the setup timing). Finally, if the timing constraints are correct and the design routability cannot be improved, you can turn off ENABLE_HOLD_BACK_OFF to force the router to try harder to satisfy hold, which may result in setup failures, long router runtimes, and/or fitting failures.

Thanks.

[PGigl]

​As mentioned, this path in question is crossing a clock domain that we have marked the path as a false path.  Why would it still be attempting to meet hold times. 

[KhaiChein_Y_Intel]

Hi,

Can you check if this constraint is being ignored in the Timing Analyzer?

Thanks.

[KhaiChein_Y_Intel]

Hi,

May I know if you have any updates?

Thanks.

[PGigl]

​I will be going in there tomorrow, and hope to have an update

[KhaiChein_Y_Intel]

Hi,

May I know if you have any updates?

Thanks.

[PGigl]

​The paths in question where crossing clock domains.  The clocks are derived from a single PLL but are asynchronous (25 Mhz and 8 Mhz) but the tools were treating them as synchronous, and trying to meet a hold because of that.  A timing constraint was added to make the clocks asynchronous, and that solved the issue.

[KhaiChein_Y_Intel]

It's glad to hear that the issue has been resolved.