micheleandClaude Sonnet 5
ccaf3ee059
Adds result_writeback.v, one instance per packed_slot.v, writing each completed job's result directly into DDR3 at the job's own result_addr_a/b instead of driving literal top-level pins -- the same architectural shape as the weight-fetch path, in reverse. job_done now means "durably in DDR3", not "captured in a register only a pin could see". n2_system_ddr3_top.v's own s0_result_data_a/b, s1_result_data_a/b top-level package pins are removed (and the now-dangling XDC constraint for them), closing the real, hard scaling blocker docs/ARCHITECTURE_ ANALYSIS.md flagged since EXP-0074/0079 (8 bits x 2 lanes x N cores -> 256 pins at N=16). Addressing reuses the exact same JOB_ADDR_WIDTH->ctrl-bus-word truncation x_base_a/w_base already use (verified against act_tile_ fetch.v's/layer_prefetch_ctrl.v's own real code, not guessed). The host reads results back via the already-existing READ_MEM (0x02) SPI opcode -- no new protocol. A real EXP-0066-class bug (issuing ctrl_req before mem_grant) was caught and fixed before ever compiling, by re-deriving the design against act_tile_fetch.v's own proven S_MEMWAIT/S_GAP sequencing. Verified two ways: tb_packed_slot.v extended with a real DDR3 read-after-write check (9/9 PASS, confirms the write actually landed, not just that job_done pulsed); tb_n2_system_ddr3.v re-run via real xsim to confirm correct behavior under real 2-slot shared-bus arbitration (8/8 PASS, 0 errors, consistent timing with EXP-0087's own baseline for this workload). 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.