What do ANDR, ERI, and EWI each actually control during post-route optimization, and how do they relate to each other?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
ANDR (Auto Non-Default Rules) are non-default rules the tool creates AUTOMATICALLY during preroute and global-route optimization for timing/power -- not user-specified NDRs, tool-generated ones. ERI (enable_runtime_improvements) is a runtime-focused post-route optimization enhancement. EWI (enable_wireopt_improvements) specifically enables ANDR wire optimization and layer promotion, mostly during global-route-based optimization in clock_opt -- meaning EWI and ANDR are directly linked (EWI is what turns on ANDR's wire-optimization behavior), while ERI is a separate, runtime-oriented improvement.
Technical Explanation
- ANDR (Auto Non-Default Rules) are non-default routing rules the tool creates AUTOMATICALLY during preroute and global-route optimization for timing/power -- distinct from user-authored NDRs you'd apply manually.
- ERI (enable_runtime_improvements) is a runtime-focused enhancement to post-route optimization.
- EWI (enable_wireopt_improvements) specifically enables ANDR wire optimization and layer promotion -- mostly active during global-route-based optimization inside clock_opt.
- EWI and ANDR are directly linked: EWI is literally what turns on ANDR's wire-optimization behavior. ERI is a separate lever, focused on runtime rather than wire optimization specifically.
What To Check
- Warning sign: EWI is enabled but no measurable wire-optimization or layer-promotion effect is observed.
- Inspect: confirm the optimization in question is actually using global-route-based optimization within clock_opt -- EWI's effect is concentrated there specifically, not uniformly across every optimization stage.
- Correct: if the relevant stage isn't using global-route-based optimization, EWI genuinely has limited scope to act, regardless of being enabled.
Command Checks & Actions
enable_wireopt_improvementsEnables ANDR wire optimization and layer promotion, primarily during global-route-based optimization in clock_opt.
enable_runtime_improvementsA separate, runtime-focused post-route optimization enhancement, distinct from EWI's wire-optimization focus.
Healthy, Suspicious & Hard-stop Results
- Expected: ANDR/wire-optimization improvements from EWI are observed specifically in stages using global-route-based optimization within clock_opt, matching the documented scope.
- Investigate: EWI is enabled design-wide but shows no effect in a stage that isn't using global-route-based optimization -- expected given its documented concentration, not necessarily a misconfiguration.
- Stop: EWI and ERI are being tuned interchangeably as if they controlled the same thing -- they're genuinely separate mechanisms (wire optimization/layer promotion vs. runtime).
Common Mistake
The Trap: Treating ANDR, ERI, and EWI as three independent, unrelated settings -- EWI specifically controls ANDR's wire-optimization behavior, they aren't three separate unconnected features.
What The Interviewer Is Testing
Whether you know EWI and ANDR are directly linked (not three independent settings) and specifically where EWI's effect is concentrated in the flow (global-route-based optimization within clock_opt).
Practical Example
Debug Scenario: A team enables both ERI and EWI expecting a combined runtime-and-quality improvement, but observes wire-optimization behavior only in the clock_opt stage specifically using global-route-based optimization -- exactly matching EWI's documented scope, while ERI's runtime benefit is separate and stage-independent.
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Continue practising