clarify

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 9cd047b4367c45538692a6dda11cd995bf2bc265..4496bb14e05552417aa0d5e074a2fdee62f12c06 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -406,16 +406,21 @@ and is the only idea that meets the three requirements:
   (at all) that could cost them immediate short-term profits.**
   (met because existing implementations, with the exception of those
   that have Custom Extensions, come under the "vendor/arch-id read only
-  is a declaration of having no Custom Extensions" fall-back category)
+  is a formal declaration of an implementation having no Custom Extensions"
+  fall-back category)
 
 So to summarise:
 
 * The consequences of not tackling this are severe: the RISC-V Foundation
   cannot take a back seat.  If it does, clear historical precedent shows
   100% what the outcome will be (1).
+* Making the mvendorid and marchid CSRs WARL solves the problem in a
+  minimal to zero-disruptive fashion.
 * The retro-fitting cost onto existing implementations (even though the
-  specification has not been finalised) is negligeable
-  (changes to words in the specification)
+  specification has not been finalised) is zero to negligeable
+  (only changes to words in the specification required at this time:
+  no vendor need discard existing designs, either being designed,
+  taped out, or actually in production).
 * The benefits are clear (pain-free transition path for vendors to safely
   upgrade over time; no fights over Custom opcode space; no hassle for
   software toolchain; no hassle for GNU/Linux Distros)
@@ -424,10 +429,13 @@ So to summarise:
   an extreme unlikely outlier).
 * Compliance Testing is straightforward and allows vendors to seek and
   obtain *multiple* Compliance Certificates with past, present and future
-  variants of the RISC-V Standard (in the exact same processor), in order
-  support legacy customers and provide same customers with a way to avoid
-  "impossible-to-make" decisions that throw out ultra-expensive multi-decade
-  proprietary legacy software at the same as the hardware.
+  variants of the RISC-V Standard (in the exact same processor,
+  simultaneously), in order to support legacy customers and provide
+  same customers with a way to avoid "impossible-to-make" decisions that
+  throw out ultra-expensive multi-decade proprietary legacy software at
+  the same as the (legacy) hardware.
+
+-------
 
 # Conversation Exerpts