Pith. sign in

REVIEW 5 major objections 6 minor 59 references

VeriLoC: Line-of-Code Level Prediction of Hardware Design Quality from Verilog Code

T0 review · 5 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Pith's one-line read VeriLoC predicts timing and routing congestion directly from Verilog source code at both the line and module level.

desk verdict Useful, well-executed first pass at line-level QoR prediction from Verilog, but the split ambiguity and metric inconsistencies mean the headline numbers outrun the evidence. read the letter →

arxiv 2506.07239 v2 pith:NEYR73SM submitted 2025-06-08 cs.AR cs.AI

classification cs.ARcs.AI
keywords Verilogline-levelpredictiontimingcongestionLLMembeddingsRTLqualityhardwaredesign
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

This paper introduces a method for predicting hardware design quality directly from Verilog source code at both the individual-line and whole-module levels. Designers would use it to catch timing violations or routing congestion problems in their code before running hours-long synthesis, placement, and routing. The central claim is that embeddings from a Verilog-specialized language model, combined with embeddings of the surrounding lines and of the whole module, carry enough information to identify the exact lines of code that cause physical-design problems. The reported numbers are F1-scores of 0.86 for line-level congestion and 0.95 for line-level timing, with module-level timing error reduced from 14-18% to 4%.

What carries the argument

The central mechanism is the concatenation of local and global context: for each line, the embedding of the line itself is combined with embeddings of up to two neighboring lines on each side and an attention-pooled embedding of the entire module. This preserves the local semantics of the line while providing the context needed to distinguish, for example, a harmless clocked block from a clocked block that causes congestion.

What would settle it

Training on a split where modules from the same project are kept in either train or test, or using labels from a second design-quality tool, would reveal whether the reported F1-scores and error rates persist under stricter generalization.

Watch

Extended reading notes

Core claim

The central discovery is that a single line of Verilog can carry enough semantic information to determine whether it causes timing or congestion issues, provided its embedding is enriched with embeddings of the surrounding lines and of the whole module. The system uses a Verilog-specialized language model as an encoder, concatenates line-level and module-level embeddings, reduces dimensionality, and then applies classifiers or regressors. The paper claims this approach identifies problem-causing lines with high F1-scores and improves module-level worst-negative-slack prediction over previous RTL-stage methods, and states this is the first line-of-code-level quality prediction result.

Load-bearing premise

The per-line labels from the automated design tool are correct, and the random split of modules does not leak information across train and test, so the reported scores reflect prediction on genuinely new designs.

Editorial extensions

If this is right

  • Designers can get early feedback on which lines to rewrite to avoid timing and congestion problems, before running expensive synthesis and physical design.
  • The same line-level embeddings could be reused for other quality-of-results prediction tasks such as power or area.
  • Smaller models can be used for faster predictions, with a reported tradeoff of modest accuracy loss but 22x average and 113x median speedups.

Reading between the lines

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

  • The approach is likely to be sensitive to the distribution of modules in the training set; if modules from the same project appear on both sides of the split, the reported scores may be inflated and not represent prediction on genuinely new designs.
  • The labels come from a single EDA tool with a specific aggressive timing constraint, so the findings may transfer differently to designs with different constraints or tool versions.
  • A natural test is to see whether the predicted line-level hotspots align with the lines a designer would actually modify to relieve congestion in a real design revision, beyond matching the tool's back-annotation.
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

5 major / 6 minor

Summary. The paper proposes VeriLoC, a method for predicting hardware design quality—specifically routing congestion and timing slack—directly from Verilog source code at both line-of-code and module granularity. VeriLoC uses the penultimate-layer embeddings of CL-Verilog, a Verilog-specialized LLM, to represent individual lines and entire modules; these embeddings are concatenated with neighboring-line context, projected via an autoencoder, and fed into XGBoost, LightGBM, or a small FNN. Line-level congestion and timing are treated as binary classification, while WNS is treated as regression; module-level WNS is obtained by taking the minimum predicted line-level WNS. Experiments on the OpenABCD dataset with Synopsys RTL Architect labels report F1-scores of 0.86 for congestion and 0.95 for timing, and improved module-level timing MAPE compared to MasterRTL, RTL-Timer, VeriDistill, and GNN baselines. The paper also reports runtime speedups over RTL Architect and a qualitative comparison against GPT-4o.

Significance. If the reported results are reliable, VeriLoC is the first method to predict line-level design-quality metrics from RTL code, and the combination of a hardware-specialized LLM with local and global context is a plausible and potentially useful architectural idea. The paper also demonstrates a practical speedup over full synthesis/placement, and it makes an honest attempt to compare against several state-of-the-art baselines. However, the central claims depend on the evaluation protocol: the split unit is unspecified, label-generation details are missing, and the headline MAPE in the abstract is not supported by the reported tables. These issues affect the validity of the generalization claims, so the significance is real but conditional on the evaluation being corrected.

major comments (5)
  1. [Section 4.1, Table 1] The 80/20 random split is not defined at the line, module, or project level. OpenABCD is organized by projects, and Table 1 shows that a single project (e.g., bp_quad, coyote, ariane) contributes many modules and lines. If the split is at line or module granularity, modules from the same project appear on both sides of the training/test boundary, and the model can exploit project-specific idioms, repeated structural patterns, and near-duplicate lines. This would inflate the reported F1-scores and deflate MAPE relative to deployment on genuinely new designs. The authors should split by project (or perform grouped cross-validation) and report results on held-out projects; this is load-bearing for the paper's central generalization claim.
  2. [Abstract, Section 4.3, Tables 3-5] The abstract claims a reduction of MAPE to 'only 4%,' but Table 5 reports VeriLoC's aggregate MAPE as 0.06, Table 4 reports per-design module-level MAPE values between 0.02 and 0.08, and Table 3 reports per-design line-level MAPE as high as 0.27. The 4% figure is not derivable from any table, and the paper never defines how the aggregate MAPE is computed. Please either correct the abstract, state the exact metric and aggregation used to obtain 4%, or provide a confidence interval for the aggregate MAPE. As written, the headline number is inconsistent with the empirical section.
  3. [Section 4.1] The label-generation procedure is not specified in enough detail to assess the validity of the ground truth. The paper states only that RTL Architect was run with a 0.25 ns timing constraint and that congestion/timing labels were back-annotated to lines. It does not explain how individual lines are assigned congestion labels, what threshold defines a 'congestion-causing' line, how line-level WNS is defined for a single line (since WNS is naturally a path- or design-level metric), or how line-level WNS is computed from the tool output. Every F1 and MAPE result depends on these labels, so the paper should include a concrete description of the back-annotation and, ideally, an analysis of label noise.
  4. [Section 3.5, Tables 3 and 4] Module-level WNS is computed by taking the minimum predicted line-level WNS across all lines. This is a non-trivial assumption about how line-level slacks compose into module-level WNS, and the paper does not validate it. Moreover, there is an apparent tension between Table 3 and Table 4: for designs like dynamic_node and bp_be_top, the line-level regression is weak (R² = 0.76, MAPE = 0.18 and R² = 0.76, MAPE = 0.27), yet the module-level results derived from those line-level predictions are excellent (R² = 0.99, MAPE = 0.06 and R² = 0.98, MAPE = 0.08). The authors should explain how this can occur, and should compare module-level WNS computed from ground-truth line-level labels against the tool's reported module-level WNS to quantify the error introduced by the min-composition step.
  5. [Section 4.1 and all result tables] All results are based on a single 80/20 split with no error bars, no multiple seeds, and no statistical significance tests. Given the small number of projects (about a dozen) and the class imbalance in line-level labels, the differences between classifiers and context windows could easily be within run-to-run variation. The paper should report means and standard deviations over multiple random splits, or use repeated cross-validation, to support the quantitative claims in Tables 2-5.
minor comments (6)
  1. [Section 3.3] The autoencoder for dimensionality reduction is trained on the concatenated line and module embeddings, but the paper does not state whether this training includes test-set embeddings. If the autoencoder is fit on the full dataset before the 80/20 split, this is a form of transductive information leakage that should be disclosed, even if the effect is expected to be small.
  2. [Section 4.3 heading] The heading contains a typo: 'Comaprisons' should be 'Comparisons'.
  3. [Section 3.5] The phrase 'we we first estimate WNS at the line level' contains a duplicated word and should be corrected.
  4. [Section 4.1] The sentence 'Synopsys RTL-A only reports WNS when a timing constraints are actually violated' has a subject-verb agreement error; it should read 'timing constraints are actually violated'.
  5. [References] References [13] and [17] are the same Synopsys RTL Architect datasheet and should be merged or cross-referenced.
  6. [Table 1] The table formatting is garbled: the header row 'Design # of Modules # of Lines' appears to be split, and it is not clear whether the second and third columns are module counts and line counts. Please reformat the table for readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: VeriLoC's predictions are supervised fits to external EDA ground truth, and the line-to-module aggregation is a modeling choice, not a construction.

full rationale

VeriLoC's derivation chain is a standard supervised-learning pipeline. Line-level congestion and timing labels come from Synopsys RTL Architect, an external EDA tool, applied to the OpenABCD dataset; the trained classifiers and regressors are evaluated on a held-out 20% split. No target quantity is defined in terms of the model's own outputs, and no fitted parameter is renamed as a prediction. The module-level WNS estimate is obtained by taking the minimum of line-level WNS predictions, which is an aggregation heuristic consistent with worst negative slack being the most negative slack value; the line-level targets are tool-generated, so the minimum operation composes independent predictions rather than recovering the training label by definition. The paper's use of CL-Verilog [14] and OpenABCD [18] involves overlapping authors, but these are public model and dataset artifacts used as a feature extractor and benchmark, not unverified results imported to force a conclusion; the choice of the last hidden layer is additionally supported by an in-paper ablation (Appendix B.6). The paper also explicitly cautions that the CircuitFusion comparison is on different datasets and states in its Limitations section (Sec. 5) that validation is restricted to leaf modules in OpenABCD and has not been adapted to industrial designs; these are scope and generalization caveats, not circular reductions. The unspecified unit of the 80/20 split is a potential evaluation-leakage concern about whether the reported F1 and MAPE generalize to genuinely new designs, but that is a correctness risk, not a circularity of the derivation. Overall, the central claims are self-contained against external benchmarks and do not reduce to their inputs by construction.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The method rests on the premise that LLM embeddings encode RTL semantics relevant to physical design, on the accuracy of the proprietary tool's per-line labels, and on a split that prevents leakage. The key free parameters are model hyperparameters and the timing constraint, selected by ablation or heuristic, not by fitting to the target result.

free parameters (5)
  • Context window p = 5
    Chosen by ablation; larger context improves congestion F1, p=5 best.
  • Encoder hidden dimension d = 128
    Chosen by ablation; F1 saturates at 128.
  • XGBoost hyperparameters = scale_pos_weight=majority/minority, max_depth=30, lr=0.05, n_estimators=500
    Configured for imbalanced data; not swept beyond defaults.
  • LightGBM hyperparameters = is_unbalance=True, num_leaves=100, lr=0.05, feature_fraction=0.8
    Configured for imbalanced data.
  • Timing constraint = 0.25 ns
    Set aggressively because RTL Architect only reports WNS under violation; this makes every design violated and may bias the regression target.
assumptions (4)
  • domain assumption CL-Verilog penultimate-layer activations are informative embeddings for timing and congestion prediction.
    Central to the method; supported only by the paper's own ablation of layer choice (Appendix B.6).
  • domain assumption Per-line labels from RTL Architect correctly identify lines that cause congestion and timing issues.
    The paper does not describe the back-annotation procedure, and noisy labels would directly degrade the reported F1.
  • domain assumption A random 80/20 module-level split prevents information leakage.
    Modules from the same OpenABCD project appear on both sides; no project-wise split is reported.
  • ad hoc to paper Taking the minimum of line-level WNS gives a valid module-level WNS estimate.
    Used to generate module-level predictions from line-level regressions; no justification that path-based WNS equals the min of per-line values.

how reviews work

0 comments
Cite this review

Pith. "Pith review of VeriLoC: Line-of-Code Level Prediction of Hardware Design Quality from Verilog Code." pith.science (2026). https://pith.science/paper/NEYR73SM

@misc{pith2026250607239,
  author       = {Pith},
  title        = {Pith review of: VeriLoC: Line-of-Code Level Prediction of Hardware Design Quality from Verilog Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NEYR73SM}},
  note         = {Machine review of arXiv:2506.07239}
}
read the original abstract

Modern chip design is complex, and there is a crucial need for early-stage prediction of key design-quality metrics like timing and routing congestion directly from Verilog code (a commonly used programming language for hardware design). It is especially important yet complex to predict individual lines of code that cause timing violations or downstream routing congestion. Prior works have tried approaches like converting Verilog into an intermediate graph representation and using LLM embeddings alongside other features to predict module-level quality, but did not consider line-level quality prediction. We propose VeriLoC, the first method that predicts design quality directly from Verilog at both the line- and module-level. To this end, VeriLoC leverages recent Verilog code-generation LLMs to extract local line-level and module-level embeddings, and train downstream classifiers/regressors on concatenations of these embeddings. VeriLoC achieves high F1-scores of 0.86-0.95 for line-level congestion and timing prediction, and reduces the mean average percentage error from 14% - 18% for SOTA methods down to only 4%. We believe that VeriLoC embeddings and insights from our work will also be of value for other predictive and optimization tasks for complex hardware design.

Figures

Figures reproduced from arXiv: 2506.07239 by the authors.

Figure 1
Figure 1. Conventional flow vs proposed for an exemplary AES design. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The architecture of VeriLoC for line-level timing and congestion prediction from RTL. Module-level prediction uses module embedding. The context window is set to p = 5 in this example. 3.1 Module-Level Embeddings Modules in RTL designs are represented as sequences of lines of Verilog: M = {l1, l2, . . . , ln}, where li is the i-th line of code in the module. To capture the global semantics of the module, the complet… view at source ↗
Figure 3
Figure 3. Effect of neighbor embeddings in context-aware [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Scatter plots of actual vs. predicted line-level WNS using [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: further supports these findings through saliency-based visualizations of batched vs individual line embeddings. Specifically, the saliency heatmaps reveal that, w/o comments, key structural elements like always @(posedge clk) receive a disproportionate amount of attent…
Figure 6
Figure 6. Figure 6: The lines of code highlighted by GPT-4o and [PITH_FULL_IMAGE:figures/full_fig_p018_6.png]
Figure 7
Figure 7. Figure 7: The lines of code highlighted by GPT-4o and [PITH_FULL_IMAGE:figures/full_fig_p019_7.png]
Figure 8
Figure 8. Figure 8: The lines of code highlighted by GPT-4o and [PITH_FULL_IMAGE:figures/full_fig_p020_8.png]
Figure 9
Figure 9. Figure 9: The lines of code highlighted by GPT-4o and [PITH_FULL_IMAGE:figures/full_fig_p021_9.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

59 extracted references · 40 canonical work pages

  1. [1]

    Annotating slack directly on your verilog: Fine-grained rtl timing evaluation for early optimization,

    W. Fang, S. Liu, H. Zhang, and Z. Xie, “Annotating slack directly on your verilog: Fine-grained rtl timing evaluation for early optimization,” in Proceedings of the 61st ACM/IEEE Design Automation Conference, ser. DAC ’24. New York, NY , USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10.1145/3649329.3655671

  2. [2]

    Applying gnns to timing estimation at rtl : (invited paper),

    D. S. Lopera and W. Ecker, “Applying gnns to timing estimation at rtl : (invited paper),” in2022 IEEE/ACM International Conference On Computer Aided Design (ICCAD), 2022, pp. 1–8

  3. [3]

    Using graph neural networks for timing esti- mations of rtl intermediate representations,

    D. Sánchez Lopera, I. Subedi, and W. Ecker, “Using graph neural networks for timing esti- mations of rtl intermediate representations,” in 2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD), 2023, pp. 1–6

  4. [4]

    Masterrtl: A pre-synthesis ppa estimation framework for any rtl design,

    W. Fang, Y . Lu, S. Liu, Q. Zhang, C. Xu, L. W. Wills, H. Zhang, and Z. Xie, “Masterrtl: A pre-synthesis ppa estimation framework for any rtl design,” in Proceedings of 2023 IEEE/ACM International Conference on Computer-Aided Design (ICCAD). IEEE, 2023, pp. 1–9

  5. [5]

    Preplacement net length and timing estimation by customized graph neural network,

    Z. Xie, R. Liang, X. Xu, J. Hu, C.-C. Chang, J. Pan, and Y . Chen, “Preplacement net length and timing estimation by customized graph neural network,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 41, no. 11, pp. 4667–4680, 2022

  6. [6]

    Drills: Deep reinforcement learning for logic synthesis,

    A. Hosny, S. Hashemi, M. Shalan, and S. Reda, “Drills: Deep reinforcement learning for logic synthesis,” 2020 25th Asia and South Pacific Design Automation Conference (ASP-DAC), pp. 581–586, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:207853198

  7. [7]

    Exploring logic optimizations with reinforcement learning and graph convolutional network,

    K. Zhu, M. Liu, H. Chen, Z. Zhao, and D. Z. Pan, “Exploring logic optimizations with reinforcement learning and graph convolutional network,” in2020 ACM/IEEE 2nd Workshop on Machine Learning for CAD (MLCAD), 2020, pp. 145–150

  8. [8]

    Rl-guided runtime-constrained heuristic exploration for logic synthesis,

    Y . V . Peruvemba, S. Rai, K. Ahuja, and A. Kumar, “Rl-guided runtime-constrained heuristic exploration for logic synthesis,” in 2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD), 2021, pp. 1–9

Show all 59 references
  1. [9]

    Bulls-eye: Active few-shot learning guided logic synthesis,

    A. Basak Chowdhury, B. Tan, R. Carey, T. Jain, R. Karri, and S. Garg, “Bulls-eye: Active few-shot learning guided logic synthesis,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 42, no. 8, pp. 2580–2590, 2023

  2. [10]

    Retrieval-guided reinforcement learning for boolean circuit minimization,

    A. B. Chowdhury, M. Romanelli, B. Tan, R. Karri, and S. Garg, “Retrieval-guided reinforcement learning for boolean circuit minimization,” arXiv preprint arXiv:2401.12205, 2024

  3. [11]

    The graph’s apprentice: Teaching an llm low level knowledge for circuit quality estimation,

    R. Moravej, S. Bodhe, Z. Zhang, D. Chetelat, D. Tsaras, Y . Zhang, H.-L. Zhen, J. Hao, and M. Yuan, “The graph’s apprentice: Teaching an llm low level knowledge for circuit quality estimation,” 2025. [Online]. Available: https://arxiv.org/abs/2411.00843

  4. [12]

    Circuitfusion: Multimodal circuit representation learning for agile chip design,

    W. Fang, S. Liu, J. Wang, and Z. Xie, “Circuitfusion: Multimodal circuit representation learning for agile chip design,” in International Conference on Learning Representations (ICLR), 2025. [Online]. Available: https://arxiv.org/abs/2505.02168

  5. [14]

    Rome was not built in a single step: Hierarchical prompting for llm-based chip design,

    A. Nakkab, S. Q. Zhang, R. Karri, and S. Garg, “Rome was not built in a single step: Hierarchical prompting for llm-based chip design,” in Proceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD , ser. MLCAD ’24. New York, NY , USA: Association for...

  6. [15]

    Llm2vec: Large language models are secretly powerful text encoders,

    P. BehnamGhader, V . Adlakha, M. Mosbach, D. Bahdanau, N. Chapados, and S. Reddy, “Llm2vec: Large language models are secretly powerful text encoders,” 2024. [Online]. Available: https://arxiv.org/abs/2404.05961

  7. [16]

    Beyond decoder-only: Large language models can be good encoders for machine translation,

    Y . Luo, T. Zheng, Y . Mu, B. Li, Q. Zhang, Y . Gao, Z. Xu, P. Feng, X. Liu, T. Xiao, and J. Zhu, “Beyond decoder-only: Large language models can be good encoders for machine translation,”

  8. [17]

    Synopsys rtl architect,

    “Synopsys rtl architect,” https://www.synopsys.com/content/dam/synopsys/implementation& signoff/datasheets/rtl-architect-ds.pdf

  9. [18]

    Openabc-d: A large-scale dataset for machine learning guided integrated circuit synthesis,

    A. B. Chowdhury, B. Tan, R. Karri, and S. Garg, “Openabc-d: A large-scale dataset for machine learning guided integrated circuit synthesis,” 2021

  10. [19]

    Xgboost: A scalable tree boosting system,

    T. Chen and C. Guestrin, “Xgboost: A scalable tree boosting system,” in Proceedings of the 22nd acm sigkdd international conference on knowledge discovery and data mining, 2016, pp. 785–794

  11. [20]

    Lightgbm: a highly efficient gradient boosting decision tree,

    G. Ke, Q. Meng, T. Finley, T. Wang, W. Chen, W. Ma, Q. Ye, and T.-Y . Liu, “Lightgbm: a highly efficient gradient boosting decision tree,” in Proceedings of the 31st International Conference on Neural Information Processing Systems , ser. NIPS’17. Red Hook, NY , USA: Curran As...

  12. [21]

    A. B. Kahng, J. Lienig, I. L. Markov, and J. Hu,VLSI Physical Design: From Graph Partitioning to Timing Closure. Springer, 2011

  13. [22]

    A simplr method for routability-driven placement,

    M.-C. Kim, J. Hu, D.-J. Lee, and I. L. Markov, “A simplr method for routability-driven placement,” in 2011 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2011, pp. 67–73

  14. [23]

    Ripple 2.0: High quality routability-driven placement via global router integration,

    X. He, T. Huang, W.-K. Chow, J. Kuang, K.-C. Lam, W. Cai, and E. F. Young, “Ripple 2.0: High quality routability-driven placement via global router integration,” in 2013 50th ACM/EDAC/IEEE Design Automation Conference (DAC), 2013, pp. 1–6

  15. [24]

    Optimization of placement solutions for routability,

    W.-H. Liu, C.-K. Koh, and Y .-L. Li, “Optimization of placement solutions for routability,” in 2013 50th ACM/EDAC/IEEE Design Automation Conference (DAC), 2013, pp. 1–9

  16. [25]

    Ntuplace4dr: A detailed-routing-driven placer for mixed-size circuit designs with technology and region constraints,

    C.-C. Huang, H.-Y . Lee, B.-Q. Lin, S.-W. Yang, C.-H. Chang, S.-T. Chen, Y .-W. Chang, T.-C. Chen, and I. Bustany, “Ntuplace4dr: A detailed-routing-driven placer for mixed-size circuit designs with technology and region constraints,”IEEE Transactions on Computer-Aided Design o...

  17. [26]

    Fast and accurate routing demand estimation for efficient routability-driven placement,

    P. Spindler and F. M. Johannes, “Fast and accurate routing demand estimation for efficient routability-driven placement,” in 2007 Design, Automation & Test in Europe Conference & Exhibition, 2007, pp. 1–6

  18. [27]

    Glare: Global and local wiring aware routability evaluation,

    Y . Wei, C. Sze, N. Viswanathan, Z. Li, C. J. Alpert, L. Reddy, A. D. Huber, G. E. Tellez, D. Keller, and S. S. Sapatnekar, “Glare: Global and local wiring aware routability evaluation,” in DAC Design Automation Conference 2012, 2012, pp. 768–773

  19. [28]

    Ripple: A robust and effective routability-driven placer,

    X. He, T. Huang, L. Xiao, H. Tian, and E. F. Y . Young, “Ripple: A robust and effective routability-driven placer,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 32, no. 10, pp. 1546–1556, 2013

  20. [29]

    Routability- driven global placer target on removing global and local congestion for vlsi designs,

    J.-M. Lin, C.-W. Huang, L.-C. Zane, M.-C. Tsai, C.-L. Lin, and C.-F. Tsai, “Routability- driven global placer target on removing global and local congestion for vlsi designs,” in2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD), 2021, pp. 1–8

  21. [30]

    Routenet: Routability prediction for mixed-size designs using convolutional neural network,

    Z. Xie, Y .-H. Huang, G.-Q. Fang, H. Ren, S.-Y . Fang, Y . Chen, and J. Hu, “Routenet: Routability prediction for mixed-size designs using convolutional neural network,” in 2018 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2018, pp. 1–8

  22. [31]

    Mitigating distribution shift for congestion optimization in global placement,

    S. Zheng, L. Zou, S. Liu, Y . Lin, B. Yu, and M. Wong, “Mitigating distribution shift for congestion optimization in global placement,” in 2023 60th ACM/IEEE Design Automation Conference (DAC), 2023, pp. 1–6

  23. [32]

    Versatile multi-stage graph neural network for circuit representation,

    S. Yang, Z. Yang, D. Li, Y . Zhang, Z. Zhang, G. Song, and J. Hao, “Versatile multi-stage graph neural network for circuit representation,” in Advances in Neural Information Processing Systems, S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh, Eds., vol. 35. C...

  24. [33]

    Congestionnet: Routing congestion prediction using deep graph neural networks,

    R. Kirby, S. Godil, R. Roy, and B. Catanzaro, “Congestionnet: Routing congestion prediction using deep graph neural networks,” in 2019 IFIP/IEEE 27th International Conference on Very Large Scale Integration (VLSI-SoC), 2019, pp. 217–222

  25. [34]

    Lhnn: lattice hypergraph neural network for vlsi congestion prediction,

    B. Wang, G. Shen, D. Li, J. Hao, W. Liu, Y . Huang, H. Wu, Y . Lin, G. Chen, and P. A. Heng, “Lhnn: lattice hypergraph neural network for vlsi congestion prediction,” in Proceedings of the 59th ACM/IEEE Design Automation Conference, ser. DAC ’22. New York, NY , USA: Associatio...

  26. [35]

    Generalizable cross-graph embedding for gnn-based congestion prediction,

    A. Ghose, V . Zhang, Y . Zhang, D. Li, W. Liu, and M. Coates, “Generalizable cross-graph embedding for gnn-based congestion prediction,” in 2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD) . IEEE Press, 2021, p. 1–9. [Online]. Available: https://doi.org/...

  27. [36]

    Lay-net: Grafting netlist knowledge on layout-based congestion prediction,

    S. Zheng, L. Zou, P. Xu, S. Liu, B. Yu, and M. Wong, “Lay-net: Grafting netlist knowledge on layout-based congestion prediction,” in2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD), 2023, pp. 1–9

  28. [37]

    Pin accessibility and routing congestion aware DRC hotspot prediction using graph neural network and u-net,

    K. Baek, H. Park, S. Kim, K. Choi, and T. Kim, “Pin accessibility and routing congestion aware DRC hotspot prediction using graph neural network and u-net,” in IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2022

  29. [38]

    A timing engine inspired graph neural network model for pre-routing slack prediction,

    Z. Guo, M. Liu, J. Gu, S. Zhang, D. Z. Pan, and Y . Lin, “A timing engine inspired graph neural network model for pre-routing slack prediction,” in Proceedings of the 59th ACM/IEEE Design Automation Conference, ser. DAC ’22. New York, NY , USA: Association for Computing Machin...

  30. [39]

    Tf-predictor: Transformer-based prerouting path delay prediction framework,

    P. Cao, G. He, and T. Yang, “Tf-predictor: Transformer-based prerouting path delay prediction framework,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 42, no. 7, pp. 2227–2237, 2023

  31. [40]

    Evaluating large language models trained on code,

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. de Oliveira Pinto, J. Kaplan, H. Edwards, Y . Burda, N. Joseph, G. Brockman, A. Ray, R. Puri, G. Krueger, M. Petrov, H. Khlaaf, G. Sastry, P. Mishkin, B. Chan, S. Gray, N. Ryder, M. Pavlov, A. Power, L. Kaiser, M. Bavarian, C. Winter,...

  32. [41]

    CodeBERT: A pre-trained model for programming and natural languages,

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang, and M. Zhou, “CodeBERT: A pre-trained model for programming and natural languages,” in Findings of the Association for Computational Linguistics: EMNLP 2020, T. Cohn, Y . He, and Y . Liu, E...

  33. [42]

    Graphcode{bert}: Pre-training code representations with data flow,

    D. Guo, S. Ren, S. Lu, Z. Feng, D. Tang, S. LIU, L. Zhou, N. Duan, A. Svyatkovskiy, S. Fu, M. Tufano, S. K. Deng, C. Clement, D. Drain, N. Sundaresan, J. Yin, D. Jiang, and M. Zhou, “Graphcode{bert}: Pre-training code representations with data flow,” in International Conferenc...

  34. [43]

    Inferfix: End-to-end program repair with llms,

    M. Jin, S. Shahriar, M. Tufano, X. Shi, S. Lu, N. Sundaresan, and A. Svyatkovskiy, “Inferfix: End-to-end program repair with llms,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering , ser. ESE...

  35. [44]

    Enhancing static analysis for practical bug detection: An llm-integrated approach,

    H. Li, Y . Hao, Y . Zhai, and Z. Qian, “Enhancing static analysis for practical bug detection: An llm-integrated approach,” Proceedings of the ACM on Programming Languages , vol. 8, no. OOPSLA1, pp. 474–499, 2024. 12

  36. [45]

    Llm-powered test case generation for detecting tricky bugs,

    K. Liu, Y . Liu, Z. Chen, J. M. Zhang, Y . Han, Y . Ma, G. Li, and G. Huang, “Llm-powered test case generation for detecting tricky bugs,” arXiv preprint arXiv:2404.10304, 2024

  37. [46]

    Sanitizing large language models in bug detection with data-flow,

    C. Wang, W. Zhang, Z. Su, X. Xu, and X. Zhang, “Sanitizing large language models in bug detection with data-flow,” in Findings of the Association for Computational Linguistics: EMNLP 2024 , Y . Al-Onaizan, M. Bansal, and Y .-N. Chen, Eds. Miami, Florida, USA: Association for C...

  38. [47]

    Verigen: A large language model for verilog code generation,

    S. Thakur, B. Ahmad, H. Pearce, B. Tan, B. Dolan-Gavitt, R. Karri, and S. Garg, “Verigen: A large language model for verilog code generation,” ACM Trans. Des. Autom. Electron. Syst., vol. 29, no. 3, Apr. 2024. [Online]. Available: https://doi.org/10.1145/3643681

  39. [48]

    Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,

    S. Liu, W. Fang, Y . Lu, Q. Zhang, H. Zhang, and Z. Xie, “Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,” in 2024 IEEE LLM Aided Design Workshop (LAD). IEEE, 2024, pp. 1–5

  40. [49]

    Verilogeval: Evaluating large language models for verilog code generation,

    M. Liu, N. Pinckney, B. Khailany, and H. Ren, “Verilogeval: Evaluating large language models for verilog code generation,” 2023. [Online]. Available: https://arxiv.org/abs/2309.07544

  41. [50]

    Rtllm: An open-source benchmark for design rtl generation with large language model,

    Y . Lu, S. Liu, Q. Zhang, and Z. Xie, “Rtllm: An open-source benchmark for design rtl generation with large language model,” in Proceedings of the 29th Asia and South Pacific Design Automation Conference, ser. ASPDAC ’24. IEEE Press, 2024, p. 722–727. [Online]. Available: http...

  42. [51]

    Codev: Empowering llms with hdl generation through multi-level summarization,

    Y . Zhao, D. Huang, C. Li, P. Jin, M. Song, Y . Xu, Z. Nan, M. Gao, T. Ma, L. Qi, Y . Pan, Z. Zhang, R. Zhang, X. Zhang, Z. Du, Q. Guo, and X. Hu, “Codev: Empowering llms with hdl generation through multi-level summarization,” 2025. [Online]. Available: https://arxiv.org/abs/2...

  43. [52]

    BetterV: Controlled verilog generation with discriminative guidance,

    Z. Pei, H. Zhen, M. Yuan, Y . Huang, and B. Yu, “BetterV: Controlled verilog generation with discriminative guidance,” in Proceedings of the 41st International Conference on Machine Learning, ser. Proceedings of Machine Learning Research, R. Salakhutdinov, Z. Kolter, K. Heller...

  44. [53]

    Rtlrewriter: Methodologies for large models aided rtl code optimization,

    X. Yao, Y . Wang, X. Li, Y . Lian, R. Chen, L. Chen, M. Yuan, H. Xu, and B. Yu, “Rtlrewriter: Methodologies for large models aided rtl code optimization,” 2024. [Online]. Available: https://arxiv.org/abs/2409.11414

  45. [54]

    Rtlfixer: Automatically fixing rtl syntax errors with large language models,

    Y .-D. Tsai, M. Liu, and H. Ren, “Rtlfixer: Automatically fixing rtl syntax errors with large language models,” 2024. [Online]. Available: https://arxiv.org/abs/2311.16543

  46. [55]

    Lightgbm: A highly efficient gradient boosting decision tree,

    G. Ke, Q. Meng, T. Finley, T. Wang, W. Chen, W. Ma, Q. Ye, and T.-Y . Liu, “Lightgbm: A highly efficient gradient boosting decision tree,” Advances in neural information processing systems, vol. 30, 2017

  47. [56]

    When do neural nets outperform boosted trees on tabular data?

    D. C. McElfresh, S. Khandagale, J. Valverde, V . P. C, G. Ramakrishnan, M. Goldblum, and C. White, “When do neural nets outperform boosted trees on tabular data?” in Thirty-seventh Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2023. [Online...

  48. [57]

    OpenAI, “GPT-4,” Mar. 2023. [Online]. Available: https://openai.com/research/gpt-4

  49. [58]

    Workshops on extreme scale design automation (esda) challenges and opportunities for 2025 and beyond,

    R. I. Bahar, A. K. Jones, S. Katkoori, P. H. Madden, D. Marculescu, and I. L. Markov, “Workshops on extreme scale design automation (esda) challenges and opportunities for 2025 and beyond,” 2020. [Online]. Available: https://arxiv.org/abs/2005.01588

  50. [59]

    Automated concatenation of embeddings for structured prediction,

    X. Wang, Y . Jiang, N. Bach, T. Wang, Z. Huang, F. Huang, and K. Tu, “Automated concatenation of embeddings for structured prediction,” in Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Nat...

  51. [2025]

    Available: https://arxiv.org/abs/2503.06594 10

    [Online]. Available: https://arxiv.org/abs/2503.06594 10

Pith tools

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