openhwgroup
Clarification on ECALL instruction
Dear All,
I have a question regarding the handling of the ECALL instruction (32h73): In the rvfi_tracer this instruction leads to the direct finish of the simulation (https://github.com/openhwgroup/cva6/blob/master/corev_apu/tb/rvfi_tracer.sv#L60). Can you explain why this is the case? Is this just not handled at this point in time?
I am currently using a little bit older commit (44a89b9cd408b869fb4ed2c0cec35e1561588e37), as the later ones result in the issue raised in #800. Running make run-asm-tests will run the rv64ui-v-addi test which results in the test not passing (no "SUCCESS" is being printed).
I raise this issue, as one can comment out the finish statements in the tracer and the program finishes correctly. However, a synthesized version of the core will get stuck at this instruction. The synthesized core I have will run the benchmarks and other compiled programs (and most isa tests) correctly, but some of them exhibit this problem.
I would be really happy to hear back from you
Kind regards Christian
Hi @christian-lanius, this issue should be fixed in #988. The underlying problem is that #780 added RFVI_TRACER to the default defines, which intercepts ecalls as you describe above. This is incompatible with binaries that use the ecall instruction for other purposes (in particular the riscv-tests)
I wonder why it calls $finish in the first place. And it calls $finish twice in a line. Is it a mistake?
Hi @christian-lanius, a lot of RISC-V testbenches use ecall to terminate a simulation and this was added to the CVA6 testbenches some time ago. It is a bad practise as it prevents verification of the ecall (and a few other things besides), and we are in the process of fixing this.
I too have wondered about the "double finish". One of our team members (@szbieg) pointed out that some versions of Verilator require this to properly terminate. I am hopeful that by now this issue has been resolved in Verilator and so we will be able to remove it as part of our efforts to create a "proper" end-of-simulation event. In the meantime, it doesn't hurt anything. :stuck_out_tongue_winking_eye:
If this answers your questions please close this issue. Otherwise, let us know what you need.
@christian-lanius We are cleaning the "Github Issues". I assume this issue is closed. May I ask you to close it ?
