-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different behavior compared to spike when accessing an invalid address #12
Comments
Hi,
Great, thanks :) So, i just run the sim, and remember that it in that binary, both Spike and Nax are doing what they are expected to do. I have no idea how other CPU in general handle this kind of case. As it is mostly a baremetal / no mmu case. Notice that store access fault are checked for IO accesses. I think, the spike fork could be patched to never catch regular memory store fault in order to match nax So, if you want, another way to produce an exception on store is to have a missaligned address : _start:
la x1, pass
csrw mtvec, x1
addi x1, x1, 64
addi x2, x2, 64
sw x3, 0(x0)
j fail
pass:
j pass
fail:
j fail ./obj_dir/VNaxRiscv --load-elf ../../../../ext/NaxSoftware/baremetal/play/build/rv32ima/play.elf --trace-ref --spike-debug --pass-symbol pass --fail-symbol fail
Also, seems you are looking into security stuff ? |
Thanks for your prompt reply! It seems that by setting the
Partially yes. More specifically, I would like to test this core by generating random inputs. When randomly generated, there is a high possibility of accessing an incorrect memory address. Therefore, not only missaligned load/store instructions, but also load/store instructions to invalid addresses, can be easier to test if their behavior matches with spike. I am also interested in side channels, so this will help me a lot. Thank you. |
Ahhh nice :) |
Hi, The NaxRiscv project is really great!
I am learning a lot about testing hardware designs from this project.
An error like
*** MISSMATCH PC DUT=8000000c REF=0 ***
occurred when a program containing an illegal memory access was executed by verilator. Is this an expected behavior? If the post-processing due to illegal memory accesses is matched with spike, I would expect the RTL and spike behavior to match. What could be the cause?Reproduction steps:
/NaxRiscv/ext/NaxSoftware/baremetal/test/crt.S
.make -C $NAXRISCV/ext/NaxSoftware/baremetal/test RISCV_PATH=$RISCV MARCH=rv32im MABI=ilp32
.cd $NAXRISCV/src/test/cpp/naxriscv; ./obj_dir/VNaxRiscv --load-elf ../../../../ext/NaxSoftware/baremetal/test/build/test.elf
.The text was updated successfully, but these errors were encountered: