TimeQuest - clocks related by default?

Hi All,

It is obviously my fault, and the correct answer is probably "RTFM" (1), but I've just lost significant amount of time, because TimeQuest treats clocks as related by default. The design which worked perfectly compiled with standard Timing Analyzer, got crazy after switching to TQ. I discovered the problem when I got strange warnings like:

"Warning: 26 (of 12252) connections in the design require a large routing delay to achieve hold requirements. Please check the circuit's timing constraints and clocking methodology, especially multicycles and gated clocks."

The TQ considers all clocks as related unless specified otherwise. Is it reasonable to consider two clocks with different frequences (e.g. 10.3213 MHz and 13.43345 MHz - just the random values) as related? In this case there must be ALWAYS ts and th violations. Shouldn't the TQ loudly complain about not specified relationships between the clocks instead of assuming by default that all clocks are related?

-- TIA & Regards, Wojtek.

(1) qts_qii53019.pdf

Page 7-1: All clocks are related by default. (Refer to "Related and Unrelated Clocks" on page 7-=AD13.) Page 7-13: Related and Unrelated Clocks In the Quartus II TimeQuest Timing Analyzer, all clocks are related by default, and you must add assignments to indicate unrelated clocks. However, in the Quartus II Classic Timing Analyzer, all base clocks are unrelated by default. All derived clocks of a base clock are related to each other, but are unrelated to other base clocks and their derived clocks.

Then on 7-14 it is explained how to set clocks to unrelated with set_clock_groups -exclusive -group {clock_a} -group {clock_b}

Reply to
wzab
Loading thread data ...

Wojtek,

Analyzing all clock transfers by default is consistent with what other SDC based, ASIC strength Timing Analyzers (e.g. PrimeTime) do, and that is the main reason why we did it this way.

The warning you got is intended to tell you that the fitter is seing hold violations that look too high to be normal. This is basically the waring you are asking for, but maybe the text is not that clear. Basically, a number of issues with the SDC can create this. Most common ones are 1) not cutting transfers between unrelated clocks (what seems to be your case) and 2) Not adding "set_multicycle_path - hold" when adding a "set_multicycle_path -setup" (Another difference with Classic).

In your case, I recommend you use the report_clock_transfers command to review all your clock transfers, and then add a false path or clock group as needed.

Also, please note that we improved the Quartus II V7.1 QSF2SDC utility to automatically add the set_clock_groups to match Classic Timing Analyzer behavior. We also automatically add the hold multicycles to match Classic behavior.

Hope this helps.

-David Karchmer Altera

Reply to
dkarchmer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.