Hi everyone,I've got a design which has what I think is an excessive amount of routing delay added to meet holding timing, ~23us or 3.7% of our AVGZ routing resources. When I disable Optimize Hold Timing under Advanced Fitter Settings, the resulting compile has a Design-wide TNS of -72.503ns for Hold as reported in the Multicorner Timing Analysis Summary. Analyzing the hold violations, the worst offenders are on register to register paths at the boundaries between Spine Clock Regions. I would expect this since these transitions are where the clock skew would differ the most. I'm curious if there's a way to dig deeper into why these numbers are so different. My issue is that the device is full enough and is running fast enough that I believe this additional routing is pushing the design to where it's impossible to meet setup requirements. I consistently get no setup warnings when Optimize Hold Timing is disabled. The fastest clock domain is 300 MHz and is fairly close to meeting hold requirements with no hold optimization (-2.057ns TNS) but has 12us added with Optimize Hold Timing enabled and then fails setup. If it helps, I'm using Quartus 16.1.0 Build 196 Thanks! Scott
The numbers you're seeing are very common, and I don't think you can really go much below that. Note that the 23us is higher than you think, as that's accumulated across multiple paths, e.g. a single amount of delay added can be counted many times. I also believe its' counting against the "ideal" route, e.g. when the router first starts and everything can use ideal resources(but it's illegal, since routing wires can be used more than once). So a lot of the numbers are high.
Thank you for responding Ryan! I wouldn't hate an option that tracked it through the fitter and reported more realistic numbers but I definitely understand that the Quartus development guys have bigger fish to fry.