micheleandClaude Sonnet 5
ee5a68f6e6
EXP-0053: sdram_cdc_bridge.v decouples the SDRAM clock (115.2MHz, real value derived from the board's own existing PLL VCO=576MHz, verified via ecppll) from the 64MHz compute domain. Isolated: 137/137 tests, 0 errors, but real measured speedup is only 1.095x (not the naive 1.8x clock-ratio estimate) -- the CDC handshake's own synchronizer round-trip is a fixed per-transaction tax. EXP-0054: sdram_controller_openrow.v implements the page-hit/ keep-row-open optimization sdram_controller.v's own header had always deferred. weight_prefetch_engine_wide.v's real production traffic is strictly sequential per job and mostly stays within one SDRAM row -- closing/reopening it every tile (today's fixed auto-precharge policy) wastes tRP+tRCD for no reason. Isolated: 154/154 tests, 0 errors, 0 protocol violations (including the new refresh-while-row-open hazard, fixed via an explicit precharge-before-refresh path). Real measured speedup on the actual sequential access pattern: 1.141x. EXP-0055: composed both, then integrated into the real D-Stress benchmark (N=4/N=8, 256/256 bit-exact in every config). Result: open-row ALONE gives a real, consistent ~5% cycle-count improvement (47445/47468 vs baseline 49927/49909). CDC alone is a real ~8% REGRESSION. Combined is still a ~4% regression -- the CDC's fixed tax is paid on every transaction regardless of row-hit, and real D-Stress traffic interleaves weight-fetch/activation-result access far more than the isolated same-row test exercised, so open-row's real saving doesn't offset it. Decision: do not adopt the CDC approach; open-row alone is the disclosed, real win worth considering for production next, pending an explicit go-ahead (not applied to the real board top in this commit -- all additive, existing production RTL untouched). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUG92aM9m68TRc4rG55BcC
Formato dei log V2
Regola non negoziabile (docs/v2-description.md §25-29): ogni attività
significativa (modifica, simulazione, sintesi, benchmark, decisione, errore)
deve essere registrata. Nessun log viene mai sovrascritto o troncato — solo
append. Nessun ID esperimento (EXP-XXXX) o decisione (DEC-XXXX) viene mai
riutilizzato, anche se il risultato è un FAIL.
File
development.log— log principale di sviluppo, un'entry per ogni sessione di lavoro/milestone (creazione file, refactor, avanzamento roadmap).architecture.log— decisioni e note di architettura a grana fine (non scelte finali — quelle vanno indecisions.log— ma esplorazioni, alternative considerate, vincoli scoperti).simulation.log— ogni run di simulazione (Icarus/Verilator): test, vettori, cicli, PASS/FAIL, confronto bit-exact con V1, stall/memory-wait.synthesis.log— ogni run Yosys: LUT/FF/DSP/BRAM, warning, problemi CHECK.timing.log— ogni run nextpnr-ecp5: Fmax, percorso critico, WNS/TNS se disponibili. Fmax "ufficiale" di una configurazione = solo da qui, mai da simulazione o stima.benchmark.log— tabelle di confronto per configurazione (Fmax, MAC/cycle, cycles/neuron, utilization, ecc.), sempre con etichetta THEORETICAL/SIMULATED/SYNTHESIZED/POST-P&R.decisions.log— decisioni architetturali importanti, formatoDEC-XXXX(vedidocs/v2-description.md§27).experiments.log— registro principale, unEXP-XXXXper ogni esperimento end-to-end (config → sim/synth/timing → risultato), rimanda areports/experiments/EXP-XXXX/.errors.log— errori/bug/regressioni incontrati durante lo sviluppo V2 stesso (non i bug V1, già chiusi inhardware/v1/docs/validation/bugs.md).
Campi minimi per entry (§26)
timestamp, experiment_id (se applicabile), git_commit, session/agent,
module, configuration, action, reason, command, result, errors, decision,
next_action
Per synthesis/timing aggiungere: LUT, FF, DSP, BRAM, Fmax, critical path, WNS/TNS. Per simulazione: test, vectors, cycles, PASS/FAIL, bit-exact result, stall cycles, memory wait, utilization.