Timequest reports setup violation in clock "n/a"

[Altera_Forum]

Clock Slack Endpoint TNS 

n/a -8.274 -233.269   I'm quite certain I have no signal called "n/a" in my device, so this must be something I did wrong in the constraints. Anyone see this problem?  --Mickey

[Altera_Forum]

You probably did a set_max_delay or set_min_delay assignment on an I/O port. I/O analysis is always analyzed as if there's an external register. (For example, if you do a set_max_delay on an output port of 10ns to try and mimic a 10ns Tco requirement, then TQ treats it like you're driving an external register.) The problem is that TQ doesn't know what clock drives that external register, and ends up calling it n/a.  

The constraints intended for I/O constraints are set_input_delay and set_output_delay, which have a -clock parameter, whereby you explicitly tell it what clock is driving the off-chip register. I know some of the documentation talks about using set_max/min_delay for I/O constraints, and for the most part it's easy and it works. My biggest concern with it is that it ignores PLL phase-shifts. So if you have a set_max_delay of 10ns, and it takes 9ns to get off-chip, then you have a slack of +1ns. Let's say someone else phase-shifts that PLL tap forward by 2ns, so now your data gets out 2ns later. Assuming everything else is the same, the set_max_delay requirement would still say you met timing by 1ns. To account for this, you would need to change the set_max_delay to 8ns, in which case you would fail. This is exactly how set_max/min_delay is supposed to work, and why I don't generally recommend it for I/O, because it's an easy mistake for users to make.

[Altera_Forum]

Ah... 

 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? I'm trying to get an external RAM interface properly constrained, and need to have the phase shifts in there for it to work.

[Altera_Forum]

--- 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.

[Altera_Forum]

It ignores the manual phase-shift in it's analysis, but if you tweak the constraint in the opposite direction, it all works out. (I hate to say ignores, since that sounds like a mistake. Phase-shifts affect your edges, which affect the setup and hold relationships. set_max/min_delay is purposely meant to override the default setup and hold relationships, i.e. let the user tweak it to whatever they want, and as such, the original phase-shift is not used in the new calculation). So you can tweak your settings in the opposite direction, or learn how the set_input/output_delay constraints work. I posted a TimeQuest .ppt in here that talks about default setup and hold relationships, multicycles, etc. It's probably worth looking at that before proceeding. (It doesn't cover the I/O constraints, but it still might be worth looking at to understand setup and hold relationships.)