PFL - Flash queries

Knug · ‎03-02-2021

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 ? It states that it is using flash byte addressing mode and like to know if my understanding below for our 'word addressing' mode is correct?

We are using x16 so it is possible to write 1 to 256 words within the write buffer before starting a programming operation (ie 256 address locations of 16bit word data per page ( 256x16 = 4096 ) wrt below info :

Flash document S29GL01GT/S29GL512T, 1-Gb (128 MB)/512-Mb (64 MB), GL-T MirrorBit® Eclipse™ Flash (cypress.com)

The Flash we are using is : S29GL01GT
Page : 4096 per sector and uses addresses A15-A4 (12bit address)

PFL can store up to 8 pages (page0-page7) of info so if each page is 4096 (4KB) where will the .pof version be stored? if Page 7 (last page) end address is 0x007FFFF.

Will the .pof version occupy only 1 word in the option bits sector and it could be 0x0080000 ?

Because we have no enhanced bitstream compression feature enables within our PFL this value should be 0x0003 and it should be generated automatically. Please confirm.

If we only use 3 pages, will the .pof version still reside at the same fixed location?

YuanLi_S_Intel · ‎03-02-2021

The start address for option bit will be generated and provided during PFL IP instantiation. Meanwhile for the page address of all the SOF in the POF, you can select Auto to let the Intel Quartus Prime software automatically set the start address for that page. Select Block to specify

the start and end addresses, or select Start to specify the start address only.

You may follow the link below for the guide to create the POF file for your design.

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

Knug · ‎03-04-2021

Hi,

Used <auto> mode and managed to generate the .pof file successfully.

Page_0 start address: 0x00020000 end address: 0x0043241B

Page_1 start address: 0x00440000 end address: 0x0085241B

Page_2 start address: 0x00860000 end address: 0x00C7241B

Option bits start address: 0x0000000 end address: 0x00000080 <- .pof version

Start addresses were generated automatically on a 128KB boundary (actually 2^17 = 131,072)

Thanks for this.

1) But the .map file generated stated that all addresses in the .map file are byte addresses. Does it mean each address location contains a byte of data ?

---

2) However, still need someone to explain wrt Parallel Flash Loader Intel FPGA IP User Guide pg17 :

"Page Start Address, End Address, and Page-Valid Bit Stored as Option Bits" Fig12 diagram ? It states that it is using flash byte addressing mode

It states that Bits 0 to 12 for the page start address are set to zero and are not stored as option bits.

Is that for a 28bit address (27:0) : Address(12:0) are always set to '0'?

I am confused from the fig12 byte addressing mode shown. The Bit7....Bit1 at eg 0x002000 address does this correspond to the data and bit 0 of the start address of each page is 'Page-Valid' bit?

If Bit7....Bit0 corresponds to the data, what about address 0x002002 shows only 7 bits of data ie Bit7...Bit1 ?

or are those bits representing the address bits?

Very confusing..

3) Our system uses flash_addr(25:0) & flash_data(15:0). How will we address our PFL correctly ?

YuanLi_S_Intel · ‎03-05-2021

Hi,

Please find my response below:

1) But the .map file generated stated that all addresses in the .map file are byte addresses. Does it mean each address location contains a byte of data ?

It means the data of is stored from 0x00020000 to 0x0043241B. Each address has data.

2) However, still need someone to explain wrt Parallel Flash Loader Intel FPGA IP User Guide pg17 :

"Page Start Address, End Address, and Page-Valid Bit Stored as Option Bits" Fig12 diagram ? It states that it is using flash byte addressing mode

It states that Bits 0 to 12 for the page start address are set to zero and are not stored as option bits.

Is that for a 28bit address (27:0) : Address(12:0) are always set to '0'?

I am confused from the fig12 byte addressing mode shown. The Bit7....Bit1 at eg 0x002000 address does this correspond to the data and bit 0 of the start address of each page is 'Page-Valid' bit?

If Bit7....Bit0 corresponds to the data, what about address 0x002002 shows only 7 bits of data ie Bit7...Bit1 ?

or are those bits representing the address bits?

Very confusing..

Those are the information on the options bit and its structure. 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.

3) Our system uses flash_addr(25:0) & flash_data(15:0). How will we address our PFL correctly ?

Are you saying hardware connection with flash? If it so, take a look below:

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

Thank You.

Regards,

Bruce

Knug · ‎03-05-2021

Hi @YuanLi_S_Intel ,

>>1) But the .map file generated stated that all addresses in the .map file are byte addresses. Does it mean each address location contains a byte of data ?

>> It means the data of is stored from 0x00020000 to 0x0043241B. Each address has data.

So Initial address 0x00020000 stores 8bit of data

Next address 0x00020001 stores 8bit of data (ie for byte addressing, using address increments of 1)

etc up until address location 0x0043241B

1) Does the tool currently take special care when addressing the PFL / Flash which is 16bit data ?

Wrt Page 0: Start address: 0x00020000, End address: 0x0043241B (4.269083MB of data)

Do I then try to relate above addresses to the flash S29GL01GT/S29GL512T, 1-Gb (128 MB)/512-Mb (64 MB), GL-T MirrorBit® Eclipse™ Flash (cypress.com) Table1 as follows wrt start address 0x00020000 ?

A25:A16 -> 002h # Sector 2 of 1023 (Normally 0 – 1023 sectors)
A15:A8 -> 00h # Write Buffer Line 0 of 255 (Normally 0 – 255 Write Buffers)
A7:A0 -> 00h # Start address within Write Buffer line 0 is 0
# (Normally 0 – 255 addresses within Write Buffer)
A15:A4 -> 000h # Page 0 of 4095 (Normally 0 – 4095 Pages)
A3:A0 -> 0h # Start address within Page 0 is 0 (Normally 0 – 15 addresses within a Page)

The above Flash spec states for x16 it is possible to write from 1 to 256 words, anywhere within the Write Buffer (there look to also be 256 line buffers per sector) before starting a programming operation

Our address range for eg Page 0 is huge actual page contents of our .pof is 4.269083MB from the above address range.

I looks like it uses Sectors: 2 -> 67 (i.e 66 sectors)

66 sectors * 256 line buffers * 256 words per line buffer = 4.325376MB

(4.325376MB > 4.269083MB => ok ie can fit this requested data within 66 Sectors)

Is my assumption (ie calculation above) correct here ?

2) Ok thanks. My OPTI0N_BITS were reported with the <auto> selected

Start Address: 0x00000000
End Address: 0x00000080 <- .pof version

Will keep this as it is.

>> 3) Our system uses flash_addr(25:0) & flash_data(15:0). How will we address our PFL correctly ?

>> Are you saying hardware connection with flash? If it so, take a look below:

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

I noticed that figure. Since we are using Cypress Flash in 16-bit mode, address bits of PFL & Flash match exactly, so in our case we will have :

Addr(0) of PFL connects to Addr(0) of flash
::::::::::::::::::::::::::
Addr(25) of PFL connects to Addr(25) of flash

Wrt my question "How will we address our PFL correctly ?"

Our PFL is connected to the flash directly. We can program the flash with the current .pof generated by the 'Convert Programming files' tool.

3) To implement our own 'user logic' within the Cyclone V FPGA (and avoid using the Remote Update IP as discussed already) our option now is the FPGA to read in the updated .pof file via the I2C and then ?

One of your answers to my one of my previous ticket :

>> Our remote host I2C has just links to our FPGA Cyclone V (and not direct links to the CPLD (MAX V)) before the new application image data gets forwarded to the CPLD (MAX V) with the use of the PFL IP core to program the flash :

>> Can we just implement our own logic circuitry within Cyclone V FPGA (without the use of the Remote Update IP) to receive remotely the new application image data (just chunk bare data) from our external host via I2C serially (and also convert it from Serial-2-Parallel within the Cyclone V FPGA) and then be able to load/update/store it to the PFL (PFL is within CPLD MAX V) new sector location as parallel data ready to program the flash?

>> Yes, you can do that.

4) How can we implement the 'user logic' circuitry? FPGA can decode the stream of incoming .pof data from I2C byte at a time until the entire .pof file is been transmitted through. I'm I right to think this way?

How are we able to then load/update/store it to the flash via PFL? Your answer was we can do that but how?

We currently have a flow to program the flash via the USB blaster jtag with the current .pof file that is generated by the 'Convert Programming files' tool.

The new user_logic communication/interaction with the PFL / Flash is what I am trying to figure out (ie the interaction of the Flash (& not PFL as I originally thought) from the FPGA when forwarding/sending the updated .pof addr/data + other flash control info..

I am thinking breaking the current link of the PFL within the CPLD MAX V to the flash address/data & flash control signals via multiplexers. The multiplexer could then select 'User Mode control' (ie controlling the flash via the 'user logic' circuitry within the Cyclone V FPGA so that the flash can receive address / data & control signals from the FPGA) or 'Non User mode control' (ie the muxes will re-connect it as it is at the moment ie direct PFL-to-Flash connection to maintain this connectivity too during non-user mode control).

So basically, the direct connection of the PFL to Flash when forwarding the User addr/data & control signals via FPGA user logic will be accessed by the 'User logic' from the FPGA.

What is your opinion on this ? I'm I thinking in the right direction ? Please comment here

Knug · ‎03-06-2021

Hi @YuanLi_S_Intel ,

The system did not allow me to edit my latest ticket. Last 3 paragraphs should have stated the following :

I am thinking breaking the current link of the PFL within the CPLD MAX V to the flash address/data & flash control signals via multiplexers. The multiplexer could then select 'User Mode control' (ie controlling the flash via the 'user logic' circuitry within the Cyclone V FPGA so that the flash can receive address / data & control signals from the FPGA) or 'Non User mode control' (ie the muxes will re-connect it as it is at the moment ie direct PFL-to-Flash connection to maintain this connectivity too during non-user mode control).

So basically, the direct connection of the PFL to Flash as it is at the moment will not be present when in User mode control & forwarding the User address/data (of the new POF file) & control signals via the FPGA user logic.

What is your opinion on this ? I'm I thinking in the right direction ? Please comment here

Knug · ‎03-08-2021

Hi @YuanLi_S_Intel,

No reply received yet. Will appreciate your reply to this latest message.

Just had an automated message to say 'are you satisfied with the reply?'

Regards,

Kevin

Knug · ‎03-08-2021

Hi @YuanLi_S_Intel ,

Very urgent. Please reply to 1) / 2) below. Thanks so far wrt your previous replies.

Sorry, the breaking of the the current link of the PFL within the CPLD MAX V to the flash address/data & flash control signals via multiplexers IS NOT A GOOD IDEA. My mistake here. Things will not work. We will still be using the PFL.

From FPGA we can process data and write it to the flash. Can have data ready from the FPGA I2C slave controller as RSU & need to make sure that we can write it into the flash in a way PFL can recognize. Basically, the structure in the flash is defined by the PFL.

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.

----

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.

When generating the .pof / .map files from .sof files using the 'convert programming files' and using <auto> the start address of the option bit was selected as 0x00000000 and end address as : 0x00000080 as follows :

BLOCK START ADDRESS END ADDRESS

Page_0 0x00020000 0x0043241B
Page_1 0x00440000 0x0085241B
Page_2 0x00860000 0x00C7241B
OPTION BITS 0x00000000 0x00000080

Page 0 start address was then @0x00020000. So there is alot of waste address space from 0x00000080 -> 0x00020000.

The Option bits was allocated to use the 1^st 131,072 dec boundary (0 – 131,071 or 0x0000000 – 0x0001FFFF). The next boundary starts then @ 0x00020000 for Page 0.

To save waste space at the beginning wrt previous example, decided to add the OPTION BITS at the end and start Page_0 at 0x00000000 as follows without <auto> mode and specifying the right boundary <start> addresses :

BLOCK START ADDRESS END ADDRESS

Page_0 0x00000000 0x0041241B

Page_1 0x00420000 0x0083241B

Page_2 0x00840000 0x00C5241B

OPTION BITS 0x00C54000 0x00C54080

This generated also successfully the .pof file with the above Start manually entered Addresses and generated the above .map file

Regards,

Kevin

YuanLi_S_Intel · ‎03-08-2021

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 · ‎03-09-2021

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 66^th Flash Sector (ie no 65) uses 36 Line Buffers (256 Words per Line Buffer) + 1 Line buffer (27 Words)

YuanLi_S_Intel · ‎03-09-2021

Hi,

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.

Knug · ‎03-10-2021

Hi @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)

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 66^th 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.

Knug · ‎03-11-2021

Hi @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

Knug · ‎03-11-2021

Hi @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

Knug · ‎03-12-2021

Please 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..

Knug · ‎03-12-2021

Hi @YuanLi_S_Intel ,

Seen this link just now :

https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/solutions/rd03032014_456.html

So if I use the 'Convert Programming Files' , select

Configuration device: CFI_1Gb
Mode: Passive Parallel x16

& then convert .sof to .rbf file to generate the .rbf file

1) Can I then assume that the .rbf contains purely just configuration data (no headers bytes involved) ?

The configuration data in the .rbf programming file is little Endian as stated in this link.

For FPPx16 mode, the first byte in the file is the LSB (Least Significant Byte) of the configuration word and the 2nd byte is the MSB (Most Significant Byte)

If .rbf contains sequence 02 1B EE 01

then for FPPx16 mode:

Word 0 = 1B 02 Word 1 = 01 EE

LSB: BYTE0 = 02 , MSB: BYTE1 = 1B LSB: BYTE2 = EE, MSB: BYTE3 = 01

D[7:0] D[15:8] D[7:0] D[15:8]

00000010 00011011 11101110 00000001

2) I can then try to place Word 0 data to Start address 0, Word data 1 to address 1 etc ?

(If my start address for a Page is defined as 0x00000000)

Is this the case ?

Regards,

Kevin

YuanLi_S_Intel · ‎03-15-2021

Hi Kevin,

Sorry for being late as we were out of office. Hope you are doing good.

Please find my response below:

[1] https://www.intel.com/content/www/us/en/programmable/support/support-resources/knowledge-base/soluti...

So if I use the 'Convert Programming Files' , select

Configuration device: CFI_1Gb

Mode: Passive Parallel x16

& then convert .sof to .rbf file to generate the .rbf file

1) Can I then assume that the .rbf contains purely just configuration data (no headers bytes involved) ?

Yes, this is pure configuration data with no header.

2) The configuration data in the .rbf programming file is little Endian as stated in this link.

For FPPx16 mode, the first byte in the file is the LSB (Least Significant Byte) of the configuration word and the 2nd byte is the MSB (Most Significant Byte)

If .rbf contains sequence 02 1B EE 01

then for FPPx16 mode:

Word 0 = 1B 02 Word 1 = 01 EE

LSB: BYTE0 = 02 , MSB: BYTE1 = 1B LSB: BYTE2 = EE, MSB: BYTE3 = 01

D[7:0] D[15:8] D[7:0] D[15:8]

00000010 00011011 11101110 00000001

I can then try to place Word 0 data to Start address 0, Word data 1 to address 1 etc ?

(If my start address for a Page is defined as 0x00000000)

First of all, if you are using RBF file, you need to write your own controller to do programming and configuration as PFL IP is not supporting RBF file.

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

So to answer your question, addressing and data are different. You can have 16 bit data on an address if you are using x16. Thus, you can put 0000 0010 0001 1011 (2 bytes) to 0x0000 0000.

Thank You.

Regards,

Bruce

Knug · ‎03-18-2021

Hi @YuanLi_S_Intel ,

Thanks for your replies so far. Please comment here too (urgent to know please).

>> First of all, if you are using RBF file, you need to write your own controller to do programming and configuration as PFL IP is not supporting RBF file.

What file formats does the PFL IP support other than .pof that we can identify its contents ?

or how can we decode the contents of a .pof file?

Does it just contain the OPTION_bits data followed by the Page data info and no other headers involved?

If it does great. But need confirmation.

eg Page 1

.map file generated for the corresponding .pof file for Page1 was :

--------------------------------------------------------

BLOCK START ADDRESS END ADDRESS

Page_1 0x00440000 0x0085241B
OPTION BITS 0x00000000 0x00000080

Notes:

- Data checksum for this conversion is 0xB8A3B1AF

- All the addresses in this file are byte addresses

----------------------------------------------------------------

Regards,

Kevin

Knug · ‎03-18-2021

Hi @YuanLi_S_Intel

Will appreciate a reply to my previous msg.

Our latest updates :

Chunks of bytes will be send via I2C to the CPLD via FPGA (FPGA is just a middle man, pass through i2c data to CPLD).

So configuration data will be coming from FPGA to CPLD now. Data manipulation will be done in the CPLD. CPLD contains one PFL (see next paragraph) & will update the flash Device. I will need to supply data to the combined loader_config_pfl with some manipulation of course. Could this data be .pof format (knowing its structure?). Then the writing data to the flash will be held automatically by the combined loader_config_pfl itself (which I am trying to test right now, not remotely to get that to work first)

Wrt another ticket I created, we are trying to combine now 'flash programming' + 'FPGA configuration' using one PFL. Having other issues here at the moment not knowing how to control the handshaking signals pfl_flash_access_granted & pfl_flash_access_request to achieve successful flash programming & FPGA configuration. Your reply to this matter will be appreciated too. In this instance we are not sending any data across via I2C.

With this test I am doing now (having issues with the 2 handshaking signals how to properly control), we are:

1) Programming/configuring the CPLD with the combined loader_config.pof

2) Then after power cycle, autodetecting the flash device

3) Then we program/Configure the flash with the application page data .pof

=> We expect to see successful Flash programming & FPGA configuration at the end of this test

------

Could we have byte of data that can be converted to JTAG kind of data for the loader_config_pfl to understand? or can you propose other ways to achieve this?

ie need to be able to extract the data (eg .pof) & supply it to the loader (this will be implemented in VHDL).

What is the best way of achieving this ?

It is very important to know what the .pof structure format looks like otherwise will not now what data will be sending across to the loader and how the loader will receive it and understand it?

Regards,

Kevin

Knug · ‎03-20-2021

Hi @YuanLi_S_Intel

>> First of all, if you are using RBF file, you need to write your own controller to do programming and configuration as PFL IP is not supporting RBF file.

Q/ Is this still the case ?

Found the following comments by @ShafiqY_Intel who replied to another user the following :

Yes, PFL is able to configure the FPGA with .rbf file if only you convert POF to rbf. (not SOF to rbf). You no need to write extra Option Bits to the flash device (in rbf file already include Option Bits (in binary form) )

1) converting .pof to .hexout

quartus_cpf -c <pof_file_base_name>.pof <hex_file_base_name>.hexout

2) Then convert .hexout to .rbf using nios2_elf_objcopy command on the NIOS II command shell

nios2-elf-objcopy –I ihex –O binary <input file>.hexout <output file>.rbf

--

1) I found the way to convert from .pof to .hexout on the quartus command window because above quartus_cpf command was not recognised :

Invoke Quartus. Load the project
cd into the directory where the .pof file is
Then execute the following in the command window :
execute_module -tool cpf -args "-c *.pof *.hexout"

I am not using the NIOS II processor just a CPLD with the PFL instantiated within it and an FPGA Cyclone V (no NIOS II processor is used within the FPGA)

Where can I execute the 2nd nios2_elf_objcopy command:

nios2-elf-objcopy –I ihex –O binary <input file>.hexout <output file>.rbf

Do I need a special NIOS II command shell? If yes, how do I get this ?

=> Looks like I need to get the NIOS II command shell up to be able to type above NIOS II command.

I have the following directory:

C:\intelFPGA_lite\20.1.0\nios2eds

Inside it contains:

NIOS II Command Shell.bat
nios2_command_shell.sh (Is this the Unix version?)
version.ptf

Need the windows command shell version.

Clicked on the "NIOS II Command Shell.bat" executable but window opens and closes instantly. I also tried to give administrator right permission but see same behaviour (ie Command Shell prompt window instantly closes after it is opened)

Need assistance here please..

I asked @ShafiqY_Intel the same question.

Regards,

Kevin

Knug · ‎03-22-2021

Hi @YuanLi_S_Intel

Did you see my latest message wrt not able to convert directly from .sof to .rbf because the

"PFL is able to configure the FPGA with .rbf file if only you convert POF to rbf (not SOF to rbf). These were comments by ShafiqY_Intel

to another user asking a similar question in another ticket. He suggested doing it the following way :

1) converting .pof to .hexout

quartus_cpf -c <pof_file_base_name>.pof <hex_file_base_name>.hexout [ I managed to do this ]

2) Then convert .hexout to .rbf using nios2_elf_objcopy command on the NIOS II command shell

nios2-elf-objcopy –I ihex –O binary <input file>.hexout <output file>.rbf

That is the reason why I asked the question about the NIOS II command (2) ie .hexout to .rbf how to get it up and running (how to get the NIOS prompt ..).

No answer to this yet.

----

& one of your other replies before I replied with above was :

>> First of all, if you are using RBF file, you need to write your own controller to do programming and configuration as PFL IP is not supporting RBF file.

From above PFL supports RBF but needs to be converted from 1) .pof to .hexout , then 2) .hexout to .rbf

Isn't this the case ?

Regards,

Kevin