Max10 RSU of NIOS processor

[Morten2000]

Hi

I have a project were I update the system through RSU. 

When I generate the rpd files. 4 files are being generated:

- Project1_auto.rpd

- Project1_cfm0_auto.rpd

- Project1_cfm1_auto.rpd

- Project1_ufm_auto.rpd

What is the difference between the files? When I use cfm0 and cfm1 it seems only the VHDL part of the design is being updated - and not the C code for the NIOS processor. Is it possible to update the NIOS part of the system and is it included in Project1_ufm_auto or Project1_auto file?

[EBERLAZARE_I_Intel]

Hi,

You can refer here for the "Nios II Processor Booting from On-Chip Flash (UFM)":

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/nios2/edh_ed_handbook.pdf#page=226

The descriptions of the UFM and CFM are there too.

[Morten2000]

Thanks for the link.

It doesn't mention anything about RPD files. So I still don't understand what Project1_auto.rpd contains - is it a combination of the 3 CFM0, CFM1 and UFM files or something else?

- Project1_auto.rpd (314KB)

- Project1_cfm0_auto.rpd (140KB)

- Project1_cfm1_auto.rpd (140KB)

- Project1_ufm_auto.rpd (32KB)

[EBERLAZARE_I_Intel]

Hi,

May I know which method/approach of booting that you are trying to use? Is it UFM OCRAM etc..

[jozephka99]

The flash memory of max 10 split into parts relative to your configuration mode. When applying RSU you have to select "dual compressed image". If you do that flash memory splits into 3 section that are CFM0, CFM1 and UFM. CFMs stand as "Configuration Flash Memory" and they holds the fpga's configuration image. UFM stand as "User Flash Memory" and it holds user memory if there any. All of that flash memories logically high when they are empty and you can't change low bit to high, you can just change high bit to low. So if you wanna rewrite this sections you must clear them before write. There are UFM IP to do flash operations (relative manual: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/max-10/ug_m10_ufm.pdf).

When it comes to RSU, the files that you mention refers to flash memory sections. You can send the fpga which flash section will you change and write them to relative flash section. Since RSU's goal change configuration of fpga, you generally send one of the cfms to write. As you mention these operations just changes fpga's configuration not C part. The other files that created also cannot change the C part of system. If you only use RSU logic on your C side, I recommend you to do the RSU in the fpga side so you can change all of your design.