What does enabling a trial clock tree in place_opt actually change, and why would you turn it on before CTS?

Short Answer

By default, place_opt.flow.trial_clock_tree is false and place_opt uses ideal (zero-delay) clocks throughout placement -- fast, but blind to real clock-tree insertion delay. Setting place_opt.flow.trial_clock_tree = true makes the tool build a temporary clock tree and use propagated clocks during placement instead, which is exactly what CCD needs to compute useful skew accurately during place_opt. The tradeoff is real: more accurate pre-CTS timing, at the cost of building and discarding a throwaway tree during every placement iteration.

Technical Explanation

• By default place_opt uses ideal (zero-delay, zero-skew) clocks during placement -- fast, but blind to what the real clock tree will eventually cost in insertion delay.
• place_opt.flow.trial_clock_tree = true makes the tool build a temporary clock tree and use propagated clocks during placement instead, giving timing analysis a much closer picture of post-CTS reality.
• This is a real prerequisite for CCD: useful-skew optimization in place_opt needs a trial clock tree, or optimize_icgs enabled, or accurate manually-specified ideal-clock latencies on every clock pin -- without one of those it has nothing real to compute skew adjustments from.
• During clock-gating cell optimization specifically, the tool builds a temporary clock tree and does clock-aware placement regardless of these settings -- and when trial CTS or CGC optimization is already active, the tool skips separate clock-gate-latency estimation since it already has that information.
• The cost: building and discarding a throwaway clock tree adds real runtime to every placement iteration -- accuracy versus speed, not a free upgrade.

Formula Or Decision Rule

Enable trial_clock_tree when: CCD/useful-skew accuracy during place_opt matters more than placement runtime, and you have not manually specified accurate ideal-clock latencies on every clock pin. Leave it off (default) when: placement runtime is the constraint, or manually-specified latencies are already accurate enough for CCD to work from.

What To Check

• Warning sign: post-CTS useful-skew results look nothing like what place_opt's CCD reported pre-CTS, despite CCD being enabled during placement.
• Inspect: check whether place_opt.flow.trial_clock_tree was actually true, or whether CCD was running against ideal clocks with inaccurate manually-specified latencies.
• Correct: enable trial_clock_tree (or fix the manual latencies) so pre-CTS CCD has real data to work from, and re-run.

Healthy, Suspicious & Hard-stop Results

• Expected: pre-CTS CCD results (with trial_clock_tree on) roughly track post-CTS clock_opt CCD results -- the trial tree did its job.
• Investigate: pre- and post-CTS useful-skew numbers diverge significantly -- check whether the trial tree's topology looks nothing like the real synthesized tree.
• Stop: CCD is enabled in place_opt with trial_clock_tree off and no accurate manual latencies -- that configuration has no real basis for its skew decisions and should not be trusted.

What The Interviewer Is Testing

Whether you understand that "clocks stay ideal until CTS" is a default, not a law -- and that useful-skew optimization during placement has a real data prerequisite, not just a feature flag.