micheleandClaude Sonnet 5
3416b8d3cf
Same class of testbench-vs-DUT scheduling race documented in EXP-0058 (tb_layer_prefetch_ctrl.v, tb_neural_processor_layer_reuse.v) was also present here on ctrl_req/fill_done/consume_done: clearing a one-cycle pulse on the very next @(posedge clk) let the clear land in the same active-region pass as the edge the DUT needed to sample it at, so the pulse could be silently missed. Confirmed via direct state tracing: sdram_controller_openrow.v sat in S_IDLE with busy=0 forever after the first burst, never latching req_pending for the second -- this is why the file hung indefinitely rather than completing. Fixed with the same #1-before-clear hardening as the other files. Honesty note: fixing this hang exposed a SECOND, still-unfixed bug in prefetch_layer's own fill_addr sequencing (real data-correctness failures once the run actually completes, not just a hang) -- so EXP-0057's own headline "7.16x real measured speedup" number is NOT re-verified by this commit and should not be treated as confirmed. Not pursued further -- see decisions.log for why (project paused). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUG92aM9m68TRc4rG55BcC