Conflicts with shared opcodes

[kdockser]

Since the P and V extensions have overlapping functionality, yet are largely suited to different application domains, they are considered mutually incompatible. This avails each extension of the other's major opcode without concern of collision.

As allowed, the proposed Vector Crypto encodings overlap with some of the proposed Packed-SIMD encodings. We are getting conflicts when we run the python script in riscv-opcodes (with crypto opcodes in our own branch):

$ make
Running with args : ['./parse.py', '-c', '-go', '-chisel', '-sverilog', '-rust', '-latex', '-spinalhdl', 'rv*', 'unratified/rv*']
Extensions selected : ['rv*', 'unratified/rv*']
ERROR:: instruction : rstsa16 from rv_p has the same encoding with instruction vsha2ms_vv added from ['rv_zvknh'] in same base extensions
make: *** [Makefile:12: everything] Error 1

Right now both of these extensions are in unratified/rv*, but eventually they will be ratified.

@neelgala We need a means to tell the script which extensions' encodings should be processed and which should be ignored when the opcodes are reused in mutually exclusive extensions.

[aswaterman]

Note this isn't the only problematic case: for example, the Zcmt extension overlaps the double-precision FP instructions in the C extension.

I think the $pseudo_op designation could be used as a workaround, but I'm unsure whether this is the best solution, hence soliciting @neelgala's input.

[neelgala]

So when you say "mutually-exclusive extensions" I am assuming that those extensions can never exist together in hardware. This would also mean that those extensions don't occur together in the ISA string. Please correct me if am wrong.

@kdockser the quickest solution is to modify the EXTENSIONS variable in the makefile here. You can basically list out (space separated) all the extensions you want the script to parse. Each of those entries in the list are treated as regex so it shouldn't be tough to get what you want. This should allow you to bypass the above error quickly.

The long term solution here is to use $pseudo_op (as defined in this section). One of conflicting extensions will have the entire encoding for some base instruction, while in the other extension you will do a pseudo_op of this base instructions. For pseudo_ops the encodings can remain the same. So when both these conflicting extensions occur the pseudo_op will be dropped. Based on which extension needs priority you can decided where the base instructions go.

[aswaterman]

This would also mean that those extensions don't occur together in the ISA string

Yes, that's right.

[baibeta]

This would also mean that those extensions don't occur together in the ISA string

Yes, that's right.

I found several RISC-V ip cores support both P and V extensions, eg:
https://www.andestech.com/en/products-solutions/andescore-processors/riscv-nx27v/
The 64-bit NX27V... including ... “P” DSP extension instructions, “V” vector extension instructions...

https://www.nucleisys.com/product/rvipes/900/
RISC-V RV32/64 I/M/A/C/F/D/P/V ISA supported
Configurable vlength VFPU based on V-extensions
SIMD，Partial-SIMD，64-bit and Non-SIMD DSP instructions (P extension)

[aswaterman]

There's no such thing as an extension called "P" currently; there are only proposals. Vendors claiming support for "P" are claiming support for something that isn't a RISC-V standard. So it isn't really relevant.

(Note also it is possible for implementations to support conflicting extensions using a mode switch.)