How to handle properly pfl_flash_access_granted & pfl_flash_access_request signals ?

[Knug]

Hi @YuanLi_S_Intel 

How to handle properly pfl_flash_access_granted & pfl_flash_access_request signals if PFL uses both Flash Programming + FPGA Configuration mode

Looked at the PFL doc :

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf

Seen in the pin list what it describes BUT cannot get CFI_1Gb flash to be detected to perform flash programming of the generated .pof (when I combined the 2 flash programming + fpga configuration & generated just one module) within CPLD MAX V.

Seen the following message on the JTAG programmer screen:

"Waiting for pfl_flash_access_granted to be asserted"

Before we had separate loader (for flash programming) & separate config module (for FPGA configuration FPPx16) (MConfig module was a VHDL wrapper instantiating the loader_pfl) generated within the CPLD (that worked ok ie was programming the flash with the loader .pof & then autodetecting the flash & then FPGA configuration of the application code was successful) but after I combined the 2 functionalities (flash programming + FPGA configuration using FPPx16) into 1 module & tried to use same internal logic controlling the pfl_flash_access_granted & pfl_flash_access_request signals as was done for the Mconfig standalone module had problems autodetecting the flash.

The issue autodetecting the flash has to do with the controlling correctly the pfl_flash_access_granted & pfl_flash_access_request  signals.

The logic that was implemented within MConfig and re-used in the 1 module (when combining the Flash Programming & FPGA Configuration together in 1 module) was:

pfl_flash_acess_request output of the loader_config_pfl was connected internally within the Loader_MConfig wrapper as follows :

pfl_flash_access_granted <= pfl_flash_access_request AND (not fpga_conf_done);

It was actually connected like this within the component instantiation :

::::

signal r_fl_access_req : std_logic;
signal r_config_done : std_logic := '0';

::::

pfl_inst : component config_pfl
port map (
flash_addr => flash_addr,
flash_data => flash_data,
flash_nce => flash_nce,
flash_noe => flash_noe,
flash_nwe => flash_nwe,
fpga_conf_done => fpga_conf_done,
fpga_data => fpga_data,
fpga_dclk => fpga_dclk,
fpga_nconfig => fpga_nconfig,
fpga_nstatus => fpga_nstatus,
fpga_pgm => fpga_pgm,
pfl_clk => in_clk,
pfl_flash_access_granted => r_fl_access_req and (not fpga_conf_done),
pfl_flash_access_request => r_fl_access_req,
pfl_nreset => (not r_config_done)
);

----

If I connect directly the pfl_flash_access_request output signal to the input pfl_flash_access_granted of the pfl within the  Loader_MConfig wrapper, I see that I can autodetect the flash after I load the loadware code and do a power cycle BUT it fails to program the loaded application code !

----

I read in the above pfl doc pg13 the following :

"When programming the configuration flash memory device through the CPLD JTAG pins, you must tri-state the FPGA configuration pins common to the CPLD and the configuration flash memory device.
You can use the pfl_flash_access_request and pfl_flash_access_granted signals of the PFL block to tri-state the correct FPGA configuration pins"

pfl_flash_access_granted signal (wrt PFL IP core doc) it states that it enables the access to the flash memory device whenever the PFL IP core receives a high input signal at this pin. This active high pin can be connected permanedly high if we want PFL Core to function as the Flash Master. Pulling the  pfl_flash_access_granted pin low prevents the JTAG interface from accessing the flash and FPGA configuration.

Q/ Is it ok to connect pfl_flash_access_granted input pfl to '1' and leave the pfl_flash_access_request output unconnected?

When I did this & compiled the code, I had the following extra warnings :

Warning (13044): Always-enabled tri-state buffer(s) removed
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[0]" to the node "flash_addr[0]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[1]" to the node "flash_addr[1]" into a wire
:::
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[23]" to the node "flash_addr[23]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[24]" to the node "flash_addr[24]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_addr[25]" to the node "flash_addr[25]" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_nce" to the node "flash_nce" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_noe" to the node "flash_noe" into a wire
Warning (13045): Converted the fanout from the always-enabled tri-state buffer "loader_config_pfl:pfl_inst|altera_parallel_flash_loader:parallel_flash_loader_0|altparallel_flash_loader:altparallel_flash_loader_component|alt_pfl:\PFL_CFI:pfl_cfi_inst|flash_nwe" to the node "flash_nwe" into a wire

I did not attempt to try this on the bench yet. Asking whether it is ok to try this but seen above (13045) warning Converted the fanout from the always-enabled tri-state buffer to a wire !!

Any help on this matter will be appreciated

Regards,

Kevin

[JohnT_Intel]

Attach is the reference design

[Knug]

Hi @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 ?

[Knug]

Hi @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

[Knug]

Hi @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

[Knug]

Hi @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 :

• Info (209018): Device 1 silicon ID is not ready - waiting for pfl_flash_access_granted to be asserted
• Error (209064): Failed to get access to the flash interface
• Error (209012): Operation failed

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

[JohnT_Intel]

Hi,

The pin can disable when you select the setting of your PFL. I would recommend you to connect the flash nreset pin so that you are able to reset the flash to make sure that it is go into known state.

[Knug]

Hi @JohnT_Intel 

I also connected this morning the flash_nreset pin (output from the PFL) input to the flash. After programming/configuring the loadware PFL, flash was detected after power cycle & autodetect BUT I could NOT program the application code loaded into the flash. It failed to run !

Programmer reported the following :

209025  Can't recognize silicon ID for Device 1

209012 Operation failed

Power cycled the whole system & tried this test again & it failed with the same error as above.

[Knug]

Hi @JohnT_Intel 

------------------------------------------------------------------
-- Programming flash ok But FPGA Configuration NOT ok
------------------------------------------------------------------
pfl_flash_access_request connected directly to pfl_flash_access_granted

During flash programming both  pfl_flash_access_request and pfl_flash_access_granted are high

During FPGA Configuration (ie right after Flash programming) pfl_flash_access_request is '0' and thus  pfl_flash_access_request is low too and don't see them going back high ! 

Doesn't the PFL drive pfl_flash_access_request pin back high also when the PFL configures the FPGA right after successful flash programming?

fpga_conf_done is '1' during flash programming and stays at '1'. That should go '0' to kickstart FPGA Configuration after successful flash programming but it stays high !

fpga_nconfig is '0' during flash programming and stays '0'

fpga_nstatus is '1'  during flash programming and stays at '1'

pfl_nreset is '1'  during flash programming and stays at '1'

[JohnT_Intel]

Hi,

May I know how do you generate the POF file to program into the flash? Do you set the MSEL correctly on the FPGA?

May I know what is the status of the nStatus, nConfig and CONF_DONE after power cycle?

[Knug]

Hi @JohnT_Intel 

>> May I know how do you generate the POF file to program into the flash? Do you set the MSEL correctly on the FPGA?

Our MSEL(4:0) is set to '00100' on the board by switches for FPP Configuration scheme

Using Convert Programming File to generate the .pof file

     Specify Configuration Device: CFI_1Gb   / Mode: Passive Parallel x16

     Specify same application  code .sof at different page valid start addresses : Page 0, Page 1 & Page 2

     .pof file was successfully generated & .map file generated was :

      BLOCK               START ADDRESS                END ADDRESS

      Page_0              0x00020000                       0x0043241B
      Page_1              0x00440000                       0x0085241B
      Page_2              0x00860000                       0x00C7241B
      OPTION BITS   0x00000000                      0x00000080

>> May I know what is the status of the nStatus, nConfig and CONF_DONE after power cycle?

After changing our loadware file to our combined Loader_MConfig.pof Program/Configure it and then Power cycle before Autodetecting the flash device the status of the above signals were :

    nStatus : '1'

    CONF_DONE : '1'

    nConfig : '0'

Q/  Are there readings what you expect to see right after power cycle ?

nConfig ?  Is that correct ?

Does CONF_DONE need to be held '1' during flash programming and then go back low during FPGA configuration and when FPGA Configuration is completed it should go back high?

& why pfl_flash_access_request pin does not go back high also for the PFL to configure the FPGA right after successful flash programming?   I do not have control to this pin (it's output of the PFL)

& why during the flash programming stage if I select for the CFI_1Gb flash device just the page I want to program out of the 3 (note: the loadware code I programmed/configured earlier before power cycling specified that particular page), it erases all the contents of the flash first (expect this) BUT then it programs the entire flash and not just the specific sectors of the page I ticked on the programmer ie  just ticked on the <appl_file>.pof, one of the pages and the OPTION_BITS (ie the other 2 pages are unticked). Is this behaviour expected here compared to if my application .pof file just specifies 1 page?

[JohnT_Intel]

Hi,

I have concern on the nConfig and CONF_DONE pin.

The nConfig should be released except that something is driving this low. Do you have osciloscope to scope this signal?

The CONF_DONE will only be released to high by FPGA when the configuration is completed. If the nConfig is low then the CONF_DONE shouldn't be high.

[Knug]

Hi @JohnT_Intel 

Yes, I am using a logic Analyser scoping nConfig + CONF_DONE & nStatus.

Those readings I supplied were before even autodetecting the flash and loading the application code to check if FPGA is configured. You just asked me for the status of those signals after power cycle & I supplied them to you.

Why did you state that "if the nConfig is low then the CONF_DONE shouldn't be high"  at that stage?

Wrt page 1:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cfg/cfg_cf51001.pdf

At the beginning before configuration starts (ref. Fig1) nConfig is low, CONF_DONE is high & nStatus is high so it looks like we are at that stage. I'm I not correct to state this ?

----

I carried on autodetecting the flash & then loading the application code.

In the latest run, I noticed CONF_DONE being low, nStatus being high and nCONFIG low

Configuration somehow kickstarted because noticed DCLK pulsing and CONF_DONE went high at the end of the configuration cycle BUT nConfig was low throughout this time. Application code was not running (ie FPGA configuration not fully working).

So, yes nConfig could be the issue during the Configuration phase. Expected that pin to be high. Please confirm here.

Regards,

Kevin

[Knug]

Hi @JohnT_Intel 

After looking into the 'loader', 'Mconfig' separate PFLs within CPLD noticed at the beginning when loading / programming/configuring the 'loader' code, there is no FPGA_nconfig, FPGA_conf_done, FPGA_conf_done signals used here (note: these pins were declared later at the 'Config' PFL). Pin list of the 'loader' listed those pins as “Reserved input with a weak pull-up”. So during this stage eg pin A4 (which is used later in the 'Config' module as FPGA_nconfig) was listed for the loader as “Reserved input with a weak pull-up”, so this looks the reason why pin A4 is high at this stage (as expected due to the reserved weak pull-up resistor).

In my case with the combined PFL Loader_MConfig, pin A4 is set to FPGA_nconfig from the start BUT since there is no pull-up resistor present on the board to the FPGA_nconfig line this line cannot go high right after reset to begin the configuration cycle. And thus since FPGA_nconfig is low, the device is held in reset.  Isn't this the case? Please confirm

Note: 

-> FPGA_nconfig is output of the PFL module, so I do not have direct control access to this

-> nStatus & conf_done noticed pull-up resistors in place but not on the FPGA_nconfig line.

Regards,

Kevin

[JohnT_Intel]

Hi,

At the beginning before configuration starts (ref. Fig1) nConfig is low, CONF_DONE is high & nStatus is high so it looks like we are at that stage. I'm I not correct to state this ?

This is not correct as if the nConfig is low then the CONF_DONE will be also be reset with the maximum delay of 600ns. You may refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_51002.pdf Table 18.

The nConfig pin of the FPGA is a input pin where it will need to be pull-high and if external component is driving it low then it will go into reset state.

You may refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_5v2.pdf "Figure 7-1: Configuration Sequence for Cyclone V Devices"

[Knug]

Hi @JohnT_Intel 

>>This is not correct as if the nConfig is low then the CONF_DONE will be also be >>reset with the maximum delay of 600ns. You may refer >>to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature>>/hb/cyclone-v/cv_51002.pdf Table 18.

Table 18 in the above link has no relation on what we are talking about. Which Table 18 you mean? or do you mean Table 58?'

----

A better state Configuration cycle state machine I was looking at yesterday is at :

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cfg/cfg_cf51001.pdf - Fig2

After power up, the FPGA should hold FPGA_nStatus low for the time of the POR delay.

After power up, before and during configuration, open drain FPGA_conf_done should be low

When the device comes out of reset, FPGA_nConfig must be at logic high level in order to release the open-drain FPGA_nStatus pin. Cyclone FPGA should sense the low-to-high transition on FPGA_nconfig to initiate configuration. After FPGA_nStatus is released, it should be pulled high by a pull-up resistor and the FPGA will be ready to receive Configuration data. To begin configuration, FPGA_nconfig & FPGA_nStatus must be at a logic high level and kickstart configuration. The device should then receive configuration data on it’s DATA0 pins.

Isn't this the case?

>> The nConfig pin of the FPGA is a input pin where it will need to be pull-high and if >> external component is driving it low then it will go into reset state.

The nConfig is an output of the PFL module and I do not control it within the CPLD (as stated before).  BUT if an external pull-up resistor is not present on the nConfig pin, it will not drive it back high right after reset. Isn't this the case?

[Knug]

One thing which I will report to my team is the nconfig could be missing the pull-up resistor.

---

I just run again the combined PFL Loader_MConfig. Noticed just if I load program/configure the Loader_MConfig.pof file (this is before power cycle to autodetect the flash and then run the application code to configure the FPGA once the flash is detected)

Conf_done was high then it went low. pfl_flash_access_request and pfl_flash_access_granted went low from high and after around 28uS later nConfig went low and stayed low.  pfl_flash_access_request and pfl_flash_access_granted stayed low for about 66.18uS and then went back high. fpga_dclk then started clocking. 

fpga_conf_done was low for 641.191mS and then it went back high. fpga_dclk was pulsing during the time the conf_done was low.

--

This looks like it tried to configure the FPGA during this time ! I was not expecting this at this stage. Please comment here ..

FPGA configuration should happen after power cycling / autodetecting the flash and then loading the application code for flash erase the flash programming and then FPGA configuration at the end.

---

I tried re-running the same above ie just loading programming/configuring the combined Loader_MConfig.pof file (this is again before power cycle to autodetect the flash and then run the application code to configure the FPGA once the flash is detected).

Results were now different than the ones reported above.

conf_done and nstatus remained high.

fpga_nconfig went low and fpga_dclk went low from high and both stayed low

pfl_flash_access_request and pfl_flash_access_granted went both low before fpga_nconfig went low.

This is the state I had before and suspected fpga_nconfig staying low (held in reset state). 

With this test (2nd try), managed to autodetect the flash ok after power cycle but fpga_nconfig stayed low and conf_done and nstatus stayed high here.

Decided not to load/program the application code because I know it will not configure the FPGA after successful flash programming.. 

[JohnT_Intel]

Hi,

I would recommend that you connect the nConfig to weak-pull high before we proceed as this will help on avoiding the device from getting reset.

[Knug]

Hi @JohnT_Intel 

I raised this concern about the pull-up resistor to the FPGA_nconfig line.

However, my colleague came back to tell me that there was a hardware mod on the board adding a pull-up resistor to the FPGA_nconfig line. 

I would not have been able to spot that that pull-up resistor modification was connected to the FPGA_nconfig line. My board has a DALE 1441 type (questioned to whether this a 1.44Kohm resistor? or 1441 means something else?) 

Instructions they listed specified a 10K pull-up resistor and a 10K is the recommended value your link doc (listed within this ticket) suggested

Does it make a difference to the value of the pull-up? The larger the value the weaker it is. Isn't this the case?  or should I attempt to change this to a 10k value one?

You suggested connecting the nConfig to a weak-pull high as this will help on avoiding the device from getting reset. The 1.44K resistor is a stronger pull-up. Will this be the reason of the issue seen ? Do I need to change it to a 10K one (ie weaker pull-up) ?

[Knug]

Another meeting I had, my colleague confirmed that the DALE 1441 resistor (same one on his board) is a 10K one. When he unsoldered the resistor on one end he measured it as 10K and he said it was written 10K at the bottom of the resistor which I could not see whilst the resistor is soldered on the board. So FPGA_nconfig looks to have a 10K pull up resistor to 3V3

What is the problem then?? Why the FPGA cannot be configured? What causes the FPGA_nconfig stay low?

[JohnT_Intel]

Hi,

May I know if the nConfig is only connected to CPLD or it is connected to other host as well? The reason is that something is driving the nConfig low which cause the issue. We will need to figure out where it is driving from.

[Knug]

Hi @JohnT_Intel 

nConfig is an output from the CPLD and it is connected directly to the FPGA nConfig pin (input) and has a 10K pull up resistor.

It may be trying to do FPGA configuration at the start and puts nConfig line low together with Conf done (nStatus remaining high) and fails doing it (will be re-checking this) when I try to configure/program the PFL before even autodetecting the flash to program/configure it with the FPGA application code and thus when I reach that stage nConfig line is still held low !