Re-enable CTS repair_timing on liteeth_udp_stream_sgmii once OpenROAD ODB-1200 is fixed

[mguthaus]

Summary

designs/asap7/liteeth/liteeth_udp_stream_sgmii/BUILD.bazel currently sets
SKIP_CTS_REPAIR_TIMING: "1" as a workaround for a deterministic OpenROAD
crash in the post-CTS hold-repair pass. This issue tracks removing the
workaround once upstream fixes the bug.

Workaround commit: f56a8b1 (branch liteeth).

The bug

During cts.tcl stage 4_1_cts, OpenROAD's repair_timing aborts with:

[INFO RSZ-0100] Repair move sequence: UnbufferMove SizeUpMove SwapPinsMove BufferMove CloneMove SplitLoadMove
[INFO RSZ-0098] No setup violations found
[INFO RSZ-0046] Found 347 endpoints with hold violations.
...
[ERROR ODB-1200] InsertBufferBeforeLoads: Load pin '_34829_/SN' is not connected to net '_03825_'.
Error: cts.tcl, 82 ODB-1200

Tested against OpenROAD commit 5f1bd87f37fd3c6dc83ad2195cc63b7b366771bc
(the pin introduced by bazel-orfs PR #71 in this repo).

The failure is bit-for-bit reproducible: same worst-slack endpoint
(udpcore_int_rst$_DFF_P_/D), same crash iteration, same load pin, same
net. Likely cause: the new RSZ-0100 move-sequence framework places
UnbufferMove first; on this particular netlist an unbuffer step
orphans a load pin before a subsequent InsertBufferBeforeLoads pass
tries to reference it.

Why this design only

Previously ran fine on the docker-extracted OpenROAD from ORFS image
26Q2-32-gca75a11e2. Other liteeth variants (mac_axi_mii,
mac_wb_mii, udp_raw_rgmii, udp_stream_rgmii, udp_usp_gth_sgmii)
pass on the same new OpenROAD — the udp_stream_sgmii combination of
1000 ps clock + 40 % util + 0.3 density + 5x5 macro halo + flat synth
is the specific case that steers the deterministic move sequence into
the buggy iteration. See conversation thread for detailed diagnosis.

Things that did NOT work (for the record)

• set_dont_touch [get_nets -hierarchical *udpcore_int_rst*] — net
  name doesn't survive Yosys flat-synth; no-op, same crash.
• set_false_path -from [get_ports sys_reset] +
  set_false_path -through on reset candidates — STA hold-endpoint
  count only dropped 347 → 346. The 346 other violations are datapath,
  not reset. Same crash net.

Only SKIP_CTS_REPAIR_TIMING=1 bypasses the bug. GRT and detailed
route still perform their own hold-repair passes, so final QoR is
still reasonable (41 % util, 14886 µm² on asap7, clean 6_final).

To re-enable

1. Confirm upstream OpenROAD has fixed the InsertBufferBeforeLoads /
   UnbufferMove interaction. Candidate filter:
   git log OpenROAD/src/rsz | grep -iE 'InsertBufferBeforeLoads|UnbufferMove'
2. Bump bazel-orfs submodule and the OpenROAD pin in MODULE.bazel.
3. Remove SKIP_CTS_REPAIR_TIMING and its comment block from
   designs/asap7/liteeth/liteeth_udp_stream_sgmii/BUILD.bazel.
4. Run bazel build //designs/asap7/liteeth/liteeth_udp_stream_sgmii:liteeth_udp_stream_sgmii_final
   and verify cts.tcl completes without the ODB-1200 error.

Upstream issue

Not yet filed against The-OpenROAD-Project/OpenROAD. Worth doing once
we can produce a minimized testcase — the current repro requires the
full liteeth UDP SGMII netlist + this specific placement.