(cc'ing libre-soc-isa mailing list, cc'ing NLnet the financial<br>sponsor for the RFCs, moving ibm cc recipients to bcc)<br><br>thank you brad for acknowledging, and the feedback.<br>the amount of money involved in preparing and submitting<br>to meet the requirements you outline below was obviously<br>not catered for in the original grant proposal of 2022 august<br>(18 months ago, now).<br><br>    <a href="https://libre-soc.org/nlnet_2022_opf_isa_wg/">https://libre-soc.org/nlnet_2022_opf_isa_wg/</a><br><br>when writing the original EU/NLnet Grant proposal, 18 months<br>ago, we could not have known the process as it was not<br>written down anywhere public, plus there was a learning<br>curve for everyone, as the ISA had never been opened up<br>before.<br><br>therefore, now that we have some idea of what to expect it<br>*might*, and i stress might, be necessary to put together<br>an additional *entirely new* EU / NLnet Grant request in order<br>to fund the requested submission.<br><br>please do bear in mind that if you require significant<br>modifications (weeks or months of work) we will need to know<br>*in advance* precisely and exactly what you want, in order<br>to estimate the costings involved.<br><br>given that the NLnet Grant Proposal process requires absolute<br>clear milestones, the last thing we need is to put in a Grant<br>Request (fixed budget, 3+ month evaluation, independent<br>3rd party review) only to find 8+ months down the line that<br>"there is another thing, another hurdle, something not previously<br>revealed".<br><br>one possibility which is very simple, avoiding any delay<br>and crucially avoiding any financial cost (a personal<br>financial loss to myself as i personally will be the one<br>doing the work to meet the outlined requirements below)<br>is to submit the entire contents of<br><a href="https://libre-soc.org/openpower/sv">https://libre-soc.org/openpower/sv</a> which is<br>built as a PDF here:<br><br>    <a href="https://ftp.libre-soc.org/simple_v_spec.pdf">https://ftp.libre-soc.org/simple_v_spec.pdf</a><br><br>you can ignore Section III, pages 229 onwards, the rest<br>of the document (Sections I and II) are the Simple-V<br>specification: management instructions, SVP64 format,<br>REMAP subsystem, PO9 format, everything that was previously<br>submitted in separate RFCs.<br><br>if that is acceptable and meets the requirements you ask for<br>then i can do that in under 5 minutes and you will have<br>everything in one document. it will also not require us<br>(Libre-SOC) to delay providing the information you seek<br>by 4+ months due to us having to put in an entirely new<br>NLnet Grant to pay for doing it.<br><br>please do let us know if submitting the full contents of<br>the entire body of work of the past 3+ years is acceptable<br>and meets the requirements below? as part of answering this<br>question, you can download the PDF above, and let me know<br>before i spend my personal time and personal money<br>(unfunded, as it is not a listed Milestone under NLnet Grant<br>2022-08-051) to update that PDF and submit it formally.<br><br>tia,<br><br>l.<br><br><br>On Wednesday, February 21, 2024, Brad Frey via RT <isa@openpower.foundation> wrote:<br>> PUBLIC FEEDBACK - NON CONFIDENTIAL<br>><br>> The OPF ISA TWG has received your requests and reviewed the associated proposals related to the Simple-V looping mechanism.  Given the stated direction to consolidate the proposals into a single RFC for the looping mechanism, the presentation by David Calderwood and Luke Leighton outlining the functional content to be represented in that RFC, and the question posed by David of whether the workgroup will approve the RFC based on that functional overview, we are giving this response to all of the looping mechanism-related requests.<br>><br>> The content of the proposals and the presentation look compatible with the existing architecture at a conceptual level and has the potential to be a valuable extension to the architecture.  However, we are missing in-depth details of several features.  Without a complete RFC, we lack the ability to understand all the details of how the aggregate proposal fits into the existing architecture, and cannot provide you with accurate feedback.  Please also remember that 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 await your RFC submission to proceed further.