Skip to content

UNSOLVED-001: MOESI TC-MOESI-1/TC-MOESI-2 fail — root cause not found

Field Value
Status Roadblocked — awaiting human investigation
Component RTL (rtl/duck_coherency_ctrl.sv)
Date opened 2026-07-19
Related docs/issues/BUG-006.md
Fix branch none yet — see "How to resolve" below

Why this was picked

Found by accident on 2026-07-19 while verifying an unrelated fix (run_riscv_program / BUG-004 / BUG-005): a routine MOESI sanity run turned up tb_moesi_integration failing with the exact symptom BUG-003 already claimed to have fixed. It was logged as BUG-006 rather than fixed in that session (out of scope for the run), then promoted to the top of docs/next_run.md's queue so the next 5-hourly dev cycle would pick it up first — which it did on 2026-07-20, per the queue-order rule in automation/dev_cycle.md step 1.

What was encountered

MODULE=tb_moesi_integration ASM_TEST=moesi_weight_test.asm:

test_moesi_cpu_write_npu_read          FAIL — expected 42 at 0x1000, got 0
test_moesi_npu_invalidate_on_cpu_write FAIL — Phase B: expected 77, got 0
test_moesi_clean_npu_dma               PASS

Same symptom as BUG-003 (dirty L2 line not flushed before NPU DMA reads it) — but that entry's fix (ST_NPU_GAP state) is confirmed present in the current rtl/duck_coherency_ctrl.sv by inspection. So either a second, different timing bug is producing the same symptom, or there's an environment difference (this run used locally-extracted iverilog 12.0 + cocotb 2.0.1 on Python 3.14 — see automation/toolchain_env.sh — versus whatever combination validated the original BUG-003 fix).

Ruled out as a regression from the chiplet-split (v5) session's own changes: reproduced identically on rtl/system_top.sv/tb/cpu_peak_tests.asm stashed back to their pre-session state, so this predates and is unrelated to the 2026-07-20 chiplet/UCIe work. Not investigated at the waveform level — that's a longer task than fits in one 5-hour automated cycle, and forcing a speculative fix without being able to confirm it against a waveform risked masking the real bug rather than fixing it.

Status of the fix

Not fixed. No RTL changes were made or kept for this item — main is left at the pre-existing state: tb_server_dispatch_unit 11/11 PASS, tb_moesi_integration 1/3 PASS (2 FAIL), which matches the pre-chiplet-split v4 baseline exactly, so nothing has regressed further while this sits open. Full technical detail and investigation notes are in BUG-006.

How to resolve

  1. git checkout -b fix/unsolved-001-moesi-dma-flush
  2. Waveform-trace the ST_NPU_FLWAIT → ST_NPU_GAP → ST_NPU_DRAM transition in rtl/duck_coherency_ctrl.sv ($dumpvars + gtkwave, or dut._log.info state prints) for test_moesi_cpu_write_npu_read in isolation, to see whether the gap state is actually being entered/exited as BUG-003 designed on this toolchain, or whether the fault has moved elsewhere (the flush trigger itself, or L2 dirty-bit tracking).
  3. Confirm the fix gets tb_moesi_integration to 3/3 PASS and tb_server_dispatch_unit still 11/11 PASS — no regressions elsewhere.
  4. Update this file: Status → "Fix proposed", Fix branch → the branch name, and open it for review.
  5. On human approval: merge to main, set BUG-006.md's Status → Fixed, and move this entry to Resolved in docs/unsolved/README.md.