WARL Clarification

[StevenBellock]

In the event that software writes an illegal value to a WARL field, is the hardware permitted to store that illegal value, and even use it in its execution, so long as when software reads the field it returns a legal value? Or must the illegal-to-legal conversion always happen during the write to the WARL field?

[Allen Baum]

Correct, but more specifically: after writing some value into a WARL field:

   if you read back the same value that was written, then it was a legal value. 

   If you read back any other value   then the value that was written was an illegal value, and the value that was read back is guaranteed to be legal.

The mapping from a specific illegal value to the legal value is completely arbitrary, but must determinstically depend on the state of the hart (which includes the previous value in that field) and the value being written.

That said: the compliance framework (in its next revision) must be provided with the specific mapping that an implementation performs.

Not all mappings are allowed, and the syntax and mappings can be found here: https://riscv-config.readthedocs.io/en/latest/yaml-specs.html#warl-field-definition

In many cases, the only legal value is 0, so it doesn't matter what you write, you'll always read zero.

The simplest other mapping is to inhibit the write and leave the old value.

Other possible mappings include the smallest, largest, and closest (with tie breakers) legal value  to the value being written.

WARL fields are characterized by 

 - a set of legal ranges (which can be as small as a single bit for fields such as SATP.mode), or 

 - mask/value pairs (the mask indicates which bits are writable, and the value is how the non-writable bits are set - simplest is no bits writable, all bits zero)

Subfields can also have separate mappings , e.g. 

 - the upper bits of mtvec could be a range, while 

 - the lower bits have only a legal value of zero.

The mappings can also change depending on the state of the hart, e.g. mtvec.base could have 

 -   4B alignment if mtvec.mode=00, or

 -  64B alignment if mtvec.mode=01.

On Thu, May 7, 2020 at 9:18 AM Zeeshan Rafique <zeeshanr...@gmail.com> wrote:

As WARL describes itself that "write any read legal" so let the instruction to write the csr 'warl' field, but while reading it make sure the value must be legal if it is illegal change it to legal.(set the higher priority)

--
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/3e42b9ec-2908-4c88-a7ce-ed3fa8e3b640%40groups.riscv.org.

[Allen Baum]

Just re-read the question again - and I don't think either of us answered it,

Effectively, the illegal value is never written, because if it were, then the HW would be required to actually use that value until it was read back.

Microarchitecturally, an implementation could write the illegal value, but any use of it, (including reading it), must never see the illegal value.

So the legal->illegal mapping could be implemented on the input or the output of the CSR.

A scan chain might be able to see the difference, but nothing else should.

[StevenBellock]

So a succinct way to state this is that "hardware sees whatever software sees", and that hardware can either:

- Perform the illegal-to-legal conversion on the software write and store it as a legal value

or

- Store the illegal value in the CSR, but whenever hardware utilizes it or software reads it, then an illegal-to-legal conversion is performed. 

On Thursday, May 7, 2020 at 9:51:30 AM UTC-7, Allen Baum wrote:

Just re-read the question again - and I don't think either of us answered it,

Effectively, the illegal value is never written, because if it were, then the HW would be required to actually use that value until it was read back.

Microarchitecturally, an implementation could write the illegal value, but any use of it, (including reading it), must never see the illegal value.

So the legal->illegal mapping could be implemented on the input or the output of the CSR.

A scan chain might be able to see the difference, but nothing else should.

On Thu, May 7, 2020 at 9:46 AM Allen Baum <alle...@esperantotech.com> wrote:

Correct, but more specifically: after writing some value into a WARL field:

   if you read back the same value that was written, then it was a legal value. 

   If you read back any other value   then the value that was written was an illegal value, and the value that was read back is guaranteed to be legal.

The mapping from a specific illegal value to the legal value is completely arbitrary, but must determinstically depend on the state of the hart (which includes the previous value in that field) and the value being written.

That said: the compliance framework (in its next revision) must be provided with the specific mapping that an implementation performs.

Not all mappings are allowed, and the syntax and mappings can be found here: https://riscv-config.readthedocs.io/en/latest/yaml-specs.html#warl-field-definition

In many cases, the only legal value is 0, so it doesn't matter what you write, you'll always read zero.

The simplest other mapping is to inhibit the write and leave the old value.

Other possible mappings include the smallest, largest, and closest (with tie breakers) legal value  to the value being written.

WARL fields are characterized by 

 - a set of legal ranges (which can be as small as a single bit for fields such as SATP.mode), or 

 - mask/value pairs (the mask indicates which bits are writable, and the value is how the non-writable bits are set - simplest is no bits writable, all bits zero)

Subfields can also have separate mappings , e.g. 

 - the upper bits of mtvec could be a range, while 

 - the lower bits have only a legal value of zero.

The mappings can also change depending on the state of the hart, e.g. mtvec.base could have 

 -   4B alignment if mtvec.mode=00, or

 -  64B alignment if mtvec.mode=01.

On Thu, May 7, 2020 at 9:18 AM Zeeshan Rafique <zeeshanr...@gmail.com> wrote:

As WARL describes itself that "write any read legal" so let the instruction to write the csr 'warl' field, but while reading it make sure the value must be legal if it is illegal change it to legal.(set the higher priority)

--
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...@groups.riscv.org.

[Paul Donahue]

I don't think that the spec is particularly clear on this topic, though I agree with the comments that the fixup should happen on the write.

What happens if I do this software sequence:

1. write misa.H=1

2. write mie[12]=1 (a legal value for the SGEIE bit which is a WARL field)

3. write misa.H=0 (which causes mie[12]=1 to no longer be legal)

4. read mie

Is hardware supposed to fix up the mie value returned in step 4?

Thanks,

-Paul

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/4025d808-deb1-4f7c-ae43-416f39074a6f%40groups.riscv.org.