Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20764 Discussions

Locked signal stays low for Cyclone V PLL

Mikexx
New Contributor I
1,504 Views

I'm using a simple PLL using a 50MHz clock source to produce a 300MHz clock using a PLL IP in simple "Integer-N PLL" mode.

 

The 300MHz clock is fine and if I divide by 6 and count I can compare it with the reference clock with issues using signal tap.

 

However the "locked" signal remains low. I'm convinced it should be high.

 

Is there any reason why this should stay low? What am I doing wrong?

 

I'm using Quartus 20.1.1

0 Kudos
13 Replies
FvM
Valued Contributor III
1,466 Views
Hello,
can you show all parameters that are defining the PLL? What's the input clock source?
Regars,
Frank
0 Kudos
Ash_R_Intel
Employee
1,430 Views

Hi,

You are right. "Locked" signal should stay high.

But, in spite of locked = '0' are you seeing a stable clock output? This sounds strange.

Can you check if you are probing the right PLLs locked output in signal tap?


Regards


0 Kudos
Mikexx
New Contributor I
1,424 Views

It is my presumption that locked should go, and stay high.

 

The source is a 50MHz clock module and this has already been used to create a fractional PLL working at 148.5MHz for an HDMI clock and the evidence shows this is stable. This was another design to prove the HDMI interface.

 

I am using signal tap and looking directly at the locked signal. It stays low.

 

Many thanks for your reply.

0 Kudos
Ash_R_Intel
Employee
1,408 Views

Can you please share your design with us to reproduce the issue at our end?


Regards


0 Kudos
Mikexx
New Contributor I
1,396 Views

 

Many thanks for your offer.

 

I have uploaded a cut-down version of my design to include just the PLL and signal tap in a zip file . I hope this has all the information you need.

 

The clock for signal tap is the 300MHz generated clock. This is then divided by 6 so a direct comparison of timing can be made with the reference clock. I believe the reference and 300MHz clocks are both stable and consistent with each other.

 

I might have expected the Locked signal to go in and out of lock if there were any stability issues.

 

Hopefully it will be obvious that I'm doing something wrong.

 

PLL_Test.png

0 Kudos
Ash_R_Intel
Employee
1,277 Views

Hi,

Can you bring the 'global_reset' as well in your signal tap?

PLL may need some more time to get properly locked to the clock. Once it is out of reset, it may start giving the output clock, but it still may not be the correct one.

Consider the PLL output clock valid only when the locked signal is asserted.

Recommend you to run the signal tap for some more time and trigger on the locked signal.

Regards


0 Kudos
Mikexx
New Contributor I
1,242 Views

 

I've pulled out the local rst signal for the PLL IP and added that to signal tap.

Mikexx_1-1683308234176.png

 

I can confirm the locked signal never goes high. If I try and trigger a signal tap capture with this signal transition going high it never happens.

 

This is quite a simple project to test the failure. I'm surprised I seem alone in having this issue.

0 Kudos
Ash_R_Intel
Employee
1,147 Views

Hi,

I tried your design on a Cyclone V SoC dev kit with corresponding pin changes. It works fine for me. See the screen shot.

Ash_R_Intel_0-1684298909574.png

 

Please check if you are providing a stable 50MHz clock to the PLL.

 

Regards

 

0 Kudos
Mikexx
New Contributor I
1,058 Views

Many thanks for trying this out.

The crystal module is a EC3645TS-50.000M TR

The datasheet: https://abracon.com/datasheets/Ecliptek/EC36.pdf

It should have low jitter and low sensitivity to ripple on it's power rail.

I've checked with a 1GS/s scope and jitter after 10uS is consistent with +/-1ns sampling scope capabilities. It is confirmed by a scope to be nominal 50MHz.

Both the 2.5V for the PLL supply and 3.3V rails have ~40mv p-p ripple that should be within spec. The same +3.3V is supplied to the crystal and the FPGA VCCIO associated with the input so any ripple should track thresholds.

There are two clock pins attached to the FPGA, I have tried both as the reference clock in the PLL and locked remains low. I have tried 3.3V-TTL and 3.3V-LVCMOS pin input thresholds.

I've tried different settings such as low bandwidth.

For now I have put this issue on hold as the 300MHz clock seems stable for my needs.

Can there be any other cause I haven't considered?

0 Kudos
Ash_R_Intel
Employee
1,081 Views

Hi Mike,

Any update on the case?


Regards


0 Kudos
Ash_R_Intel
Employee
994 Views

Hi,

Can you try inserting the signal tap freshly on the locked pin?


Regards


0 Kudos
Ash_R_Intel
Employee
877 Views

Hi,

As there is no further response to the case, I am setting the case to closure. However, it will still be open for the community members to comment. Please feel free to open a new case if you need support.


Regards



0 Kudos
Mikexx
New Contributor I
808 Views

Sorry it's taken so long to reply.

The Locked signal would stay high if I set the "PLL Bandwidth Preset" to "High".

I also added some extra decoupling on the 2.5V rail.

I also entered the clock period into the Timing Analyser as I wasn't sure if the dips in the lock signal were due to SignalTap sampling.

It's now reliably high.

 

 

0 Kudos
Reply