Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

pre-initialized onchip memory

I have a design that uses several onchip memories. To keep it simple here, say I have: main_memory & my_init_memory.

Naturally, the main_memory is the code space for my Nios II processor, and my_init_memory is some pre-initialized memory (effectively a look-up table with some constants).

In the IDE, when I create a simple Hello World design and build it, here is the final output: 

make -s all 
Compiling hello_world.c...
Linking mem_test.elf...
Info: (mem_test.elf) 52 KBytes program size (code + initialized data).
Info:                    12 KBytes free for stack + heap.
Creating mem_test.elf.objdump...
Post-processing to create main_memory.hex
Post-processing to create my_init_memory.hex

This places my code in main_memory.hex, and sets my_init_memory.hex to all zero's which blows away my predefined lookup table.

There are two work-arounds that I can do to get past this...

1) create a variable such as: 

static const int my_init_array __attribute__ ((section (".my_init_memory"))) = {#some predefined values#};

I do not want my C source file to be responsible for my init data.

2) Create an ALTSYNCRAM using the MegaWizard, and import that into SOPC Builder using the "Create New Component..." wizard and importing my newly created altsyncram.

Here I would rather use the onchip memory already provided in SOPC Builder...

How do I get the IDE to not overwrite my_init_memory.hex file during compilation? Can I create a custom linker script to avoid this? FYI, the system library has main_memory defined for .text, .rodata, and .rwdata

Is there a KEEP function or attribute that I can use?

Thoughts?

Thanks,

-Terry

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    It might be easier to just not let the compiler know about the initialized memory. Simply use the onchip memory as if it were a peripheral.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Terry,

    if you do not use this 'my_init_array' in your software (hello_world.c) , this array is optimized away and filled with default zeros. So write code, that makes use of this data array.

    You have a 'Post-processing to create my_init_memory.hex'. This file is placed in your FPGA directory and will be used by my_init_memory.vhd during FPGA compilation.

    Mike
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    I strongly agree that 'my_init_array' needs to be used in order to have it remain, and not fill with zeros.

    What I am looking for is a way to get the compiler to not run -> 'Post-processing to create my_init_memory.hex', because this will overwrite my already existing file: my_init_memory.hex that I have created using the Quartus II hex editor.

    Anyone have any suggestions?

    Thanks,

    -Terry
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    I think the best method is to convert your hex file into a comma-separated string of numbers, save it as a file (say, "my_init_memory.h") and include that in your C source file like this:

    static const int my_init_array[] __attribute__ ((section (".my_init_memory"))) = {# include "my_init_memory.h"

    };

    If you do it this way, you have the benefit of going with the flow, and you get your simulation contents files built automatically for you. Perhaps there's a way to augment the normal build makefile to convert your hex file to the .h file each time the build happens (only really an issue if your hex file changes frequently).

    If you don't care about memory simulation contents, you could overwrite the Nios II IDE's version of my_init_memory.hex with your own after each software build, or just before each Quartus compilation.

    If none of the ideas posted so far work for you, I&#39;m pretty sure there&#39;s a cheesy workaround which would prevent the unwanted commands from going into the makefile in the first place. Let me know if a cheesy workaround sounds interesting http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Just my 2 cents...

    I&#39;m not sure at all that a global variable that is not used is optimized away by the compiler. I just took a count_binary exampe, and added a file containing a global initialized variable, used anywhere in teh code. That variable was not optimized away, and it can be found on the objdump file.

    Since the hex files are produced by the IDE, I think the best way to handle them is to let them be produced by the IDE. In that way, everytime you&#39;ll change the initialization data the hex will be created again by the IDE...

    PJ