--- Quote Start ---
Not strictly true. If you put the .rodata elsewhere, and load the code from another Avalon master (or from within the fgpa image itself), then the nios cpu doesn't need data access to its own code.
--- Quote End ---
Right. I had understood it. But in this case I'd need another master connected to tcm (which is substantially the same I did now through nios data master port) or I'd have to recompile Quartus design with the generated tcm initialization hex file EVERY TIME I modify my code (which is not really advisable for debugging...)
--- Quote Start ---
I presume you meant 'data'
--- Quote End ---
Exactly. Sorry
--- Quote Start ---
This is because your linker script is wrong.
You should be able to get the linker to put the data items such that both paddr and vaddr are correct (the current vaddr value).
For instance, if you want to initialize a large block of M9K memory, and your main code is in TC memory. then you don't want the initialisation data appended to your code - there just isn't space there.
--- Quote End ---
That's right, too. But I didn't want to use a custom linker script. I used the default setting and simply mapped a few object to tcm.
Is there any sample of linker script available? I'd like to perform these operations in this way but I don't want to read the whole linker manual.
Another question: can the attribute directive be extended to a group of functions/variables without tagging every function?
I conclude (I hope) this long thread, sharing the final results of moving the code to tcm.
I'll give the critical code execution times worst/better case.
Original design, everything in sdram:
205/274
Moved most critical functions to tightly coupled code memory:
160/194
Like above but also moved stack to tightly coupled data memory
145/158
I can say it's worth it.
Again, thank you all
Cris
Honored Contributor
