# Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path
+## Executive Summary
+
+A non-invasive backwards-compatible change to make mvendorid and marchid
+being read-only to be a formal declaration of an architecture having no
+Custom Extensions, and being permitted to be WARL in order to support
+multiple simultaneous architectures on the same processor (or per hart
+or harts) permits not only backwards and forwards compatibility with
+existing implementations of the RISC-V Standard, not only permits seamless
+transitions to future versions of the RISC-V Standard (something that is
+not possible at the moment), but fixes the problem of clashes in Custom
+Extension opcodes on a global worldwide permanent and ongoing basis.
+
+Summary of impact and benefits:
+
+* Implementation impact for existing implementations (even though
+ the Standard is not finalised) is zero.
+* Impact for future implementations compliant with (only one) version of the
+ RISC-V Standard is zero.
+* Benefits for implementations complying with (one or more) versions
+ of the RISC-V Standard is: increased customer acceptance due to
+ a smooth upgrade path at the customer's pace and initiative vis-a-vis
+ legacy proprietary software.
+* Benefits for implementations deploying multiple Custom Extensions
+ are a massive reduction in NREs and the hugely reduced ongoing software
+ toolchain maintenance costs plus the benefit of having security updates
+ from upstream software sources due to
+ *globally unique identifying information* resulting in zero binary
+ encoding conflicts in the toolchains and resultant binaries
+ *even for Custom Extensions*.
+
+## Introduction
+
In a lengthy thread that ironically was full of conflict indicative
of the future direction in which RISC-V will go if left unresolved,
multiple Custom Extensions were noted to be permitted free rein to
sets of instructions (interacts at the "decode" phase). The difference
between what MISA does and the mvendor/march-id WARL idea is that whilst
MISA only switches instruction decoding on (or off), the WARL idea
-*redirects* encoding, to *different* engines, fortunately in a deliberately
-mutually-exclusive fashion.
+*redirects* encoding, effectively to *different* simultaneous engines,
+fortunately in a deliberately mutually-exclusive fashion.
Implementations would therefore, in each Extension (assuming one separate
"decode" engine per Extension), simply have an extra (mutually-exclusively
way there would actually be very little impact on the latency. The assumption
here is that there are not dozens of Extensions vying for the same binary
encoding (at which point the Fabless Semi Company has other much more
-pressing issues to deal with that make resolving encoding conflicts trivial
-by comparison).
+pressing issues to deal with that make resolving binary encoding conflicts
+trivial by comparison).
Also pointed out was that in certain cases pipeline stalls could be introduced
during the switching phase, if needed, just as they may be needed for
not quite I think. It is more like
+// Hardware, implementing interface with UUID 0xABCD
+
def A_shutdown(cookie, data):
...
def A_do_more_stuff(cookie, data):
...
- def B_do_stuff(cookie, data):
- ...
+ interfaceA = {
+ "shutdown": A_shutdown,
+ "init": A_init,
+ "ctl0": A_do_stuff,
+ "ctl1": A_do_more_stuff
+ }
+
+// hardware implementing interface with UUID = 0x1234
+ def B_do_things(cookie, data):
+ ...
def B_shutdown(cookie, data)
...
- interfaceA = {
- shutdown: A_shutdown,
- init: A_init,
- ctl0: A_do_stuff,
- ctl1: A_do_more_stuff
- }
-
interfaceB = {
- shutdown: B_shutdown,
- init: B_init,
- ctl0: B_do_stuff
+ "shutdown": B_shutdown,
+ "ctl0": B_do_things
}
+
+// The CPU being wired to the devices
+
cpu_interfaces = {
0xABCD: interfaceA,
0x1234: interfaceB
}
+// The functionality that the CPU must implement to use the extension interface
+
cpu_open_handles = {}
__handleId = 0
def new_unused_handle_id()
- __handle = __handle + 1
- return __handle
+ __handleId = __handleId + 1
+ return __handleId
def ext_open(uuid, data):
interface = cpu_interface[uuid]
if interface == NIL:
- raise Exception("Unrecognised interface")
+ raise Exception("No such interface")
handleId = new_unused_handle_id()
- cpu_open_handles[handleId] = (interface, CurrentVirtualMemoryAddressSpace).
- cookie = A_init(data)
+ cpu_open_handles[handleId] = (interface, CurrentVirtualMemoryAddressSpace)
+
+ cookie = A_init(data) # Here device takes over
return (handle_id, cookie)
assert(interface != NIL)
shutdown = interface["shutdown"]
if shutdown != NIL:
- err = interface.shutdown(cookie, data)
+
+ err = interface.shutdown(cookie, data) # Here device takes over
+
if err != 0:
return err
cpu_open_handles[handleId] = NIL
(handleId, cookie) = handle
intf_VMA = cpu_open_handles[handleId]
if intf_VMA == NIL:
- raise Exception("unknown interface")
+ raise Exception("No such interface")
(interface, VMA) = intf_VMA
if VMA != CurrentVirtualMemoryAddressSpace:
- raise Exception("unknown interface") #Disclosing that the interface exists in different address is security hole
+ raise Exception("No such interface") #Disclosing that the interface exists in different address is security hole
assert(interface != NIL)
ctl0 = interface["ctl0"]
if ctl0 == NIL:
- raise Exception("Invalid Instruction")
+ raise Exception("No such Instruction")
- return ctl0(cookie, data)
+ return ctl0(cookie, data) # Here device takes over
- The other ext_ctl's are similar.
+The other ext_ctl's are similar.
==End RB==
cannot take a back seat. If it does, clear historical precedent shows
100% what the outcome will be (1).
* Making the mvendorid and marchid CSRs WARL solves the problem in a
- minimal to zero-disruptive fashion.
+ minimal to zero-disruptive backwards-compatible fashion that provides
+ indefinite transparent *forwards*-compatibility.
* The retro-fitting cost onto existing implementations (even though the
specification has not been finalised) is zero to negligeable
(only changes to words in the specification required at this time:
* Compliance Testing is straightforward and allows vendors to seek and
obtain *multiple* Compliance Certificates with past, present and future
variants of the RISC-V Standard (in the exact same processor,
- simultaneously), in order to support legacy customers and provide
- same customers with a way to avoid "impossible-to-make" decisions that
- throw out ultra-expensive multi-decade proprietary legacy software at
- the same as the (legacy) hardware.
+ simultaneously), in order to support end-customer legacy scenarios and
+ provide the same with a way to avoid "impossible-to-make" decisions that
+ throw out ultra-costly multi-decade-investment in proprietary legacy
+ software at the same as the (legacy) hardware.
-------
projects / libreriscv.git / blobdiff