1 of 23

OpenROAD and the Era of Agents

Andrew B. Kahng��University of California, San Diego

abk@ucsd.edu

1

2 of 23

Outline

The agentic era in EDA

Case studies in OpenROAD

Emerging challenges for agentic open-source EDA

2

3 of 23

The agentic lever (LLMs 🡪 Agents 🡪 R&D Acceleration )

Scaling is design-based
Tools are bespoke
Ecosystem is consolidated
Optimization imperative = do better and faster, with less

From “EDA tools” to “EDA R&D collaborators”

IC design �optimization �(PPA, schedule, cost)

LLMs + tool use

EDA = tools �(synthesis, P&R, STA, etc.)

(Human +) Agentic R&D loop�(read logs, tweak params, edit code, check/eval + iterate)

Multi-hours/multi-days reasoning

Comprehend large codebases

Invoke tool commands

Self iteration with feedback

LLMs in EDA (2026 ++)

3

Why the rush to agents in EDA? The answer lies in EDA’s unique nature. Scaling is now design-based – and it’s all about optimization.. The tools are bespoke – they encode decades of heuristic know-how, but they are hard to generalize, and hard to adapt and tune.

[CLICK] This is why agents are so interesting. LLMs can already answer complex EDA queries and automate complex tasks. The new lever is that now an agent can sit inside the R&D loop. It can read logs, call tools, adjust parameters, edit code, run flows, and learn from feedback iteratively over many hours or days or even weeks.

[CLICK] So marrying tool-using agents with EDA tools enables a true agentic R&D loop: eventually, the slow human steps will be phased out, and the end-state limiters will be the environment and the tool latencies.

[CLICK] The transition is from EDA tools being passive executables to EDA tools plus agents being R&D collaborators.

4 of 23

From assistance to autonomy: two levels

Fact: Agents (in EDA) will operate across differing levels of abstraction

Abstraction determines search space, feedback signal, and risk
Open-source EDA is the perfect (and our only) testbed !!!

Two levels (~patterns)

Code-level agents modify algorithmic structure (source code) �🡨 “Improve the global swap operator in the dpl module of OpenROAD”
Flow-level agents modify control variables (tool flow, parameters, objectives) �🡨 “Minimize ECP with < 2% area/power/PDP degradation by tuning ORFS configs”

Is the agent reasoning about heuristics (code and operators) or about � policies (parameters and sequencing)? (Inevitably, agents will reason about both!)

4

5 of 23

OpenROAD as a foundation for agentic EDA research

Code-level��GR-evolve 🡪 grt��HELIX 🡪 dpl, gpl��AuDoPEDA 🡪 dpl, gpl, rsz

Flow-level��ORFS-Agent �🡪 flow knobs

Assistants ��OR-Assistant, OpenROAD-Agent 🡪 scripts + user queries�

Open code

Open APIs

Open benchmarks

“~13% WL/ECP gains, 40% fewer iterations”

94% pass-rate vs. 0% for foundational models”

Up to 9% HPWL, 23% RWL reduction across 2 PDKs

5

6 of 23

Three frontiers of recent progress in OpenROAD

“~40% fewer iterations than autotuners”

“~19% power gains”

“~9% HPWL gains”

Treat EDA tools as black-boxes; tune parameters and orchestrate flows
ORFS-Agent (UCSD) OpenROAD-Agent (ASU) ORAssistant (PII)
Algorithms unchanged; agents learn the policy

Agents can read, edit, compile and benchmark across multi-language codebases
AuDoPEDA (UCSD)
Algorithms change; formal verification; closed-loop guardrails

Per-design code evolution; tool specializes to the workload
HELIX (UCSD)�GR-Evolve (ASU)
Algorithms change; one tool per design vs. one tool for all designs

Flow tuners

Repo-scale coding

Bespoke, design-adaptive tools

6

Finally, we can classify research progress with OpenROAD according to three frontiers.

The first frontier is flow tuning. Here, the agent treats the EDA tools as black boxes. It [CLICK] does not change the algorithms inside OpenROAD; it learns how to configure the flow. For example, ORFS-agent finds good QoR with 40% fewer iterations than Bayesian autotuners.

The second frontier is repository-scale coding where the agent can read [CLICK] *and edit* source, compile, and benchmark across an entire codebase (such as OpenROAD’s). This is hard because reward is built from constraints and objectives: the diff must compile, and it must improve QoR. AuDoPEDA from UCSD is a recent example.

The third frontier is bespoke, design-adaptive tools. Now we go beyond having one EDA tool trying to handle all designs: the agent [CLICK] evolves code for a particular task and design context. HELIX from my group and GR-Evolve from Arizona State are two examples. So this is really quite radical: the tool SPECIALIZES ITSELF to the design.

631/1814 5:47

�

7 of 23

Outline

The agentic era in EDA

Case studies in OpenROAD

Emerging challenges for agentic open-source EDA

7

8 of 23

Evolving placement and routing in OpenROAD

Synthesis

Floorplan

GPL

DPL

CTS

GRT

DRT

Coding evolution targets

HELIX

GR-Evolve

Attributes	HELIX (placement) – UCSD	GR-Evolve (routing) – ASU
Target	Global + detailed placement (gpl, dpl)	Global routing (grt)
Method	(μ+λ) evolutionary search with literature-guided operators	Stateless agentic loop with persistent QoR history
Knowledge base	97 papers + documentation + pseudocode + parameter list	Distilled router summaries + source
Key results	9% HPWL and 23% RWL (max) �4.5% / 5.6% geomean	8.7% post-DR WL (max)

8

9 of 23

Repository-grounded coding agents for OpenROAD

Repo graph + documentation

Literature-grounded planning

Plan localization �(map plan to edit surfaces)

Autonomous execution loop �(apply diffs, build, run flow, measure QoR)

Formal diff checking �(Lean; Aristotle; AXLE)

Target	Module(s)		Diff scope
Routed wirelength	dpl	-5.4%	11 files, ~1k LoC
Effective clock period	gpl, rsz	-10.0%	11 files, ~330 LoC
Total power	rsz	-19.4%	9 files, ~1k Loc

Removing any single stage dramatically reduces valid diff-rate!

No execution loop

Full system

No documentation

No formal gate

No localization

No planning

92/100

54/100

44/100

41/100

37/100

26/100

Valid diffs out of 100 trials

https://arxiv.org/abs/2601.06268

9

This next example is AuDoPEDA, a repo-grounded coding agent for OpenROAD.

The key here is that editing an EDA codebase is not just a code-generation task. The agent must understand the repo structure, map a high-level optimization idea to the right edit surface, make a valid change, compile it, run the flow, and then interpret QoR, and ITERATE.

So the pipeline on the left runs through a repo graph and documentation step, literature-grounded planning, plan localization, autonomous execution, and formal or semi-formal diff checking. A lot of scaffolding supports the LLM agent.

At top right, you see improvements from the targeted diffs for routed wirelength, effective clock period, and power. And, [CLICK] ablations show how removing any one stage sharply reduces the number of valid diffs. So the agentic EDA success does depend on smart scaffolding – not just a stronger model.

// PR 9038 is the first-ever autonomously-created diff that passed human maintainers’ review and is now in OpenROAD.

10 of 23

ORFS-agent – LLM-driven flow autotuning

Design flow tuning is high-dimensional

1000s (actually 10000s) of knobs in RTL-to-GDS

Plain Bayesian Optimization struggles – weak domain priors; poor high-D scaling
Key idea: LLM-driven flow autotuner 🡪 ORFS-agent

Read logs; reason in context; interpret bottlenecks; propose structured parameter updates; iterate with tool feedback

Comparison of ORFS-agent and OR-AutoTuner w.r.t. wirelength and ECP

Normalization: Results with OR-AT4 params and 375 iterations set as 1.0

Baseline: OR-AT �(4 vars, 375 iters) ≡ 1.0

ORFS-agent uses ~40% fewer iterations, iso-QOR

Also: ≈ 13% gains in WL or ECP (single-objective) �(details: MLCAD25 paper)

https://arxiv.org/abs/2506.08332

10

11 of 23

Improving a SOTA Hypergraph Partitioner (OpenROAD/par)

TritonPart = SOTA hypergraph partitioner (> hMETIS, KaHyPar)
Has ILP “boundary optimization” step (with CPLEX or OR-Tools)
Autonomous AI diff “lowers the variance” of solver step
Substantial wins over TritonPart
Even with the weaker OR-Tools solver, finds world’s best-ever solutions!

Kahng talk 20251020

Titan23 suite, LLM-evolved diff

Cut reduction (%) vs. TritonPart

K = 2

K = 3

K = 4

11

And fourth: Min-cut hypergraph partitioning is basic to divide and conquer. My group has had the state of the art in the field, off and on, for roughly the past quarter century.

TritonPart from 2023 is /par in OpenROAD today. And in TritonPart, there is a key step called boundary optimization where an ILP solver – such as CPLEX or OR-Tools – is called.

And the agent figured out a better way to set up and orchestrate these ILP calls!

[CLICK] These are percentage cutsize reductions on the Titan23 benchmark suite – more to the right means a bigger reduction. So this tweak can enable massive cutsize reductions – and [CLICK] even using the weaker open-source ILP solver, OR-Tools, quite a few world’s best-ever cutsizes (highlighted with yellow here) are found.

For someone who’s worked on VLSI partitioning for three-plus decades – this is just nuts.

Today there’s a third generation of this engine called FastPart, that adapts to a given runtime budget – it matches state of the art cutsizes with order of magnitude speedups. *** 1201/1814 ***

12 of 23

Outline

The agentic era in EDA

Case studies in OpenROAD

Emerging challenges for agentic open-source EDA

12

13 of 23

Challenge 1: validation & evaluation

Agents are non-deterministic; flows are slow and expensive

Reproducibility & traceability – same prompt, different code
Cost: minutes to hours per RTL-to-GDS candidate
Improvements at GR / placement may only show after detailed routing

What “correct” means is no longer obvious

DRC-clean is necessary; not sufficient
Multi-objective: WL, timing, power, area, runtime
Generalization across designs and PDKs

What we need

Standardized testbeds: ORFS, MacroPlacement, etc.
Hard gates: DRC, build, regression tests – reject before scoring
Formal contracts where possible: Lean / SMT / static analysis
Statistical rigor: seed sweeps, confidence intervals, ablations

13

The first challenge is validation and evaluation.�

Agents are non-deterministic, and EDA flows are slow. The same prompt can produce different code, and the RTL-to-GDS flow takes hours to days. And, a change that looks good after placement or global routing may fail after detailed routing. SO: Rewards are hierarchical and delayed.�

[CLICK] Then, defining a “correct” diff is not simple. DRC-clean is necessary, but not sufficient. We care about wirelength, timing, power, area, runtime, robustness, and generalization. SO: Constraints and careabouts live in some lexicographic order.

[CLICK] So what we NEED is evaluation infrastructure: standardized testbeds and hard safety gates (build, or DRC, or regressions) to have reject-before-scoring mechanisms.

We’ll need formal contracts or static checks. And statistical rigor – starting with seed sweeps, confidence intervals, and ablations.

14 of 23

Challenge 2: humans + agents; IP & creators’ rights

Where does the human belong in the loop?

Objective definition, trade-offs, safety -- not API debugging
Agents explore; humans judge and are accountable
Risk: deskilling if agents become opaque oracle “experts”

IP and creators’ rights are murky (in the ‘agentic future’ …)

Who owns an LLM-evolved diff? Model? Prompter? Repo? (If it reads on a patent claim?)
Permissively-licensed code bases might accept agent diffs (is usability clouded?)
Training with public “scraped” corpora (creator rights, opt-ins, … ?)
Attribution and credit when an agent rediscovers known techniques

What does “authorship” mean for agent-generated EDA code?

14

15 of 23

Challenge 3: project & ecosystem governance

Agents change the contribution model

PRs at machine speed: how does review scale?
Bot accounts, auto-generated commits 🡪 what counts as a maintainer signal?
Risks: hallucinated, or subtly-wrong code overwhelming reviewers

Ecosystem-level questions

Reproducibility: pin commits, PDKs, agents, prompts
Saturated benchmarks: need open, evolving evaluation suites
Compute access: who can run repo-scale evolution? 🡨 equity in research
Co-evolution: agent capabilities and tool APIs both moving targets

In an ideal (OpenROAD) future …

CI-enforced QoR gates: non-regressing diffs, machine-checkable invariants
Provenance metadata: model, prompt, evaluation context per diff
Versioned manifests: OpenROAD commit + ORFS + PDK + agent 🡪 replay any result

Note: https://github.com/ieee-ceda-datc/OpenROAD-Research

15

The third challenge is project and ecosystem governance.�

Agents generate diffs at machine speed, so human review becomes a bottleneck. Guardrails, and ladders of checkers, and careful design of rewards – preventing subtly wrong changes from infiltrating the code base – there are many things to work on.�

[CLICK] At the ecosystem level, reproducibility means pinning not just commits and PDKs, but also agent versions, prompts, and evaluation settings. Benchmarks saturate quickly, so benchmark suites must avoid leakage and have roadmaps. Should we be worrying about equity of resources and access in the research ecosystem?

And then, agents co-evolve with the agentic code surfaces they work with: who controls the universe of surfaces? // (in OpenROAD …)

[CLICK] So table stakes going forward might be called “proactive infrastructure”: CI-enforced QoR gates, provenance metadata for every agent-generated diff, and versioned manifests that make results replayable.

And through initiatives like [CLICK] this, researchers might take the lead.

This is all doable, and paths forward are actually pretty obvious. It more an issue of what Archimedes said … “Give me a place to stand …”

16 of 23

Toward an open vertical environment for EDA agents

Environment scaffolding�(The substrate agents act inside)	Agent capabilities�(What we want agents to do)	Ecosystem and governance (What OpenROAD can achieve)
Episode schema for EDA (workspace, actions, constraints, QoR)	Lexicographic, constraint-aware rewards (hard gates 🡪 QoR frontier 🡪 cost)�	Open evolving agent benchmark suite
Cross-stage state & observability (RTL ↔ verif ↔ synth ↔ PD ↔ signoff causality)	Cross-tier orchestration (flow-level + code-level in one loop)	Reproducibility manifests�(pinned commits, PDKs, agent versions, prompts)
Multi-fidelity ladder (lint 🡪 sim 🡪 synth 🡪 PD 🡪 signoff audit)	Trajectory-grounded training + research-grade memory	CI-enforced QoR gates + machine-checkable invariants
Fast learned surrogates as first-class env citizens	Code-level R&D	Industrial calibration loop + compute equity

16

Here’s my last slide – about OpenROAD becoming an open vertical environment for EDA agents.

This slide is about THE key missing artifact -- which is the environment around the agent. **What makes up this environment?**

On the left is scaffolding: episode schemas, cross-stage observability, multi-fidelity evaluation, fast surrogates.

In the middle there’s agent capabilities: constraint-aware rewards, cross-tier orchestration, trajectory-grounded training, memory, and code-level R&D.

On the right is where OpenROAD and ONLY the open-source innovation ecosystem can lead: evolving benchmarks, reproducibility manifests, CI-enforced QoR gates, machine-checkable invariants, and so on.

So: OpenROAD will be more than an open EDA toolchain – it will be the open research substrate that lets us understand agentic EDA.

Several folks in my lab are working toward this vision – and one of them, Bodhi Pramanik, helped immensely with compiling this talk – so, huge thanks to Bodhi.

With that, thank you and open for questions.

GitHubs/Docker Hubs/etc.

ORFS-Agent: https://github.com/ABKGroup/ORFS-Agent

EDA corpus: https://github.com/OpenROAD-Assistant/EDA-Corpus

OpenROAD-Agent: https://github.com/OpenROAD-Assistant/OpenROAD-Agent

OpenROAD-Assistant: https://github.com/OpenROAD-Assistant/OpenROAD-Assistant.git

EDA-AI: https://github.com/Thinklab-SJTU/EDA-AI/tree/main

EvoPlace: https://github.com/yaoxufeng/EvoPlace/tree/master

ChatEDA: https://github.com/wuhy68/ChatEDA

AuDoPEDA: https://hub.docker.com/r/abkgroupucsd/audopeda

HELIX: https://github.com/ABKGroup/HELIX.git

MLCAD26 contest: https://github.com/ASU-VDA-Lab/MLCAD26-Contest.git

GR-Evolve: https://github.com/ASU-VDA-Lab/GR-Evolve

CHICO-Agent: https://github.com/ASU-VDA-Lab/CHICO-Agent

OpenROAD: https://github.com/The-OpenROAD-Project/OpenROAD.git

ORFS: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git

ORFS Docker image: https://hub.docker.com/r/openroad/orfs

FastPart / hypergraph partitioning artifacts: https://vlsicad.ucsd.edu/hypergraphs/

MacroPlacement benchmark/infrastructure: https://github.com/TILOS-AI-Institute/MacroPlacement

CircuitNet: https://github.com/circuitnet/CircuitNet

CircuitOps: https://github.com/NVlabs/CircuitOps

17 of 23

Thank You!

17

18 of 23

Flow-level agents – architecture

High-level objective�“Minimize ECP with < 2% PDP degradation”

LLM planner

Parse documents
Parse codebase / scripts
Parse misc. corpus
Decompose objective
Generate flow script
Propose parameters

Execution layer

Invoke tools
Monitor logs
Capture metrics

EDA tools

LLM

Feedback

Knowledge�corpus

ChipNeMo (NVIDIA) (2023)

Pretraining on expert-engineer scripts
Combines ICL with document retrieval
Generates high-quality Tcl scripts for timing analysis, etc.

ChatEDA (CUHK) (2024)

Translates flow automation to an agentic task
Rich training corpora, CoT prompting, usage of multi-agents

ORAssistant (Precision Innovation) (2024)

Automated script generation and chatbot for OpenROAD ecosystem

ORFS-agent (UCSD) (2025)

LLM-driven iterative optimization agent for parameter tuning in the OpenROAD-flow-scripts repo.

Treat EDA tools as black-boxes; LLM decomposes objective into subtasks; each subtask is translated to scripts

Response

Query

Response

Invoke

PPA

18

19 of 23

Code-level agents – architecture

High-level objective�“Reduce HPWL by improving global swap operator in OpenROAD’s dpl”

Parse source code
Parse relevant modules
Parse misc. corpus
Understand dependencies

Code parser

Propose code edits
Introduce new cost terms
Tune hyperparameters
Refactor control logic

LLM reasoner

Build tool
Run benchmark suite
Sanity checks
Linters

Compiler + regression tests

EDA tools

QoR metrics

Feedback

Modify internal heuristics and algorithms; LLM reads, proposes and edits code diffs

EvoPlace (CUHK) (2025)

Python code edits inside DREAMPlace framework

SATLUTION (NVIDIA) (2025)

C++ code diffs targeting Boolean Satisfiability problems
Directly evolves solver repositories

-EVO (UCSD) (2025)

C++ code diffs targeting placement algorithms in OpenROAD
Directly evolves placement repositories

AuDoPEDA (UCSD) (2026)

Proposes research directions + expands them into executable code diffs

VLM-MPL (UCSD) (2026)

Vision language models-based macro placer

LLM

Query

Response

Query

19

20 of 23

AuDoPEDA: Documentation 🡪 Planning 🡪 Diff 🡪 QoR Loop

Parse OpenROAD via tree-sitter
Build cross-language property graph
Generate hierarchical doc cards
Create machine-readable API/invariant summaries

Retrieve from repo docs, EDA literature corpus
DSPy-compiled planning program
Outputs: research hypothesis, proposed interventions, QoR targets

Map plan 🡪 specific files/functions
Generate granular diff plan: pre-checks, run config, QoR probes, rollback conditions

Codex-class agent
Apply diffs
Build
Run flow
Extract QoR
Hill climb under safety gates

Convert codebase to structured knowledge

Planning is typed and validated

Converts research intent into executable diffs

Accept only if QoR improves

QoR

20

21 of 23

A merge-ready OpenROAD PR (agent-driven)

What “merge-ready” requires

Passed regression/PPA �guardrails
Iterated on review feedback + �merge conflicts
Auto-generated docs + configs + �PR descriptions
Only manual step: human-expert �sign-off
End-to-end LLM cost: ~$30
Human-edits: 0 (except sign-off)

https://github.com/The-OpenROAD-Project/OpenROAD/pull/9038

21

22 of 23

Links

GitHubs/Docker Hubs/etc.
ORFS-Agent: https://github.com/ABKGroup/ORFS-Agent
EDA corpus: https://github.com/OpenROAD-Assistant/EDA-Corpus
OpenROAD-Agent: https://github.com/OpenROAD-Assistant/OpenROAD-Agent
OpenROAD-Assistant: https://github.com/OpenROAD-Assistant/OpenROAD-Assistant.git
EDA-AI: https://github.com/Thinklab-SJTU/EDA-AI/tree/main
EvoPlace: https://github.com/yaoxufeng/EvoPlace/tree/master
ChatEDA: https://github.com/wuhy68/ChatEDA
AuDoPEDA: https://hub.docker.com/r/abkgroupucsd/audopeda
HELIX: https://github.com/ABKGroup/HELIX.git
MLCAD26 contest: https://github.com/ASU-VDA-Lab/MLCAD26-Contest.git
GR-Evolve: https://github.com/ASU-VDA-Lab/GR-Evolve
CHICO-Agent: https://github.com/ASU-VDA-Lab/CHICO-Agent
OpenROAD: https://github.com/The-OpenROAD-Project/OpenROAD.git
ORFS: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git
ORFS Docker image: https://hub.docker.com/r/openroad/orfs
FastPart / hypergraph partitioning artifacts: https://vlsicad.ucsd.edu/hypergraphs/
MacroPlacement benchmark/infrastructure: https://github.com/TILOS-AI-Institute/MacroPlacement
CircuitNet: https://github.com/circuitnet/CircuitNet
CircuitOps: https://github.com/NVlabs/CircuitOps

22

23 of 23

Hypergraph partitioning – beyond quality: speed

Same cutsize with significantly faster runtime!

Better cutsize than TritonPart

23