hdl2v: A Code Translation Dataset for Enhanced LLM Verilog Generation

Advay Ratan; Alex Um; Brendan Roberts; Charles Hong; Huijae An; Yakun Sophia Shao

REVIEW 3 major objections 6 minor 38 references

hdl2v: A Code Translation Dataset for Enhanced LLM Verilog Generation

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

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

Pith's one-line read Fine-tuning a 32-billion-parameter open-weight LLM on 46,549 VHDL-, Chisel-, and PyMTL3-to-Verilog pairs improves VerilogEvalV2 scores by up to 13% at pass@1 and 23% at pass@10.

desk verdict A solid dataset paper with a contamination question that must be answered before the headline numbers are trusted; otherwise the work is a clean contribution. read the letter →

arxiv 2506.04544 v2 pith:ER2RRTEP submitted 2025-06-05 cs.AR cs.AIcs.LGcs.PL

Charles Hong , Brendan Roberts , Huijae An , Alex Um , Advay Ratan , Yakun Sophia Shao This is my paper

classification cs.ARcs.AIcs.LGcs.PL

keywords hdl2vVeriloggenerationHDL-to-VerilogtranslationLLMfine-tuningVHDLChiselPyMTL3Eval

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

Hardware design needs Verilog, but public Verilog is scarce compared with software code. This paper presents hdl2v, a dataset of 46,549 pairs in which VHDL, Chisel, or PyMTL3 code is translated or compiled to Verilog, and claims that fine-tuning a 32-billion-parameter open-weight LLM on these pairs improves VerilogEvalV2 performance by up to 13% at pass@1 and 23% at pass@10, with no data augmentation or distillation from larger models. It additionally claims that VHDL-Verilog pairs transfer better than C-Verilog pairs from the same designs, and that the model learns mostly from code rather than natural-language comments. The dataset is meant as a complement to existing Verilog fine-tuning data, and the paper shows it can also boost a data-augmentation pipeline, increasing the fine-tuning gain by 63%.

What carries the argument

The central object is hdl2v itself: a dataset of 46,549 prompt-response pairs in which the prompt is a hardware description in VHDL, Chisel, or PyMTL3 and the response is the corresponding Verilog module, obtained respectively by a VHDL-to-Verilog translator, by compiling Chisel designs from an SoC generator framework, and by compiling PyMTL3 designs through its Verilog translation pass. The mechanism is supervised fine-tuning on these pairs, which teaches the model to map HDL constructs and design intent onto Verilog syntax that it may not have seen during pretraining. The paper also uses perplexity, type-token ratio, and n-gram diversity of the Verilog responses to characterize what makes a translation dataset useful, and it performs ablations that remove comments or obfuscate variable names to isolate what the model actually learns.

What would settle it

Run a contamination check that matches hdl2v prompts and their source repositories against VerilogEvalV2 problem statements and reference solutions, then recompute pass@1 and pass@10 after excluding all overlapping or near-duplicate designs; if the gains largely disappear, the central claim is refuted.

Watch

Extended reading notes

Core claim

The central claim is that existing non-Verilog HDL code can be turned into novel Verilog training data by translation or compilation, and that this data materially improves LLM Verilog generation. Concretely, the paper constructs 8,626 VHDL-to-Verilog pairs via an open-source translator, 18,939 Chisel-to-Verilog pairs by compiling SoC configurations, and 18,636 PyMTL3-to-Verilog pairs by compiling PyMTL3 code, for 46,549 total. Fine-tuning a 32-billion-parameter open-weight coder LLM on combinations of these pairs raises VerilogEvalV2 pass@10 from 58.8% to 72.2% and pass@1 to 50.2%, which the paper attributes to the diversity and pre-training-novelty of the translated Verilog rather than to augmentation or knowledge distillation. It also establishes that, holding designs constant, VHDL-translated data outperforms C-translated data, and that removing comments barely hurts while obfuscating variable names sharply degrades performance, which it interprets as evidence the model learns from code structure, not natural language.

Load-bearing premise

The fine-tuning data is assumed to be essentially disjoint from the VerilogEvalV2 evaluation problems, so the measured gains reflect better Verilog generation rather than memorization; the paper performs no contamination check, and the PyMTL3 subset is drawn from a benchmark with designs similar to VerilogEval.

Editorial extensions

If this is right

VerilogEvalV2 pass@10 for a 32-billion-parameter open-weight model rises from 58.8% to 72.2% after fine-tuning on combined hdl2v data, so translation pairs alone are a practical fine-tuning signal.
Adding hdl2v VHDL and Chisel data to an augmented-Verilog training set lifts the fine-tuning gain from 3.8 to 6.6 percentage points, so the dataset strengthens, rather than duplicates, data augmentation.
When designs are held constant, VHDL-to-Verilog pairs outperform C-to-Verilog pairs on VerilogEvalV2, indicating that domain-close HDL translation is more useful than translation through a software language.
Removing comments from the VHDL dataset barely changes pass@10, while obfuscating variable names drops it from 59.8% to 39.1%, indicating that the model transfers code structure and meaningful identifiers, not natural-language comment content.

Reading between the lines

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

Because the paper does not run a contamination check and the PyMTL3 subset is built from a benchmark whose designs are similar to VerilogEval, a reader should treat the PyMTL3-specific gains and part of the combined gains as provisional until overlap with VerilogEvalV2 is measured.
The same translate-and-fine-tune recipe could be applied to other HDLs such as MyHDL, Amaranth, or SpinalHDL, and the VHDL-versus-C result predicts that languages with RTL semantics close to Verilog will transfer better than general-purpose software languages.
Dataset-size and entry-length differences are not controlled in the combination experiments; an alternative design that balances token volume and sampling order across languages could separate the effect of language choice from the effect of sheer training-data volume.
The comment-removal result suggests that adding natural-language descriptions to translation pairs may contribute less than preserving meaningful identifiers and code structure, which is a testable prediction for future dataset-construction work.

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.

Desk Editor's Note

read the letter

Short version: hdl2v is a genuinely useful dataset, and the central claim holds up under a skeptical read. The main risk is train/eval overlap, and the experimental reporting could be tighter, but this deserves peer review, not a desk reject.

What's actually new: this is the first dataset, as far as I know, to translate VHDL, Chisel, and PyMTL3 to Verilog for LLM fine-tuning, and it's shipped openly. That's a real resource. The experiments are well-designed: two model sizes, a sensible set of ablations, and a clean C-vs-VHDL comparison that isolates language choice. The comment-removal/obfuscation ablation is a nice touch, and the finding that meaningful names matter more than comments is informative.

The soft spots are in the empirical claims. Every fine-tuning run is single-seed, with no error bars or significance tests. Given consistent direction across configurations, that's a limitation, not a fatal flaw, but it should be stated. The 63% augmentation-boost claim has a baseline inconsistency: the text says 54.8, Figure 6 shows 54.4. Small, but it should be fixed.

The bigger issue is the PyMTL3 subset. It's built from PyHDL-Eval, which the paper itself says covers designs similar to VerilogEval. The individual PyMTL3 numbers (pass@10 69.3 vs 58.8) could be inflated by memorization. The strongest combined result in Figure 5 excludes PyMTL3, so the main claim doesn't rest on that subset. Still, the paper should run a contamination audit for all three subsets, especially VHDL and Chisel, and either report exact-match rates or de-emphasize the PyMTL3 result. Since both hdl2v and VerilogEvalV2 are public, this is a direct check rather than a theoretical objection.

One more overreach: the conclusion calls the Verilog 'unseen in pre-training corpora' without verification. That's plausible for VHDL-sourced Verilog, but it's asserted, not shown.

Who this is for: anyone working on LLM-assisted hardware design or low-resource code generation. The dataset alone is worth having. I'd send this to review, with the contamination check and multi-seed runs as expected revisions rather than desk-reject conditions.

Referee Report

3 major / 6 minor

Summary. The manuscript presents hdl2v, a dataset of 46,549 pairs in which VHDL entities, Chisel modules, and PyMTL3 components are translated or compiled to Verilog. The authors fine-tune Qwen2.5-Coder-32B-Instruct on individual and combined subsets and report VerilogEvalV2 spec-to-rtl improvements of up to 13% for pass@1 and 23% for pass@10 (Section V-B, Figure 5), and a case study with Qwen2.5-Coder-7B-Instruct in which adding VHDL and Chisel augmented data to gpt-4o-augmented Verilog data increases the fine-tuning delta over the base model by 63% (Section V-C, Figure 6). The paper also reports dataset statistics and ablations that isolate C versus VHDL translation and the effect of comments and variable names on learning.

Significance. If the reported gains are not confounded by training/evaluation overlap, hdl2v is a useful and reasonably large open resource: it is, to the authors' knowledge, the first dataset to translate non-Verilog HDLs to Verilog for LLM fine-tuning, and the positive results are consistent in direction across two model sizes and several ablations. The datasets are publicly released, which enables direct external verification and reuse. The main uncertainties are contamination and variance, so the contribution's value is clear but the exact magnitude of the headline numbers is not yet established.

major comments (3)

[Sections V-A and III-B3; Figure 4] The paper does not report a contamination analysis between any hdl2v training subset and the 156 VerilogEvalV2 evaluation problems. This is load-bearing because Section V-A states that the PyMTL3 subset targets 'a benchmark set of designs similar to VerilogEval' and Section III-B3 constructs that subset from PyHDL-Eval artifacts. If PyMTL3 examples reproduce the same designs or natural-language specifications as evaluation problems, the individual PyMTL3 result (49.4 vs. 44.6 pass@1 and 69.3 vs. 58.8 pass@10 in Figure 4) and part of the combined gains could reflect memorization rather than improved generation. The authors should perform an exact and near-duplicate overlap check per subset (VHDL, Chisel, and PyMTL3), remove overlapping entries, and re-report the main results.
[Section V-C and Figure 6] The 63% augmentation-boost claim is based on inconsistent baseline numbers. The text says 'Compared to the baseline of 54.8%,' but Figure 6 labels the base model pass@10 as 54.4%. With 54.4, the augmented-Verilog delta is 4.2 points and the best hdl2v-augmented delta is 6.6 points, which is a 57% increase; with 54.8, the deltas are 3.8 and 6.2 points, which is a 63% increase. The text, table, and figure must be reconciled and the percentage increase recomputed from the reported values.
[Sections V and VI, Figures 4-8] All fine-tuning results appear to be single-seed runs with no error bars, confidence intervals, or significance tests. Several conclusions depend on differences of a few percentage points, such as the claim in Section V-B that combining C and Verilog data yields no significant improvement and the C-versus-VHDL comparison in Figure 7. The authors should report multiple seeds or a variance estimate for the main comparisons, or explicitly qualify the ordering claims as preliminary.

minor comments (6)

[Section II-A] The phrase 'Prior work has seeked' should be 'Prior work has sought.'
[Section VI-A] The perplexity-to-accuracy formula is written as '1/perplexity × 100'; it should be '100/perplexity' or '1/perplexity × 100%.'
[Section III-B2] The sentence 'which contain a single Verilog module' should be 'which contains a single Verilog module.'
[Abstract and Sections I, III-B3] The abstract describes hdl2v as 'human-written Verilog data,' but the PyMTL3 subset is derived from LLM-generated PyMTL3 code from PyHDL-Eval and then compiled to Verilog; this qualification should be stated explicitly wherever the dataset is characterized as human-written.
[Section III-B3] The statement that PyHDL-Eval contains 'about 50,000' examples is imprecise; the exact number of examples obtained from the artifact should be reported.
[Reference [1]] Reference [1] is listed only as a URL; include the repository name and access date for completeness.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the headline gains rest on independently sourced VHDL and Chisel data, and the acknowledged PyMTL3/VerilogEval similarity is a contamination risk rather than a definitional reduction.

full rationale

The paper's central claims are empirical: translating VHDL, Chisel, and PyMTL3 to Verilog and fine-tuning Qwen2.5-Coder yields gains on the external VerilogEvalV2 benchmark. No equation defines the evaluand in terms of its input; no fitted parameter is renamed as a prediction; no load-bearing result is justified by a self-citation. The headline gains (up to 13% pass@1 and 23% pass@10) come from Chisel+VHDL combinations shown in Figure 5, with VHDL sourced from GitHub and Chisel from Chipyard, both independent of the evaluation benchmark. The VHDL-versus-C comparison in Section VI-B is controlled by using the same source designs for both translations. The only overlap-sensitive passage is Section V-A, which acknowledges that PyHDL-Eval 'generated code for a benchmark set of designs similar to VerilogEval', and the PyMTL3 subset is built from that artifact; this is a potential train/eval contamination risk for the individual PyMTL3 result, but it is not a circular definition or a fitted-input-as-prediction. Since the central result does not reduce to that subset and no derivation chain is self-referential, there is no circularity.

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

The central claim rests on benchmark validity, tool correctness, and train/test disjointness. The PyMTL3 subset makes the disjointness assumption fragile.

assumptions (3)

domain assumption VerilogEvalV2 is a valid proxy for Verilog generation ability
All performance claims are measured solely on this benchmark (Section IV-B); no corroborating benchmark is used.
domain assumption Translation tools (vhd2vl, v2c, Chipyard, PyMTL3 VerilogTranslationPass) produce correct Verilog that is useful for fine-tuning
The dataset constructs responses via these tools (Section III-B); errors in translation could bias the model.
domain assumption hdl2v train data does not overlap with VerilogEvalV2 test problems
The paper asserts the Verilog is novel/unseen (Section VII), but does not measure contamination; the PyMTL3 subset is derived from PyHDL-Eval, whose designs are similar to VerilogEval (Section V-A), so this assumption is fragile for that subset.

how reviews work

0 comments

Cite this review

Pith. "Pith review of hdl2v: A Code Translation Dataset for Enhanced LLM Verilog Generation." pith.science (2026). https://pith.science/paper/ER2RRTEP

@misc{pith2026250604544,
  author       = {Pith},
  title        = {Pith review of: hdl2v: A Code Translation Dataset for Enhanced LLM Verilog Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ER2RRTEP}},
  note         = {Machine review of arXiv:2506.04544}
}

read the original abstract

Large language models (LLMs) are playing an increasingly large role in domains such as code generation, including hardware code generation, where Verilog is the key language. However, the amount of publicly available Verilog code pales in comparison to the amount of code available for software languages like Python. In this work, we present hdl2v ("HDL-to-Verilog"), a dataset which seeks to increase the amount of available human-written Verilog data by translating or compiling three other hardware description languages - VHDL, Chisel, and PyMTL3 - to Verilog. Furthermore, we demonstrate the value of hdl2v in enhancing LLM Verilog generation by improving performance of a 32 billion-parameter open-weight model by up to 23% (pass@10) in VerilogEvalV2, without utilizing any data augmentation or knowledge distillation from larger models. We also show hdl2v's ability to boost the performance of a data augmentation-based fine-tuning approach by 63%. Finally, we characterize and analyze our dataset to better understand which characteristics of HDL-to-Verilog datasets can be expanded upon in future work for even better performance.

Figures

Figures reproduced from arXiv: 2506.04544 by the authors.

**Figure 1.** How the Verilog Completion, C, and VHDL datasets are collected. Note that Verilog is translated to C and VHDL is translated to Verilog, but during [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

**Figure 3.** How the PyMTL3 dataset is collected. are removed, but for cases where the same Chisel file with different parameters generates differing Verilog output, all the data is kept. This results in 18,939 Chisel/Verilog pairs (with a total size of 1.69 GB). We additionally collect the corresponding FIRRTL. We do not use it for any further experiments in this work, but include it in our dataset for future users. In our prom… view at source ↗

**Figure 4.** VerilogEvalV2 performance for Qwen2.5-Coder-32B-Instruct, after [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

Figures from the paper (5 more)

**Figure 5.** Figure 5: VerilogEvalV2 performance for Qwen2.5-Coder-32B-Instruct, after [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

**Figure 6.** Figure 6: VerilogEvalV2 performance of Qwen2.5-Coder-7B-Instruct, after [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]

**Figure 5.** Figure 5: However, adding PyMTL3 on top of this combination [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

**Figure 7.** Figure 7: VerilogEvalV2 performance for Qwen2.5-Coder-7B-Instruct, after [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]

**Figure 8.** Figure 8: VerilogEvalV2 performance for Qwen2.5-Coder-7B-Instruct, after [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

38 extracted references · 15 canonical work pages

[1]

Available: https://repositorystats.com/

[Online]. Available: https://repositorystats.com/

work page
[2]

Chipyard: Integrated design, simulation, and implementation framework for custom socs,

A. Amid, D. Biancolin, A. Gonzalez, D. Grubb, S. Karandikar, H. Liew, A. Magyar, H. Mao, A. Ou, N. Pemberton, P. Rigge, C. Schmidt, J. Wright, J. Zhao, Y . S. Shao, K. Asanovi´c, and B. Nikoli ´c, “Chipyard: Integrated design, simulation, and implementation framework for custom socs,” IEEE Micro, vol. 40, no. 4, pp. 10–21, 2020

2020
[3]

Chisel: constructing hardware in a scala embedded language,

J. Bachrach, H. V o, B. Richards, Y . Lee, A. Waterman, R. Avi ˇzienis, J. Wawrzynek, and K. Asanovi ´c, “Chisel: constructing hardware in a scala embedded language,” in Proceedings of the 49th Annual Design Automation Conference , ser. DAC ’12. New York, NY , USA: Association for Computing Machinery, 2012, p. 1216–1225. [Online]. Available: https://doi.o...

work page arXiv 2012
[4]

Pyhdl-eval: An llm evaluation framework for hardware design using python- embedded dsls,

C. Batten, N. Pinckney, M. Liu, H. Ren, and B. Khailany, “Pyhdl-eval: An llm evaluation framework for hardware design using python- embedded dsls,” in Proceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD , ser. MLCAD ’24. New York, NY , USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10....

arXiv 2024
[5]

Chip-chat: Chal- lenges and opportunities in conversational hardware design,

J. Blocklove, S. Garg, R. Karri, and H. Pearce, “Chip-chat: Chal- lenges and opportunities in conversational hardware design,” in 2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD) , 2023, pp. 1–6

work page 2023
[6]

Language models are few-shot learners,

T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert- V oss, G. Krueger, T. Henighan, R. Child, A. Ramesh, D. M. Ziegler, J. Wu, C. Winter, C. Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B. Chess, J. Clark, C. Berner, S. McCandlish, A. Radford, I. Sutskever, and D. Am...

work page 2020
[7]

Data is all you need: Finetuning llms for chip design via an automated design-data augmentation framework,

K. Chang, K. Wang, N. Yang, Y . Wang, D. Jin, W. Zhu, Z. Chen, C. Li, H. Yan, Y . Zhou, Z. Zhao, Y . Cheng, Y . Pan, Y . Liu, M. Wang, S. Liang, Y . Han, H. Li, and X. Li, “Data is all you need: Finetuning llms for chip design via an automated design-data augmentation framework,” in Proceedings of the 61st ACM/IEEE Design Automation Conference , ser. DAC ...

arXiv 2024
[8]

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,” 2023. [Online]. Available: https://arxiv.org/abs/2305.14019

arXiv 2023

Show all 38 references

[9]

Evaluating large language models trained on code,

M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H. Edwards, Y . Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374 , 2021

2021 arXiv
[10]

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, Y . Liang, X. Zhang, D. Song, and D. Lin, “Origen: Enhancing rtl code generation with code-to-code augmentation and self-reflection,” in Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design...

2025
[11]

Myhdl: a python-based hardware description language,

J. Decaluwe, “Myhdl: a python-based hardware description language,” Linux J., vol. 2004, no. 127, p. 5, Nov. 2004

2004
[12]

Doolittle, Sep 2015

L. Doolittle, Sep 2015. [Online]. Available: http://doolittle.icarus.com/ ∼larry/vhd2vl/

2015
[13]

Verilogcoder: Autonomous verilog coding agents with graph-based planning and abstract syntax tree (ast)-based waveform tracing tool,

C.-T. Ho, H. Ren, and B. Khailany, “Verilogcoder: Autonomous verilog coding agents with graph-based planning and abstract syntax tree (ast)-based waveform tracing tool,” 2025. [Online]. Available: https://arxiv.org/abs/2408.08927

2025 arXiv
[14]

Autocomp: Llm-driven code optimization for tensor accelerators,

C. Hong, S. Bhatia, A. Cheung, and Y . S. Shao, “Autocomp: Llm-driven code optimization for tensor accelerators,” 2025. [Online]. Available: https://arxiv.org/abs/2505.18574

2025
[15]

Llm-aided compilation for tensor accelerators,

C. Hong, S. Bhatia, A. Haan, S. K. Dong, D. Nikiforov, A. Cheung, and Y . S. Shao, “Llm-aided compilation for tensor accelerators,” in2024 IEEE LLM Aided Design Workshop (LAD) , 2024, pp. 1–14

2024
[16]

Lora: Low-rank adaptation of large language models,

E. J. Hu, Y . Shen, P. Wallis, Z. Allen-Zhu, Y . Li, S. Wang, L. Wang, and W. Chen, “Lora: Low-rank adaptation of large language models,”
[17]

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, K. Dang, Y . Fan, Y . Zhang, A. Yang, R. Men, F. Huang, B. Zheng, Y . Miao, S. Quan, Y . Feng, X. Ren, X. Ren, J. Zhou, and J. Lin, “Qwen2.5-coder technical report,” 2024. [Online]. Available: ...

2024 arXiv
[18]

Livecodebench: Holistic and contamination free evaluation of large language models for code,

N. Jain, K. Han, A. Gu, W.-D. Li, F. Yan, T. Zhang, S. Wang, A. Solar-Lezama, K. Sen, and I. Stoica, “Livecodebench: Holistic and contamination free evaluation of large language models for code,” arXiv preprint arXiv:2403.07974, 2024

2024 arXiv
[19]

Pymtl3: A python framework for open-source hardware modeling, generation, simulation, and verifi- cation,

S. Jiang, P. Pan, Y . Ou, and C. Batten, “Pymtl3: A python framework for open-source hardware modeling, generation, simulation, and verifi- cation,” IEEE Micro, vol. 40, no. 4, pp. 58–66, 2020

2020
[20]

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

2023 arXiv
[21]

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,” 2025. [Online]. Available: https://arxiv.org/abs/2409.12993

2025 arXiv
[22]

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: htt...

2024
[23]

V2c – a verilog to c translator,

R. Mukherjee, M. Tautschnig, and D. Kroening, “V2c – a verilog to c translator,” vol. 9636. Springer, 2016, pp. 580–586

2016
[24]

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

2022 arXiv
[25]

Gpt-4 technical report,

OpenAI et al., “Gpt-4 technical report,” 2024

2024
[26]

Spinalhdl

C. Papon and Y . Xiao, “Spinalhdl.” [Online]. Available: https: //github.com/SpinalHDL/SpinalHDL
[27]

Gorilla: Large language model connected with massive apis,

S. G. Patil, T. Zhang, X. Wang, and J. E. Gonzalez, “Gorilla: Large language model connected with massive apis,” arXiv preprint arXiv:2305.15334, 2023

2023 arXiv
[28]

Betterv: controlled verilog generation with discriminative guidance,

Z. Pei, H.-L. 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. ICML’24. JMLR.org, 2024

2024
[29]

Revisiting verilogeval: A year of improvements in large-language models for hardware code generation,

N. Pinckney, C. Batten, M. Liu, H. Ren, and B. Khailany, “Revisiting verilogeval: A year of improvements in large-language models for hardware code generation,” 2025. [Online]. Available: https://arxiv.org/abs/2408.11053

2025 arXiv
[30]

Zero: Memory optimizations toward training trillion parameter models,

S. Rajbhandari, J. Rasley, O. Ruwase, and Y . He, “Zero: Memory optimizations toward training trillion parameter models,” 2020. [Online]. Available: https://arxiv.org/abs/1910.02054

2020 arXiv
[31]

Benchmarking large language models for auto- mated verilog rtl code generation,

S. Thakur, B. Ahmad, Z. Fan, H. Pearce, B. Tan, R. Karri, B. Dolan- Gavitt, and S. Garg, “Benchmarking large language models for auto- mated verilog rtl code generation,” in 2023 Design, Automation & Test in Europe Conference & Exhibition (DATE) , 2023, pp. 1–6

2023
[32]

Icarus verilog: open-source verilog more than a year later,

S. Williams and M. Baxter, “Icarus verilog: open-source verilog more than a year later,” Linux J., vol. 2002, no. 99, p. 3, Jul. 2002

2002
[33]

Haven: Hallucination-mitigated llm for verilog code generation aligned with hdl engineers,

Y . Yang, F. Teng, P. Liu, M. Qi, C. Lv, J. Li, X. Zhang, and Z. He, “Haven: Hallucination-mitigated llm for verilog code generation aligned with hdl engineers,” 2025. [Online]. Available: https://arxiv.org/abs/2501.04908

2025 arXiv
[34]

Deepspeed-chat: Easy, fast and affordable rlhf training of chatgpt-like models at all scales,

Z. Yao, R. Y . Aminabadi, O. Ruwase, S. Rajbhandari, X. Wu, A. A. Awan, J. Rasley, M. Zhang, C. Li, C. Holmes, Z. Zhou, M. Wyatt, M. Smith, L. Kurilenko, H. Qin, M. Tanaka, S. Che, S. L. Song, and Y . He, “Deepspeed-chat: Easy, fast and affordable rlhf training of chatgpt-like...

2023 arXiv
[35]

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,”
[36]

Mage: A multi-agent engine for automated rtl code generation,

Y . Zhao, H. Zhang, H. Huang, Z. Yu, and J. Zhao, “Mage: A multi-agent engine for automated rtl code generation,” 2024. [Online]. Available: https://arxiv.org/abs/2412.07822 7

2024 arXiv
[2021]

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

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

arXiv
[2024]

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

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

arXiv

Pith tools

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

[1] [1]

Available: https://repositorystats.com/

[Online]. Available: https://repositorystats.com/

work page

[2] [2]

Chipyard: Integrated design, simulation, and implementation framework for custom socs,

A. Amid, D. Biancolin, A. Gonzalez, D. Grubb, S. Karandikar, H. Liew, A. Magyar, H. Mao, A. Ou, N. Pemberton, P. Rigge, C. Schmidt, J. Wright, J. Zhao, Y . S. Shao, K. Asanovi´c, and B. Nikoli ´c, “Chipyard: Integrated design, simulation, and implementation framework for custom socs,” IEEE Micro, vol. 40, no. 4, pp. 10–21, 2020

2020

[3] [3]

Chisel: constructing hardware in a scala embedded language,

J. Bachrach, H. V o, B. Richards, Y . Lee, A. Waterman, R. Avi ˇzienis, J. Wawrzynek, and K. Asanovi ´c, “Chisel: constructing hardware in a scala embedded language,” in Proceedings of the 49th Annual Design Automation Conference , ser. DAC ’12. New York, NY , USA: Association for Computing Machinery, 2012, p. 1216–1225. [Online]. Available: https://doi.o...

work page arXiv 2012

[4] [4]

Pyhdl-eval: An llm evaluation framework for hardware design using python- embedded dsls,

C. Batten, N. Pinckney, M. Liu, H. Ren, and B. Khailany, “Pyhdl-eval: An llm evaluation framework for hardware design using python- embedded dsls,” in Proceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD , ser. MLCAD ’24. New York, NY , USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10....

arXiv 2024

[5] [5]

Chip-chat: Chal- lenges and opportunities in conversational hardware design,

J. Blocklove, S. Garg, R. Karri, and H. Pearce, “Chip-chat: Chal- lenges and opportunities in conversational hardware design,” in 2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD) , 2023, pp. 1–6

work page 2023

[6] [6]

Language models are few-shot learners,

T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert- V oss, G. Krueger, T. Henighan, R. Child, A. Ramesh, D. M. Ziegler, J. Wu, C. Winter, C. Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B. Chess, J. Clark, C. Berner, S. McCandlish, A. Radford, I. Sutskever, and D. Am...

work page 2020

[7] [7]

Data is all you need: Finetuning llms for chip design via an automated design-data augmentation framework,

K. Chang, K. Wang, N. Yang, Y . Wang, D. Jin, W. Zhu, Z. Chen, C. Li, H. Yan, Y . Zhou, Z. Zhao, Y . Cheng, Y . Pan, Y . Liu, M. Wang, S. Liang, Y . Han, H. Li, and X. Li, “Data is all you need: Finetuning llms for chip design via an automated design-data augmentation framework,” in Proceedings of the 61st ACM/IEEE Design Automation Conference , ser. DAC ...

arXiv 2024

[8] [8]

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,” 2023. [Online]. Available: https://arxiv.org/abs/2305.14019

arXiv 2023