isa_conflict_resolution/mvendor_march_warl.mdwn

   1 # mvendorid/marchid WARL <a name="mvendor_marchid_warl"></a>
   2
   3 (Summary: the only idea that meets the full requirements.  Needs
   4  toolchain backup, but only when the first chip is released)
   5
   6 This proposal is make the mvendorid and marchid CSRs have WARL (writeable)
   7 characteristics.  Each unique tuple identifies (including on a per-hart
   8 basis within the same processor) and switches over to a completely
   9 separate and distinct binary-encoding support such that:
  10
  11 * Different versions (legacy and new) of the RISC-V Standard may be
  12   supported within the same processor
  13 * The fight over the extremely limited custom opcode space ends
  14 * Entirely foreign ISA may be supported within the same processor
  15   (not the same as JIT Extension).
  16
  17 For instances where mvendorid and marchid are readable, that would be
  18 taken to be a Standards-mandatory "declaration" that the architecture
  19 has *no* Custom Extensions (and that it conforms precisely to one and
  20 only one specific variant of the RISC-V Specification).
  21
  22 This incredibly simple non-invasive idea has some unique and distinct
  23 advantages over other proposals:
  24
  25 * Existing designs - even though the specification is not finalised
  26   (but has "frozen" aspects) - would be completely unaffected: the
  27   change is to the "wording" of the specification to "retrospectively"
  28   fit reality.
  29 * Unlike with the MISA idea this is *purely* at the "decode" phase:
  30   no internal Extension state information is permitted to be disabled,
  31   altered or destroyed as a direct result of writing to the
  32   mvendor/march-id CSRs.
  33 * Compliance Testing may be carried out with a different vendorid/marchid
  34   tuple set prior to a test, allowing a vendor to claim *Certified*
  35   compatibility with *both* one (or more) legacy variants of the RISC-V
  36   Specification *and* with a present one.
  37 * With sufficient care taken in the implementation an implementor
  38   may have multiple interpretations of the same binary encoding within
  39   an inner loop, with a single instruction (to the WARL register)
  40   changing the meaning.
  41
  42 A couple of points were made:
  43
  44 * Compliance Testing may **fail** any system that has mvendorid/marchid
  45   as WARL.  This however is a clear case of "Compliance Tail Wagging Standard
  46   Dog".
  47 * The redirection of meaning of certain binary encodings to multiple
  48   engines was considered extreme, eyebrow-raising, and also (importantly)
  49   potentially expensive, introducing significant latency at the decode
  50   phase.
  51
  52 On this latter point, it was observed that MISA already switches out entire
  53 sets of instructions (interacts at the "decode" phase).  The difference
  54 between what MISA does and the mvendor/march-id WARL idea is that whilst
  55 MISA only switches instruction decoding on (or off), the WARL idea
  56 *redirects* encoding, effectively to *different* simultaneous engines,
  57 fortunately in a deliberately mutually-exclusive fashion.
  58
  59 Implementations would therefore, in each Extension (assuming one separate
  60 "decode" engine per Extension), simply have an extra (mutually-exclusively
  61 enabled) wire in the AND gate for any given binary encoding, and in this
  62 way there would actually be very little impact on the latency.  The assumption
  63 here is that there are not dozens of Extensions vying for the same binary
  64 encoding (at which point the Fabless Semi Company has other much more
  65 pressing issues to deal with that make resolving binary encoding conflicts
  66 trivial by comparison).
  67
  68 Also pointed out was that in certain cases pipeline stalls could be introduced
  69 during the switching phase, if needed, just as they may be needed for
  70 correct implementation of (mandatory) support for MISA.
  71
  72 Update 29apr2018:
  73
  74 * In cases where mvendorid and marchid are WARL, the mvendorid-marchid becomes
  75   part of the execution context that must be saved (and switched as necessary)
  76   just like any other state / CSR.
  77 * When any trap exception is raised the context / state *must not* be altered
  78   (so that it can be properly saved, if needed, by the exception handler)
  79   and that includes the current mvendorid-marchid tuple.  This leads to some
  80   interesting situations where a hart could conceivably be directed
  81   to a set of trap handler binary instructions that the current
  82   mvendorid-marchid setting is incapable of correctly interpreting.
  83   To fix this it will be necessary for implementations (hardware /
  84   software) to set up separate per-mvendorid-marchid trap handlers and
  85   for the hardware (or software) to switch to the appropriate trap "set"
  86   when the mvendorid-marchid is written to.  The switch to a different
  87   "set" will almost undoubtedly require (transparent) hardware assistance.
  88 * It's been noted that there may be certain legitimate cases where an
  89   mvendorid-marchid should *specifically* not be tested for RISC-V
  90   Certification Compliance: native support for foreign architectures
  91   (not related to the JIT Extension: *actual* full entire non-RISC-V
  92   foreign instruction encoding).  Exactly how this would work (vis-a-vis
  93   Compliance) needs discussion, as it would be unfortunate and
  94   undesirable for a hybrid processor capable of executing more than one
  95   hardware-level ISA support to not be permitted to receive RISC-V
  96   Certification Compliance.
  97