{"id":"595a7ac8-5918-42b1-89f6-f28bc3a61dcd","arxiv_id":"2505.00962","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A race-free cache coherence protocol called BedRock and three coherence directory implementations in the BlackParrot multicore show that programmable and hybrid coherence engines can match fixed-function performance with small area overhead.","lead":"This dissertation builds three versions of a cache coherence controller for an open-source RISC-V multicore chip: a fixed one, a programmable one, and a hybrid. It reports that the programmable and hybrid versions run real parallel programs almost as fast as the fixed one, with only a small area increase.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The performance-competitiveness claim is not tested where the protocol's way-group serialization is exposed; higher ucode occupancy may become a throughput bottleneck under contention.","rationale":"The reader identified way-group serialization as the weakest load-bearing assumption, and my stress-test converges on the same point. The dissertation is a substantial open-source engineering effort with detailed occupancy tables, FPGA measurements, and a reproducible implementation, and I credit that evidence. However, the performance-competitiveness claim is specifically about the programmable design matching the fixed-function design, and the one place where the protocol's serialization could expose the ucode CCE's higher per-request cost is not analyzed in the reported benchmarks. The absence of variance information and contention metrics makes the reported parity hard to assess. I do not think this rises to rejection; the claim can be made conditional on showing that way-group conflicts do not disproportionately penalize the programmable engine. The reader's conditional verdict is therefore unchanged. The formal-verification gap (MESI verified, MOESIF implemented) is a secondary caveat, but it is not the main threat to the performance/area claim, so I did not make it the headline concern.","tokens_in":48082,"tokens_out":6624,"duration_ms":80090,"concrete_test":"Use the open-source BP-BedRock RTL (Verilator or FPGA) to run a synthetic microbenchmark in which all cores repeatedly issue load/store misses to addresses that differ only in tag bits while mapping to the same way group (same set-index/way-group bits), so every request contends for one pending bit. Sweep core count from 1 to 8 and compare FSM CCE versus ucode CCE steady-state miss throughput and per-request latency. Separately, add a counter that records cycles each way group's pending bit is asserted and collect it during the Splash-3 runs. If the ucode CCE's throughput degrades more than the FSM CCE's under same-way-group contention, or if pending-bit busy time is a substantial fraction of execution time, the 'no significant performance overhead' claim needs scoping or qualification. If the ucode CCE degrades by the same proportion as the FSM CCE, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim depends on the programmable CCE matching the fixed-function CCE's performance, but the evaluation does not stress the protocol's serialization point. Section 4.3.1 permits only one active coherence transaction per way group: the pending bit is set when the CCE begins processing a request and cleared only when the CohAck arrives. Every request to an address mapping to that way group is therefore stalled at the directory. The ucode CCE, and the programmable pipe in the hybrid design, necessarily have higher per-request processing occupancy than the FSM CCE (Tables 4.10, 4.18, 4.19; the fast/slow-path split in Figures 4.20 and 4.21 makes this concrete). Under way-group contention, that higher per-request occupancy translates directly into lower throughput, because the pending bit prevents overlap of transactions to the same way group. The reported Splash-3 and FPGA comparisons do not report way-group conflict counts, pending-bit stall cycles, or variance/error bars, so it is not established that the workloads actually exercise this regime. If realistic or adversarial access patterns concentrate misses on one or a few way groups, the ucode CCE may lose the claimed parity with the fixed-function design. This is not a fatal objection, but it is a load-bearing gap in the performance evidence.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The dissertation presents the BedRock directory-based MOESIF cache coherence protocol and three open-source implementations within the BlackParrot RISC-V multicore: a fixed-function FSM coherence directory engine, a microcode-programmable engine, and a hybrid of the two. The central claim, stated in Section 1.2 and revisited in Chapters 4 and 5, is that programmability can be added to the coherence system without significant performance or area overhead. Evidence includes exhaustive protocol tables and state-transition diagrams, occupancy tables for each engine, FPGA resource measurements, and Splash-3 and microbenchmark execution comparisons. The work also provides a protocol-complexity comparison against a canonical directory protocol, including CMurphi verification results for the MESI variant and a mathematical latency model for both protocols.","tokens_in":48243,"tokens_out":3353,"duration_ms":39143,"significance":"If the central claim holds, this is a solid, reproducible systems contribution: it ships an open-source, well-documented programmable coherence engine inside a real multicore, with machine-readable protocol artifacts and clear occupancy/area accounting. The three-engine comparison is a useful data point for a long-standing architectural question. The work is explicit about its parameter-free methodology, and the open-source release (Section 4) makes the measurements independently checkable. The main significance is therefore as an engineering demonstration and an open research platform, not as a new protocol concept; the protocol itself is a simplified directory protocol whose novelty lies in the elimination of exposed transient states and directory-controlled replacements.","major_comments":[{"comment":"The performance-competitiveness claim is not tested where the protocol's serialization point is exposed. Section 4.3.1 states that only one coherence transaction per way group may be active, enforced by a pending bit, and that all requests to that way group stall at the directory. The occupancy comparison in Tables 4.10, 4.18, and 4.19 shows the ucode and hybrid engines have higher per-request occupancy than the FSM engine, but the evaluation in Section 4.6 and Chapter 5 reports only aggregate Splash-3 and microbenchmark execution times, without way-group conflict counts, pending-bit stall cycles, or access-pattern variance. Under realistic or adversarial contention on a single way group, the higher occupancy directly becomes lower throughput. This is a load-bearing gap because the thesis's central claim is parity with the fixed-function design; the manuscript should either measure contention directly or qualify the claim to no-contention and low-contention regimes.","section":"§4.3.1, §4.6, Tables 4.10/4.18/4.19"},{"comment":"The verification evidence covers only the MESI variant, while the implemented engines run the MOESIF protocol. Table 3.10 reports CMurphi verification for BedRock MESI, and the text in Section 3.4 says only the MESI protocol has been verified. The BP-BedRock implementations described in Chapter 4 and 5 execute the MOESIF protocol with the O and F states (Tables 3.7, 4.18, and related state tables). Since O/F state interactions are precisely where directory-controlled transfers and writebacks are most complex, the correctness claim for the shipped design is not established by the reported verification. The authors should either verify the MOESIF variant or provide a rigorous argument for why MESI verification transfers to MOESIF, and should state this limitation explicitly where correctness is claimed.","section":"§3.4, Table 3.10; §4.4–4.5"},{"comment":"The hybrid CCE performance comparison in Chapter 5 is presented as a single aggregate result without reporting variance across runs or the configuration parameters (e.g., number of cores, cache sizes, network widths) used. Since the hybrid design's programmable pipe is the key new contribution, the evaluation should show the occupancy and execution-time relationship for the specific requests that use the programmable pipe, not only the blended result. This would make the claimed 'performance parity' of the hybrid design falsifiable and would address the way-group serialization concern raised above.","section":"§5.3, Figure 5.11"}],"minor_comments":[{"comment":"The sentence 'programmability can be be introduced to the cache coherence system' contains a duplicated 'be'; please fix.","section":"§1.2"},{"comment":"The mathematical models use abbreviations such as 'M em', 'F ill', and 'Ack' without a legend; add a short note defining each symbol and explaining why the 'Ack' term is counted as latency for BedRock but the requester can overlap it with execution.","section":"§3.5.5, Tables 3.14–3.15"},{"comment":"The caption of Figure 4.15 contains 'T able' instead of 'Table'; also, the y-axis label 'Directory Storage Overhead' should specify the normalization basis (L1 cache capacity) directly in the axis title.","section":"§4.3.3, Figure 4.15"},{"comment":"The description of the 'Set State & Transfer & Writeback (dirty)' occupancy of '2 + (2*N)' cycles is clear, but the table would benefit from an explicit note that N is the cache block width divided by the fill width, as defined in Section 4.2.2.","section":"§4.2.2, Table 4.2"}],"recommendation":"major_revision","confidential_remarks":"This is a dissertation-length manuscript rather than a compact journal article; the editor may wish to consider whether the archival format is appropriate. The two substantive gaps are fixable: add a contention-focused performance analysis that reports way-group conflicts and stall cycles, and either verify the MOESIF protocol variant or clearly scope the correctness claim to MESI. The open-source release and the detailed occupancy tables are strong points that make the revisions feasible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague — this is a publicly posted dissertation, and it reads like one: thorough, honest about trade-offs, and built on code you can actually fetch. The genuinely new piece is the BedRock protocol and its three BP-BedRock CCE implementations (fixed-function FSM, microcode, hybrid) inside the BlackParrot multicore. BedRock is a MOESIF directory variant that removes transient states by serializing per way group and having the directory control replacements, with compound commands. That combination is not standard. The microcode and hybrid CCE designs are real original work, not small tweaks.\n\nWhat the paper does well: complete protocol tables, state transition diagrams, occupancy tables, and CMurphi verification of the MESI variant. The directory storage overhead analysis is clear. All three implementations are open-source. FPGA area and performance comparisons use Splash-3 and microbenchmarks, and the dissertation is candid about the protocol's lower per-block concurrency.\n\nSoft spots: two real ones. First, the formal verification covers only MESI, while the delivered system uses MOESIF. That gap is stated in the text, so it is not hidden, but it means the \"race-free protocol verified\" claim is directly supported only for a subset. Second, the way-group pending bit serializes all transactions to a way group, and the occupancy tables show the ucode and hybrid engines have higher per-request processing occupancy. Under contention on one way group, that translates into throughput loss. The evaluation reports normalized execution time but no way-group conflict counts, no pending-bit stall cycles, and no variance information. So the parity claim is supported for the tested workloads, not established for adversarial ones. That is a load-bearing gap, not a fatal flaw.\n\nThe citation pattern looks fine; self-citations are to prior BlackParrot and BedRock documentation and describe the same platform. No fitted parameters or invented entities.\n\nWho it is for: architecture researchers who want an open-source coherent RISC-V multicore with a programmable directory, and anyone studying coherence protocol design trade-offs. I would send it to peer review. A serious referee will ask for contention analysis and MOESIF verification, and the manuscript should be revised before archival publication, but it deserves referee time.","headline":"A solid engineering dissertation that delivers an open-source programmable coherence system with real measurements, though the headline performance claim is not tested at the protocol's serialization bottleneck.","tokens_in":48799,"tokens_out":1426,"would_cite":true,"duration_ms":16387,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Programmable cache coherence can match fixed-function engines","keywords":["cache coherence","programmable coherence engine","MOESIF protocol","directory-based coherence","RISC-V multicore","BlackParrot-BedRock","microcode-programmable directory","open-source hardware"],"falsifier":"Run a many-core workload whose address stream is deliberately hashed so that a small number of way groups receive all the coherence traffic, then measure request throughput against the same workload with addresses hashed evenly. If the programmable or hybrid CCE's throughput collapses relative to the fixed-function design under way-group contention, the programmability-without-overhead claim fails for that regime.","tokens_in":47799,"feed_emoji":"🧩","tokens_out":4600,"duration_ms":45195,"temperature":0.7,"pith_summary":"This dissertation argues that cache coherence controllers can be made programmable—able to change protocol behavior after fabrication or adapt to applications—without sacrificing the performance or area efficiency of fixed-function hardware. To show this, it presents the BedRock coherence protocol, which keeps all cache blocks in stable MOESIF states by letting the coherence directory serialize every transaction per way group. It then describes three full directory implementations inside the open-source BlackParrot multicore: a fixed-function finite-state machine, a microcode-programmable engine, and a hybrid of the two. The programmable and hybrid engines match the fixed-function design's request-processing occupancy and Splash-3 benchmark results, with a small reported area overhead relative to the whole multicore. The thesis is that programmability in the coherence system is feasible today and can be studied in an open-source setting.","feed_headline":"Programmable cache coherence can match fixed-function engines","feed_subtitle":"Open-source BedRock protocol shows flexibility comes at minimal performance and area cost in multicore chips.","key_machinery":"The central objects are the way group and the pending bit. A way group collects one tag set from every cache in the system for a single cache set, and the pending bit allows only one active coherence transaction per way group. Because the CCE is the only component that changes coherence state and it always waits for the coherence acknowledgment before clearing the pending bit, the protocol never exposes transient states, which dramatically simplifies verification and the cache controller logic. The microcode-programmable CCE uses a small base ISA plus coherence-specific instructions for flag, directory, and queue operations to process BedRock's messages, while the hybrid CCE runs a fixed-function request pipe and a programmable pipe side by side. This machinery is what lets the dissertation compare protocol-processing occupancy directly across the three designs.","core_discovery":"The central claim is that adding programmability to the cache coherence directory does not inherently require significant performance or area cost. The evidence is the BP-BedRock system, in which a microcode-programmable CCE and a hybrid CCE both achieve request-processing occupancy and benchmark performance comparable to the fixed-function FSM CCE, while occupying minimal additional area relative to the full multicore. BedRock itself is the enabling protocol design: it is a directory-based invalidate protocol using MOESIF states with no transient coherence states, because the directory is the sole arbiter of state changes and one pending bit per way group serializes all transactions touching that way group. The directory's full-duplicate tag sets give it exact knowledge of every cached block, so cache-to-cache transfers and upgrades can be scheduled without races. Together the protocol and the three engines demonstrate that programmable coherence is implementable and competitive, not just theoretically attractive.","pith_inferences":["If the way-group serialization premise holds under adversarial access patterns, the same pending-bit mechanism could be reused for lightweight ordered or speculative transactions in the coherence system, an extension the dissertation does not explore.","Because the duplicate-tag directory overhead is constant while complete-directory overhead grows with core count, programmable duplicate-tag directories may become comparatively cheaper in many-core designs than traditional directory organizations.","A direct test of the thesis would be to program the ucode CCE with a non-MOESIF protocol, such as a coherence scheme tailored to accelerators, and measure whether the occupancy advantage persists; this is an extension beyond the paper's claims.","The performance-competitiveness result is demonstrated for Splash-3 and microbenchmark workloads, not for worst-case hashing, so the claim should be read as holding for typical rather than adversarial way-group contention."],"forward_implications":["A protocol without transient states verifies dramatically faster: CMurphi checks the BedRock MESI variant up to 66x faster than a traditional MESI protocol with six caches, completing in hours where the traditional model would take months.","Because the duplicate-tag directory has a constant 6.25% storage overhead relative to L1 capacity regardless of core count, the directory can be tiled across cores with a fixed per-tile size.","A microcode-programmable coherence engine can match fixed-function request occupancy on common MOESIF protocol paths, so a chip could ship one programmable directory and later change the protocol without new hardware.","The hybrid CCE offers a path to fixed-function performance on common operations and programmable flexibility for uncommon or system-specific operations in the same directory.","All three designs are open source, giving other researchers a working multicore platform on which to prototype and evaluate coherence features."],"supporting_citations":[{"why":"Defines the BedRock coherence protocol and system components that the dissertation implements and analyzes.","marker":"[133]"},{"why":"Supplies the BlackParrot 64-bit RISC-V multicore platform and cache engine interface on which BP-BedRock is built.","marker":"[107]"},{"why":"Provides the canonical directory protocol, terminology, and coherence invariants used as the comparison baseline.","marker":"[96]"},{"why":"The CMurphi model checker used to verify the BedRock MESI variant and to measure the verification speedup over the traditional protocol.","marker":"[106]"},{"why":"Defines the coarse directory organization against which BP-BedRock's duplicate-tag directory storage overhead is compared.","marker":"[130]"},{"why":"Supports the premise that hardware cache coherence will remain the dominant shared-memory model, motivating the value of making it programmable.","marker":"[86]"}],"fun_headline_variants":["Open-source BedRock coherence matches fixed-function performance","Programmable cache coherence: minimal cost in multicore chips","BedRock protocol proves programmable coherence is viable","BlackParrot-BedRock: hybrid coherence engine wins on flexibility","Cache coherence programmability without the performance hit"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that serializing all coherence transactions touching the same way group with a single pending bit does not become a performance bottleneck when many cores miss to addresses that map to the same group; if that serialization ever becomes the bottleneck, the programmable engines' competitive standing is lost.","fun_headline_variants_meta":{"raw":{"variants":["Open-source BedRock coherence matches fixed-function performance","Programmable cache coherence: minimal cost in multicore chips","BedRock protocol proves programmable coherence is viable","BlackParrot-BedRock: hybrid coherence engine wins on flexibility","Cache coherence programmability without the performance hit"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000785,"raw_usage":{"total_tokens":3470,"prompt_tokens":956,"completion_tokens":2514,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":572,"completion_tokens_details":{"reasoning_tokens":2438}},"tokens_in":572,"tokens_out":2514,"duration_ms":19446,"temperature":1.0,"reasoning_tokens":2438,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T04:30:21.740393+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a many-core workload whose address stream is deliberately hashed so that a small number of way groups receive all the coherence traffic, then measure request throughput against the same workload with addresses hashed evenly. If the programmable or hybrid CCE's throughput collapses relative to the fixed-function design under way-group contention, the programmability-without-overhead claim fails for that regime.","supporting_citations":[],"review_version":1}