Fix SpMV correctness and align RTL schedule

[n0thingNoob]

Summary

This PR fixes the VectorCGRA SpMV RTL validation so that the numerical result matches the CPU model and the steady-state schedule matches the compiler/Zeonica timing.

SpMV validation and memory layout

• Give the logical arrays distinct addresses: val=0, col=8, row=16, feature=24, and output=28.
• Patch the generated GEP base constants locally in the pytest without changing spmv.yaml.
• Replicate the input image across four physical memory banks and assign one bank to each unrolled lane.
• Configure every tile before sending launch packets, then order launches by controller-ring distance.
• Add a CPU golden model, logical-memory reconstruction, output-store monitoring, and an assertion that the measured effective II equals the compiled II.

Generator fixes

• Order constants by their first real consumption time, including invalid_iterations * II, instead of YAML/control-address order.
• Apply prologue handling to register-to-routing-crossbar paths as well as directional tile inputs.

RTL token and handshake fixes

• Gate stores with address/data predicates and keep an outstanding load from accepting a later false token.
• Preserve PHI input predicates and update PHI first-use state only on a completed handshake.
• Track GRANT_ONCE state per control slot.
• Defer constant-queue pointer advancement until the associated control step retires.
• Drain one final II after CMD_COMPLETE so post-return stores can finish.
• Preserve read-before-write data while a control step is stalled and drain unused register-routing inputs during prologue.
• Expose control-step completion to register clusters in all tile variants.

Trace support

• Record raw address interfaces and the current crossbar prologue state so load/store timing can be compared directly with Zeonica.

Root cause

The incorrect result had multiple causes: all GEP bases aliased the same memory region, constants were queued in a different order from their post-prologue consumption order, and several false/stalled tokens were retired incorrectly by the RTL.

After the numerical fixes, the measured RTL II was still 19 instead of the compiled II of 15. The four unrolled lanes were contending for the same single-port memory bank even though the compiler schedule assumed parallel accesses. Assigning one bank per lane removes that serialization.

Results

• CPU and CGRA memory contents match.
• SpMV output: [1, 4, 9, 0, 5, 12, 21, 0].
• Compiled II: 15.
• Measured RTL effective II: 15.
• Main dataflow window: Zeonica 28 cycles, RTL 28 cycles.
• First valid operation through final store: Zeonica 42 cycles, RTL 43 cycles.
• The remaining one-cycle difference is startup ring/launch skew, not a steady-state stall.

Validation

• Full SpMV RTL simulation with CPU-memory and effective-II assertions: passed.
• SpMV lane-to-bank static test: passed.
• MemUnit, PHI, Grant, constant queue, control memory, register bank, and register cluster regressions: 20 passed.
• Python compilation and git diff --check: passed.

Branch note

This is intentionally a draft. The tested local validation baseline is ahead of the current remote zeonica-bicg-validation branch, so the PR history should be cleaned up or the base branch synchronized before final review.

[n0thingNoob]

There are too many modifications in RTL files. We can review it later after the paper submission.