Process for Embedding NIOS Code in .pof

Hi,

if you would like to have your Nios code in the programming file, you have to have a on chip rom (maybe a ram will work, too) and you have to check the "Enable non-default initialization file" option in your SOPC on chip rom module.

You have to make sure that the Nios II IDE creates a *.hex file named according to the field "User-created initialization file". If all your settings in SOPC are okay (reset vector, etc.) then it should work after you re-generated your SOPC system and recompiled your Quartus project.

After recompilation of your Quartus project, the Nios program should be also in your *.sof file.

The basic steps are as follows:

1. Build your SOPC sytsem with onchip ROM and enable the "Enable non-default initialization file" option.

2. Generate your SOPC system.

3. Create a Nios II IDE project based on the just generated SOPC system.

4. Build your Nios II IDE project and make sure that the *.hex file according to your "User-created initialization file"-name was created.

5. Go back to SOPC and regenerate the system that now includes your *.hex.

6. Implement your SOPC sytsem in a Quartus project and compile this to get your *.sof and *.pof files.

This is the way I do it.

Maik

Thanks Maik for the detailed list. I have tried your steps several times with no luck!

Another thought I still have....Do I need to preform an update of my memory initiilization file?

From the Quartus Menu:

Processing...Update Memory Initialization File

The way I have historically done it:

1 - Build your SoPC system. By default, your onchip memory will use a ".hex" file with the same name as the memory (e.g. "onchip_memory_0.hex").

2 - Build your NIOS project in the IDE. Upon successful compilation, the IDE will produce the desired "onchip_memory_0.hex" (or whatever you named your memory component). However, my understanding is that this has changed somewhat in 9.1 and you have to do a little extra work. Let me know if you are using 9.1.

3 - Build your Quartus project. During the assembler stage, the "onchip_memory_0.hex" will automatically be used to initialize your RAM.

Now with regards to the "Update Memory Initialization File" menu item. Use this if:

You have changed your software code.

and you have NOT changed your SoPC system.

and you have NOT changed the rest of your FPGA design.

Basically, running "Update Memory Initialization File" followed by running the assembler just updates your programming file with new RAM contents (containing your software code).

Jake

Thanks Jake,

When I compile from these steps I see the timestamp change on the .hex so I know it’s being modified. Of course then when I recompile from with Quartus my .sof and .pof timestamps change as well leading me to believe that my files are being updated with the NIOS code, but when I use the byteblaster on my DE0 development board I get NO code execution. The LEDs show that something is happening (hardware configuration) just no CPU functionality. As I mentioned in a previous post if I just run from the debugger everything works.

Am I doing something stupid like not building a release version of the NIOS code?

John

Look at your compilation report under:

Fitter -> Resource Section -> RAM Summary

You should get a table that lists each RAM block in the design. One of the columns indicates which MIF (or HEX) files is being used to initialize the memory. Verify that it is correct for your onchip memory.

You can also look at "Analysis & Synthesis" -> RAM Summary and see what it's showing for the MIF file.

Another thing to try is attaching to the existing target with the NIOS debugger rather than downloading the code and executing. Then, if the CPU is running, the debugger will just hook up to it at it's present location. You set this option in the run configuration dialog for your project in the IDE. We've seen various situations when for one reason or another, the code will run when download it but hang when you try to boot from it and run.

Jake

I see the onchip_memory.hex filename under Fitter -> Resource Section -> RAM Summary as you suggested, but how do I attach to target?

Thanks

What version of the tools are you using?

You have to open the "Run Configuration" dialog for the software project you are working with.

From the IDE: Run->Debug...

Then click on the debugger tab. There is a panel entitled "Download and Reset". Under this panel, change the selection from "Download program to RAM" to "Attach to existing program on target (no download)."

Jake

version

I am using the 9.0 Web Edition ...and I own a license for NIOS. Also I am on a Vista box and I am using the GUI versions of the tools for compiling. (I am command line challenged)

remote debug

I tried to connect directly...that is I assume what you asked me to do... was to load the .sof (hardware) with Quartus and then use the NIOS IDE to debug the hardware with the debugger set to "attach to existing program on target (no download)" hoping that this would flush out some sort of connection problem. Result == the same as before. The LED digits are lit from loading the .sof, but inanimate or unaffected by the code that should be running.

Again when I load the .sof and then run the debugger using "download program to ram" the debugging and code works great. I just can't create a .pof that I can load into the EPCS via the AS programming mode.

other thoughts

I am using the SDRAM core and the University Program SDCARD IP cores. These wouldn't interfere would they??? Is it possible that these need a time-limited version and the NIOS License prevents a time-limited build creating my scenario???

(It has always been unclear to me as to what falls under the description OpenCore Plus.) There is some sort of color code scheme (some are light green and some are grey), but are these all free to be included in designs? How do I know which ones need licensed?

It might be worth looking at the elf program that is generated to check that the code and data sections have the correct addresses for the internal memory blocks. The link script used by the IDE build rather assumes that your code+data is being loaded into a large memory area (eg the SDRAM) and code is added to copy the data into internal memory.

Look at the output of 'objdump -p' (and maybe 'objdump -h') to ensure that the physical and logical addresses are the one you need.