Honored ContributorHow do I force quartus to use a specific PLL?
I am using a DDR2 controller and I believe that some of my critical warnings are because the PLL that it creates is not the one closest to the IO pins. I've tried looking in assignment editor but can't find out how to do it. I'm using Quartus II v11.sp1
Honored ContributorDoes your input reference clock feed the dedicated clock pin that drives the PLL you want? That's the most direct way to control it.
I also use the attached file to get the syntax for locking stuff down. Just run it in debug mode, so it dumps location assignments to the output. Change the name to match your PLL, and it then becomes pretty clear. In general, the fitter usually chooses the correct PLL, so there might be a reason it's not, either the clock coming in doesn't directly drive the PLL you want, or the PLLs you want are being used.Honored ContributorUse Google and search on "altera forum assign pll" for responses to earlier posts of the same question. The Altera Forum search engine is pretty lame.
Honored ContributorI am using a PLL to convert my 60MHz input clock on a dedicated clock (CLK14) to 100MHz that then drives all of my logic and NIOS. As part of the Qsys construction I have a DDR2 ALTMEMPHY controller which uses it's own PLL.
When I compile it I get the first PLL at position 4 and the DDR2 at position 1 although the DDR2 IO pins are at the opposite corner where PLL2 is. The critical warning I am getting says - Critical Warning: PLL clock inst|altmemddr|Nios_Only_altmemddr_controller_phy_inst|Nios_Only_altmemddr_phy_inst|Nios_Only_altmemddr_phy_alt_mem_phy_inst|clk|pll|altpll_component|auto_generated|pll1|clk[1] not driven by a dedicated clock pin or neighboring PLL source. To ensure minimum jitter on memory interface clock outputs, the PLL clock source should be a dedicated PLL input clock pin or an output of the neighboring PLL. I have been told that this warning is probably due to the pll being so far from the DDR2 IO pins. What does the phrase " output of the neighboring PLL" really mean and how do I achieve it as I know I haven't got the controller connected to a dedicated PLL input.Honored ContributorIt's not how close it is to the PLL being far from the DDR2 pins. Even if it were right next to them, it still drives global/regional clock trees, which basically is driving to the middle of the clock tree and then fanning out in a balanced structure(probably H-tree).
The problem is that the PLL is not being driven by it's dedicated clock pin. Note that altmemphy used a macro timing model, whereby hardware was actually evaluated to determine how much margin it had, then modeled for all the PVT variation, etc. Because of this, if you do something that is different than how the original setup was done, such as not using the dedicated clock driver, the results could be different. The problem with macro models is that we just don't know how much different it is. How fast are you going? I have seen numerous designs with this issue, where the board is already laid out and there's not much they can do. In the end, everything works fine. The reason it's a critical warning is to try and bring it to your attention before the board is laid out. It's not an error though, since it can be done this way. In general you should be fine unless really pushing the boundaries of what it can do. (Sorry for not having a more yes/no answer...)Honored ContributorI'm using a Cycole III EP3C40U484C7N device with a clock input of 60MHz. I then use one of the PLLs to create a 100MHz clock for my logic and the DDR2 clock frequency is 167MHz. The board I am using is a prototype board so there might be the possibility to change some pins later. It appears to run ok at the moment and the timequest analysis appears to be ok.
