isa_conflict_resolution/mvendor_march_warl.mdwn

   1 # mvendorid/marchid WARL <a name="mvendor_marchid_warl"></a>
   2
   3 This proposal is to make the mvendorid and marchid CSRs have WARL (writeable)
   4 characteristics as a means and method of providing RISC-V implementations
   5 with a way to support multiple binary instruction encodings simultaneously
   6 within the same processor.  Each unique tuple (including on a per-hart
   7 basis) uniquely identifies and permits switch-over
   8 to a completely separate and distinct binary-encoding such that:
   9
  10 * Different versions (legacy and new) of the RISC-V Standard may be
  11   supported within the same processor
  12 * The fight over the extremely limited custom opcode space ends (permanently)
  13 * Entirely foreign ISA may be supported within the same processor
  14   (actually executed: i.e. not the same thing at all as the JIT Extension).
  15
  16 For instances where mvendorid and marchid are readable, that would be
  17 taken to be a Standards-mandatory "declaration" that the architecture
  18 has *no* Custom Extensions (and that it conforms precisely to one and
  19 only one specific variant of the RISC-V Specification).
  20
  21 Beyond that, the change is so simple and straightforward that there is not
  22 much to discuss aside from its feasibility and its implications.  The
  23 main considerations are:
  24
  25 * State information.  How is state to be handled?
  26 * Compliance.  What impact does the change have on Compliance (and testing)?
  27 * Implementation.  Is it feasible and practical?
  28 * Exception-handlling.  What happens during a trap?
  29 * Backwards compatibility.  Is the change zero-impact (for existing systems)
  30 * Forwards compatibility.  Does the change affect (limit) future hardware?
  31
  32 ## State information
  33
  34 Unlike with MISA (which can be used to completely switch off - i.e. power
  35 down) certain Extensions, state information is **not permitted to be
  36 altered or destroyed** during or by a switch-over.  Switch-over to a different
  37 mvendorid-marchid tuple shall have the effect of *purely* disabling certain
  38 instruction encodings and enabling others.
  39
  40 Note also that during (for example) standard OS context-switching *all*
  41 state of *all* extensions (and variants of the Base Standards) related
  42 to *all* mvendorid-marchid tuples will need to be saved onto the stack,
  43 given that a hart may, at any time, switch between any available
  44 mvendorid-marchid tuples.
  45
  46 ## Compliance
  47
  48 It was pointed out early in the discussions that Compliance Testing may
  49 **fail** any system that has mvendorid/marchid as WARL.  This however is a
  50 clear case of "Compliance Tail Wagging Standard Dog".  However it *was*
  51 recognised that overly complex Compliance Testing would result
  52 in rejection of the entire RISC-V Standard.
  53
  54 A simple solution is to modify the Compliance Test Suite to specify the
  55 required mvendorid/marchid to be tested, as a parameter to the test
  56 applications.  The test can be run multiple times, providing the
  57 implementor with multiple Compliance Certificates for the same processor,
  58 against *different variants* of past, present and future RISC-V Standards.
  59
  60 *This is clearly a desirable characteristic*
  61
  62 It's been noted that there may be certain legitimate cases where
  63 a mvendorid-marchid should *specifically* not be tested for RISC-V
  64 Certification Compliance: native support for foreign architectures (not
  65 related to the JIT Extension: *actual* full entire non-RISC-V foreign
  66 instruction encoding).  Exactly how this would work (vis-a-vis Compliance)
  67 needs discussion, as it would be unfortunate and undesirable for a hybrid
  68 processor capable of executing more than one hardware-level ISA support
  69 to not be permitted to receive RISC-V Certification Compliance.
  70
  71 How such foreign architectures would switch back to RISC-V when the foreign
  72 architecture does not support the concept of mvendorid-marchid is out of
  73 scope and left to implementors to define and implement equivalent
  74 functionality.
  75
  76 ## Implementation
  77
  78 The redirection of meaning of certain binary encodings to multiple
  79 engines was considered extreme, eyebrow-raising, and also (importantly)
  80 potentially expensive, introducing significant latency at the decode
  81 phase.
  82
  83 However, it was observed that MISA already switches out entire
  84 sets of instructions (interacts at the "decode" phase).  The difference
  85 between what MISA does and the mvendor/march-id WARL idea is that whilst
  86 MISA only switches instruction decoding on (or off), the WARL idea
  87 *redirects* encoding, effectively to *different* simultaneous engines,
  88 fortunately in a deliberately mutually-exclusive fashion.
  89
  90 Implementations would therefore, in each Extension (assuming one separate
  91 "decode" engine per Extension), simply have an extra (mutually-exclusively
  92 enabled) wire in the AND gate for any given binary encoding, and in this
  93 way there would actually be very little impact on the latency.  The assumption
  94 here is that there are not dozens of Extensions vying for the same binary
  95 encoding (at which point the Fabless Semi Company has other much more
  96 pressing issues to deal with that make resolving binary encoding conflicts
  97 trivial by comparison).
  98
  99 Also pointed out was that in certain cases pipeline stalls could be introduced
 100 during the switching phase, if needed, just as they may be needed for
 101 correct implementation of (mandatory) support for MISA.
 102
 103 ## Exception Handling (traps) and context-switching
 104
 105 In cases where mvendorid and marchid are WARL, the mvendorid-marchid
 106 becomes part of the execution context that must be saved (and switched
 107 as necessary) just like any other state / CSR.
 108
 109 When any trap exception is raised the context / state *must not* be
 110 altered (so that it can be properly saved, if needed, by the exception
 111 handler) and that includes the current mvendorid-marchid tuple.  This
 112 leads to some interesting situations where a hart could conceivably be
 113 directed to a set of trap handler binary instructions that the current
 114 mvendorid-marchid setting is incapable of correctly interpreting.
 115
 116 To fix this it will be necessary for implementations (hardware /
 117 software) to set up separate per-mvendorid-marchid trap handlers and
 118 for the hardware (or software) to switch to the appropriate trap "set"
 119 when the mvendorid-marchid is written to.  The switch to a different
 120 "set" will almost undoubtedly require (transparent) **hardware** assistance.
 121
 122 The reason for requiring hardware-assist for switching exception
 123 handling tables is because it has to be done atomically: there cannot
 124 be a situation where just as a hart is switching to a different
 125 mvendorid-marchid tuple an exception occurs, resulting in execution of
 126 effectively foreign instructions.
 127
 128 In essence this means that mtvec needs to be a multi-entry table, one
 129 per (mvendorid-marchid) tuple.  Likewise stvec, and bstvec.
 130
 131 ## Backwards-compatibility
 132
 133 Backwards compatibility is vital for Standards.  There are two aspects
 134 to this:
 135
 136 * The actual change to the Standard should be minimally-disruptive
 137 * There should be no interference between two different encodings
 138   (any two separate tuples).
 139
 140 Given that mvendorid and marchid are presently read-only; given that
 141 the change is to the *wording* and does not add any new CSRs; the change
 142 can clearly be seen to be zero-impact, with the exception being to
 143 implementors that have Custom Extensions in silicon at the moment.
 144
 145 On the second point: the *entire purpose* of the change is to provide
 146 globally world-wide irrevocable permanent distinction and separation
 147 between instruction encodings!
 148
 149 ## Forwards-compatibility
 150
 151 Forwards compatibility is again vital for Standards.  Standards are required
 152 to adapt, yet at the same time provide a means and method of identifying
 153 and separating older (and legacy) systems from present and future versions.
 154
 155 The clear separation which mutually-exclusively redirects encodings based
 156 on which mvendorid-marchid tuple is currently active clearly meets that
 157 requirement.
 158
 159 # How the "custom extension conflict" is solved
 160
 161 * Vendor 1 produces a Custom Extension
 162 * Vendor 2 produces a Custom Extension
 163 * Both Custom Extensions have conflicting binary encodings.
 164 * Fabless Semi Company 1 licenses both Vendor 1 and 2 Custom Extensions
 165 * Fabless Semi Company 1 sets marchid=0xeee1 WARL to represent
 166   enabling Vendor 1's conflicting encoding
 167 * Fabless Semi Company 1 sets marchid=0xeee2 WARL to represent
 168   enabling Vendor 2's conflicting encoding
 169 * Fabless Semi Company 1 contacts the FSF, submitting patches to gcc
 170   (and likewise with binutils) to register
 171   (mvendorid=fabless1,marchid=0xeee1) to be added to the global
 172   (FSF-curated?) database for Vendor 1's instruction encoding.
 173 * Likewise for Vendor 2's instruction encoding.
 174
 175 Note that the RISC-V Foundation is **not** involved (or consulted) in
 176 this process.  The **FSF** (as the Copyright holder of gcc and binutils)
 177 inherently and implicitly becomes the de-facto atomic arbiter in control
 178 of the registration of Custom Extension instruction encodings.
 179
 180 The FSF's "job" is however quite straightforward: ensure that all
 181 registrations are in fact unique.  It would be absolutely no good if a
 182 Vendor decided to re-use two mvendorid-marchid tuples to mean two
 183 totally different sets of instructions needed to be enabled!  Any
 184 Vendor attempting to do so should be red-flagged immediately.
 185
 186 Situations in which the FSF receives requests for patches with
 187 *another fabless semiconductor company's* mvendorid should also be treated
 188 with suspicion, at the very least being queried as to why one fabless semi
 189 company is trying to encroach on another company's JEDEC-registered
 190 encoding space.
 191
 192 The special case of the above is when a fabless semiconductor company
 193 implements a new version of the RISC-V Standard.  Here, again, the
 194 fabless semi company will provide patches to gcc and binutils, requesting
 195 that their specific mvendorid-marchid tuple be added to the (inherently
 196 de-facto atomic arbitrated) global database for that particular RISC-V
 197 Standard "Variant".
 198
 199 # Questions to be resolved
 200
 201 * Can the declaration (meaning) of read-only be expanded to cover
 202   any number of (non-conflicting) Custom Extensions?  What are the
 203   implications of doing so?