Better chip-wide clock (low-skew mesh / multi-source CTS) — BLOCKED on OpenROAD upstream

[npip99]

Goal

A proper low-skew, low-insertion chip-wide clock for the full design — the kind a real GPU uses (clock mesh or multi-source/multi-driver CTS), targeting insertion ≤ ~1 ns and skew ~100 ps across the die. This is the long-term "do it right" clock, distinct from the per-array workaround.

Status: BLOCKED on OpenROAD upstream

A true clock mesh is not buildable in OpenROAD today — STA can't time a multi-driver shorted net, and TritonCTS only builds loop-free trees. Tracked upstream at OpenROAD#2202 (open/unbuilt, confirmed by the OpenROAD lead). Until that lands, the mesh path is closed to us regardless of effort.

What we already learned (don't re-litigate)

• Mesh: unbuildable in OpenROAD (above).
• Balanced top-metal (M8/M9) tree — the achievable in-tool alternative — was prototyped and regressed: 3.4 → 4.0 ns insertion, 998 → 1525 ps skew (worse than today). See closed PR #33: implementation plan — top-metal clock infrastructure #37 / closed Top-metal clock mesh / multi-source CTS — chip-wide infrastructure clock #33.
• Directional clock-feedthrough (Full 32×32 compute_array abutment: re-harden cmd_unit + skew_lanes as abutment-ready tiles #40) is the workaround for the systolic array specifically: ~440 ps insertion measured (V1), skew is directional and co-travels with the data. It does not give a general low-skew clock — it concentrates skew at the array output boundary (handled by the Full 32×32 compute_array abutment: re-harden cmd_unit + skew_lanes as abutment-ready tiles #40 V2 deskew). So Full 32×32 compute_array abutment: re-harden cmd_unit + skew_lanes as abutment-ready tiles #40 unblocks the array, not the chip.

Scope of THIS issue (what #40 does not cover)

A genuine low-skew clock for the non-array blocks and chip top (smem, cmdproc, store, and any block where a traveling clock isn't a fit) + the eventual unified chip clock. This is where a mesh / multi-source CTS would actually be needed and where we're upstream-blocked.

Unblock paths (in priority order)

1. OpenROAD#2202 lands (multi-driver clock STA / mesh support) — then revisit the mesh.
2. Port to a PDK + commercial CTS (Calibre/Tempus/ICC2 territory) that supports mesh sign-off — PDK-swap-time, aligns with the other PDK-swap blockers (Density fill insertion methodology (PDK-swap-time blocker) #18, IO pad ring / chip-pad placement (PDK-swap-time blocker) #19).
3. Multi-source CTS via a hand-built balanced spine if a future OpenROAD release adds partial support short of full mesh.

Acceptance

• Either OpenROAD#2202 (or equivalent) is available and a mesh/multi-source clock signs off with insertion ≤ ~1 ns and skew ~100 ps, OR
• the design moves to a flow whose CTS supports it, OR
• it's explicitly decided the Full 32×32 compute_array abutment: re-harden cmd_unit + skew_lanes as abutment-ready tiles #40 feedthrough (array) + a simple tree (small non-array blocks) is sufficient and this is closed as won't-need.

Related

• Upstream blocker: OpenROAD#2202
• Superseded prior attempts: Top-metal clock mesh / multi-source CTS — chip-wide infrastructure clock #33 (closed), PR #33: implementation plan — top-metal clock infrastructure #37 (closed — tree regressed)
• Array workaround (not a substitute): Full 32×32 compute_array abutment: re-harden cmd_unit + skew_lanes as abutment-ready tiles #40
• PDK-swap-time siblings: Density fill insertion methodology (PDK-swap-time blocker) #18, IO pad ring / chip-pad placement (PDK-swap-time blocker) #19