Forum Discussion
Altera_Forum
Honored Contributor
17 years agoRysc is correct about the minimum pulse width violations. I suspect you asked about the clock network delay because of your setup violations.
The clock network delay magnitude does not matter for internal paths (it could matter for I/O paths). What does matter is the clock skew from the difference between the clock network delays in the data arrival path and data required path. Clock skew is reported on the Statistics tab of the Report Timing window in the TimeQuest GUI. Small skews are normal even for global clocks. If this skew is bigger than around 0.1 ns, check to see whether the clock for one of the registers has combinational logic in the clock path. See http://www.alteraforum.com/forum/showthread.php?t=2388 for more information about issues with logic in the clock path. The clock network delay line in the report represents the total delay for everything in the clock path. To see what is in the clock path, run report_timing with the "-detail full_path" argument. In the Report Timing dialog box, set "Detail level" to "Full Path". You will see how the clock goes from a device pin through any PLL(s), clock control block(s) for global buffers, and combinational logic to the source or destination register. If you still have negative setup slack after you've taken care of any problems causing excessive clock skew, try the recommendations shown in Quartus at "Tools --> Advisors --> Timing Optimization Advisor" under "Maximum Frequency (fmax)".