Skip to content

fix: no error on h-mode SV39x4 translation#3221

Open
NicolasDerumigny wants to merge 4 commits intoopenhwgroup:masterfrom
NicolasDerumigny:master
Open

fix: no error on h-mode SV39x4 translation#3221
NicolasDerumigny wants to merge 4 commits intoopenhwgroup:masterfrom
NicolasDerumigny:master

Conversation

@NicolasDerumigny
Copy link
Copy Markdown
Contributor

@NicolasDerumigny NicolasDerumigny commented Feb 27, 2026

G-Stage translation (SV39x4/SV32x4) mandates the upper bits to be 0, not to be sign-extended.
This PR was tested working in SV39x4 mode ; we plan to add further tests for the H-Mode in a future PR.

@github-actions
Copy link
Copy Markdown
Contributor

❌ failed run, report available here.

@JeanRochCoulon
Copy link
Copy Markdown
Contributor

image

@NicolasDerumigny
Copy link
Copy Markdown
Contributor Author

I see bugs on my tests following the merge of master, some access errors in VS-mode are not forwarded correctly (maybe following speculative loads?). I will look tomorrow how to fix that.

Comment thread core/.vimrc Outdated
@NicolasDerumigny NicolasDerumigny force-pushed the master branch 2 times, most recently from 3c58b75 to ce0320b Compare March 17, 2026 10:17
@JeanRochCoulon
Copy link
Copy Markdown
Contributor

Concerning the bug you have seen. Unfortunately it is difficult for @LorenzoR01 or me to detect a regression without tests dedicated to your use case. Look forward to know whether you are able to fix the bug. For the futur, it would be good to discuss how to make the ci cover your use case. This would prevent from having again this kind of regression.

@LorenzoR01
Copy link
Copy Markdown
Contributor

Exceptions from misspredicted speculative loads are discarded on the load unit, maybe this is why some errors are not propagated.

@NicolasDerumigny
Copy link
Copy Markdown
Contributor Author

NicolasDerumigny commented Mar 18, 2026

I was mistaken. The issue is not related to speculation, but comes from the fact that you test is on SV32 mode, and I test on SV39.
In SV32x4 mode (G-Stage translation only), the address is 34-bit wide, which is not taken into account on 32-bit (CVA6Cfg.VLEN) fetch_vaddr size.

I have update the condition to be partially valid in both 64 and 32-bit versions, but the 32-bit H-mode is still broken: only 32-bit GPAs are possible instead of 34 on pure G-Stage translations.
We need either:

  • to change semantic of the fetch_vaddr in case of pure G-Stage translation to be shifted right by two bits (I do not like it)
  • to enlarge fetch_vaddr to be 34 bits (max(CVA6Cfg.VLEN, CVA6Cfg.GPLEN))), but this may also generate further errors

I also fixed #3232 (parenthesis were missing in two lines of cva6_tlb, here also tested on Verilator.

@NicolasDerumigny
Copy link
Copy Markdown
Contributor Author

NicolasDerumigny commented Mar 18, 2026

I also realized that the check is also wrong (as well as the size of lsu_vaddr_i) in both SV32 and SV39 for the data interface. I will look at that in the following weeks, probably in a follow-up PR, and after having submitted the tests I currently use.

@JeanRochCoulon
Copy link
Copy Markdown
Contributor

On next Tuesday CVA6 weekly, we will speak about adding tests to CI to test several new features. We are welcomed !

NicolasDerumigny and others added 4 commits March 24, 2026 14:42
@github-actions
Copy link
Copy Markdown
Contributor

👋 Hi there!

This pull request seems inactive. Need more help or have updates? Feel free to let us know. If there are no updates within the next few days, we'll go ahead and close this PR. 😊

@github-actions github-actions Bot added the Status:Stale Issue or PR is stale and hasn't received any updates. label Apr 24, 2026
@JeanRochCoulon JeanRochCoulon removed the Status:Stale Issue or PR is stale and hasn't received any updates. label Apr 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants