nlnet-2024-12-324/progress.md

@@ -17,16 +17,26 @@ https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability#Timeline
 This is for adding the code for translating Fayalite HDL to Rocq, as well as determining how exactly we'll describe HDL in Rocq. I expect the translation code to be of comparable size to the compiler portion of the simulator (the simulator is broken into three main parts, a compiler to an IR optimized for interpretation, the interpreter itself, and the code for reading/writing simulator I/O and handling time simulation), so somewhere around 5000 LoC.
 
 - € 3000 [Issue #2](https://git.libre-chip.org/libre-chip/grant-tracking/issues/2) Figure out how exactly we should represent HDL in Rocq, writing down a manually-translated version of common HDL components (e.g. how to translate a register, a memory, an add/sub/mul/div, etc.).
+
+    Required skills: HDL, Rocq, writing proofs.
 - € 6000 [Issue #3](https://git.libre-chip.org/libre-chip/grant-tracking/issues/3) Write the code to do the translation in Fayalite.
 
+    Required skills: HDL, Rocq, IR, code generation, Fayalite's semantics, Rust.
+
 ## € 4500 Adding supporting code for generating FPGA bitstreams from Fayalite
 
 This is for adding the tooling to run all the right programs to generate FPGA bitstreams, as well as adding code to handle connecting I/O ports to the FPGA pins. I expect this to be on the order of 1000-2000 LoC for the FPGA pins code, as well as a few hundred for running all the right programs in sequence.
 
 - € 2000 [Issue #4](https://git.libre-chip.org/libre-chip/grant-tracking/issues/4) Write support for board interface descriptions and the code for running the FPGA toolchain (similar to the existing code for running SymbiYosys -- the current formal verification toolchain).
+
+    Completed.
 - € 1500 [Issue #5](https://git.libre-chip.org/libre-chip/grant-tracking/issues/5) Add support for the Orange Crab since both Cesar and Jacob have one.
+
+    Required skills: HDL, Rust, FOSS FPGA toolchains.
 - € 1000 [Issue #6](https://git.libre-chip.org/libre-chip/grant-tracking/issues/6) Add support for the Arty A7 100T since that's what we're using for CI.
 
+    Completed.
+
 ## € 14250 Register Renaming, Execution, and Instruction Retire
 
 This covers getting register renaming working, as well as scheduling, executing simple ALU and Branch instructions, and properly handling instruction retire. (Some of that work is already done.)
@@ -34,9 +44,17 @@ This covers getting register renaming working, as well as scheduling, executing
 A lot of this is the work to come up with a detailed low-level plan for the CPU, so I don't have a good idea of how complex or not this is, though I expect it to be probably 40% of the CPU's complexity.
 
 - € 1500 [Issue #7](https://git.libre-chip.org/libre-chip/grant-tracking/issues/7) Add to the simulator in Fayalite the ability to transfer non-HDL data (e.g. HashMap) through the digital signalling mechanism, this allows using those data types when writing procedural models.
+
+    Completed.
 - € 9000 [Issue #8](https://git.libre-chip.org/libre-chip/grant-tracking/issues/8) Create a model of the whole rename/execute/retire control system, using procedural implementations of the most complex HDL modules where appropriate.
+
+    Required skills: OoO speculative CPU design, HDL, Rust.
 - € 3750 [Issue #9](https://git.libre-chip.org/libre-chip/grant-tracking/issues/9) Translate the procedural model to use actual synthesizeable HDL. includes a proof of correctness of the out-of-order CPU in relation to a sequential CPU (probably most easily done by adding the proof to the retire stage).
 
+    (note: we may have to leave the proof part out of this task due to lack of time.)
+
+    Required skills: CPU design, HDL, Rust, Proofs.
+
 ## € 9000 Instruction Fetch/Decode
 
 This covers instruction fetch, decoding, and caching. For the decoder, unless OpenPower has gotten around to releasing the Latex source code, I'm expecting to use a parser I wrote that parses the instruction descriptions out of the PowerISA v3.1C PDF and writes out XML.
@@ -44,11 +62,21 @@ This covers instruction fetch, decoding, and caching. For the decoder, unless Op
 https://git.libre-chip.org/libre-chip/parse_powerisa_pdf
 
 - € 1000 [Issue #10](https://git.libre-chip.org/libre-chip/grant-tracking/issues/10) Create the next-instruction logic -- includes some sort of branch prediction or branch target buffer so we can actually keep the rest of the CPU pipeline full. This should support fetching more than one instruction per clock.
+
+    Completed.
 - € 1000 [Issue #11](https://git.libre-chip.org/libre-chip/grant-tracking/issues/11) Create the fetch and i-cache logic.
+
+    Completed.
 - € 2000 [Issue #12](https://git.libre-chip.org/libre-chip/grant-tracking/issues/12) Create the PowerISA decoder -- it translates to the internal microcode. For now, only needs to support a reasonable subset of 64-bit LE integer instructions in problem mode (aka. user mode), FP and VMX/VSX can be disabled.
+
+    Completed.
 - € 2000 [Issue #13](https://git.libre-chip.org/libre-chip/grant-tracking/issues/13) Create a model of the instruction fetch/decode control system, using procedural implementations of the most complex HDL modules where appropriate.
+
+    Completed.
 - € 3000 [Issue #14](https://git.libre-chip.org/libre-chip/grant-tracking/issues/14) Translate the procedural model to use actual synthesizeable HDL.
 
+    Required skills: CPU design, HDL, Rust
+
 ## € 15000 Load/Store instructions
 
 This covers implementing the load/store hierarchy, including an L1 cache. For now, the CPU will only target on-FPGA memory blocks, as well as simple I/O devices. (Support for DRAM can be added at a later point outside of this grant.)
@@ -57,12 +85,24 @@ It should include d-cache, some kind of memory, and at least one IO device.
 It should include at least lr/sc, some atomic fetch-op, cached load/store, and IO load/store (IO needs to wait until non-speculative to start executing).
 
 - € 1500 [Issue #15](https://git.libre-chip.org/libre-chip/grant-tracking/issues/15) memory system: main memory and IO devices -- I'm expecting just a big sram to be good enough for simulation of memory, on the fpga we could probably get away with a relatively small sram and put off a dram interface for later. for the IO device, I'm thinking we'd have a simple fixed-frequency uart.
+
+    Required skills: HDL, Rust
 - € 1500 [Issue #16](https://git.libre-chip.org/libre-chip/grant-tracking/issues/16) d-cache
+
+    Required skills: HDL, Rust
 - € 3750 [Issue #17](https://git.libre-chip.org/libre-chip/grant-tracking/issues/17) memory load execution unit (we'll want to be able to do more than one load at once)
+
+    Required skills: OoO speculative CPU design, HDL, Rust
 - € 3750 [Issue #18](https://git.libre-chip.org/libre-chip/grant-tracking/issues/18) memory store execution unit
+
+    Required skills: OoO speculative CPU design, HDL, Rust
 - € 3000 [Issue #19](https://git.libre-chip.org/libre-chip/grant-tracking/issues/19) adding atomics: lr/sc, atomic fetch-add (or other fetch-op)
+
+    Required skills: OoO speculative CPU design, HDL, Rust
 - € 1500 [Issue #20](https://git.libre-chip.org/libre-chip/grant-tracking/issues/20) adding order-violation detection logic, so we can make memory look like it has total-store-order (for x86), or even sequential consistency (meaning we can ignore all non-IO fences)
 
+    Required skills: OoO speculative CPU design, HDL, Rust
+
 ## € 0 Work towards the Formal Proof of No Spectre bugs
 
 (Deprecated, left as future work)

scripts/check-consistency.sh

@@ -88,7 +88,7 @@ function check_issue()
     subtask_body="$4"
     example_title="NLnet $nlnet_id $subtask_title"
     body_prefix="Issue for tracking progress of a subtask of [NLnet grant $nlnet_id]($(grant_url "$nlnet_id")):
-$subtask_title
+- $subtask_title
 $subtask_body
 "
     body_suffix="" # TODO
@@ -253,9 +253,9 @@ function check_progress()
             for ((i = subtask_line_index + 1; i < line_index; i++)); do
                 if [[ "${lines[i]}" =~ ^[[:space:]]*$ ]]; then
                     subtask_body_trailing_lines+="${lines[i]}"$'\n'
-                elif [[ -z "$subtask_body" ]]; then
-                    subtask_body+="${lines[i]}"$'\n'
-                    subtask_body_trailing_lines="" # ignore any leading blank lines
+                # elif [[ -z "$subtask_body" ]]; then
+                #     subtask_body+="${lines[i]}"$'\n'
+                #     subtask_body_trailing_lines="" # ignore any leading blank lines
                 else
                     # add subtask_body_trailing_lines since they're lines in between non-blank lines
                     subtask_body+="$subtask_body_trailing_lines${lines[i]}"$'\n'
@@ -263,7 +263,10 @@ function check_progress()
                 fi
             done
             if [[ "$nlnet_id" != "YYYY-MM-ID" ]]; then
-                check_issue "$issue_number2" "$nlnet_id" "$subtask_title" "$subtask_body" || diag "note:" -line_index="$subtask_line_index" "issue is linked from here"
+                check_issue "$issue_number2" "$nlnet_id" "$subtask_title" "$subtask_body" || {
+                    diag "note:" -line_index="$subtask_line_index" "issue is linked from here"
+                    any_errors=1
+                }
             fi
         done
         (( subtasks_total == task_amount )) || \
@@ -294,5 +297,8 @@ for nlnet_dir in nlnet-*/; do
         esac
     done
 done
+if (($any_errors)); then
+    echo "errors running check-consistency.sh" >&2
+fi
 exit $any_errors