Pith. sign in

REVIEW 4 major objections 4 minor 36 references

DecoRTL: A Run-time Decoding Framework for RTL Code Generation with LLMs

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

Pith's one-line read DecoRTL claims that decoding-time choices — class-conditioned temperature plus contrastive re-ranking of top candidates — significantly raise the synthesizability and functional correctness of LLM-generated Verilog on VerilogEval across…

desk verdict A plausible, well-scoped decoding trick for Verilog generation with consistent gains across three models, but the 'significant' claim lacks statistical grounding and the closest prior baseline is not compared. read the letter →

arxiv 2507.02226 v1 pith:HQ2JM5PM submitted 2025-07-03 cs.PL cs.ARcs.LG

classification cs.PLcs.ARcs.LG
keywords RTLcodegenerationVerilogLLMdecodingstrategysyntax-awaretemperatureadaptationcontrastiveself-consistencysamplingsynthesizabilityEval
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 argues that the decoding strategy, not just the model or the prompt, is a limiting factor in LLM-based Verilog (RTL) generation, and that standard text-oriented decoding choices are a poor fit for hardware code. It proposes DecoRTL, an inference-time-only framework with two levers: a contrastive re-ranking of the top-K candidate tokens that penalizes candidates too similar to the group average, and a syntax-aware temperature schedule that lowers sampling temperature by 0.1 when the next token is predicted to be structural (keywords, delimiters) and raises it by 0.1 when the token is predicted to be high-impact (operators, assignments). Across CodeLlama-7B, QwenCoder-2.5-14B, and the RTL-fine-tuned CodeV on the VerilogEval benchmark, the combined strategy lifts pass@1 functional correctness by up to about 17 percentage points and synthesizability by up to about 16 points, with negligible runtime overhead. The central claim is that syntax-critical regions need determinism while design-critical regions need exploration, and that the previously generated token carries enough signal to switch between the two at each step.

What carries the argument

The machinery is the two-lever decoding rule itself. The contrastive term treats the top-K candidates' mean embedding $\bar{e}$ as the center of a redundant cluster and penalizes any candidate close to it, $\text{score}(x^{(i)}) = L_i - \lambda\,\text{sim}(e_i,\bar{e})$, with $\lambda = 0.5$ and $K = 5$ in the experiments, which flattens overconfident, semantically clustered distributions. The temperature lever uses a hand-assigned two-class token table (structural tokens such as module, begin, end, and punctuation; high-impact tokens such as operators and comparisons) and a rule that the previously generated token predicts the next token's class; it then applies $T_{\text{base}} - 0.1$ for structural and $T_{\text{base}} + 0.1$ for high-impact tokens. Both levers act only on the softmax at decode time, so no training, dataset, or architecture change is needed.

What would settle it

Run the paper's C+TA strategy on VerilogEval with the temperature schedule attached to randomly shuffled token classes (same fraction of structural and high-impact decisions, same $\pm 0.1$ offsets, contrastive re-ranking unchanged). If shuffled labels reproduce the reported gains, the syntax-aware schedule is not the cause; if they collapse to baseline, the class rule is doing the work. A second check is to scan the offset magnitude: if gains are flat across offsets from 0 to 0.3, the specific $\pm 0.1$ choice is not load-bearing.

Watch

Extended reading notes

Core claim

DecoRTL's central claim is that conventional decoding — greedy, top-k, or nucleus — fails on RTL because it applies one sampling behavior across tokens that play very different roles. The authors show that token-level entropy during Verilog generation is generally low but spikes at control constructs and block boundaries, exactly where syntax errors appear, and they report corpus statistics from roughly 200K open-source Verilog modules indicating that the class of the next token (structural versus high-impact) is often predictable from the token that precedes it. On that basis they define a decoding rule: predict the next token's class from the last generated token; sample at $T_{\text{base}} - 0.1$ if structural, $T_{\text{base}} + 0.1$ if high-impact; and re-rank the top-K candidates by score $\text{score}(x^{(i)}) = L_i - \lambda \cdot \text{sim}(e_i, \bar{e})$, where $L_i$ is the log-probability and $\bar{e}$ is the mean embedding of the candidate set. On the VerilogEval benchmark the combined C+TA strategy improves both synthesizability and functional correctness for all three tested models compared with top-k baselines, with average decoding time rising from 0.1383 to 0.1413 seconds per token.

Load-bearing premise

The load-bearing assumption is that a token's class — structural versus high-impact — can be read off the previously generated token often enough that nudging the temperature down for one class and up for the other improves validity without hurting correctness; the paper supports this with corpus frequency statistics but does not validate the classifier or isolate the temperature shift's contribution from the contrastive re-ranking.

Editorial extensions

If this is right

  • Applying C+TA decoding lifts pass@1 functional correctness from 18.2% to 32.0% on CodeLlama-7B, 37.1% to 54.4% on QwenCoder-2.5-14B, and 53.2% to 69.8% on CodeV over the VerilogEval benchmark, with synthesizability gains of comparable scale.
  • The same decoding strategy reduces hallucinated and repetitive outputs: 18 hallucinated and 9 repetitive outputs for CodeLlama under top-k drop to 3 and 0 under C+TA, and QwenCoder's 11 hallucinated and 5 repetitive outputs drop to 0 and 0.
  • Because the framework operates entirely at inference time with no retraining, it can be applied on top of any pre-trained or RTL-fine-tuned LLM, including models released after this work.
  • The overhead is small enough to be called imperceptible in the paper: average decoding time per token rises from 0.1383 to 0.1413 seconds and peak GPU memory by 0.5%.
  • Lower and steadier token entropy under contrastive decoding (mean 0.106 to 0.071 for QwenCoder; 0.219 to 0.134 for CodeLlama) indicates the method concentrates probability mass on confident, non-redundant choices.

Reading between the lines

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

  • The temperature shift is the least controlled part of the design: the paper reports corpus-level frequency statistics but never validates the previous-token-to-next-class predictor, so an ablation that shuffles the class labels while keeping the $\pm 0.1$ schedule would test whether the gains come from the specific classes or only from the contrastive reranker.
  • The same two-lever recipe — class-conditioned temperature plus embedding-dissimilarity re-ranking — should transfer to other syntax-heavy hardware languages such as SystemVerilog assertions or VHDL, and to other structured code domains with strong local grammar, since nothing in the mechanism is Verilog-specific beyond the token table.
  • The paper fixes the offsets, the penalty $\lambda$, and the candidate size $K$ by hand (0.1, 0.5, and 5); a sensitivity study scanning these values per model would show whether the reported gains are robust or concentrated at the chosen operating point.
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. The paper proposes DecoRTL, an inference-time decoding framework for RTL (Verilog) code generation with LLMs. It first presents an empirical entropy analysis contrasting natural-language and RTL generation, and a corpus study of preceding-token statistics for two hand-defined token classes. It then introduces two decoding components: a contrastive re-ranking of top-K candidate tokens that penalizes similarity to the mean candidate embedding, and a syntax-aware temperature adaptation that lowers temperature after structural tokens and raises it after high-impact tokens. The method is evaluated on VerilogEval (Human) with CodeLlama-7B, QwenCoder-2.5-14B, and CodeV, reporting synthesizability and functional pass rates for baseline, temperature-adaptive, contrastive, and combined decoding. The authors claim consistent, significant improvements with negligible overhead.

Significance. If the reported gains are robust, DecoRTL is a useful contribution to LLM-based hardware design: it is model-agnostic, requires no fine-tuning or extra data, and addresses a relatively underexplored dimension (decoding strategy) for RTL generation. The entropy analysis and the corpus-based motivation are interesting and potentially reusable. Positive evidence in the manuscript includes the internal consistency between the adaptive-temperature result in Table IV (25.6% for CodeLlama) and the TA-only row in Table VII (25.6% for CodeLlama pass@1), the availability of code, and the consistent direction of improvement across three models. However, the experimental validation currently lacks statistical grounding and has several protocol ambiguities that make the central claim of 'significant' improvement not yet established.

major comments (4)
  1. [Section V-D, Tables VI and VII] The central claim that DecoRTL 'significantly reduces functionality and synthesizability issues' rests on point estimates with no error bars, no number of benchmark problems, no number of independent runs or seeds, and no confidence intervals or significance tests. For example, CodeV functional pass@1 increases from 53.2% to 69.8%; since pass@1 with one sample per problem is highly variable, this gap could shrink or disappear under repeated sampling. Please report the number of VerilogEval problems used, the number of independent generation runs per condition, and provide confidence intervals or a paired statistical test across problems.
  2. [Section V-D and footnotes to Tables VI and VII] The metrics 'Pass@i' and 'Syn@i' are not precisely defined: the footnote says 'functional correctness in i runs', which is ambiguous between 'at least one success among i generated candidates per problem' and 'i independent single-sample runs'. The baseline configuration is also incompletely specified: Section V-A uses top-k with k=10, while Section V-D states that the contrastive method uses k=5, and it is not stated what k the Base rows in Tables VI and VII use. If the baseline uses k=10 while C and C+TA use k=5, the comparison conflates the proposed mechanism with the candidate-set size. Please state the exact pass@k definition, the top-k value, base temperature, and generation budget for every row, and ensure the baseline and method differ only in the component under test.
  3. [Section V-B and Section IV-B] The adaptive-temperature component is not compared against the closest existing adaptive-temperature decoding method for code generation, namely reference [9] (Hot or Cold? adaptive temperature sampling). Without such a comparison, it is unclear whether the syntax-aware class rule is responsible for the TA gains or whether any token-adaptive scheduler that lowers temperature in uncertain regions would perform similarly. In addition, the hand-defined token classes in Table II are not validated: there is no classification accuracy or error analysis for the rule that the previous token predicts the next token's class, and no sensitivity analysis for the chosen temperature step of ±0.1 or for Tbase. Please add these comparisons and ablations.
  4. [Section IV-A and Section V-D] The hyperparameters λ=0.5, K=5, Tbase=0.7, and ΔT=0.1 are fixed in all experiments, but the paper does not report how they were selected or whether they were tuned on the same VerilogEval split used for the reported results. If they were tuned on the test set, the reported gains may reflect tuning rather than the method's intrinsic benefit. Please state the hyperparameter selection procedure, use a held-out split if any tuning was performed, and include a sensitivity analysis over λ, K, and ΔT.
minor comments (4)
  1. [Throughout] There are several typos and grammatical errors, including 'construsts' and 'entorpy' in Section III-A, 'uaing' in Section II-A, and 'he next token' in Section IV-A. A proofreading pass is needed.
  2. [Section III-B, Figure 4] The two subfigures in Figure 4 have unclear captions/questions ('what is the token generated before high-impact tokens?' and the analogous question for structural tokens); please clarify which panel corresponds to which token class and make the figure self-contained.
  3. [Section V-A] The entropy evaluation uses only 40 prompts from VerilogEval; please state how these prompts were selected and whether they overlap with the subset used for the main results in Tables VI and VII.
  4. [Table I] Table I is a qualitative comparison with entries such as 'High', 'Medium', and 'Low' that are not defined or measured; consider labeling it as the authors' qualitative assessment rather than an empirical result.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: DecoRTL's decoding formulas are independent of its evaluation metrics, and the reported gains come from external VerilogEval/Vivado measurements.

full rationale

The paper's two mechanisms are defined by explicit, non-circular formulas: the contrastive re-ranking score is log-probability minus lambda times cosine similarity to the mean embedding of the top-K candidates, and the temperature schedule is Tbase-0.1 or Tbase+0.1 based on a hand-assigned token-class table. Neither formula is defined in terms of the reported synthesizability or functional-correctness metrics, and those metrics (Xilinx Vivado synthesis and logic simulation on VerilogEval) are external to the decoding rule. The entropy analysis in Section III motivates the design but does not entail the Table VI/VII results; those results are measured. The paper includes multiple self-citations (refs [5], [6], [10], [19], [20]), but they appear in related-work and motivational contexts, not as load-bearing justification for the method or its evaluation; no uniqueness theorem is invoked. No fitted parameter is renamed as a prediction, and no equation reduces to its inputs by construction. The absence of confidence intervals, seed counts, and a tuning protocol is a statistical-evidence concern, not circularity.

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

No new physical entities. The main load-bearing choices are numerical hyperparameters and the hand-written token class mapping.

free parameters (4)
  • lambda (contrastive penalty) = 0.5
    Used in score = L_i - lambda * cos_sim(e_i, mean). No sensitivity analysis or tuning protocol reported; chosen by hand.
  • K (candidate set size) = 5
    Contrastive re-ranking uses top-K=5; baseline uses top-k=10, so the comparison is not matched.
  • T_base (base temperature) = 0.7
    Base temperature for adaptive decoding; fixed without justification.
  • Delta T (temperature step) = 0.1
    Temperature adjustment for structural and high-impact tokens; chosen by hand with no justification.
assumptions (4)
  • domain assumption Frequency of preceding token types in open-source Verilog corpus predicts the class of the next token during generation.
    Section III-B and Fig. 4 establish correlation; Section IV-B relies on it to set temperature before sampling the next token.
  • ad hoc to paper The hand-defined token classification in Table II (structural vs high-impact vs other) is sufficient and correct for temperature adaptation.
    The classifier is not learned or validated; identifiers are excluded, so many tokens fall into no controlled class.
  • ad hoc to paper Lower temperature for structural tokens improves syntactic validity and higher temperature for high-impact tokens improves functional diversity.
    Stated in Section IV-B; no experiment isolates this causal effect.
  • domain assumption Cosine similarity of a candidate token embedding to the mean embedding of top-K candidates measures undesirable redundancy.
    Section IV-A; plausible but unvalidated for RTL tokens.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DecoRTL: A Run-time Decoding Framework for RTL Code Generation with LLMs." pith.science (2026). https://pith.science/paper/HQ2JM5PM

@misc{pith2026250702226,
  author       = {Pith},
  title        = {Pith review of: DecoRTL: A Run-time Decoding Framework for RTL Code Generation with LLMs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HQ2JM5PM}},
  note         = {Machine review of arXiv:2507.02226}
}
read the original abstract

As one of their many applications, large language models (LLMs) have recently shown promise in automating register transfer level (RTL) code generation. However, conventional LLM decoding strategies, originally designed for natural language, often fail to meet the structural and semantic demands of RTL, leading to hallucinated, repetitive, or invalid code outputs. In this paper, we first investigate the root causes of these decoding failures through an empirical analysis of token-level entropy during RTL generation. Our findings reveal that LLMs exhibit low confidence in regions of structural ambiguity or semantic complexity, showing that standard decoding strategies fail to differentiate between regions requiring determinism (syntax-critical regions) and those that benefit from creative exploratory variability (design-critical regions). Then, to overcome this, we introduce DecoRTL, a novel run-time decoding strategy, that is both syntax-aware and contrastive for RTL code generation. DecoRTL integrates two complementary components: (i) self-consistency sampling, which generates multiple candidates and re-ranks them based on token-level agreement to promote correctness while maintaining diversity; and (ii) syntax-aware temperature adaptation, which classifies tokens by their syntactical and functional roles and adjusts the sampling temperature accordingly, enforcing low temperature for syntax-critical tokens and higher temperature for exploratory ones. Our approach operates entirely at inference time without requiring any additional model fine-tuning. Through evaluations on multiple open-source LLMs using the VerilogEval benchmark, we demonstrate significant improvements in syntactic validity, functional correctness, and output diversity, while the execution overhead (performance overhead) is imperceptible.

Figures

Figures reproduced from arXiv: 2507.02226 by the authors.

Figure 1
Figure 1. RTL codes generated using different decoding strategies. Greedy and sampling-based methods often produce repetitive/invalid code, while our ap￾proach (Contrastive + TA decoding) generates more diverse and syntactically correct RTL (Examples are abstracted due to space constrained)2 . generation with existing models. II. RELATED WORKS A. LLM for Code Generation LLMs have achieved remarkable success in code generation… view at source ↗
Figure 2
Figure 2. The Overall Comparison of Greedy, Top-k, Nucleus, and Our Contrastive Decoding Strategies for RTL Token Generation. tokens endorsed by the expert but disfavored by the amateur, enhancing reasoning and reducing hallucination [33]. As shown in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Token-wise Entropy and their Comparison between Prompts for Natural Language vs. that of RTL Generation [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Distribution of Preceding Tokens for Structural and High-Impact Categories (For code generation purposes, only syntactic tokens—such as keywords, operators, and punctuation—are considered; variable names and identifiers are excluded from parsing.). • High-impact tokens…
Figure 5
Figure 5. Figure 5: Overview of DecoRTL Framework for RTL Generation. Given a design prompt (here the encryption controller FSM), the LLM generates RTL code (token by token) with two decoding-time enhancements: syntax-aware temperature adaptation adjusts sampling based on token type (the …

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

36 extracted references · 10 canonical work pages

  1. [9]

    Hot or cold? adaptive temperature sampling for code generation with large language models,

    Y . Zhu, J. Li, G. Li, Y . Zhao, Z. Jin, and H. Mei, “Hot or cold? adaptive temperature sampling for code generation with large language models,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 38, no. 1, 2024, pp. 437–445

  2. [1]

    DecoRTL Repository - A Run-time Decoding Framework for RTL Code Generation with LLMs, https://github.com/mhakyash/DecoRTL, 2025

  3. [2]

    Machine learning for electronic design automation: A survey,

    G. Huang, J. Hu, Y . He, J. Liu, M. Ma, Z. Shen, J. Wu, Y . Xu, H. Zhang, K. Zhong et al., “Machine learning for electronic design automation: A survey,”ACM Transactions on Design Automation of Electronic Systems (TODAES), vol. 26, no. 5, pp. 1–46, 2021

  4. [3]

    Chateda: A large language model powered autonomous agent for eda,

    H. Wu, Z. He, X. Zhang, X. Yao, S. Zheng, H. Zheng, and B. Yu, “Chateda: A large language model powered autonomous agent for eda,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2024

  5. [4]

    Chipgpt: How far are we from natural language hardware design,

    K. Chang, Y . Wang, H. Ren, M. Wang, S. Liang, Y . Han, H. Li, and X. Li, “Chipgpt: How far are we from natural language hardware design,” arXiv preprint arXiv:2305.14019 , 2023

  6. [5]

    Evolutionary large language models for hardware security: A comparative survey,

    M. Akyash and H. M Kamali, “Evolutionary large language models for hardware security: A comparative survey,” in Proceedings of the great lakes symposium on VLSI 2024 , 2024, pp. 496–501

  7. [6]

    Rtl++: Graph-enhanced llm for rtl code generation,

    M. Akyash, K. Azar, and H. Kamali, “Rtl++: Graph-enhanced llm for rtl code generation,” arXiv preprint arXiv:2505.13479 , 2025

  8. [7]

    Origen: Enhancing rtl code generation with code-to-code augmentation and self-reflection,

    F. Cui, C. Yin, K. Zhou, Y . Xiao, G. Sun, Q. Xu, Q. Guo, D. Song, D. Lin, X. Zhang et al. , “Origen: Enhancing rtl code generation with code-to-code augmentation and self-reflection,” arXiv preprint arXiv:2407.16237, 2024

Show all 36 references
  1. [8]

    Rtl- coder: Fully open-source and efficient llm-assisted rtl code generation technique,

    S. Liu, W. Fang, Y . Lu, J. Wang, Q. Zhang, H. Zhang, and Z. Xie, “Rtl- coder: Fully open-source and efficient llm-assisted rtl code generation technique,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , 2024

  2. [10]

    Simeval: Investigating the similarity obstacle in llm-based hardware code generation,

    M. Akyash and H. Mardani Kamali, “Simeval: Investigating the similarity obstacle in llm-based hardware code generation,” in Proceedings of the 30th Asia and South Pacific Design Automation Conference, ser. ASPDAC ’25. New York, NY , USA: Association for Computing Machinery, 20...

  3. [11]

    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,” in 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD) . IEEE, 2023, pp. 1–8

  4. [12]

    Evaluating large language models trained on code,

    M. Chen et al. , “Evaluating large language models trained on code,”

  5. [13]

    Codegen: An open large language model for code with multi-turn program synthesis,

    E. Nijkamp, B. Pang, H. Hayashi, L. Tu, H. Wang, Y . Zhou, S. Savarese, and C. Xiong, “Codegen: An open large language model for code with multi-turn program synthesis,” arXiv preprint arXiv:2203.13474 , 2022

  6. [14]

    Competition-level code generation with alphacode,

    Y . Li et al. , “Competition-level code generation with alphacode,” Science, vol. 378, no. 6624, p. 1092–1097, Dec. 2022. [Online]. Available: http://dx.doi.org/10.1126/science.abq1158

  7. [15]

    Diverse beam search for improved description of complex scenes,

    A. Vijayakumar, M. Cogswell, R. Selvaraju, Q. Sun, S. Lee, D. Crandall, and D. Batra, “Diverse beam search for improved description of complex scenes,” Proceedings of the AAAI Conference on Artificial Intelligence , vol. 32, no. 1, Apr. 2018. [Online]. Available: https://ojs.a...

  8. [16]

    Hierarchical neural story generation,

    A. Fan, M. Lewis, and Y . Dauphin, “Hierarchical neural story generation,” in Proceedings of the 56th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) , I. Gurevych and Y . Miyao, Eds. Melbourne, Australia: Association for Computational L...

  9. [17]

    Towards llm-powered verilog rtl assistant: Self-verification and self-correction,

    H. Huang, Z. Lin, Z. Wang, X. Chen, K. Ding, and J. Zhao, “Towards llm-powered verilog rtl assistant: Self-verification and self-correction,” arXiv preprint arXiv:2406.00115 , 2024

  10. [18]

    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,” arXiv preprint arXiv:2409.11414 , 2024

  11. [19]

    Self-hwdebug: Automation of llm self- instructing for hardware security verification,

    M. Akyash and H. M. Kamali, “Self-hwdebug: Automation of llm self- instructing for hardware security verification,” in 2024 IEEE Computer Society Annual Symposium on VLSI (ISVLSI) , 2024, pp. 391–396

  12. [20]

    Llm-ift: Llm- powered information flow tracking for secure hardware,

    N. Mashnoor, M. Akyash, H. Kamali, and K. Azar, “Llm-ift: Llm- powered information flow tracking for secure hardware,” in 2025 IEEE 43rd VLSI Test Symposium (VTS) , 2025, pp. 1–5

  13. [21]

    Mg-verilog: Multi- grained dataset towards enhanced llm-assisted verilog generation,

    Y . Zhang, Z. Yu, Y . Fu, C. Wan, and Y . C. Lin, “Mg-verilog: Multi- grained dataset towards enhanced llm-assisted verilog generation,” in 2024 IEEE LLM Aided Design Workshop (LAD) . IEEE, 2024, pp. 1–5

  14. [22]

    Craftrtl: High-quality synthetic data generation for verilog code models with correct-by- construction non-textual representations and targeted code repair,

    M. Liu, Y .-D. Tsai, W. Zhou, and H. Ren, “Craftrtl: High-quality synthetic data generation for verilog code models with correct-by- construction non-textual representations and targeted code repair,” arXiv preprint arXiv:2409.12993, 2024

  15. [23]

    Codev: Empowering llms for verilog generation through multi-level summarization,

    Y . Zhao, D. Huang, C. Li, P. Jin, Z. Nan, T. Ma, L. Qi, Y . Pan, Z. Zhang, R. Zhang et al. , “Codev: Empowering llms for verilog generation through multi-level summarization,” arXiv preprint arXiv:2407.10424 , 2024

  16. [24]

    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 Transactions on Design Automation of Electronic Systems, vol. 29, no. 3, pp. 1–31, 2024

  17. [25]

    Betterv: Con- trolled verilog generation with discriminative guidance,

    Z. Pei, H.-L. Zhen, M. Yuan, Y . Huang, and B. Yu, “Betterv: Con- trolled verilog generation with discriminative guidance,” arXiv preprint arXiv:2402.03375, 2024

  18. [26]

    Language mod- els are few-shot learners,

    T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell et al., “Language mod- els are few-shot learners,” Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020

  19. [27]

    The good, the bad, and the greedy: Evaluation of llms should not ignore non-determinism,

    Y . Song, G. Wang, S. Li, and B. Y . Lin, “The good, the bad, and the greedy: Evaluation of llms should not ignore non-determinism,” arXiv preprint arXiv:2407.10457, 2024

  20. [28]

    The effect of sampling temperature on problem solving in large language models,

    M. Renze, “The effect of sampling temperature on problem solving in large language models,” in Findings of the Association for Computa- tional Linguistics: EMNLP 2024 , 2024, pp. 7346–7356

  21. [29]

    The curious case of neural text degeneration,

    A. Holtzman, J. Buys, L. Du, M. Forbes, and Y . Choi, “The curious case of neural text degeneration,” 2020. [Online]. Available: https://arxiv.org/abs/1904.09751

  22. [30]

    Dola: Decoding by contrasting layers improves factuality in large language models,

    Y .-S. Chuang, Y . Xie, H. Luo, Y . Kim, J. Glass, and P. He, “Dola: Decoding by contrasting layers improves factuality in large language models,” arXiv preprint arXiv:2309.03883 , 2023

  23. [31]

    A contrastive framework for neural text generation,

    Y . Su, T. Lan, Y . Wang, D. Yogatama, L. Kong, and N. Collier, “A contrastive framework for neural text generation,” 2022. [Online]. Available: https://arxiv.org/abs/2202.06417

  24. [32]

    Contrastive decoding: Open- ended text generation as optimization,

    X. L. Li, A. Holtzman, D. Fried, P. Liang, J. Eisner, T. Hashimoto, L. Zettlemoyer, and M. Lewis, “Contrastive decoding: Open- ended text generation as optimization,” 2023. [Online]. Available: https://arxiv.org/abs/2210.15097

  25. [33]

    Contrastive decoding improves reasoning in large language models,

    S. O’Brien and M. Lewis, “Contrastive decoding improves reasoning in large language models,” arXiv preprint arXiv:2309.09117 , 2023

  26. [34]

    Qwen2. 5-coder technical report,

    B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Lu et al. , “Qwen2. 5-coder technical report,” arXiv preprint arXiv:2409.12186, 2024

  27. [35]

    Code llama: Open foundation models for code,

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remez et al. , “Code llama: Open foundation models for code,” arXiv preprint arXiv:2308.12950 , 2023

  28. [2021]

    Available: https://arxiv.org/abs/2107.03374

    [Online]. Available: https://arxiv.org/abs/2107.03374

Pith tools

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