onchip memory granularity

[Altera_Forum]

Is there something in Quartus/SOPC/NIOSII that forces M4K allocation for on-chip memory to be a power of 2? If so is there a workaround or is this something basic like the hardware always allocates 2^addresswidth bytes and not the size requested?. 

 I was struggling to fit some logic that needs M4Ks, and the fitter reported none left. I had 4kbytes of onchip ROM for NIOSII, it used 8 M4Ks - ok. So I reduced the memory to 3kbytes, but the fitter still failed. It reports the correct (smaller) number of bits used, but still allocated 8 M4Ks. It only dropped the M4K count when I reduced the onchip memory size to 2kbytes (4 M4Ks - ok). The same seems true for the 16k onchip rom, which still uses 32 M4Ks at 14kbytes. I guess if I drop to an unusable 8kbytes then it will call up 16M4Ks.

[Altera_Forum]

May be it will usefull for you. I have such kind of a problem with NIOS v1. As I found this is trouble of SOPC Builder and Quartus. It allocates memory in wery strange mode. I want to have 24Kbyte of onchip ROM (ROM - M4Ks only) on Stratix 1s10 device. Such amount succesfully fits into device, but Quartus didn't fit it. My system in SOPC Builder was generated in verilog. I found next thing - in verilog file that describes memory (boot_rom.v for example) sopc builder writes 

the_altsyncram.numwords_a = 8192 while correct ansver is the_altsyncram.numwords_a = 6144. The word width is 32 bit. I correct it manually and all works well. So you can try to find where memory is described in your project and check value and correct it manually if needed. Also Quartus didn't fit for example 25Kbytes or 27Kbytes evein if there are free M4Ks in needed amount. It will fit it if only 32Kbytes are availible. I don't know why:( It's wery bad bug cause in Stratix devices you can not use all M4Ks memory as single block. All this (upper words) is correct for memory usage as a single block.

[Altera_Forum]

I also had the same problem here quad with quartus 4.1 when i was trying to use all of the available M4Ks in a single memory block. It seems that there is a bug in the way the altsyncram megafunction allocates memory resources when the requested memory is not a power of 2 in terms of M4Ks. The workarround i have found is to also constrain the maximum depth parameter to 512 bytes. This is an available parameter during the memory generation if you are using the altsyncram wizzard. Of course if you are trying to instantiate onchip memory inside SOPC this parameter is not available. Perhaps in this case you could edit the onchip.v (the name depends on how you have named the memory inside SOPC) generated file after generating the system in SOPC and add there the 512 byte parameter in the defparam section. Maybe this could work.

[Altera_Forum]

Very useful replies, I will try again. I wonder if another workaround is to allocate multiple on-chip ROM segments in SOPC, so for example to get 25k, install 16k, 8k and 1k, all powers of 2. Anyway sounds like an undocumented 'feature' or a bug for Altera to look at.

[Altera_Forum]

Allocating multiple segments could also be a workarround in SOPC - Quartus environment. But i am wondering here how could then assign all this segments to a single memory section (i.e. .text) in the Nios II IDE. Do you have any ideas on this quad?

[Altera_Forum]

Specifying multiple memory segments for code or data to linkers is a normal capability, so I expect it is true also of the gnu linker. However the NIOSII IDE presents a simplified interface since it only allows a single selection in the .text memory drop-down list. So unless you create your own linker script the only option seems to be to specify sections using __atttribute__ (NIOSII software manual page 4-32). That's not very satisfactory from a maintenance/portability point of view. Maybe Altera should consider allowing multiple selections, or address the original problem of allocation granularity.

[Altera_Forum]

The problem you described is indeed very inconvenient. SOPC does not support full utilisation of the memory resources. By editing the generated vhdl files you can maximize your code or data memory.  

I have been doing this many times. Every rebuild needs manual adjustments. By choosing a code or data block bigger than you actually needs (2^x) SOPC generates the correct address lines and control signals. After code generation just downsize the number of words (not forgetting these fields in the comment lines, these are reads by the tools as well). Now synthesize the design.  Still I can not gain full utilisation of the M4Ks with one data and one code segment.

[Altera_Forum]

What you mean Debugger when you say that you still cannot gain full utilization of the M4Ks with one data and one code segment? 

 Have you also tried to set manually in the generated code the maximum depth parameter to 512 bytes and still does not work? (see my first post in this thread for some more details)

[Altera_Forum]

I did not notice the max-depth last week (sorry for not reading carrefully).  

My design used up all the m4k blocks accept for the last 5. By changing the max depth parameter in the VHDL two extra m4ks were added to my codesegment (victory!) but the last three I could not access (floor plan shows the tangling blocks).  A few hours of experimenting with these settings (that are not very clear to me) did not add new m4ks to code or data segments. Enlarging the num_words values by one m4k block causes the fitter to complain. But still, 2 extra blocks already helps. Thanks for the input.