Pith. sign in

REVIEW 5 major objections 5 minor 55 references

VerilogDB: The Largest, Highest-Quality Dataset with a Preprocessing Framework for LLM-based RTL Generation

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

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

Pith's one-line read VerilogDB claims to be the largest synthesis-verified Verilog dataset for LLM-based RTL generation, with 20,392 unique modules produced by an automated preprocessing pipeline.

desk verdict Useful dataset-pipeline idea, but the headline numbers and per-module synthesis claim don't hold up as reported; deserves a conditional review, not a desk reject. read the letter →

arxiv 2507.13369 v1 pith:GFOSUESM submitted 2025-07-09 cs.AR cs.AIcs.LG

Paul E. Calzada , Zahin Ibnat , Tanvir Rahman , Kamal Kandula , Danyu Lu , Sujan Kumar Saha , Farimah Farahmandi , Mark Tehranipoor This is my paper
classification cs.ARcs.AIcs.LG
keywords VerilogdatasetRTLcodegenerationlargelanguagemodelslogicsynthesisverificationdatapreprocessinginstructiontuninghardwaredesignautomationopen-source
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

VerilogDB is an attempt to fix the data bottleneck in LLM-based Verilog and RTL generation: prior fine-tuning datasets were small, manually filtered, or lacked synthesizability checks. The paper claims to deliver the largest dataset of its kind to its knowledge, 20,392 unique, synthesizable modules totaling 751 MB, produced by an automated pipeline that scrapes open-source Verilog, removes duplicates, checks syntax, runs logic synthesis, and extracts per-module metadata. The design goal is to give an LLM training corpus that reflects real-world RTL diversity, including hierarchical designs, while excluding code that only simulates or does not synthesize. If the claim is right, the dataset gives researchers an instruction-ready prompt-response corpus for fine-tuning RTL code generators, and a reusable pipeline for keeping such a corpus current. The paper itself does not fine-tune a model; it presents dataset construction, filtering statistics, and distribution analysis.

What carries the argument

The load-bearing mechanism is the preprocessing pipeline's project-level synthesis gate. After MD5-based deduplication and per-file syntax checking with Icarus Verilog, Algorithm 3 collects every file in a project, auto-detects a top module, and runs Yosys's 'synth -top top_module'; only files in projects that synthesize are advanced to metadata extraction. The metadata stage then uses regex to parse module names, ANSI and Non-ANSI ports, parameters, and comments, estimates LLM token counts with a custom tokenizer, and calls o3-mini to write a one-sentence description, storing the result in JSON inside a PostgreSQL database. This chain, especially the Yosys synthesis check, is what the paper credits for excluding non-synthesizable and simulation-only code without manual review.

What would settle it

Take every one of the 20,392 output modules, run Yosys on each file in isolation with the module as its own top, and count failures; if a substantial fraction do not synthesize standalone, the '20,392 unique, synthesizable modules' claim overstates what the pipeline verified. A second check: sample modules with generated descriptions and compare each description to the module's actual behavior in simulation.

Watch

Extended reading notes

Core claim

The paper's central claim is that synthesis-aware cleaning can be fully automated at scale without the manual sample-by-sample verification used by earlier efforts. Its counting claim: after processing roughly 30 GB of raw Verilog from GitHub, OpenCores, and academic sources, 72,600 modules survived initial filtering, 63.07% of deduplicated modules passed Icarus Verilog syntax checking, 69.49% of those passed Yosys synthesis, and 99.01% of those yielded complete metadata, leaving 20,392 unique modules in 751 MB. The paper asserts this is the largest high-quality Verilog dataset for LLM fine-tuning to its knowledge and the first such dataset to include explicit logic-synthesis checks and hierarchical designs. It frames the dataset as ready for instruction tuning once the extracted metadata (module name, ports, comments, token count, and an o3-mini-generated one-sentence description) is turned into prompt-response pairs.

Load-bearing premise

The pipeline counts a module as synthesizable whenever its whole project passes a single Yosys synthesis run, even though modules not on the top module's instantiation path, or modules that only work because of sibling files or macros, may not synthesize on their own; it also assumes the automatically generated one-sentence descriptions used as instruction prompts are accurate enough, though the paper concedes they are occasionally generic or inaccurate.

Editorial extensions

If this is right

  • An LLM fine-tuned on the 20,392 prompt-response pairs should generalize across more RTL constructs and coding styles than models trained on smaller, hand-curated corpora.
  • The same automated pipeline can be re-run on newly scraped repositories, so the dataset can stay current without re-doing manual filtering.
  • Because token counts and port counts are stored, training samples can be selected to fit a given model's context window, such as 4,096 or 8,192 tokens.
  • The dataset can also feed retrieval-augmented generation systems once the modules are vectorized, as the paper notes in its DeepC discussion.
  • The reported per-stage retention rates give downstream users a quantitative expectation of how much raw Verilog survives cleaning.

Reading between the lines

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

  • Because synthesis is run project-wide rather than per module, a module that only synthesizes as part of a larger project, or one not on the top module's instantiation path, may still be counted among the 20,392 'synthesizable modules'; re-running the gate on each module in isolation would likely shrink the count.
  • The o3-mini descriptions become the instruction prompts, so any inaccuracy or generic phrasing in those descriptions becomes part of the training signal; the dataset's 'quality' is therefore bounded by the description generator as well as by synthesis.
  • With 46.17% of modules classified as basic digital building blocks and most modules under 100 lines, the dataset's practical diversity tilts toward small designs; rebalancing or augmentation would be needed before claiming coverage of complex SoC-level RTL.
  • A useful next experiment would be to fine-tune the same base model on VerilogDB versus prior datasets such as RTLCoder or MG-Verilog and compare pass rates on VerilogEval-style benchmarks; the paper itself does not report such a head-to-head.
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 / 5 minor

Summary. This manuscript introduces VerilogDB, a dataset and automated preprocessing pipeline intended for fine-tuning LLMs on Verilog RTL generation. The pipeline scrapes GitHub, OpenCores, and academic sources; filters out testbenches, netlists, and SystemVerilog files; removes exact duplicates via MD5 hashing; validates syntax with Icarus Verilog; checks synthesizability with Yosys; extracts module metadata and o3-mini-generated descriptions; stores results in PostgreSQL; and formats instruction-tuning prompts. The headline result is a dataset of 20,392 unique, supposedly synthesizable Verilog modules totaling 751 MB, which the authors claim is the largest high-quality dataset of its kind. The paper also reports distribution analyses by functional class, complexity, and comment density, and discusses applications to LLM fine-tuning and retrieval-augmented generation.

Significance. If the headline claims are correct, VerilogDB would be a practically useful resource: it is larger than many prior RTL corpora, it combines multi-source collection with automated syntax and synthesis checks, and its JSON/PostgreSQL metadata format is well suited to instruction tuning. The use of explicit logic-synthesis validation and structured metadata extraction are genuine strengths of the pipeline, and no equation-level circularity or invented entities are apparent. However, the significance is conditional: the reported funnel statistics are internally inconsistent, the synthesis check is performed at the project level rather than per extracted module, and at least one headline quality statistic is mathematically impossible under its stated definition. These issues directly affect the central claims of dataset size and dataset quality, so the contribution cannot be fully assessed until they are resolved.

major comments (5)
  1. [§4.1, Table 1] The reported preprocessing funnel is numerically inconsistent with the final module count. Starting from 72,600 modules and applying the stated retention rates in sequence, 72,600 × 0.8753 × 0.6307 × 0.6949 × 0.9901 ≈ 27,600 modules, not 20,392. Since the 20,392 figure is the headline result, please reconcile the percentages with the final count and report module counts at each stage rather than only MB values.
  2. [§3.2.4, Algorithm 3] The synthesis check validates at the project/top-module level, not at the level of each extracted module. Algorithm 3 reads all files in a project, auto-detects one top module, runs hierarchy and synth with that top, and if no errors are found, all files in the project proceed to metadata extraction. Modules not on the chosen top's instantiation path, or modules that elaborate only because of project-specific macros, parameters, or sibling files, can therefore be counted among the 20,392 "synthesizable modules." Because the released JSON entries store isolated module code, the paper's core quality guarantee is not established. Please either run Yosys per module on the isolated module file, or explicitly reword the claim to state that synthesis was verified at the project level. Section 4.3.1's own observation that many syntactically valid files failed synthesis due to unresolved submodules or macro dependencies illustrates exactly this concern.
  3. [§4.2.3] The reported mean comment density of 1093.71% is impossible under the definition given in the same section: if comment density is comment characters divided by total characters of the Verilog code, then every module's density is at most 100%, and the mean over the 11,009 commented modules cannot exceed 100%. This indicates either a different density formula (e.g., comment characters divided by non-comment characters), a data error, or a misstatement of the metric. Please correct the definition or the statistic and report the distribution consistently.
  4. [§3.4 and §4.3.2] The instruction-tuning prompts are constructed from o3-mini's one-sentence descriptions, yet Section 4.3.2 concedes that these descriptions are "occasionally generic or inaccurate." The database validation stage checks schema conformance of the metadata, not the semantic correctness of the descriptions. Given that the dataset is intended for LLM instruction tuning, the accuracy of these prompt-side descriptions is load-bearing. Please add a quantitative audit of description quality, or clearly separate human-verified metadata from LLM-generated annotations in the released artifacts.
  5. [§3.1–§4] No dataset release URL, DOI, or access instructions appear anywhere in the manuscript. Since the central contribution is the dataset itself, a public artifact location is necessary for readers to download the corpus and independently verify the 20,392-module count and the synthesis claims. Please add an availability statement or explain how reviewers can access the data during the review process.
minor comments (5)
  1. [§4.2.1] The text says "761 MB of Verilog data" immediately after Figure 6, while all other places report 751 MB; please make the numbers consistent.
  2. [Figure 7 caption] The caption lists panels as "(a) functional classes, (b) line count, and (c) estimated token count," but the figure panels are labeled "(a) Line counts" and "(b) Estimated token counts"; the caption and the figure labels should be reconciled.
  3. [Algorithm 3] The return-code convention is confusing: Algorithm 3 returns False to indicate a passed synthesis check and True for failure, while Algorithm 2 returns True for a passed syntax check; please unify the conventions across the two algorithms.
  4. [§3.2.3] The tool is referred to as "iVerilog" here but as "Icarus Verilog" and "iverilog" elsewhere; please standardize the spelling.
  5. [Appendix, Table 3] Class 10 in Table 3 is "Verification-Only Designs" and lists basic testbenches, scoreboards, and interface monitors as examples, which appears to contradict Section 3.2.1's statement that testbenches and simulation artifacts are removed from the dataset; please clarify whether any such modules actually remain in the final dataset and, if so, how they are synthesizable.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: VerilogDB's central claims rest on external collection, external synthesis tools, and reported pipeline statistics, not on fitted parameters or a self-citation chain.

full rationale

VerilogDB is a dataset-construction paper, not a predictive derivation. The central claim that the pipeline produced 20,392 unique, synthesizable modules with metadata (Section 4.1) is a report of a preprocessing run whose inputs (GitHub/OpenCores/academic sources) and validation tools (iverilog, Yosys, PostgreSQL) are external. There is no equation-level reduction, no fitted parameter renamed as a prediction, and no uniqueness theorem imported from the authors' prior work. The paper's own prior publications (references [35]-[37]) appear only in background on LLM hardware-security applications and do not carry the dataset-quality argument. Two self-referential elements exist but are not load-bearing: (i) the dataset's 'high-quality' is operationalized as passing the paper's own syntax/synthesis/metadata stages, which is a definitional quality criterion rather than a circular derivation; and (ii) o3-mini generated the instruction descriptions (Section 3.2.5) and later classified modules for the diversity analysis (Section 4.2.1), so the same model labels part of the dataset and one analysis of it. However, the central claims of scale (751 MB, 20,392 modules) and synthesizability are established by Yosys runs and pipeline logs, not by o3-mini's labels; the paper even concedes in Section 4.3.2 that o3-mini descriptions 'occasionally produced generic or inaccurate descriptions.' The main substantive weakness is a correctness/validity concern rather than circularity: Algorithm 3 runs synthesis at project level with a single auto-detected top module, so a project-level pass does not strictly prove every extracted module is individually synthesizable (Section 3.2.4, Section 4.3.1). That overstatement weakens the 'synthesizable modules' wording but is not a derivation that reduces to its own inputs. No circular step meets the quoted-reduction bar.

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

The central claim rests on tool-based filtering (iverilog, Yosys), regex-based metadata extraction, and LLM-generated descriptions. None of these are formally verified, and the paper's own caveats (Section 4.3.2) weaken the quality guarantee. No free parameters are fitted, but the pipeline's effectiveness is assumed rather than demonstrated against an external benchmark, and the project-level synthesis assumption directly affects the 'synthesizable modules' claim.

assumptions (5)
  • domain assumption Icarus Verilog syntax checking and Yosys synthesis are reliable proxies for 'high-quality' and 'synthesizable' Verilog code.
    The entire filtering pipeline depends on these open-source tools to reject bad code; Section 3.2.3-3.2.4.
  • domain assumption Project-level Yosys synthesis success implies every module in that project is individually synthesizable.
    Algorithm 3 runs synthesis at project level with an auto-detected top module, and all files in passing projects advance to metadata extraction; Section 3.2.4.
  • domain assumption Regex patterns correctly extract module names, ports, parameters, and comments across diverse Verilog styles (ANSI and non-ANSI).
    The metadata extraction stage in Section 3.2.5 relies entirely on regex, and the paper admits regex coverage had to be extended to handle all cases.
  • domain assumption o3-mini generated descriptions are sufficiently accurate for instruction-tuning data.
    Descriptions become the prompt side of every fine-tuning pair; Section 4.3.2 concedes descriptions were occasionally generic or inaccurate.
  • domain assumption MD5 content hashing removes all problematic redundancy, including near-duplicates.
    The dedup rationale claims near-duplicate removal, but Algorithm 1 only removes byte-identical files; Section 4.3.1 overstates the claim.

how reviews work

0 comments
Cite this review

Pith. "Pith review of VerilogDB: The Largest, Highest-Quality Dataset with a Preprocessing Framework for LLM-based RTL Generation." pith.science (2026). https://pith.science/paper/GFOSUESM

@misc{pith2026250713369,
  author       = {Pith},
  title        = {Pith review of: VerilogDB: The Largest, Highest-Quality Dataset with a Preprocessing Framework for LLM-based RTL Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GFOSUESM}},
  note         = {Machine review of arXiv:2507.13369}
}
read the original abstract

Large Language Models (LLMs) are gaining popularity for hardware design automation, particularly through Register Transfer Level (RTL) code generation. In this work, we examine the current literature on RTL generation using LLMs and identify key requirements for training and fine-tuning datasets. We construct a robust Verilog dataset through an automated three-pronged process involving database (DB) creation and management with PostgreSQL, data collection from code hosting sites like OpenCores and GitHub, and data preprocessing to verify the codes' syntax, run logic synthesis, and extract relevant module metadata. We implement a scalable and efficient DB infrastructure to support analysis and detail our preprocessing pipeline to enforce high-quality data before DB insertion. The resulting dataset comprises 20,392 Verilog samples, 751 MB of Verilog code data, which is the largest high-quality Verilog dataset for LLM fine-tuning to our knowledge. We further evaluate the dataset, address associated challenges, and explore potential applications for future research and development in LLM-based hardware generation.

Figures

Figures reproduced from arXiv: 2507.13369 by the authors.

Figure 1
Figure 1. High-level flow for LLM fine-tuning process including iterative feedback for closed-loop fine-tuning. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of the Verilog RTL data collection process from GitHub, OpenCores, and textbooks. Each source passes through a [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Overview of the VerilogDB Framework Data Preprocessing Flow. [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Data sample JSON for decoder containing metadata and generated description. [PITH_FULL_IMAGE:figures/full_fig_p014_4.png]
Figure 5
Figure 5. Figure 5: SQL schema for PostgreSQL structured DB Implementation [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 6
Figure 6. Figure 6: Class Distribution of VerilogDB modules. a module’s complexity: (1) estimated LLM token count to represent the module’s size for downstream processing, (2) Verilog code line count (not including blank lines) to highlight how large the file was, and (3) the number of po…
Figure 7
Figure 7. Figure 7: Distributions of VerilogDB modules by (a) functional classes, (b) line count, and (c) estimated token count [PITH_FULL_IMAGE:figures/full_fig_p020_7.png]
Figure 8
Figure 8. Figure 8: Scatterplot showing of module complexity relating estimated token and line counts of the Verilog modules [PITH_FULL_IMAGE:figures/full_fig_p020_8.png]
Figure 9
Figure 9. Figure 9: Comment density module counts for 0-12.5%, 12.5%-25%,25%-37.5%, 37.5%-50%, 50%-62.5%, 62.5%-75%, and >75% buckets [PITH_FULL_IMAGE:figures/full_fig_p021_9.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

55 extracted references · 19 canonical work pages

  1. [1]

    Mohammad Akyash, Kimia Azar, and Hadi Kamali. 2025. RTL++: Graph-enhanced LLM for RTL Code Generation. arXiv:2505.13479 [cs.PL] https://arxiv.org/abs/2505.13479

    arXiv 2025

  2. [2]

    Ahmed Allam and Mohamed Shalan. 2024. RTL-Repo: A Benchmark for Evaluating LLMs on Large-Scale RTL Design Projects. arXiv:2405.17378 [cs.LG] https://arxiv.org/abs/2405.17378

    arXiv 2024

  3. [3]

    Shadan Alsaqer, Sarah Alajmi, Imtiaz Ahmad, and Mohammad Alfailakawi. 2024. The potential of LLMs in hardware design. Journal of Engineering Research (2024). doi:10.1016/j.jer.2024.08.001

    doi:10.1016/j.jer.2024.08.001 2024

  4. [4]

    Anisuzzaman, Jeffrey G

    D.M. Anisuzzaman, Jeffrey G. Malins, Paul A. Friedman, and Zachi I. Attia. 2025. Fine-Tuning Large Language Models for Specialized Use Cases. Mayo Clinic Proceedings: Digital Health 3, 1 (2025), 100184. doi:10.1016/j.mcpdig.2024.11.005

    doi:10.1016/j.mcpdig.2024.11.005 2025

  5. [5]

    Oliver Arafat and Dirk Riehle. 2009. The comment density of open source software code. In2009 31st International Conference on Software Engineering - Companion Volume. 195–198. doi:10.1109/ICSE-COMPANION.2009.5070980

    work page arXiv 2009

  6. [6]

    Rudolf Bayer and Edward M McCreight. 1972. Organization and maintenance of large ordered indexes. Acta Informatica 1, 3 (1972), 173–189

    work page 1972

  7. [8]

    Kaiyan Chang, Ying Wang, Haimeng Ren, Mengdi Wang, Shengwen Liang, Yinhe Han, Huawei Li, and Xiaowei Li. 2023. Chipgpt: How far are we from natural language hardware design. arXiv preprint arXiv:2305.14019 (2023)

    arXiv 2023

  8. [9]

    Fan Cui, Chenyang Yin, Kexing Zhou, Youwei Xiao, Guangyu Sun, Qiang Xu, Qipeng Guo, Demin Song, Dahua Lin, Xingcheng Zhang, Yun, and Liang. 2024. OriGen:Enhancing RTL Code Generation with Code-to-Code Augmentation and Self-Reflection. arXiv:2407.16237 [cs.AR] https://arxiv.org/abs/2407.16237

    arXiv 2024

Show all 55 references
  1. [10]

    Yin Cui, Menglin Jia, Tsung-Yi Lin, Yang Song, and Serge Belongie. 2019. Class-Balanced Loss Based on Effective Number of Samples. In 2019 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) . 9260–9269. doi:10.1109/CVPR.2019.00949

    2019

  2. [11]

    Yonggan Fu, Yongan Zhang, Zhongzhi Yu, Sixu Li, Zhifan Ye, Chaojian Li, Cheng Wan, and Yingyan Celine Lin. 2023. Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models. In 2023 IEEE/ACM International Conference on Computer Aided Design ...

    2023

  3. [12]

    Mingzhe Gao, Jieru Zhao, Zhe Lin, Wenchao Ding, Xiaofeng Hou, Yu Feng, Chao Li, and Minyi Guo. 2024. AutoVCoder: A Systematic Framework for Automated Verilog Code Generation using LLMs. arXiv:2407.18333 [cs.AR] https://arxiv.org/abs/2407.18333

    2024 arXiv

  4. [13]

    Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. 2024. Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997 [cs.CL] https://arxiv.org/abs/2312.10997

    2024 arXiv

  5. [14]

    PostgreSQL Global Development Group. [n. d.]. PostgreSQL. https://www.postgresql.org/

  6. [15]

    Daya Guo, Shuai Lu, Nan Duan, Yanlin Wang, Ming Zhou, and Jian Yin. 2022. UniXcoder: Unified Cross-Modal Pre-training for Code Representation. In Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) , Smaranda Muresan,...

    2022 doi

  7. [16]

    Shailja Gupta, Rajesh Ranjan, and Surya Narayan Singh. 2024. A Comprehensive Survey of Retrieval-Augmented Generation (RAG): Evolution, Current Landscape and Future Directions. arXiv:2410.12837 [cs.CL] https://arxiv.org/abs/2410.12837

    2024 arXiv

  8. [17]

    Guyue Huang, Jingbo Hu, Yifan He, Jialong Liu, Mingyuan Ma, Zhaoyang Shen, Juejian Wu, Yuanfan Xu, Hengrui Zhang, Kai Zhong, Xuefei Ning, Yuzhe Ma, Haoyu Yang, Bei Yu, Huazhong Yang, and Yu Wang. 2021. Machine Learning for Electronic Design Automation: A Survey.ACM Trans. Des....

    2021 doi

  9. [18]

    Albert Q. Jiang, Alexandre Sablayrolles, Arthur Mensch, Chris Bamford, Devendra Singh Chaplot, Diego de las Casas, Florian Bressand, Gianna Lengyel, Guillaume Lample, Lucile Saulnier, Lélio Renard Lavaud, Marie-Anne Lachaux, Pierre Stock, Teven Le Scao, Thibaut Lavril, Thomas ...

    2023 arXiv

  10. [19]

    Heiko Koziolek, Sten Grüner, Rhaban Hark, Virendra Ashiwal, Sofia Linsbauer, and Nafise Eskandani. 2024. LLM-based and Retrieval-Augmented Control Code Generation. In Proceedings of the 1st International Workshop on Large Language Models for Code (Lisbon, Portugal) (LLM4Code ’...

    2024

  11. [20]

    Katherine Lee, Daphne Ippolito, Andrew Nystrom, Chiyuan Zhang, Douglas Eck, Chris Callison-Burch, and Nicholas Carlini. 2022. Deduplicating Training Data Makes Language Models Better. arXiv:2107.06499 [cs.CL] https://arxiv.org/abs/2107.06499

    2022 arXiv

  12. [21]

    Mingjie Liu, Nathaniel Pinckney, Brucek Khailany, and Haoxing Ren. 2023. VerilogEval: Evaluating Large Language Models for Verilog Code Generation. arXiv preprint arXiv:2309.07544 (2023)

    2023 arXiv

  13. [22]

    Mingjie Liu, Nathaniel Pinckney, Brucek Khailany, and Haoxing Ren. 2023. Verilogeval: Evaluating large language models for verilog code generation. In 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD) . IEEE, 1–8

    2023

  14. [23]

    Mingjie Liu, Yun-Da Tsai, Wenfei Zhou, and Haoxing Ren. 2025. CraftRTL: High-quality Synthetic Data Generation for Verilog Code Models with Correct-by-Construction Non-Textual Representations and Targeted Code Repair. arXiv:2409.12993 [cs.AR] https://arxiv.org/abs/2409.12993 M...

    2025 arXiv

  15. [24]

    Shang Liu, Wenji Fang, Yao Lu, Jing Wang, Qijun Zhang, Hongce Zhang, and Zhiyao Xie. 2024. RTLCoder: Fully open-source and efficient LLM-assisted RTL code generation technique. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (2024)

    2024

  16. [25]

    Shang Liu, Yao Lu, Wenji Fang, Mengming Li, and Zhiyao Xie. 2025. OpenLLM-RTL: Open Dataset and Benchmark for LLM-Aided Design RTL Generation. In Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design (Newark Liberty International Airport Marriott, ...

    2025

  17. [26]

    Yao Lu, Shang Liu, Qijun Zhang, and Zhiyao Xie. 2024. RTLLM: An Open-Source Benchmark for Design RTL Generation with Large Language Model. In 2024 29th Asia and South Pacific Design Automation Conference (ASP-DAC) . IEEE, 722–727

    2024

  18. [27]

    Zhendong Mi, Renming Zheng, Haowen Zhong, Yue Sun, Seth Kneeland, Sayan Moitra, Ken Kutzer, and Zhaozhuo Xu Shaoyi Huang. 2025. CoopetitiveV: Leveraging LLM-powered Coopetitive Multi-Agent Prompting for High-quality Verilog Generation. arXiv:2412.11014 [cs.LG] https://arxiv.or...

    2025 arXiv

  19. [28]

    OpenAI. 2025. Introducing Codex: An AI coding agent. https://openai.com/index/introducing-codex Accessed: 2025-05-17

    2025

  20. [29]

    OpenCores Organization. 1999. OpenCores: Open-Source Hardware Community. https://opencores.org/

    1999

  21. [30]

    Venkatesh Balavadhani Parthasarathy, Ahtsham Zafar, Aafaq Khan, and Arsalan Shahid. 2024. The Ultimate Guide to Fine-Tuning LLMs from Basics to Breakthroughs: An Exhaustive Review of Technologies, Research, Best Practices, Applied Research Challenges and Opportunities. arXiv:2...

    2024 arXiv

  22. [31]

    Zehua Pei, Hui-Ling Zhen, Mingxuan Yuan, Yu Huang, and Bei Yu. 2024. BetterV: Controlled Verilog Generation with Discriminative Guidance. arXiv:2402.03375 [cs.AI] https://arxiv.org/abs/2402.03375

    2024 arXiv

  23. [32]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2024. Autobench: Automatic testbench generation and evaluation using llms for hdl design. In Proceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD . 1–10

    2024

  24. [33]

    Ronald L. Rivest. 1992. The MD5 Message-Digest Algorithm. Request for Comments (RFC) 1321. https://tools.ietf.org/html/rfc1321

    1992

  25. [34]

    Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov, Ivan Evtimov, Joanna Bitton, Manish Bhatt, Cristian Canton Ferrer, Aaron Grattafiori, Wenhan Xiong...

    2024 arXiv

  26. [35]

    Dipayan Saha, Hasan Al Shaikh, Shams Tarek, and Farimah Farahmandi. 2025. ThreatLens: LLM-guided Threat Modeling and Test Plan Generation for Hardware Security Verification. arXiv:2505.06821 [cs.CR] https://arxiv.org/abs/2505.06821

    2025 arXiv

  27. [36]

    Dipayan Saha, Shams Tarek, Katayoon Yahyaei, Sujan Kumar Saha, Jingbo Zhou, Mark Tehranipoor, and Farimah Farahmandi. 2024. LLM for SoC Security: A Paradigm Shift. IEEE Access 12 (2024), 155498–155521. doi:10.1109/ACCESS.2024.3427369

    2024

  28. [37]

    Dipayan Saha, Katayoon Yahyaei, Sujan Kumar Saha, Mark Tehranipoor, and Farimah Farahmandi. 2024. Empowering Hardware Security with LLM: The Development of a Vulnerable Hardware Database. In 2024 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) . 233...

    2024

  29. [38]

    Pranab Sahoo, Ayush Kumar Singh, Sriparna Saha, Vinija Jain, Samrat Mondal, and Aman Chadha. 2025. A Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications. arXiv:2402.07927 [cs.AI] https://arxiv.org/abs/2402.07927

    2025 arXiv

  30. [39]

    Rogers, Inna Goncearenco, Giuseppe Sarli, Igor Galynker, Denis Peskoff, Marine Carpuat, Jules White, Shyamal Anadkat, Alexander Hoyle, and Philip Resnik

    Sander Schulhoff, Michael Ilie, Nishant Balepur, Konstantine Kahadze, Amanda Liu, Chenglei Si, Yinheng Li, Aayush Gupta, HyoJung Han, Sevien Schulhoff, Pranav Sandeep Dulepet, Saurav Vidyadhara, Dayeon Ki, Sweta Agrawal, Chau Pham, Gerson Kroiz, Feileen Li, Hudson Tao, Ashay S...

    2025 arXiv

  31. [40]

    Reshma Sheik, K P Siva Sundara, and S Jaya Nirmala. 2024. Neural data augmentation for legal overruling task: Small deep learning models vs. Large language models. Neural Process. Lett. 56, 2 (March 2024)

    2024

  32. [41]

    Jingzhe Shi, Qinwei Ma, Hongyi Liu, Hang Zhao, Jeng-Neng Hwang, Serge Belongie, and Lei Li. 2025. Explaining Context Length Scaling and Bounds for Language Models. arXiv:2502.01481 [cs.LG] https://arxiv.org/abs/2502.01481

    2025

  33. [42]

    2003–2024

    Wilson Snyder and contributors. 2003–2024. Verilator: Open Source SystemVerilog Simulator. https://verilator.org

    2003

  34. [43]

    Demin Song, Honglin Guo, Yunhua Zhou, Shuhao Xing, Yudong Wang, Zifan Song, Wenwei Zhang, Qipeng Guo, Hang Yan, Xipeng Qiu, and Dahua Lin. 2024. Code Needs Comments: Enhancing Code LLMs with Comment Augmentation. arXiv:2402.13013 [cs.CL] https://arxiv.org/abs/2402.13013

    2024 arXiv

  35. [44]

    Shailja Thakur, Baleegh Ahmad, Hammond Pearce, Benjamin Tan, Brendan Dolan-Gavitt, Ramesh Karri, and Siddharth Garg. 2024. VeriGen: A Large Language Model for Verilog Code Generation. ACM Transactions on Design Automation of Electronic Systems (2024). doi:10.1145/3643681

    2024 doi

  36. [45]

    Shailja Thakur, Baleegh Ahmad, Hammond Pearce, Benjamin Tan, Brendan Dolan-Gavitt, Ramesh Karri, and Siddharth Garg. 2024. Verigen: A large language model for verilog code generation. ACM Transactions on Design Automation of Electronic Systems 29, 3 (2024), 1–31

    2024

  37. [46]

    Shailja Thakur, Jason Blocklove, Hammond Pearce, Benjamin Tan, Siddharth Garg, and Ramesh Karri. 2024. AutoChip: Automating HDL Generation Using LLM Feedback. arXiv:2311.04887 [cs.PL] https://arxiv.org/abs/2311.04887

    2024 arXiv

  38. [47]

    Ning Wang, Bingkun Yao, Jie Zhou, Xi Wang, Zhe Jiang, and Nan Guan. 2025. Large Language Model for Verilog Generation with Code-Structure- Guided Reinforcement Learning. arXiv:2407.18271 [cs.AR] https://arxiv.org/abs/2407.18271

    2025 arXiv

  39. [48]

    Stephen Williams. 2024. Icarus Verilog Documentation. https://steveicarus.github.io/iverilog/

    2024

  40. [49]

    Clifford Wolf. 2024. Yosys Open SYnthesis Suite Documentation. https://yosyshq.readthedocs.io/. Manuscript submitted to ACM 28 Calzada et al

    2024

  41. [50]

    Peiyang Wu, Nan Guo, Xiao Xiao, Wenming Li, Xiaochun Ye, and Dongrui Fan. 2025. ITERTL: An Iterative Framework for Fine-tuning LLMs for RTL Code Generation. arXiv:2407.12022 [cs.CL] https://arxiv.org/abs/2407.12022

    2025 arXiv

  42. [51]

    Shangyu Wu, Ying Xiong, Yufei Cui, Haolun Wu, Can Chen, Ye Yuan, Lianming Huang, Xue Liu, Tei-Wei Kuo, Nan Guan, and Chun Jason Xue. 2025. Retrieval-Augmented Generation for Natural Language Processing: A Survey. arXiv:2407.13193 [cs.CL] https://arxiv.org/abs/2407.13193

    2025 arXiv

  43. [52]

    Yingsheng Wu, Yuxuan Gu, Xiaocheng Feng, Weihong Zhong, Dongliang Xu, Qing Yang, Hongtao Liu, and Bing Qin. 2024. Extending Context Window of Large Language Models from a Distributional Perspective. InProceedings of the 2024 Conference on Empirical Methods in Natural Language ...

    2024 doi

  44. [53]

    Bei Yu. 2023. Machine Learning in EDA: When and How. In 2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD) . 1–6. doi:10.1109/ MLCAD58807.2023.10299822

    2023

  45. [54]

    Yongan Zhang, Zhongzhi Yu, Yonggan Fu, Cheng Wan, and Yingyan Celine Lin. 2024. Mg-verilog: Multi-grained dataset towards enhanced llm-assisted verilog generation. In 2024 IEEE LLM Aided Design Workshop (LAD) . IEEE, 1–5

    2024

  46. [55]

    Zixi Zhang, Balint Szekely, Pedro Gimenes, Greg Chadwick, Hugo McNally, Jianyi Cheng, Robert Mullins, and Yiren Zhao. 2025. LLM4DV: Using Large Language Models for Hardware Test Stimuli Generation. arXiv:2310.04535 [cs.LG] https://arxiv.org/abs/2310.04535

    2025 arXiv

  47. [56]

    Yang Zhao, Di Huang, Chongxiao Li, Pengwei Jin, Muxin Song, Yinan Xu, Ziyuan Nan, Mingju Gao, Tianyun Ma, Lei Qi, Yansong Pan, Zhenxing Zhang, Rui Zhang, Xishan Zhang, Zidong Du, Qi Guo, and Xing Hu. 2025. CodeV: Empowering LLMs with HDL Generation through Multi-Level Summariz...

    2025 arXiv

Pith tools

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