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:
Top level schematic
Basically, the 100 MHz, single-ended clock comes in, is routed through a Clock_Control module (we didnt have this at first, so weve tried with and without). From there its 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 theres 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.
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.
Clock_out
The second clock, clock_out1, is half the frequency of the first clock, and while it should be 50 MHz, its actually 9.1 KHz, this is still about half of clock_outs 18.3 KHz, so the division factor is at least partially working.
Clock_out1
Obviously the PLL doesnt 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 isnt. Weve tried about a million trouble-shooting steps but are completely baffled. We dont understand why the same project can work on the Eval board but not on ours. We dont think that its a hardware problem as all of our firmware works great, the only thing that doesnt 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