Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

PLL is not consistently producing a clock

QII 7.2sp1:

I am using a Microtronix FireflyII board (CycloneII) and nios reference design. The design uses one pll to generate a 90mhz sdram clock from an on-board 24mhz osc, and another pll to generate a 50mhz logic clock from an external 50mhz osc.

During the development of my project, I have run into some inexplicable behavior of the 90mhz clock. I will start with a build which works 100% and I will make some small change like adding a gpio port. When I build this modified project, the 90mhz clock will no longer work when I try the new sof. There are no new errors to explain why this happens. If I go back to the previous sof it always works 100%.

This has happened 3 or 4 times during my project development. The way I have gotten around it is to add or change a project setting related to clocks. The first time I added a clock setting for each of the input clocks that just specified the fmax. That seemed to do it. The next time I had the problem I found that if I deleted the db folder before the build the sdram clock would work again. The next time I found that I needed to specify all the design files under the settings->files category before the project would build properly.

Every time I think I have stumbled on the magic formula to make this cursed problem go away it comes back one or two builds later. I have run out of voodoo magic to make it work. What the heck is going on here?

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    1) Please describe the difference between 90MHz working and no longer working? Does it come out a port and at other times stops? Does it come out but at the wrong frequency? Does the logic not work and you're not sure if it's the clock or not?

    2) You've probably got a timing issue, something unconstrained that happens to make timing on some compiles and does not on others. Create an unconstrained paths report(I don't know if you're using the Classic Timing analyzer or TimeQuest, but you can do it with both)

    3) Another possibility is a bad pin assignment. If an input clock pin isn't assigned, then on some compiles the fitter may put it on the clock pin you want, while on others it doesn't. (I doubt it's a regular I/O pin, because it would be more unlikely that it picks the correct pin so often)

    4) If you're using the Microtronix DDR2 core, I believe it works from a script and more off of placement constraints then timing constraints. They assign the FF locations, the delay chain settings, and everything should work. I had a case with this core where the clkctrl global buffer was jumping around, and occasionally would be placed in a bad location and fail timing. Look at the I/O timing(which was unconstrained), and see if it gives vastly different values between the compile that works and the one that doesn't.

    Hopefully this points you in the right direction. You need to debug exactly what is wrong, and then find why that is occuring in the bad builds.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    1) When its working, the 90mhz clock is easily measured on a resistor on the clock node. When I say the clock does not work, I mean there is no clock when it is probed with the scope. Instead of oscillating, it just sits at 3.3v.

    This is a reference design, and once I had the clock/pll configuration I wanted, I left it alone. My main changes were just to the names of the plls and clocks, and not to the pin assignments or frequencies. I have been slowly adding additional pins and new components to this base design.

    I will double-check, but I believe the resource report shows the same plls are being used with the same internal settings as it has always used.

    2) I am using the classic timing. How do I generate the unconstrained paths report? I did not see any timing constraints in this reference design before I added the few I mentioned. What would constitute a minimal set of timing constraints for a project?

    3) All the input clocks have assigned pins

    4) This isn't using DDR. This is Altera's SDR core.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hello,

    I think, bad timing, inappropriate constraints or whatever of this kind can't be responsible for a PLL not working respectively a clock not appearing where it should. This could be e. g. due to mixed-up pins or internal PLL resources, not considering a possible Quartus bug. A special reason could, be that the said PLL has an asynchronous reset function or an input switchover that comes from bad defined logic.

    You can additionally monitor the PLL lock output to get some status information. However, I did never see a PLL with no output, even if not locked.

    Regards,

    Frank
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    So really the circuit is clock input pin -> PLL -> output pin. You know you're driving the input pin, but the output pin is stuck. That has nothing to do with timing constraints or some of the other stuff I mentioned, as it's basic connections. Double check the IO locations in the .fit.rpt, maybe look at the Chip Editor(you probably don't need to). The other possibilities I can think of:

    - Do other things toggle? Maybe the part hasn't come out of configuration but the first thing you're looking at is this clock?

    - Does the PLL have a reset you drive with logic? Maybe that's getting driven in some instances?

    - Can you bring the clock out other pins or something like that?

    Good luck, as there will probably be some debug required.