FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

How to handle properly pfl_flash_access_granted & pfl_flash_access_request signals ?

Knug
Beginner
2,417 Views

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

 

 

0 Kudos
45 Replies
Knug
Beginner
1,274 Views

Hi @YuanLi_S_Intel 

I defined pfl_flash_access_granted as constant level '1' and connected the pfl_flash_access_request output to a top level pin. Flash was autodetected ok BUT I could not get it to program it with the loadware.

Can anyone please assist to how to control the handshaking signals pfl_flash_access_granted and pfl_flash_access_request to achieve flash programming and then FPGA configuration using this one PFL (flash programming and FPGA configuration, FFPx16) within CPLD MAX V?

FPGA using is Cyclone V

--

Like to know the pfl_flash_access_granted and pfl_flash_access_request signal handshaking activity during loadware program/configure, autodetection of Flash & flash programming stage

Like to also know the pfl_flash_access_granted and pfl_flash_access_request signal handshaking activity during the FPGA Configuration stage

 

0 Kudos
JohnT_Intel
Employee
1,266 Views

Hi,


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

Yes but this will make that the PFL flash as master and other IP no longer able to interface with the flash.


The pfl_flash_access_granted is used for system-level synchronization. This pin is driven by a processor or any arbitrator that controls access to the flash. This active-high pin is connected permanently high if you want the PFL IP 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.


pfl_flash_access_request is used for system-level synchronization. When necessary, this pin connects to a processor or an arbitrator. The PFL IP core drives this pin high when the JTAG interface accesses the flash or the PFL IP core configures the FPGA. This output pin works in conjunction with the flash_noe and flash_nwe pins


May I know if the flash is connected to both CPLD and FPGA? If yes, do you release the connection from the FPGA where the pin is tri-stated? The reason is that if both is connected to the flash and you do not tri-state the pin on 1 of the device where it will cause contention and you will not be able to communicate with the flash correctly.


0 Kudos
Knug
Beginner
1,259 Views

Hi @JohnT_Intel 

I will ignore setting pfl_flash_access_granted input pfl to '1' 

I have seen already the definitions of the pfl_flash_access_granted & pfl_flash_access_request within the PFL IP user doc.

>>May I know if the flash is connected to both CPLD and FPGA? If yes, do you release the connection from the FPGA where the pin is tri-stated? The reason is that if both is connected to the flash and you do not tri-state the pin on 1 of the device where it will cause contention and you will not be able to communicate with the flash correctly.

Flash looks to have connections to both FPGA and CPLD. 

How do you release the connection from the FPGA where the pin is tri-stated?

I've already ticked the box "Set flash bus pins to tri-state when not in use" when I parameterised the PFL Intel FPGA IP under the General drop own menu.

Did not tick the box "Allow user to control the flash_nreset pin" ie no reset pin to reset the flash directly. This box was unticked in the options when the loader (flash programming only) and MConfig (FPGA configuration) PFLs were created separately before. So I left it unticked too. 

The document at pg 36 stated the following "The Set bus pins to tri-state when not in use option for the PFL IP core disables
the PFL IP core whenever the pfl_flash_access_granted pin is pulled low". I ticked that box option as stated above.

PFL FPGA IP User guide stated 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"

This is why I was looking on how to control properly the pfl_flash_access_request and pfl_flash_access_granted signals. pfl_flash_access_request is an output and pfl_flash_access_granted is an input to the PFL

Seen many programmer warning messages: "Waiting for pfl_flash_access_granted to be asserted" and then noticed it then failed to get access to the flash interface as follows :

 

209018   Device 1 silicon ID is not ready - waiting for pfl_flash_access_granted to be asserted

209018   Device 1 silicon ID is not ready - waiting for pfl_flash_access_granted to be asserted

:::::

209064   Failed to get access to the flash interface

 

Regards,

Kevin

0 Kudos
Knug
Beginner
1,249 Views

Any reply to this will be appreciated because I am not able to get it to work reliably every time.

I also got rid of the logic that was controlling the  pfl_flash_access_granted & pfl_flash_access_request and propagated these signal to the top-level of the PFL IP as they were before in the standalone loader pfl (loader was used before for purely flash programming) BUT seen similar behaviour. May have got it to work once out of multiple tests.

Most of the tests I did failed to start the flash programming (erase followed by programming stages).

What else could be going wrong?

0 Kudos
Knug
Beginner
1,234 Views

Hi @JohnT_Intel ,

Has the combined 'flash programming and FPGA configuration' PFL into one module (not separate) been tried out by anyone yet? 

The PFL User guide mentions splitting the 2 ie creating a separate PFL for flash programming a a separate one for FPGA Configuration.

Page 12 of the doc :

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

"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

::: "

We had that flow going. Our aim now is to create one PFL that includes "Flash Programming and FPGA Configuration" together as the operating mode and not 2 separate PFLs.  Is this feasible to do?

Pg 42 defines pfl_flash access_request as :

"The PFL IP core drives this pin high when the JTAG interface accesses the flash or the PFL IP core configures the FPGA. This output pin works in conjunction with the flash_noe and flash_nwe pins"

When it states "This output pin works in conjunction with the flash_noe and flash_nwe pins" do we get automatically flash_noe and flash_nwe going low when pfl_flash_access_request output of the PFL goes high?

& pfl_flash_access_granted as :

".... Pulling the pfl_flash_access_granted pin low prevents the JTAG interface from accessing the flash and FPGA configuration"

 

Could I then AND the output of the pfl_flash_access_request with the (not flash_noe) AND (not flash_nwe) AND (not fpga_nconfig) and connect the output internally to the PFL wrapper to pfl_flash_access_granted as follows :

pfl_flash_access_granted <= pfl_flash_access_request and (not flash_noe) and (not flash_nwe) and (not fpga_nconfig);

So pfl_flash_access_granted is only asserted high during flash programming + FPGA configuration stages ?  Is my thought here valid ?  Please comment.

 

Regards,

Kevin

 

 

 

 

 

 

0 Kudos
Knug
Beginner
1,225 Views

Hi @JohnT_Intel 

I will not try this modification on the bench due to the above warnings..

Still my outstanding big question "How to handle properly the pfl_flash_access_granted & pfl_flash_access_request signals for a combined "Flash Programming + FPGA Configuration" 1 PFL solution ?" remains unanswered ..

I am stuck at the moment not knowing how to proceed with a solution to this problem

 

Regards,

Kevin

0 Kudos
Knug
Beginner
1,219 Views

Hi @JohnT_Intel 

Noticed one issue with my original suggestion :

pfl_flash_access_granted <= pfl_flash_access_request and (not flash_noe) and (not flash_nwe) and (not fpga_nconfig);

Above looks wrong. Tried the following :

pfl_flash_access_granted <= pfl_flash_access_request and ((not flash_noe) or (not flash_nwe)) and (not fpga_nconfig);

or

pfl_flash_access_granted <= pfl_flash_access_request and (not flash_nce) and ((not flash_noe) or (not flash_nwe)) and (not fpga_nconfig);

 

But still get similar warnings to the ones reported earlier !

 

Then tried the following :

pfl_flash_access_granted <= pfl_flash_access_request and (((not r_flash_nwe) and (not r_flash_nce)) or (not fpga_conf_done));

 

Don't get as many warnings now apart from :

Warning (13046): Tri-state node(s) do not directly drive top-level pin(s)
Warning (13047): Converted the fan-out from the 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 "pfl_flash_access_granted" into an OR gate
Warning (13047): Converted the fan-out from the 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 "pfl_flash_access_granted" into an OR gate

--

Warning (332125): Found combinational loop of 4 nodes
Warning (332126): Node "pfl_flash_access_granted~2|combout"
Warning (332126): Node "pfl_flash_access_granted~1|datab"
Warning (332126): Node "pfl_flash_access_granted~1|combout"
Warning (332126): Node "pfl_flash_access_granted~2|dataa"

 

Decided not to try any of these options on the bench due to the above warnings ...

 

Please assist here to how to get the combined "Flash Programming + FPGA Configuration" to work using just 1 PFL.

 

Regards,

Kevin

0 Kudos
JohnT_Intel
Employee
1,205 Views

Hi,


May I know what is the reason is that you are connecting to multiple signal? Is it possible to just connect to only 1 signal?


0 Kudos
Knug
Beginner
1,199 Views

Hi @JohnT_Intel 

Reason of attempted to connect to multiple signals was to be able to get the system to work. But those warnings seen I was reluctant to run that code on the bench and rejected that solution. Ideally I do not want to connect to multiple signals if a simple solution can be found to resolve the problem I see.

I am trying to get the both functionalities "Flash Programming + FPGA Configuration" option to work when using just one PFL with this option enabled.

I tried various ways to see which one works reliably but could not find an answer.

I even connected the pfl_flash_access_request signal internally to the pfl_flash_access_granted one but that did not work reliably too.

If I manage to get it to work once, when I power cycle and tried to run again same test or setting up a new page to program the flash and then configure the FPGA, it failed to get access to the flash interface. Also, seen messages such as "Can't recognise silicon ID for Device 1 operation Failed"

I was worried then about the flash being corrupted and went back with the old 2 separate PFL code and written successfully to all 3 pages of the flash without any issues (ie programmed the flash) and then configured the FPGA.

There is something fundamental going wrong with the combined 1 PFL solution. Has anyone tried it ?

If yes, how the control of pfl_flash_access_request signal & pfl_flash_access_granted signal were handled?  This is my question.

or is it something else, reset issue (ie control of the pfl_nreset) that is causing the issues I see?

I am stuck the past week with this issue and it does not look good !

 

Regards,

Kevin 

 

0 Kudos
JohnT_Intel
Employee
1,180 Views

Hi,


May I know if you have tried to refer to the board update portal design where it is part of the development kit installation file?


0 Kudos
Knug
Beginner
1,171 Views

Hi @JohnT_Intel 

I don't understand your question here.

Which board update portal design (part of the development kit installation file) do you mean ?

I instantiated the PFL with both "Flash Programming and FPGA Configuration" options enabled together and had the same setups as the separate standalone PFLs done before (before we had 2 separate PFLs with not both options mixed up together, that worked) and having intermittent issues with the combined 1 PFL solution accessing the flash to be able to Program it.

My suspicion it may have to do with the control of the pfl_flash_access_granted / pfl_flash_access_request signals. 

I did not get a satisfactory reply to my query yet.

Is there a reference document or a reference kit link that describes the way to setup the combined "Flash Programming and FPGA Configuration" to 1 PFL solution? 

Regards,

Kevin

 

 

 

0 Kudos
Knug
Beginner
1,153 Views

Still waiting for a satisfactory reply.  Cannot proceed without resolving this issue ..

0 Kudos
JohnT_Intel
Employee
1,133 Views

Hi,


Sorry for the delay.


If you are refering to https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-cyclone-v-gt.html, you are able to download the installation kit. Inside the installation kit, you will be able to get Max V design which contain the PFL for reference


0 Kudos
Knug
Beginner
1,126 Views

Hi @JohnT_Intel 

I downloaded the kit. Thanks.

Noticed that there is a pfl_control module within MAX5. It looks pretty complicated. There are 9 instances within it. The P2 is the PFL.

Looks like the pfl_flash_access_request output of the PFL is dangling (unconnected) internally to the internal signal  fl_access_req of the pfl_control module.

The control of the pfl_flash_access_granted is by the pfl_en signal which gets generated by the wdt module reset output signal. Very confused with the process inside the wdt.vhd that generates the reset_int signal (reset out). 

We had a similar process within our code and I tried adding the reset_int to it within my Loader_MConfig that instantiates the PFL as follows :

process(in_clk, in_reset)
begin
     if  (in_reset = '0') then
           r_hb_led <= '0';
           r_counter <= 0;
           reset_int <= '1';

     elsif (rising_edge(in_clk)) then
           if (r_counter = COUNTER_MAX) then
                 r_counter <= 0;
                 reset_int <= '0';
                 r_hb_led <= not r_hb_led;

                -- if(fpga_conf_done = '1') then
                --       r_config_done <= '1';
                -- end if;
          else
                r_counter <= r_counter + 1;
                reset_int <= '1';
          end if;
    end if;
end process;

pfl_en <= reset_int;

 

I then connected pfl_en to the pfl_flash_access_granted input pin of the PFL instance within our Loader_MConfig module.

I then generated a .pof of the Loader_MConfig module, loaded it to our programmer, program/configured it. Then Power cycled it. Autodetected the CFI flash. Loaded our application code .pof file which contains the page data info to program the flash, changed that .pof file to the flash. Then tried to Program/Configure it, BUT I get issues : 

Error (209025): Can't recognize silicon ID for device 1
Error (209012): Operation failed

Note: It worked just once but then when I tried to program other pages in the flash it failed with the above Error !  Looks like again it intermittently works BUT not always. I only seen it working once in 10 tries !   

I powered cycled each time for a clean run BUT seen above error message.

--

I then re-run an old code with the 2 PFL's splitted and that code still works ok ie no issues with programming the flash there.

My combined to 1 PFL code what ever I do to it it does not always work ok !

 

0 Kudos
Knug
Beginner
1,109 Views

Hi @JohnT_Intel 

Wrt the kit example I received, I went ahead this morning and added slow_clk_gen, wdt, reset_generator blocks within my PFL wrapper as was done in the MAX 5 and connected similar way to what it was doing in the kit.

Tried here to generate the pfl_nreset and pfl_flash_access_granted signals as it was done in the kit, pfl_flash_access_request output signal of the  PFL was left unconnected as the kit did.

Not used the msel_reset_n process because not using AS fast or AS standard modes. Using FPP so the output of the reset_generator connects to wdt (reset_n) & reset of slow_clk_gen.

The output reset of the wdt (pfl_en) was connected to the pfl_flash_access_granted input signal of the PFL and the pfl_nreset of the PFL.

Avoided using the:  reconfigure_n <= (load_image and pls_out and reset_n and srst);

as was used within the pfl_control.vhd. That has to do with reconfiguration which I have not enabled that option within my PFL, so connected the output of the reset_generator (reset) directly to the reset_n of the wdt module.  Is this ok ?  

Result =>  After programming/configuring the new generated combined PFL .pof It could not autodetect the flash and if autodetected it once it could not start erasing/programming it !

What I am doing wrong here?

Still Stuck in trying to get the combined 'Flash programming + FPGA Configuration' mode to work with 1 PFL. 

 

0 Kudos
Knug
Beginner
1,099 Views

Q/  How do I control pfl_flash_access_granted, pfl_flash_access_request & pfl_nreset signals to achieve correct combined 1 PFL "flash programming + FPGA configuration" and without any issues when I power cycle and run it again ?

Very surprised that I cannot get a straight forward answer to this simple question !

 

0 Kudos
JohnT_Intel
Employee
1,095 Views

Hi,


The method that we are using is just directly connect the control signal from Nios II to the PFL IP pfl_flash_access_request which is to request for the access to the flash while Nios will start accessing the flash once "pfl_flash_access_granted" is high.


0 Kudos
Knug
Beginner
1,109 Views

Hi @JohnT_Intel 

First of all we are NOT using the NIOS II.

PFL IP pfl_flash_access_request is an  output pin of the PFL not an input.

pfl_flash access_granted is input to the PFL

Just need the correct logic to control pfl_flash_access_granted from the pfl_flash_access_request output

and also the correct logic to control the pfl_nreset

 

 

0 Kudos
Knug
Beginner
1,106 Views

Hi @JohnT_Intel 

First of all we are NOT using the NIOS II.

PFL IP pfl_flash_access_request is an  output pin of the PFL not an input.

pfl_flash access_granted is input to the PFL

Just need the correct logic to control pfl_flash_access_granted from the pfl_flash_access_request output

and also the correct logic to control the pfl_nreset

0 Kudos
JohnT_Intel
Employee
1,093 Views

Hi,


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.


0 Kudos
Reply