Contributor
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
ContributorHi @JohnT_Intel
Finally I believe I found the issue that was bothering me and managed to rectify it by myself !
pfl_nreset needs to be delayed low ie '0' within the 1 pfl solution wrapper code. I added a counter that counted up to eg 2000000000 COUNTER_MAX1 value and then set the pfl_nreset to '1'. Still using just 1 main clk @10MHz.
So after programming/configuring the loadware PFL code, autodetecting the flash and program/configure the application code, pfl_nreset at this stage is kept low and then sometime during the erase period of the flash, pfl_nreset goes high preparing it to configure the FPGA right after successful flash programming. And after programming/configuring just the loadware nconfig went low and stayed low. This was not the main issue I had. It was the pfl_nreset issue described above.
Nowhere within the PFL documentation mentions this detail wrt having to delay pfl_nreset low wrt 1 PFL combined solution.
If we do not do this (ie not delay pfl_nreset low), FPGA configuration tries to kickstart at the wrong time after programming/configuring the loadware PFL code before even attempting to 'power cycle / autodetect the flash' and before even trying to program/execute the main application code'. Noticed here that DCLK started pulsing (for the duration when CONF_DONE was low), because CONF_DONE went low and nConfig went low too and stayed low, nStatus was high all the time. This is when pfl_nreset was kept high at that time without being delayed low.
However, case1-> if wait a while and pass the stage when the pfl_nreset goes '1'. After autodetecting the flash and trying to program/configure it with the latest application code. This is where it fails, with the following :
and it looks like the same failure I had before and it could not recover from this.
--
Planning to run many tests tomorrow to see the results. So far it did not fail and managed to configure the FPGA successfully apart from case1 above.
--
What are your views wrt the counter I added ?
If the user does not program the flash and delays this passing the time when pfl_nreset goes back high, the system will fail to configure the FPGA.
Regards,
Kevin
