Pith. sign in

REVIEW 4 major objections 5 minor 44 references

Spec2RTL-Agent: Automated Hardware Code Generation from Complex Specifications Using LLM Agent Systems

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

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

Pith's one-line read An LLM agent system claims it can read an unstructured hardware specification document and output correct RTL code, with only about four human check-ins per design.

desk verdict A sensible end-to-end pipeline for spec-to-RTL, but the 3/3 correct claim is not independently verified; treat the accuracy numbers as preliminary. read the letter →

arxiv 2506.13905 v2 pith:T6J4KNHZ submitted 2025-06-16 cs.AR

Zhongzhi Yu , Mingjie Liu , Michael Zimmer , Yingyan Celine Lin , Yong Liu , Haoxing Ren This is my paper
classification cs.AR
keywords RTLcodegenerationLLMagentsmulti-agentsystemshigh-levelsynthesishardwaredesignautomationspecificationunderstandingunstructureddocumentsFIPSbenchmarks
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

Spec2RTL-Agent is a multi-agent LLM system designed to take a raw, unstructured hardware specification document — the kind with figures, tables, equations, and dozens of pages — and produce a functionally correct RTL implementation with only a handful of human interventions. The paper's central claim is that this level of end-to-end automation is achievable today: on three U.S. federal standards documents (AES, DSS, HMAC), the full system reports correct RTL for all three, with an average of about 4.3 human interventions per design compared with roughly 20 for a human-in-the-loop baseline. The design choice that carries the result is to generate synthesizable C++ and let a commercial high-level synthesis tool produce the RTL, rather than asking the LLM to write RTL directly. If the claim holds, hardware teams could delegate a substantial slice of specification-to-implementation work to agents, accelerating design starts and freeing engineers for higher-level decisions.

What carries the argument

The load-bearing mechanism is the three-stage agent loop. First, the iterative understanding and reasoning module summarizes each section of the spec, decomposes the target into implementable sub-functions, and builds a structured information dictionary (inputs, outputs, functionality, references) for each sub-function. Second, the progressive coding and prompt optimization module implements each sub-function by generating pseudocode, then Python, then synthesizable C++, with a verifier that derives test cases from the spec or from higher-level code, and a prompt optimizer that tightens instructions after repeated failures. Third, the adaptive reflection module reviews the whole generation trajectory, classifies the error source as instruction-level, previous-sub-function, current-sub-function, or unclear, and routes the repair accordingly, asking a human only when the source is unclear. A final code optimizer reformats the C++ for the HLS tool, which then produces the RTL.

What would settle it

Run the generated RTL for AES against the published FIPS 197 known-answer test vectors, and run the DSS and HMAC designs against their FIPS test vectors, without letting the agent generate or select the tests; if any implementation fails an independent vector while passing the agent's own tests, the reported correctness claim is refuted.

Watch

Extended reading notes

Core claim

The discovery, on the paper's own terms, is that an end-to-end LLM agent pipeline can convert complex, unstructured specification documents into correct RTL code with minimal human guidance: all three tested FIPS designs (AES, DSS, HMAC) pass the system's verification, with a mean of 4.33 human interventions compared with about twenty for a human-driven coding baseline, a reduction of roughly 75%. The paper attributes this success to three integrated enablers — iterative understanding and reasoning that decomposes the spec into a structured implementation plan with an information dictionary per sub-function, progressive coding that moves from pseudocode to Python to synthesizable C++ with verifier feedback and prompt optimization, and adaptive reflection that traces errors to the right stage and either regenerates code, revises instructions, or escalates to a human. Critically, the system chooses to generate C++ for HLS rather than RTL directly, and the ablations indicate that each of the three modules is needed: removing understanding raises interventions more than fourfold, and removing reflection or progressive coding also degrades the metrics. The paper also demonstrates robustness to injected semantic errors at any stage, recovering to 3/3 correct in all noise conditions.

Load-bearing premise

The load-bearing premise is that the system's own spec-derived test cases actually certify functional correctness; if those tests share the generator's blind spots, the 3/3 correctness result does not establish that the RTL truly matches the specification.

Editorial extensions

If this is right

  • The system reports correct RTL for all three FIPS designs (AES, DSS, HMAC), which means the pipeline is not limited to toy components and can handle multi-module cryptographic implementations.
  • Human effort drops to an average of 4.33 interventions per design, roughly 75% fewer than the human-in-the-loop baseline, directly addressing the labor bottleneck in RTL development.
  • Choosing synthesizable C++ as an intermediate representation and refining it before HLS conversion yields higher correctness than attempting to generate RTL directly.
  • Each module is load-bearing: removing understanding raises human interventions more than fourfold, and removing either progressive coding or reflection significantly increases both interventions and coding iterations.
  • The robustness ablation shows the pipeline can recover from deliberately injected semantic errors at any stage, returning to 3/3 correct even when the implementation plan or code is perturbed.

Reading between the lines

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

  • The correctness verdict currently rests on tests the verifier derives from the same specification, so an independent known-answer test suite is the natural next check; the 3/3 score should not be read as proof against an external oracle.
  • Token cost is a likely scaling constraint, since each sub-function takes around ten code generation or revision attempts; cheaper verification or more selective reflection would be needed for large designs.
  • The understanding–coding–reflection template is not specific to cryptography and could be tried on other specification-heavy engineering domains with mixed text, tables, and figures.
  • Routing through an HLS tool means the generated RTL inherits that tool's coding constraints; designs that need cycle-accurate timing or finely tuned area may still require manual RTL work.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper proposes Spec2RTL-Agent, an LLM multi-agent system that takes raw, unstructured NIST FIPS specification documents (AES, DSS, HMAC) and produces RTL implementations through a pipeline of iterative understanding and reasoning, progressive coding across pseudocode/Python/C++, adaptive reflection, and code optimization followed by Stratus HLS conversion. The authors report that the full system achieves Correct 3/3 on their three-document benchmark with 4.33 human interventions on average, about 75% fewer than their Human baseline, and that ablation studies show each module contributes to accuracy and efficiency. The paper also reports a noise-injection robustness study and a comparison of the generated AES engine's latency, throughput, and area against modified open-source implementations.

Significance. If the reported correctness can be confirmed with independent verification, the contribution is significant: it would be a credible end-to-end demonstration of LLM-based RTL generation from real specification documents with substantially reduced human effort. The system design is thoughtful and well-motivated, and the paper is honest about failure modes, particularly in Figure 6 and the Conclusion. However, the current evaluation does not yet establish functional correctness of the generated RTL, because the verification oracle is largely self-generated and verification is reported on pre-HLS code rather than final RTL. The significance is therefore contingent on strengthening the experimental evidence; the architectural claims themselves are not the main weakness. No public artifacts or reproducibility materials are provided, which further limits the current checkability of the quantitative claims.

major comments (4)
  1. [§V-A, Table I, §IV-C] Section V-A defines Correct only as 'Functional correctness of the generated RTL implementation,' with no testbench, simulation tool, or known-answer vectors, while Section IV-C states that the Verifier derives test cases from the specification document or from previously generated higher-level code and performs self-validation by direct comparison with the specification. Since the specification document is the only source available to the earlier agents, any misinterpretation shared across agents would also be shared by the Verifier and would not be detected; Figure 6, Scenario 2 explicitly shows a case where generated tests cannot identify an error. The 3/3 Correct score in Table I therefore does not, as reported, establish that the RTL is functionally correct. Please add independent testbenches based on NIST known-answer vectors for AES, HMAC, and DSS, report pass/fail per document, and define the acceptance criterion for 'Correct.'
  2. [§IV-E, Table I] The Verifier checks pseudocode, Python, and C++ before the Code Optimizer and HLS conversion; the Code Optimizer changes data formats and static memory usage, and the paper does not report any post-HLS equivalence check, co-simulation, or RTL simulation of the final output. Because the deliverable claimed in the abstract is 'RTL code,' correctness must be demonstrated on the final HLS-generated RTL, for instance by RTL simulation against the same known-answer vectors or by co-simulation against the optimized C++ model. Without that, the Correct column in Table I refers to pre-HLS C++ rather than the generated RTL.
  3. [§V-A, Table I] The central 'up to 75% fewer human interventions' claim depends on the Human baseline's approximately 20 interventions, but Section V-A does not define what counts as one intervention for the Human baseline or for Spec2RTL-Agent, and no per-intervention log is provided. Without a common counting protocol, the intervention counts may not be comparable across methods. Please define the unit of intervention, provide per-document intervention logs, and show how each recorded intervention maps to the four reflection choices in Section IV-D.
  4. [Tables I and II, §V-B] The numerical claims rest on a single run per condition on only three documents, with no variance or repeated runs despite the stochasticity of GPT-4o-based agents. The quantities 4.33, 6.33, 9.00, and 18.67 are presented as deterministic, and no artifacts are released. Please either report repeated runs with variance and confidence intervals, or explicitly frame Table I as illustrative; in either case, a reproducibility statement with prompts, execution logs, generated code, and HLS scripts is needed to make the quantitative claims checkable.
minor comments (5)
  1. [§V-C] The ablation percentages are reported in the wrong order relative to the listed baselines: compared with 'W/o Reflection and Naive Coding,' the correct pairs are 31.6% and 51.9% for interventions and 31.0% and 47.8% for coding iterations.
  2. [Table II] The table header 'HMCA' should be 'HMAC.'
  3. [Abstract, §V-B] The abstract says 'up to 75% fewer human interventions' while Section V-B says 'approximately 75%'; using Table I's ~20 and 4.33 gives about 78%. Please harmonize these numbers and state the exact reduction.
  4. [§IV-D, Fig. 6] The section heading should be 'Adaptive Reflection Module' rather than 'Adapative,' and Figure 6 contains 'Inable' where 'Unable' is meant.
  5. [§V-A, [43]] The implementation details state that GPT-4o is used, but reference [43] cites GPT-4; update the reference or the text so that the cited model matches the described experiments.

Circularity Check

1 steps flagged · score 6.0 of 10

The headline Correct 3/3 is produced by a self-referential oracle: the Verifier generates test cases from the same specification document used by the Coder, with no independent post-HLS functional check reported.

  1. self definitional [Section IV-C (Progressive Coding and Prompt Optimization Module); Section V-A (Evaluation Metrics); Fig. 6]
    "The Verifier either derives test cases from the specification document or utilizes those created from previously implemented higher-level code. In scenarios where external test cases are unavailable, the Verifier performs a self-validation by directly comparing the implementation against the original specifications. ... Correct: Functional correctness of the generated RTL implementation"

    The headline Correct 3/3 in Table I is the Verifier's own judgment. The Verifier's test cases are generated from the same specification document that the Coder reads, or from higher-level code the system itself produced, and in the absence of external tests it self-validates by comparing implementation against the same specification. A passing score therefore measures self-consistency between the LLM's reading of the spec and its generated code, not functional correctness against an independent golden model. The metric Correct is operationally defined as passing the system's self-generated checks, so the reported 3/3 is forced by construction. The paper's Fig.

full rationale

Spec2RTL-Agent itself is a system-engineering contribution; the multi-agent stages (understanding, progressive coding, reflection) are not derived circularly from each other, and the ablations compare configurations of the same pipeline on the same internal metrics. However, the paper's central quantitative claim—accurate RTL with 3/3 correct and 75% fewer interventions—rests on a validation loop. Section IV-C states the Verifier generates test cases from the specification document (same source used by the Coder) and falls back to self-validation against the original specifications when external tests are unavailable. Section V-A defines Correct as functional correctness but provides no external testbench, known-answer vectors, or post-HLS co-simulation; Section IV-E applies a Code Optimizer and HLS after the verifiable C++ stage, and no equivalence check is reported after those transformations. Figure 6 explicitly documents a case where the generated tests could not identify the error and a human had to supply the ground-truth reason. Thus Table I's 3/3 is not load-bearing evidence for functional correctness: it demonstrates that the pipeline can satisfy its own self-generated tests, which is partially circular by construction. The performance comparison against open-source AES covers latency/throughput/area, not functional equivalence, so it does not repair the correctness oracle. Score 6 reflects partial circularity in the evaluation, not in the system's internal derivation; no self-citation chain or imported uniqueness theorem is involved.

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

No physical entities or fitted parameters are introduced. The system architecture uses known ML components (GPT-4o, AutoGen, Stratus HLS) plus agent roles; the unstated assumptions above carry much of the evidential burden.

assumptions (4)
  • ad hoc to paper The three chosen NIST FIPS documents (AES, DSS, HMAC) are representative of complex real-world hardware specifications.
    Used as the entire benchmark in Section V-A; no selection criterion or broader corpus is given, so generality is assumed.
  • ad hoc to paper Functional correctness can be established by LLM-generated test cases derived from the specification document itself.
    Section IV-C states the Verifier 'derives test cases from the specification document'; no external known-answer tests are reported, so correctness depends on this self-referential oracle.
  • domain assumption The Stratus HLS tool faithfully converts the optimized C++ implementation into functionally equivalent RTL.
    Section IV-E relies on the commercial HLS tool and tutorial-derived formatting rules, but no post-synthesis RTL simulation or equivalence check is described.
  • ad hoc to paper The number of human interventions is a comparable and meaningful metric across baselines, with the Human baseline counting about 20 interventions without a published protocol.
    Section V-B uses intervention counts as the main automation measure; the counting rules and the Human baseline construction are not specified.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Spec2RTL-Agent: Automated Hardware Code Generation from Complex Specifications Using LLM Agent Systems." pith.science (2026). https://pith.science/paper/T6J4KNHZ

@misc{pith2026250613905,
  author       = {Pith},
  title        = {Pith review of: Spec2RTL-Agent: Automated Hardware Code Generation from Complex Specifications Using LLM Agent Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T6J4KNHZ}},
  note         = {Machine review of arXiv:2506.13905}
}
read the original abstract

Despite recent progress in generating hardware RTL code with LLMs, existing solutions still suffer from a substantial gap between practical application scenarios and the requirements of real-world RTL code development. Prior approaches either focus on overly simplified hardware descriptions or depend on extensive human guidance to process complex specifications, limiting their scalability and automation potential. In this paper, we address this gap by proposing an LLM agent system, termed Spec2RTL-Agent, designed to directly process complex specification documentation and generate corresponding RTL code implementations, advancing LLM-based RTL code generation toward more realistic application settings. To achieve this goal, Spec2RTL-Agent introduces a novel multi-agent collaboration framework that integrates three key enablers: (1) a reasoning and understanding module that translates specifications into structured, step-by-step implementation plans; (2) a progressive coding and prompt optimization module that iteratively refines the code across multiple representations to enhance correctness and synthesisability for RTL conversion; and (3) an adaptive reflection module that identifies and traces the source of errors during generation, ensuring a more robust code generation flow. Instead of directly generating RTL from natural language, our system strategically generates synthesizable C++ code, which is then optimized for HLS. This agent-driven refinement ensures greater correctness and compatibility compared to naive direct RTL generation approaches. We evaluate Spec2RTL-Agent on three specification documents, showing it generates accurate RTL code with up to 75% fewer human interventions than existing methods. This highlights its role as the first fully automated multi-agent system for RTL generation from unstructured specs, reducing reliance on human effort in hardware design.

Figures

Figures reproduced from arXiv: 2506.13905 by the authors.

Figure 1
Figure 1. Overview of the hardware implementation flow and the comparison [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Visualization of a representative specification document used as [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Overview of our proposed Spec2RTL-Agent system. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (2 more)
Figure 6
Figure 6. Figure 6: Visualizing two representation cases that human intervention is needed. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 5
Figure 5. Figure 5: Visualizing the prompt used to generate Python code for the [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

44 extracted references · 17 canonical work pages

  1. [1]

    Vicuna: An open-source chatbot impressing gpt-4 with 90%* chatgpt quality,

    W.-L. Chiang, Z. Li, Z. Lin, Y . Sheng, Z. Wu, H. Zhang, L. Zheng, S. Zhuang, Y . Zhuang, J. E. Gonzalez, I. Stoica, and E. P. Xing, “Vicuna: An open-source chatbot impressing gpt-4 with 90%* chatgpt quality,” March 2023. [Online]. Available: https://lmsys.org/blog/2023- 03-30-vicuna/

    work page 2023

  2. [2]

    Gpt-3.5,

    OpenAI, “Gpt-3.5,” https://platform.openai.com/docs/models/gpt-3-5, (Accessed on 04/10/2023)

    work page 2023

  3. [3]

    Github copilot,

    GitHub, Inc., “Github copilot,” 2021, accessed: date-of-access. [Online]. Available: https://copilot.github.com

    work page 2021

  4. [4]

    Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models,

    Y . Fu, Y . Zhang, Z. Yu, S. Li, Z. Ye, C. Li, C. Wan, and Y . Lin, “Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models,” arXiv preprint arXiv:2309.10730, 2023

    arXiv 2023

  5. [5]

    Verilogeval: Evaluating large language models for verilog code generation,

    M. Liu, N. Pinckney, B. Khailany, and H. Ren, “Verilogeval: Evaluating large language models for verilog code generation,” arXiv preprint arXiv:2309.07544, 2023

    arXiv 2023

  6. [6]

    Rtllm: An open-source benchmark for design rtl generation with large language model,

    Y . Lu, S. Liu, Q. Zhang, and Z. Xie, “Rtllm: An open-source benchmark for design rtl generation with large language model,” arXiv preprint arXiv:2308.05345, 2023

    arXiv 2023

  7. [7]

    Chip-chat: Challenges and opportunities in conversational hardware design,

    J. Blocklove, S. Garg, R. Karri, and H. Pearce, “Chip-chat: Challenges and opportunities in conversational hardware design,” arXiv preprint arXiv:2305.13243, 2023

    arXiv 2023

  8. [8]

    Chateda: A large language model powered autonomous agent for eda,

    Z. He, H. Wu, X. Zhang, X. Yao, S. Zheng, H. Zheng, and B. Yu, “Chateda: A large language model powered autonomous agent for eda,” arXiv preprint arXiv:2308.10204, 2023

    arXiv 2023

Show all 44 references
  1. [9]

    Towards llm-powered verilog rtl assistant: Self-verification and self-correction,

    H. Huang, Z. Lin, Z. Wang, X. Chen, K. Ding, and J. Zhao, “Towards llm-powered verilog rtl assistant: Self-verification and self-correction,” arXiv preprint arXiv:2406.00115, 2024

    2024 arXiv

  2. [10]

    Craftrtl: High-quality synthetic data generation for verilog code models with correct-by- construction non-textual representations and targeted code repair,

    M. Liu, Y .-D. Tsai, W. Zhou, and H. Ren, “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, 2024

    2024 arXiv

  3. [11]

    Verilogcoder: Autonomous verilog coding agents with graph-based planning and abstract syntax tree (ast)- based waveform tracing tool,

    C.-T. Ho, H. Ren, and B. Khailany, “Verilogcoder: Autonomous verilog coding agents with graph-based planning and abstract syntax tree (ast)- based waveform tracing tool,” arXiv preprint arXiv:2408.08927, 2024

    2024 arXiv

  4. [13]

    Chatcpu: An agile cpu design and verification platform with llm,

    X. Wang, G.-W. Wan, S.-Z. Wong, L. Zhang, T. Liu, Q. Tian, and J. Ye, “Chatcpu: An agile cpu design and verification platform with llm,” in Proceedings of the 61st ACM/IEEE Design Automation Conference, 2024, pp. 1–6

    2024

  5. [14]

    Key stages of hardware product development,

    nAO.Design, “Key stages of hardware product development,” https://nao.design/blog/key-stages-of-hardware-product-development, 2024, accessed: 2024-11-18

    2024

  6. [15]

    Overview of the hardware product development stages: Poc,

    EnCata, “Overview of the hardware product development stages: Poc,” https://www.encata.net/blog/overview-of-the-hardware-product- development-stages-explained-poc-evt-dvt-pvt, n.d., accessed: 2024-11- 18

    2024

  7. [16]

    Key phases of hardware product development,

    Dynedge, “Key phases of hardware product development,” https://dynedge.com/key-phases-hardware-product-development/, n.d., accessed: 2024-11-18

    2024

  8. [17]

    Scalertl: Scaling llms with reasoning data and test-time compute for accurate rtl code generation,

    C. Deng, Y .-D. Tsai, G.-T. Liu, Z. Yu, and H. Ren, “Scalertl: Scaling llms with reasoning data and test-time compute for accurate rtl code generation,” arXiv preprint arXiv:2506.05566, 2025

    2025 arXiv

  9. [18]

    Mg-verilog: Multi- grained dataset towards enhanced llm-assisted verilog generation,

    Y . Zhang, Z. Yu, Y . Fu, C. Wan, and Y . C. Lin, “Mg-verilog: Multi- grained dataset towards enhanced llm-assisted verilog generation,” in 2024 IEEE LLM Aided Design Workshop (LAD). IEEE, 2024, pp. 1–5

    2024

  10. [19]

    Chipnemo: Domain- adapted llms for chip design,

    M. Liu, T.-D. Ene, R. Kirby, C. Cheng, N. Pinckney, R. Liang, J. Alben, H. Anand, S. Banerjee, I. Bayraktaroglu et al., “Chipnemo: Domain- adapted llms for chip design,” arXiv preprint arXiv:2311.00176, 2023

    2023 arXiv

  11. [20]

    Chipalign: Instruction alignment in large language models for chip design via geodesic interpolation,

    C. Deng, Y . Bai, and H. Ren, “Chipalign: Instruction alignment in large language models for chip design via geodesic interpolation,” arXiv preprint arXiv:2412.19819, 2024

    2024 arXiv

  12. [21]

    Rtl- coder: Fully open-source and efficient llm-assisted rtl code generation technique,

    S. Liu, W. Fang, Y . Lu, J. Wang, Q. Zhang, H. Zhang, and Z. Xie, “Rtl- coder: Fully open-source and efficient llm-assisted rtl code generation technique,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2024

    2024

  13. [22]

    Hlspilot: Llm-based high-level synthesis,

    C. Xiong, C. Liu, H. Li, and X. Li, “Hlspilot: Llm-based high-level synthesis,” arXiv preprint arXiv:2408.06810, 2024

    2024 arXiv

  14. [23]

    Evaluating large language models for automatic register transfer logic generation via high-level synthesis,

    S. Swaroopa, R. Mukherjee, A. Debnath, and R. S. Chakraborty, “Evaluating large language models for automatic register transfer logic generation via high-level synthesis,” arXiv preprint arXiv:2408.02793, 2024

    2024 arXiv

  15. [24]

    Autoagents: A framework for automatic agent generation,

    G. Chen, S. Dong, Y . Shu, G. Zhang, J. Sesay, B. F. Karlsson, J. Fu, and Y . Shi, “Autoagents: A framework for automatic agent generation,” arXiv preprint arXiv:2309.17288, 2023

    2023 arXiv

  16. [25]

    Evoagent: Towards automatic multi-agent generation via evolutionary algorithms,

    S. Yuan, K. Song, J. Chen, X. Tan, D. Li, and D. Yang, “Evoagent: Towards automatic multi-agent generation via evolutionary algorithms,” arXiv preprint arXiv:2406.14228, 2024

    2024 arXiv

  17. [26]

    Autogen: Enabling next-gen llm applications via multi-agent conversations,

    Q. Wu, G. Bansal, J. Zhang, Y . Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu et al., “Autogen: Enabling next-gen llm applications via multi-agent conversations,” in First Conference on Language Modeling

  18. [27]

    Multi-agent collaboration: Harnessing the power of intelligent llm agents,

    Y . Talebirad and A. Nadiri, “Multi-agent collaboration: Harnessing the power of intelligent llm agents,” arXiv preprint arXiv:2306.03314, 2023

    2023 arXiv

  19. [28]

    Unleashing cognitive synergy in large language models: A task-solving agent through multi- persona selfcollaboration. arxiv 2023,

    Z. Wang, S. Mao, W. Wu, T. Ge, F. Wei, and H. Ji, “Unleashing cognitive synergy in large language models: A task-solving agent through multi- persona selfcollaboration. arxiv 2023,” arXiv preprint arXiv:2307.05300

    2023 arXiv

  20. [29]

    Agentcoder: Multi-agent-based code generation with iterative testing and optimisation,

    D. Huang, J. M. Zhang, M. Luck, Q. Bu, Y . Qing, and H. Cui, “Agentcoder: Multi-agent-based code generation with iterative testing and optimisation,” arXiv preprint arXiv:2312.13010, 2023

    2023 arXiv

  21. [30]

    Autosafecoder: A multi-agent framework for securing llm code generation through static analysis and fuzz testing,

    A. Nunez, N. T. Islam, S. K. Jha, and P. Najafirad, “Autosafecoder: A multi-agent framework for securing llm code generation through static analysis and fuzz testing,” arXiv preprint arXiv:2409.10737, 2024

    2024 arXiv

  22. [31]

    Autodse: Enabling software programmers to design efficient fpga accelerators,

    A. Sohrabizadeh, C. H. Yu, M. Gao, and J. Cong, “Autodse: Enabling software programmers to design efficient fpga accelerators,” ACM Transactions on Design Automation of Electronic Systems (TODAES), vol. 27, no. 4, pp. 1–27, 2022

    2022

  23. [32]

    R. Alur, R. Bodik, G. Juniwal, M. M. Martin, M. Raghothaman, S. A. Seshia, R. Singh, A. Solar-Lezama, E. Torlak, and A. Udupa, Syntax-guided synthesis. IEEE, 2013

    2013

  24. [33]

    Hardware as policy: Mechanical and computational co-optimization using deep reinforcement learning,

    T. Chen, Z. He, and M. Ciocarlie, “Hardware as policy: Mechanical and computational co-optimization using deep reinforcement learning,” arXiv preprint arXiv:2008.04460, 2020

    2008 arXiv

  25. [34]

    Make every move count: Llm-based high-quality rtl code generation using mcts,

    M. DeLorenzo, A. B. Chowdhury, V . Gohil, S. Thakur, R. Karri, S. Garg, and J. Rajendran, “Make every move count: Llm-based high-quality rtl code generation using mcts,” arXiv preprint arXiv:2402.03289, 2024

    2024 arXiv

  26. [35]

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

    K. Chang, Y . Wang, H. Ren, M. Wang, S. Liang, Y . Han, H. Li, and X. Li, “Chipgpt: How far are we from natural language hardware design,” arXiv preprint arXiv:2305.14019, 2023

    2023

  27. [36]

    Efficient streaming language models with attention sinks,

    G. Xiao, Y . Tian, B. Chen, S. Han, and M. Lewis, “Efficient streaming language models with attention sinks,” arXiv preprint arXiv:2309.17453, 2023

    2023 arXiv

  28. [37]

    Duoattention: Efficient long-context llm inference with retrieval and streaming heads,

    G. Xiao, J. Tang, J. Zuo, J. Guo, S. Yang, H. Tang, Y . Fu, and S. Han, “Duoattention: Efficient long-context llm inference with retrieval and streaming heads,” arXiv preprint arXiv:2410.10819, 2024

    2024 arXiv

  29. [38]

    Meic: Re-thinking rtl debug automation using llms,

    K. Xu, J. Sun, Y . Hu, X. Fang, W. Shan, X. Wang, and Z. Jiang, “Meic: Re-thinking rtl debug automation using llms,” arXiv preprint arXiv:2405.06840, 2024

    2024 arXiv

  30. [39]

    [Online]

    Cadence Design Systems, Inc., Stratus High-Level Synthesis, Accessed 2024, a high-level synthesis tool for designing hardware systems. [Online]. Available: https://www.cadence.com

    2024

  31. [40]

    Advanced encryption standard (aes),

    National Institute of Standards and Technology (NIST), “Advanced encryption standard (aes),” FIPS PUB 197, November 2001. [Online]. Available: https://doi.org/10.6028/NIST.FIPS.197

    2001 doi

  32. [41]

    Digital signature standard (dss),

    ——, “Digital signature standard (dss),” FIPS PUB 186-5, February

  33. [42]

    The keyed-hash message authentication code (hmac),

    ——, “The keyed-hash message authentication code (hmac),” FIPS PUB 198-1, July 2008. [Online]. Available: https://doi.org/10.6028/NIST.FIPS.198-1

    2008 doi

  34. [43]

    OpenAI, “Gpt-4,” https://platform.openai.com/docs/models/gpt-4, (Ac- cessed on 04/10/2023)

    2023

  35. [2020]

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

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

    2001 arXiv

  36. [2023]

    Available: https://doi.org/10.6028/NIST.FIPS.186-5

    [Online]. Available: https://doi.org/10.6028/NIST.FIPS.186-5

    doi

Pith tools

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