fix inconsistencies on xnxti CSR #438
Conversation
Regarding the definition of xnxti CSR, several inconsistencies have been pointed out in riscv#395, riscv#415, riscv#433, and riscv#434. This PR attempts to resolve them. Signed-off-by: Hiroo HAYASHI <[email protected]>
| if (clic.priv==M && clic.level > rs1[23:16] && clic.level > mintthresh.th) { | ||
| // There is an available interrupt. | ||
| if (rs1[4:0] != 0 && rs1 != x0) { // Side-effects should occur. | ||
| if (rs1 != x0) { // Side-effects should occur. |
There was a problem hiding this comment.
This changes can t be accepted since it is changing the initial behavior.
Currently I m starting a thread of mail with ARC to better understand what we should do.
There was a problem hiding this comment.
Thank you for your response.
This changes can t be accepted since it is changing the initial behavior.
This PR does not propose a change to the specifications.
We have to change either the pseudo code or the following descriptions.
If the CSR instruction that accesses mnxti includes a write, ...
Following the usual convention for CSR instructions, if the CSR instruction does not include write side effects (e.g., csrr t0, mnxti), then no state update on any CSR occurs.
Currently I m starting a thread of mail with ARC to better understand what we should do.
Thank you!
On the other hand, #399, I opened last July, requires changing the behavior. The current specification simply does not work (If I understand correctly).
There was a problem hiding this comment.
A thread of mail has been started to understand the best way to proceed with NXTI.
I ll keep you updated
Regarding the definition of xnxti CSR, several inconsistencies have been pointed out in #395, #415, #433, and #434. This PR attempts to resolve them.
In addition to this PR, additional explanations are needed for the following points.
I removed the following comment after each pseudo code.
This conflicts with the following sentence. (Using different CSR is reserved.)