Contributor
Regular ContributorHi,
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.
ContributorHi @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
ContributorAny 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?
ContributorHi @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
