|
Hi Privileged ISA group,
There's been a longstanding shortcoming in the RISC-V Privileged ISA
document that it doesn't precisely explain what may happen when one
CSR controls the writability of bits or fields of a second CSR, and
the bits/fields of the second CSR are first configured as writable
(unmasked), then read-only (masked, usually zeros), then later back
to writable again. Is the original state of the second CSR retained
while the CSR bits/fields are masked and then revealed again by the
unmasking? Do writes to the second CSR while masked change this hidden
state? The current document rarely says.
To resolve these questions, a new subsection for the CSRs chapter is
proposed with the text below, or something to the same effect. My
interest for the moment is less to quibble over the exact words but
rather to give everyone an opportunity to comment on the intent,
assuming that much is clear. The current plan is to treat hidden,
masked state usually the same way that bit 1 of CSR epc is already
explicitly treated when IALIGN is configurable between 16 and 32 (for
example, because misa.C is writable).
The justification for keeping the hidden state is that this is usually
the cheapest for the hardware to implement---the same justification
there was for bit 1 of epc. Writes to the CSR's flip-flops can
continue to occur unchanged whether the CSR is masked or not; only the
flip-flops are ignored while the CSR is masked.
Be aware, there will be a number of deviations that will be necessary,
falling under the category of "specified otherwise". But we are
intending to have deviations only when needed.
Thoughts?
- John Hauser
--------------------
section title: Masking of CSRs and CSR Fields
The value written to one CSR may change whether the contents of a
second CSR, or a subfield of a CSR, is writable or read-only. In such
cases, unless specified otherwise:
- When the second CSR or subfield is configured as read-only, its
register state continues to exist but is said to be _masked_
(hidden).
- While the second CSR or subfield is configured as read-only, writes
to that CSR modify the masked register state as though the CSR or
subfield were configured as writable. If the CSR or subfield is
WARL when writable, the value attained by the masked register state
is always a valid one, the same as if the CSR or subfield were
configured as writable.
- When a write to the first, controlling CSR changes whether the
second CSR contents or subfield is writable or read-only, the
corresponding register state becomes masked or unmasked accordingly
but its value is unchanged.
Masked register state is normally ignored for all other purposes, so
only the readable value of a CSR matters. Consequently, so long as a
CSR or subfield remains configured as read-only, any masked register
state that exists for it will have no visible effect.
|
|
|
The current Priv spec effectively allows implementation flexibility (for better or worse) and it's quite reasonable to expect that some implementations answered this question one way, other implementations answered another way, and yet other implementations answered differently in different places (i.e. whatever is convenient of the design). Hence this, or any, mandating of a specific behavior will not be backward compatible with all existing and in-flight implementations - and instead will make a fraction (whether a majority or a minority) of implementations incompatible. This isn't something to be doing in Priv 1.12 as it is about to be ratified. But this would be good food for community discussion and input for a possible fast-track arch extension or maybe (?) as part of a "Priv 1.13".
And, if anything, there has been more clamoring over the past couple of years for possibly narrowing down similar sorts of behaviors around what is allowed with WARL fields (starting with the basics of when legalization is performed, and especially when legal values for a field are dependent on other arch state and can change). The point being that there are a number of areas (like these) where the architecture provides lots of flexibility and/or is under-specified (depending on one's viewpoint).
On Fri, Nov 12, 2021 at 7:41 PM John Hauser < jh.riscv@...> wrote: Hi Privileged ISA group,
There's been a longstanding shortcoming in the RISC-V Privileged ISA
document that it doesn't precisely explain what may happen when one
CSR controls the writability of bits or fields of a second CSR, and
the bits/fields of the second CSR are first configured as writable
(unmasked), then read-only (masked, usually zeros), then later back
to writable again. Is the original state of the second CSR retained
while the CSR bits/fields are masked and then revealed again by the
unmasking? Do writes to the second CSR while masked change this hidden
state? The current document rarely says.
To resolve these questions, a new subsection for the CSRs chapter is
proposed with the text below, or something to the same effect. My
interest for the moment is less to quibble over the exact words but
rather to give everyone an opportunity to comment on the intent,
assuming that much is clear. The current plan is to treat hidden,
masked state usually the same way that bit 1 of CSR epc is already
explicitly treated when IALIGN is configurable between 16 and 32 (for
example, because misa.C is writable).
The justification for keeping the hidden state is that this is usually
the cheapest for the hardware to implement---the same justification
there was for bit 1 of epc. Writes to the CSR's flip-flops can
continue to occur unchanged whether the CSR is masked or not; only the
flip-flops are ignored while the CSR is masked.
Be aware, there will be a number of deviations that will be necessary,
falling under the category of "specified otherwise". But we are
intending to have deviations only when needed.
Thoughts?
- John Hauser
--------------------
section title: Masking of CSRs and CSR Fields
The value written to one CSR may change whether the contents of a
second CSR, or a subfield of a CSR, is writable or read-only. In such
cases, unless specified otherwise:
- When the second CSR or subfield is configured as read-only, its
register state continues to exist but is said to be _masked_
(hidden).
- While the second CSR or subfield is configured as read-only, writes
to that CSR modify the masked register state as though the CSR or
subfield were configured as writable. If the CSR or subfield is
WARL when writable, the value attained by the masked register state
is always a valid one, the same as if the CSR or subfield were
configured as writable.
- When a write to the first, controlling CSR changes whether the
second CSR contents or subfield is writable or read-only, the
corresponding register state becomes masked or unmasked accordingly
but its value is unchanged.
Masked register state is normally ignored for all other purposes, so
only the readable value of a CSR matters. Consequently, so long as a
CSR or subfield remains configured as read-only, any masked register
state that exists for it will have no visible effect.
|
|
|
Allen Baum
Greg beat me to it; the case where a WARL mapping becomes illegal has concerned me for a while. OR when an illegal value is written, but writing another CSR would have made that original value legal - what should happen Note that there should be no precondition that the field becomes read-only in those cases; it remains perfectly writable, The proposed text doesn't seem to cover that, even though the principle remains the same.
I like this clarification; I think it is the easiest to implement, and the most useful.
On Fri, Nov 12, 2021 at 10:55 PM Greg Favor < gfavor@...> wrote: The current Priv spec effectively allows implementation flexibility (for better or worse) and it's quite reasonable to expect that some implementations answered this question one way, other implementations answered another way, and yet other implementations answered differently in different places (i.e. whatever is convenient of the design). Hence this, or any, mandating of a specific behavior will not be backward compatible with all existing and in-flight implementations - and instead will make a fraction (whether a majority or a minority) of implementations incompatible. This isn't something to be doing in Priv 1.12 as it is about to be ratified. But this would be good food for community discussion and input for a possible fast-track arch extension or maybe (?) as part of a "Priv 1.13".
And, if anything, there has been more clamoring over the past couple of years for possibly narrowing down similar sorts of behaviors around what is allowed with WARL fields (starting with the basics of when legalization is performed, and especially when legal values for a field are dependent on other arch state and can change). The point being that there are a number of areas (like these) where the architecture provides lots of flexibility and/or is under-specified (depending on one's viewpoint). On Fri, Nov 12, 2021 at 7:41 PM John Hauser < jh.riscv@...> wrote: Hi Privileged ISA group,
There's been a longstanding shortcoming in the RISC-V Privileged ISA
document that it doesn't precisely explain what may happen when one
CSR controls the writability of bits or fields of a second CSR, and
the bits/fields of the second CSR are first configured as writable
(unmasked), then read-only (masked, usually zeros), then later back
to writable again. Is the original state of the second CSR retained
while the CSR bits/fields are masked and then revealed again by the
unmasking? Do writes to the second CSR while masked change this hidden
state? The current document rarely says.
To resolve these questions, a new subsection for the CSRs chapter is
proposed with the text below, or something to the same effect. My
interest for the moment is less to quibble over the exact words but
rather to give everyone an opportunity to comment on the intent,
assuming that much is clear. The current plan is to treat hidden,
masked state usually the same way that bit 1 of CSR epc is already
explicitly treated when IALIGN is configurable between 16 and 32 (for
example, because misa.C is writable).
The justification for keeping the hidden state is that this is usually
the cheapest for the hardware to implement---the same justification
there was for bit 1 of epc. Writes to the CSR's flip-flops can
continue to occur unchanged whether the CSR is masked or not; only the
flip-flops are ignored while the CSR is masked.
Be aware, there will be a number of deviations that will be necessary,
falling under the category of "specified otherwise". But we are
intending to have deviations only when needed.
Thoughts?
- John Hauser
--------------------
section title: Masking of CSRs and CSR Fields
The value written to one CSR may change whether the contents of a
second CSR, or a subfield of a CSR, is writable or read-only. In such
cases, unless specified otherwise:
- When the second CSR or subfield is configured as read-only, its
register state continues to exist but is said to be _masked_
(hidden).
- While the second CSR or subfield is configured as read-only, writes
to that CSR modify the masked register state as though the CSR or
subfield were configured as writable. If the CSR or subfield is
WARL when writable, the value attained by the masked register state
is always a valid one, the same as if the CSR or subfield were
configured as writable.
- When a write to the first, controlling CSR changes whether the
second CSR contents or subfield is writable or read-only, the
corresponding register state becomes masked or unmasked accordingly
but its value is unchanged.
Masked register state is normally ignored for all other purposes, so
only the readable value of a CSR matters. Consequently, so long as a
CSR or subfield remains configured as read-only, any masked register
state that exists for it will have no visible effect.
|
|
|
If I understand it correctly, the proposal states that the csr value must be updated as usual by csrw and normalized according to the r/w qualifier on read. The argument is that since there exists
at least one situation where the flops are writable by csrw, the simplest implementation is to make them always writable by csrw.
A counter argument to this is a case where the value in the flops is used as input to a timing critical operation. In this case, it would be better if the flops stored the normalized value so that the critical operation does not need to add
the overhead of doing the normalization. Normalizing at the time of the csrw would be a one-time non critical operation, whereas reading the value may be done many times and may be timing critical.
Perhaps this is an argument to change the default proposal from normalize-on-read to normalize-on-write. Or maybe it is an argument that this behavior should be left to the implementation.
James
toggle quoted message
Show quoted text
On Nov 13, 2021, at 3:14 AM, Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
Greg beat me to it; the case where a WARL mapping becomes illegal has concerned me for a while.
OR when an illegal value is written, but writing another CSR would have made that original value legal - what should happen
Note that there should be no precondition that the field becomes read-only in those cases; it remains perfectly writable,
The proposed text doesn't seem to cover that, even though the principle remains the same.
I like this clarification; I think it is the easiest to implement, and the most useful.
On Fri, Nov 12, 2021 at 10:55 PM Greg Favor < gfavor@...> wrote:
The current Priv spec effectively allows implementation flexibility (for better or worse) and it's quite reasonable to expect that some implementations answered this question one way, other implementations answered another way, and yet other
implementations answered differently in different places (i.e. whatever is convenient of the design). Hence this, or any, mandating of a specific behavior will not be backward compatible with all existing and in-flight implementations - and instead will make
a fraction (whether a majority or a minority) of implementations incompatible. This isn't something to be doing in Priv 1.12 as it is about to be ratified. But this would be good food for community discussion and input for a possible fast-track arch extension
or maybe (?) as part of a "Priv 1.13".
And, if anything, there has been more clamoring over the past couple of years for possibly narrowing down similar sorts of behaviors around what is allowed with WARL fields (starting with the basics of when legalization is performed, and especially
when legal values for a field are dependent on other arch state and can change). The point being that there are a number of areas (like these) where the architecture provides lots of flexibility and/or is under-specified (depending on one's viewpoint).
On Fri, Nov 12, 2021 at 7:41 PM John Hauser < jh.riscv@...> wrote:
Hi Privileged ISA group,
There's been a longstanding shortcoming in the RISC-V Privileged ISA
document that it doesn't precisely explain what may happen when one
CSR controls the writability of bits or fields of a second CSR, and
the bits/fields of the second CSR are first configured as writable
(unmasked), then read-only (masked, usually zeros), then later back
to writable again. Is the original state of the second CSR retained
while the CSR bits/fields are masked and then revealed again by the
unmasking? Do writes to the second CSR while masked change this hidden
state? The current document rarely says.
To resolve these questions, a new subsection for the CSRs chapter is
proposed with the text below, or something to the same effect. My
interest for the moment is less to quibble over the exact words but
rather to give everyone an opportunity to comment on the intent,
assuming that much is clear. The current plan is to treat hidden,
masked state usually the same way that bit 1 of CSR epc is already
explicitly treated when IALIGN is configurable between 16 and 32 (for
example, because misa.C is writable).
The justification for keeping the hidden state is that this is usually
the cheapest for the hardware to implement---the same justification
there was for bit 1 of epc. Writes to the CSR's flip-flops can
continue to occur unchanged whether the CSR is masked or not; only the
flip-flops are ignored while the CSR is masked.
Be aware, there will be a number of deviations that will be necessary,
falling under the category of "specified otherwise". But we are
intending to have deviations only when needed.
Thoughts?
- John Hauser
--------------------
section title: Masking of CSRs and CSR Fields
The value written to one CSR may change whether the contents of a
second CSR, or a subfield of a CSR, is writable or read-only. In such
cases, unless specified otherwise:
- When the second CSR or subfield is configured as read-only, its
register state continues to exist but is said to be _masked_
(hidden).
- While the second CSR or subfield is configured as read-only, writes
to that CSR modify the masked register state as though the CSR or
subfield were configured as writable. If the CSR or subfield is
WARL when writable, the value attained by the masked register state
is always a valid one, the same as if the CSR or subfield were
configured as writable.
- When a write to the first, controlling CSR changes whether the
second CSR contents or subfield is writable or read-only, the
corresponding register state becomes masked or unmasked accordingly
but its value is unchanged.
Masked register state is normally ignored for all other purposes, so
only the readable value of a CSR matters. Consequently, so long as a
CSR or subfield remains configured as read-only, any masked register
state that exists for it will have no visible effect.
|
|
|
Allen Baum
Could you give an example of the kind of timing critical operation?
What I was thinking of was the added delay from clock to CSR output, and if the next instruction has a dependency hazard on that, there could be a timing problem. But because of the case where changing some other field will cause a remapping of this one - you need to remap output anyway.
There are alternatives to that also - forcing a write to occur to any dependent field even if that CSR isn't addressed - but that is both ugly, power consuming, and adds delay to some other path that might be critical.
The high-end designs I am familiar with usually flush the pipe on CSR writes (at least those with hazards) because pipe stages for ops using their results may already been executed.
On Sat, Nov 13, 2021 at 12:59 AM James Robinson < jrobinson@...> wrote:
If I understand it correctly, the proposal states that the csr value must be updated as usual by csrw and normalized according to the r/w qualifier on read. The argument is that since there exists
at least one situation where the flops are writable by csrw, the simplest implementation is to make them always writable by csrw.
A counter argument to this is a case where the value in the flops is used as input to a timing critical operation. In this case, it would be better if the flops stored the normalized value so that the critical operation does not need to add
the overhead of doing the normalization. Normalizing at the time of the csrw would be a one-time non critical operation, whereas reading the value may be done many times and may be timing critical.
Perhaps this is an argument to change the default proposal from normalize-on-read to normalize-on-write. Or maybe it is an argument that this behavior should be left to the implementation.
James
Greg beat me to it; the case where a WARL mapping becomes illegal has concerned me for a while.
OR when an illegal value is written, but writing another CSR would have made that original value legal - what should happen
Note that there should be no precondition that the field becomes read-only in those cases; it remains perfectly writable,
The proposed text doesn't seem to cover that, even though the principle remains the same.
I like this clarification; I think it is the easiest to implement, and the most useful.
On Fri, Nov 12, 2021 at 10:55 PM Greg Favor < gfavor@...> wrote:
The current Priv spec effectively allows implementation flexibility (for better or worse) and it's quite reasonable to expect that some implementations answered this question one way, other implementations answered another way, and yet other
implementations answered differently in different places (i.e. whatever is convenient of the design). Hence this, or any, mandating of a specific behavior will not be backward compatible with all existing and in-flight implementations - and instead will make
a fraction (whether a majority or a minority) of implementations incompatible. This isn't something to be doing in Priv 1.12 as it is about to be ratified. But this would be good food for community discussion and input for a possible fast-track arch extension
or maybe (?) as part of a "Priv 1.13".
And, if anything, there has been more clamoring over the past couple of years for possibly narrowing down similar sorts of behaviors around what is allowed with WARL fields (starting with the basics of when legalization is performed, and especially
when legal values for a field are dependent on other arch state and can change). The point being that there are a number of areas (like these) where the architecture provides lots of flexibility and/or is under-specified (depending on one's viewpoint).
On Fri, Nov 12, 2021 at 7:41 PM John Hauser < jh.riscv@...> wrote:
Hi Privileged ISA group,
There's been a longstanding shortcoming in the RISC-V Privileged ISA
document that it doesn't precisely explain what may happen when one
CSR controls the writability of bits or fields of a second CSR, and
the bits/fields of the second CSR are first configured as writable
(unmasked), then read-only (masked, usually zeros), then later back
to writable again. Is the original state of the second CSR retained
while the CSR bits/fields are masked and then revealed again by the
unmasking? Do writes to the second CSR while masked change this hidden
state? The current document rarely says.
To resolve these questions, a new subsection for the CSRs chapter is
proposed with the text below, or something to the same effect. My
interest for the moment is less to quibble over the exact words but
rather to give everyone an opportunity to comment on the intent,
assuming that much is clear. The current plan is to treat hidden,
masked state usually the same way that bit 1 of CSR epc is already
explicitly treated when IALIGN is configurable between 16 and 32 (for
example, because misa.C is writable).
The justification for keeping the hidden state is that this is usually
the cheapest for the hardware to implement---the same justification
there was for bit 1 of epc. Writes to the CSR's flip-flops can
continue to occur unchanged whether the CSR is masked or not; only the
flip-flops are ignored while the CSR is masked.
Be aware, there will be a number of deviations that will be necessary,
falling under the category of "specified otherwise". But we are
intending to have deviations only when needed.
Thoughts?
- John Hauser
--------------------
section title: Masking of CSRs and CSR Fields
The value written to one CSR may change whether the contents of a
second CSR, or a subfield of a CSR, is writable or read-only. In such
cases, unless specified otherwise:
- When the second CSR or subfield is configured as read-only, its
register state continues to exist but is said to be _masked_
(hidden).
- While the second CSR or subfield is configured as read-only, writes
to that CSR modify the masked register state as though the CSR or
subfield were configured as writable. If the CSR or subfield is
WARL when writable, the value attained by the masked register state
is always a valid one, the same as if the CSR or subfield were
configured as writable.
- When a write to the first, controlling CSR changes whether the
second CSR contents or subfield is writable or read-only, the
corresponding register state becomes masked or unmasked accordingly
but its value is unchanged.
Masked register state is normally ignored for all other purposes, so
only the readable value of a CSR matters. Consequently, so long as a
CSR or subfield remains configured as read-only, any masked register
state that exists for it will have no visible effect.
|
|
|
On Fri, Nov 12, 2021 at 10:55 PM Greg Favor < gfavor@...> wrote: And, if anything, there has been more clamoring over the past couple of years for possibly narrowing down similar sorts of behaviors around what is allowed with WARL fields (starting with the basics of when legalization is performed, and especially when legal values for a field are dependent on other arch state and can change). The point being that there are a number of areas (like these) where the architecture provides lots of flexibility and/or is under-specified (depending on one's viewpoint).
To clarify, my point was that the proposed "mask on read" mandate is no different than mandating that WARL fields must be legalized on read and not on write. Mandating "legalize on read" (or mandating "legalize on write") would make many implementations incompatible. And this topic has proven contentious over the past couple of years whenever it has come up. Which reflects the loss of implementation flexibility from any new restrictions, and the backward incompatibility that the current arch flexibility allows.
For completeness, some past WARL legalization discussions have tried to limit the allowed behaviors to just a small subset of possibilities (as Allen can attest), but even those discussions got troublesome when the legal values of a multi-bit WARL field are dependent on other arch (CSR) state - and hence a legal value can become illegal, and the mapping onto a legal value can itself become illegal, in-between reads and/or writes to the WARL field.
This whole topic of legalizing/masking CSR fields based on other arch state, and when to mask/legalize, needs to be a broad holistic effort that ideally establishes a consistent architectural practice across all these sorts of situations (modulo any unavoidable and explicit exceptions). (I suspect the end result would be to either maintain the current arch flexibility, or to constrain allowed behaviors to just two or three options.) If past WARL discussions are an indicator, this won't be a quick uncontentious effort.
Greg
|
|
|
I had a few questions. On Fri, Nov 12, 2021 at 07:41:07PM -0800, John Hauser wrote: The value written to one CSR may change whether the contents of a
second CSR, or a subfield of a CSR, is writable or read-only. In such
cases, unless specified otherwise:
- When the second CSR or subfield is configured as read-only, its
register state continues to exist but is said to be _masked_
(hidden).
Assume that the values in the hidden fields continues to exist as-is? And if those hidden fields affect execution in anyway then they continue to affect the execution/events as per their current value unless the control in the first CSR that caused these bits to be hidden in the second CSR also makes these hidden field to not have any effect on execution/events (e.g. feature/instructions affected by these hidden fields is itself disabled)? When the second CSR is read what do the _masked_/hidden bits provide? If that is expected to be specfied as part of the specific CSR definition then that could be clarified (like the *epc[1] reading 0). - While the second CSR or subfield is configured as read-only, writes
to that CSR modify the masked register state as though the CSR or
subfield were configured as writable. If the CSR or subfield is
WARL when writable, the value attained by the masked register state
is always a valid one, the same as if the CSR or subfield were
configured as writable.
This was not clear. The text states that the first CSR write makes the second CSR read-only or its sub-fields read-only but then states that the CSR writes do actually modify those read-only fields? However this behavior may not be always desirable - e.g. if the first CSR bit that affect the second CSR was a LOCK bit that makes the second CSR read-only e.g. pmp[i]cfg.L when set makes pmpaddr[i] read-only and writes are ignored. However this text would imply that writes must cause the pmpaddr[i] up update. So perhaps this is one of the cases to invoke the "unless specified otherwise" clause. If so this would imply that such bits made read-only by a first CSR must not have any effect thereafter on events/executions on that hart. Is that right? And if so then why not treat this same as previous clause of _masked_/hidden instead of read-only (e.g. like *epc[1]). Or was the intent to state that these fields become WARL and the only legal value from the point they were made read-only is the value held by these read-only fields at the time of writing the first CSR bit(s) that caused this change? - When a write to the first, controlling CSR changes whether the
second CSR contents or subfield is writable or read-only, the
corresponding register state becomes masked or unmasked accordingly
but its value is unchanged.
Masked register state is normally ignored for all other purposes, so
only the readable value of a CSR matters. Consequently, so long as a
CSR or subfield remains configured as read-only, any masked register
state that exists for it will have no visible effect.
To me the terms masked/unmasked and read-only/writeable seem to be used interchangeably and are causing much confusion about their definition. regards ved
|
|
|
Allen Baum
I interpret this to mean simply that there is a mapping function at the output of the field IF there is a dependency on some other field.
What follows is my interpretation of what I think is happening; it is not necessarily "truth". IF I didn't interpret this correctly, it means that John is going to have to write a long correction.....sorry.
That mapping function takes the field value, and some other controlling field value, and converts it to a legal value. That mapping function output is what is presented to hardware, which is what performs its intended function, and what is read by a CSRRD instruction. If it is readonly, then I *think* the output is only a function of the controlling field value (I'd like to see some examples to understand what he had in mind for the read-only behavior) Writing the field then appears to leave it unchanged, but the underlying state is actually changing; the mapping function ignores those state bits because the mapping isn't dependent on them. Changing the controlling field back to its original state would make the last written value appear (or not, if it is illegal....)
But, it isn't necessarily readonly. The output could be a function of both fields, in which case the value presented to the hardware could change on a write. e.g. if the field had a legal value, and changing the controlling field made it illegal, the mapping function would present as some legal value. A write to that field with some other legal value would change the output to that new legal value A write to that field with some other illegal value might change the output to some other legal value, or leave it as the same legal value, depending on the mapping function.
An example of the latter case is SATP, where not all values are legal. The mapping function determines which legal value replaces the illegal value. If that legal mapping is, for example, the closest legal value, or the next larger legal value, then writing a different illegal value will change the output.
The canonical mapping function is "leave the old state unchanged" though; its the easiest to implement, but if a field has both a dependency that isn't readonly, and wants to inhibit the write, then you need to detect illegal on both input and output, which is painful. I can't think of an example of that offhand,
On Sun, Nov 14, 2021 at 2:56 PM Vedvyas Shanbhogue < ved@...> wrote: I had a few questions.
On Fri, Nov 12, 2021 at 07:41:07PM -0800, John Hauser wrote:
>The value written to one CSR may change whether the contents of a
>second CSR, or a subfield of a CSR, is writable or read-only. In such
>cases, unless specified otherwise:
>
> - When the second CSR or subfield is configured as read-only, its
> register state continues to exist but is said to be _masked_
> (hidden).
>
Assume that the values in the hidden fields continues to exist as-is?
And if those hidden fields affect execution in anyway then they continue to affect the execution/events as per their current value unless the control in the first CSR that caused these bits to be hidden in the second CSR also makes these hidden field to not have any effect on execution/events (e.g. feature/instructions affected by these hidden fields is itself disabled)?
When the second CSR is read what do the _masked_/hidden bits provide? If that is expected to be specfied as part of the specific CSR definition then that could be clarified (like the *epc[1] reading 0).
> - While the second CSR or subfield is configured as read-only, writes
> to that CSR modify the masked register state as though the CSR or
> subfield were configured as writable. If the CSR or subfield is
> WARL when writable, the value attained by the masked register state
> is always a valid one, the same as if the CSR or subfield were
> configured as writable.
>
This was not clear. The text states that the first CSR write makes the second CSR read-only or its sub-fields read-only but then states that the CSR writes do actually modify those read-only fields?
However this behavior may not be always desirable - e.g. if the first CSR bit that affect the second CSR was a LOCK bit that makes the second CSR read-only e.g. pmp[i]cfg.L when set makes pmpaddr[i] read-only and writes are ignored. However this text would imply that writes must cause the pmpaddr[i] up update.
So perhaps this is one of the cases to invoke the "unless specified otherwise" clause.
If so this would imply that such bits made read-only by a first CSR must not have any effect thereafter on events/executions on that hart. Is that right? And if so then why not treat this same as previous clause of _masked_/hidden instead of read-only (e.g. like *epc[1]).
Or was the intent to state that these fields become WARL and the only legal value from the point they were made read-only is the value held by these read-only fields at the time of writing the first CSR bit(s) that caused this change?
> - When a write to the first, controlling CSR changes whether the
> second CSR contents or subfield is writable or read-only, the
> corresponding register state becomes masked or unmasked accordingly
> but its value is unchanged.
>
>Masked register state is normally ignored for all other purposes, so
>only the readable value of a CSR matters. Consequently, so long as a
>CSR or subfield remains configured as read-only, any masked register
>state that exists for it will have no visible effect.
>
To me the terms masked/unmasked and read-only/writeable seem to be used interchangeably and are causing much confusion about their definition.
regards
ved
|
|
|
Allen Baum wrote: What follows is my interpretation of what I think is happening; it is not
necessarily "truth".
IF I didn't interpret this correctly, it means that John is going to have
to write a long correction.....sorry.
That mapping function takes the field value, and some other controlling
field value, and converts it to a legal value.
That mapping function output is what is presented to hardware, which is
what performs its intended function, and what is read by a
CSRRD instruction.
If it is readonly, then I *think* the output is only a function of the
controlling field value (I'd like to see some examples to understand what
he had in mind for the read-only behavior)
Writing the field then appears to leave it unchanged, but the underlying
state is actually changing; the mapping function ignores those state bits
because the mapping isn't dependent on them.
Changing the controlling field back to its original state would make the
last written value appear [...] Yes, you have it correct, Allen, although my text only addressed writable-versus-read-only and not the possibility that the set of valid values might change due to another CSR. Some of the RISC-V heavyweights discussed this topic amongst themselves, off the mailing list, and concluded that they'd prefer a different approach, which I'll share with everyone for your input. This isn't necessarily the final wording (you all might contribute to that), but the gist is this: Unless specified otherwise, if a write to one CSR changes the set of valid (legal) values allowed for a second CSR or a subfield, then the second CSR or subfield immediately gets an unspecified value among the set of valid values it's allowed to have. Note that when a CSR's contents or subfield is read-only, its set of possible valid values has only one member (or at least only one at any given time). So, by the rule stated above, if a write to the first CSR causes the second CSR or subfield to become read-only, then it immediately gets the required read-only value, which is the only value it's allowed to have. On the other hand, if a write to the controlling CSR changes the second CSR or subfield back to being writable (multiple values are now allowed), it may suddenly take on any valid value allowed to it; exaclty which value it gets is unspecified. An important point is that this change to the value of the second CSR or subfield may occur _even if its old value would still have been valid_ both before and after the write to the controlling CSR. Compared to the first proposal, this one swings in the opposite direction toward maximal freedom for the implementation. So how does everyone feel about this alternate proposal? If I didn't explain it well enough above and there are questions about what exactly the new proposed rule is, I'll be happy to attempt to clarify. - John Hauser
|
|
|
On Wed, Nov 17, 2021 at 5:02 PM John Hauser < jh.riscv@...> wrote: Allen Baum wrote:
> What follows is my interpretation of what I think is happening; it is not
> necessarily "truth".
> IF I didn't interpret this correctly, it means that John is going to have
> to write a long correction.....sorry.
>
> That mapping function takes the field value, and some other controlling
> field value, and converts it to a legal value.
> That mapping function output is what is presented to hardware, which is
> what performs its intended function, and what is read by a
> CSRRD instruction.
> If it is readonly, then I *think* the output is only a function of the
> controlling field value (I'd like to see some examples to understand what
> he had in mind for the read-only behavior)
> Writing the field then appears to leave it unchanged, but the underlying
> state is actually changing; the mapping function ignores those state bits
> because the mapping isn't dependent on them.
> Changing the controlling field back to its original state would make the
> last written value appear [...]
Yes, you have it correct, Allen, although my text only addressed
writable-versus-read-only and not the possibility that the set of valid
values might change due to another CSR.
Some of the RISC-V heavyweights discussed this topic amongst
themselves, off the mailing list, and concluded that they'd prefer a
different approach, which I'll share with everyone for your input.
This isn't necessarily the final wording (you all might contribute to
that), but the gist is this:
Unless specified otherwise, if a write to one CSR changes the set
of valid (legal) values allowed for a second CSR or a subfield,
then the second CSR or subfield immediately gets an unspecified
value among the set of valid values it's allowed to have.
IMO, we need to consider something a bit more constrained. If the second subfield's value remains legal, then the second subfield should not change. In other words, the legal value the second subfield assumes is only unspecified if its previous value is no longer legal.
Note that when a CSR's contents or subfield is read-only, its set of
possible valid values has only one member (or at least only one at any
given time). So, by the rule stated above, if a write to the first
CSR causes the second CSR or subfield to become read-only, then it
immediately gets the required read-only value, which is the only value
it's allowed to have. On the other hand, if a write to the controlling
CSR changes the second CSR or subfield back to being writable
(multiple values are now allowed), it may suddenly take on any valid
value allowed to it; exaclty which value it gets is unspecified. An
important point is that this change to the value of the second CSR or
subfield may occur _even if its old value would still have been valid_
both before and after the write to the controlling CSR.
Compared to the first proposal, this one swings in the opposite
direction toward maximal freedom for the implementation. So how does
everyone feel about this alternate proposal? If I didn't explain it
well enough above and there are questions about what exactly the new
proposed rule is, I'll be happy to attempt to clarify.
- John Hauser
|
|
|
Scott Johnson
This would mean that the previous proposal (masking only output of registers) is no longer allowed. Example 1, if bit 13 of hideleg is writable only if bit 13 of mideleg is 1, and read-only 0 otherwise: csrw mideleg, 1<<13 csrw hideleg, 1<<13 csrw mideleg, 0 csrr x4,hideleg // must read 0 csrw mideleg,1<<13 csrr x4,hideleg // okay to read 1<<13?
Under John's proposal from a few days ago, this must read 1<<13. Under his relaxation today, either 0 or 1<<13 is allowed. Andrew's proposal means that 0 is required, which means that hardware must write hideleg whenever mideleg is written.
Example 2:
csrw hideleg,0
csrw mideleg,0
csrw hideleg,1<<13
csrr x4,hideleg // must be 0
csrw mideleg,1<<13
csrr x4,hideleg // okay to read 1<<13?
Same three possibilities from the three proposals. Andrew's proposal means that hardware must mask hideleg on write.
The middle proposal matches the specification of extension state when re-enabled (e.g. write misa.H=0 then write misa.H=1, and hstatus is unspecified).
On Wed, Nov 17, 2021 at 5:13 PM Andrew Waterman < andrew@...> wrote:
IMO, we need to consider something a bit more constrained. If the second subfield's value remains legal, then the second subfield should not change. In other words, the legal value the second subfield assumes is only unspecified if its previous value is no longer legal.
|
|
|
On Wed, Nov 17, 2021 at 05:02:12PM -0800, John Hauser wrote: Allen Baum wrote:
What follows is my interpretation of what I think is happening; it is not
necessarily "truth".
IF I didn't interpret this correctly, it means that John is going to have
to write a long correction.....sorry.
That mapping function takes the field value, and some other controlling
field value, and converts it to a legal value.
That mapping function output is what is presented to hardware, which is
what performs its intended function, and what is read by a
CSRRD instruction.
If it is readonly, then I *think* the output is only a function of the
controlling field value (I'd like to see some examples to understand what
he had in mind for the read-only behavior)
Writing the field then appears to leave it unchanged, but the underlying
state is actually changing; the mapping function ignores those state bits
because the mapping isn't dependent on them.
Changing the controlling field back to its original state would make the
last written value appear [...] Yes, you have it correct, Allen, although my text only addressed
writable-versus-read-only and not the possibility that the set of valid
values might change due to another CSR.
Some of the RISC-V heavyweights discussed this topic amongst
themselves, off the mailing list, and concluded that they'd prefer a
different approach, which I'll share with everyone for your input.
This isn't necessarily the final wording (you all might contribute to
that), but the gist is this:
Unless specified otherwise, if a write to one CSR changes the set
of valid (legal) values allowed for a second CSR or a subfield,
then the second CSR or subfield immediately gets an unspecified
value among the set of valid values it's allowed to have.
Note that when a CSR's contents or subfield is read-only, its set of
possible valid values has only one member (or at least only one at any
given time). So, by the rule stated above, if a write to the first
CSR causes the second CSR or subfield to become read-only, then it
immediately gets the required read-only value, which is the only value
it's allowed to have. On the other hand, if a write to the controlling
CSR changes the second CSR or subfield back to being writable
(multiple values are now allowed), it may suddenly take on any valid
value allowed to it; exaclty which value it gets is unspecified. An
important point is that this change to the value of the second CSR or
subfield may occur _even if its old value would still have been valid_
both before and after the write to the controlling CSR.
Maybe a good definition of read-only would help since earlier you agreed to Allen but that text did not address the concept of read-only field holding on to written data instead of discarding the write. This behavior is quite unlike every other definition of read-only that I have come across. About the act of making a field writeable causing the field to assume any legal value I think this may be extremely hard for software to comprehend. An implementation may have a deterministic answer but if different implementations have different answer then software has to be prepared for each possible outcome. To take it to an extreme, consider a hypothetical second CSR that makes the satp CSR read-only. If the act of writing the second CSR to make satp writeable changes the mode to NONE that would be an extremely challenging outcoming the software will need to be prepared to deal with. Why was the choice not to leave the CSR with the legal value it has and not allow suddenly taking on any of the possible values. Compared to the first proposal, this one swings in the opposite
direction toward maximal freedom for the implementation. So how does
everyone feel about this alternate proposal? If I didn't explain it
well enough above and there are questions about what exactly the new
proposed rule is, I'll be happy to attempt to clarify.
- John Hauser
|
|
|
Andrew Waterman wrote: IMO, we need to consider something a bit more constrained. If the second
subfield's value remains legal, then the second subfield should not
change. In other words, the legal value the second subfield assumes is
only unspecified if its previous value is no longer legal. I just knew somebody was going to say that. Scott Johnson: This would mean that the previous proposal (masking only output of
registers) is no longer allowed. Exactly right. It does seem intuitive that, when the set of legal values changes, the CSR/subfield value should avoid changing unless it's necessary. But that rule would force the addition of extra hardware in certain situations, most notably in the common case when the controlling CSR toggles the second CSR/subfield between read-only zero and writable. - John Hauser
|
|
|
On Wed, Nov 17, 2021 at 7:15 PM John Hauser < jh.riscv@...> wrote: Andrew Waterman wrote:
> IMO, we need to consider something a bit more constrained. If the second
> subfield's value remains legal, then the second subfield should not
> change. In other words, the legal value the second subfield assumes is
> only unspecified if its previous value is no longer legal.
I just knew somebody was going to say that.
Scott Johnson:
> This would mean that the previous proposal (masking only output of
> registers) is no longer allowed.
Exactly right.
Indeed.
It does seem intuitive that, when the set of legal values changes,
the CSR/subfield value should avoid changing unless it's necessary.
But that rule would force the addition of extra hardware in certain
situations, most notably in the common case when the controlling CSR
toggles the second CSR/subfield between read-only zero and writable.
- John Hauser
|
|
|
Allen Baum
I've been harping on this for quite a while, because it affects architectural tests to a huge extent. Architectural tests compare a reference model to a DUT. The problem is that is not possible, because the reference model cannot possibly model all possible mappings from illegal to legal for every field. We have really stood on our head to get a handle on this - by proposing a syntax of the allowed mappings, (see riscv-config docs), but it's pretty ugly.
My preference is the simplest approach: on an explicit write, if the value is illegal, suppressed the write and keep the old value. That works in all cases, and is normally the easiest to implement as well (no mapping logic required) except for the case Andrew came up with, where allowed values of a field can use a single flop to represent multiple bits. (e.g. M/U modes of 11 and 00; so writing XY would set the value to XX (or YY), or a field that is required to be properly sign extended only needs a single flop. That's easier to implement than inhibiting the write (I won't argue that otherwise) and I am willing to allow that as an alternative. (I can be gracious :-)
That doesn't work in the case where a separate modifier field changes a legal value to an illegal one. Then, an implementation will have to - (deterministically) select a (now) legal value and force the CSR field to be updated with it, or - (deterministically) map the output to some (now) legal value. That deterministic function can be quite complicated, and the arch-test framework has defined a limited number of choices that can be configured for - but not all of them. (and if an implementation does choose one of them an document it in the config YAML file, their tests will fail and they will need to get a waiver to overlook it)
In the opposite direction (reverting the modifier such that the original value is again legal), - in the 1st case, nothing needs to be done and the new value remains. - in the 2nd case, nothing needs to be done and the original value re-appears. A yet more complicated case is if the old and new legal values are disjoint, i.e. the value chosen is not legal if the modifier field changes back. The implementation will have to - (deterministically) select a (now) legal value and force the CSR field to be updated with it, or - do nothing and the original (legal) value re-appears.
With my arch-test hat on, what I'd like to see (not that I'll get it, because--legacy implementations--but I hope to encourage it) 1. modifier functionality mandate the inhibiting the write (retain the old value, don't force a write of a field that wasn't addressed by the CSRRS instruction) with as restricted a set of mappings we can get away with (currently, they are smallest/largest legal value, closest legal (larger/smaller) value with (tiebreaker rule).
2. The readonly case can be treated similarly: retain the old value, and map the output to some specific value (I'm not sure where this happens, so unclear to me if there is always a fixed value or not, but that would be very nice to have)
3. For general WARL fields that aren't affected by modifier bits, inhibit explicit writes of illegal values*, no output mapping is required 4. For general WARL fields that are affected by modifier bits, inhibit explicit writes of illegal values**, and map outputs if the modifier makes them illegal.
Overall: writes to a particular field inhibit the write if an illegal write value is detected outputs of a particular field are remapped if a modifier field+CSR field values are illegal * except for Andrew's counterexample can also have a modifier field, so ** (Andrew's counterexample highly unlikely here, as all the bits need to be implemented anyway, so you don't get that 1:many mapping)
On Wed, Nov 17, 2021 at 7:15 PM John Hauser < jh.riscv@...> wrote: Andrew Waterman wrote:
> IMO, we need to consider something a bit more constrained. If the second
> subfield's value remains legal, then the second subfield should not
> change. In other words, the legal value the second subfield assumes is
> only unspecified if its previous value is no longer legal.
I just knew somebody was going to say that.
Scott Johnson:
> This would mean that the previous proposal (masking only output of
> registers) is no longer allowed.
Exactly right.
It does seem intuitive that, when the set of legal values changes,
the CSR/subfield value should avoid changing unless it's necessary.
But that rule would force the addition of extra hardware in certain
situations, most notably in the common case when the controlling CSR
toggles the second CSR/subfield between read-only zero and writable.
- John Hauser
|
|
|
Allen Baum
I'm missing something. If a bit is toggling between RW field and allzero, then when the modifier forces allzero, it maps the output to zero. That's an AND gate (per bit). The alternative is to force the input to zero - an AND gate per bit. How is that the addition of extra hardware?
I've been harping on this for quite a while, because it affects architectural tests to a huge extent. Architectural tests compare a reference model to a DUT. The problem is that is not possible, because the reference model cannot possibly model all possible mappings from illegal to legal for every field. We have really stood on our head to get a handle on this - by proposing a syntax of the allowed mappings, (see riscv-config docs), but it's pretty ugly.
My preference is the simplest approach: on an explicit write, if the value is illegal, suppressed the write and keep the old value. That works in all cases, and is normally the easiest to implement as well (no mapping logic required) except for the case Andrew came up with, where allowed values of a field can use a single flop to represent multiple bits. (e.g. M/U modes of 11 and 00; so writing XY would set the value to XX (or YY), or a field that is required to be properly sign extended only needs a single flop. That's easier to implement than inhibiting the write (I won't argue that otherwise) and I am willing to allow that as an alternative. (I can be gracious :-)
That doesn't work in the case where a separate modifier field changes a legal value to an illegal one. Then, an implementation will have to - (deterministically) select a (now) legal value and force the CSR field to be updated with it, or - (deterministically) map the output to some (now) legal value. That deterministic function can be quite complicated, and the arch-test framework has defined a limited number of choices that can be configured for - but not all of them. (and if an implementation does choose one of them an document it in the config YAML file, their tests will fail and they will need to get a waiver to overlook it)
In the opposite direction (reverting the modifier such that the original value is again legal), - in the 1st case, nothing needs to be done and the new value remains. - in the 2nd case, nothing needs to be done and the original value re-appears. A yet more complicated case is if the old and new legal values are disjoint, i.e. the value chosen is not legal if the modifier field changes back. The implementation will have to - (deterministically) select a (now) legal value and force the CSR field to be updated with it, or - do nothing and the original (legal) value re-appears.
With my arch-test hat on, what I'd like to see (not that I'll get it, because--legacy implementations--but I hope to encourage it) 1. modifier functionality mandate the inhibiting the write (retain the old value, don't force a write of a field that wasn't addressed by the CSRRS instruction) with as restricted a set of mappings we can get away with (currently, they are smallest/largest legal value, closest legal (larger/smaller) value with (tiebreaker rule).
2. The readonly case can be treated similarly: retain the old value, and map the output to some specific value (I'm not sure where this happens, so unclear to me if there is always a fixed value or not, but that would be very nice to have)
3. For general WARL fields that aren't affected by modifier bits, inhibit explicit writes of illegal values*, no output mapping is required 4. For general WARL fields that are affected by modifier bits, inhibit explicit writes of illegal values**, and map outputs if the modifier makes them illegal.
Overall: writes to a particular field inhibit the write if an illegal write value is detected outputs of a particular field are remapped if a modifier field+CSR field values are illegal * except for Andrew's counterexample can also have a modifier field, so ** (Andrew's counterexample highly unlikely here, as all the bits need to be implemented anyway, so you don't get that 1:many mapping)
On Wed, Nov 17, 2021 at 7:15 PM John Hauser < jh.riscv@...> wrote: Andrew Waterman wrote:
> IMO, we need to consider something a bit more constrained. If the second
> subfield's value remains legal, then the second subfield should not
> change. In other words, the legal value the second subfield assumes is
> only unspecified if its previous value is no longer legal.
I just knew somebody was going to say that.
Scott Johnson:
> This would mean that the previous proposal (masking only output of
> registers) is no longer allowed.
Exactly right.
It does seem intuitive that, when the set of legal values changes,
the CSR/subfield value should avoid changing unless it's necessary.
But that rule would force the addition of extra hardware in certain
situations, most notably in the common case when the controlling CSR
toggles the second CSR/subfield between read-only zero and writable.
- John Hauser
|
|
|
My preference is the simplest approach: on an explicit write, if the value is illegal, suppressed the write and keep the old value.
That works in all cases, and is normally the easiest to implement as well (no mapping logic required) except for the case Andrew came up with,
where allowed values of a field can use a single flop to represent multiple bits.
(e.g. M/U modes of 11 and 00; so writing XY would set the value to XX (or YY), or a field that is required to be properly sign extended only needs a single flop.
That's easier to implement than inhibiting the write (I won't argue that otherwise) and I am willing to allow that as an alternative. (I can be gracious :-)
Seems to me that, in some cases, it’s important not to keep the previous value. One example might be the ASID in the satp CSR. An implementation might not provide the full number of ASID values. For that case, writing the largest
architectural ASID probably should modify the field to be the largest implemented ASID. The alternative is some sort of search in software for what is supported.
Xstatus.MPP has the characteristic that it may be desirable to write the highest mode that’s no higher than the mode written rather than leaving it at the original mode after the write.
Bill
|
|
|
Allen Baum
If it is important that a particular value be chosen when an illegal value is written into WARL field, then that behavior must be explicitly speced. Otherwise, yes, code that writes a value must read it back to see if the correct value got written, and it doesn't matter that it's the previous value or something else. So, I'll argue that unless a specific behavior is spec'ed, it's OK to define the default behavior as keep the previous value (or sign extend if that makes sense).
On Thu, Nov 18, 2021 at 9:27 AM Bill Huffman < huffman@...> wrote:
My preference is the simplest approach: on an explicit write, if the value is illegal, suppressed the write and keep the old value.
That works in all cases, and is normally the easiest to implement as well (no mapping logic required) except for the case Andrew came up with,
where allowed values of a field can use a single flop to represent multiple bits.
(e.g. M/U modes of 11 and 00; so writing XY would set the value to XX (or YY), or a field that is required to be properly sign extended only needs a single flop.
That's easier to implement than inhibiting the write (I won't argue that otherwise) and I am willing to allow that as an alternative. (I can be gracious :-)
Seems to me that, in some cases, it’s important not to keep the previous value. One example might be the ASID in the satp CSR. An implementation might not provide the full number of ASID values. For that case, writing the largest
architectural ASID probably should modify the field to be the largest implemented ASID. The alternative is some sort of search in software for what is supported.
Xstatus.MPP has the characteristic that it may be desirable to write the highest mode that’s no higher than the mode written rather than leaving it at the original mode after the write.
Bill
|
|
|
I think that’s going to be too restrictive. I don’t think all the behaviors that will be desired will be in the spec.
Bill
toggle quoted message
Show quoted text
From: Allen Baum <allen.baum@...>
Sent: Thursday, November 18, 2021 1:12 PM
To: Bill Huffman <huffman@...>
Cc: John Hauser <jh.riscv@...>; tech-privileged <tech-privileged@...>
Subject: Re: [RISC-V] [tech-privileged] masking of CSR bits/fields
If it is important that a particular value be chosen when an illegal value is written into WARL field, then that behavior must be explicitly speced.
Otherwise, yes, code that writes a value must read it back to see if the correct value got written,
and it doesn't matter that it's the previous value or something else.
So, I'll argue that unless a specific behavior is spec'ed, it's OK to define the default behavior as keep the previous value (or sign extend if that makes sense).
On Thu, Nov 18, 2021 at 9:27 AM Bill Huffman <huffman@...> wrote:
My preference is the simplest approach: on an explicit write, if the value is illegal, suppressed the write and keep the old value.
That works in all cases, and is normally the easiest to implement as well (no mapping logic required) except for the case Andrew came up with,
where allowed values of a field can use a single flop to represent multiple bits.
(e.g. M/U modes of 11 and 00; so writing XY would set the value to XX (or YY), or a field that is required to be properly sign extended only needs a single flop.
That's easier to implement than inhibiting the write (I won't argue that otherwise) and I am willing to allow that as an alternative. (I can be gracious :-)
Seems to me that, in some cases, it’s important
not to keep the previous value. One example might be the ASID in the satp CSR. An implementation might not provide the full number of ASID values. For that case, writing the largest architectural ASID probably should modify the field to be the largest
implemented ASID. The alternative is some sort of search in software for what is supported.
Xstatus.MPP has the characteristic that it may be desirable to write the highest mode that’s no higher than the mode written rather than leaving it at the original mode after the
write.
Bill
|
|
|
Allen Baum
If there are specific desired behaviors, and the spec doesn't require a specific one, then SW will be required to check that it wrote what was expected and acceptable (and correct it if it isn't).
So, making it restrictive makes no difference to SW, and (arguably) makes HW easier.
If a platform requires a specific behavior - that might make me change my view, but I asked (longer ago) about exactly this issue, and was told they didn't intend to mandate anything, SW would just have to cope.
So, I don't see any reason to change my view (at this time, anyway). I could be convinced otherwise, but not yet.
On Thu, Nov 18, 2021 at 10:24 AM Bill Huffman < huffman@...> wrote:
I think that’s going to be too restrictive. I don’t think all the behaviors that will be desired will be in the spec.
Bill
From: Allen Baum <allen.baum@...>
Sent: Thursday, November 18, 2021 1:12 PM
To: Bill Huffman <huffman@...>
Cc: John Hauser <jh.riscv@...>; tech-privileged <tech-privileged@...>
Subject: Re: [RISC-V] [tech-privileged] masking of CSR bits/fields
If it is important that a particular value be chosen when an illegal value is written into WARL field, then that behavior must be explicitly speced.
Otherwise, yes, code that writes a value must read it back to see if the correct value got written,
and it doesn't matter that it's the previous value or something else.
So, I'll argue that unless a specific behavior is spec'ed, it's OK to define the default behavior as keep the previous value (or sign extend if that makes sense).
On Thu, Nov 18, 2021 at 9:27 AM Bill Huffman <huffman@...> wrote:
My preference is the simplest approach: on an explicit write, if the value is illegal, suppressed the write and keep the old value.
That works in all cases, and is normally the easiest to implement as well (no mapping logic required) except for the case Andrew came up with,
where allowed values of a field can use a single flop to represent multiple bits.
(e.g. M/U modes of 11 and 00; so writing XY would set the value to XX (or YY), or a field that is required to be properly sign extended only needs a single flop.
That's easier to implement than inhibiting the write (I won't argue that otherwise) and I am willing to allow that as an alternative. (I can be gracious :-)
Seems to me that, in some cases, it’s important
not to keep the previous value. One example might be the ASID in the satp CSR. An implementation might not provide the full number of ASID values. For that case, writing the largest architectural ASID probably should modify the field to be the largest
implemented ASID. The alternative is some sort of search in software for what is supported.
Xstatus.MPP has the characteristic that it may be desirable to write the highest mode that’s no higher than the mode written rather than leaving it at the original mode after the
write.
Bill
|
|
|
