Some suggestion

[hyf6661669]

1. I find that you use riscv32-unknown-elf-objcopy and hexdump to convert the ELF file to HEX file for simulation/FPGA BRAM initialization . I think you could have a look at https://github.com/sifive/elf2hex. This tool is more convenient if you change the regions of ROM/RAM or even make them not consecutive.

2. The opensource RTL simulation tool Verilator is said to be very fast and efficient. Many opensource risc-v cores also use it for simulation, such as rocket-chip and scr1. It's very nice if you can upload a verilator simulation script.

Finally, darkriscv is becoming more and more powerful, thanks for your amazing work!

[samsoniuk]

Thank you for the suggestions!

I installed the Verilator in my machine some weeks ago in order to add support for it, mostly because I read some interesting posts from the ZipCPU and PicoRV32 guys regarding formal verification and related stuff... unfortunately I found no much free time to learn about it, but for sure I will add support for Verilator in the future.

About the elf2hex, I checked it, but unfortunately they call the objcopy in the exactly same way, which means that the problem is almost the same, i.e. the intermediate binary has a huge pad area between the ROM and RAM areas when you resize and move that areas to other locations. Of course, the hexdump trick is not much better, but I guess the root of the problem is more in the objcopy side. Just in case, I checked some possibilities regarding the objcopy itself and I found that objcopy already includes the option to generate the verilog output and it is possible selected specific sections, in a way that there is no need to generate the pads between the ROM and RAM areas anymore:

riscv32-embedded-elf-objcopy --only-section .text* -O verilog darksocv.o darksocv.rom
riscv32-embedded-elf-objcopy --only-section .data* -O verilog darksocv.o darksocv.ram

Almost perfect, but it does not work correctly because the ROM and RAM are 32-bit wide in the darksocv and the objcopy generate an output which is 8-bit wide only. It is possible interleave the output and generate separate four separate files in order to load them in separate 8-bit memories, but it appears to be too much complex, at least for the darksocv memory configuration.

Maybe you found it useful for some different memory configurations that you use, but in the case of 32-bit wide ROM and RAM, I found no much ways to use this output and, instead I found that an intermediary solution appears to works better and with less effort:

$(PROJ).rom.bin: $(PROJ).o
    $(OC) $(OCFLAGS) $< $@ --only-section .text*
    $(OD) $(ODFLAGS) $< > $(PROJ).rom.lst

$(PROJ).ram.bin: $(PROJ).o
    $(OC) $(OCFLAGS) $< $@ --only-section .data*

$(PROJ).rom: $(PROJ).rom.bin
    hexdump -ve '1/4 "%08x\n"' $< > $@
    wc -l $@
    echo rom ok.

$(PROJ).ram: $(PROJ).ram.bin
    hexdump -ve '1/4 "%08x\n"' $< > $@
    wc -l $@
    echo ram ok.

This case uses the objcopy in order to generate binary outputs for different sections and then convert it directly via hexdump, but in a way that the tools are agnostic about location, length and relative position between them! Of course, I need some days in order to change the ROM and RAM configurations in the linker script and in the darksocv in order to test it... case it works, I will update that changes in order that we can get a more flexible memory configuration in the darkriscv and support large ROM and RAM areas.

Regards, Marcelo

[samsoniuk]

I will split this issue in two separate issues:

a) elf2hex suggestion: I need think about different scenarios where objcopy and hexdump will not work... b) Verilator support: will be provided in a new issue #33