FPGA-Neural/hardware/v2/logs/errors.log

# V2 errors log -- solo append, mai troncato/sovrascritto (vedi README.md)
# Nessuna entry ancora -- popolato incrementalmente man mano che avanza lo sviluppo V2.

ERR-0001 (Icarus Verilog v13.0 toolchain bug, TASK/SCOPE-ENTRY DESYNC)
DATE: 2026-09-05
MODULE: hardware/v2/sim/tb_neural_processor.v (M1 testbench development)
SYMPTOM: a task (or any named `begin:label` block) whose FIRST executable
  statement is a blocking assignment to a signal read by another module's
  `always @(posedge clk)`, when the task/block is entered immediately after
  a time-consuming statement in the caller with no intervening
  `@(posedge clk)`, can make that FIRST assignment invisible to the DUT at
  the very next clock edge (the DUT's own always block behaves as if the
  signal never changed). Confirmed at V1's own frozen `neuron_parallel.v`
  (unmodified, already certified) via a minimal 3-statement task
  (`v1_start=1; @(posedge clk); v1_start=0;`) -- `busy` never asserted.
REPRODUCTION: /tmp/mt6.v-style repro (not committed, transient scratch
  file) -- see conversation record for the exact minimal case.
DIAGNOSIS METHOD: bisected from the full dual-DUT testbench down to a
  standalone ~15-line repro, ruling out RTL, port connections, and
  operator precedence one at a time.
WORKAROUND: always begin such a task with an explicit `@(posedge clk);`
  before its first assignment (matches the pre-existing convention in
  hardware/v1/sim's own tasks, e.g. neuron_parallel_tb.v's run_neuron,
  which is presumably why V1's own test suite was never affected).
STATUS: WORKAROUND APPLIED in hardware/v2/sim/tb_neural_processor.v's
  run_case. NOT reported upstream (out of scope for this session). See
  ERR-0004 for the broader consequence of this finding.

ERR-0002 (Icarus Verilog v13.0 toolchain bug, SPURIOUS CONDITION EVALUATION)
DATE: 2026-09-05
MODULE: hardware/v2/rtl/neural_processor.v (protocol-violation guard,
  removed -- see decisions.log DEC-0003)
SYMPTOM: `if (operand_valid && !operand_ready && (state-is-one-of-four))`
  inside `always @(posedge clk)` evaluated TRUE at an edge where
  `operand_valid` was independently confirmed (via $display in the same
  timestep, and via the testbench's own port-connected signal) to be 0.
  Bisected term-by-term: even `if (operand_valid && !operand_ready)`
  alone, and even `if (operand_valid)` alone with explicit `== 1'b1`
  comparisons, still fired spuriously. Confirmed NOT a precedence issue
  (parens are unambiguous) and NOT specific to this exact expression
  shape (multiple simplified variants all reproduced it).
CROSS-CHECK: root-caused further via a minimal 2-state FSM
  (`if (go) st<=B;`) with NO relation to the removed guard -- Icarus
  failed to transition on an ODD-numbered testbench clock edge
  (`repeat(3)` before the pulse) but succeeded on an EVEN-numbered one
  (`repeat(4)`), reproduced identically with both `always #5 clk=~clk`
  and `initial ... forever #5 clk=~clk` clock generators. VERILATOR
  5.050 gives the CORRECT result for the same repro in both cases.
  This suggests ERR-0001 and ERR-0002 are two symptoms of the same
  underlying VVP scheduling defect (edge-count/thread-parity dependent),
  not two unrelated bugs.
STATUS: the offending RTL block (protocol-violation detection) was
  REMOVED rather than chased further -- see DEC-0003. Root cause not
  fully isolated (documented honestly, not overclaimed).

ERR-0003 (real RTL bug in hardware/v2/rtl/neural_processor.v, FOUND AND FIXED)
DATE: 2026-09-05
MODULE: hardware/v2/rtl/neural_processor.v, stage 0 (input
  alignment/register)
SYMPTOM: back-to-back single-tile jobs (and some multi-tile jobs)
  produced result_data=0 instead of the correct value, while the
  internal `y7` register (one stage upstream of the FSM's capture)
  showed the CORRECT value one cycle later than `valid7` first asserted.
ROOT CAUSE: `last0 <= tile_last;` was unconditional, while
  `valid0 <= operand_valid && operand_ready;` was correctly gated. A
  master asserting `tile_last` before `operand_ready` rises (legal
  valid-before-ready behavior) let a "last" tag propagate through the
  pipeline (last1, last_tree[], last5, last6) with NO corresponding
  valid tile behind it, arriving at stage 7 one cycle ahead of the
  real valid/data pair and causing the FSM to capture a stale/wrong
  `y7`.
EVIDENCE: isolated to a single-DUT, no-task, no-V1 repro
  (hardware/v2/sim/tb_neural_processor.v run under Verilator, with a
  cycle-by-cycle dump of valid5/last5/valid6/last6/valid7/y7) --
  `last5=1` while `valid5=0` on the same cycle, confirmed the
  desync's exact origin at stage 0.
FIX: `last0 <= (operand_valid && operand_ready) ? tile_last : 1'b0;`
  -- last0 is now gated identically to valid0.
VERIFICATION: full 7-test bit-exact-vs-V1 regression
  (hardware/v2/sim/tb_neural_processor.v under Verilator) -- 7/7 PASS
  after the fix, including the back-to-back and single-tile-after-
  multi-tile cases that exposed it.
STATUS: FIXED, verified.

ERR-0004 (methodology consequence of ERR-0001/ERR-0002)
DATE: 2026-09-05
NOTE: this session's V1 certification campaign (docs/validation/,
  hardware/v1/docs/validation/) was verified exclusively with Icarus
  Verilog v13.0, the ONLY simulator available on this machine at the
  time. ERR-0001/ERR-0002 show that v13.0 has at least one real,
  reproducible scheduling defect around clock-edge/task-entry timing.
  V1's own testbenches were NOT observed to trigger it in this session
  (V1's `run_neuron`-style tasks already begin with `@(posedge clk)`,
  which incidentally avoids ERR-0001's trigger condition), and V1
  remains frozen/untouched regardless. This is flagged here for
  honesty, not to imply V1's certification is wrong -- re-verifying
  the full V1 suite under Verilator was explicitly OUT OF SCOPE for
  this V2-kickoff session (V1 is frozen, not to be touched) and was
  not performed. See decisions.log DEC-0004.
STATUS: OPEN CAVEAT, not actioned in this session by design.

ERR-0005 (synthesis measurement artifact, WORKED AROUND, not an RTL bug)
DATE: 2026-09-05
MODULE: hardware/v2/rtl/neural_processor_array.v
SYMPTOM: synthesizing neural_processor_array as a bare top-level
  module (every per-processor job/operand/result field exposed as a
  real TRELLIS_IO pin) works at N_PROCESSORS=1 but fails place&route
  at N_PROCESSORS=2 with "Unable to place cell ...$tr_io, no BELs
  remaining to implement cell type 'TRELLIS_IO'".
ROOT CAUSE: not a logic/timing limit -- the LFE5U-45F-8BG381 package
  has 245 TRELLIS_IO pins total; the array's wide per-processor buses
  (input_data/weight_data alone are DATA_WIDTH*P_IN*N_PROCESSORS bits)
  exceed that budget once N_PROCESSORS>=2, purely because these ports
  have no on-chip consumer yet (the Memory Manager/M4 and Neural
  Director/M5 that will drive them in the real system don't exist
  yet).
WORKAROUND: hardware/v2/synthesis/harness_neural_processor_array.v --
  a synthesis-only wrapper (NOT part of rtl/, not a functional
  deliverable) that drives all wide buses from an internal free-
  running LFSR and reduces outputs to a small checksum, keeping only
  clk/rst/seed/checksum as real top-level pins. See its own header
  comment and experiments.log EXP-0003 for the resulting real
  resource/Fmax numbers.
STATUS: WORKED AROUND. Will become moot once M4/M5 exist and the array
  is synthesized as part of a larger design with on-chip ports instead
  of a bare top-level module.

ERR-0006 (real RTL bugs in hardware/v2/rtl/memory_manager.v, FOUND AND FIXED)
DATE: 2026-09-05
MODULE: hardware/v2/rtl/memory_manager.v
SYMPTOM: end-to-end M4 testbench (real V1 PSRAM backend + real M1
  neural_processor) hung permanently partway through the first
  multi-tile job -- bank_ready for the "current" bank never became 1,
  even though the byte-level backend clearly kept completing read
  transactions (observed via cycle-by-cycle hierarchical tracing of
  memory_manager/prefetch_engine internal state).
ROOT CAUSES (three, found together during the same debugging session):
  1. The tile-N+2 prefetch request, queued on tile-N's handoff, could
     be issued (pf_start asserted) while prefetch_engine was STILL
     mid-fetch for tile-N+1 -- there was no single-in-flight-request
     discipline at all in the first draft. Fixed by adding a
     single-entry pf_pending register: requests are queued, not
     issued directly, and a dedicated rule launches the queued
     request only once the engine reports free.
  2. Even with that queue, pf_busy does not read 1 until the cycle
     AFTER pf_start was first observed by prefetch_engine (its own
     fetch_busy<=1 lags its own fetch_start sampling by one clock) --
     checking only `!pf_busy` left a genuine one-cycle window where a
     second queued request would fire on top of the one just
     launched, silently overwriting pf_target_bank (and pf_x_addr/
     pf_w_addr) for the fetch already in flight. The address corruption
     was harmless (prefetch_engine had already latched the correct
     address into its own state that same edge), but pf_target_bank
     corruption meant the eventually-completed fetch's real data got
     filed into the WRONG bank's bank_ready/bank_x/bank_w, permanently
     starving the bank actually needed next. Fixed by gating the issue
     rule on `!pf_busy && !pf_start` (the extra term closes exactly
     this one-cycle window).
  3. A combinational mux selecting between prefetch_engine's own
     backend wires and the result-write-back FSM's wires was gated on
     `state == MM_WRITE_RESULT`, but wr_mem_req (asserted while
     state==MM_WRITE_RESULT) only becomes valid the FOLLOWING cycle,
     i.e. while state==MM_DONE -- the mux therefore selected the wrong
     source for the one cycle the write request pulse was actually
     high, silently dropping the PSRAM write entirely. Fixed by
     widening the mux's select condition to cover both states.
DIAGNOSIS METHOD: cycle-by-cycle hierarchical signal dumps (mm.state,
  tile_idx, bank_ready, pf_busy, pf_pending, pf_target_bank,
  prefetch_engine's own state) under Verilator, printed only on
  signal-change to keep the trace readable, comparing against the
  hand-derived expected sequence of events for a 3-tile job.
VERIFICATION: hardware/v2/sim/tb_memory_manager.v -- 3/3 tests PASS
  after all three fixes, including a 5-tile job (steady-state
  double-buffer swap across more than 2 tiles) and independent
  PSRAM read-back of the written-back result byte (not just internal
  signal inspection).
STATUS: FIXED, verified end-to-end with the real (unmodified) V1
  PSRAM backend chain and a real M1 neural_processor.

ERR-0007 (Yosys usage quirk, WORKED AROUND, not an RTL bug)
DATE: 2026-09-05
MODULE: hardware/v2/synthesis/harness_dataflow_core.v (build script)
SYMPTOM: `chparam -set N_SLOTS 2 dataflow_core` (setting the parameter
  directly on the NON-top child module, before running `synth_ecp5
  -top harness_dataflow_core`) synthesizes with no visible error from
  the chparam/hierarchy commands themselves, but `synth_ecp5` then
  fails with "Module `\dataflow_core' referenced in module
  `\harness_dataflow_core' in cell `\dut' is not part of the design" --
  even though a standalone `hierarchy -top harness_dataflow_core` run
  (no synth_ecp5) with the exact same chparam succeeds.
ROOT CAUSE: harness_dataflow_core.v's own instantiation of
  dataflow_core explicitly overrides N_SLOTS via its own local
  parameter (`.N_SLOTS(N_SLOTS)`) -- chparam on the child module's
  DEFAULT is therefore always shadowed at that instantiation site
  regardless of its value, and synth_ecp5's own internal re-hierarchy
  pass (distinct from a standalone `hierarchy` call) does not
  reconcile a chparam'd-but-never-actually-used child default the
  same way, dropping the generic module reference instead.
WORKAROUND: set the parameter on the TOP module being synthesized
  instead (`chparam -set N_SLOTS 2 harness_dataflow_core`), letting
  its own instantiation forward the value down to dataflow_core as
  designed. Confirmed working for both N_SLOTS=2 and N_SLOTS=4.
STATUS: WORKED AROUND. A build-script ordering detail, not a defect in
  dataflow_core.v or harness_dataflow_core.v themselves -- noted here
  so a future N_SLOTS sweep (M9/M10) does not re-trip over it.