Routing Dense Layouts with History-Aware Offline Reinforcement Learning using LSTM
cs.AR · cs.LG
Quick verdict
Claims LSTM-aided offline RL cuts DRVs 92% vs OpenROAD baseline on 8 Nangate45 designs; open-sourced and plausible, but no ablation isolates the LSTM's gain.
Summary
This paper targets detailed-routing convergence under high placement density, where OpenROAD's fixed cost schedules stall with persistent design rule violations (DRVs). Extending the authors' prior CQL-based offline RL cost controller — which they show degrades sharply as density rises (Figure 1) — they add LSTM heads to actor and critics (8-iteration windows), log/ratio feature transforms, and train-time Bernoulli masking of density/adjustment inputs, so the policy generalizes across densities and route-guide qualities. The policy outputs only TritonRoute's four cost multipliers per iteration, leaving the core search untouched. It was trained on ~10,000 routing runs from 8 Nangate45 designs across 6 densities and adjustment 0.0–0.3. On held-out interleaved densities (converging cases), it cuts total iterations 65→37 and runtime 10.06% versus the OpenROAD baseline (Table 2); on hard, baseline-non-converging points (adjustment 0.0, Table 3) it reduces total DRVs 15,767→1,215 (−92.29%) with 10.42% less runtime and +0.32% wirelength. Limitations: one technology node and 8 designs, all present in training; no ablation isolating the LSTM from the other additions; no variance or significance reporting despite 10-run averaging; and the prior-work comparison rests on published numbers at a single default density.
Review complete
Assessment at a glance
4
risk flags identified
● high 0
● medium 3
● low 1
5 strengths · 5 weaknesses · 5 author questions
AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- Prior single-operating-point CQL cost control [4] degrades sharply as placement density rises, while the proposed LSTM-based history-aware policy remains effective across densities (Figure 1).
- On eight Nangate45 designs at hard non-converging operating points (adjustment 0.0), the policy reduces total DRVs from 15,767 to 1,215 (−92.29%) versus the OpenROAD baseline (Table 3).
- The policy reduces runtime ~10% in both converging (−10.06%, Table 2) and non-converging (−10.42%, Table 3) regimes with only +0.32% wirelength increase.
- The method integrates into any cost-based iterative router via four cost multipliers without modifying the core search, at ~3 s inference overhead per run.
Strengths
Hard-regime evaluation with large, robust effects
Table 3 tests baseline-non-converging points (adjustment 0.0): per-design DRV cuts of 89.85–98.01% (aes 5,342→486 at density 0.74; bp_fe 6,882→542; bp_be 1,856→37), total 15,767→1,215 (−92.29%) with −10.42% runtime and only +0.32% wirelength.
Distribution-shift-aware design, tested at held-out interpolated densities
Test densities are interleaved between training values (Section 5.1); log/ratio transforms, Bernoulli masking of density/adjustment inputs (Eq. 3), and the 8-step LSTM window each target the saturation failure the authors demonstrate for the prior CQL-only policy (Figure 1).
Candid boundary reporting
Evidence-backed architecture choice
Lightweight, open integration
Weaknesses
No component ablation
No statistical dispersion or testing
Prior-work baseline not re-run
Narrow evaluation scope
Underspecified reward and action bounds
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Scope & Claims
The paper targets detailed-routing convergence in OpenROAD's TritonRoute under high placement utilization, where fixed cost schedules stall with persistent design rule violations (DRVs). Its central claims: (1) the authors' prior CQL-based offline RL cost controller [4], trained and evaluated at a single operating point, degrades sharply as placement density rises (Figure 1); (2) an LSTM-augmented policy with log/ratio feature transforms and train-time masking of density/adjustment inputs sustains convergence across densities and route-guide qualities; (3) on hard, baseline-non-converging operating points it cuts total DRVs by 92.29% (Table 3) with ~10% runtime savings in both regimes; (4) integration touches only four cost knobs (drcCost, markerCost, fixedShapeCost, markerDecay) without modifying the core search.
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 5 strengths & 5 weaknesses, analyzed in detail
- 4 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
What does this paper do?
It trains an offline reinforcement learning agent (conservative Q-learning with an LSTM) that, at each iteration of OpenROAD's detailed router, sets four cost weights to speed up convergence. Unlike a fixed cost schedule, the policy adapts to the evolving routing state of the design, which helps most when placement is dense and the router has little free track space.
How large are the improvements?
On 8 Nangate45 designs at deliberately hard operating points where the default router fails to converge (global-routing adjustment 0.0), the policy cut total design rule violations from 15,767 to 1,215 (−92.29%) while reducing runtime 10.42% and increasing wirelength only 0.32%. On easier converging cases at held-out densities it cut total iterations from 65 to 37 and runtime by 10.06%.
Is the code and data available?
The training and inference implementation is open-sourced at github.com/realise-lab/RLDRT, built on the public OpenROAD toolchain and its Nangate45 design suite; inference runs through TorchScript/LibTorch inside the C++ router. The ~10,000-run training dataset itself is not described as separately released in the paper text.
How is this different from the authors' previous RL routing paper?
Their DATE 2026 work applied CQL at a single operating point and saturated when placement density shifted. This paper adds an LSTM that conditions on recent routing history, plus log/ratio feature transforms and masking of density/adjustment inputs during training, so one policy works across multiple densities and route-guide qualities.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- Figures 1, 4, 6 and 7 are plots; only axis labels and ticks are extractable, so per-point values inside figures could not be verified numerically.
- Tables 2 and 3 are linearized in the PDF extraction; cell-to-column alignment was reconstructed from context (values are internally consistent — per-design sums match the reported totals and the abstract's 92%/10% claims).
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.