Re: Driving PLLs off multiplexed clocks

Altera_Forum · ‎10-30-2015

Hi Guys,

I have a system that I need to test over a range of frequencies and to save myself some time and effort I wish to automate the process (especially since I have to do this well over 100 times!).

The system has been passed to me and contains a PLL that was originally driven from a variable clock source (all fine and dandy), but now I wish to replicate the clock source using either a dynamically reconfigurable PLL or a bunch of PLLs with set output frequencies that I have multiplexed together so I may use only one at a time. Ideally I need to leave the system as it stands alone (i.e. not mess around with removing the original PLL due to the size and complexity of the system as this will undoubtedly break it).

My problems are 2 fold:

1. Does anyone know how to use a dynamically reconfigurable PLL in a Cyclone IV EP4CE115F29C7 device? I have infact built my own driver which matches the timing diagram in the Cyclone IV handbook but I get stuck when it comes to the actual contents I should be writing to the PLL to configure it as this is very unclear in the manual. (I don't want to be messing around with the ALTPLL_RECONFIG block and additional memory and memory drivers as I need the solution to be as space conservative as is possible!)

or 2. When I try and implement the Multiplexed PLL output idea where I have a couple of PLLs (5 output clocks each to give 10 different frequencies) and run them through a MUX like this:

always_comb

begin

case(PLLFrequencySelect)

4'b0001: PLL_Clock = CLOCK_1;

4'b0010: PLL_Clock = CLOCK_2;

4'b0011: PLL_Clock = CLOCK_3;

4'b0100: PLL_Clock = CLOCK_4;

4'b0101: PLL_Clock = CLOCK_5;

4'b0110: PLL_Clock = CLOCK_6;

4'b0111: PLL_Clock = CLOCK_7;

4'b1000: PLL_Clock = CLOCK_8;

4'b1001: PLL_Clock = CLOCK_9;

4'b1010: PLL_Clock = CLOCK_10;

default: PLL_Clock = CLOCK_50;

endcase

end

where PLLFrequencySelect is from an insystem_source (hence a TCL script can automate the switching), I am unable to drive a subsequent PLL from this ''must be driven by a non-inverted input pin or another PLL, optionally through a Clock Control block''. Conceptually I understand the problem as the input to the PLL is subject to change through the MUX but I'm hoping for a way to circumvent this as a problem so that quartus will happily synthesis this for me, if anyone knows how this maybe achieved?

Cheers,

Altera_Forum · ‎10-31-2015

Hi,

The clock that went through the MUX should be considered a gated clock already. I believe this is why QII does not allow this to be fed into the subsequent PLL. Can you check if the PLL in your device support refclk selection or switching? I know transceiver PLL support this but not sure about normal PLL.

Altera_Forum · ‎10-31-2015

I once did something similar by changing the pin assignment of the clock to a different clock pin that was connected to a test pad. Used a labview controlled function generator to generate different clock frequencies as part of an automated test.