BUG-006: TC-MOESI-1/TC-MOESI-2 fail again despite BUG-003 fix

Field	Value
Severity	CRITICAL
Component	RTL
File(s)	rtl/duck_coherency_ctrl.sv
Status	Open — roadblocked, see UNSOLVED-001
Date	2026-07-19

Symptom

Running 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

Identical symptom to BUG-003 (dirty L2 line not flushed before NPU DMA reads it), which that entry documents as fixed via an ST_NPU_GAP state. ST_NPU_GAP is present in the current rtl/duck_coherency_ctrl.sv (confirmed by inspection), so this is either a second, different timing bug producing the same symptom, or 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).

Investigation so far

Confirmed not caused by this session's other changes: reproduced identically on rtl/system_top.sv/tb/cpu_peak_tests.asm stashed back to their pre-session state (i.e. before BUG-004/BUG-005), so this regression predates and is unrelated to today's run_riscv_program fixes. Not investigated further this cycle — out of scope for the run_riscv_program task this run was scoped to; flagging for a dedicated follow-up run rather than fixing speculatively.

Root Cause

Not yet determined.

Fix

Not yet applied.

Notes

Whoever picks this up next should start by re-running just test_moesi_cpu_write_npu_read in isolation with dram_ack/FSM state waveform tracing ($dumpvars + gtkwave, or add dut._log.info state prints) around the ST_NPU_FLWAIT → ST_NPU_GAP → ST_NPU_DRAM transition described in BUG-003, to see whether the gap state is actually being entered/exited as designed on this toolchain, or whether the fault has moved elsewhere (e.g. the flush trigger itself, or L2 dirty-bit tracking).