[Libre-soc-isa] [[OPF][ISA] #197576] ISA RFC Request - Formal Proposal - by Luke Leighton (Libre-SOC Team)

[Brad Frey via RT]

PUBLIC FEEDBACK – NON CONFIDENTIAL

Before addressing specific concerns, we need to reiterate from our previous
reply: “The OPF ISA TWG can only vote on a complete RFC, and this or any other
feedback given before we have a complete RFC is not binding with respect to
the outcome of a vote by the OPF ISA TWG or the votes of individual voting
members.”

We regret any misunderstandings about the expectations for an RFC submission.
The aggregate proposal embodied in sections 1 and 2 of the simple_v_spec.pdf
may enable us to give more confident feedback about the likelihood that the
Simple-V looping mechanism RFC, when complete, will receive a positive vote
from the workgroup, and how to improve that likelihood.  The aggregate
proposal is not a complete RFC submission, and we believe it will require
significant modifications (several person-months of work) to reach a point
where we can make final, detailed adjustments collaboratively.  Until that
time, we can only make coarse-grain observations about missing content and
style issues.

One ongoing misunderstanding is the belief that there’s a hidden development
process and/or list of requirements that will culminate in a successful RFC.
The goal is simply to provide introductory motivation and the equivalent of a
diff file that contains the changes to the existing document in front-to-back
order, preferably with terse motivations for non-editorial changes.  To ease
and accelerate the evaluation process, we recommend that changes include a
reasonable amount of surrounding context (existing architecture words that
aren’t changing).  Any content that doesn’t fit the foregoing description has
no place in the RFC.  So, for example, references to other architectures and
business considerations may be appropriate in limited quantities in the
introductory motivation, but nowhere else should they appear.

The way successful RFCs are developed is through flagrant plagiarism.  Find
parts of the existing architecture that have superficially similar functions
to what is trying to be described, then copy, paste, and modify.  Carefully
use the terminology defined in the architecture and the language and editorial
constructs that it commonly employs.  Be consistent in the choice of words and
language and editorial constructs to describe the new functionality.  Describe
function from the ground up or with reference to other parts of the Power
architecture, but without external references.  Make cross references to
related content in a different section that completes a concept instead of
duplicating large parts of descriptions.  The process is straightforward.

I skimmed the aggregate proposal and have two functionality-related comments
that are likely to impact the effort required to write and/or the
acceptability of the completed RFC.  The aggregate proposal uses Little Endian
ordering for register contents unless I misread.  The existing architecture
uses Big Endian ordering for register contents and that change to existing
functionality is highly unlikely to be an acceptable blanket change.  It will
almost certainly be necessary to create a control mechanism to reverse the
orientation with which the bytes are interpreted.  The effort required to
complete that will be quite large.  My other comment is about XLEN.  Reading
front to back, XLEN just sort of appears without definition.  That would need
to be fixed.  But the amount of effort required to complete an RFC that bases
the entire architecture on XLEN is quite large and would be very
difficult/controversial in places.  I strongly recommend that XLEN be deferred
to a later RFC to increase the tractability of the initial Simple-V looping
mechanism RFC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libre-soc.org/pipermail/libre-soc-isa/attachments/20240301/ed203fb7/attachment.html>