What's the actual difference between GRLB and RDE for preroute parasitic estimation, and when does each apply?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
GRLB (Global-Route-Layer-Based) improves preroute/postroute correlation, controlled by opt.common.use_route_aware_estimation -- auto (enabled only when per-unit resistance varies across layers), true (always), or a command to remove all global-route-based estimation before routing. RDE (Route-Driven Estimation) performs actual global routing plus extraction from those routes, auto-enabled for technologies below 16nm (otherwise opt.common.enable_rde must be set). Critically, when RDE is enabled, the GRLB setting is IGNORED -- they aren't both active at once.
Technical Explanation
- GRLB (Global-Route-Layer-Based) estimation improves preroute/postroute correlation, controlled by opt.common.use_route_aware_estimation: auto (enabled only when per-unit resistance varies across layers), true (always enabled), or a command to remove all global-route-based estimation before routing.
- RDE (Route-Driven Estimation) is a heavier technique: it performs actual global routing plus extraction from those real global routes, rather than estimating from layer resistance alone.
- RDE is auto-enabled for technologies BELOW 16nm; for other technologies, opt.common.enable_rde must be explicitly set to true.
- Critically: when RDE is enabled, the GRLB setting (opt.common.use_route_aware_estimation) is IGNORED entirely -- the two techniques are not both active simultaneously, RDE supersedes GRLB when both could apply.
- RDE is applied during the final_opt stage of place_opt/clock_opt, and its parasitics are stored in the design library and reused -- it honors the -early_cap_scale/-late_cap_scale/-early_res_scale/-late_res_scale options of set_extraction_options.
- Both are applied via
set_app_options -name opt.common.use_route_aware_estimation -value auto(GRLB) andset_app_options -name opt.common.enable_rde -value true(RDE) -- the option names alone don't take effect without the real command wrapping them.
Common Mistake
The Trap: Assuming GRLB and RDE settings combine or stack -- when RDE is enabled, GRLB's setting is explicitly ignored, not layered on top of it.
Follow-up Question & Model Response
"Why would RDE be auto-enabled specifically below 16nm rather than at every process node uniformly?"
Candidate Model Response: Because parasitic effects (resistance, coupling) become proportionally more significant relative to intrinsic gate delay as process nodes shrink -- below 16nm, the accuracy gap between a layer-resistance-based estimate (GRLB) and actual global-route-derived extraction (RDE) becomes large enough that the heavier RDE technique is worth its extra cost by default, while at larger, less parasitic-dominated nodes GRLB's lighter estimate remains adequate.
Practical Example
Debug Scenario: A design on a 7nm process shows RDE auto-enabled, and a GRLB setting configured earlier in the flow script has no observable effect -- expected, since RDE being active means the GRLB setting is documented to be ignored entirely at that point.
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