MAX10 PLL Not Locking - KHz instead of MHz

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