When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says: Implementations may convert some invalid address patterns into

When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says: Implementations may convert some invalid address patterns into

Yes: X (our implementation conforms to this constraint or implements XLEN bits)

Allen, How is compliance testing going to handle this issue for software (versus hardware) writes to *tval CSRs? For example, when software writes stval with an address, how is the validity judged?

I focused on the HW writes to mtval when I described the Rocket core's behavior to Allen. The behavior for SW writes is that it unconditionally sign-extends from the most-significant implemented bit:

That sounds good. It would be great to see this software write behavior added to the Priv spec (along with whatever hardware write behavior that Allen's polling concludes with). Thanks, Greg

Thanks for your input, as always. I agree that, if we ultimately agree to tighten the behavior here, we need to specify the behavior for both HW and SW writes.

Hi Andrew, all, The current priv spec reserves lower 2bits of mtvec (ad stvec) to indicate vectored interrupts, there’s an issue that if exception handler is word aligned but SW mis-program the

I have been bitten by this, too, but I have little in the way of advice. There are various software approaches to reduce the likelihood of encountering this problem, even if the programmer forgets to

Are we going to use bit1 soon in the future? We are wondering if we can use bit1 to indicate there’s illegal value (WLRL) – if bit1 is written with 1 then fire exception. From:

It's already used: https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#44-new-xtvec-csr-mode-for-clic

Lol Do you feel it is worth to add a bit in sstatus to restrict csrw stvec to 1) mask bit1~0; 2) fire an exception when writing non-0 value to bit1~0? A separate elf section can work in some

I think this is one of dozens of little mistakes you can make in bare-metal RISC-V programming, and adding an sstatus bit for it is IMO not a great allocation of resources. Hopefully you are

I think the solution is even simpler. Even if MTVEC[1] had not been used, data dependent traps are prohibited in Risc-V (that might be too strong a word; I don't know that its explicited prohibited,

Greg Favor wrote: The overriding statement in the document is this one: When misa[7] (bit H) is clear, the hart behaves as though this extension were not implemented, .... I sympathize with

Thanks. This is the interpretation we expected to be correct. For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as though this

And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.

While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero). So there isn't

Couldn't you just change the wording to be "disabled" when referring to having misa.H=0 and leave "unimplemented" to mean having misa.H hardwired to 0? Jonathan

My response to Allen's post and my use of "unimplemented" in quotes was referring to the H extension spec's statement that "When misa[7] is clear, the hart behaves as though this extension were not