ExpertQuestion 85 of 161

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, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of 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.

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 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?

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?

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.

PnR Flow Mentor Guide

Master the Physical Design Implementation Flow

Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.

Explore PnR Flow Mentor Guide →

Offline PDF Bundle