cnn-asap7: setup timing regression on bazel-orfs 553c1c3 (WNS +122 → −3502 ps)

[mguthaus]

Summary

On the 2026-06 toolchain upgrade (bazel-orfs 553c1c3 / OpenROAD 299f3015 / OpenSTA 8575070 / yosys 0.64), cnn-asap7 still reaches 6_final but its setup timing regressed well beyond the ~5% tolerance:

Metric	Pre-upgrade baseline	Upgraded tools (current)
Setup WNS	+122 ps	−3502 ps
CORE_UTILIZATION	60	45
PLACE_DENSITY	0.40	0.50
util (achieved)	—	45.5%
comb cells (class:multi_input_combinational_cell)	—	105 984

The design finishes (6_final.odb builds, routes clean), but it is a flagged QoR regression — setup-negative where it used to close.

What was tried (flow knobs only — RTL/SDC are off-limits for the upgrade)

The original config (CORE_UTILIZATION=60, repair-timing skipped via the old ODB-1200 SKIP_*_REPAIR) GRT-hangs on the new global router. util=50 routes but with a buffer explosion (WNS −9088 ps, ~436 k cells).

A k8s parameter sweep (util × density × halo × routing-adjustment × repair-on) ranked:

util45-repair  −3502 ps   <- best, committed (e4)
util55-repair  −3790 ps
util60-repair  −4585 ps
util50-skips   −5208 ps

The ODB-1200 family SKIP_*_REPAIR flags were removed — the new resizer's repair_timing converges on this design, so repair-ON is strictly better than skipping.

A follow-up explicit-die sweep (DIE_AREA 2400/2800/3200 µm², density 0.45/0.40/0.35, halo 20/30/40, repair-ON) — the fix that fully recovered cnn-nangate45 (−60 ps) and cnn-sky130hd (+770 ps) — was inconclusive on asap7: all three variants routed to 6_final, but produced no WNS improvement over e4. asap7's regression is buffer / SRAM-access-path bound, not the RTLMP-packing / GRT-congestion that a bigger die cured on n45/sky, so more die area does not help.

Root cause (working theory)

The worst paths are SRAM-read-bound, single-cycle paths through the four fakeram_w16_l32768 macros (65 SRAM instances total). The new RTLMP macro placement + the new router/resizer lengthen these macro-to-capture-flop paths relative to the old tools. No flow-knob combination (util, density, halo, macro-blockage, die area, repair sequence) recovered the path delay.

Why it's not recoverable within upgrade scope

Closing this needs either an RTL pipeline stage on the SRAM-read path or a looser clock period — both modify RTL/SDC, which is explicitly out of scope for the toolchain upgrade. Logged here so it isn't lost.

Committed config (final answer)

designs/asap7/cnn/BUILD.bazel: CORE_UTILIZATION=45, PLACE_DENSITY=0.50, MACRO_PLACE_HALO=12 12, SYNTH_HIERARCHICAL=1, repair-ON. Reaches _final at WNS −3502 ps. Final run done locally to populate the disk cache.

See designs/src/cnn/DECISIONS.md (asap7 section) for the full sweep history.

Comparison: same regression on other cnn platforms was recoverable

• cnn-nangate45: DIE_AREA=7000×7000, density 0.45, halo 50 → WNS −60 ps (≈ baseline). Recovered.
• cnn-sky130hd: DIE_AREA=8000×8000, density 0.35, halo 80 → WNS +770 ps. Recovered.
• cnn-asap7: bigger die does not help (different failure mode). Flagged.