Forum Discussion

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

Cyclone 5 custom board PLL issues

I created a board for cyclone 5 soc 5CSEBA5U19. The design behaves in a strange way.

(hardware design)

The JTAG chain has the HPS then the FPGA in series, like in DE1-SOC eval board.

The FPGA and the ARM can be detected successfully on Quartus. I used EPCQ128 with the FPGA and SDCARD with the ARM hps.

The FPGA can be programmed with SOF and JIC. The ARM can boot successfully from the SDCARD an I could boot the prebuilt linux that comes with the SOCEDS.

The problem is the in PLLs of the FPGA. I cannot make them work.

For ex, we have an input clk of 50MHz, lvds on Bank 8A. Another 80 MHz lvds clock on bank 4A.

When I use PLLs on these clocks to generate other values, like 25MHz from 50Mhz and 40Mhz from 80 MHz, no output clock is generated from any PLL. The lock signal is low.

IF I use two PLLs with different settings with 50Mhz clock (The 50Mhz is input to two different PLLs), one PLL works, the lock signal is raised and the output clock is generated. I verify these signals using GPIOs and Oscilloscope. I also use Signal tap. BUT the second one does not work.

Another working scenario is when I use the above two PLLs with the 50Mhz and the 80Mhz and use one LVDS_RX component. The first two plls work and their output clocks are generated successfully and their lock signals are raised. but the LVDS_RX component does not work (it rx_lock is zero and its rx_outclk is not generated). If I remove the LVDS_RX, the first two PLLs don't work again.

I tried different scenarios for the reset for the PLLs. I used a block that checks the lock signal. If the lock signal is low, it resets the PLL for few milliseconds and then de-asserts the reset signal and wait for 100ms and then again. That block works with the input clk of the corresponding PLL.

note: FOR any input clk, if I use them directly without PLLs, they work, and I can see them on the oscilloscope when I output them on GPIOs .

What would be the problem?

Thanks

9 Replies

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

    I could not solve the problem yet but I found the following:

    For the input clk 50Mhz, if I only used with its PLL, I find that it utilizes the PLL FRACTIONALPLL_X0_Y56. In this case, the PLL does not lock and not output clk from the PLL.

    When I add one other PLL, I find that the 50MHz clk utilizes the PLL FRACTIONALPLL_X0_Y74. In this the first PLL works but the newer one does not work.

    I searched online on how to force one clk to use a certain pll, and I used the following constraint in the assignment editor,

    (NOTE: The design has only one PLL connected to the 50MHz input clock and )

    set_location_assignment FRACTIONALPLL_X0_Y74_N0 -to "pll50:inst1|pll50_0002:pll50_inst|altera_pll:altera_pll_i|general[0].gpll~FRACTIONAL_PLL"

    In this case the PLL worked and the output clk is generated.

    btw, this problem happens in two boards that we created.

    any help?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    After more investigation, I found that some PLLs in one FPGA are working. Others don't. The FPGA in the other board has some PLLs that work and other that don't work. PLLs are not the same in the two boards.

    Is this an issue with the supply? Is this an issue in the FPGA chips?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Can be a problem of insufficient VCCA_FPLL filtering if the power supply is noisy. What does "don't work" exactly mean? Not locking properly?

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

    "don't work" means the lock signal is not raised and no output clock from the PLL. I use the oscilloscope to see the signals.

    If no sufficient filtering exists, will the PLL stop working at all ??? I think the board has ferrite beads as filters.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    No locking at all sounds dubious, I would expect temporary loose of lock with noisy supply.

    Can it be that the PLL parameters are marginal for some reason? Can you feed the PLL with a variable clock generator to see if it locks at different frequency? Did you check the PLL parameters for plausibility?

    Did you see PLL output if you uncheck the automatic reset option?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    I also thought that it should lose lock sometimes because of the supply. But believe me that is not the case.

    I tried feeding the PLL with 50Mhz and 25Mhz and modified the PLL parameters to accept this but nothing worked. I also revised the PLL parameters many times. I checked the fitter report to see the min and max locking frequency and my input is in range.

    I enabled the auto reset and disabled it but nothing worked. I

    I also simulated the PLLs and the simulation was good.

    I have some more boards that I can assemble and will check if this issue is repeated in the third board.

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

    After revising the schematic, I found that there is a pin named "RREF_TL" that must be connected through 2Kohm to gnd. This resistor is not in the schematic. In the cyclone 5 pin connection guidelines, it says

    "If any PLL, REFCLK pin, or transceiver channel is used, you must connect each RREF pin on that side of the device through its own individual 2.0-kΩ +/- 1% resistor to GND. Otherwise, you may connect each RREF pin on that side of the device directly to GND."

    I think this is the problem.

    Unfortunately I may have to re-manufacture the board again to include this resistor.

    Any ideas?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Pin connection guidelines and Device Handbook say RREF_TL is related to Gigabit transceiver operation only, the pin is only available in GX and GT device variants. I don't see an indication that it affects general purpose PLLs.