Timequest reports setup violation in clock "n/a"

--- Quote Start ---

Yes, I do have set_max_delay & set_min_delay statements (as one of the tutorials suggested).

you mention that it ignores PLL phase shifts - would set_input_delay or set_output_delay work better for these cases?

--- Quote End ---

The preferred set_input/output_delay always works at least as well as set_min/max_delay. As Rysc said, you have to use set_input/output_delay if the constraint needs to be aware of clock effects. This includes things like multicycles on the I/O path, not just phase shifts.

You got the "n/a" because of how TimeQuest handles this one special case where it does not force the user to define a clock used by report_timing. If you constrain an I/O with set_min/max_delay without set_input/output_delay, then TimeQuest automatically sets up a set_input/output_delay with a value of zero for you. You can see this zero-value I/O delay in the report_timing path details. The set_input/output_delay constraint must have something in its -clock argument, so TimeQuest creates the "n/a" clock.