Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Mikexx
Novice
322 Views

Cyclone V PLL issues

Jump to solution

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.

0 Kudos
1 Solution
Mikexx
Novice
306 Views

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.

View solution in original post

4 Replies
JonWay_C_Intel
Employee
316 Views

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
Novice
307 Views

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.

View solution in original post

JonWay_C_Intel
Employee
299 Views

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?

Mikexx
Novice
288 Views

Ok, I'm using the 5CEBA2F23C8 where the F signified the FineLine BGA This uses T5. The U package, with the same number of pins, is similar but uses T4.

I was taught it was good engineering practice to make the same where possible, but where there was a deviation to make it a subtle and noticeable one.

 

 

Reply