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.
|
