chore: remove root-level V1 duplicates, superseded by hardware/v1/ freeze

hardware/v1/ was created (dc0b331) as a frozen snapshot of the V1
project that then lived at the repo root (rtl/, sim/, synth/, tools/,
docs/). Root received zero further commits to those files after the
freeze -- confirmed byte-identical to the hardware/v1/ copy for every
file removed here. Root was the "before", hardware/v1/ is the
curated, canonical "after".

Removed (all verified exact-hash duplicates of hardware/v1/ content):
  - rtl/ (20 files, 100% covered by hardware/v1/rtl/)
  - tools/{netasm,pinout,run_regression.py,flash_catalog,validation,
    fpga_benchmark.py} (19 files, 100% covered by hardware/v1/tools/;
    tools/neural_sim/ kept -- unique, post-freeze, no counterpart)
  - sim/*.v (47 testbenches, 100% covered by hardware/v1/sim/; the
    ~38 remaining sim/ entries are compiled binaries and .vcd
    waveform dumps, left as a separate cleanup decision)
  - synth/ecp5/{p2,p4,p8,post_fix_verify} (25 files, exact duplicates
    of hardware/v1/synthesis/; the other ~84 synth/ecp5/* experiment
    build directories are historical artifacts never carried into the
    freeze, left as a separate decision)
  - WORKLOG.md (duplicate of hardware/v1/docs/WORKLOG.md)
  - docs/{FPGA-Neural-Datapatch-Benchmark,FPGA-Neural-Hardware-Design,
    FPGA-NeuralNetwork-Engine}.md, docs/validation/*.md (18 files),
    docs/FPGA-Neural-Datasheet-{EN,IT}.pdf -- all exact duplicates of
    hardware/v1/docs/ content
  - hardware/v1/docs/DatasheetLatex/ (24 files) -- exact duplicate of
    hardware/v2/docs/datasheet/files/docs/datasheet/en/ (discovered
    during this audit; not the same DatasheetLatex already removed
    from hardware/v2/docs/ in an earlier commit)

Moved (genuine, unique, post-freeze V2 content -- not duplicated
anywhere, just living in the wrong/legacy root docs/ location):
  - docs/architecture/*.md -> hardware/v2/docs/architecture/
  - docs/pinouts.md, docs/FPGA_NEURAL_V2_DATASHEET.md,
    docs/FPGA_NEURAL_V2_SCHEMATIC.md,
    docs/FPGA-Neural-V2-Datasheet-EN.pdf -> hardware/v2/docs/

Left untouched (separate decisions, not part of this cleanup):
  - docs/FPGA-Neural-Flash-Subsystem-Verification.md, docs/
    v2-description.md -- orphaned root-only content, no duplicate
    found anywhere, but also not part of the reviewed plan
  - synth/ecp5/* experiment dirs and sim/*_sim + sim/*.vcd build
    artifacts -- not literal duplicates, flagged as candidates for a
    future, separate cleanup pass

Verified no functional breakage: grepped all remaining scripts/docs
for references to every removed path -- only prose/comment mentions
found, no executable imports or build-script paths broken.

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

hardware/v2/docs/architecture/neural_processor_batch.md

@@ -0,0 +1,122 @@
+# NMS Continuous Tile Stream — Memory Manager Redesign (STEP13)
+
+Status: implemented, bit-exact verified, synthesized. **Adopted** as
+the new reference NMS memory-manager configuration (DEC-0025). Full
+data: `hardware/v2/nms/reports/batch_processor_{sweep.csv,summary.md}`.
+Full narrative: `hardware/v2/logs/experiments.log` (EXP-0025 through
+EXP-0028), `decisions.log` (DEC-0024, DEC-0025).
+
+## Why this file is not `neural_processor_batch.v`
+
+The governing brief for this STEP asked for a "batch/continuous
+neuron execution model" — multiple neurons processed per dispatch, or
+a continuous neuron stream — to amortize the ~68.5-cycles/neuron
+non-memory floor found in EXP-0024. Before writing any RTL, Step 1
+required tracing the actual RTL to find exactly where those cycles
+go, rather than assuming.
+
+That trace (EXP-0025, an isolated testbench with `neural_processor.v`
++ `nms_memory_manager_pf.v` driven with zero real memory latency
+anywhere) found: **93.4% of the floor is explained by a 4-cycles/tile
+serialization bug inside the memory manager's own `ST_RUN` state**,
+not by per-job dispatch overhead (only 6.6%). `ST_RUN` implements
+operand delivery as a strictly sequential chain —
+`read_issued → read_ready → present → consumed` — with zero overlap
+between consecutive tiles, even though:
+
+- the local activation/weight SRAMs (`nms_activation_replicated.v`,
+  `nms_weight_packed.v`) have only a 1-cycle `rd_en`-to-data latency;
+- `neural_processor.v`'s own `operand_ready` is held continuously high
+  through the whole tile-loading phase — its datapath is explicitly
+  designed (per its own header comment) to accept a new tile every
+  cycle while previous tiles drain through the adder tree/accumulator.
+
+Neither side of this interface requires 4 cycles/tile. It is purely
+an artifact of the memory manager's own un-pipelined FSM. **The fix is
+therefore a continuous per-tile streaming redesign of the memory
+manager, not a neuron-batching scheme — hence
+`nms_memory_manager_stream.v`, not `neural_processor_batch.v`.**
+`neural_processor.v` itself required no modification.
+
+## Design: `nms_memory_manager_stream.v`
+
+Drop-in replacement for `nms_memory_manager_pf.v` (identical external
+interface, same `weight_prefetch_engine.v` instance, same outer job
+FSM `ST_IDLE`/`ST_WAIT_RESULT`/`ST_WRITE_RES`/`ST_DONE`). Only
+`ST_RUN`'s internal operand-delivery logic differs:
+
+- `rd_ptr` — the read-**issue** pointer (which tile's SRAM read has
+  been, or is about to be, issued), independent of and normally one
+  tile ahead of `tile_idx` (the **consumption** pointer, i.e. how many
+  tiles `neural_processor.v` has actually accepted).
+- A 1-deep skid buffer (`buf_valid`/`buf_input`/`buf_weight`/
+  `buf_last`) holds one tile's fully-read SRAM data, presented to NP
+  as `operand_valid`/`input_data`/`weight_data`/`tile_last`.
+- Every cycle: if a read issued last cycle is landing now (1-cycle
+  SRAM latency), it's captured into the skid buffer; independently, a
+  new read is issued for `rd_ptr` whenever legal (in bounds, weight +
+  activation ready) **and** the buffer will not overflow (empty, or
+  being drained this same cycle).
+
+Since `operand_ready` stays high throughout the tile-loading phase,
+the skid buffer drains every cycle it's full, so a new read can be
+issued every cycle too — sustained ~1 cycle/tile, down from 4.
+
+`tile_idx` (the consumption pointer) is still what feeds
+`weight_prefetch_engine.v`'s own `consumed_count` port — its external
+contract is unchanged; only the local SRAM read-issue pointer
+(`rd_ptr`) is new, and it can run up to one tile ahead of `tile_idx`
+(the skid buffer's own depth).
+
+## Verification chain (all real, none assumed)
+
+1. **EXP-0025**: isolated zero-latency trace of the *old* design —
+   established the 4-cycles/tile floor and its 93.4% share of
+   EXP-0024's real measured floor.
+2. **EXP-0026**: same isolated trace against the *new* design — the
+   fix works exactly as designed (confirmed cycle-by-cycle), but
+   total cycles barely move (81→80), because it immediately hits a
+   *second*, previously-masked bottleneck: `weight_prefetch_engine.v`'s
+   own word-fetch rate is *also* exactly 4 cycles/tile (P_IN=8 bytes ÷
+   16-bit bus = 4 word-transactions, 1 cycle/word minimum even at
+   zero real latency) — a bus-**width** ceiling, structurally
+   different from an FSM-serialization ceiling, that happens to
+   coincide numerically today.
+3. **EXP-0027**: a direct control experiment — a scratch variant with
+   weight-fetch bypassed (always-ready) isolates the new design's
+   *own* ceiling: a clean 1 cycle/tile (100% of `neural_processor.v`'s
+   theoretical per-tile rate), vs. the old design's hard 4-cycles/tile
+   cap under the identical bypass. This is the direct proof that the
+   fix removes a real, 4× architectural ceiling — it was just masked
+   by a coincidentally-equal second bottleneck.
+4. **EXP-0028**: full real-system integration
+   (`nms_dataflow_core_stream.v` → `nms_neural_multiprocessor_stream.v`,
+   real V1 PSRAM chain) — bit-exact PASS, 256/256 neurons, D-Stress
+   workload identical to EXP-0022/0024. Real cycle count: 185270 vs.
+   185398 (`_pf` baseline), -0.07% — confirms the "masked, zero net
+   benefit today" prediction exactly. Real synthesis + P&R: N=1
+   Fmax=142.92 MHz (+3.7% vs. baseline), N=2 Fmax=92.57 MHz (-2.8%,
+   still comfortably above 80 MHz), resource cost within ±6%. N=4:
+   55.22 MHz, FAILS 80 MHz — but for the *pre-existing*,
+   already-documented `nms_activation_fill_ctrl.v` priority-scan
+   regression (EXP-0022), unrelated to and unaffected by this fix.
+
+## Outcome and adoption
+
+**Outcome B** (helps, but another bottleneck appears — see
+DEC-0025 and `batch_processor_summary.md` for the full nine-question
+final decision). `nms_memory_manager_stream.v` is adopted as the new
+reference configuration: it is a strict improvement (bit-exact,
+resource-neutral, no measured downside) and is **required groundwork**
+for any future PSRAM bandwidth increase to actually translate into a
+throughput gain — without it, a wider/faster memory would immediately
+hit the old FSM's 4-cycles/tile ceiling and realize only 25% of its
+potential benefit. The original `nms_memory_manager.v` and
+`nms_memory_manager_pf.v` remain preserved, unmodified, for A/B/C
+reference. Neuron-batching (the brief's original Model B/C) was not
+pursued — evidence showed it addresses only 6.6% of the real floor and
+would deliver no measurable benefit today for the identical reason
+(weight-fetch-rate-bound). N=4/N=8 viability remains blocked by two
+independent issues neither addressed by this STEP: external PSRAM
+bandwidth, and the activation fill controller's own Fmax regression —
+both flagged as future work.