Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
18957 Discussions

MAX10 PLL Not Locking - KHz instead of MHz

Honored Contributor II



We're using the 10M16DAF256I7G FPGA from the Max10 family. We're designing the firmware in VHDL and using Quartus to connect the blocks via schematics. 99% of our firmware is working perfeclty, but none of the internal PLLs are working, no matter what we try. We are comparing our results using the ARROW DECA Evalkit with a 10M50DAF484 FPGA, whose PLLs are working just fine. 


To simplify the troubleshooting process, I created a barebones Quartus project and just added a few things as seen here:  

top level schematic  

Basically, the 100 MHz, single-ended clock comes in, is routed through a Clock_Control module (we didn’t have this at first, so we’ve tried with and without). From there it’s routed to the input of the PLL and to a debug pin for measurement. There are 3 outputs of the PLL, one that should have no division, so 100 MHz, one that should have a division of 2, so 50 MHz and one that signifies the PLL is locked (high = locked). Further there’s a single pin tied high to turn on the 100 MHz oscillator (master clock). 


It seems as though we never achieve a lock, and the output frequencies are WILDLY off. Here is the mclk_out measured showing 100 MHz. It looks exactly like the input waveform.  




Now for the first clock output, clock_out, which should be 100 MHz but is actually 18.29 KHz (this drifts). Interestingly even without a lock changing the Duty Cycle of the PLL works.  




The second clock, clock_out1, is half the frequency of the first clock, and while it should be 50 MHz, it’s actually 9.1 KHz, this is still about half of clock_out’s 18.3 KHz, so the division factor is at least partially working.  




Obviously the PLL doesn’t have a lock and is thus pll_locked pin is low. 


This exact project works just fine when put on the Arrow DECA Evalkit with a 10M50DAF484 FPGA, I just changed the device to synthesize for and adapted the .SDC file for the 50 MHz clock on the Arrow board instead of our 100 MHz clock. On the eval board the PLL works fine, outputting 50 and 25 MHz clocks (divison factor 1:1 and 1:2) and the PLL lock pin is high.  


Further, in the Processing window of Quartus the following messages were generated during synthesis and fitting:  


Info (332110): Deriving PLL clocks 

Info (332110): create_generated_clock -source {inst|altpll_component|auto_generated|pll1|inclk[0]} -duty_cycle 50.00 -name {inst|altpll_component|auto_generated|pll1|clk[0]} {inst|altpll_component|auto_generated|pll1|clk[0]} 

Info (332110): create_generated_clock -source {inst|altpll_component|auto_generated|pll1|inclk[0]} -divide_by 2 -duty_cycle 50.00 -name {inst|altpll_component|auto_generated|pll1|clk[1]} {inst|altpll_component|auto_generated|pll1|clk[1]} 


Info (332111): Found 4 clocks 

Info (332111): Period Clock Name 

Info (332111): ======== ============ 

Info (332111): 100.000 altera_reserved_tck 

Info (332111): 10.000 inst|altpll_component|auto_generated|pll1|clk[0] 

Info (332111): 20.000 inst|altpll_component|auto_generated|pll1|clk[1] 

Info (332111): 10.000 master_clock 


Our .SDC file looks like this: 


create_clock -name master_clock -period 10.000 -waveform { 0.000 

5.000 } [get_ports { master_clock}] 




So it seems that Quartus is recognizing that it is generating two PLL outputs with the proper periods, but in reality it isn’t. We’ve tried about a million trouble-shooting steps but are completely baffled. We don’t understand why the same project can work on the Eval board but not on ours. We don’t think that it’s a hardware problem as all of our firmware works great, the only thing that doesn’t work are the PLL blocks and both boards have similar, single-ended clocks.  


We appreciate any help you can provide us. Thanks in advance. 


- wblee 




0 Kudos
2 Replies
Honored Contributor II



I would recommend to go through below PLL loose lock debug checklist 






(This message was posted on behalf of Intel Corporation)
Honored Contributor II

Try connecting the input clock directly to the PLL's (adc_pll) inclock port , plus I don't see the reset as input to the PLL block. If you're not using the 'areset' pin, then enable the following option  


- Enable self-reset on loss lock 


This will reset the PLL internally when it looses a lock and thus force it to regain lock again. Although I'd suggest you use the 'areset' pin and drive it from the system reset or POR from your board.  


The PLL may not be acquiring proper lock when its internal registers/FFs are not reset properly to a known state. The internal blocks in the PLL (PFD, NCO/VCO, etc) may need to be reset at the start, for it to capture and follow the incoming clock and get a lock on it.