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 How such foreign architectures would switch back to RISC-V when the foreign
  70 architecture does not support the concept of mvendorid-marchid is out of
  71 scope and left to implementors to define and implement equivalent
  72 functionality.
  73
  74 ## Implementation
  75
  76 The redirection of meaning of certain binary encodings to multiple
  77 engines was considered extreme, eyebrow-raising, and also (importantly)
  78 potentially expensive, introducing significant latency at the decode
  79 phase.
  80
  81 However, it was observed that MISA already switches out entire
  82 sets of instructions (interacts at the "decode" phase).  The difference
  83 between what MISA does and the mvendor/march-id WARL idea is that whilst
  84 MISA only switches instruction decoding on (or off), the WARL idea
  85 *redirects* encoding, effectively to *different* simultaneous engines,
  86 fortunately in a deliberately mutually-exclusive fashion.
  87
  88 Implementations would therefore, in each Extension (assuming one separate
  89 "decode" engine per Extension), simply have an extra (mutually-exclusively
  90 enabled) wire in the AND gate for any given binary encoding, and in this
  91 way there would actually be very little impact on the latency.  The assumption
  92 here is that there are not dozens of Extensions vying for the same binary
  93 encoding (at which point the Fabless Semi Company has other much more
  94 pressing issues to deal with that make resolving binary encoding conflicts
  95 trivial by comparison).
  96
  97 Also pointed out was that in certain cases pipeline stalls could be introduced
  98 during the switching phase, if needed, just as they may be needed for
  99 correct implementation of (mandatory) support for MISA.
 100
 101 ## Exception Handling (traps) and context-switching
 102
 103 In cases where mvendorid and marchid are WARL, the mvendorid-marchid
 104 becomes part of the execution context that must be saved (and switched
 105 as necessary) just like any other state / CSR.
 106
 107 When any trap exception is raised the context / state *must not* be
 108 altered (so that it can be properly saved, if needed, by the exception
 109 handler) and that includes the current mvendorid-marchid tuple.  This
 110 leads to some interesting situations where a hart could conceivably be
 111 directed to a set of trap handler binary instructions that the current
 112 mvendorid-marchid setting is incapable of correctly interpreting.
 113
 114 To fix this it will be necessary for implementations (hardware /
 115 software) to set up separate per-mvendorid-marchid trap handlers and
 116 for the hardware (or software) to switch to the appropriate trap "set"
 117 when the mvendorid-marchid is written to.  The switch to a different
 118 "set" will almost undoubtedly require (transparent) **hardware** assistance.
 119
 120 The reason for requiring hardware-assist for switching exception
 121 handling tables is because it has to be done atomically: there cannot
 122 be a situation where just as a hart is switching to a different
 123 mvendorid-marchid tuple an exception occurs, resulting in execution of
 124 effectively foreign instructions.
 125
 126 In essence this means that mtvec needs to be a multi-entry table, one
 127 per (mvendorid-marchid) tuple.  Likewise stvec, and bstvec.
 128
 129 ## Backwards-compatibility
 130
 131 Backwards compatibility is vital for Standards.  There are two aspects
 132 to this:
 133
 134 * The actual change to the Standard should be minimally-disruptive
 135 * There should be no interference between two different encodings
 136   (any two separate tuples).
 137
 138 Given that mvendorid and marchid are presently read-only; given that
 139 the change is to the *wording* and does not add any new CSRs; the change
 140 can clearly be seen to be zero-impact, with the exception being to
 141 implementors that have Custom Extensions in silicon at the moment.
 142
 143 On the second point: the *entire purpose* of the change is to provide
 144 globally world-wide irrevocable permanent distinction and separation
 145 between instruction encodings!
 146
 147 ## Forwards-compatibility
 148
 149 Forwards compatibility is again vital for Standards.  Standards are required
 150 to adapt, yet at the same time provide a means and method of identifying
 151 and separating older (and legacy) systems from present and future versions.
 152
 153 The clear separation which mutually-exclusively redirects encodings based
 154 on which mvendorid-marchid tuple is currently active clearly meets that
 155 requirement.
 156
 157 # Questions to be resolved
 158
 159 * Can the declaration (meaning) of read-only be expanded to cover
 160   any number of (non-conflicting) Custom Extensions?  What are the
 161   implications of doing so?