From 32d32f4c0eade3b80241bfbcb8d81f1aee004d6e Mon Sep 17 00:00:00 2001 From: manvalan Date: Sun, 20 Sep 2026 13:18:46 +0200 Subject: [PATCH] docs: capture exploratory 4x4 hybrid systolic scaling direction (not built) Brainstorming session outcome: instead of flat N=16 independent DDR3 requesters, group cores into 4 weight-stationary systolic chains of 4 PEs each - reduces independent DDR3 contenders from 16 to 4 while preserving task-level parallelism across the 4 groups. Captured as docs/ARCHITECTURE_ANALYSIS.md S5.6, explicitly marked exploratory/not decided/not built - revisit after the 32-bit channel widening and real N=2/4/8 flat-core scaling tests produce real numbers. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01MUG92aM9m68TRc4rG55BcC --- docs/ARCHITECTURE_ANALYSIS.md | 66 +++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/docs/ARCHITECTURE_ANALYSIS.md b/docs/ARCHITECTURE_ANALYSIS.md index 80a1649..ba6f28d 100644 --- a/docs/ARCHITECTURE_ANALYSIS.md +++ b/docs/ARCHITECTURE_ANALYSIS.md @@ -483,6 +483,72 @@ specifically to document where/how it breaks rather than to succeed): --- +### 5.6 [EXPLORATORY — captured, not decided, not built] Hybrid systolic scaling: 4 groups × 4-PE weight-stationary chains + +Captured from a 2026-09-20 brainstorming session (same continuation), before +any N=4/8/16 scaling work starts, so the direction isn't lost. **Nothing in +this subsection is implemented or committed to — it's a working hypothesis +for a future architecture, explicitly not yet an RTL task.** + +**The problem it targets**: plain N=16 independent cores (§5.5's own +"documentary, expected to break" framing) means 16 independent DDR3 +requesters contending for one arbitrated channel — real congestion that +neither §5.1 (packing) nor §5.4 (32-bit widening) alone removes, since both +attack bytes-per-MAC or raw bandwidth, not the *number of independent +consumers*. + +**The idea**: instead of 16 flat, independent `packed_slot.v` instances, +group them into **4 systolic chains of 4 PEs each**. Within a chain: the +weight tile stays resident (loaded once, same "weight-stationary" pattern +`layer_prefetch_ctrl.v`/`layer_weight_buffer.v` already implement for the +existing A/B lane reuse — this is a direct extension to 4 positions instead +of 2, not a new mechanism), and activation data streams through the chain +position by position, fetched from DDR3 once per chain rather than once per +PE. Between the 4 chains (groups), full task-level parallelism is +preserved — each group can run an independent job, same as today's model. + +**Why weight-stationary specifically (not activation-broadcast)**: chosen +because it generalizes to any layer type (FC, conv-via-im2col, attention — +anything reducible to "same weight matrix, many activation vectors") without +assuming a specific model's channel count or convolution overlap pattern — +important since this is a general-purpose accelerator, not built for one +fixed network. + +**Real, quantifiable rationale** (order-of-magnitude, not yet measured — +flagged explicitly as a projection): +- DSP48E1: 16 cores × 8 DSP/core = 128/240 (53%) — real, fits with margin. +- DDR3 requesters: drops from 16 (flat) to 4 (one per chain) — a real 4× + reduction in the number of independent contenders for the arbitrated + channel, on top of (not instead of) §5.1's packing and §5.4's widening. +- Combined with §5.4's 32-bit widening (2× physical ceiling), the + available-bandwidth-to-demand ratio improves by roughly 8× versus the + naive flat-N=16 baseline — a real, meaningful, but NOT a full solve by + itself; still needs real measurement once anything is built. + +**Real open questions, not resolved yet** (deliberately not designed +further until the current in-flight work — §5.4's channel widening, N=2/4/8 +real testing — lands first, per this project's own "one variable at a time" +discipline): +- Intra-chain dataflow RTL (result propagation between adjacent PEs, + pipeline drain/fill at chain boundaries) is a real, new design, not a + trivial extension — needs its own isolated verification before wiring + into anything real, same as every other module in this project. +- Result collection actually gets SIMPLER under this model versus flat + N=16 (4 chain-output events instead of 16 independent ones) — relevant + to §5.3's result-writeback engine, worth designing writeback with this + in mind rather than for flat N=16 if this direction is pursued. +- Arbitration simplifies too: 4 group-level requesters instead of 16, + though `sdram_arbiter_n.v`'s own NUM_REQ parameter already generalizes to + either case without changes. + +**Decision**: not decided. Revisit after §5.4 (32-bit widening) and the +real N=2/4/8 flat-core scaling tests produce real numbers — those numbers +will tell us whether flat scaling is "good enough" up to some N, making +this restructuring unnecessary, or whether the real congestion at N=8/16 +justifies it. + +--- + ## 6. Summary table: what's real vs. what's a calculation | Claim | Status |