[Libre-soc-isa] https://libre-soc.org/openpower/ISA_WG/Board_letter_26mar2021/

[lkcl]

Dear OPF Board,

As you know the LibreSOC team have been working for over 3 years on a
massive conceptual upgrade to the OpenPOWER ISA, based on Cray-Style
Vectors, which will modernise it for today's 3D and VPU workloads,
with an incidental side-effect of upgrading it for future
supercomputing needs over the next few decades in a clean and elegant
fashion.

RISC-V has RVV, ARM has SVE2, x86 has AVX512, whilst OpenPOWER has an
out-of-date SIMD ISA which is already so large that efforts to update
it to suit modern 3D Shader and Video workloads would do far more harm
than good. It goes without saying that over the past few decades, SIMD
has been demonstrated to be harmful.

https://www.sigarch.org/simd-instructions-considered-harmful/

Normally, such huge ISA development efforts would be instigated,
organised and funded through either Academia or an extremely large
Corporation, or a Consortium combining multiple such entities. It is
therefore without precedent across the Computing Industry for
something of this magnitude of effort to come not only from
individuals with a completely independent non-affiliated Libre
background but from a Libre background that is funded by a Charitable
Foundation with a mandate to exclusively fund "Works for the Public
Good" (NLnet).

>From reading the PowerISA v3.0C sections we have learned and taken on
board that a "Sandbox" opcode exists (EXT22) which is intended for
"small private extensions" to the OpenPOWER ISA. The expectation that
these extensions not be supported by upstream tool-chains is something
with which we wholeheartedly agree.

The problem is that our Bit-Manipulation Extension alone, needed for
Audio/Video and Cryptographic workloads, struggles to fit into that
space, and we have not yet added Custom 3D opcodes or the IEEE754
Transcendentals (SIN, COS).

http://libre-soc.org/openpower/bitmanip

More than that, these are all "general-purpose" opcodes with uses far
beyond LibreSOC's use-case (notwithstanding LibreSOC's use-case itself
being by definition general-purpose).

More than that, going far beyond the "letter" of our obligations to
respect the stability of the OpenPOWER ecosystem, given that LibreSOC
is targeting high-profile mass-volume general-purpose computing, it is
our duty and responsibility to ensure that use of EXT22 does not
result in end-user developer pressure for upstream tool-chains to
override the OPF's remit, by unintentionally de-facto dominating EXT22
for LibreSOC use simply by popular overwhelming end-user demand,
outside of everyone's control.

We are also getting slightly concerned in that the resources needed
(SPR allocations, allocation of Reserved v3.1 64 bit EXT01 prefix
space to support SVP64) is quite large, and well outside of the
"anticipated" resources allocated for Sandboxing. There is no
allocation of EXT01 at all for example. Yet after one year we still
have no two-way communications channel established to discuss even the
possibility of additional reservations.

The advice in the PowerISA v3.0C document requires us to contact the
OpenPOWER Foundation, to initiate the process of including our
opcodes, and SVP64, in the OpenPOWER ISA, yet, here, we run into an
interesting twist.

In speaking verbally and informally with various people (Toshaan, Paul
and Hugh) we have pieced together the way that the OpenPOWER
Foundation ISA Workgroup is to be set up, and we have become aware
that there may be a mis-match here caused by "otherwise normally
expected" provenance of ISA proposals which, from what we can gather,
is being built-in to the ISA WG's by-laws.

>From what we understand, individuals with no affiliation (to a Company
or Academic Institution) would be prevented from tabling arbitrary ISA
extensions (without a sponsor, that is). Given that the OPF ISA WG has
to act entirely fairly i.e. in a non-discriminatory fashion towards
all proposals, yet also take into account the huge burden of time and
responsibility that results in perpetuity from any such inclusion, it
is a reasonable balance. We understand and respect that proposers
should demonstrate the willingness and access to resources sufficient
to see through a long-term committment to the OpenPOWER ISA.

Yet at the same time, whilst being perfectly reasonable, we feel that
our unique circumstances have not been anticipated. We would therefore
welcome some constructive feedback as to how we would go about
submitting our work, and also how we can communicate effectively that
we are in this for the long haul, and are committed to seeing it
through.

Note: the work that LibreSOC is doing is definitively intended for the
long term. Thanks to NLnet's "Works for the Public Good" remit, even
if, by some mischance, LibreSOC was to evaporate the work that we are
doing would still be available since what we do is entirely libre.

At this point however it is important to provide some context as to
why RED Semiconductor exists. RED Semiconductor is being set up to
realise LibreSOC designs and concepts in actual silicon. It is NOT
intended to REPLACE LibreSOC because to assign Copyright to a
Corporation is prohibited by our relationship with NLnet (assigning to
a Foundation however such as OPF is perfectly fine).

Therefore whilst we in LibreSOC as individuals are the actual
non-affiliated architects of the ISA Extensions, RED Semiconductor
will not own the Copyright but will be in exactly the same boat as any
other Corporation at liberty to implement SVP64 because of its Libre
provenance.

The key person acting as the bridge between both world will be myself
(Luke Leighton), and I will ensure and require that RED Semiconductor
provides adequate funds and resources for the long haul, in order to
not only see through the proposals but also ensure that the associated
toolchains, test suites, documentation etc. are properly written and
maintained, long-term. Yet I stress, again, that despite committing
the financial resources, RED Semiconductor will not own the Copyright
or any patents on LibreSOC work.

Our goal here is the ongoing long-term evolution of OpenPOWER, meeting
the needs of an entirely new market of end-users currently not served
by OpenPOWER or any OPF Members, and still maintaining the long-term
stability and reputation of the OpenPOWER ecosystem.

My question to you is, therefore: what is the best way forward, here?
What "vehicle" or arrangement would be suitable that takes into
account these unique circumstances? Would a conference call perhaps be
a good idea to discuss?

Respectfully,

Luke Leighton