How to handle properly pfl_flash_access_granted & pfl_flash_access_request signals ?

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

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

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

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

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 !

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

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

Attach is the reference design

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.

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?