PLL generated clocks and timing constraints

[Altera_Forum]

Is 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?

[Altera_Forum]

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

[Altera_Forum]

--- Quote Start ---    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.    --- Quote End ---     The clock on the input pin runs at 80Mhz but the output of the pll runs at 260Mhz so a tco from the input clock to my output pins won't be valid, right?

[Altera_Forum]

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

[Altera_Forum]

--- Quote Start ---  Yeah, 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.  --- Quote End ---    I have multiple chips in my system that all create this 260Mhz clock to transfer data between them. So I need to be able to check the timing between them, but there doesn't seem to be anything that will do this.

[Altera_Forum]

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

[Altera_Forum]

Thinking 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)

[Altera_Forum]

--- Quote Start ---  Thinking 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)  --- Quote End ---   Thanks for the suggestions. I decided to use option b and also switched over to TimeQuest.   Here is the setup:  One FPGA creates three 260Mhz clocks, one is used to drive logic and the other 2 are phase shifted +/- 120 degrees. This chip also drives a divided by 2 clock that is fed to other chips.  Other chips in the system generate the same 260Mhz clocks from the 130Mhz clock.  All chips drive data out on the -120 deg. shifted clock and receive it on the +120 deg. shifted clock.  When I constrain the I/O, do I need to use virtual clocks to represent the phase shifted clocks on the other chips?