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