michele/FPGA-Neural
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

feat(v2): M3 activation/weight/result buffers, real BRAM mapping

Browse Source 
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:
michele
2026-09-05 14:19:11 +02:00
co-authored by Claude Sonnet 5
parent 3026dcd997
commit 5f0d7f101c
29 changed files with 178330 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hardware/v2/logs/benchmark.log
+19
View File
@@ -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.