arXiv CSopen access

Agentic Electronic Design Automation: A Handoff Perspective

arXiv:2606.19795v1 [cs.SE] 18 Jun 2026

Agentic Electronic Design Automation: A Handoff Perspective JIAWEI LIU, The Chinese University of Hong Kong PEIYI HAN, The Chinese University of Hong Kong YUNTAO LU, The Chinese University of Hong Kong SU ZHENG, The Chinese University of Hong Kong FENGYU YAN, Primarius Technologies BEI YU, The Chinese University of Hong Kong Electronic design automation (EDA) is inherently multi-stage and handoff-heavy. Design artifacts, flow scripts, and engineering decisions cross tool, session, and organizational boundaries before final implementation, signoff, or release. Each transfer carries explicit and implicit requirements that may not be fully captured by stage-local checks. LLM-based agents now invoke EDA tools directly, embed retrieved knowledge in executable scripts, and hand off state across sessions and stages. Once their outputs condition downstream engineering decisions, the transferred object must satisfy a handoff contract and meet the assumptions of its next consumer. This survey introduces handoff validity as its organizing principle. A handoff is valid when the transferred object satisfies the consumer’s acceptance conditions and carries sufficient context, evidence, and provenance for downstream use. We review 82 systems and classify them into three boundary classes. Stage-Bound systems establish validity within a single EDA stage or bounded verification task. Flow-Bound systems preserve coherent workflow state across tools, invocations, and sessions. Organization-Bound systems maintain source grounding, provenance, scope, and admissibility across knowledge and authority boundaries. For each class, we analyze handoff contracts, handoff objects, coordination mechanisms, and open questions. These analyses motivate a five-layer EDA agent communication protocol (EACP), covering the agent discovery, agent message, tool invocation, workflow orchestration, and security and IP protocols. We aim to provide a common vocabulary and research agenda for trustworthy agentic EDA. CCS Concepts: • Hardware → Electronic design automation; • Computing methodologies → Machine learning. Additional Key Words and Phrases: electronic design automation, LLM-based agents ACM Reference Format: Jiawei Liu, Peiyi Han, Yuntao Lu, Su Zheng, Fengyu Yan, and Bei Yu. 2026. Agentic Electronic Design Automation: A Handoff Perspective. 1, 1 (June 2026), 31 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

1 1.1

INTRODUCTION EDA Workflows Are Handoff-Heavy

Electronic design automation (EDA) is an inherently multi-stage, handoff-heavy process. Design and verification artifacts, such as register-transfer level (RTL) code, netlists, layouts, simulation traces, and signoff reports, can serve as handoff objects, produced in one tool context and consumed Authors’ addresses: Jiawei Liu, The Chinese University of Hong Kong; Peiyi Han, The Chinese University of Hong Kong; Yuntao Lu, The Chinese University of Hong Kong; Su Zheng, The Chinese University of Hong Kong; Fengyu Yan, Primarius Technologies; Bei Yu, The Chinese University of Hong Kong. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. © 2026 Association for Computing Machinery. XXXX-XXXX/2026/6-ART $15.00 https://doi.org/10.1145/nnnnnnn.nnnnnnn 1

in one or more downstream contexts. Digital designs progress through synthesis, placement, routing, and iterative timing closure [1, 2]. Analog designs are evaluated through schematic-level and post-layout circuit simulation, while their physical layouts are checked using design rule checking (DRC) and layout-versus-schematic (LVS) verification. This dependency extends beyond primary design artifacts. In agent-driven flows, scripts, configuration files, constraints, logs, and intermediate results must remain mutually consistent across tool invocations [3, 4]. Similarly, organizational knowledge, methodology documents, and tool guidance must remain retrievable and interpretable when accessed by engineers in different teams or contexts [5]. For instance, a place-and-route stage consumes not only a synthesized netlist and the applicable Synopsys Design Constraints (SDC) set, but also compatible technology and library data. The RTL and SDC are distinct handoff objects. Synthesis interprets and optimizes the RTL under the supplied constraints, while downstream physical-design and timing-analysis stages must continue to receive the applicable constraint set. Although the generated gate-level netlist reflects optimization decisions made under those constraints, it does not encode their complete semantics. A stale SDC file, an incompatible library version, or an incomplete checkpoint package can therefore cause execution failures, timing violations, or non-reproducible results. Reliable downstream execution therefore requires a coherent and version-compatible handoff package, because missing context may not be reliably reconstructed without rerunning upstream stages or consulting external records. Traditional machine learning for EDA (ML4EDA) has improved the quality and efficiency of individual design tasks, including placement [1], timing prediction and optimization [2], and HLS directive search [6]. These methods can be embedded directly into EDA flows, and their outputs may be consumed by downstream tools. However, they typically operate under predefined task interfaces, data schemas, technology settings, and optimization objectives. The conditions under which an output remains reusable after a change in the PDK, tool version, or design specification are often implicit in the experimental setup rather than represented as explicit, machine-checkable handoff contracts. Likewise, the provenance and generation context needed for downstream reuse are rarely treated as first-class outputs. Recent large language models (LLMs) provide instruction-conditioned generation, in-context adaptation, and the ability to integrate heterogeneous information from specifications, code, logs, and tool feedback [7, 8]. When embedded in agentic workflows, these capabilities support iterative planning and tool interaction, often without task-specific retraining. Nevertheless, not every LLM application creates the same handoff burden. A standalone conversational system that neither invokes tools nor maintains workflow state may create no cross-tool or cross-session state handoff. Such answers become knowledge handoffs when they are used to inform downstream engineering decisions, in which case their source grounding, provenance, and scope of applicability must remain explicit. By contrast, LLMs embedded in agentic workflows can participate directly in the design process. They may invoke EDA tools and act on their feedback, translate retrieved knowledge into executable actions or scripts, and maintain state across agents, tools, and design stages. Such participation creates explicit handoff requirements. A transferred object must satisfy the acceptance conditions of its downstream consumer and carry sufficient context, evidence, and provenance for reuse without requiring the consumer to reconstruct hidden assumptions or missing context. We call this property handoff validity. Existing systems iteratively generate and repair hardware descriptions [9, 10], automate and optimize multi-stage EDA flows [3, 4], coordinate specialized agents for RTL generation and CPU design and verification [11, 12], customize synthesis scripts using retrieved design knowledge [13], and answer grounded design queries over technical documentation [5]. Major EDA vendors have also begun introducing agentic capabilities into commercial design workflows, as summarized in Table 1. In this survey, agentic EDA refers to LLM-based systems 2

Table 1. Publicly announced agentic EDA offerings summarized from vendor press releases and product briefs. Included for industry context only, not as taxonomic evidence or for cross-vendor comparison. Vendor

Offering and stated scope

Synopsys

The Synopsys agentic AI stack [14] provides the infrastructure for agentic engineering workflows. AgentEngineer [15] supports agents that reason, plan, learn, execute, and coordinate across engineering tasks. A disclosed AgentEngineer workflow generates RTL from natural-language and formal specifications, runs lint checks, generates unitlevel testbenches, and iteratively invokes EDA verification tools. ChipStack AI Super Agent [16] and AgentStack [17]: ChipStack supports agentic RTL design and verification workflows, including testbench generation, regression orchestration, debugging, and automated repair. AgentStack serves as a head-agent orchestration layer extending into physical design, custom and analog design, migration, and system-level workflows. Fuse EDA AI Agent [18] and Questa One Agentic Toolkit [19]: Fuse provides multi-tool and multi-agent orchestration across semiconductor, 3D IC, PCB, verification, and manufacturing-signoff workflows. Questa One provides agentic workflows for RTL creation, lint, CDC analysis, verification planning, debugging, and RTL signoff, with integration into Fuse.

Cadence

Siemens EDA

that interact with EDA tools, coordinate agents or workflow state, or produce grounded outputs for engineering use. Their outputs are intended to support subsequent engineering actions or decisions. Among agentic EDA systems, outputs that influence downstream engineering actions or decisions must satisfy a handoff contract. A handoff contract specifies the conditions under which a transferred object can be accepted by its consumer, together with the evidence needed to establish those conditions. A stage-local checker may establish local validity, but it cannot generally verify assumptions that arise only in downstream contexts. Three system classes follow from the scope across which handoff validity must be preserved. This survey names them Stage-Bound, FlowBound, and Organization-Bound. Each name reflects the boundary crossed by the transferred object and the scope over which its validity must be established. Stage-Bound systems operate under a stage-local acceptance boundary within a single EDA stage or bounded verification task. Systems such as RTLFixer [9] and ReChisel [10] iteratively refine hardware descriptions using compiler or simulator feedback. Such checker verdicts establish local acceptance but do not, by themselves, establish downstream synthesizability, timing compliance, or integration compatibility. Flow-Bound systems preserve workflow-state coherence across tools, pipeline steps, or sessions. Systems such as ChatEDA [3] and ASIC-Agent [20] coordinate tool invocations and transfer outputs across multiple workflow steps. Their scripts, constraints, intermediate artifacts, and execution records must remain mutually consistent across sessions and changing execution environments. Organization-Bound systems operate across knowledge, team, or authority boundaries. Systems such as ChatLS [13] and Ask-EDA [5] retrieve design knowledge that informs generated scripts, commands, or engineering guidance. Such knowledge handoffs require sufficient grounding, provenance, and applicability context to remain admissible in the receiving project, tool, and organizational environment. 1.2

Limitations of Existing Surveys

Prior surveys of LLM-based EDA organize the literature by application category, input–output modality, design stage, or implementation paradigm. To our knowledge, none uses handoff validity as its primary organizing axis. 3

HANDOFF VALIDITY

HANDOFF CONTRACT Checker Result

Is this ready for the next stage?

QoR Record WNS

TNS

Area

Power

Provenance

Valid Handoff

VALID HANDOFF (GOOD CASE) RTL

.sdc

Syn

INVALID HANDOFF (BAD CASE) RTL

.sdc

Provider

COORDINATION MECHANISMS

Consumer

Syn

HANDOFF OBJECT RTL

.sdc

Report

Script/TCL

Fig. 1. Core concepts of handoff validity in agentic EDA. The left panel contrasts valid and invalid handoff packages. The right panel shows a provider transferring a package to a consumer, where handoff objects are accompanied by the contract evidence and coordination mechanisms required for downstream use.

• He et al. [21] review the evolution of LLM-based EDA from assistants to agents through representative applications, including question answering, script generation, and automated design processes. • He et al. [7] organize existing research into code generation, verification and debugging, knowledge representation and retrieval, and optimization and modeling. They additionally map these applications according to input–output modality, including code-to-code, code-to-language, language-to-code, and language-to-language transformations. • Pan et al. [8] organize LLM applications by design stage, covering system-level design, RTL design, logic synthesis and physical design, and analog circuit design. • Zang et al. [22] present a methodological taxonomy based on implementation complexity, distinguishing prompt-based reasoning, fine-tuned specialization, and multi-agent orchestration. These surveys provide valuable accounts of what LLM-based EDA systems do, where they operate in the design flow, and how they are implemented. These axes, however, are orthogonal to the boundary across which an output must remain valid. A system can be accurately characterized by its task, design stage, modality, or implementation paradigm without specifying the acceptance conditions imposed by its downstream consumer. RTLFixer [9], ChatEDA [3], and RTLExplain [23] illustrate this distinction. RTLFixer closes a stage-local repair loop using compiler feedback. ChatEDA transfers scripts, artifacts, and execution state across multiple stages of an RTL-to-GDSII flow. RTLExplain constructs project-specific knowledge bases that support RTL summarization and grounded question answering. Although existing taxonomies describe their respective tasks and implementations, a boundary-centered view 4

distinguishes their dominant validity scopes as Stage-Bound, Flow-Bound, and Organization-Bound, respectively. This distinction motivates handoff validity as the organizing principle of this survey and leads to four questions: • Q1: What conditions and evidence establish handoff validity? • Q2: What is handed off? • Q3: How is the transfer managed? • Q4: What open questions arise at the boundary? The four questions correspond to four analytical dimensions used throughout this survey. Q1 concerns handoff contracts, asking what acceptance conditions the consumer imposes and what evidence establishes their satisfaction. Q2 concerns handoff objects, asking what artifact, workflow state, knowledge, or decision is transferred. Q3 concerns coordination mechanisms, asking how the transfer is produced, communicated, validated, and maintained. Q4 concerns open questions, asking what remains unresolved in preserving handoff validity at the boundary. These dimensions are complementary: the contract specifies what must hold, the object identifies what crosses the boundary, the coordination mechanism determines how the transfer is managed, and the open questions expose limitations that existing systems have not yet resolved. 1.3

Scope and Organizing Principle

Corpus construction. We conducted a venue-focused literature search covering work published, accepted, or publicly available by the final search date of May 1, 2026. The search covered core and specialized EDA venues, including DAC, ICCAD, DATE, ASP-DAC, ICLAD, ISEDA, MLCAD, ISPD and GLSVLSI, as well as relevant publications in TODAES, TCAD, and TCAS-I. AI and machinelearning venues, including AAAI, ACL and EACL, were searched for EDA-focused contributions. Papers from adjacent hardware design, circuit, and test venues, including ATS, AICAS, ICCD, ISLPED, ITC, and VLSI-SoC, were also considered when they satisfied the inclusion criteria below. Search queries combined terms such as LLM for EDA, EDA agent, EDA flow agent, and agentic EDA. Backward and forward citation tracing was then applied to eligible seed papers to identify additional candidates published before the search cutoff. Duplicate publications describing the same system were merged unless a later version introduced a materially different architecture, workflow, or handoff mechanism. All remaining candidates were screened according to the criteria below. The final corpus contains 82 publications describing 82 distinct agentic EDA systems. Inclusion and exclusion criteria. We include an LLM-based EDA system when the LLM materially participates in producing, transferring, interpreting, or validating an object across a tool, agent, session, workflow, or authority boundary. Eligible systems must involve at least one of the following mechanisms: (a) EDA-tool interaction or workflow orchestration whose results affect a subsequent workflow step, (b) coordination and artifact transfer among multiple agents, (c) retrieval or memory that grounds a subsequent engineering action or decision, (d) preservation or transfer of workflow state across invocations or sessions, or (e) an explicitly modeled human review, signoff, or approval handoff. Mere human consumption of a generated output is not sufficient unless the review or decision boundary forms part of the system’s stated mechanism or evaluation. We exclude three categories. First, we exclude pure ML4EDA methods whose contributions do not involve any of the mechanisms (a)–(e). Second, we exclude one-shot prompting demonstrations that produce an isolated response without tool feedback, inter-agent transfer, persistent memory, workflow-state propagation, or an explicit review handoff. Third, we exclude product and vendor claims that lack sufficient public technical detail for mechanism-level classification. Vendor press materials 5

DAC ICCAD TODAES TCAD ICLAD ASP-DAC ISEDA MLCAD AAAI LAD ISPD ICCD DATE ATS Others

11 9 7 6 6 6

19.5%

5

14.6%

3

2024 (12) 2025 (54)

3

2026 (16)

2 2

65.9%

2 2 2

(b)

16

0

5

10

15

20

Number of Papers

(a) Fig. 2. Corpus statistics across the 82 surveyed papers. (a) Papers per venue (venues with only one paper grouped as “Others”); (b) Year distribution of the 82 surveyed papers.

and product briefs, including those summarized in Table 1, are used only as signals of industrial deployment and carry no evidentiary weight in constructing or validating the taxonomy. Together, these criteria identify systems whose outputs cross boundaries relevant to handoff validity. 1.4

Positioning and Contributions

Positioning. This survey organizes agentic EDA systems along a boundary-centered axis, asking where handoff validity must be preserved and where it is most difficult to establish. The boundary determines the scope over which validity must hold and the assumptions imposed by the receiving tool, stage, session, or organizational context. Viewing the corpus through this lens reveals not only how existing systems differ, but also the infrastructure capabilities they collectively lack. These gaps motivate the five-layer EDA Agent Communication Protocol (EACP), proposed as a research agenda in Section 6. Contributions. This framing leads to four contributions. First, the survey reframes agentic EDA as a problem of handoff validity rather than local task automation alone. Second, it introduces a taxonomy of three boundary classes defined by the scope across which handoff validity must be preserved. Third, the three class-specific sections apply four shared analytical dimensions, making handoff requirements explicit and systematically comparable across classes. Fourth, the survey proposes the five-layer EACP in Section 6 as a research agenda. Outline. Section 2 presents the boundary-centered taxonomy. Sections 3 to 5 apply the framework to the three boundary classes. Section 6 presents the five-layer EACP. Finally, Section 7 concludes the survey. 2

A BOUNDARY-CENTERED TAXONOMY

This section defines the boundary-centered taxonomy that organizes the survey. Section 2.1 introduces four core concepts, including handoff validity, handoff contracts, handoff objects, and coordination mechanisms. Section 2.2 uses these concepts to define three boundary classes. 6

2.1

Core Concepts

Handoff validity. Handoff validity holds when a transferred artifact, workflow state, knowledge item, or decision satisfies the acceptance conditions of its recipient and carries sufficient context, evidence, and provenance for downstream use. The recipient should not need to reconstruct hidden assumptions or repeat upstream reasoning merely to determine whether the transferred object is applicable. Handoff validity therefore extends beyond local correctness. For example, an RTL patch may compile and pass the active testbench yet violate interface, synthesizability, or integration assumptions required by downstream synthesis and formal-verification flows. A synthesis TCL script may execute successfully in one session yet become unusable after a session restart, tool-version change, or library-path update. A retrieved DRC rule may be relevant to a query but constitute a valid handoff only when its source, process node, PDK revision, and scope of applicability are compatible with the receiving design context. Handoff contracts. A handoff contract specifies the acceptance conditions imposed by the recipient, the assumptions under which the transferred object remains applicable, and the evidence required to establish that those conditions have been satisfied. When contract information is incomplete, the recipient may be unable to determine whether the transferred object remains valid. For instance, an RTL patch delivered to an integration flow without compilation or simulation evidence leaves the receiving agent or engineer unable to determine whether the expected validation was completed before handoff. Handoff objects. A handoff object is any artifact, workflow state, knowledge item, command, or decision transferred from a provider to a downstream consumer and used in a subsequent engineering action. A synthesized netlist becomes a handoff object when it is passed to the placeand-route stage. Scripts, constraints, checkpoints, and execution records form a handoff object when a recovery agent must resume an interrupted flow. A retrieved DRC rule becomes a handoff object when it conditions the layout edits proposed or applied by an agent. Coordination mechanisms. Coordination mechanisms are recurring interaction patterns through which providers and consumers produce, transfer, validate, and maintain handoff objects. A generate–repair mechanism submits each candidate to a stage-local checker and iterates until the applicable acceptance condition is satisfied. A recover–resume mechanism reconstructs a coherent workflow state from compatible checkpoints, scripts, constraints, and execution records after an interruption. A retrieve–answer mechanism selects evidence from an applicable knowledge source and returns a grounded response together with the context needed for downstream interpretation. 2.2

Stage, Flow, and Organization Boundaries

Agentic EDA systems differ in the scope across which handoff validity must be preserved. The three boundary classes are distinguished by the boundary crossed by the transferred object, as illustrated in Figure 3. Each class is named for the scope over which its applicable handoff contracts must be satisfied. Stage-Bound systems. These systems operate under a stage-local acceptance boundary within a single EDA stage or bounded verification task. Some close an online feedback loop, while others produce stage-local artifacts or evidence for downstream generation, diagnosis, or evaluation. Their handoff contracts specify stage-local acceptance conditions, established through evidence such as compilation, simulation, performance evaluation, or physical-verification verdicts. Such evidence addresses artifact validity within the local stage context. A design or verification artifact must carry sufficient context for its immediate consumer to use it without reconstructing missing assumptions. 7

1

Spec

STAGE-BOUND

Agent A

Agent B

Artifact

2

Checker Result

Stage A

FLOW-BOUND

Agent A

Checkpoint

Agent B Stage B

RTL QoR Report

Checke r

3

ORGANIZATION-BOUND

Retrieved Agent B Engineer / Knowledge Agent A Knowledge Base Tool

Retrieved Knowledge

PASS

Source Grounding

Flow Checkpoint

Handoff Contracts

Handoff Contracts

Handoff Contracts

Script Execution · Downstream Validation

Source Grounding

Handoff Objects

Handoff Objects

Handoff Objects

Design Artifact · Verification Artifact

Stage Output · QoR Record · Flow State

Knowledge Artifact · Command Artifact

Coordination Mechanisms

Coordination Mechanisms

Functional Verification · Specification · Performance · Physical Verification

Coordination Mechanisms

Generate-Repair · Search-Optimize · Supporting

Orchestrate-Transform · Recover-Resume · Annotate-Optimize

Retrieve-Answer · Retrieve-Execute

Fig. 3. Boundary-centered taxonomy of agentic EDA systems. Stage-Bound, Flow-Bound, and OrganizationBound systems are distinguished by the scope across which handoff validity must be preserved. Each panel summarizes the corresponding handoff contracts, handoff objects, and coordination mechanisms.

Representative systems span RTL repair loops (e.g., RTLFixer [9], VerilogCoder [24]), analog sizing and layout refinement (e.g., AnalogCoder [25], LayoutCopilot [26]), and assertion generation (e.g., ChatSVA [27]). Flow-Bound systems. These systems preserve handoff validity across tool invocations, sessions, or adjacent pipeline stages. Their handoff contracts specify conditions for successful script execution or downstream validation. Execution results, accumulated quality of results (QoR) records, checkpoints, and traces provide evidence that these conditions have been satisfied. For example, a place-androute (P&R) run consumes a synthesized netlist, the applicable SDC constraint set, and compatible technology and library data. These inputs, together with scripts, tool interfaces, checkpoints, QoR records, and execution traces, must remain mutually consistent as work moves across tools, sessions, and pipeline stages. Representative systems span tool-chain orchestrators [3, 20], log- and metric-guided flow optimization agents [4, 28], and cross-representation design flows [29]. Organization-Bound systems. These systems operate across project, team, knowledge, or authority boundaries. Their handoff contracts are governed by source grounding, which requires retrieved or generated content to remain attributable to inspectable sources whose scope matches the current PDK, tool, project, and organizational context. Relevant evidence may include source attribution, document and tool versions, permission metadata, and provenance links connecting an answer or command to the records from which it was derived. Executability, review, and signoff may still affect whether an artifact is ultimately adopted, but they do not replace source grounding as the governing Organization-Bound contract. These contracts therefore determine whether knowledge or commands remain traceable, applicable, and admissible for reuse across authority boundaries. Representative systems span project-memory and retrieval systems (e.g., Ask-EDA [5], 8

ChipXplore [30]) and retrieval-grounded command or script generation systems (e.g., ChaTCL [31], ChatLS [13]). Assignment. The three classes describe increasingly broad validity scopes rather than mutually exclusive system capabilities. Evidence that establishes validity within a narrower scope does not automatically establish validity across a broader boundary. A paper is assigned to the broadest boundary scope that is both instantiated by its mechanism and supported by its evaluation. RTLFixer [9] is Stage-Bound because compiler feedback closes its local RTL repair loop. ChatEDA [3] is Flow-Bound because it coordinates scripts, tools, and artifacts across a multi-stage RTL-to-GDSII flow. Ask-EDA [5] is Organization-Bound because its retrieved outputs cross a project-knowledge boundary and support downstream engineering decisions. ChatLS [13] is also Organization-Bound because retrieved design knowledge conditions the generation of executable synthesis scripts. Its handoff validity therefore depends not only on script executability, but also on whether the retrieved knowledge is grounded in sources applicable to the current design and tool context. 3

STAGE-BOUND SYSTEMS

Stage-Bound systems are identified by a stage-local acceptance boundary within a single EDA stage. Some systems close an online feedback loop through an executable checker, while others produce stage-local artifacts or evidence that support downstream generation, diagnosis, or evaluation. Their acceptance evidence may come from compilers, functional or circuit simulators, physicalverification tools, coverage monitors, formal checkers, or learned evaluators. Table 2 summarizes the surveyed systems. The subsections below cover handoff contracts, handoff objects, and coordination mechanisms, followed by open questions about stage-local closure. 3.1

Handoff contracts

We group Stage-Bound handoff contracts into four families according to their acceptance conditions: functional verification, specification, performance, and physical verification. A system is labeled Hybrid when evidence from multiple contract families substantively shapes its mechanism, training process, candidate-selection policy, or evaluation protocol. Functional Verification. Functional-verification contracts use compilation as an executability condition, simulation or testing as evidence of behavioral correctness, and coverage as evidence of verification adequacy. Basic RTL repair loops return compiler errors or failed simulations for regeneration [9, 10, 33]. More localized variants use waveform traces, simulation checkpoints, or scored candidate histories to guide targeted edits [11, 24, 36]. Multi-artifact workflows jointly generate or revise RTL and testbenches through repeated tool execution [32, 43, 55, 65], while reference-model-based systems compare RTL against SystemC or behavioral models during correction [40, 56]. CPU-oriented generation may similarly pair modular RTL with a processor reference model and return co-simulation failures for module redesign [12]. Other structured RTL platforms revise generated implementations through automatically constructed tests, industrial simulation, static checking, formal verification, or adaptive reflection [44, 53]. Verification-focused systems regenerate tests from coverage feedback or repair executable analog testbenches from simulation failures [57, 77]. Functional evidence may also support training-data filtering or post-hoc evaluation without closing an online loop [49, 71]. Beyond pure functional closure, RTL and HLS optimization systems combine correctness with PPA-oriented regeneration or evolution [46, 61, 74]. Candidateranking systems instead filter invalid designs before applying synthesis- or implementation-derived objectives [60, 68, 70]. Workflow- and training-level methods use functional evidence for workflow search, coordinated transformation, or model updating [72, 73, 75]. Hybrid analog systems combine executable or structural correction with simulator-based performance evaluation [25, 52, 79]. 9

Table 2. Stage-Bound systems discussed in Section 3 across three analytical lenses. System

Handoff contracts

Handoff objects

Coordination mechanisms

Source

Front-end RTL Framework [32] RTL Agent [33] Artisan [34] ChatCPU [12] RTLFixer [9] ADO-LLM [35] MEIC [36] Std-Cell Layout Opt. [37]

Functional verification Functional verification Performance Functional verification Functional verification Performance Functional verification Hybrid

Hybrid Design artifact Design artifact Hybrid Design artifact Design artifact Design artifact Design artifact

Generate–repair Generate–repair Search–optimize Generate–repair Generate–repair Search–optimize Generate–repair Search–optimize

ATS’24 ATS’24 DAC’24 DAC’24 DAC’24 ICCAD’24 ICCAD’24 LAD’24

VerilogCoder [24] AnalogCoder [25] Circuit-Agent [38] PCBAgent [39] MAGE [11] ReChisel [10] UVLLM [40] LiK [41] YieldAgent [42] EDA-Aware RTL Gen. [43] RTL Designer [44] LintLLM [45] VeriOpt [46] AI Analog KG [47] AnaFlow [48] Sage-HLS [49] MALLS [50] Ledro [51] MenTeR [52] Spec2RTL-Agent [53] SVRF Code Synthesis [54] CoopetitiveV [55] AutoFSM [56] AnalogTester [57] AnalogXpert [58] DRC-Coder [59] CRADLE [60] LLM-VeriPPA [61] Atelier [62] LayoutCopilot [26] LLM-USO [63] EEsizer [64] AutoSilicon [65] ChatArch [66] ChatDSE [67] Data-Centric Agent [68] HLS Directive Optimization [69] LHS [70] FTEDA [71]

Functional verification Hybrid Performance Hybrid Functional verification Functional verification Functional verification Functional verification Performance Functional verification Functional verification Specification Hybrid Performance Performance Functional verification Hybrid Performance Hybrid Functional verification Specification Functional verification Functional verification Functional verification Specification Specification Hybrid Hybrid Performance Hybrid Performance Performance Functional verification Hybrid Performance Hybrid Performance Hybrid Functional verification

Design artifact Design artifact Design artifact Design artifact Hybrid Design artifact Hybrid Verification artifact Verification artifact Hybrid Hybrid Verification artifact Design artifact Design artifact Design artifact Design artifact Verification artifact Design artifact Design artifact Design artifact Verification artifact Hybrid Hybrid Verification artifact Design artifact Verification artifact Design artifact Design artifact Design artifact Design artifact Design artifact Design artifact Hybrid Design artifact Design artifact Design artifact Design artifact Design artifact Design artifact

Generate–repair Generate–repair Generate–repair Search–optimize Generate–repair Generate–repair Generate–repair Supporting Search–optimize Generate–repair Generate–repair Supporting Generate–repair Search–optimize Search–optimize Supporting Generate–repair Search–optimize Generate–repair Generate–repair Supporting Generate–repair Generate–repair Generate–repair Generate–repair Generate–repair Search–optimize Hybrid Search–optimize Generate–repair Search–optimize Search–optimize Generate–repair Search–optimize Search–optimize Search–optimize Search–optimize Search–optimize Supporting

AAAI’25 AAAI’25 AICAS’25 ASP-DAC’25 DAC’25 DAC’25 DAC’25 DAC’25 DAC’25 DATE’25 EIECT’25 GLSVLSI’25 ICCAD’25 ICCAD’25 ICCAD’25 ICCD’25 ICCD’25 ICLAD’25 ICLAD’25 ICLAD’25 ICLAD’25 ICMLW’25 ICONIP’25 ISEDA’25 ISEDA’25 ISPD’25 ISOCC’25 MLCAD’25 TCAD’25 TCAD’25 TCAD’25 TCAS-I’25 TODAES’25 TODAES’25 TODAES’25 TODAES’25 TODAES’25 TODAES’25 FnT EDA’25

ChipSeek [72] CODMAS [73] REvolution [74] VFlow [75] Code, Not Canvas [76] ChatSVA [27] ChatTest [77] Automated SVA [78] AnalogCoder-Pro [79] TopoSizing [80] cGenEDA [81]

Hybrid Hybrid Hybrid Hybrid Hybrid Specification Functional verification Specification Hybrid Performance Performance

Design artifact Design artifact Design artifact Design artifact Design artifact Verification artifact Verification artifact Verification artifact Design artifact Design artifact Design artifact

Search–optimize Generate–repair Hybrid Search–optimize Hybrid Supporting Generate–repair Supporting Generate–repair Search–optimize Search–optimize

ACL’26 EACL’26 ASP-DAC’26 ASP-DAC’26 ASP-DAC’26 DAC’26 DATE’26 ISEDA’26 TCAD’26 TCAD’26 TODAES’26

Other hybrids combine executability with vulnerability semantics, architectural PPA, or physical 10

validity [50, 66, 76]. Across these settings, functional evidence serves three distinct roles. It can directly drive online correction, gate candidates before downstream optimization, or support offline data construction and evaluation. Specification. Specification contracts assess conformance to explicit properties, static rules, vulnerability conditions, or rule-code semantics rather than correctness inferred only from available simulation stimuli. Property-generation systems check whether assertions preserve intended temporal and behavioral meaning through syntax analysis, formal equivalence, or coverage-oriented evaluation [27, 78]. Static-diagnosis systems identify likely primary RTL defects and consolidate secondary warnings into structured reports [45]. Rule-code systems may compare generated checker behavior with commercial DRC results and use the discrepancies for repair [59]. Other rule-code systems emphasize structural and grammatical validity through retrieval, AST-aware supervision, and parsing without executing a commercial-rule feedback loop [54]. MALLS combines Verilatorbased compilation and linting with a Validation LLM that assesses the realism of bug-injected RTL and produces bug justifications, while its Discriminator LLM performs CWE classification and vulnerable-line localization [50]. Structural analog checking may enforce block compatibility and connection legality before circuit simulation [58]. More integrated analog systems combine primitive-connectivity rules with DC-sweep and functional tests [52]. LayoutCopilot [26] is evaluated through checks of JSON formatting, invalid-request handling, command syntax, and logical consistency. These post-hoc evaluation checks do not participate in its online command-revision loop. Specification evidence therefore supports inference-time repair, offline curation, structural validation, or post-hoc workflow assessment. Performance. Performance contracts use quantitative QoR as an optimization objective, candidateranking signal, or explicit acceptance condition. Reasoning-based analog sizing may escalate to optimizer-assisted refinement or ReAct-style parameter updates [48, 64]. Bayesian and structured search methods use simulator-derived metrics to explore analog parameter spaces [35, 63, 80]. Search-space reduction, topology-aware exploration, and multi-agent design reasoning further constrain expensive simulation campaigns [34, 51, 62]. Yield-estimation systems compare simulation strategies and hyperparameter settings under explicit accuracy, precision, and computationalbudget objectives [42]. Diagnostic analog loops return failed simulation criteria to parameter or topology agents for revision [38, 52]. AI Analog KG [47] transfers structured experience from prior circuits while retaining simulation as the current-task oracle. Executable analog-generation systems combine code correction with simulator-guided refinement [25, 79]. Architectural exploration may evaluate candidates using cycle-level simulation and power models [66], whereas ChatDSE estimates power and clock-cycle metrics through LLM-generated pseudo-labels to construct a predicted Pareto set [67]. Electromagnetic design may generate geometry, simulation code, and surrogate models before candidate evaluation [81]. LayoutCopilot [26] represents a human-mediated variant in which post-layout results are relayed for command revision. RTL methods may combine functional closure with report-conditioned PPA refinement or evolutionary search [46, 73, 74]. Other RTL methods explicitly separate functional repair from scored PPA exploration [61, 68]. FPGA and HLS systems rank implementations using synthesis or downstream implementation results [60, 70]. Workflow and training methods optimize agent graphs or model policies using EDA-derived rewards [72, 75]. Physical-design systems combine continuous QoR with legality or rule constraints [37, 39]. Across these domains, performance contracts differ in whether QoR is measured directly, predicted by learned models, or relayed through human evaluation, but all use quantitative evidence to rank alternatives, guide refinement, or select locally acceptable artifacts.

11

Physical Verification. Physical-verification contracts assess spatial artifacts through legality, routability, or rule-checking evidence. Placement systems may enforce boundary, non-overlap, and minimum-spacing constraints before ranking legal candidates using wirelength-related metrics or user preferences [39]. Constraint-generation systems instead produce clustering or structural directives for a downstream layout engine and revise them using routability, LVS/DRC outcomes, cell dimensions, and wirelength [37]. Code, Not Canvas [76] formulates layout generation as Python program synthesis. It repairs programs that fail execution or GDSII generation, produces layouts under width, spacing, and area constraints, and then refines layout diversity while preserving rule compliance. Across these systems, physical evidence can serve as a feasibility gate for candidate admission, an iterative correction signal, or a hard constraint within quality-driven search. A contract is labeled Hybrid when physical validity is coupled with continuous performance or diversity objectives, but physical rule compliance remains the governing feasibility condition. 3.2

Handoff objects

In Stage-Bound systems, primary handoff objects fall into two role-defined families, namely design artifacts and verification artifacts. A system may transfer either family or both. A system is labeled Hybrid when both design and verification artifacts are substantively generated, revised, or transferred across the stage-local workflow. The distinction depends on the role of an artifact rather than its format. Plans, traces, logs, graphs, and revision histories are treated as auxiliary handoff context only when they are explicitly transferred between collaborating components or passed to an external tool. Their presence alone does not make a system Hybrid, and their internal use within a workflow does not imply that they are packaged with the final artifact. Design artifact. Design-artifact handoffs transfer a generated, repaired, or optimized designside object as the primary payload. Basic RTL systems ultimately deliver corrected RTL, with compiler and simulation evidence serving only as local repair context [9]. Systems that jointly produce RTL and testbenches or behavioral models are labeled Hybrid in the object dimension [40, 43]. ChatCPU [12] is likewise Hybrid because it generates modular RTL together with a CPU reference model used for co-simulation. RTL Designer [44] combines implementation RTL with automatically generated verification collateral, whereas Spec2RTL-Agent [53] ultimately hands off the functionally validated RTL produced through its progressive coding and reflection process. Analog-generation systems deliver executable circuit descriptions or simulator-evaluated parameter assignments [25, 35]. Candidate-management workflows retain RTL versions and scores for selection or rollback [36, 46]. Planner- and trace-based systems pass task plans, waveform evidence, or checkpoints among local agents [10, 11, 24]. Structured-generation systems exchange intermediate representations, mismatch traces, or deterministic transformation results [56, 73]. Data-Centric Agent [68] maintains Verilog candidates and derived meta-rules, but the highest-scoring RTL remains its stage-facing artifact. Analog systems may pass topology histories or hierarchical annotations to downstream optimizers [58, 80]. Physical-design systems may instead transfer clustering constraints to a layout framework [37]. AI Analog KG [47] is a cross-instance boundary case: prior-circuit knowledge graphs provide persistent context, while the primary output remains an optimized parameter assignment. VFlow [75] is a meta-level boundary case because its search object is a workflow graph, whereas executing the selected workflow produces the stage-facing RTL artifact. Overall, the classification follows the stage-facing payload consumed for implementation or optimization. Corrected RTL, executable circuit descriptions, parameter assignments, and physical constraints remain design artifacts even when they are accompanied by plans, traces, repositories, knowledge graphs, or workflow states. 12

Verification artifact. Verification-artifact handoffs transfer collateral used to check, diagnose, or stress a design. Test-generation systems produce requirements, plans, cases, and executable testbenches and may regenerate stimulus when coverage is insufficient [57, 77]. Property-generation systems produce executable assertion sets whose validity depends on temporal and behavioral fidelity [27, 78]. Rule-generation systems produce checker code or grammar-constrained rule decks for downstream verification [54, 59]. Some workflows transfer both design and verification artifacts by pairing generated RTL with testbenches, automatically generated test collateral, or behavioral reference models [32, 43, 44]. ChatCPU [12] similarly combines modular RTL with a CPU reference model that supports module-interchangeable co-simulation. Others pair RTL with non-synthesizable testbenches, SystemC verification programs, or behavioral reference models [11, 40, 56]. Co-generation systems may revise both RTL and testbenches from compiler or simulation feedback [55, 65]. Verification artifacts need not be executable. For example, YieldAgent [42] produces yield estimates, convergence records, and evidence about the relationship between estimation accuracy and computational cost for assessing manufacturing robustness. Diagnostic methods produce structured defect reports or buggy-line localization evidence for downstream repair [41, 45]. Adversarial-generation systems produce deliberately vulnerable RTL together with CWE labels, bug locations, explanations, and metadata [50]. Overall, verification artifacts may be executable or non-executable, but in either form they must faithfully support the checking, diagnostic, or stress-testing role required by the receiving component. 3.3

Coordination mechanisms

Among iterative Stage-Bound systems, two coordination mechanisms dominate: generate–repair and search–optimize. Generate–repair revises a current artifact using diagnostic feedback, whereas search–optimize compares alternatives using scalar or multi-objective scores. The table uses Supporting to mark systems that produce stage-local artifacts or evidence without independently closing either iterative loop. A system is labeled Hybrid only when it substantively instantiates both mechanisms. Generate–repair. Generate–repair repeatedly revises an active artifact until it satisfies a stage-local acceptance condition. Basic RTL loops regenerate code from compiler or simulation failures [9, 10, 33, 56]. Localized variants instead use candidate histories, waveform traces, or state checkpoints for targeted edits [11, 36]. Planner-based methods convert simulation evidence into structured debugging or revision plans [24, 73]. Multi-artifact workflows jointly revise RTL and testbenches from simulation or coverage feedback [32, 43, 55], while coverage-driven testing and modular generation apply the same pattern at different artifact scales [65, 77]. CPU-generation systems return linting and reference-model co-simulation failures for redesign of the active module [12]. Structured RTL platforms similarly regenerate implementations from simulation, testbench, staticchecking, or reflection evidence [44, 53]. Verification systems repair DUT RTL, testbench code, or adversarial examples using simulation, compilation, or linting evidence [40, 50, 57]. Analog systems revise executable circuit code or topology from structural and simulation diagnostics [25, 52, 58]. Parameter-oriented variants return failed criteria to sizing agents for further revision [38, 79]. Rule and layout systems similarly repair checker code or executable layout programs from discrepancies and execution failures [59, 76]. LayoutCopilot [26] is human-mediated, whereas VeriOpt [46] remains generate–repair because its PPA stage uses a precomputed report rather than real-time scored search. Across these systems, coordination centers on diagnosing and revising the current candidate rather than systematically comparing multiple candidates within a scored search space. Search–optimize. Search–optimize compares candidates over parameter, topology, configuration, or workflow spaces. Bayesian analog optimization explores simulator-evaluated parameter 13

candidates [35]. Multi-agent and topology-aware frameworks jointly explore circuit topology and sizing decisions under simulation feedback [62, 80]. Tree-based or structured reasoning methods guide topology exploration before simulation [34]. Staged simulation and search-space reduction reduce the cost of analog sizing [48, 51, 63]. Yield-analysis systems search over estimation methods, method combinations, resource allocations, and hyperparameters using accuracy, convergence, and simulation cost as selection criteria [42]. ReAct-style methods instead revise parameter candidates from repeated simulator evaluations [64]. AI Analog KG [47] augments the current LLM–BO loop with fixed knowledge graphs transferred from prior circuits. Architectural exploration may rank microarchitecture candidates using cycle-level simulation and power models [66], or use LLM-estimated power and clock-cycle metrics to identify Pareto-optimal designs [67]. HLS exploration uses synthesis reports or learned pseudo-labels to compare directives and designs [69]. Physical-design search compares clustering constraints or legal placements using QoR and routability metrics [37, 39]. Electromagnetic search combines EM simulation with surrogate modeling for expensive geometry exploration [81]. RTL-level search filters invalid candidates and ranks valid designs using PPA-oriented scores [68]. FPGA and HLS systems use synthesis or implementation objectives to rank candidate designs [60, 70]. Training-oriented search uses EDA feedback to improve generation policies [72]. VFlow [75] extends search above the artifact level by comparing workflow graphs. Hybrid systems repair invalid candidates before evolving or ranking valid ones [61, 74]. Code, Not Canvas [76] establishes rule-compliant code before diversity refinement. Across these systems, coordination centers on evaluating and selecting among alternative candidates rather than repeatedly diagnosing and revising the current candidate. Supporting. Supporting systems produce stage-local artifacts, diagnostic evidence, or validation results without independently closing a generate–repair or search–optimize loop. Localization methods identify likely buggy lines for downstream debugging [41]. Diagnostic methods consolidate related warnings around likely primary RTL defects [45]. Staged verification-generation methods transform specifications into plans, features, checkpoints, and property sets without an inference-time repair loop [27]. Assertion-generation methods may apply syntax checking and formal equivalence only as post-generation evaluation [78]. Rule-code synthesis can rely on retrieval, structural supervision, and grammar parsing without iterative repair against a commercial DRC engine [54]. HLS tools may filter generated training samples and evaluate synthesizability without feeding failures back into inference [49]. Evaluation frameworks may translate generated C++ into RTL and validate the result without invoking automated regeneration [71]. These systems remain Stage-Bound because both the produced artifact or evidence and the downstream component that consumes it belong to the same design or verification stage. 3.4

Open Questions

Stage-Bound systems have demonstrated measurable progress under local acceptance conditions. RTL repair systems close compiler- or simulation-facing loops using diagnostics and localized execution evidence [9, 24]. Analog systems use simulation feedback either to correct executable circuit descriptions or to guide constrained sizing optimization [25, 80]. Code-based layout generation can likewise establish executable, rule-compliant artifacts before refining secondary objectives such as layout diversity [76]. Nevertheless, local closure raises several unresolved questions. • How should heterogeneous local feedback be represented and made actionable? Local evidence may take the form of binary outcomes, compiler diagnostics, waveform traces, or reference-model mismatches. It may also include state checkpoints, convergence signals, QoR metrics, and learned performance estimates. RTL systems increasingly use localized traces or reference-model mismatches rather than undifferentiated pass/fail signals [11, 12, 24], while 14

Table 3. Flow-Bound systems discussed in Section 4 across three analytical lenses. System

Handoff contracts

Handoff objects

Coordination mechanisms

Source

ChatEDA [3] LLM-AID [28]

Script execution Hybrid

Flow state Hybrid

Orchestrate–transform Hybrid

TCAD’24 ICCAD’24

AiEDA [82] MAHL [83] ASIC-Agent [20] SoCDev [84] MALTS [29] GenSoC [85] TESLA [86] ORFS-agent [4] EDAid [87]

Downstream validation Downstream validation Hybrid Hybrid Downstream validation Downstream validation Downstream validation Downstream validation Script execution

Stage output Hybrid Hybrid Hybrid Stage output Stage output Stage output QoR record Flow state

Orchestrate–transform Hybrid Hybrid Hybrid Orchestrate–transform Orchestrate–transform Orchestrate–transform Annotate–optimize Orchestrate–transform

FAIML’25 ICCAD’25 ICLAD’25 IJCNN’25 ISEDA’25 ISLPED’25 ITC’25 MLCAD’25 NAACL’25

Autonomous Evolution [88]

Hybrid

Hybrid

Hybrid

DAC’26

analog optimization relies on multiple simulation-derived constraints and objectives [35, 80]. Yield analysis additionally combines convergence, estimation error, and simulation-budget evidence when selecting analysis strategies [42]. Other systems obtain evidence from predicted pseudo-labels or offline tool-based filtering rather than direct inference-time feedback [49, 67]. It remains open how these signals should be calibrated, prioritized, and translated into reliable repair actions, search decisions, or offline data-curation policies. • How should multiple local oracles be composed? Some systems are governed by one dominant oracle, such as compiler success in RTLFixer [9] or simulator-evaluated figures of merit in ADO-LLM [35]. Others combine syntax checking, functional simulation, performance objectives, structural rules, or physical constraints within the same stage. Open questions include whether inexpensive checks should gate expensive ones, how conflicting objectives should be resolved, and how evidence from different tools should be aggregated without allowing one local oracle to mask failures detected by another. • What termination criterion is sufficient for stage-local closure? A passing verdict is only one possible stopping condition. RTL repair systems may stop after functional success or an iteration limit [9, 24]. Search-based systems may stop after exhausting an evaluation budget, reaching stagnation, or satisfying a statistical convergence threshold [42, 75, 80]. Code, Not Canvas continues diversity refinement after establishing an executable and rule-compliant baseline [76]. Determining when local evidence is sufficiently stable, comprehensive, and robust to justify propagating an artifact remains unresolved. 4

FLOW-BOUND SYSTEMS

Flow-Bound systems are identified by a continuity boundary that spans multiple EDA stages, tool invocations, optimization rounds, or execution sessions. Their validity depends not only on whether an individual artifact is locally correct, but also on whether stage outputs, execution state, and downstream evidence remain usable across the workflow. Table 3 summarizes the surveyed systems using dimension-specific labels, with Hybrid assigned when multiple categories independently preserve flow-level continuity. 4.1

Handoff contracts

Flow-Bound handoff contracts fall into two families, namely script execution and downstream validation. Script-execution contracts determine whether commands, configurations, and runtime state remain executable as a workflow crosses tool, stage, or session boundaries. Downstreamvalidation contracts determine whether an upstream artifact or decision remains acceptable after it 15

is consumed or measured by a later stage. A system is labeled Hybrid when both forms of evidence independently govern whether the workflow may continue. Script execution. Script-execution contracts govern whether a multi-tool workflow can continue from its current execution context. General orchestration systems decompose EDA requests, generate ordered scripts, and invoke multiple tool backends across extended design flows [3]. Divergent planning methods generate and evaluate alternative execution strategies before committing to actions in long tool sequences [87]. Hybrid systems combine this executability requirement with later-stage validation. LLM-AID [28] must produce executable code and synthesis scripts before downstream PPA evidence can guide refinement. ASIC-Agent [20] executes verification, hardening, and integration procedures while monitoring tool errors and flow progress. SoCDev [84] revises Tcl scripts against an evolving Vivado project state and must preserve compatibility with completed subtasks. Autonomous Evolution [88] first requires each modified ABC repository to compile before formal equivalence and QoR evaluation can proceed. Script-execution contracts therefore determine whether the current workflow context remains executable and interpretable as commands, artifacts, and tool operations accumulate. Downstream validation. Downstream-validation contracts close only when an upstream artifact or decision remains acceptable under a later stage’s entry conditions or measurements. Full ASIC chains pass RTL, synthesized netlists, timing constraints, reports, and physical-design outputs through successive simulation, synthesis, analysis, and implementation tools [82]. Crossrepresentation and testability flows require earlier decisions to remain usable during downstream TCAD generation, synthesis, or ATPG [29, 86]. Hierarchical hardware and SoC-generation systems validate generated modules, integration decisions, and implementation configurations across later stages [83, 85]. Some systems are Hybrid because downstream evidence follows an independently enforced execution contract. LLM-AID [28] uses synthesis-derived PPA evidence after its generated code and scripts execute successfully. ASIC-Agent [20] requires RTL and configuration decisions to survive verification, hardening, and platform integration. SoCDev [84] closes only after the generated bitstream passes FPGA validation. ORFS-agent [4] evaluates flow configurations using partial and post-route metrics, while Autonomous Evolution [88] accepts repository modifications only after compilation, equivalence checking, and multi-benchmark QoR evaluation. Downstreamvalidation contracts therefore require upstream choices to remain effective after later tools expose their implementation, integration, correctness, or quality consequences. 4.2

Handoff objects

Flow-Bound systems carry continuity through three primary object families, namely stage outputs, QoR records, and flow state. A stage output moves forward to a receiving design or analysis stage. A QoR record carries downstream measurements backward to upstream decisions in later rounds. Flow state is consumed by orchestration, recovery, or evolution components to continue a multitool, multi-stage, or multi-session execution. A system is labeled Hybrid when two or more object families independently preserve continuity across later stages, sessions, or optimization rounds. Stage output. Stage-output handoffs transfer intermediate representations that later design, integration, implementation, or analysis stages directly consume. Full ASIC chains pass RTL, netlists, constraints, reports, and physical-design results through successive tools [82]. LLM-AID [28] is Hybrid because generated high-level code, HDL, and synthesis scripts move forward through the flow while associated QoR records return to guide later refinement. MAHL [83] similarly transfers hierarchical descriptions, generated RTL, and implementation configurations while retaining evaluation records for design-space exploration. ASIC-Agent [20] passes RTL, verification collateral, 16

hardening configurations, physical-design results, and integration artifacts while also preserving implementation metrics. SoCDev [84] is Hybrid because project outputs such as constraints, implementation results, and the final bitstream advance through the workflow while project state is retained for continued execution. GenSoC [85] carries selected IPs, interface information, integration configurations, and verification results into later construction stages. MALTS [29] converts layout and process information into descriptions and scripts consumed by TCAD tools, while TESLA [86] transfers partial-scan decisions and modified RTL into TPI, synthesis, and ATPG. Stage outputs remain valid only when the receiving stage can consume them without reconstructing hidden upstream assumptions or manually recreating missing context. QoR record. QoR-record handoffs preserve the relationship between downstream measurements and the upstream decisions that produced them. LLM-AID [28] retains synthesis-derived power, performance, and area evidence together with the generated code and scripts responsible for those results. MAHL [83] preserves synthesis metrics, bottleneck information, and design-space exploration results alongside its stage outputs, making it Hybrid in the object dimension. ASICAgent [20] links timing, power, area, DRC, and antenna outcomes to hardening configurations and design revisions. ORFS-agent [4] executes batches of flow configurations, collates partial and completed metrics, and uses the accumulated data to propose new configuration and timingconstraint values. Autonomous Evolution [88] is Hybrid because benchmark-level correctness and QoR profiles remain associated with repository versions, while the evolving repository and champion state are also preserved as flow state. Metrics used only for final reporting do not constitute QoR-record handoffs. QoR records must persist across rounds and remain linked to the upstream configuration, artifact, or repository version that produced them. Flow state. Flow-state handoffs encode the operational context required to continue a workflow across tool calls, stages, failures, sessions, or evolution cycles. Prescriptive state records what should be executed, including task plans, scripts, command ordering, parameters, and interface assumptions [3, 87]. Descriptive state records what has already occurred, including completed subtasks, tool responses, errors, partial results, and prior execution outcomes. SoCDev [84] is Hybrid because it preserves the current Vivado project state, scheduled subtasks, message memory, and Tcl revisions while also forwarding implementation artifacts and the final bitstream. Autonomous Evolution [88] maintains an evolving ABC repository, agent hypotheses, code modifications, correctness results, the current champion, and associated QoR histories. It is therefore Hybrid because repository-scale flow state and QoR records independently govern later evolution cycles. Scripts or logs used only within one isolated invocation are insufficient to establish a flow-state handoff. Flow state must remain available to later actions without requiring reconstruction of all prior execution context. 4.3

Coordination mechanisms

Flow-Bound coordination takes three forms, namely orchestrate–transform, recover–resume, and annotate–optimize. Orchestrate–transform manages forward execution and representation changes across stages. Recover–resume preserves or restores a consistent workflow state after partial failure or regression. Annotate–optimize routes downstream quality evidence back to upstream decisions across rounds. A system is labeled Hybrid when two or more flow-level mechanisms independently determine stage progression, recovery, rollback, or optimization updates. Local retries, logging, or result collection do not trigger this label unless they substantively govern the continuation policy. Orchestrate–transform. Orchestrate–transform mechanisms preserve forward continuity by coordinating tool invocations and preparing outputs for their receiving stages. Script-oriented systems decompose long EDA tasks, retrieve tool knowledge, generate ordered commands, and dispatch 17

them to multiple backends [3, 87]. Full ASIC chains coordinate simulation, synthesis, timing analysis, and physical implementation while carrying the required outputs between tools [82]. LLM-AID [28] is Hybrid because it coordinates transformations from specification through code generation and synthesis while also using downstream QoR for later refinement. MAHL [83] combines hierarchical generation and stage transitions with feedback-driven design-space exploration. ASIC-Agent [20] coordinates RTL generation, verification, hardening, and integration while using implementation results to update later decisions. SoCDev [84] schedules project creation, constraints, synthesis, implementation, bitstream generation, and FPGA validation while retaining the current project state for recovery. MALTS [29], GenSoC [85], and TESLA [86] emphasize forward transformation across TCAD, SoC integration, and DFT stages. Orchestrate–transform coordination therefore centers on keeping commands executable and outputs consumable as the workflow advances across stages. Recover–resume. Recover–resume mechanisms preserve or restore workflow state after partial failure or regression so that useful progress is not discarded. SoCDev [84] represents a lightweight form of stateful recovery. Tool errors and execution results are returned to the supervisory component, which revises the Tcl script for the current subtask before allowing the workflow to advance. The same system also orchestrates forward stage progression, so it is Hybrid in the mechanism dimension. SoCDev does not serialize explicit checkpoints, but it continues from an evolving project and task state rather than treating each failed command as an independent attempt. Autonomous Evolution [88] provides a stronger rollback mechanism. Compilation or equivalence failures reject the current modification, while QoR regressions restore the affected subsystem from the retained champion repository. Its rollback mechanism operates alongside QoR-guided evolution, making the system Hybrid. Recover–resume coordination therefore centers on restoring forward progress from the latest valid workflow state rather than restarting the complete process. Annotate–optimize. Annotate–optimize mechanisms attach downstream quality evidence to the upstream decisions that generated it and reuse the resulting record in later rounds. LLM-AID [28] feeds synthesis-derived PPA results into subsequent code and script refinement while also coordinating the transformations that produce those artifacts. MAHL [83] combines forward hierarchical generation with synthesis-aware and bottleneck-aware design-space exploration. ASIC-Agent [20] uses timing, power, area, and physical-verification evidence to update hardening configurations and design decisions after orchestrating the ASIC flow. These three systems are therefore Hybrid in the mechanism dimension. ORFS-agent [4] is a pure annotate–optimize case because it collates complete and partial implementation metrics and uses them to launch new configurations rather than recovering interrupted runs. Autonomous Evolution [88] uses correctness and QoR profiles to guide the next repository modification while retaining rollback to the champion state when regressions occur. It is therefore Hybrid because downstream annotation governs continued optimization and recover–resume preserves a valid repository state. Annotate–optimize coordination centers on preserving and reusing the relationship between downstream measurements and upstream choices. 4.4

Open Questions

Flow-Bound systems demonstrate that LLM-based components can coordinate heterogeneous tools, transform intermediate representations, continue from project-level failures, preserve repositoryscale state, and use downstream evidence to revise earlier decisions. Hybrid systems further show that forward orchestration, recovery, and optimization may interact within the same workflow. Their effectiveness nevertheless depends on context that may become incomplete, inconsistent, or obsolete as artifacts, tools, and environments change. 18

• How should cross-stage handoff context be represented and validated? A stage output may depend on tool versions, units, constraints, naming conventions, process assumptions, interface definitions, and command options that are not contained in the primary file. Scriptoriented systems expose the importance of executable interface context [3, 87], while full-chain systems depend on compatible assumptions across successive tools [82]. Hybrid object systems introduce an additional challenge because stage outputs, QoR records, and flow state must remain mutually consistent. It remains open how to define a minimal but sufficient context bundle and how to validate its internal consistency before a later stage consumes the handoff. • How should downstream failures be attributed and recovery boundaries selected? A failure observed in a later tool may originate from the current command, an earlier artifact, an incompatible configuration, stale runtime state, or an invalid stage transition. SoCDev [84] revises Tcl scripts using the current project state and tool outcomes but does not establish validated rollback checkpoints. Autonomous Evolution [88] supports subsystem rollback to a champion repository, but its policy assumes that regressions can be localized to designated components. Hybrid mechanisms make attribution more difficult because a failed outcome may require forward transformation, state recovery, or another optimization round. It remains open how to identify the earliest invalid handoff and select the appropriate continuation mechanism. • When does accumulated evidence remain sufficient for flow-level closure? QoR records are comparable only when their tool versions, constraints, workloads, parameter spaces, and implementation conditions remain aligned. LLM-AID [28] and ORFS-agent [4] reuse downstream measurements across refinement rounds, while Autonomous Evolution [88] aggregates correctness and QoR results before updating its champion repository. Hybrid systems must additionally satisfy multiple continuation conditions because successful orchestration does not guarantee valid recovery or converged optimization. It remains unresolved how evidence from different mechanisms should be combined and how much of the workflow must be re-executed before flow-level closure can be claimed. 5

ORGANIZATION-BOUND SYSTEMS

Organization-Bound systems are identified by an authority boundary across which documentation, project knowledge, design evidence, or procedural expertise is reused. Their validity depends on whether generated answers and commands remain grounded in inspectable sources whose scope matches the current design, tool, and organizational context. Unlike Flow-Bound systems, which preserve continuity across tool executions, Organization-Bound systems govern whether knowledge crossing project, team, or authority boundaries is sufficiently attributable and appropriately scoped for accountable reuse. Table 4 summarizes the surveyed systems according to their handoff contracts, handoff objects, and coordination mechanisms. The following subsections examine these three dimensions and conclude with open questions about source scope, provenance, and organizational admissibility. 5.1

Handoff contracts

Organization-Bound systems use one primary contract family, namely source grounding. This contract determines whether an answer, diagnosis, or executable artifact remains attributable to sources whose authority and scope match the current question, design revision, or tool environment. Retrieval relevance alone does not establish the contract because a semantically similar source may still describe an incompatible PDK, tool version, project state, or organizational procedure. Source grounding. Source-grounding contracts require generated outputs to remain tied to inspectable and appropriately scoped evidence. Documentation-oriented systems ground answers 19

Table 4. Organization-Bound systems discussed in Section 5 across three analytical lenses. System

Handoff contracts

Handoff objects

Coordination mechanisms

Source

CustRAG [89] Ask-EDA [5]

Source grounding Source grounding

Knowledge artifact Knowledge artifact

Retrieve–answer Retrieve–answer

ICCAD’24 LAD’24

ChatLS [13] MM-GRADE [90] ChipXplore [30] ChaTCL [31] EDA-Debugger [91] RTLExplain [23]

Source grounding Source grounding Source grounding Source grounding Source grounding Source grounding

Command artifact Knowledge artifact Hybrid Command artifact Command artifact Knowledge artifact

Retrieve–execute Retrieve–answer Hybrid Retrieve–execute Retrieve–execute Retrieve–answer

DAC’25 ICCAD’25 ICLAD’25 ISEDA’25 ISQED’25 MLCAD’25

ChipMind [92] MuaLLM [93] VeriRAG [94] RAG-EDA [95]

Source grounding Source grounding Source grounding Source grounding

Knowledge artifact Knowledge artifact Knowledge artifact Knowledge artifact

Retrieve–answer Retrieve–answer Retrieve–answer Retrieve–answer

AAAI’26 ASP-DAC’26 ASP-DAC’26 ISPD’26

in EDA manuals, PDK materials, technical discussions, and internal question-answer collections [5, 89]. Multimodal systems extend the evidence base to figures, screenshots, layout images, and other visual content that cannot be represented adequately through text-only retrieval [90, 93]. Project-oriented systems instead ground explanations in the structure and dependencies of the current RTL design [23]. Graph-based systems preserve relationships among retrieved facts so that multi-hop answers can be traced through documentation sections, design entities, or specification dependencies [92, 94, 95]. Source grounding also governs executable outputs. Script- and querygeneration systems retrieve tool or database knowledge before producing synthesis scripts, Tcl commands, SQL queries, or Cypher queries [13, 30, 31]. EDA-Debugger [91] grounds runtime diagnosis and executable remedies in technical documentation and previously resolved issues. Source-grounding contracts therefore judge whether an output remains attributable to evidence whose scope is appropriate for its intended reuse. 5.2

Handoff objects

Organization-Bound systems transfer two primary object families, namely knowledge artifacts and command artifacts. Knowledge artifacts package retrieved or derived information for later reasoning, explanation, or engineering decisions. Command artifacts encode grounded knowledge in an executable form intended for an EDA tool, database, or workflow environment. A system is labeled Hybrid when both object families are independently transferred to different consumers or remain necessary for completing the organizational handoff. Knowledge artifact. Knowledge-artifact handoffs externalize documentation, design structure, specification facts, and retrieved evidence into reusable information substrates. Flat retrieval systems index tool manuals, PDK documentation, technical discussions, and domain-specific question-answer records for later engineering queries [5, 89]. Multimodal systems associate textual evidence with figures, screenshots or image summaries [90, 93]. RTLExplain [23] constructs a project-specific substrate from module structure, signals, and data dependencies extracted from the current RTL revision. Graph-oriented systems organize documentation, RTL facts, or specification dependencies into relational structures that support cross-chunk or multi-hop retrieval [92, 94, 95]. ChipXplore [30] is Hybrid because its Interpreter converts database results into a grounded naturallanguage response for engineering consumption, while the SQL and Cypher queries used to obtain those results remain independently consumed command artifacts. Knowledge artifacts therefore preserve inspectable evidence and relationships so that later answers do not depend only on information contained implicitly in model parameters. 20

Command artifact. Command-artifact handoffs translate grounded knowledge into scripts, commands, modifications, or database operations that can be applied to an external environment. ChatLS [13] conditions logic-synthesis script generation on design information, target-library knowledge, tool documentation, and prior synthesis evidence. ChaTCL [31] identifies the target EDA environment before retrieving tool-specific documentation and generating corresponding Tcl commands. ChipXplore [30] is Hybrid because it generates SQL and Cypher queries that are executed against relational and graph databases, while a separate Interpreter converts the returned results into a user-facing knowledge artifact. EDA-Debugger [91] analyzes runtime logs using retrieved documentation and previously resolved issues, then converts the diagnosis into code modifications, configuration adjustments, and specialized EDA commands. Its diagnostic explanation supports review, but the tool-applicable remedy remains the primary handoff object. Command artifacts therefore remain valid only when the retrieved procedural knowledge matches the syntax, configuration, and assumptions of the environment in which they will be used. 5.3

Coordination mechanisms

Organization-Bound coordination uses two mechanisms, namely retrieve–answer and retrieve– execute. Retrieve–answer coordinates evidence acquisition and reasoning before delivering a grounded response. Retrieve–execute translates retrieved evidence into an executable artifact intended for direct or human-mediated application. A system is labeled Hybrid when both mechanisms independently contribute to the final organizational handoff. Internal retrieval performed only to support command generation does not by itself constitute retrieve–answer. Retrieve–answer. Retrieve–answer mechanisms coordinate the path from an engineering query to a source-grounded response. Hybrid lexical and semantic retrieval can be followed by reranking or terminology normalization to remove weakly related evidence and reduce domain-specific ambiguity [5, 89]. Multimodal methods retrieve and align textual and visual evidence before producing an answer [90, 93]. Project-grounded methods parse RTL before query time and constrain explanations to the current design revision [23]. Graph-oriented methods route queries through connected documentation sections, RTL entities, or specification facts before answer generation [92, 95]. VeriRAG [94] combines semantic retrieval with structured graph queries and merges their evidence. ChipXplore [30] is Hybrid because its Interpreter converts structured database results into a grounded natural-language answer after query execution. Retrieve–answer coordination therefore centers on selecting, combining, and presenting evidence whose source and scope remain inspectable at the point of engineering use. Retrieve–execute. Retrieve–execute mechanisms convert retrieved knowledge into executable artifacts whose semantics depend on the active environment. ChatLS [13] grounds synthesis-script generation in design structure, library information, tool documentation, and prior reports so that optimization directives reflect the target synthesis context. ChaTCL [31] first identifies the intended EDA tool and then retrieves tool-specific evidence before generating Tcl commands with compatible syntax and parameter semantics. ChipXplore [30] generates and executes SQL and Cypher queries, repairs invalid or incomplete queries through a Refiner, and passes the returned data to an Interpreter. It is therefore Hybrid because executable query generation and grounded answer formulation are both substantive coordination stages. EDA-Debugger [91] retrieves documentation and previously resolved issues to diagnose runtime failures, then converts the diagnosis into code modifications, configuration changes, and specialized EDA commands. A checking component reviews the proposed remedy before it is delivered for user-mediated implementation. Retrieve– execute coordination therefore centers on preserving the link between retrieved procedural evidence and the executable action derived from it. 21

5.4

Open Questions

Organization-Bound systems have improved the grounding of engineering answers and commands in inspectable sources [5]. Current systems nevertheless provide only partial support for the scope, attribution, and authorization conditions required for accountable organizational reuse. Hybrid systems introduce an additional requirement because executable queries and user-facing interpretations must remain consistent with the same underlying evidence. • How should source scope be represented and enforced at query time? Retrieved evidence may depend on a particular PDK revision, tool release, design snapshot, access domain, or organizational procedure. Flat and multimodal retrieval systems can return relevant evidence without proving that its scope matches the current project [5, 89, 90]. Project-specific parsing and semantic anchors reduce this ambiguity but still require explicit policies for selecting the valid revision and authority context [23, 92]. It remains open how source scope should be encoded, propagated through retrieval, and checked before an answer or command is accepted. • What provenance structure is sufficient for accountable reuse? Chunk-level citations identify retrieved documents but may not preserve the transformations or relational paths used to produce an output. Graph-based systems retain more explicit relationships among source facts [92, 94], while multimodal systems must additionally preserve links between textual claims and visual evidence [93]. Hybrid systems such as ChipXplore [30] must also connect the final answer to the executable queries and database records that produced it. It remains unresolved what provenance granularity is necessary to reconstruct an answer, audit a command, or admit an artifact into a review and signoff process. • How should grounded commands be validated and authorized before use? A command may be correctly grounded in documentation yet remain unsafe, outdated, incompatible with the current design, or unauthorized under organizational policy. Script-generation systems evaluate syntax or execution behavior in specific tool environments [13, 31], while EDA-Debugger [91] applies an additional review stage and leaves final implementation to the user. It remains open how source validity, execution correctness, design constraints, access permissions, and change approval should be combined into a distinct admissibility decision before grounded commands modify an active project.

6

TOWARD A UNIFIED EDA AGENT COMMUNICATION PROTOCOL

The three boundary classes examined in Sections 3 to 5 reveal a structural interoperability gap. Existing general-purpose protocols support messaging, tool access, or workflow execution, but the surveyed literature does not reveal a shared EDA-specific protocol that jointly standardizes how agents discover compatible peers, exchange handoff messages, invoke tools, orchestrate multi-stage flows, and enforce IP boundaries. Each of these five dimensions is currently addressed through deployment-specific or system-specific mechanisms. The reviewed public vendor materials do not disclose a shared cross-vendor interchange format [14, 16, 18]. This section proposes a five-layer research agenda for an EDA Agent Communication Protocol (EACP), where a protocol refers to shared semantics, standardized formats, validation rules, and state transitions that agents and tools can implement independently. The five layers address agent discovery, handoff messaging, tool invocation, workflow orchestration, and security and IP protection. Each layer poses a core question, identifies the EDA-specific gap that keeps it open, and proposes the protocol capabilities needed to address it. Table 5 lists the five layers and the core question each addresses. Figure 4 illustrates the overall structure.

22

Table 5. Five-layer EACP research agenda. Layer

Core question

L1

(Agent discovery protocol) How do agents in a multi-vendor EDA environment find and verify compatible peers? (Agent message protocol) What structure must a handoff message carry for the receiving agent to act on it correctly? (Tool invocation protocol) How can agents invoke heterogeneous EDA tools through a shared typed interface with backend-specific adapters? (Workflow orchestration protocol) How do multiple agents compose into a reliable, recoverable multi-stage pipeline? (Security & IP protocol) How can sensitive process IP be protected and every agent action be made accountable?

L2 L3 L4 L5

L1: AGENT DISCOVERY PROTOCOL

L2: AGENT MESSAGE PROTOCOL

L3: TOOL INVOCATION PROTOCOL

L4: WORKFLOW ORCHESTRATION PROTOCOL

L5: SECURITY & IP PROTOCOL IP BOUNDARY

SYNTH Iterate P&R

RECEIVER

SENDER

SKILL

SIGNOFF

ALLOWED DISCOVER ACK

PEERS

MANIFEST FIELDS Identity

MESSAGE FIELDS Header Correlation

Endpoint

Compatibility

OPERATION FIELDS Operation

Action Payload

WORKFLOW FIELDS Executor

Signature

SECURITY FIELDS Authorization

Dependency

Precondition

Intent

Capability

CHECKPOINT / RESUME

Postcondition

Transition Checkpoint

Disclosure Protection

Execution

Recovery

Error

Termination

Backend

Retention Audit

Fig. 4. Overview of the five-layer EACP.

Shared reference types. EACP avoids redefining the same design context, artifact, evidence, identity, policy, and provenance information in every layer. It instead defines six shared reference types that may be carried or inspected by multiple layers: • ContextRef. It identifies the PDK, process node, operating corner, library set, tool environment, constraint set, and design revision under which a handoff remains valid. • ArtifactRef. It identifies a design, verification, workflow, command, or knowledge object through its type, version, location, content hash, and ownership metadata. • EvidenceRef. It identifies checker results, diagnostic records, QoR measurements, validator identities, and contract verdicts used to justify acceptance or rejection. • PrincipalRef. It identifies an agent, user, service, orchestrator, or tool adapter through an authenticated and organization-scoped identity. • PolicyRef. It identifies the authorization, confidentiality, disclosure, execution, and retention policies governing a handoff. • TraceRef. It links messages, tool calls, workflow events, approvals, and source records into a provenance chain. 23

These shared types are defined once by the protocol. Individual layers reference them without redefining their internal fields, allowing the same context, artifact, evidence, identity, policy, and trace to remain consistent across discovery, messaging, execution, orchestration, and review. 6.1

Layer 1: Agent Discovery Protocol

General-purpose discovery and tool-description formats do not encode the EDA-specific scope needed to determine whether an agent is compatible with a requested handoff. An orchestrator must verify not only that a discovered agent provides the required capability, but also that it accepts the relevant handoff object, supports the required contract, and operates under compatible process, library, constraint, and tool assumptions. Across the surveyed systems, process, tool, and constraint scope is typically embedded in prompts, wrappers, or experimental configurations rather than exposed through a shared discovery manifest [25, 27, 38, 40]. The Layer 1 agent discovery protocol addresses this gap through a registry or resolver and a versioned capability manifest. The manifest contains four Layer-specific fields: • Identity. It references the PrincipalRef of the agent and records the manifest version, provider, and credentials needed to authenticate the published capability. • Endpoint. It specifies the communication address and supported protocol bindings through which the agent may be contacted. • Capability. It declares the operations supported by the agent, the ArtifactRef types it accepts and produces, and the handoff contracts it can establish or evaluate. • Compatibility. It defines how an incoming ContextRef and applicable PolicyRef are evaluated against the agent’s supported process, library, constraint, tool, and deployment scope. Discovery proceeds through registration, candidate lookup, identity verification, compatibility negotiation, and dispatch. Rather than requiring exact equality across every scope property, the protocol should support version ranges, aliases, optional fields, and policy-governed exceptions, returning a structured verdict that distinguishes matched, mismatched, unknown, and policydependent conditions. Sensitive process information may be represented through opaque scope references or signed compatibility attestations. The manifest is analogous to general tool descriptions in Anthropic’s MCP [96] and the OpenAPI Specification [97], but extends them with EDA-specific artifact, contract, process, constraint, and policy semantics. 6.2

Layer 2: Agent Message Protocol

Layer 1 makes compatible agents discoverable but does not specify what a handoff message must preserve for the receiving component to interpret and act on it correctly. General-purpose frameworks provide transport envelopes and basic request structures [98], but they do not define EDA-specific semantics for process context, constraint versions, handoff objects, contract evidence, or design revisions. Receiving components must therefore reconstruct information that should have been preserved by the sender [3, 4]. The Layer 2 agent message protocol defines a shared, versioned envelope with five Layer-specific fields: • Header. It records the protocol version, schema version, message type, timestamp, sender and receiver PrincipalRef values, and the active ContextRef and PolicyRef values. • Correlation. It associates related requests, intermediate updates, results, errors, and cancellations through message identifiers, parent identifiers, idempotency keys, and a shared TraceRef. 24

• Intent. It records the originating design objective and the local subtask represented by the message. The session-level intent remains attached to derived interactions so that local actions can be traced to the original engineering goal. • Action. It identifies the operation requested from the receiving agent or tool, such as simulation, synthesis, rule checking, retrieval, or script generation. • Payload. It carries action-specific parameters and references to the transferred ArtifactRef objects. In result-bearing messages, the payload may also include returned artifacts and corresponding EvidenceRef values. The protocol distinguishes request, status, result, error, and cancel messages so that intermediate or failed outputs are not mistaken for accepted handoffs. A returned artifact closes the handoff only after the designated validator records the required verdict in its EvidenceRef. Longrunning EDA tasks also require asynchronous callbacks or polling, intermediate status reporting, timeout handling, and cancellation [3, 4]. Layer 2 carries protected context and policy references, while Layer 5 determines whether their underlying values are disclosed, masked, encrypted, or withheld. 6.3

Layer 3: Tool Invocation Protocol

Layers 1 and 2 make compatible agents discoverable and define the structure of their handoff messages, but neither specifies how agents invoke the heterogeneous EDA tools that produce and validate the exchanged artifacts. Existing tools expose results through structured design files, proprietary databases, native APIs, command-line output, and textual reports whose schemas and semantics vary across vendors and releases [4, 12]. Agents therefore depend on backend-specific wrappers and parsers that may become invalid when a tool version, report format, or execution environment changes [3, 4]. Inconsistent output representations also make it difficult to relate downstream results to their invocations and configurations [3, 91]. The Layer 3 tool invocation protocol defines a typed operation descriptor with seven Layerspecific fields: • Operation. It specifies the versioned operation name, namespace, and semantic definition independently of the vendor command used to implement it. • Signature. It defines the typed parameters, returned values, units, accepted and produced ArtifactRef types, and expected EvidenceRef values. • Precondition. It states the design state, required artifacts, tool mode, and ContextRef assumptions that must hold before invocation. • Postcondition. It states the expected state changes, produced artifacts, and validation properties after successful completion. • Execution. It defines side effects, idempotency, asynchronous behavior, cancellation, timeout handling, retry safety, and treatment of partial outputs. • Error. It defines structured failure categories, diagnostics, retryability, affected artifacts, and recovery options. • Backend. It identifies the adapter, supported tool versions, and translation rules used to map the standard operation to a vendor-specific interface. The protocol standardizes operation and result semantics rather than prescribing a complete catalog of EDA commands. Operations such as simulate(), synthesize(), and drc_check() may use the same descriptor structure, while additional domains define versioned namespaces. Backend adapters translate between the descriptor and an installed tool, preserving comparable units, artifact references, provenance, and error categories. Composed skills may reuse the same descriptor, but schema-conformant calls alone do not establish correctness. Their preconditions, 25

postconditions, dependencies, termination rules, and expected evidence must also be satisfied. The transport binding may use an SDK, REST, gRPC, or another implementation without changing the Layer 3 semantics. 6.4

Layer 4: Workflow Orchestration Protocol

Layers 1–3 enable peer discovery, structured messaging, and typed tool invocation, but they do not govern how agents, tools, and handoff objects compose into a reliable multi-stage workflow. Without explicit dependencies and transition conditions, downstream components cannot determine whether their inputs satisfy the required contracts, while failures may invalidate earlier artifacts or runtime state without triggering appropriate recovery [3, 4, 99]. General-purpose workflow languages such as CWL [100] and WDL [101] represent computational dependencies but do not directly encode EDA-specific handoff contracts, configuration fingerprints, or downstream validation. The Layer 4 workflow orchestration protocol defines a versioned workflow graph with six Layer-specific fields: • Executor. It identifies the agent, skill, or Layer 3 operation responsible for executing the node. • Dependency. It declares the incoming and outgoing ArtifactRef values, their required ContextRef, and the boundary and contract conditions associated with each handoff. • Transition. It defines the conditions for success, failure, iteration, alternative branching, and human escalation using applicable EvidenceRef values. • Checkpoint. It specifies whether validated state is committed and identifies the artifacts, evidence, trace state, and configuration fingerprint preserved at commit time. • Recovery. It defines the permitted retry, resume, rollback, branch-substitution, or restart actions after failure. • Termination. It defines the iteration budget and stopping conditions, including contract satisfaction, QoR convergence, resource exhaustion, unrecoverable failure, or human approval. The workflow graph may contain controlled feedback cycles because downstream evidence can revise upstream design or optimization decisions. Each cycle therefore requires an explicit iteration bound or termination condition, while every executed transition is recorded through a TraceRef. Recovery depends on the scope of failure. A local execution failure may permit retry, an invalid input may require rollback, and a downstream contract violation may return control to the node that produced the handoff. Each checkpoint stores validated artifacts, evidence, and a configuration fingerprint covering the design context, constraints, tools, environment, and upstream state. Resume is permitted only when the active context is compatible or the affected contracts are revalidated. 6.5

Layer 5: Security & IP Protocol

Layer 4 provides sequencing, validation, and recovery semantics, but a correctly orchestrated workflow does not by itself enforce authority boundaries or make agent actions accountable. EDA collaboration may involve foundries, design houses, IP vendors, tool providers, and external services governed by different trust domains. Process information therefore cannot be exchanged solely on the basis of technical compatibility [14, 16, 18, 102]. Agent-driven actions must also remain attributable to authenticated actors and supporting evidence [40, 103, 104]. Layer 5 interprets the shared identity, policy, artifact, context, evidence, and trace references used by the other layers and introduces five Layer-specific fields: • Authorization. It defines whether a PrincipalRef may discover a capability, inspect an artifact, invoke an operation, approve a transition, or modify an active project. 26

• Disclosure. It defines whether protected information is revealed, masked, encrypted, replaced by an opaque reference, or represented through a signed attestation. • Protection. It defines the confidentiality and integrity requirements for transmission, storage, and execution. • Retention. It defines storage duration, caching permissions, derivative-data restrictions, modeltraining restrictions, and deletion requirements. • Audit. It defines the signed and tamper-evident records needed to associate actions, evidence, approvals, and transitions with authenticated actors and trusted timestamps. Layer 5 applies these fields across discovery, messaging, invocation, and orchestration. A designhouse agent may receive characterized timing data without receiving underlying process models, while more sensitive tasks may execute inside a trusted environment and return only approved results [14, 16]. Audit records should be append-only, digitally signed, hash-linked, and periodically anchored externally. Their content depends on the boundary class. Stage-Bound records preserve modifications and checker evidence, Flow-Bound records preserve transitions, checkpoints, configurations, and downstream QoR, and Organization-Bound records connect retrieved facts and commands to their sources, policies, and approvals. Layer 5 therefore determines whether an otherwise technically valid handoff is authorized, appropriately disclosed, protected throughout its lifecycle, and admissible for organizational reuse. 7

CONCLUSION

Agentic EDA systems are increasingly capable within individual design stages, yet stage-local capability does not guarantee that outputs remain usable across stage, flow, and organization boundaries. This survey organizes more than 80 agentic EDA systems around a boundary-centered taxonomy that asks what must remain valid at each handoff rather than what task a system automates. Three qualitatively distinct boundary classes emerge (Stage-Bound, Flow-Bound, and Organization-Bound), each characterized by its handoff contracts, handoff objects, coordination mechanisms, and open questions that current systems leave unresolved. To address the gaps each class exposes, the survey proposes a five-layer EDA Agent Communication Protocol (EACP): agent discovery protocol (L1), agent message protocol (L2), tool invocation protocol (L3), workflow orchestration protocol (L4), and security & IP protocol (L5). The long-term goal is not merely stronger isolated EDA agents, but design artifacts, workflow records, and decisions that remain portable, auditable, and admissible across stage, flow, and organization boundaries. REFERENCES [1] Y. Lin, S. Dhar, W. Li, H. Ren, B. Khailany, and D. Z. Pan, “Dreamplace: Deep learning toolkit-enabled GPU acceleration for modern VLSI placement,” in Proc. DAC, 2019, pp. 1–6. [2] S. Liu, Z. Wang, F. Liu, Y. Lin, B. Yu, and M. Wong, “Concurrent sign-off timing optimization via deep steiner points refinement,” in Proc. DAC. IEEE, 2023, pp. 1–6. [3] H. Wu, Z. He, X. Zhang, X. Yao, S. Zheng, H. Zheng, and B. Yu, “ChatEDA: A large language model powered autonomous agent for eda,” TCAD, vol. 43, no. 10, pp. 3184–3197, 2024. [4] A. Ghose, A. B. Kahng, S. Kundu, and Z. Wang, “ORFS-Agent: Tool-using agents for chip design optimization,” in Proc. MLCAD. IEEE, 2025, pp. 1–13. [5] L. Shi, M. Kazda, B. Sears, N. Shropshire, and R. Puri, “Ask-EDA: A design assistant empowered by llm, hybrid rag and abbreviation de-hallucination,” in Proc. LAD. IEEE, 2024, pp. 1–5. [6] Q. Sun, T. Chen, S. Liu, J. Chen, H. Yu, and B. Yu, “Correlated multi-objective multi-fidelity optimization for hls directives design,” TODAES, vol. 27, no. 4, pp. 1–27, 2022. [7] Z. He, Y. Pu, H. Wu, T. Qiu, and B. Yu, “Large language models for eda: Future or mirage?” TODAES, vol. 30, no. 6, pp. 1–53, 2025. [8] 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,” TODAES, vol. 30, no. 3, pp. 1–21, 2025. 27

[9] Y. Tsai, M. Liu, and H. Ren, “RTLfixer: Automatically fixing RTL syntax errors with large language model,” in Proc. DAC, 2024, pp. 1–6. [10] J. Niu, X. Liu, D. Niu, X. Wang, Z. Jiang, and N. Guan, “ReChisel: Effective automatic chisel code generation by llm with reflection,” in Proc. DAC. IEEE, 2025, pp. 1–7. [11] Y. Zhao, H. Zhang, H. Huang, Z. Yu, and J. Zhao, “Mage: A multi-agent engine for automated rtl code generation,” in Proc. DAC. IEEE, 2025, pp. 1–7. [12] 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 Proc. DAC, 2024, pp. 1–6. [13] H. Zheng, H. Wu, and Z. He, “Chatls: Multimodal retrieval-augmented generation and chain-of-thought for logic synthesis script customization,” in Proc. DAC. IEEE, 2025, pp. 1–7. [14] Synopsys, “Agentic AI: Automating Engineering Workflows with AI Agents,” https://www.synopsys.com/ai/agenticai.html, 2026, accessed: 2026-04-30. [15] ——, “Synopsys Outlines Vision for Engineering the Future,” https://investor.synopsys.com/news/news-details/2026/ Synopsys-Outlines-Vision-for-Engineering-the-Future/default.aspx, Mar. 2026. [16] Cadence Design Systems, “Cadence ChipStack AI Super Agent: Agentic AI for SoC Design and Verification,” https: //www.cadence.com/en_US/home/resources/product-briefs/cadence-chipstack-ai-super-agent-pb.html, 2026. [17] ——, “Cadence and NVIDIA Expand Partnership to Reinvent Engineering for the Age of AI and Accelerated Computing,” https://login.cadence.com/content/cadence-www/global/zh_CN/home/company/newsroom/press-releases/pr/ 2026/cadence-and-nvidia-expand-partnership-to-reinvent-engineering.html, Apr. 2026. [18] Siemens Digital Industries Software, “Siemens Launches Fuse EDA AI Agent for Automation Across Semiconductor, 3D IC and PCB System Workflows,” https://news.siemens.com/en-us/siemens-fuse-eda-ai-agent/, Mar. 2026. [19] ——, “Questa One Agentic Toolkit,” https://www.siemens.com/en-us/products/ic/questa-one/agentic-toolkit/, 2026. [20] A. Allam, Y. Mansour, and M. Shalan, “Asic-agent: An autonomous multi-agent system for asic design with benchmark evaluation,” in Proc. ICLAD. IEEE, 2025, pp. 23–29. [21] Z. He, Y. Pu, H. Wu, Y. Qin, T. Qiu, and B. Yu, “Large language models for eda: From assistants to agents,” Found. Trends EDA, vol. 14, no. 4, pp. 295–314, 2025. [22] Z. Zang, Y. Song, A. Wang, B. W.-K. Ling, Q. Sun, Z. Lei, F. Yang, C. Zhuo, and J. Luo, “The dawn of agentic eda: A survey of autonomous digital chip design,” arXiv preprint arXiv:2512.23189, 2025. [23] T.-H. Chi, C. Mackin, L. Shi, P. Vijayaraghavan, H. Tsai, and E. Degan, “Rtlexplain: A structured approach to rtl code summarization and question answering for medium-to-large designs using llms,” in Proc. MLCAD. IEEE, 2025, pp. 1–7. [24] 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,” in Proc. AAAI, vol. 39, no. 1, 2025, pp. 300–307. [25] Y. Lai, S. Lee, G. Chen, S. Poddar, M. Hu, D. Z. Pan, and P. Luo, “Analogcoder: Analog circuit design via training-free code generation,” in Proc. AAAI, vol. 39, no. 1, 2025, pp. 379–387. [26] B. Liu, H. Zhang, X. Gao, Z. Kong, X. Tang, Y. Lin, R. Wang, and R. Huang, “Layoutcopilot: an llm-powered multiagent collaborative framework for interactive analog layout design,” TCAD, vol. 44, no. 8, pp. 3126–3139, 2025. [27] L. T. Fu, J. Zhou, S. Ren, M. Zhang, J. Xiong, H. Jiang, N. Guan, X. Wang, and J. Yang, “Chatsva: Bridging sva generation for hardware verification via task-specific llms,” in Proc. DAC, 2026. [28] F. Firouzi, S. S. R. Nakkilla, C. Fu, S. Banerjee, J. Talukdar, and K. Chakrabarty, “Llm-aid: Leveraging large language models for rapid domain-specific accelerator development,” in Proc. ICCAD, 2024, pp. 1–9. [29] J. Dou, J. Zhang, B. Ye, Y. Shen, X. Li, Y. Shi, Y. Zhang, and Y. Sun, “Malts: A multi-agent large language model-based layout-to-tcad structure synthesizer,” in Proc. ISEDA. IEEE, 2025, pp. 795–800. [30] M. Abdelatty, J. K. Rosenstein, and S. Reda, “Chipxplore: Natural language exploration of hardware designs and libraries,” in Proc. ICLAD. IEEE, 2025, pp. 51–60. [31] Y. Rui, Y. Li, R. Wang, R. Chen, Y. Zhu, Z. Di, X. Wang, and M. Ling, “Chatcl: Llm-based multi-agent RAG framework for tcl script generation,” in Proc. ISEDA. IEEE, 2025, pp. 736–742. [32] V. K. Gupta, A. Yadav, M. Fujita, and B. Kumar, “LLM-aided front-end design framework for early development of verified RTLs,” in Proc. ATS. IEEE, 2024, pp. 1–6. [33] S. Ranga, R. Mao, D. Bhattacharjee, E. Cambria, and A. Chattopadhyay, “RTL agent: An agent-based approach for functionally correct HDL generation via llms,” in Proc. ATS. IEEE, 2024, pp. 1–6. [34] Z. Chen, J. Huang, Y. Liu, F. Yang, L. Shang, D. Zhou, and X. Zeng, “Artisan: Automated operational amplifier design via domain-specific large language model,” in Proc. DAC, 2024, pp. 1–6. [35] Y. Yin, Y. Wang, B. Xu, and P. Li, “Ado-llm: Analog design bayesian optimization with in-context learning of large language models,” in Proc. ICCAD, 2024, pp. 1–9. [36] K. Xu, J. Sun, Y. Hu, X. Fang, W. Shan, X. Wang, and Z. Jiang, “MEIC: Re-thinking RTL debug automation using LLMs,” in Proc. ICCAD, 2024, pp. 1–9.

28

[37] C.-T. Ho and H. Ren, “Large language model (llm) for standard cell layout design optimization,” in Proc. LAD. IEEE, 2024, pp. 1–6. [38] T. Yang, B. Li, Y. Li, W. Mao, and G. Han, “Circuit-agent: A large language model based circuit agent framework for analog/mixed-signal circuit design automation,” in Proc. AICAS. IEEE, 2025, pp. 1–5. [39] L. Chen, R. Chen, S. Hu, X. Yao, Z. Tang, S. Kai, S. Xu, M. Yuan, J. Hao, B. Yu et al., “Pcbagent: An agent-based framework for high-density printed circuit board placement,” in Proc. ASP-DAC, 2025, pp. 781–787. [40] Y. Hu, J. Ye, K. Xu, J. Sun, S. Zhang, X. Jiao, D. Pan, J. Zhou, N. Wang, W. Shan et al., “Uvllm: An automated universal rtl verification framework using llms,” in Proc. DAC. IEEE, 2025, pp. 1–7. [41] B. Yao, N. Wang, J. Zhou, X. Wang, H. Gao, Z. Jiang, and N. Guan, “Location is key: Leveraging llm for functional bug localization in verilog design,” in Proc. DAC. IEEE, 2025, pp. 1–7. [42] H. Qin, J. Kou, L. Zhang, W. Kang, and W. W. Xing, “Multi-agent yield analysis for circuit design,” in Proc. DAC. IEEE, 2025, pp. 1–7. [43] M. ul Islam, H. Sami, P.-E. Gaillardon, and V. Tenace, “Eda-aware rtl generation with large language models,” in Proc. DATE. IEEE, 2025, pp. 1–6. [44] B. Huang, C. W. Ng, and P. F. Lam, “Rtl designer: An ai-powered platform with end-to-end workflow for automated rtl generation,” in Proc. EIECT. IEEE, 2025, pp. 241–250. [45] Z. Fang, R. Chen, Z. Yang, Y. Guo, H. Dai, and L. Wang, “Lintllm: An open-source verilog linting framework based on large language models,” in Proc. GLSVLSI, 2025, pp. 673–680. [46] K. Tasnia, A. Garcia, T. Farheen, and S. Rahman, “Veriopt: Ppa-aware high-quality verilog generation via multi-role llms,” in Proc. ICCAD. IEEE, 2025, pp. 1–9. [47] K. S. NS and P. Li, “Ai analog circuit design agents: On knowledge extraction and transfer with knowledge graphs,” in Proc. ICCAD. IEEE, 2025, pp. 1–9. [48] M. Ahmadzadeh, K. Chen, and G. Gielen, “Anaflow: Agentic llm-based workflow for reasoning-driven explainable and sample-efficient analog circuit sizing,” in Proc. ICCAD. IEEE, 2025, pp. 1–7. [49] M. Z. S. Khan, N. Mashnoor, M. Akyash, K. Azar, and H. Kamali, “Sage-hls: Syntax-aware ast-guided llm for high-level synthesis code generation,” in Proc. ICCD. IEEE, 2025, pp. 574–581. [50] J. Talukdar, A. Seth, S. Banerjee, F. Firouzi, and K. Chakrabarty, “Malls: Multi-agent llms for synthetic hardware vulnerability generation and detection,” in Proc. ICCD. IEEE, 2025, pp. 782–789. [51] D. V. Kochar, H. Wang, A. P. Chandrakasan, and X. Zhang, “Ledro: Llm-enhanced design space reduction and optimization for analog circuits,” in Proc. ICLAD. IEEE, 2025, pp. 141–148. [52] P.-H. Chen, Y.-S. Lin, W.-C. Lee, T.-Y. Leu, P.-H. Hsu, A. Dissanayake, S. Oh, and C.-S. Chiu, “Menter: A fully-automated multi-agent workflow for end-to-end rf/analog circuits netlist design,” in Proc. ICLAD. IEEE, 2025, pp. 124–132. [53] Z. Yu, M. Liu, M. Zimmer, Y. Celine, Y. Liu, and H. Ren, “Spec2rtl-agent: Automated hardware code generation from complex specifications using llm agent systems,” in Proc. ICLAD. IEEE, 2025, pp. 37–43. [54] A. E. Abdelmalak, M. A. Elsayed, I. Torunoglu, and D. Abercrombie, “An ast-guided llm approach for svrf code synthesis,” in Proc. ICLAD. IEEE, 2025, pp. 68–76. [55] Z. Mi, R. Zheng, H. Zhong, Y. Sun, S. Kneeland, S. Moitra, K. Kutzer, and Z. X. S. Huang, “Coopetitivev: Leveraging llm-powered coopetitive multi-agent prompting for high-quality verilog generation,” ICML Workshop, 2025. [56] Q. Luo, Y. Lei, K. Wu, Y. Cao, and C. Liu, “Autofsm: A multi-agent framework for fsm code generation with ir and systemc-based testing,” in Proc. ICONIP. Springer, 2025, pp. 417–431. [57] W. Chen, C. Liu, W. Huang, J. Lyu, M. Yang, Y. Du, L. Du, and J. Yang, “Analogtester: A large language model-based framework for automatic testbench generation in analog circuit design,” in Proc. ISEDA. IEEE, 2025, pp. 201–207. [58] H. Zhang, S. Sun, Y. Lin, R. Wang, and J. Bian, “Analogxpert: Automating analog topology synthesis by incorporating circuit design expertise into large language models,” in Proc. ISEDA. IEEE, 2025, pp. 772–777. [59] C.-C. Chang, C.-T. Ho, Y. Li, Y. Chen, and H. Ren, “Drc-coder: Automated drc checker code generation using llm autonomous agent,” in Proc. ISPD, 2025, pp. 143–151. [60] L. Krupp, M. Schöffel, E. Biehl, and N. Wehn, “Cradle: Conversational rtl design space exploration with llm-based multi-agent systems,” in Proc. ISOCC. IEEE, 2025, pp. 1–2. [61] K. Thorat, J. Zhao, Y. Liu, A. Hasan, H. Peng, X. Xie, B. Lei, and C. Ding, “Llm-verippa: Power, performance, and area optimization aware verilog code generation with large language models,” in Proc. MLCAD. IEEE, 2025, pp. 1–7. [62] J. Shen, Z. Chen, J. Zhuang, J. Huang, F. Yang, L. Shang, Z. Bi, C. Yan, D. Zhou, and X. Zeng, “Atelier: An automated analog circuit design framework via multiple large language model-based agents,” TCAD, 2025. [63] N. K. Somayaji and P. Li, “Llm-uso: Large language model-based universal sizing optimizer,” TCAD, 2025. [64] C. Liu and D. Chitnis, “Eesizer: Llm-based ai agent for sizing of analog and mixed signal circuit,” TCAS-I, 2025. [65] C. Li, C. Chen, Y. Pan, W. Xu, Y. Liu, K. Chang, Y. Wang, M. Wang, H. Li, Y. Han et al., “Autosilicon: Scaling up rtl design generation capability of large language models,” TODAES, vol. 30, no. 6, pp. 1–21, 2025.

29

[66] Z. Wu, Z. Yang, Z. Yang, Z. Chen, L. Shang, and F. Yang, “Chatarch: A knowledge-driven graph-of-thought llm framework for processor architecture optimization,” TODAES, vol. 31, no. 2, pp. 1–26, 2025. [67] M. Tang, W. Chen, L. Wu, L. Huang, and K. Zeng, “Chatdse: A zero-shot microarchitecture design space explorer powered by GPT4.0,” TODAES, vol. 30, no. 4, pp. 1–24, 2025. [68] K. Chang, W. Zhu, K. Wang, X. He, N. Yang, Z. Chen, D. Jin, C. Li, Y. Zhou, H. Yan et al., “A data-centric chip design agent framework for verilog code generation,” TODAES, vol. 30, no. 6, pp. 1–27, 2025. [69] X. Yao, W. Zhao, Q. Sun, C. Zhuo, and B. Yu, “High-level synthesis directives design optimization via large language model,” TODAES, vol. 30, no. 5, pp. 1–24, 2025. [70] E. B. E. Reddy, S. Bhattacharyya, A. Sarmah, F. Nongpoh, K. Maddala, and C. Karfa, “Lhs: Llm assisted efficient high-level synthesis of deep learning tasks,” TODAES, vol. 30, no. 6, pp. 1–27, 2025. [71] S. Swaroopa, R. Mukherjee, A. Debnath, and R. S. Chakraborty, “Evaluating large language models for automatic register transfer logic generation for combinational circuits via high-level synthesis,” Found. Trends EDA, vol. 14, no. 4, pp. 315–337, 2025. [72] Z. Chen, K. Chang, Z. Li, C. Li, X. He, C. Chen, M. Wang, H. Xu, Y. Han, H. Li, and Y. Wang, “Chipseek: Optimizing verilog generation via eda-integrated reinforcement learning,” in Proc. ACL, 2026. [73] C.-M. Chang, P. Vijayaraghavan, A. Jadhav, C. Mackin, H. Tsai, V. Mukherjee, and E. Degan, “Codmas: A dialectic multi-agent collaborative framework for structured rtl optimization,” in Proc. EACL, 2026, pp. 777–788. [74] K. Min, K. Cho, J. Jang, and S. Kang, “Revolution: An evolutionary framework for rtl generation driven by large language models,” in Proc. ASP-DAC. IEEE, 2026, pp. 282–288. [75] Y. Wei, Z. Huang, L. He, L. Huang, T.-J. Lin, and W. W. Xing, “Vflow: Discovering optimal agentic workflows for verilog generation,” in Proc. ASP-DAC. IEEE, 2026, pp. 355–361. [76] H. Yang and H. Ren, “Code, not canvas: Multi-agent layout generation beyond vision models,” in Proc. ASP-DAC. IEEE, 2026, pp. 632–638. [77] G.-W. Wan, S. Su, J. Zhang, S. Z. Wong, M. Xing, L. Ji, Z. Jiang, X. Wang, and J. Yang, “Chattest: Coverage-enhanced testbench generation for agile hardware verification with llms,” in Proc. DATE, 2026, pp. 1–7. [78] L. T. Fu, Q. Wang, S. Ren, M. Zhang, S. Yang, J. Liu, and X. Wang, “Automated sva generation with llms,” in Proc. ISEDA, 2026. [79] Y. Lai, S. Poddar, S. Lee, G. Chen, M. Hu, B. Yu, P. Luo, and D. Z. Pan, “Analogcoder-pro: Unifying analog circuit generation and optimization via multi-modal llms,” TCAD, 2026. [80] Z. Wei, Z. Kong, Y. Wang, D. Z. Pan, and X. Tang, “Toposizing: An llm-aided framework of topology-based understanding and sizing for ams circuits,” TCAD, 2026. [81] P. Tremuel, F. Benites, C. Würsch, U. Hügel, F. Wolf, A. Büchel, and E. Gavves, “cgeneda: Code-generation for electronic design optimization,” TODAES, 2026. [82] C. R. Pamnani, “Ai-driven automation for digital hardware design: A multi-agent generative approach,” in Proc. FAIML, 2025, pp. 26–30. [83] J. Tang, J. Qin, N. Xu, P. S. Nalla, Y. Cao, Y. K. Zhao, and C. Ding, “Mahl: Multi-agent llm-guided hierarchical chiplet design with adaptive debugging,” in Proc. ICCAD. IEEE, 2025, pp. 1–9. [84] W. Zhao, Y. Gao, L. Shen, and Q. Luo, “Socdev: Soc design automation through tcl code generation via llm-based agents,” in Proc. IJCNN. IEEE, 2025, pp. 1–8. [85] P. Yan, Q. Zhi, L. Liu, and T. Jia, “Gensoc: A multi-agent-assisted soc generation methodology leveraging open-source hardware,” in Proc. ISLPED. IEEE, 2025, pp. 1–7. [86] Z. Chao, R. Zhang, F. Gu, H. Lyu, B. Sun, W. Li, Z. Liu, J. Mu, J. Ye, X. Li et al., “Tesla: Testability enhancement for shift-left automation via multi-llm collaboration,” in Proc. ITC. IEEE, 2025, pp. 45–52. [87] H. Wu, H. Zheng, Z. He, and B. Yu, “Divergent thoughts toward one goal: Llm-based multi-agent collaboration system for electronic design automation,” in Proc. NAACL, 2025, pp. 1710–1721. [88] C. Yu and H. Ren, “Autonomous evolution of eda tools: Multi-agent self-evolved abc,” in Proc. DAC, 2026. [89] Y. Pu, Z. He, T. Qiu, H. Wu, and B. Yu, “Customized retrieval augmented generation and benchmarking for eda tool documentation qa,” in Proc. ICCAD, 2024, pp. 1–9. [90] Y. Pu, Z. He, S. Lin, J. Qin, X. Zhang, H. Han, H. Zheng, Y. Jiang, C. Zhuo, Q. Sun et al., “Mm-grade: A multi-modal eda tool documentation qa framework leveraging retrieval augmented generation,” in Proc. ICCAD. IEEE, 2025, pp. 1–9. [91] J. Li, S.-Z. Wong, G.-W. Wan, X. Wang, and J. Yang, “Eda-debugger: An llm-based framework for automated eda runtime issue resolution,” in Proc. ISQED. IEEE, 2025, pp. 1–7. [92] C. Xing, S. Wong, X. Wan, Y. Lu, M. Zhang, Z. Ma, L. Qi, Z. Li, N. Guan, Z. Jiang et al., “Chipmind: Retrieval-augmented reasoning for long-context circuit design specifications,” in Proc. AAAI, vol. 40, no. 2, 2026, pp. 1337–1345. [93] P. Abbineni, S. Aldowaish, C. Liechty, S. Noorzad, A. G. Ghalati, and M. Fayazi, “Muallm: A multimodal large language model agent for circuit design assistance with hybrid contextual retrieval-augmented generation,” in Proc. ASP-DAC. IEEE, 2026, pp. 646–652.

30

[94] J. Thangellamudi, R. Saravanan, and S. M. P. Dinakarrao, “Verirag: A knowledge graph-augmented rag for verilog and assertion generation,” in Proc. ASP-DAC. IEEE, 2026, pp. 105–111. [95] Y. Qin, Y. Pu, T. Qiu, Z. He, and B. Yu, “Infusing eda knowledge into llm systems: An information-source perspective,” in Proc. ISPD, 2026, pp. 112–120. [96] Anthropic, “Model context protocol specification,” https://modelcontextprotocol.io/specification/2025-11-25, 2025. [97] OpenAPI, “Specification,” https://spec.openapis.org/oas/v3.2.0.html, 2025. [98] Z. Guo, B. Xu, C. Zhu, W. Hong, X. Wang, and Z. Mao, “Mcp-agentbench: Evaluating real-world language agent performance with mcp-mediated tools,” in Proc. AAAI, vol. 40, no. 37, 2026, pp. 30 888–30 896. [99] T. W. Malone and K. Crowston, “The interdisciplinary study of coordination,” CSUR, vol. 26, no. 1, pp. 87–119, 1994. [100] P. Amstutz, M. R. Crusoe, N. Tijanić, B. Chapman, J. Chilton, M. Heuer, A. Kartashov, D. Leehr, H. Ménager, M. Nedeljkovich et al., “Common workflow language, v1.0,” 2016. [101] OpenWDL contributors, “Workflow description language (WDL),” https://github.com/openwdl/wdl, 2024. [102] J. Talukdar, S. Banerjee, and F. Firouzi, “Llm-sec: Closing the security loop using llms for hardware design,” in Proc. COINS. IEEE, 2025, pp. 1–6. [103] T. Li, C. Chu, Y. Zheng, B. Zhang, N. Z. Gong, and C. Xiao, “A2asecbench: A protocol-aware security benchmark for agent-to-agent multi-agent systems,” in Proc. ICLR, 2026. [104] W. Fu, Y. Wang, Z. Lu, X. Guo, and G. Qu, “Hada: Leveraging multi-source data to train large language models for hardware security assertion generation,” in Proc. MLCAD. IEEE, 2025, pp. 1–7.

31

Related documents

• Experimental Settings in LLM-Based Program Repair: A Study of Inputs, Tool Access, Feedback, and Validation#965480
• A11yLTLNav: Automatic Detection of Accessibility Navigation Failures#965481
• Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations#965482
• A Large-Scale Empirical Study of Quality Assurance Practices and Gaps in AI Agents#965483
• CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts#965484