feat(v2): M7 Dataflow Core - full M1-M6 integration, wake-up loop closed end-to-end

dataflow_core.v integrates dependency_manager (M6) -> neural_director
(M5) -> N_SLOTS x (memory_manager (M4) + neural_processor (M1)) for
the first time. A slot's completion (via neural_director's new
slot_node_id tracking, an additive port) feeds back as a
producer_done event to dependency_manager, waking up any node that
depended on it - closing the dataflow loop without external glue.

Verified end-to-end (Verilator) on a 3-node DAG: two independent
nodes plus a third depending on both, confirmed to dispatch only
after both genuinely complete via real neural_processor computation.
4/4 PASS.

Real synthesis + nextpnr-ecp5 P&R via a synthesis-only timing harness
(bare per-slot backend ports exceed the LFE5U-45F's TRELLIS_IO
budget, same pattern as ERR-0005): N_SLOTS=2 -> 165.15 MHz,
N_SLOTS=4 -> 133.19 MHz, both PASS at 80MHz, 0 synthesis problems.

Scope explicitly deferred to M8 (DEC-0009): M3's BRAM buffers not
wired in yet, per-slot Memory Backend Interface ports not arbitrated
to one shared PSRAM master yet - both need real measured data before
committing to a design, not guessed at here.

Logged: simulation/synthesis/timing/benchmark/decisions (DEC-0009)/
experiments (EXP-0008)/errors (ERR-0007, a Yosys chparam-ordering
build quirk, not an RTL bug)/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:
2026-09-05 15:05:28 +02:00
co-authored by Claude Sonnet 5
parent 8af16d3a12
commit 77baa8fc16
13 changed files with 798 additions and 1 deletions
+27
View File
@@ -176,3 +176,30 @@ VERIFICATION: hardware/v2/sim/tb_memory_manager.v -- 3/3 tests PASS
signal inspection).
STATUS: FIXED, verified end-to-end with the real (unmodified) V1
PSRAM backend chain and a real M1 neural_processor.
ERR-0007 (Yosys usage quirk, WORKED AROUND, not an RTL bug)
DATE: 2026-09-05
MODULE: hardware/v2/synthesis/harness_dataflow_core.v (build script)
SYMPTOM: `chparam -set N_SLOTS 2 dataflow_core` (setting the parameter
directly on the NON-top child module, before running `synth_ecp5
-top harness_dataflow_core`) synthesizes with no visible error from
the chparam/hierarchy commands themselves, but `synth_ecp5` then
fails with "Module `\dataflow_core' referenced in module
`\harness_dataflow_core' in cell `\dut' is not part of the design" --
even though a standalone `hierarchy -top harness_dataflow_core` run
(no synth_ecp5) with the exact same chparam succeeds.
ROOT CAUSE: harness_dataflow_core.v's own instantiation of
dataflow_core explicitly overrides N_SLOTS via its own local
parameter (`.N_SLOTS(N_SLOTS)`) -- chparam on the child module's
DEFAULT is therefore always shadowed at that instantiation site
regardless of its value, and synth_ecp5's own internal re-hierarchy
pass (distinct from a standalone `hierarchy` call) does not
reconcile a chparam'd-but-never-actually-used child default the
same way, dropping the generic module reference instead.
WORKAROUND: set the parameter on the TOP module being synthesized
instead (`chparam -set N_SLOTS 2 harness_dataflow_core`), letting
its own instantiation forward the value down to dataflow_core as
designed. Confirmed working for both N_SLOTS=2 and N_SLOTS=4.
STATUS: WORKED AROUND. A build-script ordering detail, not a defect in
dataflow_core.v or harness_dataflow_core.v themselves -- noted here
so a future N_SLOTS sweep (M9/M10) does not re-trip over it.