Schedule A, based on https://libre-soc.org/nlnet_2022_ongoing/ ----------------------------------------------------------------------- # SFFS Operating System Porting XXXX MUST NOT DOUBLEFUND! (resolved: no longer a duplicate of bug #983) XXXX to continue the work done by VanTosh under NGI POINTER with PowerEL porting to SFFS, gentoo and debian need a PowerPC64 "SFFS" port as well, and PowerEL needs additional work. this will be suitable not just for Libre-SOC but also Microwatt and also the Freescale/NXP E5500 64-bit CPU (with emulation of v3.0 already present in linux kernel) https://bugs.libre-soc.org/show_bug.cgi?id=999 EUR: 10,000 ----------------------------------------------------------------------- # improvements of Libre-SOC core support on FPGA boards mostly this is the ls2 peripheral fabric which needs peripherals and platforms improving, generally this milestone is to cover improving Libre-SOC core support on FPGA boards. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1037 EUR: 6,000 -------------------------------------------------------------------- # redesign dct and fft integer twin butterfly instructions the integer dct and fft instructions need redesigning and full development and integration with the FFT and DCT REMAP subsystem. if possible they should be integrated into the planned 2D DCT/FFT subsystem of bug #963 as well. https://bugs.libre-soc.org/show_bug.cgi?id=1206 EUR: 6,000 ----------------------------------------------------------------------- # Formal Proof for LDSTCompUnit is needed the ALU CompUnit Formal Proof was very successful and tracked down a critical bug. a similar proof is needed for LDSTCompUnit. https://bugs.libre-soc.org/show_bug.cgi?id=1036 EUR: 3,000 ----------------------------------------------------------------------- # Implement PO9 changeover and associated tasks As part of bug #952 - the NLnet 2022 OPF ISA WG Grant 2022-08-051 - it was established that PO9 is a candidate for use by SVP64 instead of shoe-horning into PO1. That now needs to be implemented along-side its knock-on implications in ISACaller, the insndb, and binutils. Additionally there are some instructions easy to implement (LD/ST-post-update) that are beneficial to performance, that again came out of the OPF RFC Feedback process. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1150 EUR: 10,000 ----------------------------------------------------------------------- # Addition of ALUs and pipelines for Draft ISA instructions Unit tests and ISACaller Simulator implementation exists for the various Draft ISA instructions to be proposed under bug #952 (NLnet 2022-08-051) but HDL for inclusion in Libre-SOC Core does not yet exist. There are approximately 50 new IEEE754 Transcendental instructions to be added, several bitmanip instructions, and the BigInt 3-in 2-out (64-bit carry) instructions. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1026 EUR: 8,000 ----------------------------------------------------------------------- # XLEN unit tests. The Simulator needs a huge number of Unit tests for elwidth overrides as every existing 64-bit unit test now needs to be joined by 8-bit, 16-bit and 32-bit tests. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1032 EUR: 4,000 ----------------------------------------------------------------------- # Implementation and enhancement of "Test API" add microwatt, cavatools, FPGA and "standard Makefile" targets for running as raw binaries in a VM/native/FPGA. related to NLnet Grant OPF ISA 2022-08-051 cavatools. the purpose of the "Test" API is to make it possible to compare unit test results automatically against different implementations. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1033 EUR: 2,500 ----------------------------------------------------------------------- # Continuation of instruction database and binutils the instruction database (machine-generation) needs continuation particularly for CR and Branch operations. note this is a duplicate of bug #976 which has been marked as resolved/fixed, avoid "missing specifiers" (what bug #976 covered) under this task unless further work is needed https://bugs.libre-soc.org/show_bug.cgi?id=1003 EUR: 10,500 ----------------------------------------------------------------------- # Implement Scalar Power ISA v3.1 instructions in ISACaller Power ISA has moved on to v3.1, and if Draft SVP64 is to be accepted in a future version of Power it must be on the future version (not v3.0). URL: https://bugs.libre-soc.org/show_bug.cgi?id=1035 Budget: 7000 ----------------------------------------------------------------------- # Implement "necessary" additions to SVP64 and Scalar Power ISA In the OPF ISA WG Grant 2022-08-051 there is considerable work to be done in submitting almost 100 instructions via the OPF's External RFC Process. Adding to this workload is greatly undesirable however under certain circumstances may prove necessary, was already planned, or may be demonstrably greatly beneficial. For example a 2D DCT Mode for REMAP was planned, as was the design and addition of Integer DCT and FFT Butterfly instructions. Additionally some 64-bit versions of SVP64's setvl and REMAP instructions have been planned for some time, including extending Matrix REMAP to do both inner and outer product, and the CRweird and ternary/binary instructions have to be implemented. Note that the key difference between this Milestone and the OPF ISA WG Grant 2022-08-051 is that everything under 2022-08-051 has already been designed and implemented under the SVP64 ISACaller Simulator. This Milestone brings the necessary additions up to a point where 2022-08-051 can take over. Additionally the python-based pypowersim needs to be made easier to compile for x86: presently it runs best only on ppc64. This will allow development of SVP64 and Power ISA additions to be easier. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1027 Budget: 30,000 ----------------------------------------------------------------------- # add hardware-cycle-accurate statistical modelling to ISACaller for an in-order core Hardware-cycle-accurate statistics are needed but it will take some effort to add to cavatools. therefore a model needs to be added to ISACaller which allows some basic performance estimates. This task is not part of the cavatools grant 2021-08-071. It can be achieved much more immediately. URL: https://bugs.libre-soc.org/show_bug.cgi?id=1039 Budget: 3000
possible idea, add continuation tasks for bug #987 cavatools?
suggestions from cesar: My suggestions, for consideration: 1) Participation in conferences. The original Wishbone grant had such provision, it seems. Could cover traveling expenses, as well as building a physical FPGA demo for presenting on a stand at FOSDEM (running microPython, Zepyhr, Linux or even an X desktop with VGA/HDMI output on a framebuffer). 2) Formal proof for LDSTCompUnit. Unless, it already fits under the "In-order Core" task. 3) Put the GRAM task and the Nexys Video task under a more general "Improve ls2 support for selected FPGA boards" task. Cesar
(In reply to Luke Kenneth Casson Leighton from comment #2) > suggestions from cesar: > 2) Formal proof for LDSTCompUnit. > > Unless, it already fits under the "In-order Core" task. done https://bugs.libre-soc.org/show_bug.cgi?id=1036 > 3) Put the GRAM task and the Nexys Video task under a more general > "Improve ls2 support for selected FPGA boards" task. hm good idea
Created attachment 197 [details] report.NLnet.2022-08-107.ongoing.json I updated comment #0 as described on IRC, so that needs to be checked before submitting the MOU: https://libre-soc.org/irclog/%23libre-soc.2023-08-02.log.html#t2023-08-02T22:04:04
Conversation from Michiel to Luke (permission given to copy over). Initial email from Luke to Mikiel: >> On Fri, Aug 4, 2023 at 7:54 PM Luke Kenneth Casson Leighton >> <lkcl@lkcl.net> wrote: >>> >>> dear michiel bob and team, >>> >>> please find in the links below the Schedule A and associated >>> JSON file. the JSON file also contains the team members for >>> the MoU. >>> >>> * JSON file: https://bugs.libre-soc.org/attachment.cgi?id=197 >>> * Schedule A: https://bugs.libre-soc.org/show_bug.cgi?id=961#c0 >>> >>> with many many thanks, >>> >>> l.
Michiel responded with several questions. Luke's response: michiel is it ok to transfer this conversation to te bugreport? https://bugs.libre-soc.org/attachment.cgi?id=197 the reason i ask is because private email gets lost and forgotten. if you say "yes" please one of you (LS team, cc'd) take responsibility for doing so. On Thursday, August 17, 2023, <michiel@nlnet.nl> wrote: > Hi Luke, > > please find the imported draft attached. Questions: thx michiel, i will take a look. i trust you did not have to make any modifications to the task words? (that defeats the object of autogenerating them!) > - Task https://bugs.libre-soc.org/show_bug.cgi?id=1003 > > "note this is a duplicate of bug #976 which has been marked as resolved/fixed, avoid "missing specifiers" (what bug #976 covered) under this task unless further work is needed" ok, see comment 2 https://bugs.libre-soc.org/show_bug.cgi?id=1003#c2 and then observe in the child tasks that the entire budget *has* already been allocated to subtasks.... *none of which* overlap (or are a duplicate of) #972. > The wording indicates dat this is work already done/double, it was, 6 months ago. i spent several days going over ALL tasks and eventually caught it. it was then changed but i did not want to lose sight of the mistake made (i.e. looking like i am hiding something, an Audit "no-no"). on reflection, strictly speaking, the "history of comment edits" records that, for Audit purposes, but it is good to have the up-front conversation with you, so that you fully understand and are not caught off-guard if the Auditor queries it. > while I gather from the context that this essentially builds on that work. In that case, let's make that explicit. i leave it with the others to carry out that adjustment, i have made a few minor adjustments. > - Task 999 is a bit vague (what does 'build' mean), where will these packages be delivered? I assume upstream Gentoo, Debian? Please make specific. i did tell the team during the meeting precisely and exactly that, that there has to be a *deliverable* that can be vetted and audited. they didn't take it on-board. upstream debian and gentoo will require at least 2-3 years, we cannot possibly wait that long. i therefore requested that the "deliverable" be a set of "reproducing instructions", and that all patches be included in a git repository. which i have already set up for gentoo, Sadoon, and you still haven't pushed anything to it. https://git.libre-soc.org/?p=portage.git;a=summary and i recall you said "i made some random git repository" on tuesday and i know for a fact that you did not ask me for permission to use unauthorized external repositories: the answer is and remains an automatic NO. please push the work that you have done to date IMMEDIATELY to public repositories and continue ONLY in public *LIBRESOC* repositories. if you need more repositories raise it on the bugreport and i will create them (and please remember that binary files, log files, or anything autogeneratable is PROHIBITED from being committed). we DO NOT work out of gitlab or github, period. team: welcome to the fact that this is a HUNDRED THOUSAND Euro task, it is GUARANTEED 100% as a Condition of this Grant that a EU Auditor, dedicated to this Grant, WILL go through it with a fine-tooth comb. Michiel and his team need ABSOLUTE CAST IRON CONFIDENCE that they can answer any questions. "the work got done somewhere, just trust us and give us the money" is in NO WAY acceptable. > - Task 1024, not a wrapup. it's just genuinely that complex. it *might* get subdivided into the usual "implementation tests docs" which would give 3 subtasks but there will be no "wrapup". > 1025, i am leaving that to jacob to subdivide, as part of training him to get his feet on the ground. there will be no "wrapup", the entire lot goes to connecting the IEEE754FPU work into TestIssuer. it's FIFTY instructions so no way we will get all of it done but it will be a good start. the rest of the team will be helping him to make the assessment. > 1032, again: not a wrapup, it really is that big. i will attempt to get the others to (again) think in terms of Project Management and create the subtasks. there will be no wrapup, there will only be subtasks. > 1033: can "wrapup" be a bit more specific as well? again: not a "wrapup". the task is relatively straightforward and needs no subdivision into subtasks.
Michiel's response, 17/08/2023, 13:07 (BST): Hi Luke, > michiel is it ok to transfer this conversation to te > bugreport? https://bugs.libre-soc.org/attachment.cgi?id=197 > the reason i ask is because private email gets lost > and forgotten. fine by me, but of course not the attachment with addresses. > thx michiel, i will take a look. i trust you did not > have to make any modifications to the task words? (that > defeats the object of autogenerating them!) I did have to clean up a bit in places where it e.g. said: "TODO" or "The following part should not be part of the MoU" (but the generated text did). And hi @Sadoon: I think you are new to this group? Welcome on board! Best, Michiel
Created attachment 200 [details] report.NLnet.2022-08-107.ongoing.json after changing code to remove non-MOU things
(In reply to Andrey Miroshnikov from comment #7) > Michiel's response, 17/08/2023, 13:07 (BST): Luke's response to Michiel, 17/08/2023, 15:04 (BST): On Thursday, August 17, 2023, <michiel@nlnet.nl> wrote: > Hi Luke, > fine by me, but of course not the attachment with addresses. no of course. >> thx michiel, i will take a look. i trust you did not >> have to make any modifications to the task words? (that >> defeats the object of autogenerating them!) > > I did have to clean up a bit in places where it e.g. said: "TODO" or "The following part should not be part of the MoU" (but the generated text did). ahh ok. hmm we should sort that out somehow, perhaps by spotting "---" on a new line l.
(In reply to Andrey Miroshnikov from comment #7) > Michiel's response, 17/08/2023, 13:07 (BST): Sadoon's response to Michiel, 17/08/2023, 18:19 (BST): Relatively new, thanks! I believe we met in FOSDEM 2023? Aug 17, 2023 3:07:59 PM michiel@nlnet.nl: > > > And hi @Sadoon: I think you are new to this group? Welcome on board!
(In reply to Andrey Miroshnikov from comment #10) > (In reply to Andrey Miroshnikov from comment #7) > > Michiel's response, 17/08/2023, 13:07 (BST): > > Sadoon's response to Michiel, 17/08/2023, 18:19 (BST): Michiel's response to Sadoon, 17/08/2023, 21:37 (BST): Hi Sadoon, > Relatively new, thanks! I believe we met in FOSDEM 2023? sorry that I didn't make the connection. Hope you're enjoying the project... there is a lot of work to be done! Best, Michiel
Created attachment 201 [details] report.NLnet.2022-08-107.ongoing.json manually verified that JSON is correct in terms of not including non-MOU things using fix-mou-splitting branch of utils.git
Created attachment 202 [details] report.NLnet.2022-08-107.ongoing.json
replies by ghostmansd for discussion of tasks https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-August/005614.html
Created attachment 203 [details] report.NLnet.2022-08-107.ongoing.json with cesar added
Created attachment 204 [details] report.NLnet.2022-08-107.ongoing.json after meeting Everyone in the meeting agrees that the MOU is ready for submission to NLNet, so I'll let you do that luke (since that's something only you can do)
https://libre-soc.org/task_db/report/ bug #737 shows EUR 2500 unallocated to subtasks bug #1035 EUR 4000 and bug #1026 shows EUR 5000 if the intention is to reallocate those to other toplevel tasks then the "drilldown" estimation under each needs to be completed. ghostmansd needs for example to say an amount he is happy with to cover v3.1 SFFS 32bit ops in binutils (and insndb if needed), and jacob if you want to move budget from 1035 to 1026 you need to do a full lines/days-estimate on every v3.1 SFFS 32bit op, before moving budget in case it ends up leaving too little. but also bear in mind as i said on IRC, if there *is* spare it should be balanced against LD/ST-322 and Vectorised-Immediates also likely needing extra (particularly VI).
(In reply to Luke Kenneth Casson Leighton from comment #17) > https://libre-soc.org/task_db/report/ > > bug #737 shows EUR 2500 unallocated to subtasks > bug #1035 EUR 4000 and afaict the leftover budget is unused for both of those, so is available for re-assigning. > bug #1026 shows EUR 5000 the whole budget is used in bug #1026, like #1025 there are enough subtasks that we are constrained by the budget and will have to pick and choose what to do. the full list of tasks isn't established for #1026 yet since it'll likely be partially leftovers from #1025 and I haven't done the subtask budget estimation yet. > ghostmansd needs for example to say an amount he > is happy with to cover v3.1 SFFS 32bit ops in binutils (and > insndb if needed), and jacob if you want to move budget from > 1035 to 1026 you need to do a full lines/days-estimate on > every v3.1 SFFS 32bit op, before moving budget in case it ends > up leaving too little. as mentioned on IRC, I already finished all non-binutils work for bug #1035 and I'm happy with the budget. the binutils budget under #1035 is currently set to EUR 1000 and ghostmansd seems happy with that, since the work should be pretty easy to do. ghostmansd left the budget assignment for the rest of #1035 up to the rest of us: https://libre-soc.org/irclog/%23libre-soc.2023-08-30.log.html#t2023-08-30T20:38:49 > > but also bear in mind as i said on IRC, if there *is* spare it > should be balanced against LD/ST-322 and Vectorised-Immediates > also likely needing extra (particularly VI). ok, I missed that on bug #1047 you already did most the work and the extra budget would be needed for getting whoever works on it up-to-speed. As mentioned on IRC, I don't think we should assign more budget to Vectorised-Immediates since I think it should be lower priority than #1025 and most other tasks, if we run out of budget for Vectorised-Immediates then I think we should do what fits in the current budget and put off the rest for another grant. therefore, I think we should take the leftover budget from bug #737 and bug #1035 and assign it like so: we have EUR 6500 to distribute: * bug #1047 gets additional EUR 1000 2500 for lkcl and 1500 for whoever finishes it off the additional money is for the learning curve and because there's not much left after paying lkcl. * bug #1025 gets additional EUR 4500 it could use a lot more than that...iirc the full task list sums to well in excess of 20k, somewhere around 30k last I checked * bug #1146 gets EUR 1000 assigned through bug #1037 increasing it to EUR 7000 I think it's highly beneficial to have a decent amount of working ram without needing to wait on ddr3 getting figured out. additionally, making it work with a RPi or other SBC with a SPI interface is useful because they're much more widely available than HyperRAM and have much more ram, enough that we could run compilers and stuff. I estimate that EUR 1000 is just about enough to get the wishbone to SPI slave translator and write the simple ram emulator program which will use SPI through Linux's drivers.
(In reply to Jacob Lifshay from comment #18) > (In reply to Luke Kenneth Casson Leighton from comment #17) > > https://libre-soc.org/task_db/report/ > > > > bug #737 shows EUR 2500 unallocated to subtasks > > bug #1035 EUR 4000 and > > afaict the leftover budget is unused for both of those, ha ha very funny. you have no idea how much work is involved in the in-order core. i have created a new bug and assigned the entirety of the remaining budget to it. where are brd etc. implemented? https://bugs.libre-soc.org/show_bug.cgi?id=1120#c5 > so is available for re-assigning. not a chance. andrey there is no budget available for ls2 documentation, i have removed that task and reassigned it to the much higher priority task of completing the in-order core. > > bug #1026 shows EUR 5000 > > the whole budget is used in bug #1026, like #1025 there are enough subtasks > that we are constrained by the budget and will have to pick and choose what > to do. not a problem. > the full list of tasks isn't established for #1026 yet since it'll > likely be partially leftovers from #1025 and I haven't done the subtask > budget estimation yet. > > > ghostmansd needs for example to say an amount he > > is happy with to cover v3.1 SFFS 32bit ops in binutils (and > > insndb if needed), and jacob if you want to move budget from > > 1035 to 1026 you need to do a full lines/days-estimate on > > every v3.1 SFFS 32bit op, before moving budget in case it ends > > up leaving too little. > > as mentioned on IRC, I already finished all non-binutils work for bug #1035 > and I'm happy with the budget. the binutils budget under #1035 is currently > set to EUR 1000 and ghostmansd seems happy with that, since the work should > be pretty easy to do. might be a good idea to double-check given that there is no evidence that brd (etc.) have been completed, and to give ghostmansd a full and explicit list https://bugs.libre-soc.org/show_bug.cgi?id=1147#c0 > > but also bear in mind as i said on IRC, if there *is* spare it > > should be balanced against LD/ST-322 and Vectorised-Immediates > > also likely needing extra (particularly VI). > > ok, I missed that on bug #1047 you already did most the work and the extra > budget would be needed for getting whoever works on it up-to-speed. > > As mentioned on IRC, I don't think we should assign more budget to > Vectorised-Immediates since I think it should be lower priority than #1025 it's part of the spec and it gets a "one-shot" opportunity to present EVERYTHING. therefore it cannot be "de-prioritised". > therefore, I think we should take the leftover budget from bug #737 there isn't any > and bug #1035 you need to re-check the list. there is no evidence that brd/brw/brh has been done. and the documentation of the spec - as i said twice now - is a far higher priority than anything else. it is the absolute top priority and the absolute critical dependency on which EVERYTHING depends. do not UNDER ANY CIRCUMSTANCES consider the writing of the specification to be anything other than an absolute top priority task. if the specification is wrong or out-of-date it literally jeapordises the entire project. > * bug #1146 gets EUR 1000 **NO**. i have said this several times now. there is too much going on already. adding additional tasks places completion in jeapordy as it reduces available budget for those tasks. there is far too much already.
i've updated https://bugs.libre-soc.org/show_bug.cgi?id=1025#c0 as you missed TestIssuer work entirely. TestIssuer integration is the top priority over-and-above what goes into the pipelines.
(In reply to Luke Kenneth Casson Leighton from comment #19) > (In reply to Jacob Lifshay from comment #18) > might be a good idea to double-check given that there is no evidence > that brd (etc.) have been completed, there's a whole bug dedicated to brh/w/d with commit logs: https://bugs.libre-soc.org/show_bug.cgi?id=1119 it is completed. > and to give ghostmansd a full > and explicit list https://bugs.libre-soc.org/show_bug.cgi?id=1147#c0 he has the full list now. > > As mentioned on IRC, I don't think we should assign more budget to > > Vectorised-Immediates since I think it should be lower priority than #1025 > > it's part of the spec and it gets a "one-shot" opportunity to present > EVERYTHING. therefore it cannot be "de-prioritised". except that there are much higher priority things than Vector-Immediates, because I know Vector-Immediates are a bad idea the way they are now, they require massive invasive changes to the entire fetch decode pipeline, if you thought 64-bit instructions PO1 make the fetch/decode pipeline a pain, you haven't seen anything yet. I would never implement them. And no, they cannot be treated as a branch instruction, because that *skips* reading all instruction data between the branch and the target, where does your immediate data come from now?! Therefore, if you want them, I think they should be left for much later, if they don't end up in the next version of the specification, no problem, just wait for the version after that. That's exactly what will happen with Texture loads and triangle rasterization instructions anyway, which are actually widely used and known to be implementable, since every 3D GPU ever implements them (if it doesn't, I wouldn't call it a 3D GPU). > > > > therefore, I think we should take the leftover budget from bug #737 > > there isn't any > > > and bug #1035 > > * bug #1146 gets EUR 1000 > > **NO**. i have said this several times now. > there is too much going on already. but this allows us to test large sw on a fpga (what we've been trying to do for many months and failing due to gram not working), i think this is higher priority than many of the other tasks in this grant. > > adding additional tasks places completion in jeapordy as it reduces > available budget for those tasks. assigning the budget instead to #1025 would just be creating new different tasks such as implementing fp comparison. In summary, I'm now proposing moving EUR 4000 from #1035 to #1025.
(In reply to Luke Kenneth Casson Leighton from comment #20) > i've updated https://bugs.libre-soc.org/show_bug.cgi?id=1025#c0 as you > missed TestIssuer work entirely. TestIssuer integration is the top > priority over-and-above what goes into the pipelines. I did not miss that, I just haven't updated #1025 since you last reviewed it. I will be responding to all those comments later when I work on it again. (though it would have been nice if you pointed all that out before I did a bunch of work on assigning budgets that now needs to all be redone since you merely want to *totally redo* the whole task list to be based on pipelines, you did presumably glance at it before...that's part of why I've been putting it off)
(In reply to Jacob Lifshay from comment #22) > again. (though it would have been nice if you pointed all that out before I > did a bunch of work on assigning budgets that now needs to all be redone please do not in any way be sarcastic regarding the process of clarifying tasks, ever, under any circumstances. it is deeply inappropriate. your words are being cc'd to NLnet *in real time* (2022-08E@nlnet.nl) and will also be read by the EU Auditor. i have been doing these micro-adjustments that you are sarcastically complaining about for five years now, and it requires extraordinary patience and attention, and *multiple* adjustments that often take three to four *weeks* to eventually settle. however that detail and deep-level of due diligence is precisely why NLnet is comfortable backing us repeatedly, and your attitude threatens that. do not do it, ever again.
(In reply to Luke Kenneth Casson Leighton from comment #23) > (In reply to Jacob Lifshay from comment #22) > > again. (though it would have been nice if you pointed all that out before I > > did a bunch of work on assigning budgets that now needs to all be redone > > please do not in any way be sarcastic regarding the process of > clarifying tasks, ever, under any circumstances. it is deeply > inappropriate. I'm sorry, the way I said that was inappropriate and I regret that.
discussion with luke on irc: https://libre-soc.org/irclog/%23libre-soc.2023-09-01.log.html#t2023-09-01T21:54:33 ok, for figuring out the exact list of subtasks for bug #1025, I'm not sure what you meant by "documentation budget": 1. if you meant under a different grant, then that doesn't change what we need to do before the MOU is signed and we can figure it out later. 2. If you meant it should come out of this grant, then, reading through the top-level subtasks' descriptions and not spotting anything mentioning documentation, I think the best place to get that budget from is actually bug #1025, because an intrinsic part of completing bug #1025 is figuring out the exact list of subtasks of bug #1025. Likewise, adding FP/FPSCR registers to TestIssuer and stuff is also an intrinsic part of bug #1025, so I think the budget should come out of #1025. All of the other things I recall you mentioning are also subtasks of bug #1025. Since all of the above tasks are then subtasks of bug #1025 or in a completely different grant and we do not need to flesh out bug #1025's subtasks in order to sign the MOU because bug #1025 has enough tasks that we will need to remove a lot of them to fit in the allocated budget, I think we should leave all of the above tasks till after we sign the MOU. Therefore, I think we should move the excess EUR 4000 from bug #1035 (which is almost completely done already, so the currently assigned budgets are sufficient) to bug #1025 where we need it.
Created attachment 205 [details] Updated MoU after meeting with Michiel Attaching the updated MoU after morning meeting with Michiel.
Created attachment 207 [details] Updated json for nlnet
Created attachment 208 [details] json file for schedule A new version that again removes DynamicSIMD and prioritises DDFFirst and PO9 changeover