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

[lkcl]

Brad this message is the one did not see until now,
you can see it is forwarded manully (by me) to our
ISA miling list, please ensure tjis is one automatically
in future for all communication on LibreSOC RFCs, or
use our bugtracker, you will find the URL in each RFC.
thank you.

Date:
March 1, 2024, 1:34 AM
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/20240315/0dd929cb/attachment.html>