QiMeng-CodeV-R1: Reasoning-Enhanced Verilog Generation

We sincerely thank you for your comprehensive feedback, particularly for your appreciation of our writing, training data generation process, and training framework. For your concerns on our work's cross-benchmark performance variations, theoretical foundations, and NL generation for complex modules, we would like to respond as follows:

• Q1: The evaluation results require further clarification. The proposed model shows a notable improvement over existing methods on the RTLLM dataset, yet achieves similar or even worse performance on the VerilogEval benchmark. This raises questions about dataset-specific characteristics and should be more thoroughly discussed. What makes RTLLM particularly amenable to improvement under this framework?

Thank you for your focus on dataset-specific characteristics. Given that RTLLM's performance gains stem mainly from reinforcement learning, we analyzed distribution differences between our RL dataset and the two benchmarks. We run the instructer-embedding model [1] for the golden code in our RL dataset, RTLLM (v2), and VerilogEval (v2 spec-to-RTL), then generated a t-SNE distribution plot [2]. This plot revealed our RL dataset aligns closely with RTLLM but diverges from VerilogEval (to be added in revision). Below we also show cosine similarity and Euclidean distance metrics for the embedding centroids between our RL dataset and the benchmarks:

Our RL dataset’s embedding centroid shows significantly smaller Euclidean distance and closer-to-1 (maximum value) cosine similarity with RTLLM than with VerilogEval. Importantly, this reflects only embedding centroid relationships, not data homogenization or overfitting to RTLLM.

Additionally, we conducted a detailed case study across both datasets and identified one reason is VerilogEval’s heavier use of table/graph-based problems, where our model underperforms significantly. Below is a comparison of our model's accuracy against Deepseek-r1 on these problem types, including their ratios within benchmarks:

This points to a key improvement direction: incorporating more table/graph-specific instruction-response pairs (e.g., KMap, FSM, waveform data as in CraftRTL [3]) into our training dataset.

Finally, we should mention that RTLLM is more practical than VerilogEval since VerilogEval clearly states "we do not evaluate the performance of downstream circuit implementations". The similarity between our dataset and RTLLM shows the practicality of our dataset. In addition, we have gone through rigorous data decontamination against these benchmarks by Rouge-L score during data collection (in section 2.2).

[1] Su, H., Shi, W., Kasai, J., Wang, Y., Hu, Y., Ostendorf, M., ... & Yu, T. (2022). One embedder, any task: Instruction-finetuned text embeddings. arXiv preprint arXiv:2212.09741.

[2] Maaten, L. V. D., & Hinton, G. (2008). Visualizing data using t-SNE. Journal of machine learning research, 9(Nov), 2579-2605.

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

• Q2: Definition 2.1 and Theorem 2.1 are confusing. Given the inherently probabilistic nature of LLMs, the conditions in Definition 2.1 are unlikely to hold in practice, which undermines the applicability and significance of Theorem 2.1. Moreover, they appear to have limited relevance to the rest of the paper.

We sincerely thank you for your thoughtful critique regarding our theoretical framework.

As for the stringency of Theorem 2.1's conditions, although LLMs behave probabilistically in text, they can be relatively deterministic when implementing the functionality. For instance, given the NL prompt "Generate a Python implementation of the quicksort algorithm," the specific code text produced might vary slightly (e.g., in variable naming or comment placement), but the core functionality $f$ (i.e., a correctly working quicksort algorithm in Python) remains highly consistent. Notably, the stronger the model's capability and the more specific the NL description, the more deterministic this $L \rightarrow F$ (NL->code) mapping becomes. This logic also applies in the reverse direction, where generating an NL description ($l$) from a given code ($f$) can exhibit similar determinism under sufficient model competence. We will clarify this in our revised paper.

Definition 2.1 and Theorem 2.1 are relevant to the rest of the paper based on the above insights. They provide a theoretical foundation for understanding why the round-trip data synthesis process can enhance data quality: as model capacity approaches the assumptions outlined in Definition 2.1 (e.g., more reliable bidirectional mappings), the outputs of the synthesis process align more closely with the guarantees in Theorem 2.1, resulting in higher-quality data. Specifically, the deterministic equivalence of generated code and source code will guarantee the correctness of both problem summarization and code generation. Our experimental results further validate the reasonableness of this theoretical framework.

In conclusion, these definitions and theorems offer critical insights from an information-theoretic perspective, elucidating the underlying mechanisms through which round-trip synthesis reduces noise and strengthens the consistency between input and output spaces—ultimately justifying its effectiveness in improving data quality.

• Q3: The natural language description generator component would benefit from a deeper analysis. While the appendix includes some illustrative examples, they are limited to short RTL code snippets. In practice, generating natural language descriptions for complex RTL modules, especially those involving non-trivial sequential logic, is a challenging task. Without access to simulation traces, inferring sequential behavior from code alone is difficult even for human experts. This raises concerns about the generator's ability to generalize to realistic and more complex RTL designs.

We sincerely thank you for your insightful perspective on natural language generation for complex RTL. We would like to engage with this perspective through the following technical considerations:

Our dataset contains significantly more complex code than the limited examples included in the appendix. This underscores the capability of our natural language description generator: it can effectively handle such complex code, as evidenced by the high-performance model we trained using the dataset—composed entirely of (problem, code) pairs generated by this generator. Notably, our model can solve asyn_fifo (147 lines of golden code) and float_multi (165 lines) in RTLLM v2. Below is a table comparing the average code length (in tokens) in our dataset with that of the benchmarks (RTLLM v2 and VerilogEval v2 - Spec to RTL).

From the table, the average code length in our dataset is longer than that in RTLLM v2 and VerilogEval v2. Besides, the longest code in our SFT dataset is over 3000 tokens, and those can pass the round-trip equivalence checking in our RL dataset include relatively complex ones like single round of SHA-256 calculation.

We also acknowledge that, although we have trained a high-performance model using our workflow involving this natural language description generator, we have room to further improve this process. For example, we can add mechanisms like multi-turn refinement for code summarization with RTL simulator, code parser or other tools.

Thank you again for your valuable feedback. Should our responses adequately address your concerns, we would be grateful for your consideration in recognizing these improvements in your final assessment. If any questions remain, we welcome further discussion.

Dear reviewer, we sincerely thank you for taking the time to review our paper. As the discussion phase is coming to an end, we note that you have read our response but have not raised any further discussion. We believe that our response addresses your main concerns. We would greatly appreciate it if you could review our response and participate in the discussion by indicating whether your concerns have been addressed. This will help ensure a fair and comprehensive evaluation of our work. Thank you again for your valuable contribution.

Dear Reviewer,

We hope this message finds you well. As the discussion period is nearing its end (extended to Aug 8, 11.59 pm AoE), we want to ensure that we have addressed all of your concerns satisfactorily. If there are any additional suggestions or feedback you'd like us to consider, please do not hesitate to let us know. Your insights are invaluable to us, and we're eager to address any remaining concerns to improve our work.

Thank you for your time and effort in reviewing our paper.

Thank you sincerely for your thoughtful and detailed feedback on our work. We greatly appreciate your recognition of the importance of the RTL code generation problem, as well as your positive remarks on our adoption of various ML-based techniques. Your inquiries regarding model applications have offered valuable guidance for both the current implementation and future development of R2TL. Addressing your primary concern, we present our perspectives below.

• Q1: The results aren't mindblowing compared to state-of-the-art methods. So the question then becomes is such a complex approach necessary, or will future reasoning model releases potentially outperform R2TL? I still did appreciate the thorough evaluation, but as a user, would the author recommendation be to use R2TL right now, or wait for Deepseek-R1+N? That said, it seems like future R2TL can benefit from a vanilla DeepSeek reasoner and/or coder model (qwen2.5), so perhaps there is lots of merit to R2TL. Could the authors comment a bit about such a scenario?

Thank you for raising this point. The core value of R2TL lies in its unique advantages that make it a compelling choice for specific use cases.​

Firstly, R2TL boasts significant deployment advantages due to its compact size. With only 7B parameters, it stands in stark contrast to DeepSeek-R1’s 671B parameters, reducing storage requirements by two orders of magnitude. Additionally, its computational demands are approximately an order of magnitude lower than DeepSeek-R1 under the same token budget. Importantly, R2TL is already well-equipped to handle a range of automated design tasks effectively. These characteristics—strong capability paired with high deployment efficiency—make it a viable and excellent choice for local deployment, as it can be set up and run with minimal resource investment, allowing for quick integration into existing workflows.​

Secondly, R2TL represents a generalizable approach that can evolve alongside advancements in general-purpose models, showing the effectiveness of the distillation followed by RL approach in the hardware design domain. Its performance is inherently tied to the capabilities of the models in its training pipeline—both distillation models like DeepSeek-R1 and base models like Qwen2.5-Coder-Instruct. As these models improve, with distillation models generating higher-quality training data and base models providing stronger foundational architectures, R2TL’s performance will strengthen in tandem. This adaptability allows it to leverage future developments in such models, ensuring it remains relevant and powerful as the field progresses.​

Thirdly, in terms of user applicability, R2TL is particularly well-suited for professional developers and researchers with specialized needs. While entry-level users and developers may find general-purpose models more accessible via web interfaces or APIs to meet basic requirements, R2TL offers unique value to professionals. Specifically, when these users possess private data or their own base models, they can leverage R2TL's training pipeline to develop dedicated models that are more powerful and better suited to their specific needs. This makes it highly beneficial for those in fields like chip automated design or other AI domains to tackle domain-specific design tasks effectively.

In summary, R2TL is not only a practical tool for current applications with its deployment-friendly size and efficiency but also a generalizable approach that can grow with advancements in foundational models, making it particularly valuable for professional users requiring independent deployment or training with their unique data.

Thank you again for this valuable discussion. We welcome further discussion if you have any questions.

Thank you for your valuable feedback. We appreciate your recognition of our contributions, including our method and model performance. Your insights on the limitations, including rule-based testbenches’ scalability, VerilogEval performance, training data size and complexity concerns, and agent performance, are crucial and will guide our improvements. We will address your concerns as follows:

• W1&Q3: The rule-based testbench generation may require manual maintaining with more expert heuristics for complex or real-world Verilog design. How to generalize it to larger-scale or complex/hierarchical modules?

Thank you for pinpointing the challenges of rule-based approaches in complex Verilog verification. Our testbench, built on manual rules, runs fully automatically and works directly for complex multi-module designs like SHA256 or FFT, validating DUT-golden code equivalence via consistent I/O checks.

Limitations of our framework include unguaranteed coverage with random I/O, no support for multiple clocks, and certain syntax issues (e.g., macro definitions, Verilog-SystemVerilog reserved word differences). A future direction is to added LLM-generated directed cases to target corner cases missed by random stimuli.

• W2: While the method outperforms SOTA on RTLLM, it underperforms on VerilogEval, I believe the RTLLM has fewer tests and is relatively easier than VerilogEval.

We sincerely thank you for highlighting the performance differences across benchmarks. We emphasize that RTLLM is harder and more practical than VerilogEval. Moreover, our model has also achieved SOTA results among 7B models on VerilogEval v1-Human (surpassing the previous SOTA model CraftRTL-DS-6.7B by 4.5%) and VerilogEval v2.

In terms of practicality, VerilogEval [1] explicitly states that "we do not evaluate the performance of downstream circuit implementations, a gap that is addressed by the work presented in RTLLM". Therefore, RTLLM is more aligned with real-world applications. The test coverage on RTLLM is strong, with 98.5% average line coverage for v1.1 and 96.0% for v2, which is satisfactory.

Regarding difficulty, results in Tables 1&2 show most models (except Qwen2.5-Coder and RTLCoder-Mistral-7B) perform better on VerilogEval than RTLLM, including our distillation model R2TL-7B-Distill. RTLLM is also harder by code length -- The table below provides the average number of lines and tokens (comments and blank lines removed) for VerilogEval and RTLLM:

Meanwhile, our dataset's distribution is more consistent with RTLLM than VerilogEval. Details can be found in the answer for Q1 for reviewer oSjb.

[1] Liu, M. et al. Verilogeval: Evaluating large language models for verilog code generation.

[2] Su, H. et al. One embedder, any task: Instruction-finetuned text embeddings.

• W3: 3.1k data is small (although high-quality), which may affect the generalization and robustness of RL training, even induce overfitting to the dataset distribution. This is not well verified and discussed in the paper.

We appreciate your note on the dataset scale. Our model shows strong generalization on unseen benchmark problems, as evidenced by the performance gain from R2TL-7B-Distill (without RL) to R2TL-7B (with RL) on VerilogEval and RTLLM (Tables 1&2). Note we have rigorously de-contaminated our training data against benchmarks to avoid overfitting as shown in Section 2.2.

Moreover, 3.1k is typical for RL in this context. LLM-based RL prioritizes data quality over quantity: Qwen3 [1] utilized 3995 query-verifier pairs during their reasoning RL phase. LIMR [2] filtered 8523 RL data down to 1389 and achieved superior results. Logic-RL [3] enhanced models' logical reasoning capabilities using a mere 900 instances. All these works demonstrate that 3.1k data is sufficient for our RL setup. We will clarify this in the revised paper.

[1] Yang, A. et al. Qwen3 technical report.

[2] Li, X. et al. Limr: Less is more for rl scaling.

[3] Xie, T. et al. Logic-rl: Unleashing llm reasoning with rule-based reinforcement learning.

• Q1: How could R2TL be potentially combined with agentic methods? Will it still outperform large size model? e.g, MAGE: A Multi-Agent Engine for Automated RTL Code Generation, which demonstrates 95% pass rate for VerilogEval dataset.

Thank you for your forward-looking inquiry regarding agentic integration. We note two fundamental distinctions between MAGE and R2TL: First, the MAGE agent uses the golden testbench while R2TL does not. Second, the performance of MAGE strongly depends on prompt engineering and is model-dependent (see table below), which does not align well with the model capacity.

Given these divergences and computational constraints (MAGE's multi-agent sequential calls limiting parallelization efficiency, as well as the time limitation of rebuttal period), we designed a targeted experiment, using R2TL to replace the RTL generation agent (which best aligns R2TL's ability among the four agents) in MAGE, keeping other agents based on Claude. The test results are shown in the table below.

These results demonstrate the potential of R2TL to be applied in the agent workflow, which implies R2TL could develop end-to-end agent capabilities in the future.

• Q2: What is the complexity of the RTL code (#tokens) obtained from GitHub? Any case with a very long context length that fails with the 16k context length?

Thank you for raising this point. Below are some statistics of our 87k distillation dataset:

Distillation considers (prompt + response) length: around 0.8% of the data exceed the 16k context length and truncated. Meanwhile, the longest RTL code in our dataset is 3375 tokens. Some examples of long code include single round of SHA-256 calculation, CORDIC arctan() implementation, BCD-format 12-hour clock with AM/PM, etc.

• Q4: What could be some potential solutions to further reduce the 2.7% wrong flags?

Thank you for your concern about this. The 2.7% mismatch in golden-vs-golden comparisons mainly stems from corner syntax errors, like inconsistent variable names, generated by the automated testbench, while the runtime inequivalences only count for 0.3%. In contrast, the 7.6% inaccuracy for LLM-generated testbenches excludes such test-phase errors. Using a consistent standard, our method’s false negative rate is less than 1/20 of the LLM approach, showing superior stability.

For the remaining inequivalences, around half involve random numbers, which fall outside our testbench's scope. For the remaining half, removing the -g2012 compile option works for some cases, and switching from Icarus Verilog to VCS can work for most cases. (However, VCS requires license so it is not as convenient as Icarus Verilog.)

• Q5: How does the method can be potentially generalized to other HDLs like VHDL, System Verilog?

We appreciate your question about HDL generalization. Our method is adaptable to other HDLs: we already support SystemVerilog (for VerilogEval) and Verilog (for RTLLM). To extend to other HDLs like VHDL, our five-stage framework (Figure 1) can be adjusted for specific languages:

In pre-Stage 1 data preparation, we would collect language-specific code snippets (e.g., VHDL modules) from relevant repositories, similar to how we gathered Verilog from GitHub.

For Stages 3-5, our automated testbench framework would be extended to support the target HDL (mainly syntax adaptation), enabling proper verification during difficulty filtering (Stages 3,5) and equivalence checking (Stage 4).

With such adjustments, R2TL can generalize to more HDLs beyond Verilog and SystemVerilog.

Thank you again for this valuable discussion. Please feel free to ask if you still have any questions.