of the standard, regardless of whether the fixes are absolutely critical
show-stoppers or whether they are just keeping the standard up-to-date (2).
+With no transition path there is guaranteed to be tension and conflict
+within the RISC-V Community over whether revisions should be made:
+should existing legacy designs be prioritised, mutually-exclusively over
+future designs (and what happens during the transition period is absolute
+chaos, with the compiler toolchain, software ecosystem and ultimately
+the end-users bearing the full brunt of the impact). If several
+overlapping revisions are required that have not yet transitioned out
+of use (which could take well over two decades to occur) the situation
+becomes disastrous for the credibility of the entire RISC-V ecosystem.
+
It was also pointed out that Compliance is an extremely important factor
to take into consideration, and that Custom Extensions (as being optional)
-effectively fall entirely outside of the Compliance Testing. At this
-point in the discussion however it was not yet noted the stark problem
-that the *mandatory* RISC-V Specification also faces, by virtue of there
-being no transitional way to bring in show-stopping critical alterations.
+effectively and quite reasonably fall entirely outside of the scope of
+Compliance Testing. At this point in the discussion however it was not
+yet noted the stark problem that the *mandatory* RISC-V Specification
+also faces, by virtue of there being no transitional way to bring in
+show-stopping critical alterations.
To put this into perspective, just taking into account hardware costs
alone: with production mask charges for 28nm being around USD $1.5m,
projects / libreriscv.git / blobdiff