ExpertQuestion 287 of 111Source PDF page undefined

How does the ML-based global-route optimization flow actually improve preroute/postroute timing correlation for clock trees, and what has to stay constant across iterations?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

For designs with poor preroute/postroute timing correlation, ML collects Features (inputs) and Labels (predicted outputs, e.g. real post-route delay) from detail routing to train a Model relating them. Iteration N trains the model (est_delay.ml_delay_gre_mode = feature, then estimate_delay -train_model after detail routing); iteration N+1 uses it (est_delay.ml_delay_gre_mode = enable). The hard requirement: the same active scenarios must be used at each step and iteration, and the model must be re-created if the design, environment, or flow changes -- a stale model silently mispredicts.

Technical Reference DiagramHow does the ML-based global-route optimization flow actually improve preroute/postroute timing correlation for clock trees, and what has to stay constant across iterations?
How does the ML-based global-route optimization flow actually improve preroute/postroute timing correlation for clock trees, and what has to stay constant across iterations?, illustrating the physical design concept.

Technical Explanation

  • ML terms: Labels are the predicted outputs (e.g. real post-route delay), Features are the inputs, Model is the learned feature-to-label relationship, and Training is the process of fitting that model.
  • Iteration N trains the model: set est_delay.ml_delay_gre_mode to feature, run clock_opt -from final_opt, detail-route, then run estimate_delay -training_labels and -train_model to fit the model from what detail routing actually produced.
  • Iteration N+1 uses the trained model: set est_delay.ml_delay_gre_mode to enable, run clock_opt -from final_opto -- now using the model's predictions instead of the default estimation.
  • Hard requirement: the SAME active scenarios must be used at each step and iteration -- a model trained under one scenario set and applied under a different one is not a valid application of what it learned.
  • The model must be re-created if the design, environment, or flow changes -- it's not a general-purpose model, it's fit to this specific design's routing behavior at this specific point in the flow.

Formula Or Decision Rule

Iteration N (train): set gre_mode=feature, clock_opt -from final_opt, detail route, then estimate_delay -training_labels / -train_model. Iteration N+1 (use): set gre_mode=enable, clock_opt -from final_opto.

What To Check

  • Warning sign: post-route timing correlation with an ML-assisted preroute estimate looks noticeably worse than a prior iteration using what should be the same trained model.
  • Inspect: check whether the active scenario set changed between training and this application, or whether the design/environment/flow changed since the model was trained.
  • Correct: re-train the model under the current scenario set and design state rather than continuing to apply a now-stale model.

Command Checks & Actions

ICC2set_application_option -name est_delay.ml_delay_gre_mode -value feature

Iteration N, collecting training features.

ICC2estimate_delay -train_model "features_1 label_1" -output_dir ./ML

Trains the model after detail routing produces real labels.

ICC2set_application_option -name est_delay.ml_delay_gre_mode -value enable

Iteration N+1, applying the trained model.

ICC2estimate_delay -disable_model -output_dir ./ML

Disables the model when it's known to be stale.

Healthy, Suspicious & Hard-stop Results

  • Expected: preroute/postroute correlation measurably improves when applying a model trained under the same active scenarios and design state it's being applied to.
  • Investigate: correlation degrades between iterations using what should be the same model -- check for a scenario-set change or an unacknowledged design/environment/flow change since training.
  • Stop: a trained model continues to be applied after a known design or flow change with no re-training -- disable it (estimate_delay -disable_model) rather than trust predictions from a model fit to a design state that no longer exists.

Common Mistake

The Trap: Reusing a trained ML delay model after the design, environment, or flow has changed, or applying it under a different active-scenario set than it was trained on -- both silently invalidate the model's predictions without necessarily producing an obvious error.

What The Interviewer Is Testing

Whether you know the precise train/apply cycle (feature mode then enable mode) and the hard constancy requirements (same scenarios, re-train on design/environment/flow change), not just that "ML helps correlation."

Practical Example

Debug Scenario: An ML-assisted clock_opt run shows worse preroute/postroute correlation than the previous iteration that used what was assumed to be the same trained model. Checking the flow, the active scenario set had been expanded since training -- the model, trained under the narrower scenario set, was being applied outside the conditions it actually learned from.

Physical Design & Planning Handbook

Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.

Explore Design Planning Guide →

Continue practising

Related PnR (Place & Route) questions

ExpertWhat is CCD (Concurrent Clock and Data optimization), and what does it actually change in the clock tree?IntermediateWhat's the difference between route_opt and hyper_route_opt, and what does Targeted Endpoint Optimization actually let you do?ExpertWhat problem do via ladders actually solve on a clock tree, and where does insert_via_ladders fit in the clock_opt flow?ExpertWhat extra steps does multi-level physical hierarchy (MLPH) clock driver insertion need beyond the normal create_clock_drivers flow?