- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page