[verilator] Load elf instead of vmem

[imphil]

Currently we need to pre-process elf files into vmem files to load them into a Verilator simulation (through $readmemh()). It would be nice if we can improve Verilator to directly load elf files.

Steps towards that:

• Use libelf to convert elf file into binary. Sample code e.g. https://github.com/opensocdebug/osd-sw/blob/master/src/libosd/memaccess.c#L167 or all across the Internet. (No, not beautiful.)
• Load the memories with this binary data.
  • Either convert the binary into vmem, dump it to a temporary file, and then use $readmemh()
  • Or (preferred) directly write the mem variable in the prim_generic_ram_1p.sv & Co. through Verilator. Either by making it /* verilator public*/ or through a task/function in the SV code, similar to the simutil_verilator_memload function in prim_generic_ram_1p.sv & Co.

There might be existing code out in the internet that does that, it might be worth googling first :-)

[imphil]

@towoe please assign this to yourself if you want to give it a try, and let me know if you have any questions.

[towoe]

Thanks @imphil for putting this down. I will give it a try!

[towoe]

I've created a small sample Verilator example which uses libelf to access the data, same as your previous work @imphil, and /* verilator public */. I used this to test stuff as our main Verilator build takes quite some time.

So do we want to load ROM and Flash with this method?
Quick method would be to hard code the path of each instance.
Not sure if it is even possible, but would be nice to check for the addresses used in the bus and correlate with the ELF addresses.

Do we load the first segment of each file into the memory?
I am not an expert on ELF but a segment has no associated name as with a section.
But we do control the link process so we can make sure the first, (&& PT_LOAD), segment contains the relevant data (which we already have).

[imphil]

I used this to test stuff as our main Verilator build takes quite some time.

Replace -O2 in the fusesoc file with -O0 to get faster test builds.

So do we want to load ROM and Flash with this method?
Quick method would be to hard code the path of each instance.

We already hardcode a hierarchical path to each memory, you can use this path for this work as well.

Not sure if it is even possible, but would be nice to check for the addresses used in the bus and correlate with the ELF addresses.

That won't be possible. You need to start writing at address 0 of the respective memory.

Ultimately, you need to write the memory with the same data that objdump creates when transforming an elf file into a bin file. The code in Open SoC Debug should do that.

[towoe]

Replace -O2 in the fusesoc file with -O0 to get faster test builds.

Thanks for the tip!

So do we want to load ROM and Flash with this method?

Rephrasing this, what should we do with the RAM section? There is currently a method to load data into RAM but maybe we will get rid of this?

Quick method would be to hard code the path of each instance.
We already hardcode a hierarchical path to each memory, you can use this path for this work as well.

True. My current approach will reuse the scope method and use a function on the SV side in order to make it more obvious how the memory is updated.

Not sure if it is even possible, but would be nice to check for the addresses used in the bus and correlate with the ELF addresses.

That won't be possible. You need to start writing at address 0 of the respective memory.

Will write to address 0 of the memory. But my idea, which I still think will not work, would be to select the appropriate memory based on the address in the elf file.

Ultimately, you need to write the memory with the same data that objdump creates when transforming an elf file into a bin file. The code in Open SoC Debug should do that.

I am assuming you meant objcopy and also that this should only include the "text" segment, so in our current situation objcopy -R .data -R .bss -O binary file.elf load.bin. Create the bin file without the .data/.bss section.

[imphil]

Rephrasing this, what should we do with the RAM section? There is currently a method to load data into RAM but maybe we will get rid of this?

Treat them all the same: you have a binary and want to load it into a memory space. From the view of Verilator, it doesn't make a difference if that memory is called ROM, RAM, or flash. We (most likely likely) won't have a single elf file that needs to be split between the three.

[towoe]

Supported by #1091