Lab3 memory organization

Lab3 memory organization

par Loïc Ted Ferrot,
Nombre de réponses : 3

Hello,

We have some troubles understanding the global memory organization described in the lab 3 instructions.

We added one on-chip memory of 4096 bytes with 32 bits data width for each of the two NIOS processors, linked solely to the Avalon data and instruction master from their corresponding processor. Then, the (offchip) SDRAM memory is connected to the two processors' data master.

However, when building the software in a uC/OS-II project for one of the processors, we get an error message  "RTES_multiproc_0.elf section `.text' will not fit in region `subsystemA_0_onchip_memory2_0' " and "region `subsystemA_0_onchip_memory2_0' overflowed by 52672 bytes".

When changing the .text memory region to the shared sdram in the BSP editor, the software compiles, but the uploaded soft doesn't seem to be executed, no printf is displayed and no bit in the PIO changes (if I understand correctly no program is executed because the instruction master is only connected to the on-chip memory, and changing the .text location to a memory to which the instruction master is not connected should be forbidden?)

Could you please clarify this?


Thanks in advance!

En réponse à Loïc Ted Ferrot

Re: Lab3 memory organization

par Sahand Kashani,

Hi,

I re-read the lab statement and it says the onchip memories are 4k x 32b (bits) => 16KB (Bytes). But from your description, I feel you've use actually 4KB total, which is way too small. Additionally, 16KB is by itself quite small and your C code will need to be very compact. With the FPGAs we have, you can easily do 32KB total for each of the 2 CPUs and still be ok. Regardless of what you do, be sure to use the "Hello world small" template for each processor when creating your C project otherwise the stdio library by itself will easily fill up most of the memory.

The Nios IDE has a tendency to use the largest memory that is connected to the Nios processor's instruction master for code (.text region in the binary). If you want to force the code to reside on the on-chip memories, you can disconnect the instruction_master from the SDRAM. In theory then only the data region of the binary could reside on the SDRAM (which you can overwrite in the linker script as you said). I'd keep everything in the on-chip memory and do manual accesses to the SDRAM using its base address defined in the system.h header file personally. Like that none of the elf data is placed in the SDRAM and it is completely empty so you can use it in your C code without risk of overwriting any code or the stack/heap (which is what I think the problem you are facing now is since your program stops; probably overwriting the stack or something).

En réponse à Sahand Kashani

Re: Lab3 memory organization

par Loïc Ted Ferrot,

Hey,

We indeed have set an onchip memory of size 4096 Bytes, and corrected it now to 16 kBytes. However the uc/OSII code still doesn't fit in the onchip memory, even without the other memory portions (that are linked to the sdram)... The "normal" hello world template (and so also the small hello world) do however fit in.

I have the feeling that when disabling some portions of the RTOS the code could be squeezed in the memory, but I don't know exactly which ones to disable, so before trying to do this I'd like to check what the instructions expect from us. Indeed it is written once "you can use RTOS uc/OSI" but then later "create a process with the RTOS".

So do we disable some parts of the RTOS, and if so which ones? Or increase even more the onchip memory size as you suggested? Or just don't use the RTOS?

Thanks for your confirmation!