mx_selector uses a reserved-for-custom CSR address

[Wren6991]

The current spec allocates addresses in the reserved-for-custom CSR ranges for CXU control, e.g. mcx_selector is at 0xbc0. The ability to write 0 to the mcx_selector.version field means CXUs can interoperate cleanly with default non-CXU allocation of the custom opcodes, but this doesn't quite resolve clashes with legacy-custom CSRs. For example I implement a custom power state control CSR in the BCx address range.

If the CX TG is looking to define a standard extension for multiplexing functional units allocated to the custom* opcodes, is it actually permitted for that extension to unconditionally use reserved-for-custom CSR addresses? The defining feature of this address space is that standard extensions do not touch it (although a tree-falling-in-a-forest argument can be made for conditionally touching it being ok as long as this is not the default). Should the base CX CSRs instead be in the reserved-for-standard address ranges?

If there is resistance to dishing out four standard CSR addresses for the CX ISA extension, then a compromise would be to allocate a single bit in the standard space (like menvcfg) to enable the standard CX CSRs in the custom space. When disabled, you would get the machine's underlying allocation of those custom CSRs, or an illegal instruction exception if there is no such underlying allocation.

[grayresearch]

Thank you very much for reviewing the spec and for filing this issue.

Yes this spec, which we now refer to as the old spec, the (SoftCPU) SIG's spec, or the basis spec, intentionally proposed custom CSR addresses for its extensions and proposed to use this custom extension to multiplex other composable custom extensions. As you point out this compromises the objective of allowing composable extensions to use any custom instruction or custom CSR. But in lieu of RVIA adoption we hoped to advance a CX system that might be expressed as a custom extension.

Now within the pending RVIA CX task group we expect to introduce a package of standard extensions, e.g. for CX multiplexing and CX access control, that will use standard CSR addresses instead of the custom CSR addresses in this basis spec. (*)

Furthermore we expect to author new CX TG specifications, drawing on concepts and details from the basis spec as appropriate, rather than attempting to edit-in-place this spec into the anticipated CX TG spec(s).

I apologize that this new trajectory is not made clear e.g. in the repo README and the basis spec Preface and I will make this clear shortly.

--

(*) Note however that the anticipated new way of supporting CX agnostic state context management #28 incl. CX state context save/restore might yet propose a few standard CX CSRs (i.e. "standard custom CSRs") to interrogate and manage any CX state context. TBD.