Honored ContributorIs there a way to specify a tco from a clock generated by a pll to an output pin? The Quartus manual says that tco only defines a pin to pin delay, but this clock does not come from a pin. Also, for a pll that isn't driven by its dedicated input pins, is there a way to report the phase relationship between the generated clocks and the and the clock input?
Honored ContributorIn general, all timing is traced back to the top-level I/O. You can do some things to avoid this(like creating master clocks inside the device), but in general this is not recommended.
The output of the PLL is based on the input clock that feeds it, which comes from a pin(usually). So your Tco is from that input pin to the output pin. For example, if you had two compiles and one had a 1ns delay from the pin to the PLL, and the second one had a 5ns delay, the data's Tco would be considerably different. If you're in a situation where that delay "cancels out", i.e. you just care about a bunch of output pins related to each other, then it will cancel out when using the input pin too. As for the second item, sort of. Basically you've got a delay from the pin to the PLL that is uncompensated for, so static timing analysis will show this. Note that it will change with PVT. But there is no direct report for this, as it doesn't really matter in a timing analysis perspective. If you do a timing requirement(like a clock constraint or a Tco), then that delay will be used in the calculations, and if you're curious what that delay is, then do a List Paths on it and you can see all the details. (I'm assuming you're using the Classic Timing Analyzer). If you use TimeQuest, you can probably do things like report_net to directly get this info, but the basic principle that it is accounted for in your constraints still holds true.Honored ContributorHonored ContributorYeah, that's a weird combo, and assume anything this domain needs to be related to is out of the PLL. If I remember correctly, your Tco is still your delay from the input pin to/through the PLL, minus it's delay compensation, plus the global, through the register and out the pin. The compensation and global should be pretty close to canceling out.
Again, since your Tco's don't really make sense in relation to your input clock, that delay will just cancel out for everything you do.Honored ContributorHonored ContributorSo you do care about the delays from the input pin. Use your Tco, Tsu, Th and Min Tco constraints, which are related to the input clock, to analyze these interfaces.
Honored ContributorThinking about this some more, I'm concerned that your PLLs will talk correctly. For example, if you have 4 devices all fed with an 80 MHz clock that then create a 260MHz clock, the output clock will "align" with the input clock every 4th cycle(I think, please double check). But there is no guarantee this alignment will occur in sync across the 4 PLLs. For example, the period is ~3.846ns. So making up a theoretical time 0ns that the first PLL locks up with, it will have edges at 0ns, 3.846, 7.69, 11.538, etc. But another PLL may align with the input clock at time 8.5ns, so it will have edges at that are not "off" from the other PLL.
I did a sample design to fix this, but it requies the PLLs sending out the faster clock and then we divide it down in the altclkctrl block: http://www.alteraforum.com/forum/showthread.php?t=1473&highlight=pll Naturally, we can't send out a 13*80MHz clock to do this, as the clock trees don't run that fast. My thoughts would be to: a) Run at 3x, or 240MHz, so the output clocks align with every edge of the input clock and the problem goes away. (Theoretically you could do a 4x too) b) Have one device's PLL create the clock and use that to distribute that across the devices. (Or do something like a 13/8ths speed clock, which is 130MHz, distribute that and multiply it up. Again, the edges are aligned with the input clock, so it will work out.http://www.alteraforum.com/forum/showthread.php?t=1473&highlight=pll)Honored Contributor
