Forum Discussion
There are a few things going on here. Extra delay is good for hold (in this case, removal) analysis. Remember that for hold/removal analysis, you want the signal to remain active longer to meet the timing requirement after the latch edge. So the issue here is the delay of the clock to the destination register (the data required path), not the control signal itself (data arrival path). The clock skew of 11 ns shown at the top of the screenshot is a quick giveaway to the problem.
It looks like the clock is being routed through device logic instead of a global clock routing channel because you have a gated clock. If you must gate the clock, it's usually best to put the gating logic on the clock enable signal of the destination register instead of in the clock path. That would probably fix this issue. You could also try forcing the clock onto a global routing channel using the Global Signal assignment in the Assignment Editor, but the gating logic would still require the clock to come off of the global routing channel, adding potentially additional delay.
There's no way of knowing why this routed OK on the older device vs. the Arria 10. Did the design change at all? Were there other assignments involved?
#iwork4intel