Classic Timing Analyzer: tsu calculation backwards?

--- Quote Start ---

The actual tsu for one path is 3.7ns which means that the data signal is available 3.7ns before the clock edge arrives.

--- Quote End ---

(I wrote this before I saw Rysc's response.)

If by "actual tsu" you mean the tsu reported by Quartus (not when you know your driving device will present data to the FPGA), then Quartus is saying that the FPGA needs the data to be valid at least 3.7 ns before the clock active edge, not that Quartus knows the data will be valid by then. You entered a 0.5 ns tsu requirement, which tells Quartus that on your board the data might not arrive until as late as 0.5 ns before the clock active edge. The 3.7 ns tsu actually needed by the FPGA is 3.2 ns earlier than the 0.5 ns user-entered tsu requirement, so it really is a negative (not positive) 3.2 ns slack. It is a real timing violation for the 0.5 ns requirement.

If by "actual tsu" of 3.7 ns you mean the latest you know your driving device could present data to the FPGA, then you can give Quartus a tsu requirement of 3.7 ns. You'd probably want to give Quartus a slightly smaller tsu requirement to allow for some extra slack to care of any uncertainty in the 3.7 ns number from things like signal integrity making the signal settle out a little late, board delay being a little longer than you expect, the driving device and FPGA not getting their clocks at exactly the same time, etc.

Thanks Rysc/Brad. I'm always amazed by your expertise. I'm also amazed how you can spend so much time in these forums. Are you exployed by Altera by any chance?

I will study your responses in more detail tonight. For now, based on your explanations, it seems only external timings need to be constrained (input pin to input registers and output registers to output pin - adjusted for the requirements of the external devices), not timings between internal modules? I have a large number of internal modules in the form of Verilog, LPMs etc and i have no idea what kind of timings these modules need. This is why i just punched in 0.5 ns for tsu and th in the GUI - clearly i don't know what i'm doing but i'll figure it out soon, i'm sure...

tsu, th, tco, and min tco constraints in Quartus and the report tables for these are always for I/O timing at device pins and are in terms of the timing right at the data pin with respect to the timing right at the clock pin, not right at the register inside the FPGA.

You will see things like micro tsu and micro th for the registers inside the device when you look at the list-paths details, but you don't constrain things like tsu for the internal registers. For internal timing, you enter fmax constraints (which will be done automatically for you for PLL clocks with the Classic Timing Analyzer), clock uncertainty, multicycle, and false paths ("Cut Timing Path" in the Classic Timing Analyzer).

To be sure you've constrained everything, run "Processing --> Start --> Start Classic Timing Analyzer Constraint Check". TimeQuest users should run Check Timing and Report Unconstrained Paths.

I recommend that you not use any of the project-wide timing constraints for fmax or I/O. Constrain each non-PLL clock individually. Constrain each pin individually. Anything you miss will then be caught by the timing constraint check. Someone maintaining your design later (even if it is you) will have more confidence that you really intended the constraints you used and didn't overlook something like a particular input pin needing a tsu different from the project-wide setting.