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.  Each unique tuple (including on a per-hart
   5 basis within the same processor) uniquely identifies and permits switch-over
   6 to a completely separate and distinct binary-encoding such that:
   7
   8 * Different versions (legacy and new) of the RISC-V Standard may be
   9   supported within the same processor
  10 * The fight over the extremely limited custom opcode space ends (permanently)
  11 * Entirely foreign ISA may be supported within the same processor
  12   (actually executed: i.e. not the same thing at all as the JIT Extension).
  13
  14 For instances where mvendorid and marchid are readable, that would be
  15 taken to be a Standards-mandatory "declaration" that the architecture
  16 has *no* Custom Extensions (and that it conforms precisely to one and
  17 only one specific variant of the RISC-V Specification).
  18
  19 Beyond that, the change is so simple and straightforward that there is not
  20 much to discuss aside from its feasibility and its implications.  The
  21 main considerations are:
  22
  23 * State information.  How is state to be handled?
  24 * Compliance.  What impact does the change have on Compliance (and testing)?
  25 * Implementation.  Is it feasible and practical?
  26 * Exception-handlling.  What happens during a trap?
  27 * Backwards compatibility.  Is the change zero-impact (for existing systems)
  28 * Forwards compatibility.  Does the change affect (limit) future hardware?
  29
  30 ## State information
  31
  32 Unlike with MISA (which can be used to completely switch off - i.e. power
  33 down) certain Extensions, state information is **not permitted to be
  34 altered or destroyed** during or by a switch-over.  Switch-over to a different
  35 mvendorid-marchid tuple shall have the effect of *purely* disabling certain
  36 instruction encodings and enabling others.
  37
  38 Note also that during (for example) standard OS context-switching *all*
  39 state of *all* extensions (and variants of the Base Standards) related
  40 to *all* mvendorid-marchid tuples will need to be saved onto the stack,
  41 given that a hart may, at any time, switch between any available
  42 mvendorid-marchid tuples.
  43
  44 ## Compliance
  45
  46 It was pointed out early in the discussions that Compliance Testing may
  47 **fail** any system that has mvendorid/marchid as WARL.  This however is a
  48 clear case of "Compliance Tail Wagging Standard Dog".  However it *was*
  49 recognised that overly complex Compliance Testing would result
  50 in rejection of the entire RISC-V Standard.
  51
  52 A simple solution is to modify the Compliance Test Suite to specify the
  53 required mvendorid/marchid to be tested, as a parameter to the test
  54 applications.  The test can be run multiple times, providing the
  55 implementor with multiple Compliance Certificates for the same processor,
  56 against *different variants* of past, present and future RISC-V Standards.
  57
  58 *This is clearly a desirable characteristic*
  59
  60 It's been noted that there may be certain legitimate cases where
  61 a mvendorid-marchid should *specifically* not be tested for RISC-V
  62 Certification Compliance: native support for foreign architectures (not
  63 related to the JIT Extension: *actual* full entire non-RISC-V foreign
  64 instruction encoding).  Exactly how this would work (vis-a-vis Compliance)
  65 needs discussion, as it would be unfortunate and undesirable for a hybrid
  66 processor capable of executing more than one hardware-level ISA support
  67 to not be permitted to receive RISC-V Certification Compliance.
  68
  69 ## Implementation
  70
  71 The redirection of meaning of certain binary encodings to multiple
  72 engines was considered extreme, eyebrow-raising, and also (importantly)
  73 potentially expensive, introducing significant latency at the decode
  74 phase.
  75
  76 However, it was observed that MISA already switches out entire
  77 sets of instructions (interacts at the "decode" phase).  The difference
  78 between what MISA does and the mvendor/march-id WARL idea is that whilst
  79 MISA only switches instruction decoding on (or off), the WARL idea
  80 *redirects* encoding, effectively to *different* simultaneous engines,
  81 fortunately in a deliberately mutually-exclusive fashion.
  82
  83 Implementations would therefore, in each Extension (assuming one separate
  84 "decode" engine per Extension), simply have an extra (mutually-exclusively
  85 enabled) wire in the AND gate for any given binary encoding, and in this
  86 way there would actually be very little impact on the latency.  The assumption
  87 here is that there are not dozens of Extensions vying for the same binary
  88 encoding (at which point the Fabless Semi Company has other much more
  89 pressing issues to deal with that make resolving binary encoding conflicts
  90 trivial by comparison).
  91
  92 Also pointed out was that in certain cases pipeline stalls could be introduced
  93 during the switching phase, if needed, just as they may be needed for
  94 correct implementation of (mandatory) support for MISA.
  95
  96 ## Exception Handling (traps) and context-switching
  97
  98 In cases where mvendorid and marchid are WARL, the mvendorid-marchid
  99 becomes part of the execution context that must be saved (and switched
 100 as necessary) just like any other state / CSR.
 101
 102 When any trap exception is raised the context / state *must not* be
 103 altered (so that it can be properly saved, if needed, by the exception
 104 handler) and that includes the current mvendorid-marchid tuple.  This
 105 leads to some interesting situations where a hart could conceivably be
 106 directed to a set of trap handler binary instructions that the current
 107 mvendorid-marchid setting is incapable of correctly interpreting.
 108
 109 To fix this it will be necessary for implementations (hardware /
 110 software) to set up separate per-mvendorid-marchid trap handlers and
 111 for the hardware (or software) to switch to the appropriate trap "set"
 112 when the mvendorid-marchid is written to.  The switch to a different
 113 "set" will almost undoubtedly require (transparent) **hardware** assistance.
 114
 115 The reason for requiring hardware-assist for switching exception
 116 handling tables is because it has to be done atomically: there cannot
 117 be a situation where just as a hart is switching to a different
 118 mvendorid-marchid tuple an exception occurs, resulting in execution of
 119 effectively foreign instructions.
 120
 121 In essence this means that mtvec needs to be a multi-entry table, one
 122 per (mvendorid-marchid) tuple.  Likewise stvec, and bstvec.
 123
 124 ## Backwards-compatibility
 125
 126 Backwards compatibility is vital for Standards.  There are two aspects
 127 to this:
 128
 129 * The actual change to the Standard should be minimally-disruptive
 130 * There should be no interference between two different encodings
 131   (any two separate tuples).
 132
 133 Given that mvendorid and marchid are presently read-only; given that
 134 the change is to the *wording* and does not add any new CSRs; the change
 135 can clearly be seen to be zero-impact, with the exception being to
 136 implementors that have Custom Extensions in silicon at the moment.
 137
 138 On the second point: the *entire purpose* of the change is to provide
 139 globally world-wide irrevocable permanent distinction and separation
 140 between instruction encodings!
 141
 142 ## Forwards-compatibility
 143
 144 Forwards compatibility is again vital for Standards.  Standards are required
 145 to adapt, yet at the same time provide a means and method of identifying
 146 and separating older (and legacy) systems from present and future versions.
 147
 148 The clear separation which mutually-exclusively redirects encodings based
 149 on which mvendorid-marchid tuple is currently active clearly meets that
 150 requirement.
 151