Forum Discussion

Mikexx's avatar
Mikexx
Icon for Occasional Contributor rankOccasional Contributor
5 years ago
Solved

Cyclone V PLL issues

I'm trying to obtain a 148.5MHz clock from a PLL using a 50MHz source. Currently the PLL has no output and the lock signal is low.

I'm using Quartus 18.1 as version 20 seems to be very broken when it comes to NIOS2.

I can confirm the source is connected and with a 28 bit counter and I can create a reset pulse that is ~5s long. This is used to reset the PLL

The reset signal and locked signal can be viewed on some test pins. The reset pin stays high for 5s before going low.

All VCCA_FPLL pins are driven from a 2.5V source. Since this is well decoupled and this supply is not connnected to anything toggling I beleive this power supply is going to be very quiet.

One anomally I have noticed is that in one datasheet "Pin Information for the Cyclone® V 5CEBA2 Device" - "Version 1.1" for the U484 package T4 is connected to VCCA_FPLL. I'm using the F(BGA)484 device where the T5 pin is being used as a VCCA_FPLL pin, as confirmed by Quartus Pin Planner.

RREF_TL is connected to ground using 2.0k I have checked the voltage on the RREF_TL pin and it sits at 3.13V. Is this correct? It feels too high? I can't find any documentation giving the expected voltage on this pin.

I have removed and replaced the resistor and confirmed it is 2.0k

Any ideas would be gratefully received.

  • Mikexx's avatar
    Mikexx
    5 years ago

    The PLL is now working.

    This PCB has been a little disaster. VCCBat was left unconnected so we couldn't program the device. This was drilled through from the bottom (the joys of BGAs) to the copper pad under the solder ball and a connection made. Unfortunately made to the FPGA 3.3V supply. Why 3.3V? Because it was convenient and was within the max working voltage on VCCBat.

    We also discovered that the Vref pins are left disconnected. These should be connected to GND or the respective bank power supply and it's not clear what leaving them floating will have?

    The 3.1V on the RREF_TL was perhaps an indicatio there was a problem and perhaps connected in some way to VCCBat.

    After some careful moving of the power to VCCBat from 3.3V to 2.5V I noted the voltage on RREF_TL pin was now at 0.7V, and after loading a basic test SOF file the PLL now works.

    Many thanks for your post. T5 is connected as per the rest of the VCC_FPLL pins. I was noting an anomaly on a data sheet that caused me some concern.

4 Replies

  • JonWay_altera's avatar
    JonWay_altera
    Icon for Frequent Contributor rankFrequent Contributor
    5 years ago

    Hi @Mikexx

    Im not sure about the VCC_FPLL there? Do you mean you already have it connected correctly to T5 (in fact there is a bunch of them

    M3
    T3
    T5
    F4
    U18
    H19

    Is it all the pll are not working?

    Is it intermittent locking/not-locking?

    Is it only 148.5Mhz is not locking? Changing to other output frequency works?

    • Mikexx's avatar
      Mikexx
      Icon for Occasional Contributor rankOccasional Contributor
      5 years ago

      The PLL is now working.

      This PCB has been a little disaster. VCCBat was left unconnected so we couldn't program the device. This was drilled through from the bottom (the joys of BGAs) to the copper pad under the solder ball and a connection made. Unfortunately made to the FPGA 3.3V supply. Why 3.3V? Because it was convenient and was within the max working voltage on VCCBat.

      We also discovered that the Vref pins are left disconnected. These should be connected to GND or the respective bank power supply and it's not clear what leaving them floating will have?

      The 3.1V on the RREF_TL was perhaps an indicatio there was a problem and perhaps connected in some way to VCCBat.

      After some careful moving of the power to VCCBat from 3.3V to 2.5V I noted the voltage on RREF_TL pin was now at 0.7V, and after loading a basic test SOF file the PLL now works.

      Many thanks for your post. T5 is connected as per the rest of the VCC_FPLL pins. I was noting an anomaly on a data sheet that caused me some concern.

      • JonWay_altera's avatar
        JonWay_altera
        Icon for Frequent Contributor rankFrequent Contributor
        5 years ago

        Hi @Mikexx Thanks for updating me the rootcause of the problem.

        Btw, for your concern, it seems that different package use different pins (T4 vs T5) for VCC_FPLL, what is the anomaly? What is the expectation?