Quartus allocates M9Ks for NIOS is 16 block increments - HELP

[Altera_Forum]

Hi Folks- 

 I'm having a problem getting use of the the last few M9K unsused blocks in my device. Block RAM for NIOS code and data seems to be allocated by Quartus in increments of 16 M9Ks. In SOPC builder, I can allocate NIOS memory in increments of 1K bytes. My device limit is 66 M9Ks and my hardware blocks use 13 M9Ks. I'd like NIOS to use whatever M9Ks remain.   An example will show my problem. If I tell SOPC builder to size NIOS RAM at 46K or 47K or 48K bytes, Quartus will allocate exactly 48K bytes (or 48 M9Ks). That leaves 66 - 48 - 13 = 5 M9Ks unused. If I tell SOPC builder to size NIOS RAM at 49K bytes, Quartus will allocate exactly 64K bytes (or 64 M9Ks). That leaves M9K over-allocated and the build will not succeed. If I ask for just a little more memory for NIOS from my 5 unused M9Ks, I can't get it because of that huge M9K allocation increment.   Every bit of RAM is precious in my system. I can fit a lot of code into 5K and I would sure love to use it.   Is there any way to get Quartus to allocate M9Ks for NIOS in smaller increments (much less than 16 M9K increments)?   Thanks, John Speth

[Altera_Forum]

You could add a 4K TCM and a 1 K TCM to your system. Although this is not general system memory, it would allow you to utilize the last of your M9K's.. 

 Pete

[Altera_Forum]

If all else fails you can always make your own memory component that you have complete control over the block width and depth. To make it visible to the CPU you would just need to add the 'isMemoryDevice' command to the hardware .tcl file so that you can target it like any other memory that ships with SOPC Builder. To find out more about the command you can find it here: http://www.altera.com/literature/hb/nios2/n2sw_nii52018.pdf 

 This won't work for tightly coupled memories, but you can always add smaller TCMs using the on-chip memory that ships with SOPC Builder.

[Altera_Forum]

Thanks, BadOmen. I can see what you're getting at with your suggestion. I tried to implement an Avalon Slave to use up the remaining M9K blocks using inferred block RAM and setting 'isMemoryDevice' to true. 

 I ran into the problem that I couldn't make the on-chip RAM and the new RAM to be located in a contiguous memory range using SPOC Builder. When I attempt to override the naturally calculated base address of the new RAM, the tool complains that it overlaps the on-chip RAM. I can locate the new RAM at arbitrary addresses but none that is contiguous to the main memory. Is there some way to make it contiguous?   Failing a solution to my contiguous problem, maybe I can locate the stack and heap in my new RAM. How would I do that?   Thanks, John Speth

[Altera_Forum]

The memory base address must be a multiple of the span which may cause gaps. If you are trying to make it continuous so that it looks like one big memory to the software compiler that won't work anyway unless you get really cleaver with the linker scripts. Do you need separate memories though? Couldn't you just make a big memory, subdivide the memory blocks any way you want internally and just limit the memory span if needed? 

 You can bind individual functions to specific memory sections if you wanted to, I think you can specify this in your code by assigning the function to a specific linker section (see the tightly coupled memory example if you want to see the syntax). You can place the stack and heap in a different memory either modifying the system library properties (using the IDE) or BSP editor (using Eclipse for Nios II). This should be documented in the Nios II software developers handbook in great detail.

[Altera_Forum]

The problem with this is you cannot use the same memory block for code and data without using a custom linker script. For some reason the linker complains about doing this causing an error when in fact there are perfectly good reasons to do this. We do this in our application and it's one more thing to keep up with having a custom linker script. 

 Bill

[Altera_Forum]

You also probably want to link all the readonly data sections with the data, not with the code. A normal (aka unix) program link puts the rodata with the code so that writes to it fault. 

If your code and data are in tightly coupled memory blocks you don't want readonly data accesses to be slow Avalon MM transfers.  IIRC the standard linker script is for large programs loaded into SDRAM (or similar) - I use a very custom script that assigns code/data to many different memory areas and includes the instructions to set %sp and %gp.