Mismatch on VM SV32 reserved tests #1198
Comments
|
Transferring this issue to the CVW repo |
|
This is great. Can you give some more lines of context around the —lockstepverbose to know exactly what is triggering this?
… On Dec 18, 2024, at 1:48 PM, Muhammad Zain ***@***.***> wrote:
Executing "wsim rv32gc arch32vm_sv32" runs virtual memory SV32 tests on Wally. All SV32 tests succeed, but reserved tests fail, showing us a mismatch. Following is a snippet of the output.
# rv32i_m/vm_sv32/src/vm_nleaf_pte_level0_S_mode.S succeeded. Brilliant!!!
# rv32i_m/vm_sv32/src/vm_nleaf_pte_level0_U_mode.S succeeded. Brilliant!!!
# Error on test rv32i_m/vm_sv32/src/vm_reserved_pte_S_mode.S result 138: adr = 80c03338 sim (D$) 0000000f signature = 0000000c
# ** Note: $stop : /home/mzain/cvw/testbench/testbench.sv(963)
Executing "wsim rv32gc /home/user/cvw/tests/riscof/work/riscv-arch-test/rv32i_m/vm_sv32/src/vm_reserved_pte_S_mode.S/dut/my.elf --lockstepverbose" shows us that it is being caused due to a fetch exception.
# Info MEMRM 0x80c02914 0x80c02914 4 202000cd L1 (refRoot/cpu/64-bit Supervisor Physical unified)
# Info 783: 'refRoot/cpu', 0x00000000917ffffc: Supervisor *** FETCH EXCEPTION ***
# Info MEMRM 0x80c02914 0x80c02914 4 202000cd L1 (refRoot/cpu/64-bit Supervisor Physical unified)
This problem is occurring with the following reserved tests:
vm_reserved_pte_S_mode
vm_reserved_pte_U_mode
vm_reserved_rwx_pte_S_mode
vm_reserved_rwx_pte_U_mode
In order to recreate this, we need to pull SV32 tests from riscv-non-isa/riscv-arch-test#516 <riscv-non-isa/riscv-arch-test#516>. Run make in cvw to compile these tests and then use the above wsim commands to run them.
—
Reply to this email directly, view it on GitHub <#1198>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA36ETL55GWSGOALP2TT2GHURVAVCNFSM6AAAAABT3TYQ3GVHI2DSMVQWIX3LMV43ASLTON2WKOZSG42DQOBQHAYDQNA>.
You are receiving this because you are subscribed to this thread.
|
|
Sure. These are the instructions being executed before the fetch exception. |
|
And some context after the exception as well, please. :)
It looks like the code is doing a jalr to 917ffffc, which may be causing an exception in the reference model (ImperasDV). Can you check what the page tables contain for that address, perhaps reserved values of XWR? If you’d like to try debugging, you can look at tlbcontrol.sv. Perhaps Wally doesn’t throw an exception on reserved PTE XWR fields, while ImperasDV does?
|
|
@Zain2050 : @rosethompson is experiencing a similar issue that Breker throws a page fault and Wally doesn't. I don't know if the two issues are related, but it's definitely timely. If you can get to the root cause and fix soon, it would confirm or refute the two mismatches being related. |
|
Did you find the root cause of the mismatch? The Breker page fault is a related to non-leaf PTE non-zero dirty, access, and user bits. Breker expects to generate a page fault and Wally does not. |
|
@zain was working on this, but no word yet.
How about we modify tlbcontrol to page fault on all of those to match Breker, and see if that also matches ImperasDV? Can you make the PR, and then Zain can test riscv-arch-test?
… On Dec 20, 2024, at 8:29 AM, Rose Thompson ***@***.***> wrote:
Did you find the root cause of the mismatch? The Breker page fault is a related to non-leaf PTE non-zero dirty, access, and user bits. Breker expects to generate a page fault and Wally does not.
—
Reply to this email directly, view it on GitHub <#1198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA35EGI24YXW6W77UL232GRAX3AVCNFSM6AAAAABT3TYQ3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGMZDGNZSGY>.
You are receiving this because you commented.
|
|
We actually have to modify the HPTW because it's a non-leaf PTE which will cause the fault. I've already made a patch and demonstrated it matches Breker. However I'm not convinced it's actually the correct thing to do. The spec just says the bits are reserved and should be zeroed by software for forward compatibility. There is no mention of faulting. |
|
Can you tell what ImperasDV does in this situation?
… On Dec 20, 2024, at 8:50 AM, Rose Thompson ***@***.***> wrote:
We actually have to modify the HPTW because it's a non-leaf PTE which will cause the fault. I've already made a patch and demonstrated it matches Breker. However I'm not convinced it's actually the correct thing to do. The spec just says the bits are reserved and should be zeroed by software for forward compatibility. There is no mention of faulting.
—
Reply to this email directly, view it on GitHub <#1198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA32LBBIJ2ID32YRTSK32GRDG7AVCNFSM6AAAAABT3TYQ3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGM3TINBVGM>.
You are receiving this because you commented.
|
|
I haven't been able to get ImperasDV to run with Breker. |
|
Is that because of the different configuration or is there a different issue going on?
… On Dec 20, 2024, at 9:00 AM, Rose Thompson ***@***.***> wrote:
I haven't been able to get ImperasDV to run with Breker.
—
Reply to this email directly, view it on GitHub <#1198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCDBCUEF5NUZFKCOSQFZ3T2GREMVAVCNFSM6AAAAABT3TYQ3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGM4TAMJTGA>.
You are receiving this because you commented.
|
|
@jordancarlin Were you able to get the two running together on chips? When I try to run them together they just hang loading uvm_dpi.so |
|
I have to copy over the imperas.ic file first, but yes. I get a mismatch almost immediately, but I assume that is because the memory map in the imperas.ic file I am using doesn’t match the Breker config.
It hangs on the loading uvm_dpi.so for about a minute, but then proceeds like normal.
… On Dec 20, 2024, at 9:19 AM, Rose Thompson ***@***.***> wrote:
@jordancarlin <https://github.com/jordancarlin> Were you able to get the two running together on chips? When I try to run them together they just hang loading uvm_dpi.so
# Loading /opt/mentor/questasim/questasim/questasim/uvm-1.1d/linux_x86_64/uvm_dpi.so
—
Reply to this email directly, view it on GitHub <#1198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCDBCX7HMNAWLFH4526WSD2GRGTLAVCNFSM6AAAAABT3TYQ3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJXGQYTOOBTGE>.
You are receiving this because you were mentioned.
|
|
That probably explains it. I figured it would error out immediately rather than hang with the wrong imperas.ic, but instead it just hangs indefinitely. |
|
My apologies for the late response. I read the test file. First it sets WX bits and then performs sw (W), lw (R) and jalr (X), from which we expect 3 faults. From the logs, I observed that sw and lw are correctly triggering faults and the mismatch occurs on jalr. DUT tries to execute the instruction instead of raising an exception, which in turn leads to mismatches in CSR values. |
|
In tlbcontrol.sv, reserved encoding logic is correctly implemented. However, it is only checked for DTLB (Data TLB) and not in the case of ITLB (Instruction TLB). I might be wrong, but I think this is the cause of the problem. Can someone verify that what I did was right? |
|
@Zain2050 that looks like you've got it! Excellent work! Finding and fixing real RTL bugs is one of the most important outcomes of all this DV work. If you are up for it, the next step would be to make a PR to cvw for your RTL fix. Think carefully about implementing RTL changes in the best possible way. This often involves reading the rest of the file and understanding the context where you are making the change. Where there's one rat, there are many rats, so think about whether the bug you are fixing is an instance of a larger class of possible bugs, and try to fix all of them at once if you can find any others. run "regression-wally --fcov" and regular "regression-wally" to test the fixe. Then make a PR to cvw. When the PR is accepted, close this issue with a message cross-referencing the PR that fixed it. |
|
Thanks a lot! I'll review it thoroughly, check for similar issues, and make sure I haven't broken anything. Once everything looks good, I'll make a PR. |
|
This issue has been fixed by PR #1206. Therefore, closing it. |
Executing "wsim rv32gc arch32vm_sv32" runs virtual memory SV32 tests on Wally. All SV32 tests succeed, but reserved tests fail, showing us a mismatch. Following is a snippet of the output.
Executing "wsim rv32gc /home/user/cvw/tests/riscof/work/riscv-arch-test/rv32i_m/vm_sv32/src/vm_reserved_pte_S_mode.S/dut/my.elf --lockstepverbose" shows us that it is being caused due to a fetch exception.
This problem is occurring with the following reserved tests:
In order to recreate this, we need to pull SV32 tests from riscv-non-isa/riscv-arch-test#516. Run make in cvw to compile these tests and then use the above wsim commands to run them.
The text was updated successfully, but these errors were encountered: