--- Quote Start ---
I have entered a Tco Requirement of 7.5ns for the SRAM1_CS_n pin, but the reported maximum delay is 16.912ns for this pin.
Have I entered invalid constraints? Or is the reported delay not what I expect it to be? Is it valid to enter the PLL's "_clk0" output as a clock source for the Tco Requirement?
--- Quote End ---
Classic Timing Analyzer tsu, th, tco, and min tco constraints and reporting are always the I/O timing between the device pin for clock and device pin for data (lots of people misunderstand this). You should not use an internal point in the clock network like the PLL output as the clock for these constraints. What is happening between the clock device pin and the register is calculated for you automatically and can be seen by doing the "list paths" Rysc mentioned on a particular I/O path, although with Classic Timing Analyzer list paths some of the PLL details get lumped together in a single number (TimeQuest report_timing lets you see more of the detail). If you are using a PLL to clock an output register, tco is from clock device pin through PLL through output register to data output device pin. As Rysc mentioned, that PLL portion of the tco calculation can be a negative number for the sum of the PLL compensation delay and user-entered PLL phase shift.
--- Quote Start ---
The next thing I will do is to try my design with Quartus v7.2 (if this version works without problems) because there might be a bug in the Timing Analyzer in v6.1.
--- Quote End ---
The Classic Timing Analyzer can't handle everything that TimeQuest can, but what you are doing is probably within the realm of what the Classic Timing Analyzer handles just fine. I very much doubt that there is a bug in 6.1 affecting tco for single-data-rate outputs.
Honored Contributor
