← Happy Beginner · AgenticEDA Survey
2026 · Survey · arXiv

Agentic Electronic Design Automation: A Handoff Perspective

A survey of 115 LLM-based agent systems across the EDA flow, organized around producer-to-consumer handoffs — the objects they transfer, the acceptance evidence each downstream stage requires, and the missing shared infrastructure for trustworthy agentic EDA.

Abstract

Electronic design automation (EDA) is multi-stage and handoff-heavy, relying on transfers among humans, design artifacts, and multiple tools. LLM-based agents now participate in these transfers, yet the resulting research landscape is highly fragmented and lacks a unified perspective.

This survey adopts the primary input–output pair as its organizing lens: for each agent system, we analyze its primary, supporting, and intermediate handoff objects and classify it according to the provenance of its primary input and the consumer boundary of its primary output. Intra-stage systems operate on objects within a single EDA stage, inter-stage systems transform EDA-native artifacts into forms usable by downstream stages, and extra-stage systems translate human intent into EDA artifacts.

Based on this taxonomy, we survey 115 representative systems and examine them along multiple dimensions, including research trends, benchmarks, and model mechanisms. Finally, we outline an agentic EDA protocol roadmap and discuss open problems for future research.

Key distinction. Producer-side success alone does not establish consumer acceptance. A handoff is valid only when the transferred object satisfies the interface, semantic, configuration, and version requirements of its next consumer — and carries enough context, evidence, and provenance for downstream use.

Overview

Consumer acceptance of a stage-local logic-optimization handoff. The primary, supporting, intermediate, and metadata objects are transferred together, and the downstream consumer accepts or rejects them under equivalence, version, constraint, and metadata checks.
Click the figure to view full screen.

Core distinction. Agentic EDA systems differ in where their primary input originates and where their primary output is consumed. Two properties determine the class:

  • Input provenance — is the primary input a machine-readable EDA-domain object, or human-originated intent and knowledge?
  • Consumer boundary — is the primary output checked and reused within the same stage, or accepted across a representation boundary by a downstream stage?

The complete set of handoff objects is written as ℛ = (Ip, Op, Is, Os, Am; M): primary input/output, supporting inputs/outputs, intermediate artifacts, and metadata.

Taxonomy

The three-class taxonomy follows directly from the primary input–output pair. Supporting objects, intermediate artifacts, metadata, model architecture, mechanisms, and benchmarks remain descriptive dimensions and do not determine the primary class.

Intra-stage36 systems

  • Consumes a machine-readable EDA-domain object (design artifact, EDA-tool code, or measurements).
  • Output is checked and reused within the same stage — compilation, simulation, equivalence, PPA, lint/DRC, or coverage.
  • e.g., RTLFixer, ADO-LLM, MappingEvolve, ModelGen.

Inter-stage16 systems

  • Consumes an EDA-native representation and produces a different design-stage representation.
  • Acceptance relies on cross-tool execution, downstream validation, QoR, or checkpoint coherence across the boundary.
  • e.g., HLSPilot, HyperPlace, PCBAgent, ChatEDA.

Extra-stage63 systems

  • Begins from human-originated text, queries, or documents and produces a machine-consumable EDA artifact.
  • Acceptance depends on specification completeness, provenance, and attribution to inspectable sources.
  • e.g., VerilogCoder, AssertLLM, ChatLS.
Three-class taxonomy of agentic EDA systems, distinguished by the primary input–output pair: same-stage refinement, cross-stage representation change, and translation of human intent into an EDA artifact.
Click the figure to view full screen.

Quick start: representative systems

These are not the only important systems in the survey. They are a first reading path across the three classes — one canonical example of each primary input–output setting — before diving into the full library.

RTLFixer
2024 · Intra-stage · RTL→RTL

A canonical compile–repair loop: an LLM fixes RTL syntax errors and re-iterates against Icarus Verilog / Quartus feedback.

Code →
ADO-LLM
2024 · Intra-stage · Netlist→Netlist

Analog sizing via Bayesian optimization with in-context learning, gated by simulation and fitting error within the same stage.

MappingEvolve
2026 · Intra-stage · EDA-tool code

LLM-driven evolution of technology-mapping tool code, with each edit accepted by a stage-local optimizer.

Code →
ChatEDA
2024 · Inter-stage · RTL→GDSII

Autonomous orchestration from RTL to implemented layout, coordinating netlist synthesis, placement, and routing scripts.

Code →
HLSPilot
2024 · Inter-stage · C/C++→RTL

LLM-based high-level synthesis that crosses the software-to-hardware representation boundary.

PCBAgent
2025 · Inter-stage · Netlist→Layout

Agent-based high-density PCB placement, producing a layout that downstream routing tools must accept.

VerilogCoder
2025 · Extra-stage · NL→RTL

Autonomous Verilog coding agents with graph-based planning and AST-based waveform tracing from natural-language specs.

Code →
AssertLLM
2025 · Extra-stage · NL→Verification Collateral

Generates hardware verification assertions from design specifications — human intent translated into machine-checkable collateral.

ChatLS
2025 · Extra-stage · NL→EDA script

Multimodal retrieval-augmented logic-synthesis script customization, grounded in tool manuals.

Curated system library

All 115 surveyed systems, grouped by handoff class and primary input–output pair. The Primary I/O column reports Ip → Op. Filter by class, recency, or code availability, or search by name, title, venue, or task family.

0 shown
Scope. The corpus covers work published, accepted, or publicly available by the August 31, 2026 cutoff. Systems that instantiate a second class carry a secondary label; each is listed once under its primary class here.

How to read this survey

If you are new to the area Start with the overview and taxonomy, then read one representative system from each class in the quick-start section. After that, use the library to go deeper into whichever primary input–output setting matches your interest — RTL repair, verification collateral, HLS, layout, or natural-language specification.
If you are using the page as a reference Jump directly to the library tables. The search bar works best for names, titles, and venues, while the filter buttons separate the three classes, recent (2025+) systems, and those with public code. The roadmap section maps the open questions to the five-layer protocol agenda.

Agentic EDA Protocol Roadmap

General-purpose agent protocols separate discovery, messaging, tool access, workflow description, and identity — but they do not record the EDA-specific object roles, acceptance evidence, configuration fingerprints, dependencies, and PDK/IP policies the surveyed workflows require. The roadmap organizes these missing semantics into five layers, each pairing a recurring coordination gap with a required capability and a validation milestone.

Overview of the five-layer Agentic EDA Protocol Roadmap.
Click the figure to view full screen.
L1 Agent discovery

A versioned capability manifest and registry that encodes process node, PDK, library, and tool assumptions, rejecting incompatible agents with explainable verdicts.

L2 Agent messaging

A shared, versioned handoff message that distinguishes primary and supporting objects from candidates and workflow state, and identifies the evidence used to accept the primary output.

L3 Tool invocation

A typed operation descriptor with backend-specific adapters returning checker results and QoR with comparable units, artifact references, and error categories across tool versions.

L4 Workflow orchestration

A workflow representation in which each edge identifies its producer, consumer, objects, accepted configuration, and dependencies, with recorded evidence gating every transition.

L5 Security & IP

Authorization, disclosure, retention, and audit semantics that determine whether a handoff is authorized, appropriately disclosed, protected, and admissible for organizational reuse.

Community & feedback

💬 Join the conversation This survey is under review. Questions, corrections, and missing-system suggestions are welcome — especially pointers to agentic EDA systems we may have missed, and public benchmarks or code releases we should catalog.
🧭 Help improve the map If your system or a system you know belongs in the library, or a handoff-object role is mislabeled, please open an issue or reach out. We aim to keep the taxonomy, object-role inventories, and benchmark catalog current.

Authors

Jiawei LiuThe Chinese University of Hong Kong
Peiyi HanThe Chinese University of Hong Kong
Yuntao LuThe Chinese University of Hong Kong
Su ZhengThe Chinese University of Hong Kong
Fengyu YanPrimarius Technologies
Bei YuThe Chinese University of Hong Kong
Contact
Jiawei Liu · The Chinese University of Hong Kong
liujw@cse.cuhk.edu.hk

Citation

Please cite this survey as follows.

@article{liu2026agenticeda,
  title={Agentic Electronic Design Automation: A Handoff Perspective},
  author={Liu, Jiawei and Han, Peiyi and Lu, Yuntao and Zheng, Su and Yan, Fengyu and Yu, Bei},
  year={2026},
  eprint={2606.19795},
  archivePrefix={arXiv},
  primaryClass={cs.SE},
  url={https://arxiv.org/abs/2606.19795},
}