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