Neighboring PLLs

[Altera_Forum]

I'm using a Cyclone III C25 device (Cyclone III Starter Kit) with Quartus 8.0. 

 Inside my SOPC design I have a NIOS core, a PLL, a DDR controller, and some other peripherals.  The clock on the board is 50MHz feeding pin V9 (which best I can tell is connected to PLL4).   What I have is a PLL inside the SOPC which takes the 50MHz clock from the crystal on the board and generates a 100MHz clock for the NIOS.  The DDR controller core creates its own PLL and I set the clock input (refclk) on the DDR controller in SOPC to the output of the PLL in the SOPC (my nios CPU_CLK).  However when I compile this design I get critical warnings that the DDR controller PLL isn't "being fed by a dedicated clock pin or a neighboring PLL"  I've set the DDR PLL to PLL#1 and the cpu PLL to PLL#4 in the assignment editor...which I thought were neighboring PLLs based on the diagram in the Cyclone III data sheets.  Does anyone have a clue what I'm doing wrong? This is my first time working with PLLs. Just for kicks I tried assigning the DDR controller PLL To# 2 and# 3 but still got the same warning.   Thanks, Andrew

[Altera_Forum]

The recommendation to use neighboring PLLs when chaining PLL seems to be a new idea of Quartus software designers, not yet found in the Cyclone III handbook. It may have plausible motivations. However, if the design is operating so far, I would ignore the warnings. But there is a recommendation in the handbook to use different PLL bandwidth for source and target PLL.

[Altera_Forum]

Does chaining the PLLs for this configuration make sense? I wasn't quite sure how to handle feeding 2 separate PLLs from a single clock source on the starter board. There's no real motivation for chaining them in terms of needs to achieve a really high multiplier / divisor that wouldn't otherwise be possible with a single stage. 

 If I set it up both PLLs to be fed from the "osc_clk" V9 pin on the board, then whichever one doesn't get mapped to PLL#4 gets a single warning saying "...is not fully compensated because it is driven by a remote clock pin V9" (which makes sense).   The design works sitting here in my office, but I do get a critical timing warning for the DDR's PLL from TimeQuest (a bunch of setup times are violated) and I was guessing this was caused by the fact that the PLL is being fed from the remote pin but I don't know for sure. I get similar critical timing warnings when I attempt to chain them together too, so perhaps I'm barking up the wrong tree.  Any advice you can give would be greatly appreciated. (I'm a complete newbie with PLLs and global clock resources).  Thanks, Andrew

[Altera_Forum]

Chaining PLLs is quite normal to my opinion as a means of clock distribution with Cyclone III and other FPGAs that allow it. But depending on the intended clock network structure, driving PLLs from remote clock pins may be meaningful as well. Quartus will find reasons to complain in both cases... 

 Regarding the Timequest errors: If they are concerning the relation of different clock domains (e. g. DDR controller to loacal bus), you probably didn't contrain the clock domains sufficient. The PLLs should be able to achieve any intended relation of clock domains. If they are internal to DDR PLL clock domain, they shouldn't depend on how the PLL is clocked.