Roflin
007c4d40f9
Returning both bytes of the SPRAM word per request was the one approach that looked like it addressed the real constraint rather than working around it. Implemented fully (16-bit exi_rsp_data + exi_rsp_odd in SPRAMArbiter, sp_buf/ sp_cnt pair-pushing in BBARegisterFile, address advance by 2, tests updated) and it made things WORSE: bba_top T9 went 6/6 / 3/6 / 1/6 at EXI_HALF=8/2/1 against the baseline's 6/6 / 6/6 / 1/6, breaking HALF=2, leaving the DE DE duplication at the hardware rate, and adding a new fault where the first read after an idle period returns all zeros. Reverted. The reason is worth keeping: the budget only doubles if the next request issues while the second byte is still being pushed, and it cannot, because that byte sits in a holding register the prefetch guard has to wait on. The sequence stays request -> response -> push -> push -> request, so round-trip latency per pair is unchanged and the first byte of each pair faces the same deadline as before. The constraint is unhidden round-trip latency, not bytes per round trip. Also corrects the recorded T9 ratio at EXI_HALF=1 from 2/6 to 1/6, which is what the committed test deterministically prints. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>