d94b7b249c7d084468b508eea8974fc685e24e23
[libreriscv.git] / nlnet_2022_ongoing / discussion.mdwn
1 # Meeting 30th aug 2023 16:00 UTC
2
3 * Checked TOML fields and participants in bugs: 961, 1035, 1068, 1083, 1119, 1120, 1123,
4 1146, 1147, 1148
5
6 **TODO**: Check unallocated budget for bugs 737, 1035, 1026.
7
8 # Meeting 30th aug 2023 08:45 UTC
9
10 * Updated the TOML fields for the following bugs: 737, 852, 990, 999, 1004, 1024, 1025,
11 1026, 1031, 1032, 1033, 1034, 1035, 1039, 1086, 1116, 1120, 1123, 1128, 1130, 1131, 1132
12
13 * If Dmitriy has any more ammendments to make, please check your subtasks (we didn't
14 see any problems).
15
16 * Jacob please update the json file.
17
18 * Luke (once checked with Dmitry and Jacob) please do a final check and submit.
19
20 **TODO**: Dmitry would like to make budget adjustments to
21 [bug #1068](https://bugs.libre-soc.org/show_bug.cgi?id=1068),
22 a subtask of [bug #1003](https://bugs.libre-soc.org/show_bug.cgi?id=1003).
23 See the
24 [IRC log](https://libre-soc.org/irclog/%23libre-soc.2023-08-30.log.html#t2023-08-30T11:18:53)
25
26 * A meeting later today will be arranged to make adjustments to the budget.
27
28 Edit:
29
30 * [Bug #1116](https://bugs.libre-soc.org/show_bug.cgi?id=1116#c7) only needs one person to do the work, so budget allocation adjusted accordingly.
31
32 * Need a discussion on [bug #1047](https://bugs.libre-soc.org/show_bug.cgi?id=1047#c10), as it also intended to done by one person.
33
34 * Jacob mentioned to re-adjust
35 [bug #1123](https://bugs.libre-soc.org/show_bug.cgi?id=1123#c3) budget to about
36 half of bug #1120. Also Dmitry is not involved in this task (his work will be on a subtask
37 bug #1035).
38
39 # questions 17 aug 2023
40
41 * <https://bugs.libre-soc.org/show_bug.cgi?id=961#c5>
42
43 ## Discussion from meeting on the 23rd August 2023 21:00 UTC+1
44
45 ### Bug #1003
46
47 * There is no overlap, as #976 tackled a different issue (and was already complete
48 before #1003).
49 * "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"
50 * Bug #1003 does however build on the work from #972.
51 * Added to comment 0 of bug #1003 to clarify that it builds on top of #972.
52
53 **TODO: just put clear message describing task. No "Edit: this etc etc"**
54
55 * Edit: Please see updated [comment 0](https://bugs.libre-soc.org/show_bug.cgi?id=1003#c0).
56
57 **TODO: 1) the 1st sentence does not mention binutils. 2. it needs to say "continuation of bug #976"
58 3. a "--" is needed. 4. the paragraph "this is an umbrella task" is unnecessary. we already know it's an umbrella task, as it has child
59 subtasks. 5. the last sentence which repeats for the *third* or fourth time "this is a task" can be removed. 6. again "bug #976" not "#976".**
60
61 * Edit: Please see updated [comment 0](https://bugs.libre-soc.org/show_bug.cgi?id=1003#c0).
62
63 ### Bug #999
64
65 * Build means that Sadoon provides documentation for setting up a SFFS port
66 of Gentoo and Debian.
67 * Stage 3 tar archive file for Gentoo is now available,
68 see [instructions](https://libre-soc.org/SFFS/gentoo_bootstrap/).
69 * Debian scripts are still being worked on as of 23rd Aug.
70 * All files required are hosted either on Libre-SOC's ftp or git.
71 * Patching qemu has been discovered to be out-of-scope for this task
72 (far too much work). Sadoon will be creating (or adding sesction to
73 Gentoo/Debian pages) a wiki page describing the
74 work he went through with qemu.
75
76 **TODO: sadoon, edit the "TODOs" and "DONEs" to include the relevant bugreports.**
77
78 **TODO: sadoon, complete the descriptions in comment zeros of each subtask of #999.**
79
80 * Edit: Sadoon updated comments 0 for bugs #999, 1130, 1131, 1132.
81
82 ### Bugs 1025/1026
83
84 * Jacob is still working on figuring out the subtasks which should be focused
85 on for the scope of the On-Going grant.
86
87 **NOT NEEDED at this stage, can be submitted later. we need to MOVE and get the MoU signed**
88
89 Edit: Jacob specified that 1025/1026 subtasks are not going to be part of
90 the MoU. See
91 [IRC log](https://libre-soc.org/irclog/%23libre-soc.2023-08-24.log.html#t2023-08-24T17:27:20)
92
93 **please REMOVE that. it is NOT necessary to make such a statement.
94 it is already known**
95
96 ### Bug 1032
97
98 * Jacob mentioned there are two major parts
99
100 1. Decoder/fetch pipeline
101 2. Execution unit
102
103 Cesar likely do the former, Jacob could do the latter.
104
105 **CORRECTION: JACOB to do both.**
106
107 * Edit: Please see updated [comment 0](https://bugs.libre-soc.org/show_bug.cgi?id=1032#c0).
108
109 ### Bug 1033
110
111 * Create the framework for testing (or choose existing)
112 (jacob: important clarification -- afaict this task is adding new `StateRunner`
113 and `State` subclasses for FPGA/verilator/etc.
114 This task is *not* for creating a new framework or choosing an existing framework,
115 we already have one with implementations for pypowersim, nmigen simulation of the
116 libre-soc core, and `ExpectedState`. maybe also QEMU through GDB, icr.)
117 * Add specialisation for pypowersim, microwatt (verilator), FPGA.
118 * Cavatools out of scope.
119 * Builds on top of <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/state.py;hb=c23202498ae30addf04ab4c1e0d7262cc825cd45>?
120 * Initially pypowersim tested against qemu, then FPGA.
121 * For Simple-V/SVP64 only pypowersim implementation right now.
122 SoC HDL has small subset of SVP64.
123
124
125 ### Automated method for removing non-MOU things
126
127 * Jacob added a feature to automatically remove non-MOU strings.
128
129 **(and didn't follow instructions which was to only add support for "--...--" the standard line-break of markdown). now additional work has to be done looking for the extremely irritating and tiresome and completely undocumented "trigger-sentence" which if typed incorrectly will not do its job)**
130
131 # questions 05 oct 2022
132
133 context is from other [[nlnet_2022_opf_isa_wg/discussion]] on 2022-08-051.
134 mailing list <https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-October/005363.html>
135
136 **
137 Again there should be a breakdown of the main tasks, and the associated effort.
138 And a clarification what rates you used.
139 (I'm assuming these are the same, but I've learned not to assume...)
140 **
141
142 yes EUR 3,000 / mo as a yardstick works out ok in practice.
143
144 tasks, adapted (OpenCAPI is now a secret closed Standard, assigned to a
145 group backed by Intel!)
146
147 * 2-3 months: Dynamic Partitioned SIMD for nmigen
148 * 5-6 months: Continuation of IEEE754 FP Formal Correctness Proofs, addition
149 of FP Rounding Modes and Power ISA Flags
150 * 3-5 months: Completion of an In-Order Single-Issue core implementing SVP64
151 * 3-4 months: Addition of the IEEE754 FPU to the Core
152 * 3-4 months: Addition of other ALUs and pipelines
153 * 4-5 months: Addition of SMP (multi-core) support (lots of research here,
154 need help from IBM / Microwatt, the SMP Memory Model is conprehensive)
155 * 3-4 months: Running under Verilator and on FPGAs (big ones)
156 * 4-5 months: Continued documentation, attendance of Conferences online
157 * 4-5 months: Begin investigating Multi-Issue Out-of-Order
158 * 2-3 months plus hosting costs: Establishment and management of CI
159 * 2? months?: two Bitmain 250 FPGA porting (thanks to UOregon)
160
161 lower estimate is around 35 months, upper limit is 46, so a EUR 100,000
162 budget @ EUR 3,000/mo is within target (just). may need adjusting or some
163 tasks removing, to fit. we cannot risk committing to tasks at too low a
164 rate to be able to attract interest and committment.
165
166 Again however I do not have a problem with reducing the scope of this one
167 to only EUR 50,000 to cover some of the less ambitious tasks, with the
168 necessary infrastructure (Dynamic SIMD, IEEE754 ALUs) being first
169 priority then a second Grant following up to continue.
170
171 **
172 What would be the concrete (high level) outcome of that project -
173 where would the grant get us? Would there be a new test chip made
174 during the lifespan of the project?
175 **
176
177 Answering on the ASIC first: it is a little early to tell. Coriolis2 needs Timing
178 based Routing completed in order to tackle lower geometries (even 90nm),
179 https://libre-soc.org/nlnet_2021_lip6_vlsi/ 2021-08-049.
180 sky130
181 is far too small an allocation (12 mm^2 when we need around 100), we
182 really need sky90 which as i understand is still being negotiated and set up.
183
184 Given the amount of time ls180 took (I have to admit it was a major time-sink for me)
185 as a "learning exercise" the 2019-10-029 project was perfect.
186 However as far as "value for money" is concerned, a repeat is honestly
187 less valuable. That said: when it is ready, RED Semiconductor
188 *will* be picking up the Libre-SOC core and taking it to Silicon
189 (28 nm or below). For this Grant Proposal, powerful FPGAs will
190 get us a long way.
191
192 The concrete outcomes:
193
194 * A greatly increased strategic capacity of nmigen HDL: full Object-Orientated
195 Abstraction of its core Language Features. Opportunities then open up
196 to perform strict type checking, length checking, other types of Arithmetic
197 (Complex numbers, Galois Field) and other "filters" as
198 3rd party extensions, of which the Dynamic SIMD Partitioning Library created under
199 2019-02-012 would be the first big showcase.
200 * A modern well-documented IEEE754 Floating-Point Library, with Formal Correctess
201 Proofs using modern FOSSHW tools (smt2, symbiyosis) is a big deal in its own right,
202 and something worth aiming for.
203 The only
204 other Libre Formal Proof is Academically developed
205 for an older version of IEEE754: we will
206 target 2008 and 2019 semantics.
207 * An actual "on-the-ground" realisation of Simple-V in a useable Core, whereas at
208 present it is Simulations only and the cavatools Cycle-accurate Simulator
209 (2021-08-071) is not quite the same thing (userspace binaries only in cavatools,
210 no Virtual Memory, for a start). SMP Support in particular would be strategically
211 very valuable to have, it greatly expands the commercial viability.
212 * A lot larger "eat own dogfood" hosting solution, the NGI POINTER Grant paid for
213 an IBM POWER9 Server which lends us credibility but it needs to be put to
214 good use!
215
216 In other words, mostly "low-level strategic outcomes" on the way to success :)