Contributor
Regular ContributorHi,
Please find my response below:
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 ?
Through PFL if the bitstream is sent from MAX V to FLASH. Through I2C / any interface on your design between FLASH and FPGA if there is any if you are sending the bitstream from FPGA to FLASH.
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
I think you can just directly write the POF into the flash memory. Since you are using PFL for FPGA configuration, the PFL IP needs to read the header from the bitstream. Thus, there is no need to remove the header or whatsoever. Just write the entire POF into the flash will do.
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
Yes, you need to change in the IP as well, then regenerate.
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
Yes it is correct.
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)
If you are using PFL, the FIFO is limited to the setting you choose.
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf (Page 32)
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)
Yes.
Thank You.
ContributorHi @YuanLi_S_Intel ,
Wrt one of your replies :
>> 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 ?
>> Through PFL if the bitstream is sent from MAX V to FLASH. Through I2C / any interface on your design between FLASH and FPGA if there is any if you are sending the bitstream from FPGA to FLASH.
>> from an external host via I2C. But need to make sure we can write to the flash in a way that PFL can recognize.
The bitstream that contains the new remote image application file data eg .pof (whatever comes from the external remote host) will be forwarded to the FPGA (slave I2C controller) via I2C (& aiming to be eventually stored to the flash correct address locations & will NOT be send from MAX V to Flash in this case).
The issue I have and don't understand at the moment is if .pof file gets send to the FPGA via I2C, I2C slave controller only uses 7-bit addressing mode (possibility of 10-bit addressing but will prefer to use it's existing 7bit addressing feature).
The .pof shown addresses eg
BLOCK START ADDRESS END ADDRESS
Page_0 0x00000000 0x0041241B
& you agreed on the following :
Upper address bits (27:16) determine the Sector 0 -> 65 (ie 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)
---
If the host sends the .pof to the FPGA via I2C how will the FPGA understand the above addressing from it? Through I2C can usually receive chunks of serial Address bits followed by serial data bits from the Master to the Slave !
Having issues understanding this communication between Host and FPGA if they just forward a .pof file across in chunks of bytes. How does this link to the above addressing info seen in the .map file of the generated .pof ?
Please assist here because I am stuck and not knowing how to proceed and NOT able to suggest to the host side what type of file to send me .pof or .rbf or any other format so that the addressing / data will be recognizable for the FPGA to then be able to store that to the correct write line buffers of the appropriate sectors of the flash.
ContributorHi @YuanLi_S_Intel ,
You mentioned that the PFL contains a header. What is the exact data structure of the POF?
( The POF file normally we generate from the Convert Programming File we specify:
Configuration Device: CFI_1Gb, Mode: Passive Parallel x16 )
How many bytes the header contains? And is the header always the same <byte> values? If yes, what are these values?
What comes after the header? Chunks of data? How do we relate the data with the addressing?
The POF file sent by the Host via I2C to the FPGA will contain just 1 new application image page each time.
Please reply.
Regards,
Kevin
ContributorHi @YuanLi_S_Intel ,
Thanks for your replies so far. However, received also no replies to my last 2 messages yet.
Could the .rbf be a better file to use? Converted the .pof to .rbf and tried to program the flash with the .rbf but it only accepts .pof files !
Reason of trying to check it with the .rbf is to see if the FPGA configures with the .rbf
1) If the host sends the .rbf data to the FPGA via I2C will this make life easier? Is the format of RBF pure raw binary data (no headers involved, no addresses just pure raw data) ie
Addr0 expect byte1 data
Addr1 expect byte2 data
etc
2) What means do you suggest comparing a .pof file vs .rbf one to check for the main differences ?
Can I convert from 'RBF to hex' & 'BOF to hex' diff the 2 hex files to check for differences? If yes, how do I do this?
Regards,
Kevin
ContributorPlease someone answer my latest messages.
This is a stopper at the moment not knowing beforehand the .pof file structure and if we use .rbf instead how the data is structured here so when the host sends it to the FPGA via I2C how will I know which specific byte data from the .rbf to process as a starting address to a particular sector of the flash?
Thanks..
