WARL behavior on MISA

[Anna Slobodova]

My understanding of WARL fields was that we can write anything but a read will always return legal values. However, in section 3.1.1 of privileged manual, for MISA it says:

"An attempt to write an unsupported combination causes those bits to be set to some supported combination"

Doesn't it contradict to being able to WRITE ANYTHING?

Thanks,

Anna

[Andrew Waterman]

I don’t see the contradiction—the text you quoted is essentially a restatement of the definition of WARL.

--


You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.


To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.


To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/6a739a01-42f5-45b9-80ac-a661aecd43b7n%40groups.riscv.org.

[Jim Wilson]

On Thu, Sep 23, 2021 at 1:39 PM Andrew Waterman <and...@sifive.com> wrote:

I don’t see the contradiction—the text you quoted is essentially a restatement of the definition of WARL.

On Thu, Sep 23, 2021 at 1:34 PM Anna Slobodova <anna.sl...@gmail.com> wrote:

My understanding of WARL fields was that we can write anything but a read will always return legal values. However, in section 3.1.1 of privileged manual, for MISA it says:

"An attempt to write an unsupported combination causes those bits to be set to some supported combination"

Doesn't it contradict to being able to WRITE ANYTHING?

You can try to write anything, but the only bits that change are the ones you are allowed to change, to values that you are allowed to change them to, which is why you can only read legal values back out of the register.  Or to put this another way, invalid values are corrected when writing, not when reading.

Jim

[Anna Slobodova]

Thanks Jim. My misunderstanding was in that I thought the values are
corrected when read.
Anna

[Allen Baum]

I must disagree. There are cases where the value must be corrected on the read - or must be implicitly written with a different value.

This happens when a legal value is dependent on some other CSR field, and the existing value becomes illegal when this other field is written.

It is not common, but it can happen.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BmXqw8-yWy0ejnF%2Bs7YZYQtrJLCS96%3DETjqbxVHn86DUkRCTQ%40mail.gmail.com.

[Paul Donahue]

I filed https://github.com/riscv/riscv-isa-manual/issues/520 but I still don't think that the definition of WARL is clear in general.  The quoted sentence appears to require misa to do input mapping (fix the values on the write rather than on the read) which at least provides clarity on one CSR.

Thanks,

-Paul

[Anna Slobodova]

I must agree with Paul. If a WARL field needs to be corrected upon
write than it fits more the definition of WLRL. Even if there is a
dependency among some fileds, they can be corrected upon read (e.f. F
and D exception fields in MISA).
Anna

[Anthony Coulter]

<anna

[Philipp Tomsich]

For whatever it's worth, I don't see a reason why this can't be considered WARL.

The mental model I use for these fields is as follows:

• Any write to a WARL-CSR 'f' write to f_request, which is not visible/readable to an outside observer.
• Any read from a WARL-CSR 'f' reads from f_status (which is synthesized from the internal state).
• Whenever a write to f_request occurs, internal logic will process the request and may update internal state (thus reflecting on any value synthesized into the value read from f_status).

In the case that Allen mentioned, no harm (i.e. illegal state) can occur if the value-written does not consider other (dependent) system state: the effect may not be as desired (i.e. a software bug is exposed), but the resulting state reflected in the CSR will always be a legal value.

Philipp.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BmXqw__hZuq3KcLpDY5D3CKXe2d2-oy5L8TouL4e4cfAaKROQ%40mail.gmail.com.

[Paul Donahue]

I agree that the misa behavior is clear and that it falls within the broad definition of WARL.  I believe that Allen was objecting to Jim's assertion that WARL requires (rather than simply allows) input mapping.  I agree with Allen that there is no such requirement in the definition of WARL and this vagueness in the definition can lead to problems in certain CSRs (other than misa).  It's unclear to me whether you think that, in cases where software can distinguish between them, the legalization process happens on writes to f_request, on reads of f_status, or either.

Thanks,

-Paul

[Philipp Tomsich]

I would argue that the write to f_request does not have to be legalized in any way.

The legalization would occur when the internal logic applies f_request to the internal state: any resulting state will have to be legal.

Consequently, f_state (whether synthesized into a location or constituted on-demand) will always be legal.

I.e., the software writing the CSR will not perform any legalization — neither will the legalization happen after collecting the state; it is rather guaranteed that the state is kept legal at all times (i.e. legalization always occurs in applying f_request to the state).

[Paul Donahue]

Yes, that's the definition of WARL.  I think that I misunderstood your comment.  The thing that's not clear is whether the hardware (or software emulator) performs the legalization when the CSR write is performed (using the state of the hart at the time of the write) or if the hardware performs the legalization when the read is performed (using the state of the hart at the time of the read).  That's the definition of input mapping and output mapping in the issue I referenced.

There is no question about misa because (1) the spec explicitly requires input mapping and (2) I don't think that the state of any other CSR can cause a misa value to become illegal.  Item 2 doesn't hold for all CSRs which is a problem.

Thanks,

-Paul

[Philipp Tomsich]

Paul,

Any WARL CSR write will be a case of input-mapping, as applying f_request is not allowed to lead to an illegal system state.

I am hard-pressed to come up with any example, where output-mapping would be a reasonable choice (as f_status will just reflect the current state, which has to be legal).

Am I missing something?

Philipp.

[K. York]

In the case you ask of, of an emulator handling a trapped "illegal CSR number" write / read, I don't see how the required logic is all that different from what hardware is required to do. Any value written must be tolerated, whether that's through masking, mapping, etc, and reads must produce a legal value. The timing question is rather moot when it needs to all happen during a single instruction.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CADQ6_n4bT%2BLGbJqPv39ZT%3DSY0r_%2BKDeAzVjWrL2c0SCMLzVwDg%40mail.gmail.com.

[Paul Donahue]

WARL doesn't say that there cannot be illegal system state.  It just says that reads must return legal values.  How and when this legalization happens is unspecified (but not UNSPECIFIED).

Suppose A=0 is illegal whenever B=0 but all other combinations are legal.  Consider the scenario where I write B=1, I write A=0, I write B=0.  If we only have input mapping then none of the writes was by itself illegal so hardware did no fixup on the writes.  Reading A will return 0 which is illegal and does not conform to WARL.

Suppose that we have output mapping and the same scenario.  The underlying state will contain A=0, B=0 which is an illegal system state.  But reads (whether implicit or explicit) will return A=1 so the illegal state cannot be detected and is WARL-compliant.  If there is a subsequent write of B=1 then a read of A will return 0 since the fixup is no longer necessary.

Thanks,

-Paul

[Allen Baum]

I believe that either output-mapping or input-mapping works.

When a CSR write of some other CSR causes this CSR field to have an illegal value), then 

 - if output mapped the value of the CSR field is mapped to a legal value when used, either when explicitly read, or implicitly read by HW.

 - else a write of a CSR with output dependencies on WARL fields  will cause *all* dependent CSR fields to be written with a legal value at the same time.

As mentioned, they are not equivalent and when a field with an output dependency is changed to make what originally had been legal to be legal again, 

(I hope that can be parsed) then either 

 - the original explicitly written value appears (if output mapped), 

 - the current value is unchanged (if input mapped)(assumes the current value is legal regardless of the written field) , 

-  some other nondeterministic value appears on a read (e.g. if the entire register disappears, like when MISA.S is cleared and then set).

In order to test this for compatibility, we need to know - for *every* WARL field with a dependency, which of these options is implemented, along with the illegal->legal mappings qre implemented for each and every WARL field for each value of the dependency field.  

The arch-test SIG knew that we can't test for any arbitrary mapping (since it isn't architectural), 

so it has defined a set of mappings that can be configured in the YAML, and will only test those. 

Any vendor that fails a test because they implement something different will need a waiver from TSC to be able to claim compatibility.

(and, in general, recommend output mapping for dependencies, and ignore write for non-dependent mappings.)

[Allen Baum]

Hmm, not sure I agree there. I thought that not only must a read return a legal value, but whatever function was dependent on that WARL field used the legal value read - so not just CSR reads.

A weird case is where all values become illegal, e.g if MISA.S is cleared. Then any S-mode CSR can't even be read, and VM mode is bare.

But for your example above, returning  A *may* return a 1 if input mapping is properly implemented (which means the write of B=0 will also cause the underlying state of A (and all other dependent WARL fields) to be written simultaneously. That, as far as I am aware, is both legal and (IMHO) ugly.

[Greg Favor]

On Mon, Sep 27, 2021 at 3:52 PM Allen Baum <allen...@esperantotech.com> wrote:

Hmm, not sure I agree there. I thought that not only must a read return a legal value, but whatever function was dependent on that WARL field used the legal value read - so not just CSR reads.

Yes, all explicit and implicit reads of a CSR must see a legal value and must see the same legal value.

Greg

[Paul Donahue]

I agree that you can have "comprehensive input mapping" where essentially each write to any CSR will relegalize the values of all CSRs.  As you mention, that can cause different behavior later so this comprehensive input mapping is not equivalent to output mapping in the long run.  I think that the architecture should address these things one way or the other.

I agree that CSR reads and whatever function depends on that field must both return the legal value.  Did I say otherwise?  I didn't mean to even imply otherwise.

Thanks,

-Paul

On Mon, Sep 27, 2021 at 3:52 PM Allen Baum <allen...@esperantotech.com> wrote: