Coprocessor should take RV32E into account

openhwgroup / core-v-xif

RISC-V eXtension interface that provides a generalized framework suitable to implement custom coprocessors and ISA extensions

https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/en

Other

60 stars 24 forks source link

Coprocessor should take RV32E into account #64

Open Silabs-ArjanB opened 1 year ago

Silabs-ArjanB commented 1 year ago

CORE-V-XIF needs to define how XIF can be used together with RV32E.

An initial proposal:

A processor configured to use RV32E will declare all instructions that would use a source or destination register within x16-x31 if the RV32I base would have been used as illegal and attempt them for offload.
A processor will never indicate that a register file source is valid via rs_valid if the related source is within x16-x31
A coprocessor shall only be allowed to accept such instructions if it is not actually using any register file register within the x16-x31 range (i.e. a coprocessor shall not wait for validity via rs_valid if the related source is within x16-x31 as it will never happen and the coprocessor shall ignore rs if the related source is within x16-x31. The coprocessor shall also never write to x16-x31 via the result interface)

christian-herber-nxp commented 1 year ago

Fully agree to the first bullet. As the encoding space with any operand in the x16-x31 range is considered custom. Second bullet, agree Third bullet: Is this really a special case within RV32E? If a custom instruction is defined from a standard instruction with out of range source or destination register(s), then those encoding bits are simply not meant to designate a register. Sounds to me the same if I have a custom instruction without source or destination register.

Silabs-ArjanB commented 1 year ago

Fully agree to the first bullet. As the encoding space with any operand in the x16-x31 range is considered custom.

Actually these encodings are no longer considered 'custom'. They are considered 'reserved'. Either way, the proposal it to offer such encodings for offload.

Third bullet: Is this really a special case within RV32E? If a custom instruction is defined from a standard instruction with out of range source or destination register(s), then those encoding bits are simply not meant to designate a register. Sounds to me the same if I have a custom instruction without source or destination register.

You are right about that. At the same time 'out of range source or destination registers' are not possible in RV32I, that is why I specifically mentioned it for RV32E. It does not imply any additional hardware (it is just something that could be verified for a coprocessor intended to work with a CPU using RV32E).

christian-herber-nxp commented 1 year ago

Actually these encodings are no longer considered 'custom'. They are considered 'reserved'. Either way, the proposal it to offer such encodings for offload.

Ok, I didn't observe this change until now. Then, I guess it is consistent with the general approach of the interface, that reserved means offered for offload.