Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

EvoDRC: A Self-Evolving Agentic Framework for Automated DRC Violation Repair

T0 review · 4 major / 4 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Residual chip design-rule violations can be repaired by an LLM agent loop that decomposes the layout, repairs each region in parallel, and evolves layer-specific skill files from recorded outcomes, cutting violations by 73.5% on seven bench

desk verdict EvoDRC is a real engineering contribution to block-level DRC repair, but the headline 73.5% number needs a defined baseline and LVS-level verification before you trust it. read the letter →

arxiv 2607.20019 v1 pith:5ITIHGG6 submitted 2026-07-22 cs.AI

Bing-Yue Wu , Chia-Tung Ho , Haoyu Yang , Brucek Khailany , Vidya A. Chhabria This is my paper
classification cs.AI
keywords designrulecheckingDRCrepairLLMagentsskillevolutionlayoutdecompositionphysicalECOautomationconnectivityverification
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

EvoDRC is an attempt to automate the last manual bottleneck in chip physical design: fixing residual design rule violations (DRVs) after routing. The paper claims that a loop of LLM agents can do what a layout engineer does—inspect each violation in context, propose a geometric edit, check that it does not break connectivity, and learn from the outcome—provided the layout is split into bounded crops and each agent is guided by layer-specific skill files. The skill files start as knowledge distilled from an unrelated, smaller reference design, then evolve as verified repair operation–result pairs accumulate in a knowledge database. On seven block-level benchmark layouts, the authors report a 73.5% overall DRV reduction (83.6% average per block), with two blocks fully cleaned. The practical stake is large: if the claim holds, days of manual engineering change order iterations can be replaced by a few agent runs at API cost, with every learned repair skill traceable to a recorded experiment.

What carries the argument

The load-bearing piece is the layer-wise skill file combined with the Knowledge DB. A skill file is the prompt-level repair manual for one metal or via layer—it contains the DRC deck for that layer plus distilled repair knowledge—and it is what the repair agent actually consults. Two evolution agents, a Skill Refiner and a DB Summarizer, produce candidate updates from the recorded operation–result history; scripted checks enforce that every assertive claim cites a stored repair record, and a Skill Judge picks the replacement. Around this loop sits the layout decomposition: first-order crops are built from DRV bounding boxes, merged when overlapping, and unioned within cell-height rows, givin

What would settle it

Run EvoDRC on a benchmark block, take its final repaired layout, and run a sign-off design-rule deck and a full layout-versus-schematic (LVS) check on it. If the LVS run reports opens, shorts, missing vias, or disconnected pins that the paper's connectivity check did not flag, then the accepted repairs are not guaranteed to preserve circuit logic, and the 'repair' claim fails. A more targeted probe: deliberately insert a repair that is geometrically legal but electrically wrong, and check whether the framework's connectivity check accepts it.

Watch

Extended reading notes

Core claim

The central claim is that agentic DRC repair at block scale is not limited by the reasoning power of the LLM but by how repair knowledge is organized and transferred. EvoDRC's discovery, in the paper's own framing, is that decomposing the layout into bounded repair regions, letting one LLM agent own each region, and continuously rewriting layer-wise skill files from recorded outcomes turns an intractable whole-chip repair problem into many tractable local ones. The paper identifies three mechanisms as jointly responsible: layout decomposition provides coverage and parallelization; skills distilled from an unrelated smaller design transfer repair knowledge across designs; and skill evolution

Load-bearing premise

The framework trusts that its connectivity check—a depth-first search over the merged metal–via stack that verifies each standard-cell pin still reaches its expected pins—is enough to guarantee that an accepted repair does not break the circuit, so if that proxy misses an open or short, a layout with fewer reported violations could actually be broken.

Editorial extensions

If this is right

  • Post-route DRV repair can be treated as a skill-evolution problem rather than a one-shot generation problem: the same agent code with an evolving skill file improves over iterations.
  • Repair knowledge is transferable: a small, unrelated design's repair history can seed skills for larger target blocks, reducing the need to start from scratch on each new layout.
  • Decomposition into bounded crops is what makes block-scale agentic repair feasible; without it, coverage collapses on the largest block (81 vs. 490 DRVs removed).
  • Recording both successful and unsuccessful repair operations, including ones that temporarily increase DRVs, enables later coordinated repairs and recovery within two iterations.
  • Because every skill statement must cite a stored repair record, the framework produces an auditable trail from each repair suggestion back to a concrete measured outcome.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the connectivity proxy were upgraded from the reachability search to a real layout-versus-schematic-style check, the same architecture would likely serve as a nearly drop-in automated ECO repair stage, since the rest of the loop is agnostic to the verifier.
  • The skill-evolution loop is effectively a tiny memory system for an LLM: raw experience is compiled into compact, citation-backed rules. A testable extension is seeding it from design-rule manuals, prior ECO logs, or multiple reference designs instead of a single one, which could reduce the number of iterations needed.
  • The reported gains are DRV-count reductions, not electrical-cleanliness guarantees; an obvious next experiment is running full sign-off verification (DRC plus LVS) on the repaired layouts, and also measuring effects on wirelength, timing, and congestion, before calling the result 'repaired' in the engineering sense.
  • The winner dynamics (the reconstructing summarizer dominates the first iteration, the incremental refiner later) suggest a cheap optimization: schedule reconstructive summarization early and incremental refinement later, potentially cutting the roughly 5–6% of total cost spent on skill evolution.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. EvoDRC is a framework for block-level post-route DRC repair. It decomposes a layout into bounded crops, assigns each crop to an LLM ReAct repair agent, and provides local DRC analysis, a connectivity check, and an impact preview tool. Proposed repairs are accepted only if they pass the full-design connectivity check; the resulting operation/local-DRV records are stored in a Knowledge DB. Two agents (Skill Refiner and DB Summarizer) generate per-layer skill files, mechanical checks and a Skill Judge select updated skills. Initial skills are distilled from an external CLA design. On the seven DAC26-DRC-Benchmark block-level cases, the authors report an aggregate 73.5% DRV reduction (per-block average 83.6%), with Blocks 3 and 5 fully cleaned.

Significance. The paper addresses an important and practical problem: post-route DRC closure at block scale. Its strengths include a concrete system with open-source code, a transparent cost table, traceable operation-result records, and ablations for skill transfer, skill evolution, and layout decomposition. If the reported reductions can be shown to preserve circuit logic and are robust across LLM samples, the framework would be a meaningful step toward automating ECO-style DRC repair. At present the absence of LVS-level verification, the unquantified baseline comparison, and the single-run evaluation make the central claim unverified, so the contribution is conditional rather than established.

major comments (4)
  1. [§3.3, Table 2, footnote 1] The only gate protecting circuit logic is the connectivity check described in footnote 1: a depth-first search over the merged metal–via stack verifying that each standard-cell pin still reaches its corresponding pins. As the footnote states, this is not an LVS run. The check does not assert that the reached-pin set is exactly the expected set; a short between two nets can leave every pin reachable while still changing the circuit. Since repair agents may add, move, resize, and delete metal/vias, and accepted edits are chosen by DRV-count improvement, the reported DRV reductions may be accompanied by invalid layouts. The final designs are never run through LVS or an equivalent equivalence check. I request LVS/equivalence verification of every final block, or a conservative restriction of allowed operations to those for which logic preservation is guaranteed.
  2. [§5.1, Table 5, Abstract] The headline '73.5% overall reduction compared to the reported baseline' is not supported by the results table. Table 5 reports EvoDRC and Ablations 1–3, but no column or row gives the DAC26-DRC-Benchmark baseline workflow's DRV counts or per-iteration improvement. The baseline is never quantified in the text. Please add the baseline DRV counts per iteration and explicitly define the aggregate metric (the 73.5% figure is consistent with (1628−432)/1628 on the final EvoDRC counts, while 83.6% is the mean of the seven per-block percentages). In addition, each configuration is a single run; no LLM seed or sampling variance is reported. Given the stochastic nature of LLM agents, multiple runs or confidence intervals are needed before the improvement magnitude can be assessed.
  3. [§4.1–§5.1, Table 5] The skill-evolution loop is trained on the same seven blocks on which improvement is measured: the framework self-trains on each target block's repair records before later iterations on that same block. The reported improvements are therefore in-sample by construction. This is not inherently wrong for a test-time adaptation method, but it should be stated explicitly. If the claim is that EvoDRC generalizes across designs, a leave-one-block-out or other held-out evaluation is needed. The DAC26 benchmark is also the authors' own open benchmark, and the baseline workflow is from their referenced prior work, so a direct, quantified baseline comparison is especially important.
  4. [§3.5.2, Table 7] The Skill Judge selects updated skill files using proxy criteria — reference check, coverage, and writing quality — but the paper does not validate that these criteria correlate with downstream repair effectiveness. The Ablation 2 result shows that disabling skill evolution hurts DRV reduction, but it does not show that the Skill Judge's selection is better than a simple fixed or random selection policy. An end-to-end ablation replacing the Judge with a fixed/random selector would make the skill-evolution claim load-bearing rather than assumed.
minor comments (4)
  1. [§5.1] The phrase 'EvoDRC’s improvement advantage reaches 77.9% on Block2' is ambiguous; it should say the gap between EvoDRC and Ablation 1 is 77.9 percentage points on Block2.
  2. [§3.1, §4.2] The crop size (2 μm × 2 μm) and the five-iteration cap are free parameters, but no sensitivity analysis is provided. A short discussion of their effect on cost and final DRV count would strengthen the evaluation.
  3. [Tables 5 and 7] The green highlighting of the best reductions in Table 5 is not visible in a monochrome printout; please use a textual marker. In Table 7, the legend (S = Skill Refiner, D = DB Summarizer, T = Tie) should be self-contained in the caption, and missing Ablation 2 columns should be explained.
  4. [§6] The claim that 'any intermediate increases recover within two iterations' appears to hold for the displayed blocks, but the paper should check all seven blocks explicitly, since Table 5 shows Block2's DRV count rising again at iteration 5.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: EvoDRC's DRV-reduction claim is an externally measured KLayout outcome, not a prediction derived from its own inputs.

full rationale

EvoDRC's central claim is an empirical repair result, not a first-principles derivation. The reported 73.5% overall reduction is computed from initial and final DRV counts (Eq. 1, Tables 4-5) produced by KLayout with the ASAP7 rule deck, an external checker; the counts are not defined by the framework's skill files or by its own connectivity check. The initial skills are distilled from a manually cleaned external OpenCores CLA design, and later skills are evolved from repair records collected on the same target blocks; this is in-sample self-adaptation rather than out-of-sample prediction, but no fitted parameter is renamed as a prediction and the quality metric is measured independently. Footnote 1 explicitly states the connectivity check "is not an LVS run" and describes a DFS reachability check; that is a genuine correctness/validation limitation (shorts may pass), but it is not circular — accepting an operation because the checker passes does not make the measured DRV count equal to the checker's definition. The DAC26-DRC-Benchmark and several related-work references are from the same lab, but the load-bearing evidence (KLayout DRC counts) does not reduce to those self-citations; they are at most non-load-bearing self-citations. No equation or construction in the paper is equivalent by definition to its claimed result, so no circular step is identified.

Assumptions & free parameters 2 free parameters · 4 assumptions · 1 invented entities

The central numbers depend on hand-chosen crop size (2μm), iteration budget (5), the KLayout/ASAP7 DRC approximation, a non-LVS connectivity check, and the assumption that skills distilled from a smaller unrelated design transfer to the target blocks. No external falsifiable entity is introduced.

free parameters (2)
  • crop_size_k_um = 2
    Hand-chosen crop bounding size in §3.1 and §4.2; determines which repair operations are allowed and therefore affects the achievable DRV reduction.
  • max_iterations = 5
    EvoDRC runs at most five iterations and stops early at zero DRVs (§4.2); the reported final counts depend on this budget.
assumptions (4)
  • domain assumption KLayout DRC with the ASAP7 PDK rule deck adequately approximates the sign-off DRC deck.
    §4.1 uses KLayout 0.30.1 and the ASAP7 PDK; real foundry decks are more complex, so results may not fully transfer to sign-off.
  • domain assumption The connectivity checker (simple DFS over merged metal-via stack verifying pin reachability) is sufficient to preserve circuit logic.
    Footnote 1 in §3.3 says the check is not an LVS run; it may miss other electrical/logic failures.
  • domain assumption Skills distilled from the small external CLA design transfer to the seven target blocks.
    §4.1 initializes skills from CLA; Ablation 1 shows this helps, but transferability is assumed rather than proven across diverse designs.
  • ad hoc to paper The Skill Judge's selection criteria (citation coverage, coverage, writing quality) correlate with downstream repair effectiveness.
    §3.5.2 selects skill candidates by majority vote on these criteria, but no evidence links these criteria to actual DRV reduction.
invented entities (1)
  • Layer-wise skill files
    purpose: Store repair knowledge (situations, suggestions, warnings) to guide LLM repair agents
    Internal data structure; no falsifiable handle outside the paper's own benchmark.

how reviews work

0 comments
Cite this review

Pith. "Pith review of EvoDRC: A Self-Evolving Agentic Framework for Automated DRC Violation Repair." pith.science (2026). https://pith.science/paper/5ITIHGG6

@misc{pith2026260720019,
  author       = {Pith},
  title        = {Pith review of: EvoDRC: A Self-Evolving Agentic Framework for Automated DRC Violation Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5ITIHGG6}},
  note         = {Machine review of arXiv:2607.20019}
}
read the original abstract

Design rule check (DRC) closure remains a major bottleneck in advanced-node physical design. Although detailed routers are rule-aware, residual design rule violations (DRVs) often require manual engineering change order iterations. Automating this process is challenging because repairs must account for complex geometric interactions, preserve circuit connectivity, and avoid introducing new violations. We present EvoDRC, a skill-evolution framework for agentic block-level DRC repair. EvoDRC initializes layer-specific repair skills using knowledge distilled from an unrelated reference design and continuously evolves these skills using traceable repair experience collected from the target design. EvoDRC decomposes the layout into bounded repair regions and assigns an LLM repair agent to each region. Local DRC analysis, connectivity-checking, and impact-preview tools provide feedback on proposed modifications. Repair operations and their resulting DRV changes are stored in a knowledge database and used to evolve the repair skills. Experiments on seven block-level designs from the DAC26 DRC Benchmark show that EvoDRC achieves a 73.5\% overall reduction compared to the reported baseline.

Figures

Figures reproduced from arXiv: 2607.20019 by the authors.

Figure 1
Figure 1. Human vs agent in DRC repair. small-scale tasks, such as standard-cell-level layouts [10, 11]. These methods are difficult to scale to block-level complex designs with diverse design rules spanning multiple routing layers. Moreover, an LLM agent’s repair capability strongly depends on a well-developed, task-specific skill file that encodes factual repair knowledge, but such a skill file is rarely available for a new… view at source ↗
Figure 2
Figure 2. Overview of EvoDRC. The framework consists of layout decomposition, agentic DRC repair, and skill evolution. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. AgenticECO: An Agentic Framework for ECO on 3D Integrated Circuits

    cs.AI 2026-08 conditional novelty 6.0 of 10

    An agentic framework with a minimal-disturbance router and independent verifier clears post-route hybrid-bond spacing defects in 3D-IC designs (7/9 on one backbone, 9/9 on another) with low disturbance and zero clock-...

Reference graph

Works this paper leans on

28 extracted references · 1 linked inside Pith · cited by 1 Pith paper

  1. [1]

    How Qualcomm Got Faster Signoff DRC Convergence

    “How Qualcomm Got Faster Signoff DRC Convergence. ” https://semiengineering. com/how-qualcomm-got-faster-signoff-drc-convergence/

  2. [2]

    ReAct: Synergizing Reasoning and Acting in Language Models,

    S. Yao, et al., “ReAct: Synergizing Reasoning and Acting in Language Models, ” in Proc. ICLR, 2023

    2023

  3. [3]

    OpenROAD-Assistant: An Open-Source Large Language Model for Physical Design Tasks,

    U. Sharma, et al., “OpenROAD-Assistant: An Open-Source Large Language Model for Physical Design Tasks, ” inProc. MLCAD, 2024

    2024

  4. [4]

    OpenROAD Agent: An Intelligent Self-Correcting Script Gener- ator for OpenROAD,

    B.-Y. Wu, et al., “OpenROAD Agent: An Intelligent Self-Correcting Script Gener- ator for OpenROAD, ” inProc. ICLAD, 2025

    2025

  5. [5]

    ORFS-agent: Tool-Using Agents for Chip Design Optimization,

    A. Ghose, et al., “ORFS-agent: Tool-Using Agents for Chip Design Optimization, ” in Proc. MLCAD, 2025

    2025

  6. [6]

    ChatEDA: A Large Language Model Powered Autonomous Agent for EDA,

    H. Wu, et al., “ChatEDA: A Large Language Model Powered Autonomous Agent for EDA, ”IEEE T. Comput. Aid. D., vol. 43, no. 10, p. 3184–3197, 2024

    2024

  7. [7]

    Generative Methods in EDA: Innovations in Dataset Generation and EDA Tool Assistants,

    V. A. Chhabria, et al. , “Generative Methods in EDA: Innovations in Dataset Generation and EDA Tool Assistants, ” inProc. ICCAD, 2024

    2024

  8. [8]

    CAPO: Certification-Guided Agentic Workflow for Physical Design Parameter Optimization,

    Z. Jiang, et al. , “CAPO: Certification-Guided Agentic Workflow for Physical Design Parameter Optimization, ” inProc. GLSVLSI, 2026

    2026

Show all 28 references
  1. [9]

    DRC-Coder: Automated DRC Checker Code Generation Using LLM Autonomous Agent,

    C.-C. Chang, et al., “DRC-Coder: Automated DRC Checker Code Generation Using LLM Autonomous Agent, ” inProc. ISPD, 2025

    2025

  2. [10]

    Special Research Session: Toward Agentic Solution for DRC Challenges in Digital VLSI Design,

    B.-Y. Wu, et al., “Special Research Session: Toward Agentic Solution for DRC Challenges in Digital VLSI Design, ” inProc. DAC, 2026

    2026

  3. [11]

    Bridging the Last Mile of Circuit Design: PostEDA-Bench, a Hi- erarchical Benchmark for PPA Convergence and DRC Fixing,

    P. Liu, et al., “Bridging the Last Mile of Circuit Design: PostEDA-Bench, a Hi- erarchical Benchmark for PPA Convergence and DRC Fixing, ” arXiv preprint arXiv:2605.06936, 2026

    2026 arXiv

  4. [12]

    DAC26_DRC_Benchmark

    “DAC26_DRC_Benchmark. ” https://github.com/ASU-VDA-Lab/DAC26_DRC_ Benchmark

  5. [13]

    EvoDRC

    “EvoDRC. ” https://github.com/ASU-VDA-Lab/EvoDRC

  6. [14]

    Placement Tomography-Based Routing Blockage Generation for DRV Hotspot Mitigation,

    A. Kahng, et al., “Placement Tomography-Based Routing Blockage Generation for DRV Hotspot Mitigation, ” inProc. ICCAD, 2025

    2025

  7. [15]

    Methodology of Resolving Design Rule Checking Violations Coupled with Fully Compatible Prediction Model,

    S. Kim, et al. , “Methodology of Resolving Design Rule Checking Violations Coupled with Fully Compatible Prediction Model, ” inProc. ISPD, 2024

    2024

  8. [16]

    RouteNet: Routability Prediction for Mixed-Size Designs Using- Convolutional Neural Network,

    Z. Xie, et al., “RouteNet: Routability Prediction for Mixed-Size Designs Using- Convolutional Neural Network, ” inProc. ICCAD, 2018

    2018

  9. [17]

    TritonRoute: The Open-Source Detailed Router,

    A. B. Kahng, et al., “TritonRoute: The Open-Source Detailed Router, ” IEEE T. Comput. Aid. D., vol. 40, no. 3, pp. 547–559, 2021

    2021

  10. [18]

    Effective and Efficient Detailed Routing with Adaptive Rip-up Scheme and Pin Access Refinement,

    Z. Qi, et al. , “Effective and Efficient Detailed Routing with Adaptive Rip-up Scheme and Pin Access Refinement, ” inProc. GLSVLSI, 2022

    2022

  11. [19]

    CoRe-ECO: Concurrent Refinement of Detailed Place-and- Route for an Efficient ECO Automation,

    C.-K. Cheng, et al., “CoRe-ECO: Concurrent Refinement of Detailed Place-and- Route for an Efficient ECO Automation, ” inProc. ICCD, 2021

    2021

  12. [20]

    SLO-ECO: Single-Line-Open Aware ECO Detailed Placement and Detailed Routing Co-Optimization,

    J.-W. Jeon, et al., “SLO-ECO: Single-Line-Open Aware ECO Detailed Placement and Detailed Routing Co-Optimization, ” inProc. ISQED, 2024

    2024

  13. [21]

    PostEDA-Bench

    “PostEDA-Bench. ” https://github.com/pengjas/posteda-bench

  14. [22]

    ASAP7: A 7-nm FinFET Predictive Process Design Kit,

    L. T. Clark, et al., “ASAP7: A 7-nm FinFET Predictive Process Design Kit, ”Micro- electronics Journal, vol. 53, pp. 105–115, 2016

    2016

  15. [23]

    KLayout

    “KLayout. ” https://www.klayout.de/

  16. [24]

    OpenCores

    “OpenCores. ” https://opencores.org/

  17. [25]

    OpenROAD-flow-scripts

    “OpenROAD-flow-scripts. ” https://github.com/the-openroad-project/openroad- flow-scripts

  18. [26]

    Claude 4.6 Sonnet

    “Claude 4.6 Sonnet. ” https://www.anthropic.com/news/claude-sonnet-4-6

  19. [27]

    Anthropic

    “Anthropic. ” https://www.anthropic.com/

  20. [28]

    Claude Models & Pricing

    “Claude Models & Pricing. ” https://platform.claude.com/docs/en/about-claude/ pricing

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.