Additional configurability needed for `misa` writability

[jordancarlin]

Right now, we have a global writable_misa config option that makes the entire misa CSR read-only or read-write. Implementations can make each individual extension bit read-only or read-write, so we need additional granularity here. For example, Spike makes the U and S bits read-only but the rest of the extension bits read-write.

UDB uses MUTABLE_MISA_A, MUTABLE_MISA_B, etc. as the parameters that control this. We probably need to do something similar.

[allenjbaum]

As we discussed in the tests plan meeting today, any CSR which has a WARL field (which can include the entire register if it a single field) needs this, so I think special casing the mechanism is a mistake, and a general mechanism should be designed E.g. CSRs should have XLEN width parameters such as: <CSRNAME[>_WRITE_MASK 1's in a bit position indicate that the bit in the corresponding position is not writable (default to All0?) <CSRNAME>_ WRITE_VALUE 1's in a bit position indicate the value of the bit in the corresponding bit position when not writable (default to All0?), else is 0. log2 XLEN width parameters <CSRNAME[_FLD}>_ WRITE_RANGE_LO indicates the lowest legal value allowed to be written to a writable field (default to 0) <CSRNAME[_FLD}>_ WRITE_RANGE_HI indicates the lowest legal value allowed to be written to a writable field (default to all1) If sign extension is needed, it is implied by (RANGE_LO < 0 ) and (writable_field_MSB < architectural_field_MSB) Field ranges are constrained by FIELDWIDTH (defined below) or 2^FIELDWIDTH parameters (FIELDWIDTH is the width of a contiguous writable field, as defined by intersection of WRITE_MASK and the architectural field definition), <CSRNAME[_FLD}>_ WRITE_LEGAL 1's in a bit position indicate that the field can be written with value of the bit position (writable field widths must be <=log2(XLEN) ) (no default ) FLD is only required if there is more than one field >1 bit wide that has constraints on their values. These are not required if all values are legal, and both WRITE_RANGE and WRITE_LEGAL can not both be defined So, if XTVEC is limited by security concerns to be some 1MB section of the address space at 4K boundaries WRITE_MASK would be 0xFFF0_0FFF, WRITE_VALUE would be 0xNNN0_0000 WRITE_RANGE would be optional if it could be anywhere in that 1MB range, or could be an 8B number if , say, only pages 127,128 were allowed instead of the entire 0..255 The above should be able to deal with just about every parameter that comes to mind (except those that are functions of some other CSR bit, like the value of XATP.MODE field)

…

On Mon, Feb 2, 2026 at 8:59 AM Jordan Carlin ***@***.***> wrote: *jordancarlin* created an issue (riscv/sail-riscv#1517) <#1517> Right now, we have a global writable_misa config option that makes the entire misa CSR read-only or read-write. Implementations can make each individual extension bit read-only or read-write, so we need additional granularity here. For example, Spike makes the U and S bits read-only but the rest of the extension bits read-write. UDB uses MUTABLE_MISA_A, MUTABLE_MISA_B, etc. as the parameters that control this. We probably need to do something similar. — Reply to this email directly, view it on GitHub <#1517>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJRSFG2THLQLXIYBCV34J57AFAVCNFSM6AAAAACTWUOUJSVHI2DSMVQWIX3LMV43ASLTON2WKOZTHA4DOMBQGQYDSMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Timmmm]

Yeah I'm undecided on whether we should special case it or not. On the one hand you probably can apply some simple generic configuration to all CSRs - which bits are writable, their reset values, etc. On the other hand there are definitely fields where we're going to need custom stuff (e.g. satp[MODE]). Also bitmasks are not super ergonomic. And they have the disadvantage of having state that does nothing; i.e. some bits will be read-only even if you think you've configured them to be read-write. I guess you could do it on a per-field basis?

Probably something we should discuss in the meeting? We might want to make PRs for both options and see which one ends up nicest.

[pmundkur]

It's likely we would need both approaches for the same CSR. For e.g, in mideleg, bits[xlen-1:16] may need a bitmask, but the standard interrupts in the lower bits might need individual settings. It doesn't make sense to delegate S-mode interrupts if S-mode is not configured, something that's awkward to capture and validate using bitmasks covering the whole CSR.

[jordancarlin]

I agree that bitmasks don't seem like the best option for all CSRs. For large WARL fields, they are a good fit, but for registers like misa with individual fields, I think separate parameters are easier to use, both in the sail code and for end users creating their configs.

[allenjbaum]

I just sent somethign about (in some forum) about a proposal for a single schema to handle all CSRs: WtMask,RdValue ( each bit indicates whether a bit is RW and, if not, what it's value is, and per/field (for fields >1 bit) either the range of possible values (low to high) or an enum mask of legal values (for fields <=6 bits) There are reasonable defaults that would reduce the amount of configuration required. I think this will handle everything I can think of that are likely anyone would implement. Separately, there is the mapping of illegal write values to legal values, and I think this can be reduced to 3 bits: ignore write, [lowest/highest ]value, [next/closest ]value ties go [lower/higher].

…

On Tue, Feb 3, 2026 at 7:48 AM Jordan Carlin ***@***.***> wrote: *jordancarlin* left a comment (riscv/sail-riscv#1517) <#1517 (comment)> I agree that bitmasks don't seem like the best option for all CSRs. For large WARL fields, they are a good fit, but for registers like misa with individual fields, I think separate parameters are easier to use, both in the sail code and for end users creating their configs. — Reply to this email directly, view it on GitHub <#1517 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJVY5FX6SOUE3PNVT4L4KC7OFAVCNFSM6AAAAACTWUOUJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNBSGA4TKNRWGY> . You are receiving this because you commented.Message ID: ***@***.***>

[allenjbaum]

RE special handling: Special cases is not a good argument for implementing something once for the vast majority of non-special cases.
And, yes, here are definitely case where some special handling is needed, mostly when the legal values in one field have dependencies on some other CSR field (in the same or a different CSR). That doesn't go away, but doesn't rule out mask/value pairs; it may mean you just need two of them depending on the value of the field,
With that , it siply means you select mask/value fields depending on something more than just the CSR number.

RE: bitmasks are not super ergonomic: requiring a page of code handling every field in a register full of them isn't either.

RE: The disadvantage of having state that does nothing; i.e. some bits will be read-only even if you think you've configured them to be read-write.
If you think you've configured it as RW, either you have, and it is, or you haven't and you're mistaken. That's an implementation bug (which will likely get caught be tests). Writing 1s into a RdOnly0 field or 0s into a RdOnly1 field leaves the field unchanged, which is exactly the way that readonly fields in non-readonly CSRs are supposed to work.
So, what exactly is the issue here?

[pmundkur]

It would be good to address #1313 at the same time to get a coherent misa configuration scheme. Then we could see how something like #1524 fits into it.