Pith. sign in

REVIEW 3 major objections 5 minor 40 references

ChipVerilog, a benchmark built from real open-source IP cores, demonstrates that current large language models can compile Verilog for large and hierarchical designs but fail to match reference behavior once code length or submodule count g

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-02 07:06 UTC pith:YCERHJOU

load-bearing objection ChipVerilog fills a real gap with a large, hierarchy-aware RTL benchmark and cleanly reported measurements, but the headline 0% results depend on a functional-verification pipeline the paper never documents. the 3 major comments →

arxiv 2607.13079 v2 pith:YCERHJOU submitted 2026-07-12 cs.AR cs.PL

ChipVerilog: A Large-Scale OpenCores-Derived Benchmark for LLM-Based Verilog RTL Generation

Yan Tan , Jiping Du , Xiangchen Meng , Yangdi Lyu This is my paper
classification cs.AR cs.PL
keywords Verilog RTL generationlarge language modelshardware benchmarksfunctional correctnessequivalence checkinghierarchical designpass@k evaluationIP-core generation
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

ChipVerilog is a description-to-Verilog benchmark built from real open-source IP and processor-core designs, with 64 targets ranging from small standalone modules to top-level processor wrappers over 1,000 lines. The paper's purpose is to show that current LLM-based RTL generators have not yet solved large-scale, hierarchical design: models reach syntax pass@1 around 83% but functional pass@1 only around 24%, and functional pass@5 stays below 38% for every model tested. The sharpest evidence is the hierarchy cliff: for targets with two or more submodules, both functional pass@1 and pass@5 are 0.00%, even though syntax pass@5 remains 74.5%. The authors argue that this gap means compilability is no longer the bottleneck; preserving cross-module interfaces, control behavior, timing, and integration semantics is what separates current models from useful RTL generation. The benchmark matters because it shifts evaluation from short, self-contained textbook modules toward the scale and structure of real chips.

Core claim

The central discovery is a quantitative separation between syntactic and functional success in LLM-generated Verilog as task scale increases. On ChipVerilog's 64 targets, the strongest model reaches a syntax pass@1 of 83.13% but a functional pass@1 of only 23.55%, and functional pass@5 reaches at most 37.50% across all models. Aggregated by reference RTL length, functional pass@1 falls from 58.0% for targets under 100 lines to 3.2% for 300–500 lines and 0.0% for targets over 500 lines. Aggregated by hierarchy, all models score 0.00% functional pass@1 and pass@5 on targets that instantiate two or more submodules. The authors conclude that current LLMs can reliably produce compilable RTL but c

What carries the argument

The load-bearing machinery is the benchmark itself plus its level-aware validation flow. Each target is a pair of a hand-curated natural-language specification (interface, behavior, timing, and execution flow) and a reference Verilog module. Generated RTL is first checked for syntax and compilation; compilable outputs are then validated by equivalence checking against the reference for standalone and multi-module targets (keeping reference submodules in place), and by testbench simulation for full-system targets. This design makes the benchmark's difficulty measurable: the same prompt is rerun five times, and pass@k is computed for k=1 and k=5, separating syntax recovery from functional corr

Load-bearing premise

The benchmark's pass rates are only as trustworthy as the ground-truth labels: the author-written natural-language specs were manually checked for consistency with the reference RTL, the equivalence-checking flow for sequential modules (reset and initial states, memories, and inconclusive results) is not specified, and the full-system testbenches have undocumented coverage—if any of these mislabels a correct design as incorrect, the reported difficulty, including the 0.0% on

What would settle it

Run the same five generated samples for the 2+-submodule targets through an independent, documented equivalence-checking setup with explicit reset and initial-state handling and cross-check the results against random and directed directed tests; if a substantial share of designs labeled non-equivalent pass co-simulation and manual review, the cliff is a validation artifact, while if all genuinely differ from the reference, the cliff is real.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • If the hierarchy cliff is real, then simply sampling more candidates will not fix RTL generation: functional pass@5 stays at 0.00% for 2+-submodule targets even when syntax pass@5 is 74.51%.
  • Benchmarks built from short standalone modules overstate LLM capability: the same models that score around 23% functional pass@1 overall score 0% on the longest targets.
  • Improving long-context reasoning and cross-module interface preservation becomes the measurable next target for training and prompting, before formal verification or synthesis.
  • Level-aware evaluation—equivalence checking for local modules, simulation for whole cores—offers a more rigorous correctness criterion for module-level tasks than testbench-only suites.
  • The 0.0% on 2+-submodule targets suggests that generated RTL fails even when submodule behavior is fixed, implicating the integration logic itself: port wiring, width matching, and cross-module control/data coordination.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A testable extension: providing models with exact submodule port lists instead of prose descriptions should recover most wiring failures on multi-submodule targets, isolating whether the bottleneck is interface planning or code synthesis.
  • The 0.00% cliff may partly be a validation artifact; because the paper does not document the equivalence checker's handling of reset states, memories, or inconclusive results, a re-run with an independent, documented equivalence setup would test whether the cliff is a model limit or a checker artifact.
  • Allowing models to iterate on failing testbenches, as human designers do, would likely shift long-target results and reveal whether the reported failures reflect one-shot generation limits or fundamental integration reasoning limits.
  • The asymmetry between equivalence checking for modules and simulation for full systems limits comparability across the 64 targets; a unified formal or coverage-driven flow would make difficulty comparisons cleaner and would sharpen the reported length and hierarchy trends.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper introduces ChipVerilog, a description-to-Verilog generation benchmark built from 64 OpenCores-derived targets spanning five design families (OR1200, FPU, MIPS-16, I2C, CORDIC). Targets are split into standalone modules, multi-module targets, and full-system IP/core targets; several exceed 500 lines. Each prompt is a natural-language specification curated from official documents and reference RTL, then manually reviewed. Generated RTL is first checked for compilation/elaboration, then validated by Yosys equivalence checking for standalone and multi-module targets, and by simulation-based testbenches for five full-system targets. The authors evaluate Claude Opus 4.5, GPT-5.4, and DeepSeek V4 Pro, reporting high syntax pass rates (up to 83.13% pass@1, 96.88% pass@5) but much lower functional pass rates (up to 23.55% pass@1, 37.50% pass@5). The central empirical claim is that functional correctness collapses for long targets (>500 lines) and targets with two or more submodules, both of which show 0.00% functional pass@1/pass@5.

Significance. If the validation pipeline is sound, ChipVerilog fills a genuine gap: existing benchmarks are mostly short, flat, single-module tasks, while ChipVerilog provides long, hierarchy-aware targets with cross-module dependencies. The paper's level-aware validation (equivalence checking for local modules, simulation for full systems) is a step beyond testbench-only evaluation. The empirical finding that syntax and functional pass rates diverge sharply, with functional correctness essentially zero on high-hierarchy and long targets, is consequential for LLM-based RTL generation research. The dataset is open-source and the prompt curation is manual, which are strengths. However, the verification methodology is under-documented, and the central quantitative claims are not yet reproducible from the manuscript alone.

major comments (3)
  1. [§3.4, §4.1, Table 5] The Yosys equivalence-checking flow is not documented. The paper states that standalone and multi-module targets are validated by equivalence checking against reference RTL, but gives no commands, no reset/initial-state handling, no treatment of memories or macro definitions, and no policy for inconclusive or timed-out results. For sequential modules, a generated design with a different FSM encoding or reset behavior can be behaviorally correct yet fail a naive equivalence run. Because the 0.00% functional pass rates for 2+ submodule targets (Table 5) and >500-line targets (Figure 2) rest entirely on this validation, the headline results could be inflated by false non-equivalence. The authors must specify the exact Yosys flow and demonstrate its soundness on the reference RTL itself (e.g., reference-vs-reference equivalence).
  2. [§3.3, Appendix A] The prompts are constructed from the reference RTL and include implementation-specific details such as exact submodule names, port names, and fixed latencies (e.g., 'addition: 20 cycles; subtraction: 21 cycles'). This makes the task closer to 'reconstruct this exact RTL implementation' than to 'implement an independent specification.' The measured difficulty is therefore partly a function of the prompt's implementation-detail level, a free parameter chosen by the authors. The manual review (§3.3) is the only consistency check and is not independently verified. The authors should report prompt statistics (length, number of implementation constraints) and, ideally, an ablation with less implementation-bound prompts, or at least explicitly discuss this circularity when interpreting the observed pass rates.
  3. [§3.4, §4.1] For the five full-system targets (or1200_top, mips_16_core_top, i2c_master_top, fpu_double, cordic), functional validation is described only as 'simulation-based validation using testbenches.' No testbench is described, no pass/fail criteria are given, and no coverage metric (line, branch, or functional) is reported. These targets contribute directly to the 0.0% functional results for 2+ submodule targets and the >500-line group. The authors must provide the testbenches, the simulation stimulus, and coverage measurements to support the claim that the generated designs are functionally incorrect rather than insufficiently exercised.
minor comments (5)
  1. [§4.2, Eq. (1)] With n=5, pass@5 is a per-target binary indicator (any success among 5 samples) and pass@1 estimates have high variance (20-percentage-point steps per target). Report per-target success counts and confidence intervals, or use a larger sampling budget, to support the aggregate pass@1 numbers.
  2. [Table 5] The table reports results 'aggregated across all evaluated models' but does not state how the aggregation is computed (pooled samples vs. per-model averages) or how the 'Tasks' counts map to model-target combinations. This should be clarified for reproducibility.
  3. [Figure 2] The 500+ line bin contains only a handful of targets (approximately five) and shows 0.0% functional pass@1. Add per-bin target counts to convey the statistical strength of the length trend.
  4. [Table 2 / Table 5] The hierarchy notation is 'multi(n)' in Table 2 but 'submodules' in Table 5; define whether n counts instantiated submodules only or also 'dependent' submodules. This affects the grouping in Table 5.
  5. [§3.3] The claim that prompts 'avoid exposing the reference implementation verbatim' is not quantified. Given the implementation-specific details in Appendix A, clarify what level of structural information is intentionally included.

Circularity Check

0 steps flagged

No significant circularity: benchmark labels are independently measured against an external oracle; no fitted parameter is repackaged as a prediction.

full rationale

ChipVerilog's central claim is an empirical evaluation: LLMs generate Verilog from curated natural-language prompts, and the generated RTL is checked by Icarus syntax/elaboration and either Yosys equivalence checking (standalone/multi-module) or Icarus simulation (full-system). The correctness oracle is the reference OpenCores RTL, not a quantity derived from the model outputs or from a fit to the benchmark scores. The prompts are manually curated from the reference RTL and official docs (§3.3), but that is a standard benchmark-construction choice; the LLM outputs are not used to define the labels, and no parameter is fitted to a subset of results and then 'predicted' on a related subset. The pass@k estimator (Eq. 1) is a standard unbiased estimator applied to measured per-sample pass/fail counts. Even the sharpest quantitative claims (0.0% pass@1/pass@5 for targets with ≥2 submodules in Table 5, and 0.0% functional pass@1 for >500-line targets in Figure 2) are not tautological: a model could in principle pass those checks, and several models do pass on shorter/standalone targets. Concerns about the equivalence-checking flow (§4.1) — reset/initial-state handling, memory/macro support, inconclusive or timed-out equivalence results — and about the coverage of the full-system testbenches (§3.4) are verification-validity risks that could shift the reported numbers, but they are not instances of circular reasoning: the difficulty numbers are not logically entailed by the inputs in the way required by the enumerated patterns. No load-bearing self-citation, imported uniqueness theorem, or ansatz-by-citation appears; the method relies on external tools (Icarus, Yosys) and open-source designs (OpenCores).

Axiom & Free-Parameter Ledger

3 free parameters · 6 axioms · 0 invented entities

The benchmark's measured difficulty is controlled by author choices — spec detail level, the single-reference gold standard, validation-tier assignment, sampling budget — rather than by physical or mathematical postulates. No new entities (particles, forces, dimensions) are introduced; the only invented artifact is the benchmark itself, whose independent evidence is the unreviewable repository.

free parameters (3)
  • specification implementation-detail level = exact port names, opcode encodings, fixed latencies (20/21/24/71 cycles), six submodule names
    Hand-chosen by the authors with no stated rule (§3.3, Appendix A.1). Directly controls measured difficulty: the more implementation detail in the prompt, the more the task is re-implementation of the reference RTL, so all reported pass rates are functions of this choice.
  • validation-tier assignment = 5 full-system targets by simulation; 59 by equivalence checking
    An author decision (§3.4). The five full-system labels depend on undocumented testbenches, so the aggregate functional results are sensitive to this split.
  • sampling budget and decoding configuration = n=5 samples per target; temperature/seed not reported
    pass@1/pass@5 estimates (Eq. 1) depend on n and on sampling configuration (§4.1). Without decoding details, cross-model comparisons assume comparable sampling, which is unverified.
axioms (6)
  • domain assumption OpenCores reference RTL is correct enough to serve as gold standard
    §3.2: designs chosen for 'stability, mature open-source RTL design status.' If the reference RTL contains latent bugs, equivalence-to-reference labels inherit them.
  • domain assumption Behavioral equivalence to the single reference implementation defines correctness
    §3.4: EC against reference RTL. A functionally correct design with different FSM encoding, port names, or timing is scored as a failure; no human or alternative-implementation check is reported.
  • domain assumption Yosys equivalence checking, as configured, is sound for these sequential designs
    §4.1 names Yosys but does not document the EC flow (initial states, reset equivalence, macro/memory handling, inconclusive or timeout results). If unsound, the functional labels are wrong.
  • domain assumption Simulation testbenches for full-system targets provide adequate functional coverage
    §3.4/§4.1: full-system targets are validated 'using testbenches' with no description of testbench origin or coverage; the pass labels for these five targets depend on this.
  • standard math The pass@k unbiased estimator (Eq. 1) is the appropriate metric
    Standard VerilogEval-style estimator; assumes n i.i.d. samples per problem and uniform problem weighting.
  • domain assumption Generated samples across models are comparably configured
    §4.1: 'Each of the five samples for a target is generated independently from the same benchmark prompt, without iterative feedback.' Temperature and other decoding parameters are not reported, so model comparisons assume comparable sampling.

pith-pipeline@v1.3.0-alltime-deepseek · 13558 in / 38251 out tokens · 322045 ms · 2026-08-02T07:06:19.868390+00:00 · methodology

0 comments
read the original abstract

Large language models have shown strong potential for Verilog RTL generation. However, many existing benchmarks are built from short, self-contained module-level tasks. These tasks are useful for controlled evaluation, but they do not fully capture the code scale, hierarchy, and module interactions found in practical IP and processor-core RTL. We present ChipVerilog, a description-to-Verilog generation benchmark built from OpenCores IP/core designs. The benchmark contains 64 generation targets from five design families: OR1200, double-precision FPU, MIPS-16, I2C, and CORDIC. It includes both single-module targets and cross-module targets that instantiate or interact with other RTL modules. Several targets exceed 1,000 lines of Verilog, making ChipVerilog substantially larger and structurally more complex than typical module-level suites. Each benchmark instance is constructed from a pair of specification documents and reference RTL. We extract the target functionality, write a detailed natural-language description, and manually review the description for correctness and clarity. Generated RTL is checked by compilation and validated through equivalence checking for local modules, or by simulation for integrated IP/core targets. Results show that large-scale RTL remains challenging, especially for hierarchical and cross-module designs.

Figures

Figures reproduced from arXiv: 2607.13079 by Jiping Du, Xiangchen Meng, Yangdi Lyu, Yan Tan.

Figure 1
Figure 1. Figure 1: Overview of the ChipVerilog benchmark construction and evaluation pipeline. The manual review step checks whether the specification is con￾sistent with the reference RTL and sufficiently clear for generation. During this process, we resolve ambiguous wording, remove ir￾relevant implementation noise, and avoid exposing the reference implementation verbatim. The resulting prompt captures the in￾tended functi… view at source ↗
Figure 2
Figure 2. Figure 2: Syntax pass@1 and functional pass@1 grouped by reference RTL length. DeepSeek V4 Pro obtains 45.94% and 13.44%, respectively. Increas￾ing the number of samples improves all models, especially on syn￾tax: Claude reaches 96.88% syntax pass@5, GPT-5.4 reaches 93.75%, and DeepSeek reaches 78.12%. However, functional pass@5 remains much lower: 37.50% for both Claude and GPT-5.4, and 23.44% for DeepSeek. This ga… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

40 extracted references · 7 linked inside Pith

  1. [1]

    Anthropic. 2025. Claude Opus 4.5.https://www.anthropic.com/claude/opus. Accessed: 2026-05-20

    2025

  2. [2]

    Yunsheng Bai, Ghaith Bany Hamad, Syed Suhaib, and Haoxing Ren. 2025. Asser- tionforge: Enhancing formal verification assertion generation with structured representation of specifications and rtl. In2025 IEEE International Conference on LLM-Aided Design (ICLAD). IEEE, 85–92

    2025

  3. [3]

    Jason Blocklove, Siddharth Garg, Ramesh Karri, and Hammond Pearce. 2024. Evaluating llms for hardware design and test. In2024 IEEE LLM Aided Design Workshop (LAD). IEEE, 1–6

    2024

  4. [4]

    Kaiyan Chang, Zhirong Chen, Yunhao Zhou, Wenlong Zhu, Kun Wang, Haobo Xu, Cangyuan Li, Mengdi Wang, Shengwen Liang, Huawei Li, et al. 2024. Natural language is not enough: Benchmarking multi-modal generative AI for Verilog generation. InProceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design. 1–9

    2024

  5. [5]

    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

  6. [6]

    Fan Cui, Chenyang Yin, Kexing Zhou, Youwei Xiao, Guangyu Sun, Qiang Xu, Qipeng Guo, Demin Song, Dahua Lin, Xingcheng Zhang, et al. 2024. OriGen: En- hancing rtl code generation with code-to-code augmentation and self-reflection. arXiv preprint arXiv:2407.16237(2024)

    Pith/arXiv arXiv 2024

  7. [7]

    DeepSeek-AI. 2026. DeepSeek-V4: Towards Highly Efficient Million-Token Con- text Intelligence

    2026

  8. [8]

    Enrique Dehaerne, Bappaditya Dey, Sandip Halder, and Stefan De Gendt. 2023. A deep learning framework for verilog autocompletion towards design and verification automation.arXiv preprint arXiv:2304.13840(2023)

    Pith/arXiv arXiv 2023

  9. [9]

    Pengwei Jin, Di Huang, Chongxiao Li, Shuyao Cheng, Yang Zhao, Xinyao Zheng, Jiaguo Zhu, Shuyi Xing, Bohan Dou, Rui Zhang, et al. 2025. Realbench: Bench- marking verilog generation models with real-world ip designs.arXiv preprint arXiv:2507.16200(2025)

    Pith/arXiv arXiv 2025

  10. [10]

    Kezhi Li, Min Li, Xiangyu Wen, Shibo Zhao, Jieying Wu, Junhua Huang, and Qiang Xu. 2026. FormalRTL: Verified RTL Synthesis at Scale.arXiv preprint arXiv:2603.08738(2026)

    arXiv 2026

  11. [11]

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

    2023

  12. [12]

    Shang Liu, Wenji Fang, Yao Lu, Qijun Zhang, Hongce Zhang, and Zhiyao Xie

  13. [13]

    Shang Liu, Yao Lu, Wenji Fang, Mengming Li, and Zhiyao Xie. 2024. OpenLLM- RTL: Open Dataset and Benchmark for LLM-Aided Design RTL Genera- tion(Invited). In2024 IEEE/ACM International Conference on Computer-Aided Design (ICCAD). ACM

    2024

  14. [14]

    Yao Lu, Shang Liu, Qijun Zhang, and Zhiyao Xie. 2024. RTLLM: An open-source benchmark for design rtl generation with large language model. In2024 29th Asia and South Pacific Design Automation Conference (ASP-DAC). IEEE, 722–727

    2024

  15. [15]

    OpenAI. 2026. GPT-5.4 Model.https://developers.openai.com/api/docs/models/ gpt-5.4. Accessed: 2026-05-20

    2026

  16. [16]

    OpenCores. 2026. OpenCores: Open Source Hardware IP Cores.https: //opencores.org/Accessed: 2026-05

    2026

  17. [17]

    Zehua Pei, Hui-Ling Zhen, Mingxuan Yuan, Yu Huang, and Bei Yu. 2024. BetterV: Controlled verilog generation with discriminative guidance.arXiv preprint arXiv:2402.03375(2024)

    Pith/arXiv arXiv 2024

  18. [18]

    Nathaniel Pinckney, Chenhui Deng, Chia-Tung Ho, Yun-Da Tsai, Mingjie Liu, Wenfei Zhou, Brucek Khailany, and Haoxing Ren. 2025. Comprehensive Verilog design problems: A next-generation benchmark dataset for evaluating large language models and agents on rtl design and verification.arXiv preprint arXiv:2506.14074(2025)

    Pith/arXiv arXiv 2025

  19. [19]

    Suresh Purini, Siddhant Garg, Mudit Gaur, Sankalp Bhat, Sohan Mupparapu, and Arun Ravindran. 2025. ArchXBench: A Complex Digital Systems Benchmark Suite for LLM Driven RTL Synthesis. In2025 ACM/IEEE 7th Symposium on Machine Learning for CAD (MLCAD). IEEE, 1–10

    2025

  20. [20]

    Shailja Thakur, Baleegh Ahmad, Zhenxing Fan, Hammond Pearce, Benjamin Tan, Ramesh Karri, Brendan Dolan-Gavitt, and Siddharth Garg. 2023. Benchmarking large language models for automated verilog rtl code generation. In2023 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 1–6

    2023

  21. [21]

    Shailja Thakur, Jason Blocklove, Hammond Pearce, Benjamin Tan, Siddharth Garg, and Ramesh Karri. 2023. Autochip: Automating hdl generation using llm feedback.arXiv preprint arXiv:2311.04887(2023)

    Pith/arXiv arXiv 2023

  22. [22]

    YunDa Tsai, Mingjie Liu, and Haoxing Ren. 2024. RTLFixer: Automatically fixing RTL syntax errors with large language model. InProceedings of the 61st ACM/IEEE Design Automation Conference. 1–6

    2024

  23. [23]

    Jing Wang, Shang Liu, Yao Lu, and Zhiyao Xie. 2025. HLSDebugger: Identification and Correction of Logic Bugs in HLS Code with LLM Solutions.arXiv preprint arXiv:2507.21485(2025)

    Pith/arXiv arXiv 2025

  24. [24]

    Stephen Williams. [n. d.]. Icarus Verilog.https://steveicarus.github.io/iverilog/. Accessed: 2026-05-20

    2026

  25. [25]

    Clifford Wolf, Johann Glaser, and Johannes Kepler. 2013. Yosys – A Free Verilog Synthesis Suite. InProceedings of the 21st Austrian Workshop on Microelectronics

    2013

  26. [26]

    Zhiyuan Yan, Wenji Fang, Mengming Li, Min Li, Shang Liu, Zhiyao Xie, and Hongce Zhang. 2025. Assertllm: Generating hardware verification assertions from design specifications via multi-llms. InProceedings of the 30th Asia and South Pacific Design Automation Conference. 614–621

    2025

  27. [27]

    Yujie Zhao, Hejia Zhang, Hanxian Huang, Zhongming Yu, and Jishen Zhao. 2025. MAGE: A Multi-Agent Engine for Automated RTL Code Generation. In2025 62nd ACM/IEEE Design Automation Conference (DAC). 1–7. doi:10.1109/DAC63849. 2025.11133191 Conference’17, July 2017, Washington, DC, USA Yan Tan, Jiping Du, Xiangchen Meng and Yangdi Lyu † A Representative Promp...

    arXiv 2025

  28. [29]

    When rst is asserted, clear the internal operand registers, operation registers, enable pipeline registers, counters, result output, ready signal, and status flags

  29. [30]

    Detect a rising edge onenable

  30. [31]

    ChipVerilog: A Large-Scale OpenCores-Derived Benchmark for LLM-Based Verilog RTL Generation Conference’17, July 2017, Washington, DC, USA

    On the detected start pulse, latch opa, opb, fpu_op, and rmodeinto internal registers. ChipVerilog: A Large-Scale OpenCores-Derived Benchmark for LLM-Based Verilog RTL Generation Conference’17, July 2017, Washington, DC, USA

    2017

  31. [32]

    Decode the registered fpu_op value to select addition, sub- traction, multiplication, or division

  32. [33]

    For add/subtract operations, use the operand signs to select the appropriate magnitude datapath

  33. [34]

    Enable the selected arithmetic datapath and generate inter- mediate sign, exponent, and mantissa values

  34. [35]

    Select the active datapath output according to the registered operation code

  35. [36]

    Send the selected sign, exponent, and mantissa tofpu_round

  36. [37]

    Send the rounded result, post-round exponent, low-order mantissa bits, original operands, operation code, and round- ing mode tofpu_exceptions

  37. [38]

    When the operation latency expires, assertready

  38. [39]

    If the exception module requests an override, assign out from the exception result; otherwise assign out from the rounded result

  39. [40]

    Update underflow, overflow, inexact, exception, andinvalid together with the final output. Generation Requirement.Generate synthesizable Verilog RTL for module fpu that matches the interface, submodule integration, operation routing, rounding path, exception path, fixed-latency ready behavior, and output flag behavior described above. Do not generate a te...

    2017

  40. [2024]

    In2024 IEEE LLM Aided Design Workshop (LAD)

    RtlCoder: Outperforming gpt-3.5 in design rtl generation with our open- source dataset and lightweight solution. In2024 IEEE LLM Aided Design Workshop (LAD). IEEE, 1–5