--- Quote Start ---
I think the next release of Quartus II will give more information, but it won't give every path.
--- Quote End ---
Rysc might have been thinking about the Fitter compilation report table shown below. It is produced in QII 8.1, at least when Juergen's message is given. I don't remember whether I've seen this table before QII 8.1.
I have seen hold optimization add significant routing delay for a path that was not in one of the clock domain combinations listed in the table. That happened to be for a case where the hold difficulty was caused by a gated clock. Gated clocks should be avoided regardless of whether they cause timing violations or large amounts of inserted routing delay. Because the problem path in that design was not included in the table, I wonder if there is some threshold for how much routing delay the Fitter hold optimization must add for the total of all paths in a clock domain combination (which might be just a large number of paths each getting a small inserted routing delay) before it gets reported in this table. That would explain why I had an unlisted clock domain combination with just a couple of paths with a big problem.
Another situation where hold optimization can insert lots of routing delay is a set_multicycle_path -setup with a value of n without a set_multicycle_path -hold with a value of n-1. The default multicycle hold in TimeQuest is 0 regardless of the multicycle setup. For a setup of n and a hold of 0, there must be enough data path delay to hold the old data value for n-1 clock cycles. For a setup of n and a hold of n-1, which is the standard combination of multicycles for use with a divide-by-n clock enable, the old data does not have to be held for any extra time.
--- Quote Start ---
The best thing to do is to go to make a copy of your design, go to Assignments -> Settings -> Fitter -> Optimize Hold Timing and turn it Off(or to I/O Paths only). Then re-fit the design
--- Quote End ---
The note at the end of the table has Rysc's suggestion. For my design with the gated clock, turning off hold optimization resulted in a new large violation, I think for a removal path. Check both the hold and removal reports when you recompile with hold optimization turned off.
+------------------------------------------------------------+
; Estimated Delay Added for Hold Timing ;
+-----------------+----------------------+-------------------+
; Source Clock(s) ; Destination Clock(s) ; Delay Added in ns ;
+-----------------+----------------------+-------------------+
; clk ; clk ; 99.647 ;
+-----------------+----------------------+-------------------+
Note: For more information on problematic transfers, consider
running the Fitter again with the Optimize hold timing option
(Settings Menu) turned off. This will disable optimization of
problematic paths and expose them for further analysis using
either the TimeQuest Timing Analyzer or the Classic Timing
Analyzer.
Honored Contributor
