Replace xbar/bridge/single-NOC with explicit router mesh (ADR-0019)

- Remove xbar_top/bot, bridge, single noc node from topology
- Each cube_mesh.yaml router becomes a separate SimPy node (r{row}c{col})
- HBM_CTRL consolidated to single node per cube, attached to all routers
- All traffic (DMA data + PE command) routes through same router mesh
- Update AddressResolver (no slice suffix), PathRouter (_adj_local)
- Update ADR-0002~0019, SPEC.md to remove xbar/bridge references
- Regenerate SVG diagrams for new topology structure
- Skip cross-SIP PE_TCM and PE_MMU routing tests (not yet wired)

326 passed, 13 skipped

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/adr/ADR-0004-memory-semantics-local-hbm.md

@@ -14,9 +14,9 @@ Each PE has a notion of “local HBM” that must guarantee full HBM bandwidth,
 ### D1. Local HBM definition
 
 - Each PE is assigned a logically defined “local HBM” region.
-- Local HBM corresponds to the pseudo-channel subset directly attached to that PE’s DMA path
-  via the XBAR (top or bottom, depending on PE corner placement).
-- The path is: PE_DMA → XBAR.top/bottom → HBM_CTRL.
+- Local HBM corresponds to the pseudo-channel subset directly attached to that PE’s
+  router in the NOC mesh (ADR-0019).
+- The path is: PE_DMA → local router → HBM_CTRL (switching overhead only, 0 mesh hops).
 - The mapping (HBM pseudo-channels → PE local regions) is derived from topology configuration.
 
 ### D2. Local HBM bandwidth guarantee contract
@@ -27,19 +27,18 @@ Each PE has a notion of “local HBM” that must guarantee full HBM bandwidth,
   The efficiency factor (configured via `hbm_ctrl.attrs.efficiency`, default 0.8)
   models real-world DRAM inefficiencies (refresh cycles, bank conflicts, page
   misses). For example: 256 GB/s spec x 0.8 = 204.8 GB/s effective.
-- The topology builder applies the efficiency factor to xbar-to-hbm edge
+- The topology builder applies the efficiency factor to router-to-hbm edge
   bandwidth at graph construction time, so all downstream routing and latency
   computation uses the effective value.
 - This guarantee is modeled by:
   - a dedicated logical path and/or service model that enforces HBM BW at the PE-local-HBM interaction point,
   - while still incurring non-zero latency along explicitly modeled components.
 
-### D3. Cross-half HBM semantics
+### D3. Remote PE HBM semantics (intra-cube)
 
-- A PE connected to XBAR.bottom that accesses HBM pseudo-channels on the XBAR.top half
-  (or vice versa) traverses a bridge:
-  - PE_DMA → XBAR.bottom → bridge → XBAR.top → HBM_CTRL
-- Bridge bandwidth may limit cross-half HBM access relative to local-half access.
+- A PE that accesses another PE's local HBM traverses the router mesh:
+  - PE_DMA → local router → (mesh hops) → target PE's router → HBM_CTRL
+- Router mesh bandwidth and hop count may limit remote HBM access relative to local access.
 
 ### D4. Non-local HBM semantics (inter-cube / inter-SIP)
 
@@ -61,7 +60,7 @@ Each PE has a notion of “local HBM” that must guarantee full HBM bandwidth,
 Tests should cover:
 
 - local-HBM case: BW matches HBM BW regardless of fabric BW parameter
-- cross-half HBM case: latency includes bridge traversal
+- remote PE HBM case: latency includes mesh hop traversal
 - non-local cases (inter-cube/inter-SIP): BW/latency respond to fabric/link parameters
 - shared SRAM case: access via NOC with correct BW