Contributor
Regular ContributorHi,
Four our dev kit design, we just connect "pfl_flash_access_granted" to "pfl_flash_access_request" as we are just using Quartus Programmer to program the flash.
Regular ContributorAttach is the reference design
ContributorHi @JohnT_Intel
Just looked at the latest kit you sent me.
We are not using the following PFL pins :
flash_clk
flash_nadv
flash_nreset
Are you using burst mode? Burst mode requires flash_clk, flash_nadv & flash_rdy. We are not using burst mode. If you are using burst mode. How do you enable it?
Q/ Do I need to enable the flash_nreset (out) of the PFL and connect it directly to the input of the flash? Will this help resolve the issue ?
---
Noticed as you said that you just connect the pfl_flash_access_request to the pfl_flash_access_granted signal. Tried that already few times and it crashed ie flash could not be autodetected.
The pfl_nreset you just connect to the top input reset pin.
Tried this pfl_nreset option too ie connected it to the top level and pfl_flash_access_request to connected to the pfl_flash_access_granted signal. It autodetects the flash after I programmed/configured the PFL loadware and powered cycled. But then when I tried to program the Application code to the flash it failed to program it !
Q/ Do I need to enable the flash_nreset (out) of the PFL and connect it directly to the input of the flash? Will this help resolve the issue ?
ContributorHi @JohnT_Intel
Looking at the max5 kit once more you sent me last time & wondering how this worked for you if the .qsf does not list the slow_clk_gen.vhd file which it was instantiated by the max5.vhd ?
The other thing I noticed from the simpler kit was that the .qsf listed also many of other pins that the max5 top level did not listed as ports (those ports looked to belong to the complex kit one)
& also noticed that the pfl_clk is clocked by external 100MHz (clk_config) (constraints file defined 10ns) compared to the clkin_max_50 (50MHz) main input clk.
I just have 1 clock input to the PFL and it is set to 10MHz. Does the pfl_clk need to be overclocked?
The 2 separate PFLs worked with the 10MHz main clock.
--
Also I noticed that the slow_clk_gen module not all outputs are used :
Warning (10036): *** object "clk_pls_n" assigned a value but never read
Warning (10036): *** object "clk_pls_p_deley" assigned a value but never read
Warning (10036): *** object "slow_clk" assigned a value but never read
Just the clk_pls_p one !
----
& after I run the above similar to what kit was doing (included the slow_clk_gen module & kept my 1 clk @ 10MHz), it was worse than before ie it failed to program the flash "Can't recognize silicon ID for Device 1. Operation Failed"
Regards,
Kevin
ContributorHi @JohnT_Intel
Very puzzled still trying to figure out why the 2 separate PFL solution works compared to the 1 PFL combined one.
In the 2 separate PFLs, the 1st PFL just declares Flash programming option so all the FPGA pins (fpga_nconfig, fpga_nstatus, fpga_conf_done etc) after looking at the pin list were declared as "RESERVED_INPUT_WITH_WEAK_PULLUP" because there was no top level pin connections to the FPGA at that stage compared to the other PFL which declared those pins.
When I run the 2 separate PFL case : When I specifically run the 1st stage ie the PFL for just flash programming then I see eg fpga_nconfig pin staying high here as expected & this could be due to the RESERVED_INPUT_WITH_WEAK_PULLUP declaration to that pin. The other 2 pins fpga_nstatus, fpga_conf_done which were also declared as RESERVED_INPUT_WITH_WEAK_PULLUP were high at this stage before and after running the loader.pof code (PFL 1 for just flash programming).
On the other hand my 1 PFL combined solution I see at this stage of the test fpga_nconfig pin held low ! 1 PFL solution had all flash programming and FPGA configuration pins connected to the top level (as you know). I just loaded the PFL generated .pof file to program/configure it at this stage before even -> "autodetecting the flash to program it with the main application code and then configure the FPGA"
Any comments here will be appreciated.
Regards,
Kevin
