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

MAX10 PLL Not Locking - KHz instead of MHz

Altera_Forum
Honored Contributor II
1,440 Views

Greetings, 

 

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: 

https://drive.google.com/uc?export=view&id=13A_hCZJdZGYNhppojQw68tv9dExJKYhx  

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.  

https://drive.google.com/uc?export=view&id=1c8tMkP-BcDfqBxP33H6u9UZU_1mUT8as  

 

mclk_out 

 

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. 

https://drive.google.com/uc?export=view&id=1NDzuszcu430PbqMr6cgBtNMUAar1XCy8  

 

clock_out 

 

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. 

https://drive.google.com/uc?export=view&id=1knn8ptuptx7wc5nfggajsdxrobyh8nvd  

 

clock_out1 

 

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}] 

derive_pll_clocks 

derive_clock_uncertainty 

 

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
Altera_Forum
Honored Contributor II
321 Views

Hi, 

 

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

https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/support/devices/pll/pll-loss-of-lock-checklist.pdf 

 

Thanks. 

 

Regards, 

spdl2001 

(This message was posted on behalf of Intel Corporation)
0 Kudos
Altera_Forum
Honored Contributor II
321 Views

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.
0 Kudos
Reply