Forum Discussion

Knug's avatar
Knug
Icon for Contributor rankContributor
5 years ago

PFL - Flash queries

Wrt Parallel Flash Loader Intel FPGA IP User Guide pg17 : Can someone please explain the following wrt "Page Start Address, End Address, and Page-Valid Bit Stored as Option Bits" Fig12 diagram ...
YuanLi_S_Intel's avatar
YuanLi_S_Intel
Icon for Regular Contributor rankRegular Contributor
5 years ago

Hi Kevin,

1) Just need to know how the PFL data structure is implemented (flash is just secondary data that get stored in the correct Write buffers/sectors). Programming it in a structure that PFL recommends will be a good step forward.

2) Is there some header in each sector that needs to be taken care when we program or is it just pure data? If it's just pure data, how do we get the data into the flash, which sectors etc?

Why we are interested in this? If we are manipulating those pages we write with the loader next time when we boot up configuration will try to read those and if it does not find what it expects in that location at that address, it will not work.

So if we know what needs to be written and if we can change that data then that's it. That's the remote update.

I think what you need to send to the flash is the POF bitstream file. The PFL IP will be able to configure the device with POF bitstream. It is not recommended to alter the bitstream content. It would be better if you could erase the particular image file (say image 2) and replace it with another new image (remote upgrade) but you need to make sure the image size will not overwrite the next image (image 3), if there is any.

3) Also, wrt one of your replies wrt OPTION_BITS :

>> Since the options bit will be generated by the IP and during POF file generating. I think what you need to take note is that when you are generating PFL IP. You are required to select the option bit storing address. Also, you need to put the correct option bit starting address when generating the POF file.

There was no option to select the option bit storing address when generating PFL IP.

The setting I was referring is as shown below:

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

Thank You.

Regards,

Bruce


  • Knug's avatar
    Knug
    Icon for Contributor rankContributor
    5 years ago

    Hi @YuanLi_S_Intel ,

    Thanks for your replies so far.

    Please respond to this email too. Have to present the latest info to the team asap.

    Wrt your reply :

    >>I think what you need to send to the flash is the POF bitstream file. The PFL IP will be able to configure the device with POF bitstream. It is not recommended to alter the bitstream content. It would be better if you could erase the particular image file (say image 2) and replace it with another new image (remote upgrade) but you need to make sure the image size will not overwrite the next image (image 3), if there is any.

    We are not trying to alter the .pof bitstream content. The .pof gets generated automatically by the 'convert programming files' option in Quartus as I stated already in my ticket. Yes, I am aware that we need to make sure that the image size will not override any other image size. The 'convert programming files' tool warns us during the .sof -> .pof conversion. If any such conflict exists it will not generate the .pof and flag it for attention.

    We are planning to use our existing I2C slave controller within our Cyclone V FPGA to send the .pof bitstream to the flash (

    1) through the PFL? Don't think it's through the PFL. Looks like it will go directly to the flash because our FPGA has direct link to the Flash Address/Data/Control lines. Do you agree here ?

    )

    from an external host via I2C. But need to make sure we can write to the flash in a way that PFL can recognize.

    FPGA will be receiving via I2C address/data information from the external host in bytes and I will need to translate it into words format and send this to the flash in a way the PFL can recognize it. Need to know how the PFL data structure is implemented.

    2) What I was asking is it all pure data (ie no hidden special headers to worry about?) within the .pof file of the PFL data structure apart from the option bits part? :

    BLOCK START ADDRESS END ADDRESS

    Page_0 0x00000000 0x0041241B

    Page_1 0x00420000 0x0083241B

    Page_2 0x00840000 0x00C5241B

    OPTION BITS 0x00C54000 0x00C54080

    3a) If the OPTION_BITS start address is changed (as the example above), I believe that the PFL IP we generate for just FPGA Configuration (ie not FPGA Programming), the FPGA Configuration parameter “What is the byte address of the option bits, in hex?” before re-generating it has to change from 0x00000000 to 0x00C54000. Is this the case ? Please confirm

    3b) The PFL we generate just for 'Flash Programming' does not specify any option bits parameter to setup like the FPGA Configuration one does. Is this the case? Please confirm

    --

    Above example has no conflict of any page addressing involved and complies with the boundary rules.

    4a) So from this above info could I assume that eg Page_1 in x16 it will be possible to write 256 words of pure data per Line Buffer to the flash as follows ?

    Page_1 : 0x00420000, End address: 0x0083241B -> (4.269083MB of data)

    4b) These were reported as byte addresses within the .map file. Our flash data line is 16 bits and from FPGA we with our current system (no remote upgrade image sent to the flash yet) can process data and write it to the flash. So this .pof file byte-to-word addressing before data gets into the flash must be happening here. Is this the case?

    Upper address bits (27:16) determine the Sector 66 -> 131 (ie total of 66 sectors)

    • 4.269083MB uses Flash Sectors: 0 -> 65 (i.e a total of 66 Sectors)

    -> 256 Line Buffers per sectors 0-64 are used (256 Words per Line Buffer)

    -> Last 66th Flash Sector (ie no 65) uses 36 Line Buffers (256 Words per Line Buffer) + 1 Line buffer (27 Words)