Fix for MISA CSR spec for CV32A6

[MikeOpenHWGroup]

This PR addresses issue #1048.

Note: I am not sure whether to merge this into master or cv32a6_v5.0.0. My suggestion is the master branch since this PR updates the CV32E6 User Manual only and the master branch is used to by ReadTheDocs to publish CVA6 documentation.

[JeanRochCoulon]

LGTM. @ASintzoff Can you tell me if PR is OK to you ?

[ASintzoff]

LGTM. @ASintzoff Can you tell me if PR is OK to you ?

I'm wondering if RO wording is the appropriate one.
There is a difference between RO (read-only) CSR and WARL (write any values, read legal values). Write access to RO CSR raises an illegal instruction exceptions but write access to WARL does not.
As the behaviour is different, it could be useful to highlight the difference.

BTW, was the file generated by Register Manager? Does it mean the generation is only for the first version?

[MikeOpenHWGroup]

Good points @ASintzoff!

I'm wondering if RO wording is the appropriate one. There is a difference between RO (read-only) CSR and WARL (write any values, read legal values).

The access mode behaviours in the Privileged Specification define what software does, not hardware.

Write access to RO CSR raises an illegal instruction exceptions but write access to WARL does not. As the behaviour is different, it could be useful to highlight the difference.

The Privilege Spec says the hardware may raise an illegal exception, but I do not believe CVA6 does this. If I am right, then for the MISA an RO CSR is a legal way to implement a WARL CSR. See #1053.

BTW, was the file generated by Register Manager? Does it mean the generation is only for the first version?

We have a choice. We can either manually update the RST files (see #1049), or we can update the source input to Register Manager and regenerate the RST.

[ASintzoff]

Good points @ASintzoff!

I'm wondering if RO wording is the appropriate one. There is a difference between RO (read-only) CSR and WARL (write any values, read legal values).

The access mode behaviours in the Privileged Specification define what software does, not hardware.

Write access to RO CSR raises an illegal instruction exceptions but write access to WARL does not. As the behaviour is different, it could be useful to highlight the difference.

The Privilege Spec says the hardware may raise an illegal exception, but I do not believe CVA6 does this. If I am right, then for the MISA an RO CSR is a legal way to implement a WARL CSR. See #1053.

I agree that writing to misa does not raise any exception as it is a WARL register. From Privilege Spec: Implementations will not raise an exception on writes of unsupported values to a WARL field.

Nevertheless, do we need to distinguish the following behaviours:

• exception raised when write to read-only (as in RISC-V privilege spec) register. Attempts to access a CSR without appropriate privilege level or to write a read-only register also raise illegal instruction exceptions.
• silent execution when write to WARL register

BTW, was the file generated by Register Manager? Does it mean the generation is only for the first version?

We have a choice. We can either manually update the RST files (see #1049), or we can update the source input to Register Manager and regenerate the RST.

Manually updating the RST file is fine for me.

[JeanRochCoulon]

Yes, very good point! It will help verification to specify whether exception is generated (or not). But in that case, all registers are concerned by this modification, not only MISA CSR. The CSR spec is to be aligned on RISC-V specification and need to contain an explanation about the RO and WARL meanings.
Agree to modify the rst file.

[JeanRochCoulon]

@MikeOpenHWGroup As the current agreed stragtegy is to modify the IP-XACT version to generate the specification (rst file), this PR should be updated. @yanicasa what do you suggest as methodology to modify the IP-XACT file ?

[JeanRochCoulon]

@frikhaAziz This PR would like to modify the CSR specification. As this need to be done in IP-XACT, could you propose an PR to fix the spec.

[JeanRochCoulon]

Hello @mike, #1330 should have superseeded this PR. If you agree, can you close it ?

[MikeOpenHWGroup]

Closing as #1330 does indeed supersede this PR.