New ContributorResets being routed through CLKENA blocks and then not meeting Recovery timing
Arria 10 devices, Quartus Prime 19.1. We have a reset pipe module that is used to create a synchonised asynchronous reset. It was my understanding that the tool should then be easily able to meet timing on these signals, but it appears not. A couple of clock domains are failing recovery timing because the final register in the pipe is being routed through Clock Enable block, presumably to distribute the signal effectively, and then they're being routed right across the chip.
Is this something to do with how we've coded the resets? We have some modules that are designed to have a synchronous reset, and some that are wired to be asynchronous, i.e. in the sensitivity list (not sure why, it's just how the design has evolved over time).
Some resets have been put through these buffers and are ok because they haven't been routed so far, I'm guessing. I'm surprised to see >1000 failing paths when we're using the recommended reset scheme.
It's entirely possible for a high fanout control signal put on a global routing channel to have timing issues. Nothing unusual about taking it off the global as a possible solution (which seemed to work in your case). If you do want to use a global, you still could but you may need to check which clock control block is being used and adjust other global signal use using assignments like you did. The "insertion delay", the delay caused by routing the signal over to an available clock control block to get it onto the global routing channel, is usually the culprit. If you're design is already using some CCBs, it may have forced the Fitter to select one farther away, causing the issue.
