feat(v2): M8 PSRAM integration - real V1 backend shared across concurrent slots
neural_multiprocessor.v wraps dataflow_core.v (M7, unmodified) around the real, unmodified V1 PSRAM backend chain (int8_memory_access -> memory_interface -> psram_controller), funneling N_SLOTS independent Memory Backend Interface ports through a new generic N-port arbiter (slot_mem_arbiter.v) inspired by (not copied from) V1's own mem_arbiter.v. Real concurrent-slot simulation immediately surfaced a genuine bug (ERR-0008): memory_manager/prefetch_engine's byte-level backend protocol is fire-and-forget (a single-cycle mem_req pulse with no accept handshake) - correct for M4's direct 1:1 connection, but a naive arbiter silently drops a pulse arriving while the shared bus is owned by another slot, hanging that slot forever. Fixed with a per-port pending-request latch, the same "queue, don't drop" idiom already used by memory_manager's own pf_pending register (ERR-0006). Verified (Verilator): 4/4 PASS with 2 slots genuinely contending for one real PSRAM port (444 cycles). No regression on M4's own testbench. Real synthesis + nextpnr-ecp5 P&R (no harness needed - real PSRAM pins keep the top-level at 157 pins): 0 problems, Fmax 142.45 MHz, PASS at 80MHz. Arbitration policy is fixed lowest-index priority, not fairness- balanced (DEC-0010) - consistent with every other "simplest correct policy first" scheduling choice in this roadmap, revisited only if M9's real measurement shows starvation matters. Logged: simulation/synthesis/timing/benchmark/decisions (DEC-0010)/ experiments (EXP-0009)/errors (ERR-0008)/development.log, ROADMAP.md updated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
This commit is contained in:
@@ -75,3 +75,23 @@ PASS/FAIL: 4/4 PASS -- node0=48, node1=8 (both real neural_processor
|
||||
dependency-manager-to-director wake-up loop closes correctly
|
||||
end-to-end with real hardware in between, not just in isolation
|
||||
(M6's own testbench already proved the wake-up logic alone)
|
||||
|
||||
[2026-09-05] EXP-0009 -- hardware/v2/sim/tb_neural_multiprocessor.v
|
||||
test: same 3-node DAG as EXP-0008 (node0/node1 independent, node2
|
||||
depends on both), routed through neural_multiprocessor.v (M8): the
|
||||
REAL, UNMODIFIED V1 PSRAM backend chain (int8_memory_access ->
|
||||
memory_interface -> psram_controller -> psram_model) shared across
|
||||
N_SLOTS=2 genuinely concurrent memory_manager instances via the new
|
||||
slot_mem_arbiter.v -- node0 and node1 are registered back-to-back
|
||||
with no dependencies, so both dispatch to their slots essentially
|
||||
simultaneously and genuinely contend for the one real PSRAM port.
|
||||
simulator: Verilator 5.050 (--binary --timing)
|
||||
PASS/FAIL: 4/4 PASS after fixing a real dropped-request bug in the
|
||||
first arbiter draft (errors.log ERR-0008) -- node0=48, node1=8
|
||||
(concurrent, real PSRAM, real arbitration), node2=40 dispatched only
|
||||
after both genuinely completed. 444 cycles end-to-end (vs 20000-cycle
|
||||
watchdog timeout with the buggy first draft, where node1's request
|
||||
was silently dropped and its slot hung forever).
|
||||
regression: hardware/v2/sim/tb_memory_manager.v (M4) re-run unchanged
|
||||
(no M4 file touched) -- still 3/3 PASS, identical cycle counts
|
||||
(446/166/728), confirming slot_mem_arbiter.v is purely additive.
|
||||
|
||||
Reference in New Issue
Block a user