How to get unused global variables into the IMEM as ROM

[Sam-Vervaeck]

I have a header file with test values that I would like to include in my IMEM as ROM. Currently, not all of them are used yet, so the compiler/linker optimizes them away. This is a slight problem because I do want to know how much the ROM image would increase in size if I would include the whole header file.

Therefore, i added my own section to the linker script and set it to be kept: KEEP(*(.retain_global)). I added all the initialised globals to that section as well: __attribute__((section(".retain_global"))).

Now the .text segment does show an increase in size but the final exe or vhdl image still has the size of the globals not being included? I thought it maybe had something to do with the NEORV32 image_gen.c program, but that seems to contain only packaging software, no actual compilation software... What am I missing?

../../../sw/lib/source/neorv32_uart.c: In function 'neorv32_uart_setup':
../../../sw/lib/source/neorv32_uart.c:90:2: warning: #warning UART0_SIM_MODE (primary UART) enabled! Sending all UART0.TX data to text.io simulation output instead of real UART0 transmitter. Use this for simulations only! [-Wcpp]
   90 | #warning UART0_SIM_MODE (primary UART) enabled! Sending all UART0.TX data to text.io simulation output instead of real UART0 transmitter. Use this for simulations only!
      |  ^~~~~~~
Memory utilization:
   text	   data	    bss	    dec	    hex	filename
2760772	      0	    116	2760888	 2a20b8	main.elf
Compiling ../../../sw/image_gen/image_gen
Executable (neorv32_exe.bin) size in bytes:
4396

Meanwhile the main.elf does have the correct size of 2.8 MB

[Sam-Vervaeck]

This actually made me think about the relationship between IMEM/DMEM and BRAM in general leading to the following more general question:

(background)

This was related to this discussion on a 64-bit DMA access: #981 (comment)

+---------+    32-bit    +------------------+    64-bit    +----------------------+
| NEORV32 |------/------>| AXI Interconnect |------/------>| BRAM / external DMEM |
+---------+              |                  |              +----------------------+
                         |                  |
+---------+              |                  |
|         |              |                  |    64-bit    +---------------------+
| Vivado  |------/------>|                  |------/------>| Your accelerator IP |
| AXI DMA |    64-bit    |                  |              +---------------------+
|         |------/------>|                  |
+---------+              |                  |----+
    ^                    +------------------+    |
    |          32-bit                            |
    +------------/-------------------------------+
       AXI4-lite for DMA configuration

I was going to copy the data to the external DMEM maybe, but I just realised that might not be possible since it could be >2MB of data and my genesys2 board only has 16 Mbits of BRAM available, so that is only 2 MB that can fit in BRAMS.

(background end)

Question: If the IMEM/DMEM have an address space of gigabytes, then how can they ever be mapped to BRAMs on an FPGA. There is no FPGA with that much space no?

[stnolting]

I have a header file with test values that I would like to include in my IMEM as ROM. Currently, not all of them are used yet, so the compiler/linker optimizes them away. This is a slight problem because I do want to know how much the ROM image would increase in size if I would include the whole header file.

What do your test values look like? Just simple constants?

const test_a uint32_t = 123;

Therefore, i added my own section to the linker script and set it to be kept: [...]

Good idea! But I think the linker is smart enough to trim all non-referenced symbols (and sections). Therefore, I also think that it would be pointless to use attributes here (e.g. __attribute__((unused))).

However, you can explicitly tell the linker which symbols you want to keep. For example, if you have this constant (placed in the .rodata section):

const char some_array[] = "this is a test!"; // 15 chars + zero-termination = 16 bytes

If you compile this and check the .rodata section we get 0x370 bytes there (this is the reference; in this case some_array will be trimmed):

$ make clean_all exe elf_sections
...
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 001000 001044 00  AX  0   0  4
  [ 2] .rodata           PROGBITS        00001044 002044 000370 00   A  0   0  4
...

Now if you tell the linker to keep this specific symbol (-> -Wl,--undefined=some_array) we'll get a .rodata size of 0x380 bytes (so some_array is still there):

$ make USER_FLAGS+=-Wl,--undefined=some_array clean_all exe elf_sections
...
There are 20 section headers, starting at offset 0x1831c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 001000 001044 00  AX  0   0  4
  [ 2] .rodata           PROGBITS        00001044 002044 000380 00   A  0   0  4
...

Question: If the IMEM/DMEM have an address space of gigabytes, then how can they ever be mapped to BRAMs on an FPGA. There is no FPGA with that much space no?

You cannot map the entire address space to BRAMs - but you could map it to external memory (for example by using a DDR memory controller).

[Sam-Vervaeck]

What do your test values look like? Just simple constants?

Currently, it is a header file with mainly uint64_t arrays (I added the file with the constants):
fullEnc.h.txt

Now if you tell the linker to keep this specific symbol (-> -Wl,--undefined=some_array) we'll get a .rodata size of 0x380 bytes (so some_array is still there):

Hmmmmm, this works for one variable but a bit impractical to do for 50+?

[stnolting]

Hmmmmm, this works for one variable but a bit impractical to do for 50+?

You could do USER_FLAGS+="-Wl,--undefined=var1 -Wl,--undefined=var2 -Wl,--undefined=var3 ..." or you could try to unify all your variables as a single element (maybe a struct).

[Sam-Vervaeck]

Yeah, I'll try some of those suggestions out, thank you!