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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user