FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6023 Discussions

Loading FPGA from Flash

jlats2
New Contributor I
551 Views

Hello,

 

Thank you for taking time to read my post.

 

I am working with a Cyclone 10 GX using micron MT25QU01G flash memory. I am able to generate a programming file (.JIC) and load the flash memory. When I power cycle the chassis the fpga loads from the flash and appears to run fine.

 

I am also generating a hexout file. Using this as my reference on how to interpret the records in the hexout file, I am able to write the hexout contents to the flash memory. When I power cycle the fpga, the fpga hangs (is unresponsive, similar to how it behaves before ever being programmed with a JIC/SOF).

 

Am I correct that writing the contents of the hexout to the flash should be the same as loading a JIC?

 

Is there anything special that I need to do (such as add a pointer in the first address in flash)?

 

I am able to readback the flash memory and compare it to the contents of the hexout file and the checksum values to match so I am fairly confident that I am writing the flash chip correctly.

 

Again, thank you so much for reading this and helping me.

Best Regards.

0 Kudos
1 Solution
jlats2
New Contributor I
469 Views

Thank you for your help. I certainly will need the 'remote update ip' as this will help me reconfigure the fpga without power cycling the entire board. Thank you for sharing.

It turns out that there is a difference between EPCS and EPCQ flash memories . EPCS can accept the hexout file which is produced during compilation. However, the EPCQ will not work with the hexout directly loaded to flash (bug with quartus?).

 

The work around is to generate a JIC file, and while doing this, check the box for generating a .RPD file. This .RPD will need to be loaded to flash and will work for EPCQ. The .RPD is not in an 'intel  hex' format. Fortunately, there is a python project which allows one to convert from the RPD to what we will call a 'hexout' format (shown below for future readers):

 

<<< python code >>>

from intelhex import IntelHex
ih = IntelHex()
ih.loadbin(filename)
ih.write_hex_file('test.hex',byte_count=128)

<<<end python code>>>

 

 

I am not sure why the hexout file varies from the rpd, maybe someone from intel can comment?

 

Best Regards

View solution in original post

6 Replies
sstrell
Honored Contributor III
537 Views

I'm not sure what you're trying to do, but a .hex file is normally used to initialize the contents of RAMs or ROMs in the design, not as an overall programming file for the device.  It gets pointed to by a parameter or a synthesis attribute and then gets included in the programming file generated by the Assembler at the end of the compilation process (.sof or .jic in your case).  What are you trying to accomplish?

jlats2
New Contributor I
522 Views

Thank you so much for your reply.

 

Perhaps I have some of my terminology incorrect, but the overall goal is to remotely update the fpga configuration data over the network. When I generate a JIC file and program my C10GX with a byteblaster, I understand that this is actually loading the 'configuration data' to a flash chip. Whenever I power cycle my fpga, the 'configuration data' from this flash chip will configure the fpga. My goal is to be able to update the 'configuration data' on this flash chip over the network (not with a byte blaster). This will allow me to 'remotely update' the firmware.  My assumption was that the generated hexout is the 'configuration data.'

 

Is my goal clearly described above?

Assuming that the records in the hexout file are correctly written to the flash memory, should this be sufficient in updating the configuration data so that during the next power cycle the new contents of the flash will configure the fpga?

 

Again, thank you for all of your help.

jlats2
New Contributor I
506 Views

Something else that I noticed and thought it might be worth sharing:

Whenever I generate a JIC file, I can also generate a rpd file. After programming the the JIC and power cycling the fpga, I can read the flash memory and see that the values loaded into the flash memory seem to match the rpd. The rpd is raw data and does not include the same record type information that the hexout file contains (which makes it difficult to compare the two). However the data contained in the .rpd and the .hexout appear to be similar with a few differences (some bytes are different, and the rpd appears to have ff's shifted into the first 30ish bytes).

 

Just adding to the above discussion.

sstrell
Honored Contributor III
487 Views
jlats2
New Contributor I
470 Views

Thank you for your help. I certainly will need the 'remote update ip' as this will help me reconfigure the fpga without power cycling the entire board. Thank you for sharing.

It turns out that there is a difference between EPCS and EPCQ flash memories . EPCS can accept the hexout file which is produced during compilation. However, the EPCQ will not work with the hexout directly loaded to flash (bug with quartus?).

 

The work around is to generate a JIC file, and while doing this, check the box for generating a .RPD file. This .RPD will need to be loaded to flash and will work for EPCQ. The .RPD is not in an 'intel  hex' format. Fortunately, there is a python project which allows one to convert from the RPD to what we will call a 'hexout' format (shown below for future readers):

 

<<< python code >>>

from intelhex import IntelHex
ih = IntelHex()
ih.loadbin(filename)
ih.write_hex_file('test.hex',byte_count=128)

<<<end python code>>>

 

 

I am not sure why the hexout file varies from the rpd, maybe someone from intel can comment?

 

Best Regards

YuanLi_S_Intel
Employee
394 Views

Hi, i am not sure how you use hexout file on it as it is meant for passive serial configuration scheme.

https://www.intel.com/content/www/us/en/programmable/quartushelp/13.0/mergedProjects/reference/gloss...


Since you are using active serial configuration scheme, using RPD file is recommended.


Reply