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