Pith. sign in

REVIEW 4 major objections 4 minor 54 references

ChiseLLM: Unleashing the Power of Reasoning LLMs for Chisel Agile Hardware Development

T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Pith's one-line read Domain-adapted reasoning traces make small open LLMs competitive at Chisel hardware code generation.

desk verdict Useful open Chisel code-generation artifacts, but the abstract's numbers are misreported and the training/benchmark overlap needs an audit before the gains can be trusted. read the letter →

arxiv 2504.19144 v1 pith:EX65XC6V submitted 2025-04-27 cs.AI cs.ARcs.SE

classification cs.AIcs.ARcs.SE
keywords ChiselhardwareconstructionlanguageLLMcodegenerationreasoningmodelsdomainadaptationtracedistillationagiledevelopmentRTLdecompilation
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

This paper argues that general reasoning models fail to improve Chisel code generation unless they are adapted to the hardware domain. It presents ChiseLLM, a dataset-and-model pipeline that distills prompt-guided reasoning traces into small open code models. If correct, the work shows that a 32B model can reach the Chisel generation quality of much larger commercial systems, making LLM-assisted agile hardware development practical at low cost. The paper also introduces two task formulations, Spec-to-Chisel and Decompile-to-Chisel, and reports that domain adaptation raises variability design ability substantially.

What carries the argument

The central mechanism is prompt-guided reasoning trace distillation: a strong reasoning model is given prompts that inject Chisel documentation fragments, benchmark reference answers, variant-pattern specifications, and Chisel feature descriptions, and its resulting reasoning traces are used to fine-tune smaller base models. This transfers task-specific thinking patterns rather than merely teaching new facts. The data pipeline also includes filtering Chisel and Verilog sources, converting them into completion and decompilation instruction datasets, and mixing those datasets in a 3:7 ratio for training.

What would settle it

Run the same design specifications through native Chisel testbenches, compiling each generated module with the Scala compiler and exercising it with Chisel's own testing constructs. If the models' Pass@k drops sharply under native testing, the SystemVerilog bridge was inflating the reported results.

Watch

Extended reading notes

Core claim

The central claim is that domain adaptation through prompt-guided reasoning trace distillation converts generic code models into capable Chisel generators, while unadapted reasoning models do not bring consistent benefits. On Verilog-derived benchmarks, ChiseLLM-7B and ChiseLLM-32B improve syntax correctness by 18.85% and 26.32% respectively over their base models, and the 32B model matches or beats much larger commercial systems on several functional-correctness measures. The same training lifts variability design ability by 47.58% relative to a baseline reasoning model. The authors attribute the gain to the distilled thinking patterns: the models learn to reason about the module's function, recall Chisel syntax from documentation, consider configurable, functional, and structural variants, and only then emit code.

Load-bearing premise

The reported Pass@k numbers treat Verilog testbenches as a proxy for Chisel correctness: generated Chisel is compiled to SystemVerilog and run against the original Verilog testbench, so the whole comparison assumes that translation preserves the benchmark's interfaces and semantics closely enough for failures to reflect real Chisel errors.

Editorial extensions

If this is right

  • Smaller open models, around 7B and 32B parameters, can be made to generate Chisel that is syntactically and functionally competitive with much larger commercial systems, cutting the compute cost of LLM-assisted hardware design.
  • Unadapted reasoning models cannot be assumed to help on low-resource hardware languages; domain adaptation is a precondition for practical gains.
  • Combining a Chisel code-completion dataset with a Verilog-to-Chisel decompilation dataset produces larger gains than either dataset alone, pointing to a synergistic effect.
  • Injecting variant-pattern guidance into reasoning traces teaches models to produce parameterized, configurable designs, supporting design-space exploration and agile hardware methodology.

Reading between the lines

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

  • If the reported gains hold, the same prompt-guided distillation recipe should transfer to other hardware construction languages and to other low-resource domain-specific languages, since the bottleneck appears to be task-specific thinking patterns rather than model scale.
  • The correctness numbers rest on compiling generated Chisel to SystemVerilog and running Verilog testbenches; a native Chisel testbench suite would be a stronger check and might change the absolute Pass@k values.
  • A natural extension would be to compile generated parameterized modules at several configurations and verify that each configuration is synthesizable and functionally correct, testing whether the variability improvements survive real parameter sweeps.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper presents ChiseLLM, a dataset construction and fine-tuning pipeline intended to adapt reasoning large language models to Chisel hardware description generation. The authors collect Chisel and Verilog sources from public repositories, construct completion and decompile instruction datasets, use DeepSeek-R1 with prompt-guided templates to synthesize reasoning traces, and fine-tune Qwen2.5-Coder-7B and 32B. They evaluate against VerilogEval-Human and RTLLM v2.0 using Pass@k and syntax correctness, and use LLM-as-a-judge to score variability. The reported results claim large improvements over base models and performance comparable to commercial systems.

Significance. If the results hold, this is a practically useful contribution to a low-resource domain: it provides open datasets and models for Chisel, demonstrates a prompt-guided reasoning distillation recipe, and shows that smaller open-weight models can be adapted to a niche hardware language with substantial gains. The strengths are the concrete pipeline, public release of datasets and models, and use of a standard Pass@k evaluation with compilation-based syntax checking. However, the current reporting of the headline numbers is internally inconsistent, the evaluation is not decontamination-checked, and the variability metric rests on a partially self-referential LLM judge. These issues currently prevent the quantitative claims from being fully trusted.

major comments (4)
  1. [Abstract, Section I, Table II] The headline improvements do not match the data in Table II. The abstract and Section I state that ChiseLLM-7B and ChiseLLM-32B improve 'syntax correctness' by 18.85% and 26.32%, respectively. Computed from Table II, the 26.32% figure is the average absolute improvement in Pass@5 for 32B across the four benchmark columns, not a syntax-correction gain; the actual syntax-correctness improvements for 32B are 2.98, 10.78, 16.05, and 33.90 percentage points (mean 15.93). The 18.85% equals the 7B syntax improvement averaged only over the two VerilogEval-Human columns, not an overall average. The paper must correct the abstract, introduction, and any other summary statements so that every reported percentage is clearly tied to a defined metric and the set of tasks.
  2. [Section IV-A, Section V-B, Table II] No decontamination or overlap analysis is reported between the training data and the evaluation benchmarks. The training data come from the-stack-v2-dedup and public Verilog datasets (Section IV-A, Fig. 2a), while VerilogEval-Human and RTLLM v2.0 are public, GitHub-derived Verilog collections used for testing. Because the Decompile-to-Chisel training set consists of (Verilog source, target Chisel) pairs, any benchmark Verilog file or near variant appearing in training could inflate Pass@k and syntax results relative to baselines that did not see those files. The authors should report a contamination check (e.g., exact or near-duplicate detection of benchmark prompts and source files in the training corpora) or explicitly decontaminate the training data and re-run the evaluation.
  3. [Section IV-B2, Section V-B, Variability Evaluation Method, Figure 4] The variability evaluation is partially self-referential and the exclusion rule is underspecified. The ChiseLLM models were fine-tuned on reasoning traces that explicitly demonstrate the exact variant patterns (configurable, functional, structural) that the judge is asked to score, and the judge is an LLM rather than human evaluation. In addition, the paper states that 'samples with high evaluation variance are not included' but does not give the variance threshold or the number of excluded samples. This can bias the reported 47.58% improvement. Please report the exclusion statistics, provide a judge-human agreement or inter-judge agreement measure, and add an analysis showing that the variability score is not simply a reward for reproducing the training-distribution reasoning patterns.
  4. [Section V-B, Correctness Evaluation Method] The validity of Pass@k as a measure of Chisel quality depends on an assumption that is not tested. The paper compiles generated Chisel to SystemVerilog with ChiselStage.emitSystemVerilog and then runs the original Verilog testbenches, which assumes that the emitted SystemVerilog matches the benchmark module interface and semantics closely enough for testbench failures to reflect real Chisel errors. The paper should state how many generated samples failed at the emission or simulation stage and, ideally, validate the pipeline on a small set of human-written Chisel designs with known-correct SystemVerilog equivalents. This issue applies symmetrically to all models, but it affects the absolute Pass@k values and the interpretation of cross-model comparisons.
minor comments (4)
  1. [Figure 4] Figure 4 reports mean variability scores without error bars or confidence intervals, even though the text discusses variance and uncertainty; please add dispersion measures or a table with standard deviations.
  2. [Table II, Section V-C] The statement that 'ChiseLLM-32B consistently ranks as the top or second-best performer across all metrics' is not supported by Table II: on VerilogEval-Human Spec-to-Chisel P@5 and syntax, DeepSeek-R1-671B is higher, and on several columns ChiseLLM-32B is not second-best. Please qualify this claim.
  3. [Section IV-A, Reference [38]] The reference for The Stack v2 is given as 'A. L. et al.'; please provide the full author list or a proper citation format so that readers can verify the dataset.
  4. [Section V-B, Variability Evaluation Method] The paper promises a 'standardized evaluation system' but does not release the judge prompt or the list of generated variants; making these public would significantly improve reproducibility and trust in the variability results.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: central correctness claims rest on external Verilog benchmarks, and the variability evaluation is a supervised-alignment check rather than a derivation that reduces to its own inputs.

full rationale

The paper's main empirical claims—Pass@k and syntax correctness improvements—are measured on VerilogEval-Human and RTLLM v2.0, which are external Verilog benchmarks, not on the ChiseLLM training sets. The training pipeline is described as using the-stack-v2-dedup and public Verilog sources, and no equation or fitting procedure in the paper reconstructs the reported benchmark numbers from the training data by construction. The 'benchmark answers' used as guidance during prompt-guided distillation are reference answers for the training code, not the evaluation benchmarks, so the correctness evaluation is not self-referential on the face of the paper. The variability evaluation uses LLM-as-a-Judge with explicit criteria, and the training data explicitly taught the target variant patterns; this is a case of fine-tuning toward the evaluated capability, which is a normal supervised-adaptation claim, not circularity in the sense of a prediction being equivalent to its input. The paper also does not rely on a load-bearing self-citation or an author-imported uniqueness theorem. The absence of a decontamination/overlap analysis is a real external-validity threat, since training on public RTL corpora could in principle overlap with the public benchmarks, but that is a contamination risk requiring evidence, not a demonstrated circular reduction; under the hard rules, no specific reduction can be quoted, so the appropriate finding is no significant circularity.

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

The ledger contains no new physical entities. All free parameters are design choices in data mixing, context length, and evaluation. The core claims rest on unvalidated transfer assumptions for benchmark validity and judge-based variability scoring.

free parameters (3)
  • Completion/Decompile data mixing ratio = 3:7
    Section IV-C states the data is mixed with a sampling ratio of 3:7 for Completion and Decompile datasets; the ratio is chosen by hand and no search or sensitivity analysis is reported.
  • Reference document count per code sample = 5-10 documents
    Section IV-B1 reports each code sample is matched to several relevant documents, averaging between 5 and 10; this range is not optimized or justified with experiments.
  • High-variance exclusion threshold in variability evaluation
    Section V-B says samples with high evaluation variance are not included, but no threshold is reported, making the exclusion rule a potentially post-hoc, unquantified selection choice.
assumptions (4)
  • domain assumption Publicly collected and LLM-annotated Chisel/Verilog data form a high-quality training corpus.
    Section IV-A asserts quality through filtering and annotation, but correctness of the training code is not verified by compilation or simulation for all samples.
  • domain assumption Verilog benchmarks and testbenches transfer to Chisel correctness evaluation.
    Section V-B compiles generated Chisel to SystemVerilog and runs Verilog testbenches; there is no validation that failures isolate Chisel errors rather than interface mismatches.
  • domain assumption LLM-as-a-judge yields valid variability scores.
    Section V-B provides no human rating, inter-rater agreement, or correlation analysis for the variability judge, and high-variance samples are dropped.
  • domain assumption Fine-tuning mostly re-weights pre-trained knowledge, so distilled traces can teach thinking patterns.
    Section IV-B relies on the LIMA finding [40]; if this premise is false, the distillation may be teaching superficial formatting rather than reusable reasoning.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ChiseLLM: Unleashing the Power of Reasoning LLMs for Chisel Agile Hardware Development." pith.science (2026). https://pith.science/paper/EX65XC6V

@misc{pith2026250419144,
  author       = {Pith},
  title        = {Pith review of: ChiseLLM: Unleashing the Power of Reasoning LLMs for Chisel Agile Hardware Development},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EX65XC6V}},
  note         = {Machine review of arXiv:2504.19144}
}
read the original abstract

The growing demand for Domain-Specific Architecture (DSA) has driven the development of Agile Hardware Development Methodology (AHDM). Hardware Construction Language (HCL) like Chisel offers high-level abstraction features, making it an ideal language for HCL-Based AHDM. While Large Language Models (LLMs) excel in code generation tasks, they still face challenges with Chisel generation, particularly regarding syntax correctness and design variability. Recent reasoning models have significantly enhanced code generation capabilities through test-time scaling techniques. However, we found that reasoning models without domain adaptation cannot bring substantial benefits to Chisel code generation tasks. This paper presents ChiseLLM, a solution comprising data processing and transformation, prompt-guided reasoning trace synthesis, and domain-adapted model training. We constructed high-quality datasets from public RTL code resources and guided the model to adopt structured thinking patterns through prompt enhancement methods. Experiments demonstrate that our ChiseLLM-7B and ChiseLLM-32B models improved syntax correctness by 18.85% and 26.32% respectively over base models, while increasing variability design ability by 47.58% compared to baseline reasoning models. Our datasets and models are publicly available, providing high-performance, cost-effective models for HCL-Based AHDM, and offering an effective baseline for future research. Github repository: https://github.com/observerw/ChiseLLM

Figures

Figures reproduced from arXiv: 2504.19144 by the authors.

Figure 1
Figure 1. An overview diagram of the construction of the ChiseLLM datasets and models, including Source Data Processing & Synthesing, Prompt-Guided [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Diagrams related to the ChiseLLM data processing and distillation [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Schematic diagrams of the three types of design variant. Practical [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Variability design capability of different models on the RTLLM dataset [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: An actual example of ChiseLLM-32B and Qwen2.5-32B-Coder-Instruct decompiling Verilog source code. The gray part represents the Verilog source [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: An actual example of ChiseLLM-32B decompiling Verilog source [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

54 extracted references · 40 canonical work pages

  1. [1]

    An agile approach to building risc-v microprocessors,

    Y . Lee and A. e. a. Waterman, “An agile approach to building risc-v microprocessors,” IEEE Micro, vol. 36, no. 2, pp. 8–20, 2016

  2. [2]

    Creating an agile hardware design flow,

    R. Bahr and C. e. a. Barrett, “Creating an agile hardware design flow,” in 2020 57th ACM/IEEE Design Automation Conference (DAC) , 2020, pp. 1–6

  3. [3]

    On programming variability with large language model-based assistant,

    M. Acher and J. G. e. a. Duarte, “On programming variability with large language model-based assistant,” in Proceedings of the 27th ACM International Systems and Software Product Line Conference - Volume A. Tokyo Japan: ACM, Aug. 2023, pp. 8–14

  4. [4]

    On hardware variability and the relation to software variability,

    C. Brink and E. e. a. Kamsties, “On hardware variability and the relation to software variability,” in 2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications , 2014, pp. 352–355

  5. [5]

    Chisel: Constructing hardware in a scala embedded language,

    J. Bachrach and H. e. a. V o, “Chisel: Constructing hardware in a scala embedded language,” in Proceedings of the 49th Annual Design Automation Conference. San Francisco California: ACM, Jun. 2012, pp. 1216–1225

  6. [6]

    SpinalHDL,

    C. Papon and Y . Xiao, “SpinalHDL,” Apr. 2025

  7. [7]

    Towards Developing High Performance RISC- V Processors Using Agile Methodology,

    Y . Xu and Z. e. a. Yu, “Towards Developing High Performance RISC- V Processors Using Agile Methodology,” in 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO) , 2022, pp. 1178–1199

  8. [8]

    Chipsalliance/rocket-chip,

    “Chipsalliance/rocket-chip,” CHIPS Alliance, Apr. 2025

Show all 54 references
  1. [9]

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

    N. Jain and K. e. a. Han, “Livecodebench: Holistic and contamination free evaluation of large language models for code,” arXiv preprint arXiv:2403.07974, 2024

  2. [10]

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

    N. Pinckney and C. e. a. Batten, “Revisiting VerilogEval: A year of improvements in large-language models for hardware code generation,” Feb. 2025

  3. [11]

    Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,

    S. Liu and W. e. a. Fang, “Rtlcoder: Outperforming gpt-3.5 in design rtl generation with our open-source dataset and lightweight solution,” in 2024 IEEE International Workshop on LLM-Aided Design . IEEE, 2024

  4. [12]

    Chipgpt: How far are we from natural language hardware design,

    K. Chang and Y . W. et al., “Chipgpt: How far are we from natural language hardware design,” 2023. [Online]. Available: https: //arxiv.org/abs/2305.14019

  5. [13]

    Rechisel: Effective automatic chisel code gen- eration by llm with reflection,

    J. Niu and X. e. a. Liu, “Rechisel: Effective automatic chisel code gen- eration by llm with reflection,” in Proceedings of the 62nd ACM/IEEE Design Automation Conference (DAC) . San Francisco, CA, USA: ACM/IEEE, Jun. 2025

  6. [14]

    ChatChisel: Enabling Agile Hardware Design with Large Language Models,

    T. Liu and Q. e. a. Tian, “ChatChisel: Enabling Agile Hardware Design with Large Language Models,” in 2024 2nd International Symposium of Electronics Design Automation (ISEDA) . Xi’an, China: IEEE, May 2024, pp. 710–716

  7. [15]

    Introducing OpenAI o1,

    “Introducing OpenAI o1,” https://openai.com/o1/, Sep. 2024

  8. [16]

    DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning,

    DeepSeek-AI, “DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning,” Jan. 2025

  9. [17]

    Scaling llm test-time compute optimally can be more effective than scaling model parameters,

    C. Snell and J. e. a. Lee, “Scaling llm test-time compute optimally can be more effective than scaling model parameters,” arXiv preprint arXiv:2408.03314, 2024

  10. [18]

    From decoding to meta-generation: Inference-time algorithms for large language models,

    S. Welleck and A. e. a. Bertsch, “From decoding to meta-generation: Inference-time algorithms for large language models,” arXiv preprint arXiv:2406.16838, 2024

  11. [19]

    O1 tops aider’s new polyglot leaderboard,

    “O1 tops aider’s new polyglot leaderboard,” https://aider.chat/2024/12/21/polyglot.html, Dec. 2024

  12. [20]

    S*: Test time scaling for code generation,

    D. Li and S. C. et al., “S*: Test time scaling for code generation,”

  13. [21]

    Qwen2.5-coder technical report,

    B. Hui and J. e. a. Yang, “Qwen2.5-coder technical report,” arXiv preprint arXiv:2409.12186, 2024

  14. [22]

    Chip multi-processor generator,

    A. Solomatnikov and A. e. a. Firoozshahian, “Chip multi-processor generator,” in Proceedings of the 44th Annual Design Automation Conference, ser. DAC ’07. New York, NY , USA: Association for Computing Machinery, 2007, p. 262–263. [Online]. Available: https://doi.org/10.1145/1...

  15. [23]

    A pythonic approach for rapid hardware prototyping and instrumentation,

    J. Clow and G. e. a. Tzimpragos, “A pythonic approach for rapid hardware prototyping and instrumentation,” in 2017 27th International Conference on Field Programmable Logic and Applications (FPL) . IEEE, 2017, pp. 1–7

  16. [24]

    Motivation of chisel,

    “Motivation of chisel,” https://www.chisel- lang.org/docs/explanations/motivation

  17. [25]

    Riscv-boom/riscv-boom: SonicBOOM: The berkeley out-of-order ma- chine,

    “Riscv-boom/riscv-boom: SonicBOOM: The berkeley out-of-order ma- chine,” https://github.com/riscv-boom/riscv-boom

  18. [26]

    Llm post-training: A deep dive into reasoning large language models,

    K. Kumar and T. e. a. Ashraf, “Llm post-training: A deep dive into reasoning large language models,” arXiv preprint arXiv:2502.21321 , 2025

  19. [27]

    Chain-of-thought prompting elicits reasoning in large language models,

    J. Wei and X. e. a. Wang, “Chain-of-thought prompting elicits reasoning in large language models,” 2023

  20. [28]

    Introducing OpenAI o3 and o4-mini,

    “Introducing OpenAI o3 and o4-mini,” https://openai.com/index/introducing-o3-and-o4-mini/

  21. [29]

    Claude 3.7 sonnet and claude code,

    “Claude 3.7 sonnet and claude code,” https://www.anthropic.com/news/claude-3-7-sonnet

  22. [30]

    Gemini 2.5: Our most intelligent AI model,

    “Gemini 2.5: Our most intelligent AI model,” https://blog.google/technology/google-deepmind/gemini-model- thinking-updates-march-2025/, Mar. 2025

  23. [31]

    Introducing SWE-bench verified,

    “Introducing SWE-bench verified,” https://openai.com/index/introducing- swe-bench-verified/

  24. [32]

    On the effectiveness of large language models in domain-specific code generation,

    X. Gu and M. e. a. Chen, “On the effectiveness of large language models in domain-specific code generation,” ACM Trans. Softw. Eng. Methodol. , vol. 34, no. 3, Feb. 2025. [Online]. Available: https://doi.org/10.1145/3697012

  25. [33]

    A survey on LLM-based code generation for low-resource and domain-specific programming languages,

    S. Joel and J. J. e. a. Wu, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” Nov. 2024

  26. [34]

    Manifesto for agile software development,

    “Manifesto for agile software development,” https://agilemanifesto.org/

  27. [35]

    Cortellessa and D

    V . Cortellessa and D. e. a. Varr ´o, Eds., Fundamental Approaches to Software Engineering: 16th International Conference, FASE 2013, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2013, Rome, Italy, March 16-24, 2013. Proceedings , se...

  28. [36]

    (system)verilog to chisel translation for faster hardware design,

    J. Bruant and P.-H. H. et al., “(system)verilog to chisel translation for faster hardware design,” in Proceedings of the 31th International Workshop on Rapid System Prototyping, RSP 2020, Virtual Conference, September 24-25, 2020 . ACM, 2020

  29. [37]

    Towards agile hardware designs with chisel: A network use-case,

    J. Bruant and P.-H. e. a. Horrein, “Towards agile hardware designs with chisel: A network use-case,” IEEE Design & Test , 2021

  30. [38]

    Starcoder 2 and the stack v2: The next generation,

    A. L. et al., “Starcoder 2 and the stack v2: The next generation,” 2024

  31. [39]

    Ucb-bar/chiseltest,

    “Ucb-bar/chiseltest,” UC Berkeley Architecture Research, Feb. 2025

  32. [40]

    LIMA: Less is more for alignment,

    C. Zhou and P. e. a. Liu, “LIMA: Less is more for alignment,” in Ad- vances in Neural Information Processing Systems , A. Oh, T. Naumann, A. Globerson, K. Saenko, M. Hardt, and S. Levine, Eds., vol. 36. Curran Associates, Inc., 2023, pp. 55 006–55 021

  33. [41]

    Codeforces cots,

    G. Penedo and A. L. et al., “Codeforces cots,” https://huggingface.co/ datasets/open-r1/codeforces-cots, 2025

  34. [42]

    Open thoughts,

    O. T. Team, “Open thoughts,” Jan. 2025

  35. [43]

    Llamafactory: Unified efficient fine-tuning of 100+ language models,

    Y . Zheng and R. Z. et al., “Llamafactory: Unified efficient fine-tuning of 100+ language models,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations). Bangkok, Thailand: Association for Computational Lin...

  36. [44]

    OpenLLM-RTL: Open Dataset and Benchmark for LLM-Aided Design RTL Generation

    S. Liu and Y . e. a. Lu, “OpenLLM-RTL: Open Dataset and Benchmark for LLM-Aided Design RTL Generation.”

  37. [45]

    Judging llm-as-a-judge with mt-bench and chatbot arena,

    L. Zheng and W.-L. C. et al., “Judging llm-as-a-judge with mt-bench and chatbot arena,” 2023. [Online]. Available: https: //arxiv.org/abs/2306.05685

  38. [46]

    Can LLMs Replace Human Evaluators? An Empirical Study of LLM-as-a-Judge in Software Engineering,

    R. Wang and J. e. a. Guo, “Can LLMs Replace Human Evaluators? An Empirical Study of LLM-as-a-Judge in Software Engineering,” Apr. 2025

  39. [47]

    Qwen2.5 technical report,

    Qwen, “Qwen2.5 technical report,” 2025. [Online]. Available: https: //arxiv.org/abs/2412.15115

  40. [48]

    The llama 3 herd of models,

    M. AI, “The llama 3 herd of models,” 2024. [Online]. Available: https://arxiv.org/abs/2407.21783

  41. [49]

    Deepseek-v3 technical report,

    DeepSeek-AI, “Deepseek-v3 technical report,” 2025. [Online]. Available: https://arxiv.org/abs/2412.19437

  42. [50]

    Hello GPT-4o,

    “Hello GPT-4o,” https://openai.com/index/hello-gpt-4o/

  43. [51]

    Huggingface/open-r1: Fully open reproduction of DeepSeek-R1,

    “Huggingface/open-r1: Fully open reproduction of DeepSeek-R1,” https://github.com/huggingface/open-r1/tree/main

  44. [52]

    CodeV: Empowering LLMs for Verilog Generation through Multi-Level Summarization,

    Y . Zhao and D. e. a. Huang, “CodeV: Empowering LLMs for Verilog Generation through Multi-Level Summarization,” Jul. 2024

  45. [53]

    Betterv: Controlled verilog generation with discriminative guidance,

    Z. Pei and H.-L. Z. et al., “Betterv: Controlled verilog generation with discriminative guidance,” 2024. [Online]. Available: https: //arxiv.org/abs/2402.03375

  46. [2025]

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

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

Pith tools

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