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

Cyclone 10 LP PLL frequency far too low

sambesse
Beginner
1,303 Views

Hello,

I am working on a Cyclone 10 lp problem using an internal PLL. 

sambesse_0-1720815111339.png

sambesse_1-1720815138949.png

I'm using the above AHDL code to configure it. The expected output is 245Mhz, since it's a 30.72MHz input and a multiplier of 8.  I have checked the synthesized code and everything is routing correctly. When I put the clock on a test point though I find that it's around 762kHz. Are there some incorrect parameters that may be impacting the frequency? 

Labels (2)
0 Kudos
1 Solution
FvM
Honored Contributor II
1,125 Views
Hi,
the small differences is frequency are obvious, you should be able to provide consistent values. However none of the quoted warnings is related to a fundamental problem that would prevent PLL function.

Some questions.
What's the reference clock source?
Is it a known working development board or custom design? In the latter case, are you sure that all hardware requirements, e.g. connection of PLL supply pins are met?

View solution in original post

0 Kudos
7 Replies
FvM
Honored Contributor II
1,242 Views

Hi,
PLL parameters looks right. If you are not familiar with PLL setup, you can also implement altpll from IP catalog.
I would probably add locked output to monitor correct PLL operation.

Most likely reason to ge a very low output frequency is that PLL gets no valid input clock, either wrong pin connected or inappropriate logic level.

0 Kudos
sambesse
Beginner
1,190 Views

Hi, 

I have checked the connections and the input clock is connected. I have routed the input clock and output to a test point and observed them on the scope. If that clock is valid, I'm not sure. Which parameter would I use to add locked output to the PLL? What do you mean by inappropriate logic level and how could I check for that? 

 

Thank you

0 Kudos
FvM
Honored Contributor II
1,182 Views

Hi,
specify PORT_LOCKED = "PORT_USED" and connect PLL245.locked respectively.

You can also route C30MHz to an output pin and check if it looks correct.

0 Kudos
sambesse
Beginner
1,145 Views

Hi, 

I have done both of these. The PLL.locked signal is always low after the code upload is complete. The C30MHz looks exactly as expected. 

 

I noticed these warnings: 

 

Warning (332070): Port "PhiPLL" relative to the rising edge of clock "C30MHz" does not specify a max-fall output delay

Warning (332070): Port "PhiPLL" relative to the rising edge of clock "C30MHz" does not specify a max-rise output delay

Warning (332056): PLL cross checking found inconsistent PLL clock settings:

                Warning (332056): Clock: PLL245MHz|auto_generated|pll1|clk[0] with master clock period: 32.550 found on PLL node: PLL245MHz|auto_generated|pll1|clk[0] does not match the master clock period requirement: 32.553

 

Critical Warning (332168): The following clock transfers have no clock uncertainty assignment. For more accurate results, apply clock uncertainty assignments or use the derive_clock_uncertainty command.

                Critical Warning (332169): From PLL245MHz|auto_generated|pll1|clk[0] (Rise) to C30MHz (Rise) (setup and hold)

                Critical Warning (332169): From PLL245MHz|auto_generated|pll1|clk[0] (Fall) to C30MHz (Rise) (setup and hold)

                Critical Warning (332169): From PLL245MHz|auto_generated|pll1|clk[0] (Rise) to PLL245MHz|auto_generated|pll1|clk[0] (Rise) (setup and hold)

 

I'm not sure what they mean, but it seems that they are not errors that should cause the PLL to break. The Warning about the master clock period seems like it is related to the "INCLK0_INPUT_FREQUENCY" field, but I don't understand that field.

0 Kudos
FvM
Honored Contributor II
1,126 Views
Hi,
the small differences is frequency are obvious, you should be able to provide consistent values. However none of the quoted warnings is related to a fundamental problem that would prevent PLL function.

Some questions.
What's the reference clock source?
Is it a known working development board or custom design? In the latter case, are you sure that all hardware requirements, e.g. connection of PLL supply pins are met?
0 Kudos
sambesse
Beginner
1,079 Views

Hi,

We have found that the problem stemmed from a manufacturing error in our design that caused the PLL to not be properly powered. Thank you for your help finding this

0 Kudos
AqidAyman_Intel
Employee
1,048 Views

I’m glad that your question has been addressed. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


0 Kudos
Reply