[NIOS] New CPU Memory HEX file -> should all NIOS system be regenerated?

[amildm]

Hello,

When the NIOS Memory HEX file is replaced with a new one -> should all NIOS subsystem be regenerated (new RTL file will be created)?

Can not I leave the whole NIOS system untouched and just replace the NIOS Memory HEX file?

Thank you!

[EBERLAZARE_I_Intel]

Helo,

Yes, if you have any changes in the hardware system, you must recreate, update or regenerate the BSP project to keep the library header files up-to-date.

The BSP editor will generate the .elf based of your design, which will be used by the .HEX.

[amildm]

The question was a bit different ....

I already have a new .HEX file - received it from out SW group.

But, when I replace the "old" .HEX with the "new" .HEX (shown in the GUI screenshot in my previous post), QSYS wants to re-generate the whole NIOS subsystem (RTL generation).

Why? The .HEX, which I received, is based on the same NIOS configuration. The only thing, that has been changed, is the Memory (ROM/RAM) contents, which NIOS works with... I mean no logic has been changed, only memory contents have been changed - so why the whole NIOS subsystem RTL should be re-generated?

Thank you in advance

[EBERLAZARE_I_Intel]

Hi,

The Platform Designer have its own interconnection in the background and generate the HDL files based of the design that you have connected in the Platform Designer, thus using different .HEX meaning, different .qsys files generated, different HDL files, which will have issue.

Thus, you need to have it re-generated. To answer your question again, it is due to the memory you mentioned having a connection with the Nios II itself, meaning any connection to the Nios II whatsoever, there will be changes in the hardware thus require a re-generation. Nevertheless, we still recommend user to re-generate whenever there's any hardware changes.

[EBERLAZARE_I_Intel]

Hi,

Do you have any further questions?

[amildm]

I've marked the solution, thanks!

[EBERLAZARE_I_Intel]

Hi,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

[RProesel · Accepted solution]

You do not have to regenerate the NIOS sub-system if you change the .hex file that you are using to initialize the memory.

You only have to do 2 steps in Quartus:

  1) Run 'Update Memory Initialization File' in the Processing menu.

  2) Run 'Start Assembler' under 'Start' in the Processing menu.

This will create a new SOF file using the new .HEX file.

[amildm]

As for the above flow ('Update Memory Initialization File' and then 'Start Assembler'), will this also re-compile the FPGA logic or will leave it the same as before updating the Memory Initialization File?

Will the above flow update the NIOS memory only or will it update ALL the INIT files for ALL the Memories in the given Project?

Thanks!

[RProesel]

It will not recompile the FPGA logic and will leave it the same as before updating the memory files.  It will update all the memories, but it the only thing you changed was the NIOS code,  any other memory contents will be the same as it was from the compile.

I have been using this technique for many years for exactly the reason you explained.