Has anyone else used 1 PFL for "programming flash + FPGA configuration", FFPx16 & got it to work ?

[Knug]

Having issues getting 1 PFL solution for programming flash + FPGA configuration using FFPx16

PLF within CPLD MAXV. PFL connected to CFI Flash device

FPGA to configure: Cyclone V

---

We have a separate 2 PFL solution that works, 1 PFL for flash programming and 1 PFL for FPGA configuration.

When I tried to combine both flash proframming + FPGA configuration into 1 PFL having issues with eg nConfig line being low (and looks like it holds the system in reset state) and FPGA configuration cannot kickstart.

Regards,

Kevin

[Ash_R_Intel]

Hi Kevin,

Does the board have proper pull-up resistors on Cyclone V device programming pins? Refer the Cyclone V Pin Connection Guidelines or even the Figures in Parallel Flash Loader Intel FPGA IP User Guide.

Are the simulations of the PFL IP working fine?

How about the timing closure?

What is the Quartus version that is being used?

There are some recommendations in the Parallel Flash Loader Intel FPGA IP User Guide, section 1.3.2, on whether to use 1 PFL or 2 PFL IPs.

Parallel Flash Loader Intel FPGA IP User Guide

Regards.

[Knug]

Hi @Ash_R_Intel 

Has anyone else tried the 1 PFL solution for programming flash + FPGA configuration, FFPx16  and manage to get it working?

Did not receive a reply on this matter.

--

Yes, there are 10K pull up resistors on nStatus, conf_done and nConfig pins.

The PFL User Guide I looking all the time. It is incomplete wrt 1 PFL solution. It just describes mainly the 2 separate PFL solution.

We did not carry out any simulations on the PFL. I am looking at the validated results using a signal analyser. They were no simulations carried our before in the 2 PFL separate design too.

There are no Timinig violations seen in the design. 

Using Quartus prime 20.1 Lite Edition when generating the .pof files and I was advised to use Quartus 13.1 for the programming stage. These versions of Quartus work on the 2 PFL solution.

>>There are some recommendations in the Parallel Flash Loader Intel FPGA IP User Guide, section 1.3.2, on whether to use 1 PFL or 2 PFL IPs

This is just the info listed there when it mentions 1 PFL solution :

"You can use the PFL IP core to either program the flash memory devices, configure
your FPGA, or both; however, to perform both functions, create separate PFL functions
if any of the following conditions apply to your design:
• You want to use fewer LEs.
• You modify the flash data infrequently.
• You have JTAG or In-System Programming (ISP) access to the Intel CPLD.
• You want to program the flash memory device with non-Intel FPGA data. For
example, the flash memory device contains initialization storage for an ASSP. You
can use the PFL IP core to program the flash memory device with the initialization
data and also create your own design source code to implement the read and
initialization control with the CPLD logic.

---

We have JTAG access to the intel CPLD and FPGA via the USB Blaster for the purpose of programmming/configuring the PFL code, autodetecting the flash, programming the main application code via the the flash & eventually configuring the FPGA.

Does this mean 1 PFL solution will not work and requires to be split into 2 separate PFLs ?

Regards,

Kevin

[Ash_R_Intel]

Hi Kevin,

Yes, this configuration is tested and is working on some of our development kits as well. You may refer https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-cyclone-v-gt.html

The design for MAX V on the dev kit can also be downloaded from the kit installation link.

For the issue that you are facing, please review the PFL IP settings once. Recommend you to do the simulations to make sure things are at least logically working,

If that goes well, then please check on following points:

1) MSEL pin settings for Cyclone V

2) Power rail, is the power reaching the specified levels for VCCPD and VCCPGM?

Regards.

[Knug]

Hi @Ash_R_Intel 

>> Does this mean 1 PFL solution will not work and requires to be split into 2 separate PFLs ?

>> Yes, this configuration is tested and is working on some of our development kits as well

Is this answer yes from you answering my above question ie "1 PFL solution will not work and requires to be split into 2 separate PFLs"? Are you answering yes to this question ?

---

Seen that kit before. Commented in another ticket about it. It uses many blocks inside generating slow clock etc (looks quite complicated what they try to do there and did not pursue that route because I tried connecting things as the kit did wrt generation of granted signal, pfl_nreset etc but could still not get that to work.

I also downloaded the MAXV on the dev kit but seen as stated above many blocks within it (must be doing other things which I do not require). 

Tried using the slow_clk_gen, wdt, reset_generator (generating the reset). My mode is FFP so msel chosen others in that design ie msel_reset_n = '1' that was AND'ed with the output of the wdt reset (plf_en) to connect to the pfl_nreset of the PFL.

wdt reset output was also connected to the pfl_flash_access_granted of the PFL

I did not use the 4 input AND gate to generate the reset_n (in) to the wdt. I connected directly the reset output of the reset_generator to the reset_n (in) of the wdt and the reset (in) of the slow_clk_gen 

Did not use the 3 input MUX with a flop output generating the msel_reset_n. As stated I connected directly '1' to the AND gate one input. So effectively the output reset (pfl_en) of the wdt connects directly to the pfl_flash_access_granted and pfl_nreset inputs of the PFL.

Regards,

Kevin

[Ash_R_Intel]

Sorry for confusion. I mean the 1 PFL solution is tested and is working. You can continue to use that.

Regards.

[Knug]

But it does not work for me and try to find out how to get it to work for weeks now !

[Ash_R_Intel]

Hi Kevin,

Is it possible for you to send us the design for further debug? You can reply to the email sent to you from supportreplies@intel.com dated 12th April.

Meanwhile can you please confirm that the flash_access_granted pin of the PFL IP is driven to '1' when flash_access_request is asserted.

Regards.

[Knug]

I have rectified my issue by myself. pfl_nreset had to be delayed from 0 -> 1 using a counter within my wrapper to get the FPGA to configure successfully right after flash programming. 

flash_access_granted pin of the PFL IP is driven to '1' when flash_access_request is asserted because I had flash_access_request (out) connected to flash_access_granted (in) internally within the wrapper.

[Ash_R_Intel]

Hi Kevin,

Glad to know that you were able to resolve the issue. Closing the case.

Regards.