Forum Discussion
Altera_Forum
Honored Contributor
9 years agoThere is a Routing Utilization report you can run in the Chip Planner. It allows you to show where there are areas of congestion, but it doesn't actually tell you what's in that area. You can go the Hierarchy Browser in the main Quartus window and right-click on hierarchies and locate to the Chip Planner to see where things are placed and look for an overlap.
Routing congestion is very difficult to debug because there is seldom a smoking gun. Let's say you had a reset that cause routing congestion. By itelf, it would easily route, so it's the combination of all the other logic routing with the reset that results in the no-fit. Actually, the one smoking gun I find is when the router adds delay to meet hold requirements. This is usually caused by incorrect multicycles(a multicycle setup without a related multicycle hold) or incorrect clock constraints(paths going between unrelated clocks, which might have something like a 0ns hold requirement, but due to clock skew a lot of delay needs to be added). Look in the fitter report's Estimated Delay for Hold timing, both Summary and Detailed, and see if anything looks wrong. The other thing I do is go to More Fitter Options, set Hold Optimizations to Off, and compile, then in TimeQuest see what fails hold timing. If it's just regular paths(like paths on a global clock tree that fail by a few 100ps) that is expected, but if there are unrelated clock domains failing hold or something like that, then fix those up first and then turn hold on and recompile. (Don't forget to look at Removal timing too, which is similar to hold, where the router adds delay to fix the timing).