<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >Hi Luke,</div>
<div dir="ltr" > </div>
<div dir="ltr" >I don't believe you have the correct understanding here.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Specifically with respect to this statement it is in direct conflict with requirements of the ISA WG.</div>
<div dir="ltr" ><span style="color:#0000ff;" >From what we understand, individuals with no affiliation (to a Company<br>or Academic Institution) would be prevented from tabling arbitrary ISA<br>extensions (without a sponsor, that is).</span></div>
<div dir="ltr" ><div dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > </div>
<div dir="ltr" >Within the ISA WG charter there is a specific requirement that the WG has a process to enable RFCs (Requests for Change) to be submitted for contribution from Non-Members (this was actually a requirement from IBM when we licensed the POWER ISA to OPF in the first place).  OPF's IPR Policy also addresses contributions from Non-Members.</div>
<div dir="ltr" > </div>
<div dir="ltr" >I'm happy to have a call to explain further.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Regards,</div>
<div dir="ltr" >Mendy</div>
<div dir="ltr" ><br><font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2" >--------------------------------------------------<br>Mendy Furmanek<br>Director - POWER Open Hardware Business Development</font></div>
<div dir="ltr" ><font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2" >OpenPOWER Foundation President<br>Mobile: (512) 507-4772</font></div></div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: lkcl <luke.leighton@gmail.com><br>To: BoD- OpenPOWER Foundation <board@openpowerfoundation.org>, libre-soc-isa@lists.libre-soc.org<br>Cc: "Tim 'mithro' Ansell" <me@mith.ro>, "Toshaan Bharvani | VanTosh" <toshaan@vantosh.com>, James Kulina <james@openpowerfoundation.org>, mendy <mendy@openpowerfoundation.org>, Alain Williams <addw@phcomp.co.uk>, David Calderwood <djac@calderwoodhan.com>, Paul Mackerras <paulus@ozlabs.org><br>Subject: [EXTERNAL] https://libre-soc.org/openpower/ISA_WG/Board_letter_26mar2021/<br>Date: Tue, Mar 30, 2021 12:04 PM<br> 
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >Dear OPF Board,<br><br>As you know the LibreSOC team have been working for over 3 years on a<br>massive conceptual upgrade to the OpenPOWER ISA, based on Cray-Style<br>Vectors, which will modernise it for today's 3D and VPU workloads,<br>with an incidental side-effect of upgrading it for future<br>supercomputing needs over the next few decades in a clean and elegant<br>fashion.<br><br>RISC-V has RVV, ARM has SVE2, x86 has AVX512, whilst OpenPOWER has an<br>out-of-date SIMD ISA which is already so large that efforts to update<br>it to suit modern 3D Shader and Video workloads would do far more harm<br>than good. It goes without saying that over the past few decades, SIMD<br>has been demonstrated to be harmful.<br><br><a href="https://www.sigarch.org/simd-instructions-considered-harmful/" target="_blank">https://www.sigarch.org/simd-instructions-considered-harmful/</a> <br><br>Normally, such huge ISA development efforts would be instigated,<br>organised and funded through either Academia or an extremely large<br>Corporation, or a Consortium combining multiple such entities. It is<br>therefore without precedent across the Computing Industry for<br>something of this magnitude of effort to come not only from<br>individuals with a completely independent non-affiliated Libre<br>background but from a Libre background that is funded by a Charitable<br>Foundation with a mandate to exclusively fund "Works for the Public<br>Good" (NLnet).<br><br>From reading the PowerISA v3.0C sections we have learned and taken on<br>board that a "Sandbox" opcode exists (EXT22) which is intended for<br>"small private extensions" to the OpenPOWER ISA. The expectation that<br>these extensions not be supported by upstream tool-chains is something<br>with which we wholeheartedly agree.<br><br>The problem is that our Bit-Manipulation Extension alone, needed for<br>Audio/Video and Cryptographic workloads, struggles to fit into that<br>space, and we have not yet added Custom 3D opcodes or the IEEE754<br>Transcendentals (SIN, COS).<br><br><a href="http://libre-soc.org/openpower/bitmanip" target="_blank">http://libre-soc.org/openpower/bitmanip</a> <br><br>More than that, these are all "general-purpose" opcodes with uses far<br>beyond LibreSOC's use-case (notwithstanding LibreSOC's use-case itself<br>being by definition general-purpose).<br><br>More than that, going far beyond the "letter" of our obligations to<br>respect the stability of the OpenPOWER ecosystem, given that LibreSOC<br>is targeting high-profile mass-volume general-purpose computing, it is<br>our duty and responsibility to ensure that use of EXT22 does not<br>result in end-user developer pressure for upstream tool-chains to<br>override the OPF's remit, by unintentionally de-facto dominating EXT22<br>for LibreSOC use simply by popular overwhelming end-user demand,<br>outside of everyone's control.<br><br>We are also getting slightly concerned in that the resources needed<br>(SPR allocations, allocation of Reserved v3.1 64 bit EXT01 prefix<br>space to support SVP64) is quite large, and well outside of the<br>"anticipated" resources allocated for Sandboxing. There is no<br>allocation of EXT01 at all for example. Yet after one year we still<br>have no two-way communications channel established to discuss even the<br>possibility of additional reservations.<br><br>The advice in the PowerISA v3.0C document requires us to contact the<br>OpenPOWER Foundation, to initiate the process of including our<br>opcodes, and SVP64, in the OpenPOWER ISA, yet, here, we run into an<br>interesting twist.<br><br>In speaking verbally and informally with various people (Toshaan, Paul<br>and Hugh) we have pieced together the way that the OpenPOWER<br>Foundation ISA Workgroup is to be set up, and we have become aware<br>that there may be a mis-match here caused by "otherwise normally<br>expected" provenance of ISA proposals which, from what we can gather,<br>is being built-in to the ISA WG's by-laws.<br><br>From what we understand, individuals with no affiliation (to a Company<br>or Academic Institution) would be prevented from tabling arbitrary ISA<br>extensions (without a sponsor, that is). Given that the OPF ISA WG has<br>to act entirely fairly i.e. in a non-discriminatory fashion towards<br>all proposals, yet also take into account the huge burden of time and<br>responsibility that results in perpetuity from any such inclusion, it<br>is a reasonable balance. We understand and respect that proposers<br>should demonstrate the willingness and access to resources sufficient<br>to see through a long-term committment to the OpenPOWER ISA.<br><br>Yet at the same time, whilst being perfectly reasonable, we feel that<br>our unique circumstances have not been anticipated. We would therefore<br>welcome some constructive feedback as to how we would go about<br>submitting our work, and also how we can communicate effectively that<br>we are in this for the long haul, and are committed to seeing it<br>through.<br><br>Note: the work that LibreSOC is doing is definitively intended for the<br>long term. Thanks to NLnet's "Works for the Public Good" remit, even<br>if, by some mischance, LibreSOC was to evaporate the work that we are<br>doing would still be available since what we do is entirely libre.<br><br>At this point however it is important to provide some context as to<br>why RED Semiconductor exists. RED Semiconductor is being set up to<br>realise LibreSOC designs and concepts in actual silicon. It is NOT<br>intended to REPLACE LibreSOC because to assign Copyright to a<br>Corporation is prohibited by our relationship with NLnet (assigning to<br>a Foundation however such as OPF is perfectly fine).<br><br>Therefore whilst we in LibreSOC as individuals are the actual<br>non-affiliated architects of the ISA Extensions, RED Semiconductor<br>will not own the Copyright but will be in exactly the same boat as any<br>other Corporation at liberty to implement SVP64 because of its Libre<br>provenance.<br><br>The key person acting as the bridge between both world will be myself<br>(Luke Leighton), and I will ensure and require that RED Semiconductor<br>provides adequate funds and resources for the long haul, in order to<br>not only see through the proposals but also ensure that the associated<br>toolchains, test suites, documentation etc. are properly written and<br>maintained, long-term. Yet I stress, again, that despite committing<br>the financial resources, RED Semiconductor will not own the Copyright<br>or any patents on LibreSOC work.<br><br>Our goal here is the ongoing long-term evolution of OpenPOWER, meeting<br>the needs of an entirely new market of end-users currently not served<br>by OpenPOWER or any OPF Members, and still maintaining the long-term<br>stability and reputation of the OpenPOWER ecosystem.<br><br>My question to you is, therefore: what is the best way forward, here?<br>What "vehicle" or arrangement would be suitable that takes into<br>account these unique circumstances? Would a conference call perhaps be<br>a good idea to discuss?<br><br>Respectfully,<br><br>Luke Leighton</font><br> </div></blockquote>
<div dir="ltr" > </div></div></div></div></div><BR>