Pith. sign in

REVIEW 4 major objections 6 minor 25 references

Repairing vague, contradictory, or incomplete specs can raise LLM-generated Verilog pass rates by roughly 13%.

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 · grok-4.5

2026-07-30 23:30 UTC pith:7WMMQNWI

load-bearing objection Solid first systematic take on defective Verilog specs with useful dual repair and public defect benchmarks; headline gains are real under light confirmation but partly upper-bounded by perfect oracles on injected defects. the 4 major comments →

arxiv 2607.24854 v1 pith:7WMMQNWI submitted 2026-07-25 cs.AR cs.PL

VClare: Resolving Imperfect Specifications in LLM-Based Verilog Generation

Zhuorui Zhao , Bing Li , Yu Li , Zheyu Yan , Ulf Schlichtmann This is my paper
classification cs.AR cs.PL
keywords Verilog generationlarge language modelsspecification repairimperfect specificationssimulation clusteringhardware designRTLinconsistency mining
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.

Human specs for hardware are often imperfect, and those defects mislead language models into wrong Verilog even when the model can code. This paper argues that the right place to intervene is the specification itself, not only the finished RTL. It offers VClare, which repairs intent in two ways: by mining the text for inconsistent statements and editing with light human confirmation, and by generating many candidate designs, clustering them by simulation behavior, and optionally asking a human which of two diverging behaviors is wanted. On new defect-injected benchmarks for single-module and multi-module designs, the framework lifts pass rates by about 12.7% and 13.7%. The deeper finding is that text-level repair works best on short contradictory specs and can hurt on long multi-module documents, while simulation consensus stays useful across both.

Core claim

Semantically defective natural-language specs are a first-class failure mode for LLM Verilog generation, and intent can be recovered without golden testbenches by combining lightweight human confirmation with either direct inconsistency mining on the text or behavioral clustering of simulated candidates. Spec-level repair strongly helps concise contradiction cases but degrades as specs grow complex; sim-level repair remains the robust default and yields the largest gains on realistic multi-module tasks.

What carries the argument

VClare’s dual repair loop: Spec-Level Repair (LLM extracts up to a few inconsistency pairs from the spec; a human only names which source to trust; the LLM edits only the rejected side) and Sim-Level Repair (many Verilog candidates plus an LLM testbench are simulated, clustered by output equivalence, ranked by consensus, with optional human choice on one distinguishing test case).

Load-bearing premise

That systematically injected vagueness, contradiction, and incompleteness, plus only confirming which mined statement or one I/O behavior to trust, stand in for real early engineering specs and a true minimum-oracle setting.

What would settle it

On held-out real engineer-written defective multi-module specs (not LLM-injected defects), measure whether sim-level or hybrid repair still raises golden-testbench pass@1 by roughly the reported 13% over no-repair, and whether spec-level repair still hurts as module count grows.

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

If this is right

  • Upstream spec repair should be treated as part of LLM hardware flows, not only post-generation RTL debugging.
  • For short single-module specs with explicit contradictions, text-level inconsistency mining plus minimal confirmation is worth running first.
  • For long multi-module documents, skip aggressive text edits and rely on simulation consensus among candidates.
  • Decomposing large specs into smaller self-contained module descriptions should make both generation and repair more reliable.
  • The released defect-injected single- and multi-module benchmarks become a standard stress test for any claim about robust HDL generation from natural language.

Where Pith is reading between the lines

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

  • Minimum-oracle arbitration on one distinguishing I/O case is a practical middle ground between fully automatic selection and full golden testbenches in early RTL.
  • The same complexity cliff—text repair failing as documents lengthen while execution consensus holds—likely appears in software and other code-from-spec settings with long requirements.
  • If cover rate of mined defects keeps falling with length and submodule count, production tools should gate spec-level edits on a complexity threshold rather than always running them.
  • Behavioral clustering may be recovering not only injected defects but also ordinary LLM sampling noise, so gains partly measure self-consistency under imperfect prompts.

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

4 major / 6 minor

Summary. The paper studies how semantic defects in natural-language specifications (vagueness, contradiction, incompleteness) degrade LLM-based Verilog generation, and proposes VClare, a framework with two repair paradigms: Spec-Level Repair (LLM inconsistency mining + human source confirmation + targeted edit, pre-generation) and Sim-Level Repair (VRank-style behavioral clustering of N=10 candidates with optional human arbitration on a distinguishing test case, post-generation). The authors construct and release two defect-injected benchmarks (VerilogEval-Defect, 156 single-module tasks; ComplexVDB-Defect, 53 multi-module tasks ×3 defect types) and evaluate on DeepSeek-v4-flash and GPT-5.4-nano with n=10 sampling and 5 runs. Headline results: Hybrid repair reaches 50.0% vs 39.2% No Repair pass@1 on VerilogEval-Defect; Sim-level reaches 49.8% vs 34.2% on ComplexVDB-Defect. The paper also reports an honest and useful negative result: Spec-Level Repair becomes counterproductive on long multi-module specifications (Finding 4), and can contaminate downstream Sim-Level Repair (Finding 6), motivating a "decompose or go straight to behavioral consensus" practical recommendation.

Significance. If the results hold, this is a valuable contribution: to my knowledge the first systematic study of defective specifications in HDL generation, with two released benchmarks, documented injection prompts (Figs. 6–9), controlled evaluation against held-out golden testbenches never used during repair, and multiple baselines including a software-domain SoTA adaptation (SpecFix-no-oracle). The complexity-dependent divergence between the two paradigms (Findings 4–6, Figs. 4–5, Table 4 m-ablation) is a genuinely informative, non-obvious empirical finding with actionable guidance. The benchmarks themselves are likely to be reused. The main qualification is that the headline numbers are measured under a perfect human confirmer, so they are best read as upper bounds on the "minimum-oracle" setting the paper motivates.

major comments (4)
  1. [§3.1, §3.2.2, §4, Appendix I] The headline gains are measured with an infallible confirmer, which is in tension with the 'minimum-oracle' framing in §2. Because defects are injected into known-correct specs, a ground-truth-correct source always exists: in Appendix I the engineer simply points to source 1 (the original clause), and in §3.2.2 the engineer confirms the desired behavior on the distinguishing test case — again with known ground truth. The entire margin of Hybrid over Hybrid(NA) (50.0 vs 45.8 DS, Table 2) and of Sim-level over VRank (49.8 vs 42.4 DS, Table 3) is attributable to arbitration whose accuracy is assumed to be 100%, and Spec-Level Repair's confirmation step has the same property. Real defective specs are defective precisely because the engineer may not know which statement is right — the paper's own Appendix III makes this point for vagueness/incompleteness. A noisy-confirmer ablation (e.g., syn
  2. [Tables 2–3, §5.1] No variance or significance is reported despite 5 runs per configuration. On ComplexVDB-Defect (53 tasks per defect type, 159 total), several reported gaps correspond to single-digit task counts: e.g., the GPT overall Sim-level vs VRank gap (39.9 vs 35.0) is ~8 tasks, and GPT vague Sim-level/Rank are identical (32.8). Finding 3's 'complementary contributions' and Finding 5's dominance claims rest partly on differences of this size. Please report confidence intervals or a paired test across the 5 runs (and ideally per-task McNemar-style comparison), especially for the ComplexVDB claims.
  3. [§5.2, §5.3] Pass@1 is not comparable across rows in compute terms. No Repair and Spec-Level rows generate one deployed sample (estimated over n=10); Sim-level/Hybrid rows consume N=10 candidates plus an LLM-generated testbench plus simulation plus (optionally) human arbitration per task. Claiming 'Sim-level improves pass@1 by 15.6%' (Finding 5) without reporting this cost asymmetry overstates the comparison. Please add a cost accounting (tokens, simulation runs, human interactions per task) per method, and state the pass@1 semantics explicitly for clustering-based rows. A compute-matched baseline (e.g., best-of-10 with the LLM testbench as filter) would strengthen the attribution to behavioral consensus rather than to sampling budget.
  4. [§4, Appendix I–II] The injected contradictions are appended clauses that directly contradict an existing numbered clause (Appendix I: clause (4) vs clause (1)), which makes inconsistency mining substantially easier than in organically contradictory documents, and there appears to be exactly one injected defect per spec while mining extracts up to m=3 pairs. The cover-rate metric (Figs. 4–5) is also measured against the known injection site. These choices are reasonable for a controlled study, but they bound external validity of the +22% contradiction-repair claim (Finding 1). Please discuss this explicitly, and consider a small set of human-authored or naturally occurring defective specs as a validation slice.
minor comments (6)
  1. [Appendix III] Text says 'continues improving up to m=3 on GPT-4 (57.4%)' — the backbone is GPT-5.4-nano, not GPT-4. Also Table 4 shows DS Hybrid contradiction peaks at m=2 (60.7%), which is worth surfacing in the main text since it qualifies the default m=3 choice.
  2. [§4] Broken/ambiguous figure references: 'Fig. 6 shows an example with the original prompts and the prompts after defect injection' appears to mean Fig. 2 (Fig. 6 is the injection prompt); 'An example of our defect injection script is presented in 6' is missing 'Fig.'. Please audit all cross-references.
  3. [Abstract / §5.4] Abstract reports 13.7% for multi-module tasks while Finding 5 reports +15.6% (DS) and +11.8% (GPT); state that 13.7% is the model average. Similarly, the contributions' '28.7% with sim-level repair' is actually the Hybrid (spec+sim) number averaged over models — the wording conflates Sim-level and Hybrid.
  4. [§5.3] The SpecFix-no-oracle adaptation is under-specified: SpecFix relies on human-written I/O examples to ground disambiguation; describe precisely what replaces them here and how many candidates/clusters it uses, so the baseline is reproducible and the comparison fair.
  5. [§3.2.1] The LLM-generated testbench T is load-bearing for clustering quality, but its size, coverage prompting, and failure handling (candidates that fail compilation become singleton clusters — how are these ranked by MBR?) are only sketched. A short algorithm box or parameter list would help.
  6. [General] The datasets are released via an anonymous link and scripts are promised 'upon acceptance'; for an arXiv posting, consider releasing generation scripts now, since the injection procedure is central to reproducibility.

Circularity Check

0 steps flagged

No derivation circularity: empirical pass@k gains are measured against held-out golden testbenches unused in repair.

full rationale

VClare is an empirical systems paper. Spec-Level Repair (inconsistency mining + human source confirmation + targeted edit) and Sim-Level Repair (candidate generation, LLM testbench, Icarus simulation, MBR clustering, optional distinguishing-case arbitration) are procedural pipelines, not definitions of the evaluation metric. Final scores use golden testbenches from VerilogEval / ComplexVDB that are explicitly withheld from repair (§4, §5.2). Reuse of the authors’ prior VRank pipeline [23] is methodological scaffolding with external simulation checks; it does not force pass@1 by construction, and baselines (No Repair, Blind Fix, VRank alone, SpecFix-no-oracle) show the reported lifts are comparative, not tautological. Defect injection constructs the test distribution; it does not redefine success as recovering the injection script. Concerns about perfect human confirmation on injected defects are external-validity / oracle-strength issues, not circular reduction of a claimed derivation to its inputs. No self-definitional loop, fitted-input-as-prediction, uniqueness import, or renaming of a known result appears in the load-bearing chain.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 2 invented entities

The central empirical claim rests on standard LLM-sampling and simulation practice, on the representativeness of injected requirement defects, on behavioral agreement as a proxy for intent without golden benches, and on lightweight human confirmation as an acceptable oracle. No physical constants or fitted scientific laws; free choices are methodological knobs (m, N, cluster ranker, models).

free parameters (3)
  • m (max inconsistency pairs per spec) = default m≤3; ablations m=1,2,3
    Capped at ≤3; Appendix III shows performance trade-offs by defect type. Choice affects spurious edits vs coverage.
  • N Verilog candidates for clustering = n=10 for pass@k estimation
    Number of samples used for behavioral clusters and pass@k with n=10 reported; affects consensus stability.
  • LLM backbone and decoding settings = DS low effort; GPT medium effort; default temperature
    deepseek-v4-flash and gpt-5.4-nano with stated reasoning effort/temperature defaults; results are model-dependent.
axioms (5)
  • domain assumption Behavioral equivalence on an LLM-generated testbench is a useful proxy for intended functionality when specs are defective.
    Core of Sim-Level Repair / VRank reuse in §3.2; golden benches used only for final scoring.
  • domain assumption Systematically injected contradiction, incompleteness, and vagueness (with light manual realism checks) represent the imperfect specs that matter in practice.
    Dataset construction in §4 and defect prompts in Appendix II.
  • domain assumption A human can correctly choose which of two mined statements (or one distinguishing I/O) matches intent without writing full corrections or golden tests.
    Minimum-oracle setup in §2–3.1 and optional arbitration in §3.2.2.
  • domain assumption MBR-style consistency scoring over pairwise simulation disagreements ranks clusters toward correct designs.
    Imported from VRank [23] in §3.2.1.
  • standard math Standard pass@k estimation with sampling is an appropriate quality metric for LLM Verilog generation.
    §5.2 cites the Chen et al. pass@k estimator.
invented entities (2)
  • VClare dual-paradigm repair framework no independent evidence
    purpose: Name the combined Spec-Level and Sim-Level pipeline for defective HDL specs.
    Methodological system, not a physical entity; evaluated empirically on new benchmarks.
  • VerilogEval-Defect and ComplexVDB-Defect benchmarks independent evidence
    purpose: Provide controlled defective-spec tasks for single- and multi-module Verilog generation.
    Constructed artifacts via defect injection into prior benchmarks/collections; useful if adopted externally.

pith-pipeline@v1.2.0-grok45-kimik3 · 18034 in / 3424 out tokens · 69983 ms · 2026-07-30T23:30:33.607001+00:00 · methodology

0 comments
read the original abstract

Large language models (LLMs) have demonstrated promising capabilities in generating Verilog code from natural language specifications. However, human-written specifications often contain semantic imperfections such as vagueness, contradictions, and incompleteness, which can significantly degrade the quality of hardware design generated by LLMs. In this paper, we present the first systematic study of imperfect specifications and propose an automated framework {VClare} to repair them to enhance the quality of resulting Verilog design. The proposed framework explores two complementary repair paradigms. The \textit{Spec-Level Repair} conducts LLM-driven inconsistency mining directly on the specification texts, while the \textit{Sim-Level Repair} employs simulation-based behavioral clustering with optional test-time inconsistency arbitration. In addition, we propose two new benchmark datasets with systematically injected specification defects. The first benchmark dataset is derived from the VerilogEval-human benchmark targeting single-module tasks, while the other benchmark dataset is derived from the ComplexVDB dataset and contains 53 multi-module tasks that reflect more realistic engineering scenarios. For single-module tasks, the {VClare} framework can repair the imperfections in the specifications effectively and thus enhance the pass rate of the generated Verilog design by 12.7\%, while for the multi-module tasks this enhancement can reach 13.7\%, demonstrating the capabilities of specification repair by {VClare} as well as further potential of LLMs in front-end hardware design.\footnote{The two benchmark datasets are released at https://anonymous.4open.science/r/VClare/.

Figures

Figures reproduced from arXiv: 2607.24854 by Bing Li, Ulf Schlichtmann, Yu Li, Zheyu Yan, Zhuorui Zhao.

Figure 1
Figure 1. Figure 1: Two repair mechanisms explored in VClare. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Specification example of original prompts and three [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Inconsistency mining cover rate on VerilogEval [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Inconsistency mining cover rate on ComplexVDB [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Main defect injection prompt APPENDIX I: AN EXAMPLE OF THE PROPOSED LLM-DRIVEN PROMPT REPAIR FRAMEWORK FOR VERILOG The following is an example extracted from our VerilogEval-defect dataset, Prob105_rotate100. Due to the length, we only show how incomplete is fixed by gpt-5.4-nano here. ===== ORIGINAL PROMPT ===== Build a 100 - bit left / right rotator , with synchronous load and left / right enable . A rot… view at source ↗
Figure 9
Figure 9. Figure 9: Prompt for vagueness defect injection [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 7
Figure 7. Figure 7: Prompt for contradiction defect injection. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png] 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

25 extracted references · 1 canonical work pages

  1. [1]

    Jason Blocklove, Siddharth Garg, Ramesh Karri, and Hammond Pearce. 2023. Chip-Chat: Challenges and Opportunities in Conversational Hardware Design. In2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD). 1–6. doi:10.1109/MLCAD58807.2023.10299874

    arXiv 2023

  2. [2]

    Kaiyan Chang, Kun Wang, Nan Yang, Ying Wang, Dantong Jin, Wenlong Zhu, Zhirong Chen, Cangyuan Li, Hao Yan, Yunhao Zhou, et al. 2024. Data is all you need: Finetuning llms for chip design via an automated design-data augmentation framework. InProceedings of the 61st ACM/IEEE Design Automation Conference. 1–6

    2024

  3. [3]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374(2021)

    Pith/arXiv arXiv 2021

  4. [4]

    Deepseek. 2026. DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence. https://www.alphaxiv.org/abs/deepseek-v4

    2026

  5. [5]

    Chia-Tung Ho, Haoxing Ren, and Brucek Khailany. 2025. Verilogcoder: Au- tonomous verilog coding agents with graph-based planning and abstract syntax tree (ast)-based waveform tracing tool. InProceedings of the AAAI Conference on Artificial Intelligence, Vol. 39. 300–307

    2025

  6. [6]

    Haoxiang Jia, Robbie Morris, He Ye, Federica Sarro, and Sergey Mechtaev. 2025. Automated Repair of Ambiguous Problem Descriptions for LLM-Based Code Gen- eration. In2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 367–379

    2025

  7. [7]

    Junzhe Liu, Chao Li, Puyuan Zhang, Jinheng Wang, Xiaowei Chen, Zhuorui Zhao, Zhaoyan Shen, Mengying Zhao, Zheyu Yan, and Zhenge Jia. 2026. Reflect- Bench: An Agentic Framework for Generating System-Level Design Testbench via Consensus and Reflection. InProc. of the 63rd IEEE/ACM Design Automation Conference (DAC)

    2026

  8. [8]

    Shankar Kumar and Bill Byrne. 2004. Minimum bayes-risk decoding for sta- tistical machine translation. InProceedings of the Human Language Technology Conference of the North American Chapter of the Association for Computational Linguistics: HLT-NAACL 2004. 169–176

    2004

  9. [9]

    Maya Larbi, Amal Akli, Mike Papadakis, Rihab Bouyousfi, Maxime Cordy, Fed- erica Sarro, and Yves Le Traon. 2025. When Prompts Go Wrong: Evaluating Code Model Robustness to Ambiguous, Contradictory, and Incomplete Task Descriptions. doi:10.48550/arXiv.2507.20439 arXiv:2507.20439 [cs]

    Pith/arXiv arXiv doi:10.48550/arxiv.2507.20439 2025

  10. [10]

    Mingjie Liu, Nathaniel Pinckney, Brucek Khailany, and Haoxing Ren. 2023. In- vited Paper: VerilogEval: Evaluating Large Language Models for Verilog Code Generation. In2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD). 1–8. doi:10.1109/ICCAD57390.2023.10323812

    arXiv 2023

  11. [11]

    Yao Lu, Shang Liu, Qijun Zhang, and Zhiyao Xie. 2024. RTLLM: An Open- Source Benchmark for Design RTL Generation with Large Language Model. InProceedings of the 29th Asia and South Pacific Design Automation Conference (ASPDAC ’24). IEEE Press, Incheon, Republic of Korea, 722–727. doi:10.1109/ASP- DAC58780.2024.10473904

    arXiv 2024

  12. [12]

    Lloyd Montgomery, Davide Fucci, Abir Bouraffa, Lisa Scholz, and Walid Maalej

  13. [13]

    Fangwen Mu, Lin Shi, Song Wang, Zhuohao Yu, Binquan Zhang, ChenXue Wang, Shichao Liu, and Qing Wang. 2024. ClarifyGPT: A Framework for Enhancing LLM-Based Code Generation via Requirements Clarification.Proc. ACM Softw. Eng.1, FSE (July 2024), 103:2332–103:2354. doi:10.1145/3660810

    doi:10.1145/3660810 2024

  14. [14]

    OpenAI. 2026. Introducing GPT-5.4. https://openai.com/index/introducing-gpt- 5-4/

    2026

  15. [15]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2024. AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design. InProceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD (MLCAD ’24). Association for Computing Machinery, New York, NY, USA, 1–10. doi:10.1145/3670474.3685956

    arXiv 2024

  16. [16]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2025. Correctbench: Automatic testbench generation with functional self-correction using llms for hdl design. In2025 Design, Automation & Test in Europe Conference (DATE). IEEE, 1–7

    2025

  17. [17]

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

    Pith/arXiv arXiv doi:10.48550/arxiv.2311.04887 2024

  18. [18]

    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

  19. [19]

    Stephen Williams. 2024. steveicarus/iverilog. https://github.com/steveicarus/ iverilog original-date: 2008-05-12T16:57:52Z

    2024

  20. [20]

    Ke Xu, Jialin Sun, Yuchen Hu, Xinwei Fang, Weiwei Shan, Xi Wang, and Zhe Jiang. 2024. Meic: Re-thinking rtl debug automation using llms. InProceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design. 1–9

    2024

  21. [21]

    Xu, Kangwei, Li, Bing, and Schlichtmann, Ulf. 2026. Invited: LLM for EDA in Front-End Design: Challenges and Opportunities. InACM/IEEE Design Automa- tion Conference (DAC)

    2026

  22. [22]

    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). IEEE, 1–7

    2025

  23. [23]

    Zhuorui Zhao, Ruidi Qiu, Ing-Chao Lin, Grace Li Zhang, Bing Li, and Ulf Schlicht- mann. 2025. VRank: Enhancing Verilog Code Generation from Large Language Models via Self-Consistency. In2025 26th International Symposium on Quality Electronic Design (ISQED). 1–7. doi:10.1109/ISQED65160.2025.11014398

    arXiv 2025

  24. [24]

    Jian Zuo, Junzhe Liu, Xianyong Wang, Yicheng Liu, Navya Goli, Tong Xu, Hao Zhang, Umamaheswara Rao Tida, Zhenge Jia, and Mengying Zhao. 2025. Com- plexVCoder: An LLM-Driven Framework for Systematic Generation of Complex Verilog Code. doi:10.48550/arXiv.2504.20653 arXiv:2504.20653 [cs.SE]. VClare: Resolving Imperfect Specifications in LLM-Based Verilog Gen...

    Pith/arXiv arXiv doi:10.48550/arxiv.2504.20653 2025

  25. [2022]

    Requirements Engineering27, 2 (June 2022), 183–209

    Empirical research on requirements quality: a systematic mapping study. Requirements Engineering27, 2 (June 2022), 183–209. doi:10.1007/s00766-021- 00367-z

    work page doi:10.1007/s00766-021- 2022