CSR Reserved fields

[AFOliveira]

Currently, UDB omits all Reserved/WPRI fields in CSRs as we suppose they are all reserved for the future. However, they have semantic behaviour and more than that, they have differences in semantic behaviour between some.

Let me explain:

WPRI - Software should ignore the values read from these fields, and should preserve the values held in these fields when writing values to other fields
RESERVED - software should write zeros and hardware implementations should return zeros

Therefore, if we plan to continue ommiting WPRI fields, we need to at least explicitly state the Reserved fields that are non-WPRI to avoid downstream tools that rely on this information to mistakenly intake this information as being the same behaviour.

For now, I have only caught reserved in MNSTATUS.

Reference ISA Manual clarification - riscv/riscv-isa-manual#2318

[AFOliveira]

@henrikg-qc Does the integrated ISS handle this reserved and WPRI fields in CSRs?

[AFOliveira]

@james-ball-qualcomm From the CSC perspective, this seems to me like a silent mismatch that can definitely cause trouble between implementations. Moreover, if the CSC has that power I think questioning ARC whether this two behaviour need to be different would be wise. It seems like if the spec changed all to WPRI it wouldn't break existing implementation and would help standardize behaviour.

[jordancarlin]

I'm not sure that they are actually different at a hardware level. The next sentence of the WPRI explanation says "For forward compatibility, implementations that do not furnish these fields must make them read-only zero". That seems to indicate that for hardware, WPRI and RESERVED are the same. They are both read-only 0.

For software, they have the potential to be different, but until another extension redefines any of these fields, they are the same as well. For WPRI, software is supposed to maintain whatever was read, but the field is read-only 0 so that means software will always read (and therefore write) 0. That is the same as RESERVED. For RESERVED, the field is read as 0 and is supposed to be written as 0, so maintaining the current value and writing 0 are equivalent. This is the same as WPRI.

[AFOliveira]

@jordancarlin WPRI does not mandate that reads zero. The fields must be ignored when read. However, nothing ensures that it is 0, it may be an arbitrary value.

[jordancarlin]

@AFOliveira The full text from the spec is the following:

Some whole read/write fields are reserved for future use. Software should ignore the values read from these fields, and should preserve the values held in these fields when writing values to other fields of the same register. For forward compatibility, implementations that do not furnish these fields must make them read-only zero. These fields are labeled WPRI in the register descriptions.

The important part is what "implementations that do not furnish these fields" means. If these fields are not considered furnished when they are reserved, then they are read-only zero.

[AFOliveira]

@jordancarlin You're right on reading, I overlooked that last statement. However, I think there's still a problem with

should preserve the values held in these fields when writing values to other fields of the same register

As this is different than:

The other bits in mnstatus are reserved; software should write zeros

So, there's still a difference in behaviour between those. One may argue that's very small but since it exists, we can't really treat them as the same in SW.

[valeriyk]

I have found reserved fields which are WARL. E.g in MIE CSR.

But from a user perspective, I only need to know if a CSR has WPRI fields.

• If so, a write must be prohibited, only read-modify-write and atomic bit set/clear is allowed
• if not, I can still allow writing

Having a WPRI flag would allow a nice implementation of CSR functions, because all other attributes are already available in UDB:

• has readable fields? (gates the CSR read)
• has writable fields? (gates the CSR write)
• has single-bit fields? (gates the atomic bit set/clear)
• has WPRI fields? (gates the CSR write and atomic swap)
• and the combination of readable, writable and WPRI together gate the non-atomic read-modify-write.

So would be good to have that in UDB directly, or have a simple method of finding out.

At the same time, I'm concerned about soundness of this approach. It is safer to treat all "unknown" reserved fields as WPRI.
So "WPRI" flag should actually mean that "we couldn't prove that this field is not WPRI", which is confusing.

For now, to simplify my current implementation, I'm thinking of this:

• Treat all CSRs with reserved fields as having WPRI
• Manually white-list CSRs for which to allow writing

[dhower-qc]

@henrikg-qc Does the integrated ISS handle this reserved and WPRI fields in CSRs?

Any unspecified bits in a CSR are read-only-0 in the ISS

[AFOliveira]

Solutions agreed on:

1. Insert in UDB all non-WPRI fields.
2. Document that all the non-described fields in UDB CSRs are WPRI.

[ThinkOpenly]

> 1. Insert in UDB all non-WPRI fields. > 2. Document that all the non-described fields in UDB CSRs are WPRI.

Is this correct? Since per

Any unspecified bits in a CSR are read-only-0 in the ISS

The "weird" cases are WPRI, not reserved. Thus, shouldn't we instead:

1. Insert in UDB all WPRI fields.
2. Document that all otherwise unspecified bits in a CSR are reserved (read-only-0)?

(or maybe I'm misunderstanding.)

I had a misunderstanding. UDB default is WPRI.