[BUG] Questasim Flow broken

[christian-lanius]

Is there an existing CVA6 bug for this?

• I have searched the existing bug issues

Bug Description

Since the changes in #1125 the questasim based simulations time out: There is no mechanism with the default Makefile to signal and end of simulation, thus the simulation times out. The following changes have to be made:

• Add +tohost_addr=80001000 to the questa-flags or questa-cmd variable. As far as I can tell, this should always be done, in order to be aligned with the test suite. This value being undefined is also the reason why there are warnings reported in the CI job (which uses verilator)
• Add RVFI_PORT back to the defines in order to get the RVFI to actually trigger the end of simulation
• Add -suppress 8607 to the vlog commands in order to work around the issue fixed in Flist: Split Flists for SV32 and SV39 to prevent Questasim elaboration errors #988

To reproduce the bug (assuming the work around for #988 is used):

1. Download the latest master branch (4f06aa6 at the time of writing)
2. Set up the riscv ISA and benchmark suite
3. Try to run any example program in questasim, which uses the tohost address to stop the simulation: make sim elf-bin=tmp/riscv-tests/build/isa/rv64ui-v-lw batch-mode=1
4. Observe the simulation failing: The to host value is 0xFFFFFFFF and the simulation only stops because of the timeout being reached

The expected behavior would be that the simulation finishes with tohost being set to 0.

[christian-lanius]

Looking at it some more, with the "default" way of compiling the test suite (running the ci/build-riscv-tests.sh script), the "tohost_addr" changes and is not always 0x80001000. This leads to some tests not passing (for example rv64uc-p-rvc and rv64ud-p-move). So just hardcoding it to that value in the Makefile is wrong.
Thus, I have modified the linker scripts for the test suite (for isa and benchmarks) to always place the tohost symbol at 0x80005000. Then, the value can be hardcoded in the Makefile.
I am unsure about a proper address for this value. Currently it is inside the main memory I think. But shouldn't it be somewhere in the unmapped (in the bis AXI interconnect in the testharness) address space?

[JeanRochCoulon]

Related to #1569