onchip memory granularity

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

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.

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.

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?

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.

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.

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

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