cts: clock-tree synthesis performance + QoR knobs

[saurav-fermions]

Summary

Clock-tree synthesis performance improvements (bit-identical clock tree) plus two additive knobs/commands.

• TechChar incremental timing — in the characterization inner loop, switch updateTiming(true) -> updateTiming(false) so incremental delay invalidation is respected instead of forcing a full re-traversal each iteration. Bit-identical clock tree (post-CTS MD5 unchanged); TechChar self-time ~153ms -> ~61ms.
• SinkClustering matching — precompute per-point insertion delay once into a flat vector, replacing two hash-map lookups per inner iteration with two array reads (same FP addition order). Bit-identical clock tree; findBestMatching self-time -41% on an 18k-sink case.
• Benchmark harnesses — bit-identity/perf bench scripts (not registered ctest targets).
• -num_max_leaf_sinks knob on clock_tree_synthesis.
• report_clock_tree — read-only clock-tree QoR command.

Testing

Built openroad; full cts regression suite passes (57/57, incl. golden log_compare). Clock tree bit-identical to baseline for the perf changes.

Notes

• Performance changes are bit-identical; the two new commands/knobs are additive and read-only/opt-in.
• No src/sta change; no cross-repo dependency.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[arthurjolo]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new report_clock_tree command to report post-CTS QoR metrics (such as sinks, buffers, levels, wire length, latency, skew, and estimated switching power) and adds a -num_max_leaf_sinks option to control the H-tree stop criterion. It also includes performance optimizations in SinkClustering by caching sink insertion delays to avoid hash-map lookups, and in TechChar by switching to incremental timing updates. The review feedback correctly identifies a bug in the total clock power calculation when multiple clocks have different periods, where summing the load capacitances and multiplying by the minimum frequency underestimates the total power. It is recommended to calculate the power for each clock individually and sum them up directly.

[gemini-code-assist]

Calculating the total clock power by summing the load capacitances and multiplying by the minimum frequency (corresponding to std::max(totals.clock_period, report.clock_period)) leads to a significant underestimation of the total power when clocks have different periods. The total power should be the sum of the estimated powers of each individual clock. Consider adding a power field to ClockTreeReport, calculating the power for each clock during collection, and then summing them up directly (totals.power += report.power).

[arthurjolo]

Please separate this PR into 2 PRs:

1. PR with the speedup changes.
2. PR with the new tcl option to set num_max_leaf_sinks and its ok files.

There is no need to create benchmarks test for aes, gcd, array and techchar. They are already tested in CTS unity test or OR regression.

Also the report seems redundant, most of the information is already reported on during the flow, the total power estimation is also done by sta so I don't think we need to add one in CTS.

[saurav-fermions]

Thanks @arthurjolo — split as requested:

• This PR now contains only the speedups (TechChar incremental-timing update + SinkClustering per-point cache), both bit-identical.
• -num_max_leaf_sinks knob and report_clock_tree moved to a separate PR: cts: add -num_max_leaf_sinks knob and report_clock_tree QoR command #10864.
• Dropped the aes/gcd benchmark harnesses.
• Accidental src/sta bump: removed (force-pushed).

The gemini comment on the clock-power basis is addressed in #10864 (where report_clock_tree now lives): the multi-clock total now sums each clock's own C·Vdd²·f instead of aggregating capacitance under a single frequency.