using Dual Port Memory with simple Nios II Qsys system

[Altera_Forum]

Hi all, 

I created a Qsys system with an internal Onchip memory dual port RAM (internal port s1, and exported port s2) I would like to be able to write data from s2 (my test bench) and read data from s1 (nios). I connected s1 to data master (only). I chose to initialize the RAM from an init_file. I created a C application that run on this system using eclipse. When simulating the design with modelsim, I have the following problems: at 0 ns : the RAM is initialized with init_file (ok) Then a little bit later, event before my first message from the C world ("hellow world") appears, I get write accesses from the nios into the RAM (port s1) I don't understand why. PS. I tried, for test purpose only to make it a ROM under Qsys, after rebuilding the project, eclipse reduced the free stack + heap report: Info: (cpu_sgen.elf) 56 KBytes program size (code + initialized data). Info: 5380 Bytes free for stack + heap. It was  Info: (cpu_sgen.elf) 56 KBytes program size (code + initialized data). Info: 59 KBytes free for stack + heap. where size of Dual port RAM = 65536 bytes  My questions: Is it correct to use an onchip memory RAM from Qsys to store data other than the program code (.elf)? Why eclipse reduced the free stack + heap parameter ? Any suggestions about the problem I have? Thank you.

[Altera_Forum]

I think you have nios memory sections mapped to that onchip ram: I mean .rwdata, .rodata, .stack and .heap 

Check your linker script file or linker configuration in bsp settings.

[Altera_Forum]

--- Quote Start ---  I think you have nios memory sections mapped to that onchip ram: I mean .rwdata, .rodata, .stack and .heap Check your linker script file or linker configuration in bsp settings.  --- Quote End ---    Thank you. Exactly I checked in the project summary and it shows: [h=3]Linker Section Mappings[/h]    [TH="width: 50%, align: left"]Section [/TH] [TH="width: 50%, align: left"]Region[/TH]      .text onchip_memory2_0      .rodata memory_points       .rwdata memory_points      .bss memory_points      .heap memory_points      .stack memory_points    Where memory_points is my Dual port RAM. I'm doing NIOS simulation for the first time. Do I have to manually modify these linker parameters ? If yes how can I easily do it ?

[Altera_Forum]

If onchip_memory2_0 is already connected to nios data master port, you simply can change this linker configurations from memory_points to onchip_memory2_0 and rebuilld.  

Instead if onchip_memory2_0 is connected to nios instruction master only, while memory_points is connected to nios data master only, you first need to add a data master connection to onchip_memory2_0 (however keep connection to memory_points!).  Then you must rebuild all, I mean Qsys system, Quartus project, bsp and Nios software. In case onchip_memory2_0 is not big enough to store both code (.text) and data sections, you'd have to add another onchip memory block and map sections there.

[Altera_Forum]

--- Quote Start ---  If onchip_memory2_0 is already connected to nios data master port, you simply can change this linker configurations from memory_points to onchip_memory2_0 and rebuilld.  Instead if onchip_memory2_0 is connected to nios instruction master only, while memory_points is connected to nios data master only, you first need to add a data master connection to onchip_memory2_0 (however keep connection to memory_points!).  Then you must rebuild all, I mean Qsys system, Quartus project, bsp and Nios software. In case onchip_memory2_0 is not big enough to store both code (.text) and data sections, you'd have to add another onchip memory block and map sections there.  --- Quote End ---    That's exactly what I did: onchip_memory2_0 is connected to data master and instruction master. Now I understand that it's not big enough to stroe code and data sections that's why my memory_points is used ... Now, can I just increase the size of onchip_memory2_0 instead of adding an other onchip memory ?

[Altera_Forum]

--- Quote Start ---   Now, can I just increase the size of onchip_memory2_0 instead of adding an other onchip memory ?  --- Quote End ---   Sure.  That's the best options if you don't have strict performance requirements where you'd rather prefer keep separate memories for instruction and data

[Altera_Forum]

If you are trying to do very specific assignments of code and data to specific memory blocks (eg because of the way they need to be dual-ported, or because you want all code and data accesses to by 'tightly coupled') then you'll almost certainly need to write your own linker script. 

In particular, if you want the code to be 'pure' (ie contain no data), the .rodata (etc) will need to linked with the read-write data and not the code. You also can't use the Altera-built gcc4 as that puts switch statement jump tables directly into the code segment.

[Altera_Forum]

--- Quote Start ---  If you are trying to do very specific assignments of code and data to specific memory blocks (eg because of the way they need to be dual-ported, or because you want all code and data accesses to by 'tightly coupled') then you'll almost certainly need to write your own linker script.  --- Quote End ---   I think a __attribute__ ((section (<section name>))) directive is enough in most cases, especially if you need 'very specific' assignments.    --- Quote Start ---  You also can't use the Altera-built gcc4 as that puts switch statement jump tables directly into the code segment.  --- Quote End ---   I can't see any reason for placing jump tables in places other than code segment. Jump tables are strictly bound to the code they are generated for; in other words they ARE part of the code.

[Altera_Forum]

Specifying the section name will assign the data to a section, you then need the linker script to assign the sections into the correct memory blocks, and probably is the desired order (and possibly at fixed offsets with the blocks). 

I also use the linker script to assign constant symbols for IO locations - I arranged for a lot of the IO and all the 'normal' memory to be within a single 64k range so that it can all be accessed relative to %gp.  If you have tightly coupled instruction memory and tightly coupled data memory (probably without any data cache) you want the jump tables in the data memory - where you get single cycle access - not in the instruction memory where a slow Avalon cycle is needed.  Since we load code using a different avalon master (PCIe) the cpu doesn't even have data access to its instruction memory.