[Chaitanya-970]

Summary

-extra_delay had no effect on partition optimization unless guardbanding was enabled. Account for the delay of each partition boundary when calculating path costs and refinement gains.

The per-cut penalty applies only when -extra_delay is explicitly provided. Runs that omit it keep their existing behavior.

Type of Change

• Bug fix
• Documentation update

Impact

An explicit cut delay can favor fewer critical-path cuts at the cost of more cut nets. The default 1 ns delay remains in use for timing-cut statistics and the optional slack guardband.

Update gains along affected timing paths without modifying shared timing data, and document how cut delay and guardbanding interact.

Verification

• Built with Bazel; all 11 partitioner test targets pass.
• Added C++ tests for path costs, move gains, refinement, and default reporting.
• Added Tcl and Python tests for omitted, explicit 1 ns, and zero delay.
• Existing partition and Verilog tests pass with their original golden files.
• GCD and AES default partitions match the original baseline.
• Checked all six reported explicit-delay combinations and repository formatting.

Related Issues

Fixes #11982

[gemini-code-assist]

Code Review

This pull request enhances the timing-aware partitioning algorithm in the par module by integrating estimated cut delays directly into path costs and timing-cut statistics during refinement. It updates GoldenEvaluator and Refiner to dynamically compute path timing scores based on the number of cuts and the -extra_delay parameter, and adjusts neighbor-finding logic to propagate gains along timing paths. A new test suite (TestCutDelay) and integration tests are added to verify these changes. The review feedback recommends optimizing the hot path in GoldenEvaluator::GetPathTimingScore by bypassing std::pow when the timing exponent is 1.0f and using float literals to avoid implicit double promotion.

[maliberty]

Why change the default behavior?

- question (main): the default behavior changes. With the default 1e-9 extra_delay, the cut term is
  ~2x the clock period per cut on gcd, so timing completely outweighs cutsize. Total cut nets go 37 → 59 (+59%)
  on gcd and 154 → 165 on AES. Is the larger cutsize acceptable as a new default? Options:
  default -extra_delay to 0 or a fraction of the clock period, or apply the per-cut term only when
  -extra_delay is set explicitly.

[Chaitanya-970]

Why change the default behavior?

- question (main): the default behavior changes. With the default 1e-9 extra_delay, the cut term is
  ~2x the clock period per cut on gcd, so timing completely outweighs cutsize. Total cut nets go 37 → 59 (+59%)
  on gcd and 154 → 165 on AES. Is the larger cutsize acceptable as a new default? Options:
  default -extra_delay to 0 or a fraction of the clock period, or apply the per-cut term only when
  -extra_delay is set explicitly.

ahh yes, applying 1 ns to the new cost changed the partitioning too much.

i’ll apply the per-cut penalty only when -extra_delay is explicitly provided.