feat(v2): M3 activation/weight/result buffers, real BRAM mapping
Implements M3: three parametric dual-port buffers for the §12 data-plane (Input/Weight/Result), reusing the proven BRAM-inference idiom from the frozen hardware/v1/rtl/act_buffer.v (synchronous write, synchronous REGISTERED read, no reset on the read register -- keeps Yosys off the LUT-RAM path). Verified with Verilator: 10/10 tests pass (write-then-read correctness, extreme INT8 round-tripping, weight_buffer's full 64-bit tile width round-tripping, undisturbed re-reads). Real synthesis at two depths per module (6 configs total): 0 CHECK problems, every configuration correctly infers DP16KD (never LUT-RAM). Non-obvious real finding: weight_buffer's BRAM cost is driven by its P_IN*DATA_WIDTH tile width, not its DEPTH -- an 8x depth reduction (512->64) left DP16KD usage unchanged at 2, while activation_buffer/result_buffer (byte-wide) scale as naively expected (2->1). All default-depth configs PASS at 80MHz with large margin (287-367 MHz) via real nextpnr-ecp5 place&route. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
This commit is contained in:
Claude Sonnet 5
@@ -40,3 +40,22 @@ until M9): N_PROCESSORS * P_IN MACs/cycle when all processors are
|
||||
simultaneously streaming tiles (8, 16, 32, 64 for N=1/2/4/8 -- verified
|
||||
achievable in principle by EXP-0003's concurrent/staggered simulation,
|
||||
not yet measured as a sustained throughput number).
|
||||
|
||||
[2026-09-05] M3 buffers -- BRAM cost vs DEPTH (real Yosys synth_ecp5)
|
||||
|
||||
| Module | DEPTH | DP16KD | LUT4 | FF |
|
||||
|--------------------|-------|--------|------|-----|
|
||||
| activation_buffer | 4096 | 2 | 37 | 30 |
|
||||
| activation_buffer | 256 | 1 | 21 | 26 |
|
||||
| weight_buffer | 512 | 2 | 88 | 139 |
|
||||
| weight_buffer | 64 | 2 | 73 | 136 |
|
||||
| result_buffer | 4096 | 2 | 37 | 30 |
|
||||
| result_buffer | 256 | 1 | 21 | 26 |
|
||||
|
||||
weight_buffer's DP16KD count is flat across an 8x depth reduction --
|
||||
its 64-bit TILE_WIDTH (P_IN=8 * DATA_WIDTH=8), not DEPTH, determines
|
||||
BRAM count for this module. activation_buffer/result_buffer (byte-
|
||||
wide) scale as expected with depth. Confirms §14's warning literally:
|
||||
"non assumere che buffer piu' grandi siano automaticamente migliori"
|
||||
-- here, smaller was not cheaper either, because depth was the wrong
|
||||
lever for this specific buffer's cost.
|
||||
|
||||
@@ -88,3 +88,25 @@ errors: ERR-0005 (artefatto di sintesi da pin-count, non un bug RTL --
|
||||
decision: vedi decisions.log DEC-0005.
|
||||
next_action: M3 -- activation_buffer.v / weight_buffer.v /
|
||||
result_buffer.v (profondita' parametrica, valutare BRAM mapping).
|
||||
|
||||
[2026-09-05T15:15:00Z] commit=3026dcd session=v2-M3-buffers
|
||||
module: hardware/v2/rtl/activation_buffer.v, weight_buffer.v,
|
||||
result_buffer.v
|
||||
action: implementato M3 -- tre buffer paramentrici (profondita'
|
||||
parametrica) che inferiscono DP16KD reale, riusando l'idioma gia'
|
||||
validato in hardware/v1/rtl/act_buffer.v (porta A scrittura sync,
|
||||
porta B lettura sync REGISTRATA, nessun reset sulla porta di lettura
|
||||
per restare fuori dal percorso LUT-RAM).
|
||||
reason: roadmap M3.
|
||||
result: 10/10 test PASS (Verilator). Sintesi reale a 2 profondita'
|
||||
ciascuno: 0 problemi CHECK, DP16KD reale confermato in tutte le 6
|
||||
configurazioni (mai LUT-RAM). Scoperta reale non assunta: il costo
|
||||
BRAM di weight_buffer e' determinato dalla LARGHEZZA (P_IN*DATA_
|
||||
WIDTH=64 bit), non dalla profondita' -- 512->64 di profondita' non
|
||||
ha ridotto il conteggio DP16KD (resta 2). Place&route reale sui
|
||||
default: tutti PASS a 80MHz con ampio margine (287-367 MHz).
|
||||
errors: nessuno.
|
||||
decision: vedi benchmark.log -- il dimensionamento di weight_buffer
|
||||
andra' guidato da P_IN, non solo da DEPTH, quando si arrivera' a
|
||||
M4/M9.
|
||||
next_action: M4 -- memory_manager.v + prefetch_engine.v.
|
||||
|
||||
@@ -159,3 +159,62 @@ decision: see decisions.log DEC-0005 (DSP is the binding constraint,
|
||||
be explored going forward).
|
||||
next_action: M3 -- activation_buffer.v / weight_buffer.v /
|
||||
result_buffer.v.
|
||||
|
||||
EXP-0004
|
||||
timestamp: 2026-09-05T15:15:00Z
|
||||
git_commit: 3026dcd (+ uncommitted M3 work)
|
||||
session: v2-M3-buffers
|
||||
module: hardware/v2/rtl/activation_buffer.v, weight_buffer.v,
|
||||
result_buffer.v
|
||||
configuration: activation_buffer/result_buffer DEPTH in {4096, 256};
|
||||
weight_buffer DEPTH (in tiles) in {512, 64}, P_IN=8, DATA_WIDTH=8
|
||||
(TILE_WIDTH=64 bits)
|
||||
action: M3 -- three parametric dual-port BRAM-inferring buffers
|
||||
(Input/Weight/Result of the §12 data-plane diagram), reusing the
|
||||
proven inference idiom from hardware/v1/rtl/act_buffer.v (sync
|
||||
write, sync REGISTERED read, no reset on the read register).
|
||||
command (sim, Verilator): verilator --binary --timing -j 0 -Wno-fatal
|
||||
--top-module tb -o /tmp/vtb_buffers hardware/v2/rtl/
|
||||
activation_buffer.v hardware/v2/rtl/weight_buffer.v
|
||||
hardware/v2/rtl/result_buffer.v hardware/v2/sim/tb_buffers.v &&
|
||||
/tmp/vtb_buffers
|
||||
command (synth): yosys -p "read_verilog <file>; chparam -set DEPTH
|
||||
<N> <module>; synth_ecp5 -json .../top.json -top <module>" for each
|
||||
of the 6 (module, depth) combinations.
|
||||
command (timing): nextpnr-ecp5 --45k --package CABGA381 --speed 8
|
||||
--freq 80 --lpf-allow-unconstrained, default-depth configs only.
|
||||
result:
|
||||
SIMULATED: 10/10 tests PASS -- write-then-read correctness incl.
|
||||
extreme INT8 (-128/127) round-tripping exactly, back-to-back
|
||||
writes to different addresses not disturbing earlier entries, and
|
||||
weight_buffer's full 64-bit TILE_WIDTH round-tripping (not just
|
||||
one lane).
|
||||
SYNTHESIZED (real BRAM mapping, not assumed):
|
||||
activation_buffer DEPTH=4096: 2 DP16KD, 37 LUT4, 30 FF
|
||||
activation_buffer DEPTH=256: 1 DP16KD, 21 LUT4, 26 FF
|
||||
weight_buffer DEPTH=512: 2 DP16KD, 88 LUT4, 139 FF
|
||||
weight_buffer DEPTH=64: 2 DP16KD, 73 LUT4, 136 FF
|
||||
result_buffer DEPTH=4096: 2 DP16KD, 37 LUT4, 30 FF
|
||||
result_buffer DEPTH=256: 1 DP16KD, 21 LUT4, 26 FF
|
||||
0 CHECK problems in all 6 configurations -- every one correctly
|
||||
inferred DP16KD block RAM, none fell back to LUT-RAM.
|
||||
REAL, NON-OBVIOUS FINDING (§14: "non assumere che buffer piu' grandi
|
||||
siano automaticamente migliori"): shrinking weight_buffer's DEPTH
|
||||
8x (512->64) did NOT reduce DP16KD usage at all (2->2) -- its
|
||||
64-bit TILE_WIDTH (P_IN*DATA_WIDTH), not its depth, is what forces
|
||||
2 physical block RAMs (a single DP16KD's usable port width in the
|
||||
density this needs is narrower than 64 bits). Depth-only buffer
|
||||
sizing decisions are the wrong lever for THIS buffer; width
|
||||
(P_IN) is. activation_buffer/result_buffer, being byte-wide, DO
|
||||
show the expected depth-proportional DP16KD count (2 -> 1).
|
||||
POST-P&R (default-depth configs): all PASS at 80MHz with large
|
||||
margin (287-367 MHz range, real place&route) -- these buffers are
|
||||
not a timing concern in isolation.
|
||||
errors: none.
|
||||
decision: keep DEPTH parametric as specified, but document (this
|
||||
entry + benchmark.log) that weight_buffer's real BRAM cost is driven
|
||||
by P_IN (its width), not DEPTH -- relevant when M4/M9 size these
|
||||
buffers against a real workload.
|
||||
next_action: M4 -- memory_manager.v + prefetch_engine.v (wires these
|
||||
three buffers + the array together, PSRAM backend reused unmodified
|
||||
from V1 per §15).
|
||||
|
||||
@@ -28,3 +28,11 @@ concurrency: confirmed genuine -- in the staggered test, the
|
||||
later-launched, shorter job (processor 1) completes BEFORE the
|
||||
earlier-launched, longer job (processor 0), proving independent
|
||||
progress rather than serialization.
|
||||
|
||||
[2026-09-05] EXP-0004 -- hardware/v2/sim/tb_buffers.v
|
||||
test: 10 cases across activation_buffer/weight_buffer/result_buffer
|
||||
vectors: extreme INT8 (-128, 127, -100, 100), regular values, full
|
||||
64-bit tile round-trip (weight_buffer), re-reads confirming earlier
|
||||
writes undisturbed
|
||||
simulator: Verilator 5.050 (--binary --timing)
|
||||
PASS/FAIL: 10/10 PASS
|
||||
|
||||
@@ -27,3 +27,12 @@ CHECK: 0 problems in all 4 configurations. Perfectly linear scaling in
|
||||
flawed harness attempt fed identical data to every processor/lane
|
||||
and Yosys silently deduplicated down to 1x regardless of N -- caught
|
||||
by checking for exactly this linearity before trusting the numbers).
|
||||
|
||||
[2026-09-05] EXP-0004 -- activation_buffer/weight_buffer/result_buffer,
|
||||
2 depths each
|
||||
activation_buffer D=4096: LUT=37 FF=30 DP16KD=2 (D=256: LUT=21 FF=26 DP16KD=1)
|
||||
weight_buffer D=512: LUT=88 FF=139 DP16KD=2 (D=64: LUT=73 FF=136 DP16KD=2)
|
||||
result_buffer D=4096: LUT=37 FF=30 DP16KD=2 (D=256: LUT=21 FF=26 DP16KD=1)
|
||||
CHECK: 0 problems, all 6 configs correctly infer DP16KD (no LUT-RAM
|
||||
fallback). weight_buffer's DP16KD count does NOT drop with depth
|
||||
(width-bound, not depth-bound -- see decisions.log / benchmark.log).
|
||||
|
||||
@@ -31,3 +31,10 @@ TRELLIS_IO stays at 18/245 (7%) throughout (harness has only
|
||||
clk/rst/seed/checksum as real pins, by design -- see ERR-0005).
|
||||
See decisions.log DEC-0005: DSP, not Fmax or LUT/FF, is the resource
|
||||
that will first prevent scaling N_PROCESSORS further at P_IN=8.
|
||||
|
||||
[2026-09-05] EXP-0004 -- default-depth buffer configs, real nextpnr-ecp5
|
||||
activation_buffer (D=4096): Fmax=325.20 MHz PASS
|
||||
weight_buffer (D=512): Fmax=339.67 MHz PASS
|
||||
result_buffer (D=4096): Fmax=325.20 MHz PASS
|
||||
All far above the 80MHz target -- buffers are not a timing concern in
|
||||
isolation at these depths.
|
||||
|
||||
Reference in New Issue
Block a user