ALTPLL Problem

Hello janhendrik,

The reference designs of the Cyclone Development Kit are using two PLLs, one for the CPU and one for the SDRAM. Have you changed the ratio of both PLLs (sdram_pll, cpu_pll)? The SDRAM clock and the CPU clock must have the same frequency.

Bye,

niosIIuser

Hi NiosIIuser,

No, I only changed the e0 connector_pll ratio. But the cpu clock is attaced to the c0 connector_pll output that still has a 1/1 ratio. Doesn't that meen that c0 output is still 50Mhz while the e0 output is 40MHz ? The sdram_pll is still c0 ratio 1/1 e0 ratio 1/1 which would make the both 50MHz, right?

Here are my settings. If I have to change them to what do I change them to keep the right phazes for each hardware component? -- revering to the sdram phase delay.

sdram_pll:

inclk0 frequency: 50.000 MHz

Operation Mode: Normal

Clk___Ratio___Ph_(dg)___TD_(ns)___DC_(%)

c0 ___1/1____ 0.00______0.00______50.00 ------- should be 50Mhz clock

e0___1/1____ -63.00____0.00______50.00 ------- should be 50Mhz clock delayed by -3.5 ns to compensate for signal delay to sdram

connector_pll:

inclk0 frequency: 50.000 MHz

Operation Mode: Normal

Clk___Ratio___Ph_(dg)___TD_(ns)___DC_(%)

c0 ___1/1____ 0.00______0.00______50.00 ------- should be 50Mhz clock

e0___4/5____ 0.00______0.00______50.00 ------- should be 40Mhz clock that goes to PLD_CLKOUT

Is this right or should I change it.

Thanks again.

Hello janhendrik,

For helping you I need some more details about your hardware. Are you using a DK from Altera? Because these ones are using one output of a PLL as a feedback to an input of another PLL for making the SDRAM clock.

BTW: SDRAM stands for synchronous DRAM, that’s why the clock of the SDRAM must have the same clock as the CPU.

Bye,

niosIIuser

Hi niosIIuser,

Yes I am using ALTERA cyclone edition development kit. With the NIOS II/s processor. I think it’s the feedback loop between the two pll’s that’s been throwing a spanner into the works. The Nios core is compiled to run at 50MHz. So I need a 50MHz clock for the SDRAM, then I need a 40MHz clock signal for output to one of the proto-headers.

Hope this helps. If you need any more info I’ll gladly provide all I can.

Hello janhendrik,

Take a look at sheet three of the Cyclone DK schematic. “pld_CLKOUT” is used to drive the clock buffer (49FCT3805). The buffered “pld_CLKOUT” is used as the feedback for the second PLL to drive the clock of the SDRAM. So if you change the frequency of “pld_CLKOUT” you will also change the frequency of the SDRAM. If you need a 40 Mhz clock at a proto-header you can change the frequency of the system in every stage or you put a 40 Mhz clock source on your expansion port (this will create a asynchronous system).

Bye,

niosIIuser

Hi niosIIuser,

After thinking about it for a while, I have only this question. If the pld_CLOUT is used as feedback to the sdram_pll doesn’t that just mean that I have to change the input of the sdram_pll to match the output of the connector_pll. Something tlike this:

sdram_pll:

inclk0 frequency: 40.000 mhz -- from pin_L14

Operation Mode: Normal

Clk___Ratio___Ph_(dg)___TD_(ns)___DC_(%)

c0 ___5/4____ 0.00______0.00______50.00 ------- should be 50Mhz clock 40 * 5/4 = 50MHz

e0___5/4____ -63.00____0.00______50.00 ------- should be 50Mhz clock delayed by -3.5 ns to compensate for signal delay to sdram -- to pin_L13

connector_pll:

inclk0 frequency: 50.000 MHz – from pin_K5

Operation Mode: Normal

Clk___Ratio___Ph_(dg)___TD_(ns)___DC_(%)

c0 ___1/1____ 0.00______0.00______50.00 ------- should be 50Mhz clock

e0___4/5____ 0.00______0.00______50.00 ------- should be 40Mhz clock that goes to PLD_CLKOUT that is also used tas feedback for sdram_pll. – to pin_L8

I’m still not sure what the time or phase delay for the sdram_pll is supposed to be. The standard example starts with it as -72 deg but if you go through the MegaWizzard plug-in manager once it changes to -63 deg, and phase delay is a function of the frequency.

I would like run the whole board at a multiple of 40MHz (but still with a single 40MHz output clock used to interface with external hardware – used as VGA pixel clock much like the 25.125 MHz designs we had used on the old UP1 and UP2 boards) but I’m not sure what that would do to the networking hardware, and the networking throughput.

Hello janhendrik,

That sounds possible. Did you try this configuration yet?

Bye,

niosIIuser

Hi niosIIuser

Yes I have, and it compiles, but then the software doesn't run. I think the problem is that I've assigned the wrong phase delay for the sdram_pll. Then the processor cannot get the instructions from the SDRAM to start the execution of my code. As yet I've been unable to find the documentation that describes what the phase delay on my Nios DevKit (Cyclone edition) SDRAM controller is supposed to be. I think this is because phase delay depends on the clock frequency and I'm adjusting the clock frequency away from the normal 50MHz - still using the onboard 50MHZ crystal though.

Unfortunately it takes me almost 15 minutes to compile a hardware image on my computer so searching for the right phase delay by trial and error would take FOREVER http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/sad.gif

I don’t know how changing the NIOS II processor to run at a different frequency (80MHz) will affect the routines and timing used to access the SDRAM so at this stage the NIOS II processor and supporting hardware is still compiled to run at 50MHz (and then there is the LAN 91C111 that I have to keep in mind as well – I’m still only learning how to work with embedded systems, and none of the Lecturers here at the University have had enough time to work with the new ALTERA kits so I feel a bit alone in my endeavors).

I was hoping that someone on the forum or at ALTERA could shed some light for me on this subject. I would appreciate it a lot and it would benefit a number of us who are learning/playing with these kits.

Thanks again.

janhendrik,

I suggest that you study our example designs closely; usually in the top-level schematic in quartus we will explain the settings used in the PLLs. As far as phase delay two basic points apply:

1. Phase delay will be fixed for a given dev board. If you go off and make your own with different trace lengths to SDRAM, you&#39;ll probably have to get out a scope and measure the delay. We do this to determine phase delay in our example designs when we roll out a new dev board.

2. If you&#39;re just using our dev board, the same phase delay applies whether you&#39;re running at 40, 50, or 80Mhz. The trick: I say "phase delay" (expressed in nanoseconds) and not "phase shift" (expressed in degrees or radians). Our example designs&#39; PLLs will have a phase delay in nanoseconds, like "-3.5" applied; if you keep this setting constant and bump the PLL output up to, say, 80Mhz, you&#39;ll be fine.