Pith. sign in

REVIEW 4 major objections 5 minor 3 cited by

MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization

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

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

Pith's one-line read The paper presents MCP4EDA, the first Model Context Protocol server that lets a large-language-model assistant drive the complete open-source RTL-to-GDSII flow, and shows that feeding actual post-layout timing and area metrics back into…

desk verdict Useful MCP-based EDA orchestration system, but the reported PPA gains are not actually shown to come from backend-aware feedback. read the letter →

arxiv 2507.19570 v1 pith:CKQO3OGF submitted 2025-07-25 cs.AR cs.MA

Yiting Wang , Wanghao Ye , Yexiao He , Yiran Chen , Gang Qu , Ang Li This is my paper
classification cs.ARcs.MA
keywords ModelContextProtocolelectronicdesignautomationlargelanguagemodelssynthesisoptimizationclosed-loopRTL-to-GDSIIOpenLanebackend-aware
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

The paper proposes MCP4EDA, presented as the first Model Context Protocol server that lets a large language model drive the entire open-source RTL-to-GDSII design flow through natural language. Its central claim is that a closed-loop, backend-aware optimization loop, where the LLM reads actual post-layout timing, power, and area metrics from OpenLane and iteratively rewrites the Yosys/ABC synthesis TCL script, produces better timing and area than any of OpenLane's nine fixed synthesis options. Across nine benchmark designs the reported geometric-mean result is a 0.94 delay ratio (about 6% faster) and a 0.91 area ratio (about 9% smaller) relative to the best fixed baseline, while a fixed-API LLM template without backend feedback slightly degrades both. The paper argues that this replaces wire-load-model estimation with real physical-implementation data, bridging the traditional synthesis-to-layout correlation gap.

What carries the argument

The load-bearing mechanism is the Model Context Protocol (MCP) itself, a standardized client–server protocol for AI-tool communication, combined with a three-phase closed loop. MCP reduces integration from M×N custom connectors to M+N standardized connections and keeps stateful sessions, which is what lets the LLM orchestrate Yosys, Icarus Verilog, OpenLane, GTKWave, and KLayout as one workflow and remember prior optimization attempts. On top of that protocol, the backend-aware loop is the argument's engine: Phase I establishes baselines from OpenLane's nine fixed synthesis options; Phase II has the LLM analyze those real post-layout metrics and propose refined Yosys/ABC TCL scripts; Phase III reruns the backend flow and feeds new metrics back until convergence in three to five iterations, with retrieval-augmented access to the ABC and Yosys manuals grounding the LLM's suggestions.

What would settle it

Run the optimization with the feedback loop ablated but with the same number of full synthesis-and-route evaluations: for example, let the LLM generate its scripts once from baseline metrics and stop, or replace the LLM with the best-of-N random TCL scripts at equal compute budget. If either non-feedback or non-LLM search reproduces the 0.94 delay and 0.91 area ratios, the paper's causal claim for backend-aware closed-loop optimization is not supported.

Watch

Extended reading notes

Core claim

MCP4EDA's central claim is that the reason LLM-driven synthesis optimization fails in prior template-based integrations is that the LLM never sees what actually happened after place-and-route, so it tunes blind. The paper's solution is a three-phase loop: execute OpenLane's fixed synthesis options to establish backend baselines; have the LLM analyze the post-layout metrics, aided by retrieval over the ABC and Yosys manuals; then run refined TCL scripts through the full backend flow, updating the baseline on each improvement until the design objectives are met. Because every script evaluation is scored by real timing, area, power, and violation figures from OpenLane, the synthesis parameters are chosen against ground-truth physical results rather than wire-load-model estimates. On nine OpenCores designs in the SkyWater Sky130 PDK, the paper reports geometric-mean improvements of 6% in delay and 9% in area over the best of OpenLane's nine fixed synthesis options, and it attributes those gains specifically to the backend-aware feedback rather than to the LLM's script-generation skill alone.

Load-bearing premise

The central claim depends on the assumption that the timing and area gains come from the LLM reasoning over post-layout feedback, not from searching several synthesis configurations and keeping the best, since the baseline is the best of nine fixed scripts and the method's third phase iterates until the objectives are satisfied.

Editorial extensions

If this is right

  • Designers can run the complete open-source chip-design flow conversationally, with the LLM choosing tools, execution order, and synthesis options based on intermediate results.
  • Synthesis tuning is guided by real placement-and-routing outcomes instead of wire-load-model estimates, which is where the reported 6% delay and 9% area improvements come from.
  • The experiment shows a fixed-API LLM template degrades delay by 4% and area by 1% relative to the baseline, indicating that closed-loop feedback, not mere LLM script generation, is what improves results.
  • Adding a new tool to the flow requires one MCP connection per tool rather than bespoke integration with every LLM client, making the flow extensible in principle.
  • Each optimization iteration costs one full synthesis-and-route run plus LLM inference (about one to three minutes for small-to-medium designs, roughly seven minutes of inference overhead), and convergence happens in three to five iterations, so the overhead is bounded but non-negligible.

Reading between the lines

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

  • Beyond the paper, the abstract's headline figures (15-30% timing closure improvement, 10-20% area reduction) are larger than Table I's geomean ratios of 0.94 for delay and 0.91 for area; the table's numbers are the defensible ones.
  • Beyond the paper, a fair attribution test would run a non-LLM search (random or evolutionary) over the same synthesis-TCL space with the same number of full OpenLane evaluations; if it matches the LLM loop, the gains are from search effort rather than backend-aware reasoning.
  • Beyond the paper, the same closed-loop pattern, feeding post-layout or post-deployment measurements back into generation, could transfer to other engineering automation settings, such as FPGA place-and-route or high-level synthesis scheduling, and to power optimization once dynamic and leakage power metrics are added to the loop.
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 presents MCP4EDA, a Model Context Protocol (MCP) server that lets LLM-based assistants such as Claude Desktop and Cursor drive an open-source RTL-to-GDSII flow through Yosys, Icarus Verilog, OpenLane, GTKWave, and KLayout. The main technical claim is a backend-aware synthesis optimization loop in which the LLM analyzes post-layout timing and area results from OpenLane and iteratively refines Yosys/ABC TCL scripts. The authors report experiments on nine (listed as ten) open-source designs in Sky130, comparing OpenLane's default synthesis options, a fixed-API LLM template, and the MCP4EDA three-phase workflow. The paper's own Table I shows geomean ratios of 0.94 for delay and 0.91 for area against the baseline, while the abstract claims 15-30% timing improvements and 10-20% area reduction.

Significance. If the backend-aware mechanism were properly isolated, MCP4EDA would be a useful and timely contribution: it is, to the authors' knowledge, the first open-source MCP server that connects general-purpose LLMs to a complete open-source RTL-to-GDSII toolchain, and the dynamic tool-selection architecture is a credible step beyond fixed API-call templates. The paper also provides a concrete empirical comparison rather than a purely architectural proposal, and the authors candidly state several limitations in Section V, including unmeasured power metrics and convergence in three to five iterations. However, the current evaluation does not establish the central causal claim that backend-aware feedback from post-layout metrics causes the observed PPA gains, and the headline quantitative claims are internally inconsistent with the reported table. The strengths are architectural; the empirical evidence needs substantial rework before the paper's main claims can be accepted.

major comments (4)
  1. [Abstract, Section I, and Table I] The abstract's headline claim of '15-30% improvements in timing closure and 10-20% area reduction' is not supported by the paper's own data: Table I reports a geomean delay ratio of 0.94 (6% improvement) and a geomean area ratio of 0.91 (9% reduction) for MCP4EDA versus baseline. Section I, contribution 4, gives a different range ('1-30% critical path improvements and 5-30% area reduction'). The authors should either report the measured geomeans as the central quantitative result or provide an explicit, apples-to-apples explanation of which comparison supports the abstract's ranges; as written, the abstract materially overstates the empirical outcome.
  2. [Section IV-A and Section III-B3] The evaluation does not isolate the claimed backend-aware feedback mechanism. The baseline is the best of nine fixed OpenLane synthesis options, each run once, while MCP4EDA iteratively generates and executes an unstated number of LLM-produced TCL scripts in Phases II-III (Section III-B3) and keeps any script that improves, with Section V reporting convergence in three to five iterations. This makes the MCP4EDA result effectively best-of-(9+N) over stochastic proposals versus best-of-9 for the baseline, so the 6% delay and 9% area geomean gains could plausibly come from increased search effort or lucky draws rather than from backend-aware reasoning. The fixed-API row in Table I is a single non-iterative script and therefore does not control for iteration count or search budget. An ablation that equalizes the number of candidate scripts (e.g., evaluating N backend-blind LLM proposals with the same budget) and reports per-design N would be needed to support the causal claim.
  3. [Table I and Section IV-A] Table I contains a duplicated 'gcd' row with inconsistent baseline values (2.29 ns / 5074.87 µm² versus 1.59 ns / 5042.34 µm²), and the table lists ten rows while Section IV-A states the benchmark suite consists of nine distinct designs. This inconsistency directly affects the reported geomeans and the soundness of the comparison; the authors must clarify which row is the correct GCD result, remove the duplicate, and recompute all aggregate statistics.
  4. [Section IV-A and Table I] No repeated runs, seeds, or variance information are reported for any condition, even though all MCP4EDA results depend on stochastic LLM calls. With the headline improvements being modest (6% delay, 9% area), run-to-run variability could be of comparable magnitude, so the single-table numbers do not establish that the observed differences are statistically meaningful. The authors should report multiple independent runs (or at least seed counts) and confidence intervals for all three conditions.
minor comments (5)
  1. [Abstract and Figure 1] The abstract contains the typo 'avaiable' and Figure 1's caption contains 'OpenlLane'; both should be corrected.
  2. [References] References [17] and [18] are the same paper, and reference [22] cites 'Various Authors' with a generic ScienceDirect URL; these should be replaced with proper scholarly references.
  3. [Section IV-B and Figure 5] The runtime plot does not include baseline total execution times, so the statement that overhead remains 'tractable' is not quantified relative to the default flow; please add baseline wall-clock times and per-design iteration counts.
  4. [Section IV-A] The fixed-API condition is described only as using 'Claude 4 Sonnet' with existing physical metrics; the prompt template, number of LLM calls, and selection rule should be reported to make this control reproducible.
  5. [Availability] The code link is a bare URL without a version or archive identifier; providing a permanent artifact (e.g., a DOI or repository snapshot) would improve reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports empirical benchmarks against external OpenLane defaults; no fitted parameter is renamed as a prediction and no load-bearing self-citation chain appears.

full rationale

The paper's central claims are empirical, not derivational. MCP4EDA is evaluated by executing synthesis and place-and-route flows on nine open-source designs and comparing timing and area against OpenLane's default synthesis options. The reported geomean ratios (delay 0.94, area 0.91) come from measured tool outputs, not from a model whose parameters were fit to those outputs. The LLM's RAG sources are Yosys/ABC manuals, which is a knowledge source, not a circular dependence on the target result. The authors' self-citations (e.g., VeriReason, SymRTLO) are background references and are not load-bearing for the RTL-to-GDSII automation claim. The main interpretive risk is that the iterative best-of-K protocol may conflate backend-aware feedback with unequal search effort against a best-of-9 baseline; that is a threat to causal attribution and statistical validity, not circularity under the definitions used here. Therefore the appropriate circularity score is 0.

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

The paper introduces no new physical entities or fitted constants. Its empirical protocol relies on tool accuracy, benchmark representativeness, LLM reliability, and a fair comparison baseline, all of which are domain assumptions rather than demonstrated facts.

assumptions (4)
  • domain assumption OpenLane, Yosys, and ABC report accurate post-layout metrics that can serve as ground truth for synthesis tuning.
    Section III-B5 treats extracted WNS, TNS, area, and power as ground-truth implementation characteristics; no validation against silicon or an independent extractor is provided.
  • domain assumption The nine hand-selected OpenCores designs are representative of small-to-medium digital designs.
    Section IV-A defines the benchmark suite without inclusion criteria, so generalization beyond these designs is an assumption.
  • domain assumption LLM-generated TCL scripts execute correctly and the LLM's iterative choices are stable enough for comparison.
    Sections III-B2 and III-B3 describe the LLM writing and refining scripts, but no repeated runs, temperature controls, or parse-error rates are reported.
  • domain assumption The fixed API template baseline is a fair representation of prior LLM-EDA integration approaches.
    Section IV-A defines it as Claude 4 Sonnet with physical metrics but without feedback; the paper does not show how this maps to ChatEDA, ChipGPT, or Chip-Chat.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization." pith.science (2026). https://pith.science/paper/CKQO3OGF

@misc{pith2026250719570,
  author       = {Pith},
  title        = {Pith review of: MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CKQO3OGF}},
  note         = {Machine review of arXiv:2507.19570}
}
read the original abstract

This paper presents MCP4EDA, the first Model Context Protocol server that enables Large Language Models (LLMs) to control and optimize the complete open-source RTL-to-GDSII design flow through natural language interaction. The system integrates Yosys synthesis, Icarus Verilog simulation, OpenLane place-and-route, GTKWave analysis, and KLayout visualization into a unified LLM-accessible interface, enabling designers to execute complex multi-tool EDA workflows conversationally via AI assistants such as Claude Desktop and Cursor IDE. The principal contribution is a backend-aware synthesis optimization methodology wherein LLMs analyze actual post-layout timing, power, and area metrics from OpenLane results to iteratively refine synthesis TCL scripts, establishing a closed-loop optimization system that bridges the traditional gap between synthesis estimates and physical implementation reality. In contrast to conventional flows that rely on wire-load models, this methodology leverages real backend performance data to guide synthesis parameter tuning, optimization sequence selection, and constraint refinement, with the LLM functioning as an intelligent design space exploration agent. Experimental evaluation on representative digital designs demonstrates 15-30% improvements in timing closure and 10-20% area reduction compared to default synthesis flows, establishing MCP4EDA as the first practical LLM-controlled end-to-end open-source EDA automation system. The code and demo are avaiable at: http://www.agent4eda.com/

Figures

Figures reproduced from arXiv: 2507.19570 by the authors.

Figure 2
Figure 2. Backend-aware TCL optimization workflow showing [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 1
Figure 1. MCP4EDA workflow architecture integrating Model Context Protocol components with EDA tools for backend￾aware synthesis optimization. The MCP Host (Claude Desk￾top/Cursor IDE) provides natural language interface. Multiple MCP Clients manage individual tool connections with stateful sessions. The MCP Server orchestrates tool execution across three domains: Simulation (Icarus Verilog, GTKWave), Synthe￾sis (TCL generati… view at source ↗
Figure 3
Figure 3. Example LLM-Guided Synthesis Optimization with [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Time vs Area (left) and APU Best Overall Optimization (right) [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Design Runtime Evaluation user requirements and achieved physical metrics validates MCP4EDA’s effectiveness. V. LIMITATIONS While MCP4EDA has demonstrated promising timing and area improvements on nine open-source benchmarks under the SkyWater Sky130 PDK, its scope rem…

Discussion (0). Sign in to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. CHIA: An open-source framework for principled, agentic AI-driven hardware/software co-design research

    cs.AR 2026-06 unverdicted novelty 7.0 of 10

    CHIA is an open-source framework for agentic AI-driven hardware/software co-design using CHIA loops as directed cyclic graphs, a tool library, and features for reliable experimentation, shown via five case studies.

  2. Bridging the Last Mile of Circuit Design: PostEDA-Bench, a Hierarchical Benchmark for PPA Convergence and DRC Fixing

    cs.AR 2026-05 unverdicted novelty 7.0 of 10

    PostEDA-Bench shows LLM agents succeed reasonably on basic DRC and single-objective PPA tasks but struggle on practical DRC reasoning (best 36.66% success) and multi-objective PPA (best 20% success).

  3. PICopilot: An LLM-based Agentic Framework for Assisting Photonic Integrated Circuit Design via Script Generation

    cs.ET 2026-08 conditional novelty 6.0 of 10

    A training-free multi-agent LLM framework with summary-based hybrid retrieval generates correct PIC design tool scripts from natural language, passing all 48 self-built benchmark tasks where the best baseline passes 27.

Reference graph

Works this paper leans on

31 extracted references · 22 canonical work pages · cited by 3 Pith papers

  1. [1]

    Flowtune: End-to-end automatic logic optimization exploration via domain-specific multi-armed bandit,

    W. L. Neto, Y . Li, P.-E. Gaillardon, and C. Yu, “Flowtune: End-to-end automatic logic optimization exploration via domain-specific multi-armed bandit,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (TCAD) , 2022

    work page 2022

  2. [2]

    Optimization of physically-aware synthesis for digital implementation flow,

    S. Kumar, A. Sharma, and R. Patel, “Optimization of physically-aware synthesis for digital implementation flow,” International Journal of Engineering and Technology, vol. 7, no. 2.8, pp. 453–458, 2018

    work page 2018

  3. [3]

    Rtlcoder: 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, “Rtlcoder: Fully open-source and efficient llm-assisted rtl code generation technique,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems , 2024

    work page 2024

  4. [4]

    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,” CoRR, vol. abs/2305.14019, 2023

    arXiv 2023

  5. [5]

    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,” in 5th ACM/IEEE Workshop on Machine Learning for CAD, MLCAD . IEEE, 2023

    work page 2023

  6. [6]

    Llm4eda: Emerging progress in large language models for electronic design automation,

    R. Zhong, X. Du, S. Kai, Z. Tang, S. Xu, H.-L. Zhen, J. Hao, Q. Xu, M. Yuan, and J. Yan, “Llm4eda: Emerging progress in large language models for electronic design automation,” arXiv preprint arXiv:2401.12224, 2024

    arXiv 2024

  7. [7]

    Verilogeval: Evaluating large language models for verilog code generation,

    S. Liu, N. Pinckney, B. Khailany, and H. Ren, “Verilogeval: Evaluating large language models for verilog code generation,” in Proc. IEEE/ACM International Conference on Computer-Aided Design (ICCAD) , 2023

    work page 2023

  8. [8]

    Verireason: Reinforcement learning with testbench feedback for reasoning-enhanced verilog generation,

    Y . Wang, G. Sun, W. Ye, G. Qu, and A. Li, “Verireason: Reinforcement learning with testbench feedback for reasoning-enhanced verilog generation,” 2025. [Online]. Available: https://arxiv.org/abs/2505.11849

    arXiv 2025

Show all 31 references
  1. [9]

    Rtlfixer: Automatically fixing RTL syntax errors with large language model,

    Y . Tsai, M. Liu, and H. Ren, “Rtlfixer: Automatically fixing RTL syntax errors with large language model,” in Proceedings of the 61st ACM/IEEE Design Automation Conference, DAC . ACM, 2024

    2024

  2. [10]

    Rtlrewriter: Methodologies for large models aided rtl code optimization,

    X. Yao, Y . Wang, X. Li, Y . Lian, C. Ran, L. Chen, M. Yuan, H. Xu, and B. Yu, “Rtlrewriter: Methodologies for large models aided rtl code optimization,” 09 2024

    2024

  3. [11]

    Symrtlo: Enhancing rtl code optimization with llms and neuron-inspired symbolic reasoning,

    Y . Wang, W. Ye, P. Guo, Y . He, Z. Wang, Y . He, B. Tian, S. He, G. Sun, Z. Shen, S. Chen, A. Srivastava, Q. Zhang, G. Qu, and A. Li, “Symrtlo: Enhancing rtl code optimization with llms and neuron-inspired symbolic reasoning,” 2025. [Online]. Available: https://arxiv.org/abs/...

    2025

  4. [12]

    Chipnemo: Domain- adapted llms for chip design,

    M. Liu, N. Pinckney, B. Khailany, and H. Ren, “Chipnemo: Domain- adapted llms for chip design,” arXiv preprint arXiv:2311.00176 , 2023

    2023 arXiv

  5. [13]

    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 , 2024

    2024 arXiv

  6. [14]

    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,” in 2023 ACM/IEEE 5th Workshop on Machine Learning for CAD (MLCAD) , 2023

    2023

  7. [15]

    Openroad: Toward a self-driving, open-source digital layout implementation tool chain,

    T. Ajayi, D. Blaauw, T. Chan, C.-K. Cheng, V . A. Chhabria, D. K. Choo, M. Coltella, S. Dobre, R. Dreslinski, M. Fogaça, S. Hashemi, A. Hosny, A. B. Kahng, M. Kim, J. Li, Z. Liang, U. Mallappa, P. Penzes, G. Pradipta, S. Reda, A. Samal, S. S. Sapatnekar, C. Sechen, V . Sriniva...

    2019

  8. [16]

    Building openlane: A 130nm openroad-based tapeout- proven flow : Invited paper,

    M. Shalan and T. Edwards, “Building openlane: A 130nm openroad-based tapeout- proven flow : Invited paper,” in 2020 IEEE/ACM International Conference On Computer Aided Design (ICCAD) , 2020, pp. 1–6

    2020

  9. [17]

    Optimization of physically-aware synthesis for digital implementation flow,

    L. E. Geralla, M. J. de Guzman, and J. A. Hora, “Optimization of physically-aware synthesis for digital implementation flow,” International Journal of Engineering and Technology, vol. 7, no. 2.11, pp. 31–34, 2018

    2018

  10. [18]

    Optimization of physically-aware synthesis for digital implemen- tation flow,

    ——, “Optimization of physically-aware synthesis for digital implemen- tation flow,” International Journal of Engineering and Technology, vol. 7, no. 2.11, pp. 31–34, 2018

    2018

  11. [19]

    Physically aware synthesis revisited: Guiding technology mapping with primitive logic gate placement,

    Y . Zhang, K. Liu, and J. Chen, “Physically aware synthesis revisited: Guiding technology mapping with primitive logic gate placement,” arXiv preprint arXiv:2408.07886, 2025

    2025 arXiv

  12. [20]

    High-level synthesis design space explo- ration: Past, present, and future,

    B. C. Schafer and Z. Wang, “High-level synthesis design space explo- ration: Past, present, and future,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 10, pp. 2628–2639, 2019

    2019

  13. [21]

    Efficient system design space exploration using machine learning techniques,

    J. Yi, D. Lilja, and D. Hawkins, “Efficient system design space exploration using machine learning techniques,” in Proc. 45th Annual Design Automation Conference (DAC), 2008

    2008

  14. [22]

    Design-space exploration - an overview,

    Various Authors, “Design-space exploration - an overview,” ScienceDirect Topics, 2019

    2019

  15. [23]

    A survey of research in large language models for electronic design automation,

    J. Pan, G. Zhou, C.-C. Chang, I. Jacobson, J. Hu, and Y . Chen, “A survey of research in large language models for electronic design automation,” ACM Trans. Des. Autom. Electron. Syst. , vol. 30, no. 3, Feb. 2025. [Online]. Available: https://doi.org/10.1145/3715324

    2025 doi

  16. [24]

    Verigen: A large language model for verilog code generation,

    S. Thakur, B. Ahmad, H. Pearce, B. Tan, B. Dolan-Gavitt, R. Karri, and H. Pearce, “Verigen: A large language model for verilog code generation,” ACM Transactions on Design Automation of Electronic Systems , vol. 29, no. 2, pp. 1–31, 2023

    2023

  17. [25]

    Benchmarking large language models for automated verilog rtl code generation,

    S. Thakur, B. Ahmad, Z. Fan, H. Pearce, B. Tan, R. Karri, B. Dolan-Gavitt, and S. Garg, “Benchmarking large language models for automated verilog rtl code generation,” 2022. [Online]. Available: https://arxiv.org/abs/2212.11140

    2022 arXiv

  18. [26]

    Model context protocol specification,

    Anthropic, “Model context protocol specification,” Anthropic, Tech. Rep., March 2025

    2025

  19. [27]

    Model context protocol (mcp): Landscape, security threats, and future research directions,

    X. Hou, Y . Chen, Z. Wang, and L. Liu, “Model context protocol (mcp): Landscape, security threats, and future research directions,” arXiv preprint arXiv:2503.23278, 2025

    2025 arXiv

  20. [28]

    Yosys-a free verilog synthesis suite,

    C. Wolf, J. Glaser, and J. Kepler, “Yosys-a free verilog synthesis suite,” in Proceedings of the Forum on Specification and Design Languages (FDL), 2013, yosys is the first open-source Verilog synthesis suite supporting a wide range of synthesizable Verilog features. [Online]....

    2013

  21. [29]

    ABC: An academic industrial-strength verification tool,

    R. Brayton and A. Mishchenko, “ABC: An academic industrial-strength verification tool,” in Computer Aided Verification: 22nd International Conference, CAV 2010, Edinburgh, UK, July 15–19, 2010. Proceedings

    2010

  22. [30]

    Springer, 2010, pp. 24–40

    2010

  23. [31]

    OpenCores,

    “OpenCores,” https://opencores.org/

Pith tools

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