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

[Knug]

Hi @JohnT_Intel ,

Stuck with this issue and cannot find the solution.

With the combined PFL solution, PFL logic in CPLD should determine when to start Configuration process, read the data from the flash & program it and then later configure the FPGA in FPP configuration scheme.

Need correct signal control access during these stages. 

conf_done, nstatus, nconfig, pfl_flash_access_granted, pfl_flash_access_request, pfl_nreset, flash_nreset

PFL combined solution documentation is NOT available. The only thing it documents is when creating 2 different PFLs, one for flash programming and one for FPGA configuration.

I'm I not right to say that conf_done should be all the time high and when Configuration kickstarts it should go low and nConfig line should be high (nStatus line high too).

nConfig stayed low?? that kept conf_done low too & tried kickstarting FPGA configuration at the end after flash programming (noticed DCLK pulsing until conf_done gone back high) and conf_done went back high at the end but the annoyed nConfig line kept being low !

[Knug]

Hi @JohnT_Intel 

Wrt your reply which I got from a different ticket :

>> Hi,

>>May I know if you are able to try to find out who is pulling the nConfig low? Is it coming from the CPLD?

>>I don't think that the PFL will pull the nConfig low without releasing it.

>>The FPGA is only using the nConfig pin as input pin and there is no way it is driving it low.

Yes, I am wondering who is pulling the nConfig pin low ?

nConfig is an output of the PFL. CPLD instantiates the PFL. It's output is directly connected to the input FPGA_nconfig pin of  the FPGA and it has a pull up resistor of 10K to 3v3

Why the PFL is driving the pin low then ? It makes it look like it is held in reset state and cannot get out of that state to kickstart the FPGA configuration process at the right time

[JohnT_Intel]

Hi,

May I know if you are able to try to find out who is pulling the nConfig low? Is it coming from the CPLD? I don't think that the PFL will pull the nConfig low without releasing it.

The FPGA is only using the nConfig pin as input pin and there is no way it is driving it low.

[JohnT_Intel]

Hi Kevin,

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.

I suspect that the PFL is performing something that cause the system will fail to configure the FPGA. Will need to monitor all the signal to understand what is actually happening.