Adding a second PLL to Cyclone III EP3C16

1) For this second one, look at where the pin is placed(which dedicated clock inputs).

2) Look in the handbook and see what PLLs that can drive for your device.

3) Look in the Compilation Report -> Fitter -> Resource Section -> PLL Summary and find where this one is placed(which won't be by the one you'd expect.)

If you want to visualize any of this, right-click on the name and Locate to Chip Planner(note this is a die view, so it may be flipped left to right if it's in a flip-chip package)

I'm guessing something will jump out as to what's going on. By default, if a pin is on a dedicated clock input and drives a PLL that is available, the fitter will always place them next to each other.

Thanks both. The pins were OK, they are both proper clock pins.

I found a solution by accident by playing with the PLL parameters:

Setting OPERATION_MODE to "NO_COMPENSATION" (originally it was NORMAL) fixed it.

Note that this doesn't "fix" the problem per se. The original warning was that you put the PLL in Normal compensation mode, where it's compensating for the clock delay. But since the PLL is not fed by its dedicated clock(and hence there's a long route from the pin it comes in on to the PLL that is not compensated for), it can't do this "Normal Compensation" that you're asking for. It's still compensating for a lot of the clock path, just not all of it.

By changing the compensation mode to No Compensation, you're not asking for any compensation. Since you're not asking for it, there's no reason to warn you that it wasn't able to do it. But I believe the PLL is still being placed away from the pin driving it and will have a long delay. In fact, it will be considerably longer now. It's generally a better solution to put it back to Normal Compensation, so at least some of it is compensated for and accept that you get a warning, rather than No Compensation.

(Most importantly, compensation basically shifts your clock back in time to compensate for the clock tree delay, i.e. it makes your clock tree seem like it's really fast. This is good for getting quick Tcos and things like that. In essence, it changes the relationship to other domains. If you have timing constraints that are correct, then this whole PLL compensation thing is a secondary affect. If you meet timing wth No Compensation, then everything's fine and you don't have to worry about it. If you do Normal Compensation and your PLL is placed away from the clock pin, but you still make timing, then everything is fine. The reason this is a critical warning is that users often layout their boards before doing timing constraints, and may not be aware that the PLL can't be placed next the clock pin that drives it for whatever reason. They get their boards back, can't meet timing, and can't do anything without a re-spin. BUt if you make timing with it the way it is, then feel free to ignore it...)

The problem is, because you did not drive your clock to two dedicated clock inputs, that are directly connectable to different PLLs. pin_31 and pin_32 are both dedicated inputs of PLL1.

The good thing is, that starting with Cyclone III (and other high end FPGAs), you are able to route PLL input from non-dedicated pins, chain PLLs and similar. In many designs, it's not absolutely necessary to have the features of dedicated clock inputs, you can accept a somewhat higher jitter and delay tolerance. Clearly, it's not always wanted to connect the clock at opposite sides of the FPGA, as it is required to connect both PLLs directly.

Thanks, I can follow that!

Looking at the clock map for the Cyclone 3 (handbook vol 1), it shows PLL1 and PLL3 alongside clock pins 0 to 3 (left hand side). However PLL2 is on the opposite side of the chip (along clocks 4 to 7) right hand side, with no "decent" path from the LHS, so no wonder it wouldn't play ball.

As a test, I created a third PLL, which worked (compensated) OK with clock pin 11 (top side), and also pin 1 (left side).

So now I got a much better feeling of what is going on..

thanks both!