Resets being routed through CLKENA blocks and then not meeting Recovery timing

[SamWhite]

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.

[SamWhite]

I have used the Quartus Prime Assignment Editor to tell the tool not to route these signals globally, and it has worked and the design now meets timing in the related areas. However, I'm still not sure I should have to do this. Is this something that people have done before, or could it be something to do with how we've written our code?

[sstrell · Accepted solution]

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.

[SamWhite]

Correct, the issue was that the clock control block being used was on the opposite side of the chip to the logic it was resetting. I will bear your comment in mind, thanks.

[Nurina]

Hi,

Does the above solution help?

Regards,

Nurina

[Nurina]

Hi,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Feel free to open a new thread or login to ‘ https://supporttickets.intel.com ’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Have a great day!

Best regards,

Nurina W.

P.S. If any answer from the community or Intel Support are helpful, feel free to rank your support experience by rating 4/5 survey. Please let me know of any inconvenience so that I may improve your future service experience.