How do Vivado and Vitis determine where stack and heap are located?

Question

Been taking advantage of lockdown to learn how to work with softcores and C on Vivado/Vitis, using a Digilent CMOD A7 board I have.

I managed to get the out of box demo built and running, but I hit a problem which was that the board always died on the memory test routine. I also had some erratic behaviour of the USB programming/debug link. The memory being tested is the external 512KB SRAM on the board.

Eventually I realised that the system was set up so that that external RAM is used as heap, stack and so on, so the memory test was stomping on the system working memory and causing the crash.

Looking in my build files, I did indeed find two copies of the linker script in my tree. One of them defines the FPGA internal memory as the working area, the other (the one in my Vitis build) defines the external RAM. (I'm not quite sure how I managed this, but I did have to do quite some fighting with Vivado/Vitis to get running.)

But when I try to replace the file in Vitis with the good one, it complains then that the board config is not valid. So I guess that the linker script cannot be manually edited like this. It seems that working memory is defined somewhere in Vibado, and then ends up as part of the board config.

I searched the Xilinx docs for something on this, but could not find any place in Vivado or Vitis where the working memory used by the system is defined.

Can anyone explain to me how to reconfigure my system to use internal FPGA memory for the processor stack, heap, etc?

Answer 1

I found the answer. It's fairly straightforward.

The manual edit of the lscript.ld linker file caused Vitas (for some reason) to not like the board config - but in fact just ignoring it's complaints and carrying on was fine after a build/program cycle.

The better way to change the memory map for heap and stack though, is to right click the project and select "Generate linker script". Now you get a window to specify in which memory blocks stack, heap and so on live, and how big they are. This regenerates the lscript.ld file, and all is well.