feat(v2): M2 Neural Processor Array, N_PROCESSORS resource sweep

Implements M2 of the V2 roadmap: neural_processor_array.v instantiates
N_PROCESSORS independent neural_processor (M1) units, each with its
own dedicated point-to-point job/operand/result interface -- no shared
bus or mux at this level (arbitration is explicitly the Neural
Director's job, M5).

Verified with Verilator (tb_neural_processor_array.v, N_PROCESSORS=4):
7/7 tests pass, including a same-cycle 4-way concurrent launch with
different tile counts and a staggered-start test where a
later-launched, shorter job completes before an earlier-launched,
longer one -- confirming genuine independent concurrent execution
(§18/§34: a blocked/busy processor must not block the others).

Real resource/timing sweep for N_PROCESSORS in {1,2,4,8} (Yosys +
nextpnr-ecp5, real place&route): Fmax stays above the 80MHz target
throughout (159.11 -> 134.70 MHz), but MULT18X18D usage scales
linearly and reaches 88% of the LFE5U-45F's 72 DSPs at N=8 while
LUT/FF stay under 6% -- DSP, not LUT/FF/routing, is the first hard
ceiling on N_PROCESSORS at P_IN=8 (decisions.log DEC-0005). Measured
via a dedicated synthesis-only timing harness after the array's wide
per-processor buses were found to exhaust the device's TRELLIS_IO pin
budget as a bare top-level module beyond N=1 (errors.log ERR-0005) --
not a logic limit, an artifact of testing the array in isolation
before the Memory Manager/Director (M4/M5) exist to consume those
ports on-chip.

Full log trail (development/experiments/errors/decisions/simulation/
synthesis/timing/benchmark.log) in hardware/v2/logs/ per the project's
logging mandate.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v

hardware/v2/logs/decisions.log

@@ -201,3 +201,50 @@ resolved by picking whichever answer looks more convenient.
 
 STATUS:
 ACCEPTED
+
+---
+
+DEC-0005
+
+DATE: 2026-09-05
+
+DECISION:
+Treat DSP (MULT18X18D) budget, not LUT/FF/routing, as the primary
+constraint when exploring the N_PROCESSORS x P_IN trade-off space
+(§16) going forward.
+
+WHY:
+Real place&route measurement (EXP-0003) shows MULT18X18D usage
+scaling linearly and reaching 88% of the LFE5U-45F-8BG381's 72 total
+DSPs at N_PROCESSORS=8, P_IN=8 -- while LUT4/FF usage stays under 6%
+at the SAME configuration and Fmax is still comfortably above the
+80MHz target (134.70 MHz). This means the naive "just add more
+processors" scaling (§8/§16) hits a hard DSP ceiling around
+N_PROCESSORS=9 at P_IN=8, long before LUT/FF/routing/timing become
+relevant -- the opposite of what LUT/FF utilization alone would
+suggest if read in isolation.
+
+EVIDENCE:
+experiments.log EXP-0003 -- MULT18X18D 8/16/32/64 (11%/22%/44%/88% of
+72) at N_PROCESSORS 1/2/4/8, LUT4 under 6% throughout, Fmax PASS at
+80MHz throughout (159.11/149.59/151.01/134.70 MHz).
+
+ALTERNATIVES:
+Assume LUT/FF/routing congestion would be the limiting factor (the
+naive expectation for "more parallel copies of a datapath"). Rejected
+by direct measurement, not assumed -- §16 explicitly requires
+choosing the final configuration "sulla base del throughput effettivo
+... non dell'utilizzo massimo delle risorse", and knowing WHICH
+resource binds first is a prerequisite for that.
+
+RESULT:
+Future N_PROCESSORS x P_IN sweeps (§16, deferred to a dedicated
+scripts/sweep/ run per §31) should budget MULT18X18D count explicitly
+(N_PROCESSORS * P_IN <= ~72, minus whatever the rest of the real
+system needs once M4/PSRAM integration lands) rather than only
+tracking LUT/FF. A smaller P_IN with more N_PROCESSORS (or vice versa)
+is a live trade-off worth exploring precisely because of this ceiling,
+not merely a stylistic choice.
+
+STATUS:
+ACCEPTED