Invited: IEEE DATC RDF-2025: Enabling an EDA Research Ecosystem PDF Free Download
1 / 9/9
100%
Invited: IEEE DATC RDF-2025: Enabling an EDA Research
Ecosystem
Vidya A. Chhabria∗, Amur Ghose†, Vikram Gopalakrishnan∗, Andrew B. Kahng†,
Sayak Kundu†, Yiting Liu†, Zhiang Wang†, Bing-Yue Wu∗
∗Arizona State University, Tempe, USA Email: {vachhabr, vgopal18, bingyuew}@asu.edu
†University of California San Diego, La Jolla, USA Email: {aghose, abk, sakundu, yil375, zhw033}@ucsd.edu
Abstract—Over the past year, IEEE CEDA DATC has continued to
improve the DATC Robust Design Flow (RDF) while continuing to expand
initiatives that advance open infrastructures and culture changes, serving
the global community of EDA researchers and users. This invited paper
focuses on three highlights: (1) establishment of an accessible, “contrib-
like” GitHub resource that provides a more accessible environment
for OpenROAD- and OpenROAD-flow-scripts-based research works; (2)
the first-ever permission mechanism and benchmarking results for a
commercial EDA P&R tool, published with permissions developed with
the tool vendor (Siemens EDA); and (3) efforts that support a nascent
“ML EDA Commons”. The paper also provides brief reviews of the past
year’s RDF developments and roadmap updates.
I. INTRODUCTION
The Design Automation Technical Committee (DATC) within the
IEEE Council on EDA (CEDA) [50] seeks to address critical issues,
needs, and community strategies in design automation. Since 2016,
DATC has overseen the development of the Robust Design Flow
(RDF), a comprehensive academic reference flow from RTL to
GDSII, integrating multiple award-winning point tools alongside the
OpenROAD [1] toolchain. RDF was created with two primary aims:
(1) to preserve and integrate cutting-edge academic research tools,
and (2) to stimulate research in design flow optimization and cross-
stage integration. A series of invited papers has chronicled updates
to RDF and the DATC’s strategic priorities and development efforts.
The 2020 integration of OpenROAD [62] [3] created a com-
plete open-source tool-based RTL-to-GDSII implementation flow
within RDF. Key directions since then have included calibration
of analyses and verifications; validation of research in a full-flow
context; and infrastructure (e.g., metrics reporting, benchmarks and
baseline solutions, ML EDA schema, and datasets) to support ML-
enabled EDA (ML EDA) research. The RDF GitHub [48] provides
a listing of component academic tools, updated reference flows, and
other outcomes of DATC efforts. Additions in the past year include
support for the IHP130-sg13g2 open-source PDK, improved design
enablements for the NanGate45 and ASAP7 research PDKs, and new
academic engines. In this paper, we focus on three highlights:
•the first-ever permission mechanism and benchmarking results for a
commercial EDA P&R tool, published with permissions developed
with the tool vendor;
•new “contrib-style” GitHub spaces that provide a more accessible,
decoupled environment for research activity that is based on
OpenROAD (OR) and OpenROAD-flow-scripts (ORFS); and
•numerous efforts that support a nascent “ML EDA Commons”.
In the following, Section II details benchmarking results for the
Siemens Aprisa tool, along with mechanisms by which reproducible
research and public benchmarking can be performed with the tool.
Section III describes motivations for the new OpenROAD-Research
and ORFS-Research repositories, along with example initial contents.
Section IV describes efforts of the DATC and RDF, as well as across
the community, toward realization of an ML EDA Commons [6].
Section V reviews the past year’s progress toward RDF roadmap
goals [5], and Section VI concludes the paper.
II. ANEDA BENCHMARKING FIRST
Previous DATC RDF updates and other works (e.g., [5] [16]) have
noted that EDA industry end-user license terms forbid benchmarking
of commercial EDA tools. However, progress of the field is slowed
when the state-of-the-art is unclear, and comparisons against leading-
edge optimizers cannot be made. Even reproducibility of results
obtained with commercial tools dates only to 2022 [15] [61], when
tool runscripts were first permitted to be shared publicly for non-
commercial, research purposes.
The new DATC GitHub repo [44] publishes, for the first time
ever, benchmarking results for a leading-edge commercial EDA tool,
Siemens EDA’s Aprisa v2025.2. Results are obtained for open-
source testcases on open research enablements (NanGate45 and
ASAP7), and are fully reproducible using the tool scripts that are
also published in the GitHub repo. This section gives highlights of
the new benchmarking results as well as the results for additional
testcases and extended tool flows. Aprisa techfiles for NanGate45
and ASAP7 are public and maintained in [44].
TABLE I: Details of the open-source testcases.
Design ASAP7 NanGate45
TCP (ns) Util #inst (#macro) TCP (ns) Util #inst (#macro)
AES 0.40 68 16k (0) 0.50 68 11k (0)
JPEG 0.40 68 53k (0) 0.60 68 45k (0)
Ariane 0.90 68 100k (133) 1.30 68 118k (133)
BlackParrot 0.85 68 836k (220) 1.30 68 768k (220)
Table I lists eight testcases used in our study. The table provides
target clock period (TCP), initial floorplan utilization (Util), and in-
stance (#inst) and macro (#macro) counts in the post-synthesis netlist
for each testcase. For Ariane and BlackParrot, the 68% floorplan
utilization reflects the setup used in [63]. The NanGate45 and ASAP7
enablements are obtained from [63]. Synthesizable Verilog RTL is
obtained from [55] for AES and JPEG, and from [63] for Ariane and
BlackParrot. All gate-level netlists are obtained from corresponding
Verilog RTL using an unnamed commercial synthesis tool. RTL,
obfuscated synthesized netlists, and SDC files are public in [44].
Tables II and III present post-route results from Aprisa v2025.2 and
from the open-source OpenROAD-flow-scripts (ORFS) [55] (commit
hash faa7fe5), including standard-cell count (#Stdcell), total cell area
(Area), routed wirelength (rWL), total power (Power), worst negative
slack (WNS), total negative slack (TNS), number of failing endpoints
(#FEP), design rule violations (#DRV), and shorts (#Shorts). The
results in Table II are obtained by running Aprisa, with corresponding
scripts provided by Siemens EDA. Post-route DRC checks are
reported by the Aprisa tool. To avoid bias in PPA reporting, we take
the post-route DEF file from Aprisa into unnamed commercial signoff
PEX and STA tools to evaluate final timing and power. PEX is set to
ignore coupling capacitances; STA is run with clock uncertainty as
given in each testcase’s respective SDC file, and with signal integrity
analysis disabled.
TABLE II: Aprisa P&R results. Power (mW ), WNS (ps), TNS (ns), and FEP are reported using an unnamed commercial PEX-STA flow.
Remaining metrics (e.g., rWL (µm), Area (µm2)) are reported by Aprisa.
Enablement Design #Stdcell Area rWL Power WNS TNS #FEP #DRV #Shorts
ASAP7
AES 12717 1278 57360 8 0 0 0 0 0
JPEG 49669 5639 85858 58 -55 -19 972 0 0
Ariane 124041 18603 981278 555 -306 -2116 18773 50 24
BlackParrot 912476 140078 6604195 1923 -348 -14145 166990 60 30
NanGate45
AES 16662 25404 229803 37 -172 -25 357 0 0
JPEG 57832 89013 415674 115 -32 -3 332 0 0
Ariane 123835 244587 4832327 745 -37 -1 144 0 0
BlackParrot 790646 1918145 27222737 3831 -31 -11 1614 0 0
TABLE III: OpenROAD-flow-scripts results: Power (mW ), WNS (ps), TNS (ns), and FEP are reported using an unnamed commercial PEX-STA
flow; DRVs and shorts are reported with an unnamed commercial P&R tool. Remaining metrics are reported by OpenROAD.
Enablement Design #Stdcell Area rWL Power WNS TNS #FEP #DRV #Shorts
ASAP7 AES 15601 1456 53188 7 -128 -20 366 0 0
JPEG 58859 6383 109920 43 -123 -83 1456 0 0
NanGate45 AES 21458 23421 253195 30 -208 -52 384 0 0
JPEG 65740 88889 492440 104 -327 -260 1809 0 0
Table III reports PPA metrics from the ORFS flow evaluated using
the same signoff PEX and STA tools applied to Aprisa results. DRC
violations and shorts are evaluated by taking post-route DEF from
OpenROAD into an unnamed commercial P&R tool. We report the
best ORFS outcome obtained after autotuning for 1000 iterations (i.e.,
flow runs) for AES and JPEG; the autotuning explores a standard
set of 10 flow hyperparameters1within predefined ranges, with the
goal of minimizing effective clock period (i.e., TCP minus worst
slack). Details of autotuning setup and runscripts are given in [44]; we
leverage ORFS infrastructure [11] and the methodology for obtaining
“best-ever” results from ORFS reported in RDF-2024 [5]. Because
ORFS does not complete P&R for the macro-based designs with
68% initial floorplan utilization, we report ORFS results only for
AES and JPEG on ASAP7 and NanGate45.2To enable independent
reproduction, [44] archives all tool scripts, synthesized netlists and
DEF files, including for the Aprisa flow.3
These published results may be freely cited, attributed and com-
pared. Mechanisms to obtain and publish further baseline benchmark
results using the Aprisa tool are documented in [44]. Ongoing efforts
include setting up Aprisa RTL for synthesis, Calibre xACT for
RC extraction, and enabling additional testcases. We thank Siemens
EDA for permission to perform and publish this first-ever public
benchmarking of a commercial EDA tool, and look forward to the use
and expansion of these baselines to drive academic EDA research.
III. OPENROAD-RESEARCH AND ORFS-RESEARCH:
FOSTERING AN OPEN ECOSYSTEM FOR NEXT-GENERATION EDA
Through IEEE CEDA DATC Robust Design Flow (RDF) and
other efforts, the research community has made significant progress
toward an open, reproducible, end-to-end RTL-to-GDS flow. Key
challenges set out in RDF-2019 have been addressed: (1) enabling
flow-scale and cross-stage optimizations; (2) removing binaries or
source codes with licensing restrictions that prevented academic and
commercial use; and (3) bridging the gap between contest-driven
tools and real-world enablements. The latest RDF-2024, developed
based on OpenROAD, spans logic synthesis through detailed routing
1ORFS hyperparameters: LB Add-on Density, Global Pad, Detailed Pad,
Enable DPO, TNS End Percent, Pin Layer Adjust, Above Layer Adjust, CTS
Cluster Size, CTS Cluster Diameter, and Flatten Hierarchy.
2ORFS can complete P&R of macro-based designs in these enablements,
but with lower utilization – e.g., 55% for Ariane in ASAP7.
3Additional details are elaborated, e.g., (1) usage of Aprisa Auto Macro
Placer (AMP) to obtain Table II results, as well as (2) recipes for IO placement
and power planning used with the two tools.
and enables academic and industrial users to conduct research and
production. OpenROAD and OpenROAD-flow-scripts (ORFS), have
been central to these advances. Today, ORFS is a fully autonomous
RTL-to-GDSII flow supporting rapid architecture/design space explo-
ration, early QoR prediction, and production-grade implementation.
A key industrial developer, Precision Innovations Inc., maintains code
quality, accepts industrial-grade contributions, and supports adoption
across semiconductor companies.
However, in 2025 we face a new inflection point in RDF’s
evolution. The emergence of machine learning, large language models
(LLMs), and GPU-accelerated parallel algorithms opens up unprece-
dented opportunities for physical design. These methods may not yet
be mature enough to compete with well-tuned, hand-crafted classical
heuristics – and their implementations may still be “poor-quality” or
otherwise not production-ready. Nevertheless, they represent essential
directions for innovation and education. At the same time, the current
OpenROAD and ORFS repositories retain only the most effective
tools and scripts, which streamlines maintenance and industrial sup-
port but limits reproducibility and hinders availability of algorithmic
baselines for the academic community.
To address the new inflection point, RDF-2025 establishes
OpenROAD-Research [72] and ORFS-Research [73], still under
the umbrella of the IEEE DATC RDF. Our goal is to provide an open
and collaborative “innovation sandbox”. Specifically, OpenROAD-
Research and ORFS-Research will:
•serve as an open library of baselines and algorithms, preserving
diverse research contributions (e.g., detailed placers implemented
with different heuristics), even if not yet production-ready;
•accelerate innovation by lowering the barrier for contributions in
emerging areas, such as LLM-based flow autotuning and agentic
frameworks;
•support education and workforce development by providing
students and researchers with access to a broad collection of
reproducible implementations; and
•foster global collaboration by functioning as “contrib” repos-
itories (analogous to open-source projects such as PyTorch’s
torch.contrib), where experimental and research-oriented code can
coexist alongside the mainline flow. The mainline repositories
(OpenROAD and ORFS) will continue to host production-quality
implementations that are thoroughly regression-tested and meet
industrial standards and deployment practices. In parallel, our
research repositories (OpenROAD-Research and ORFS-Research)
will host academically validated contributions that may remain ex-
2
ploratory, heterogeneous in approaches, or not yet fully optimized
for industrial deployment.
In short, OpenROAD-Research and ORFS-Research are envisioned
as foundational platforms to accelerate global collaboration, preserve
algorithmic diversity, and boost innovations in physical design.
Over the coming years, we anticipate that a number of significant
contributions from the global EDA community will be built upon
OpenROAD-Research and ORFS-Research.4Four possible examples:
•GPU-accelerated P&R engines integrated within OpenROAD-
Research, spanning from partitioning to design rule checking
(DRC), and enabling substantial runtime improvements and scala-
bility;
•ML-assisted physical design, where ML models are tightly inte-
grated with OpenROAD-Research to enable closed-loop optimiza-
tion and QoR enhancement across the P&R flow;
•true 3D P&R engines in OpenROAD-Research, providing open,
reproducible and transparent baselines for 3D integration; and
•the “pytorch” in EDA, offering modular operators and Python APIs
within OpenROAD-Research, to facilitate rapid prototyping and
experimentation of ML-driven EDA methodologies.
A. OpenROAD-Research
OpenROAD-Research serves as a platform for developing and shar-
ing next-generation physical design engines. Initially, the focus is on
two main directions: GPU-accelerated physical design engines, and
physical design engines for advanced packaging. We use the examples
of GPU-DPO and ChipletPart to highlight how OpenROAD-Research
extends existing engines in OpenROAD to explore new frontiers in
physical design.
1) GPU-accelerated Physical Design Engines: Advanced SoCs
can contain up to billions of instances and nets. However, the
runtime for P&R and optimization can be several days even for
a small 2 million-instance block. GPU-based acceleration offers a
potential transformative opportunity to drastically reduce runtime and
meet today’s aggressive design schedules. Two directions for GPU-
accelerated physical design are (1) GPU-accelerated kernels for
classical heuristics, whereby classical EDA heuristics (e.g., weighted
average wirelength calculation in global placement, or pattern routing
in global routing) are broken down into GPU-accelerated kernels to
gain speed; and (2) GPU-accelerated differentiable optimization,
whereby discrete optimization problems in physical design can be
approximated or relaxed into continuous and differentiable forms that
can be better mapped to GPUs for gradient-based acceleration.
OpenROAD-Research aims to provide a public platform for build-
ing and sharing a GPU-accelerated physical design prototype. To
this end, GPU-DPO transforms OpenROAD’s Detailed Placement
Optimizer into CUDA kernels to achieve substantial speedups. This
acceleration enables the integration of expensive metaheuristics, such
as Large-Step Markov Chain techniques, on top of traditional greedy
algorithms. Thus, GPU-DPO is better able to escape local optima and
improve placement quality. GPU-DPO also fully supports movable
and reorderable multi-row height cells.
In the coming year, we will extend GPU acceleration to global
placement and global routing. This step moves us closer to a fully
GPU-accelerated P&R flow. We invite the community to join this
open effort, with particular focus on critical slowdowns in real end-
to-end flows, such as detailed route search and repair, DRC fixing,
and MCMM design closure. By working together, the community can
4Initial contributions to OpenROAD-Research and ORFS-Research have
been led by Professor Zhiang Wang and his team at Fudan University, along
with Professor Andrew B. Kahng’s team at UC San Diego. Contributions and
collaborations from the broader community are welcomed.
build scalable, high-performance, and open-source GPU-accelerated
end-to-end P&R flows that serve the needs of next-generation IC
design.
2) Physical Design Engines for Advanced Packaging: Three-
dimensional integration (3D IC) has emerged as a promising strategy
to sustain performance and cost-effectiveness as the benefits of
traditional semiconductor scaling diminish. By distributing standard
cells and macros across multiple dies (chiplets in 2.5D integration) or
stacked tiers, and exploiting fine-pitch vertical interconnects, 3D ICs
provide opportunities for improved timing, reduced power, higher
yield, and lower cost. However, 3D ICs also introduce substantial
challenges in physical design.
OpenROAD-Research will support IEEE DATC RDF by aiming
to establish an academic reference design flow for chiplets and 3D
ICs. By extending the existing 2D IC P&R engines in OpenROAD,
we can lower the development effort needed to create an open
and transparent baseline for 3D IC design, thereby accelerating
research and innovation in physical design for advanced packaging.
A representative example is ChipletPart, a cost-driven 2.5D system
partitioner that leverages several components of OpenROAD, includ-
ing the partitioner and the annealing engine from the floorplanner.
ChipletPart addresses the unique constraints of chiplet systems,
including complex objective functions, limited reach of inter-chiplet
I/O transceivers, and the assignment of heterogeneous manufacturing
technologies to different chiplets.
Looking ahead, we plan to extend the OpenROAD physical design
flow to support true face-to-face (F2F) 3D integration, including
the development of both a native 3D placer and a 3D router. The
3D placer will build upon OpenROAD’s global placement engine to
simultaneously co-optimize tier assignment and instance placement.
The 3D router will extend the current router in OpenROAD to
handle vertical interconnections through hybrid bonding interfaces. In
addition, we will introduce 3D-aware congestion models and design
rule checkers to ensure manufacturability. Ultimately, OpenROAD-
Research aims to deliver a fully open-source P&R flow for true
logic-on-logic 3D ICs. We invite the research community to actively
contribute to this initiative, helping to establish a transparent and
extensible foundation for 3D IC designs.
B. ORFS-Research
ORFS-Research focuses on flow-level innovation in physical de-
sign. The goal of ORFS-Research is to create modular and repro-
ducible design flows that integrate existing engines to tackle emerging
challenges such as 3D integration and AI-driven automation. Built
on the OpenROAD-flow-scripts (ORFS) foundation, ORFS-Research
provides a sandbox for prototyping and evaluating new flows across
diverse PDKs and benchmarks. Two early efforts showcase this di-
rection. The Multi-Plugin-Pin3D-Flow extends ORFS to face-to-face
(F2F) 3D ICs with a modular pseudo-3D SP&R flow. Meanwhile,
ORFS-agent applies LLM-based iterative optimization to automate
hyperparameter tuning in ORFS.
1) Pseudo-3D Flow for Face-to-face 3D Integration: Since no
native physical design flow currently supports face-to-face (F2F)
3D integration, we propose a pseudo-3D synthesis, place and route
(SP&R) flow based on OpenROAD, leveraging mature 2D P&R
engines for 3D IC design. Building on the Pin Projection concept
introduced in [21] and extending the logic-on-memory methodology
from Open3DBench [22], we develop Multi-Plugin-Pin3D-Flow, an
open-source modular plugin-based pseudo-3D framework integrated
into ORFS-Research. The proposed framework defines standardized
interfaces for partitioning, placement, clock tree synthesis, routing,
extraction and signoff, thereby enabling interoperability across dif-
ferent 2D P&R engines (e.g., OpenROAD, or proprietary tools)
3
under a unified 3D PDK and evaluation environment. Our Multi-
Plugin-Pin3D-Flow is implemented as a set of Python/Tcl scripts
that automate the full SP&R flow. Files are used to connect different
SP&R stages and different tools.
The primary objective of Multi-Plugin-Pin3D-Flow is to enable
fair, reproducible, and tool-agnostic implementation and benchmark-
ing of 3D ICs using existing 2D physical design infrastructures.
Looking ahead, we plan to integrate three key enhancements: (1)
heterogeneous technology integration, which enables multiple nodes
such as Nangate45 and ASAP7 to coexist across stacked tiers; (2)
backside power delivery network (BSPDN) modeling, which provides
a pathway to implement modern backside power architectures; and
(3) hybrid bonding terminal (HBT) modeling, which includes both
fast geometric-level abstractions using VIA-equivalent models and
detailed timing-aware models based on physical-only “buffer cells”
with library-based delay characterization. We invite the community to
contribute to this open initiative. Key opportunities include extending
flow stages, supporting new PDKs, refining BSPDN and HBT models,
and developing true-3D optimization plug-ins (see Section III-A).
With sustained collaborative effort, Multi-Plugin-Pin3D-Flow can
evolve into a robust, extensible foundation for both academic research
and industrial exploration of 3D IC design methodologies.
2) ORFS-agent: ORFS-agent [8] [56] seeks to automate a con-
crete, measurable part of the OpenROAD system – the OR-
AutoTuner – which determines and sets hyperparameters such as
core density for a given (PDK,circuit) pair when ORFS is run. These
hyperparameters directly determine final QoR, and a fundamental
task is to find best-possible settings within an available number of
iterations. Across two major PDKs, ORFS-agent improves over OR-
AutoTuner in terms of both Routed Wirelength and Effective Clock
Period, using 40% fewer iterations. Similar superiority is seen in
multi-objective and constrained optimization scenarios.
ORFS-agent uses the Claude Sonnet 3.5 class of models; it uses
tools to inspect and analyze the results of flow runs, and to model
them for picking a best set of hyperparameters to use in the next
iteration of flow runs. Once a sufficient number of such iterations
occurs, ORFS-agent can determine the best set of hyperparameters
for a given (PDK,circuit) pair for a given QoR metric goal. ORFS-
agent is model-agnostic and modular, with no fine-tuning: any LLM
can be slotted in, meaning that availability of a new language model
can be immediately exploited. We may view ORFS-agent as a first
step toward OpenROAD-agent, an envisioned end-to-end coding agent
within the OpenROAD ecosystem that is detailed in Section IV-C2
below. To be specific: ORFS-agent, as part of ORFS-Research, will
likely be employed as a tool to verify and optimize atop code-
level changes implemented by OpenROAD-agent, which will reside
within OpenROAD-Research.
Operationally, the agent follows a simple loop— observe, analyze,
propose, apply. It launches a diverse batch of runs, consolidates
artifacts into a table of inputs (the chosen knob values) and outputs
(the observed metrics), and then reasons with context. Here, “context”
includes PDK/testcase metadata, legal ranges and scales for each
variable, historical priors, and partial proxies when end-to-end metrics
are unavailable (e.g., using early-stage indicators when detailed
routing times out). The analysis step mirrors the workflow of a careful
data scientist: inspect distributions and trade-offs, state a hypothesis
about what variables are binding in the current regime, and turn that
hypothesis into a small set of proposed next candidates that balance
promise and diversity. The apply step materializes decisions as
concrete edits to config.mk and SDC so that runs are reproducible
inside or outside the agent loop.
Three design choices are central. (1) Context first. Decisions are
conditioned on the semantics of each variable and on process/design
realities, avoiding “blind” proposals. (2) Emulation of human experts.
The agent explains itself through an evidence trail – what was
observed, why a region of the space looks promising, and exactly
which knobs were changed – so results can be reviewed and rolled
back. (3) Modularity. The LLM is a replaceable controller, and
analysis and selection routines are swappable; this future-proofs
the approach as models, surrogates and heuristics improve. Indeed,
customizability of ORFS-agent is arguably its greatest asset – the
behavior of the agent is tunable on the level of prompts and tooling,
which means that in the advent of, e.g., a blackbox superior BO tool
which can be encoded as a function call, the agent is augmented
instead of being made obsolete.
Within the broader ML EDA context, ORFS-agent is not a new
optimizer so much as a thin, model-agnostic operator layer. Modern
RTL-to-GDS flows expose many coupled controls whose effects
depend on process, libraries and design style; exhaustive sweeps
are costly and one-size-fits-all recipes are never a best fit. In this
setting, value accrues from systems that can read evidence, respect
domain constraints, and produce small, well-motivated changes to
configuration. ORFS-agent plays that role. It is compatible with
learned surrogates, Bayesian search, or GPU-accelerated exploration,
but does not require any particular choice; the controller can be any
capable LLM that can inspect artifacts, reason about context, and
write files.
As an artifact in ORFS-Research, ORFS-agent provides a trans-
parent, reproducible baseline for LLM-in-the-loop autotuning. It
complements specialized learning components by turning raw flow
outputs into actionable next steps, and it frames evaluation in terms
that match real resource budgets: QoR versus iterations, constraint
satisfaction rate, and time-to-first acceptable layout. Furthermore,
while OpenROAD-Research contains tools that will produce the
next generation of OpenROAD-based RTL-to-GDS flows, ORFS-
agent and similar tools in ORFS-Research provide harnessing to
ensure that on the level of hyperparameters, these code changes ship
with promptness and maximal impact. In other words, the goal of
OpenROAD-agent would be to produce code diffs that impact the
RTL-to-GDS pipeline; the goal of ORFS-agent and similar tools
would be to smooth the adaptation of existing tools such as Ray
Tune to the optimization problem at hand.
IV. SERVING AN ML EDA COMMONS
The landscape of ML EDA has been rapidly growing through
efforts in dataset generation [28][29], benchmarking [31], con-
tests [24][65], leaderboards [31], open-source initiatives [67], and
cyberinfrastructure for chip design [32]. However, these efforts re-
main fragmented, often duplicating one another and facing recurring
challenges such as a lack of incentives and coordination. In this
context, the need for an ML EDA Commons has become increasingly
evident [68], [66], [69]. An ML EDA Commons focuses on advancing
ML EDA applications by providing shared resources (datasets, tools,
flows, benchmarks, metrics). A vision for an ML EDA Commons was
outlined in [6], encompassing three key pillars: (1) maturing existing
EDA infrastructure to better support ML research; (2) establishing
standards for benchmarks, metrics, and data formats through gover-
nance that involves key stakeholders; and (3) improving accessibility
and reproducibility by providing open data, tools, models, and
workflows with cloud resources – thereby lowering barriers to entry
and promoting robust research practices through artifact evaluations,
canonical evaluators, and integration pipelines.
This section reviews efforts that serve as components of such a
vision, including new datasets, benchmarks, contests, hackathons,
4
Fig. 1: Components of an ML EDA Commons [6].
benchmarking coalitions, emerging standards, and new agentic flows
and assistants for EDA applications. Together, these efforts demon-
strate encouraging progress toward different components of a Com-
mons, as shown in Fig. 1.
A. Datasets and Benchmarks
We describe two recent examples of benchmark and synthetic data
generation approaches that are available in the DATC GitHub.
1) ML Buffering Benchmarks and Scripts: Buffering is a key
strategy for timing closure in modern technology nodes. Machine
learning (ML)-based buffering offers high efficiency and scalability,
and has been recently studied in, e.g., [19][17]. The DATC repository
[74] publishes benchmarks [70] which compile detailed cell- and
buffer-level attributes across the buffering process. The benchmark
includes pre buffered trees, capturing original netlists and cell fea-
tures before any buffer insertion; mid buffered trees, recording the
trajectory of OpenROAD Resizer’s [71]buffer insertion process; and
post buffered trees, containing the final Resizer-buffered netlist and
features. By offering structured data across the entire buffering flow,
these benchmarks establish an extensible foundation for evaluating,
training, and validating ML-based buffering strategies.
2) Synthetic Data for Layout Heatmaps: ML EDA approaches are
often constrained by the quantity and quality of the dataset available.
In particular, physical design data is expensive as it requires running
computationally costly tools. Although open- source datasets such
as CircuitNet [41] have been created, they are static and can lack
diversity due to the small number of available RTL designs. To ad-
dress this, DALI-PD [27] provides a framework that uses a diffusion
model pre-trained on urban satellite images to generate circuit layout
heatmaps, including cell density, macro locations, congestion, IR
drop, and power maps. DALI-PD conditions the rendering process
of the diffusion model on selected circuit specifications, including
clock period, layout dimensions, and macro locations. It produces
layout heatmaps within seconds via fast ML inference. The resulting
synthetic heatmaps provide statistically diverse yet realistic layouts,
and improve performance in downstream ML tasks such as IR drop
prediction compared to models that have been trained on small
amounts of real circuit data only.
B. Standards for Formats and Data Flows
Standards are essential for ensuring reproducibility and enabling
research through interoperability between different EDA tools. This
becomes even more critical as new methodologies and the integration
of AI/ML techniques into EDA continue to emerge. One key chal-
lenge in establishing such standards is the fragmented nature of the
EDA ecosystem: tools operate across multiple modalities and often
Fig. 2: Data pipeline developed by the Si2 ML schema working
group [47].
generate data in disparate, proprietary formats, creating significant
barriers to integration. In the context of ML EDA, data format
standards must not only reconcile these tool outputs but also account
for downstream use in GPU-friendly and ML-native data structures
such as Pandas DataFrames, NumPy arrays, vectors, and tensors.
Standards must also address challenges with data flow between
EDA tool servers and GPU servers on ML training and inference
workloads. Enabling efficient, standardized exchange between these
environments is crucial for scalability and performance.
Toward building an ML EDA Commons, several initiatives are
underway. For example, model context protocol (MCP) has emerged
as a widely adopted means of enabling AI agents to interact
seamlessly with EDA tools [20]. In parallel, Silicon Integration
Initiative (Si2) working groups are actively defining schema and
developing ML EDA data pipelines that formalize how design data is
stored, transferred, and consumed [35]. Below, we highlight emerging
standards in ML EDA data formats and ML EDA dataflows.
1) ML EDA Data Formats: Data formats such as EDA
schema [30] and CircuitOps [18] have been established to aid ML
applications in physical design. A year ago, RDF-2024 introduced the
OpenROAD framework as a research playground for ML EDA using
CircuitOps [7]. It also presented CircuitOps [18] as a data format for
AI applications and provided a dataset in CircuitOps format. Since
then, two key updates have been made to CircuitOps. (1) New use
cases for CircuitOps have been added, for prediction of arc delays
and prediction of post-global routing timing path slacks [34]. (2)
Updates have been made to develop new CircuitOps APIs that utilize
underlying Python graph libraries such as the deep graph library
(DGL), and graph tool library APIs that are inherently built to be
GPU-friendly. These new APIs include the extraction of sub-graphs
of a netlist using graph view APIs of the graph tool library based on
features that are needed by specific ML applications.
2) ML EDA Data Pipeline: An Si2 working group announced last
year [35] has been developing standards in the form of an ML EDA
schema. This schema encompasses an EDA ontology, communication
protocols for transferring data between EDA tool servers and GPU
servers, and standard formats for describing datasets and ML models
in the EDA context. A key outcome of this effort is an ontology-
driven pipeline that integrates schema-based semantics with a gRPC
communication layer, enabling standardized data access and transfer
across heterogeneous EDA tools and computing environments.
The pipeline, illustrated in Fig. 2, supports schema-aware queries
from ML clients and translates them into structured requests on
the EDA server side. The server interprets queries using ontology
definitions, fetches the relevant data tables, and delivers the processed
dataset to the ML environment over gRPC. In the example shown, a
dataset in CircuitOps format serves as the data source, with Croissant
5
JSON files providing metadata to describe the CircuitOps schema.
The main components of this pipeline are:
1) Ontology (TTL). A formal resource description framework-
based ontology that captures core EDA entities such as De-
sign, Net, Cell, and Pin and their relationships (e.g., hasPin,
connectedTo), in TTL format, serving as the semantic back-
bone of the schema.
2) Croissant metadata. A JSON-LD specification that maps ontol-
ogy terms to the CircuitOps data source (IR tables and columns)
or other supported data sources, enabling automatic discovery
and retrieval of data.
3) gRPC protocol. A lightweight, Protobuf-based communication
channel that enables efficient cross-server data transfer between
ML and EDA environments.
4) Data source. A backend service that interprets gRPC requests
and returns schema-compliant datasets derived from the data
source – in this case, the CircuitOps IR tables.
C. Agentic Physical Design Flow
Significant advances in LLM-powered agentic EDA flow research
have been seen in areas such as HLS [36], RTL debugging [37], RTL
generation [38] and RTL verification [39]. However, progress has
been limited in the back-end EDA flow, as it faces more restrictions
such as end-user license limitations and reliance on proprietary
technologies. ChatEDA [40] and OpenROAD-Assistant [23] have
previously shown promise in tool-script generation for back-end
flows. In this year’s RDF paper update, we highlight both recent
contributions to, and an envisioned trajectory for, LLM-powered
back-end flows.
1) Datasets and LLMs for OpenROAD script generation: The
EDA Corpus [25] dataset and OpenROAD-Assistant [23], an assistant
chatbot for OpenROAD questions and OpenROAD Python script
generation, were highlighted in last year’s DATC efforts [5]. This
year, the EDA Corpus dataset has been expanded with (1) latest
APIs for OpenROAD; (2) dataset augmentation through paraphrased
prompts reflecting the tones and language of five distinct categories
of users; and (3) inclusion of scenarios with incorrect OpenROAD
API calls along with corresponding error and warning messages, to
support the training of agents that directly interact with OpenROAD.
Building on the updated EDA Corpus, a highlight of this year’s
RDF update is the work in [26], which has developed a framework
enabling direct, iterative interaction between OpenROAD and an
LLM to automatically improve the quality of scripts generated by
OpenROAD-Assistant. This approach improves the pass@k accuracy
from 70% with OpenROAD-Assistant to over 85%. Both the EDA
Corpus and the models and agents from [26] are available in
the OpenROAD-Assistant organization GitHub [58]. These works
highlight efforts to develop datasets and explore possible innovations
in agentic EDA training and deployment, driving research within a
future Commons.
2) OpenROAD-agent: Recently, coding agents such as Cursor,
Windsurf, etc. have greatly accelerated software engineering. Across
large corporations such as Microsoft with GitHub Copilot, as well as
small startups such as Y Combinator companies, a significant fraction
of all code being written is AI-generated. However, these coding
agents struggle to complete various basic tasks in the OpenROAD
ecosystem and more broadly within the EDA domain, be it working
with RTL or within RTL-to-GDS flows. This disparity in various
subareas of performance is downstream of any systemic issues in the
data pipeline (e.g., languages such as Python and C++ hold a much
larger share of code emphasized for LLM training than do Verilog and
TCL). At the same time, with the rise of coding agents as a whole,
effort has gone into on-demand, modular adaptation in parallel –
e.g., in MCP server configurations or rule- setting paradigms. That
is, given an existing coding agent which is barely performant in
OpenROAD or RTL, tooling exists to feed this agent context and
rules which will make it far more capable at such tasks – mirroring
the onboarding and training up of a human R&D software engineer
from novice to expert. Creating, engineering and dynamically feeding
in this context – to create capable agents that work on OpenROAD in
a way that intelligently harnesses the tailwind of development from
Cursor, etc. – offers a clear path forward.
We envision an eventual OpenROAD-agent which can examine,
analyze, act, and then iterate based on the results of its actions on
the broader OpenROAD ecosystem as a whole, rather than just OR-
AutoTuner. We anticipate that this agent will not be built on scratch,
but rather exist as a highly specialized fork of a leading open-
source coding agent such as Cline or Roo Code, with harnessing
atop the basal, unforked agent for handling Verilog and other PD-
specific languages and tooling, as well as the testing of atomic
changes therein. This is a natural extension of ORFS-agent. To
be more precise: ORFS-agent’s capabilities are around optimally
modulating Ray Tune and other third-party libraries essential to the
operation of ORFS, while OpenROAD-agent is focused on modifying
source code – especially around the key heuristics of mpl,dpl,
grt and so on. Figure 3 shows a roadmap of waypoints toward
the realization of OpenROAD-agent. Concretely, the envisioned
OpenROAD-agent builds concise yet complete context management
systems by converting the codebase into markdown files, creating
excellent EDA documentation on the fly. It then utilizes this set of
documents as an MCP server to further allow DSPy-based agents
to come up with implementable ideas within OpenROAD, perform
state of the art PR review, and interface with existing coding agents
(based on, e.g., Cline) which can act on this context to carry out
concrete commits and diffs. Upon diff completion, tests such as
compilation, regression testing, Coverity checks, etc. can certify the
diff as functional or otherwise.
Fig. 3: Roadmap to OpenROAD-evolve.
D. Contests and Hackathons
Last year, RDF-2024 presented details on the ICCAD 2024 Prob-
lem C contest on AI-based and GPU-accelerated Logic Gate Sizing.
This year, we highlight two other ML EDA contests and hackathons:
(1) MLCAD 2025 Contest on Logic Resynthesis (ReSynthAI) and
(2) ICLAD 2025 GenAI Chip Hackathon.
1) MLCAD 2025 contest on ReSynthAI: The ReSynthAI contest
aims to drive research in physically-aware resynthesis by providing
participants with post-floorplan designs (gate- level netlists and
floorplan DEF), requiring them to improve the post-global-route PPA.
Participants are free to apply any netlist transformation, such as
logic restructuring, gate sizing, Vt swapping, buffer insertion/deletion,
and pin swapping, as long as the resynthesized netlist remains
logically equivalent. The contest uses OpenROAD for placement,
global routing and timing analysis, and provides Python API-based
scripts to interact with the tool. In addition, ML-friendly CircuitOps
formats are released for the post-floorplan designs to make the data
6
Fig. 4: Flow for generating the ReSynthAI contest benchmarks.
accessible for ML and GPU-accelerated approaches without requiring
participants to understand LEF/DEF formats.
The contest released benchmarks in the ASAP7 technology node,
with designs spanning from 10K to 150K instances. The set includes
seven visible benchmarks and five hidden benchmarks, which will
be released publicly after the contest concludes. The benchmarks
were taken from the TILOS MacroPlacement repository [63] and the
IWLS 2005 benchmarks [64]. Each benchmark is synthesized from
RTL to gate-level netlist, and then floorplanned, using commercial
EDA tools. Next, the design is run through the flow until global
routing as shown in Fig. 4, using OpenROAD [1]. The post-floorplan
netlists, along with corresponding floorplan DEF and SDC constraints
files, are released to participants along with CircuitOps intermediate
representation (IR) tables. Timing numbers are obtained from Open-
ROAD’s timing engine, OpenSTA, using post-global route parasitics
from OpenROAD. The benchmarks and other contest scripts can
be found at [65]. This combination of standard EDA formats and
ML-friendly data enables reproducible experimentation and supports
research in physically-aware resynthesis.
2) ICLAD 2025 GenAI hackathon: The ICLAD GenAI hackathon
2025 challenged participants to apply LLMs as agents to four
different chip design problems, each having several benchmarks,
contributed by both industry and academia, across the RTL to GDS
flow [46]. The hackathon featured two tracks: the small language
model (SLM) challenge (less than 7B parameters), where participants
used SLMs on the edge, and an open challenge, which allowed the
use of cloud-based LLMs such as Gemini via GCP. Each problem
consisted of both visible and hidden benchmarks. Three of the
problems contributed by the industry were related to RTL design,
while Arizona State University contributed a Spec2Tapeout problem
that leveraged OpenROAD.
The Spec2Tapeout benchmarks include a variety of design specifi-
cations in JSON format, which encompass PPA constraints, the tech-
nology node for implementation, the module signature, examples of
required input and output, and a provided System Verilog testbench.
These benchmarks vary in their level of difficulty, with 10 visible
benchmarks open-source and five hidden benchmarks. Participants
are expected to develop an agent that utilizes the LLM to generate
RTL, verify the correctness of the RTL by running a simulation with
the provided testbench, generate the ORFS config.mk file, and run
yosys and OpenROAD to generate GDS.
V. ROADMAP UPDATE
RDF-2024 [5] set out a near- and long-term roadmap comprised
of six main targets: unifying repositories, fostering external con-
tributions, supporting open-source artifacts, expanding community
engagement, improving testcases and tools, and refining evaluation
standards. Over the past year, progress has been realized in open-
source artifact evaluation, new testcases and tools, and standardized
formats and data flows. Building on this foundation, the RDF-2025
roadmap highlights three priorities: (1) continuous integration and
testing, (2) calibrations and documentation of best-ever baseline
solutions, and (3) open challenges to expand community engagement,
some of which are carried forward from the previous year’s vision.
A. Continuous Integration
To ensure quality and replicability, we have initiated continu-
ous integration (CI) pipelines for RDF and will do the same for
OpenROAD-Research and ORFS-Research. These pipelines will au-
tomatically run regression tests across a diverse set of benchmarks,
PDKs and flow configurations. Beyond verifying functional correct-
ness, the CI system will track runtime and QoR metrics, following
standardized METRICS2.1 conventions. Every time a pull request is
accepted, the CI pipelines will execute and publish the corresponding
runtime and QoR results, providing a transparent and reproducible
evaluation of each contribution. Additionally, a Developer Certificate
of Origin (DCO) check will be enforced for all pull requests in
both OpenROAD-Research and ORFS-Research, ensuring contributor
authenticity and verifiable authorship.
B. Calibrations and Best-ever Baselines
A persistent gap in physical design research is the lack of
best-ever baseline solutions for widely-used benchmarks. Although
benchmarks (especially, contest benchmarks) have historically driven
innovation, the community continues to face inconsistent and even
contradictory results across publications. Absence of standardized
inputs, evaluation flows and verified baselines undermines repro-
ducibility and slows cumulative progress. To help mitigate this, we
plan to use OpenROAD-Research as a foundation for sustainable
calibration and baseline maintenance. OpenROAD-Research provides
the regression infrastructure, database compatibility and continuous
integration (CI) pipelines needed to ensure that benchmarks and
results remain valid and reproducible over time.
We plan to establish standard evaluation flows and reporting
methodologies (e.g., for runtime, QoR metrics and intermediate-stage
outcomes), ensuring comparability across research groups. We also
plan to establish a public leaderboard that is generated from verified
runs within OpenROAD-Research and that serves as the canonical
record of baseline solutions. Researchers can contribute new results
through pull requests (PRs), which undergo automated verification
before being merged.
Establishing best-ever baselines is not a one-time task, but a
continuous community-driven effort. We invite active engagement
and contributions of verified results, improved evaluation flows, and
help to maintain an open and rigorous leaderboard. Through collective
efforts, the research community can maintain archival records of best-
ever baselines and implementations.
C. Ongoing, Long-term Challenges
Despite significant progress made by the EDA research commu-
nity and the DATC RDF, several long-standing challenges demand
sustained attention. We summarize them here.
•Support for advanced packaging. As the semiconductor industry
shifts toward chiplets and 3D ICs, physical design flows must
evolve to accommodate heterogeneous integration, backside power
delivery and hybrid bonding connections. These emerging packag-
ing technologies require not only novel algorithms, but also open
databases and publicly available PDKs that can accurately describe
advanced packaging. Building reliable and free-access native P&R
engines for advanced packaging is also a critical next step.
•Lack of open PDKs for advanced technology nodes. The limited
availability of open PDKs at advanced nodes remains a major
7
barrier for innovation and reproducibility. The “Proxy Design
Enablement” concept introduced in previous DATC RDF releases
has provided a valuable approach and direction, but sustained
development of collateral IPs (from IO cells to memory compilers)
and community adoption are essential to support research.
•Scarcity of industry-grade designs for academic research. A
long-standing gap in academic research is the absence of large-
scale industry-grade testcases. Most approaches are evaluated only
on small academic testcases, which limits their generalizability to
real-world designs. Establishing such testcases within community-
maintained repositories is therefore essential. Recent efforts such as
the Artificial Netlist Generator (ANG) make steps toward scalable
parameterized testcases, but broader adoption and refinement are
required to narrow the gaps (difficulty, relevance, behavior through
the full optimization flow, etc.) between academic and industrial
testcases.
•Integration with the broader open EDA ecosystem. Sustainabil-
ity of open-source platforms such as OpenROAD-Research and
ORFS-Research depends on their ability to interoperate within
the broader open-source EDA ecosystem. It will be increasingly
necessary for CEDA DATC efforts to align and collaborate with
other efforts, such as Chipshub [32], the nascent OpenROAD
Initiative open-source ecosystem [33], and benchmarking initiatives
inspired by MLCommons. This can enhance visibility, adoption and
community engagement, thereby accelerating innovation through
shared infrastructure.
•Standardization of metadata and metrics reporting. The repro-
ducibility and extensibility of EDA research are often hindered by
the lack of standardized metadata formats and structured reporting.
Inspired by efforts such as MLCommons Croissant, which demon-
strates the benefits of a unified metadata schema, we advocate for
a similar convention tailored to the physical design domain. In
particular, design flows, configuration environments, tool versions
and QoR metrics (following our METRICS2.1 convention) could
be captured in a structured and machine-readable format. This
will facilitate better reusability, benchmarking and integration with
emerging ML tools.
VI. CONCLUSIONS
We have reviewed several highlights from the IEEE CEDA DATC
RDF efforts of the past year.
Public benchmarking and the ecosystem for research enablement
have advanced with the first-ever permission to publish benchmark re-
sults for a leading-edge commercial EDA tool, Siemens EDA’s Aprisa
v2025.2. Using open research enablements (NanGate45 and ASAP7)
and open-source testcases (AES, JPEG, Ariane, and BlackParrot),
fully reproducible results along with collateral flow and tool scripts
are published in the DATC [44] repository. With permission granted
by Siemens EDA, academic researchers are able to calibrate progress
against a commercial baseline. This provides a new foundation and
accelerator for academic research on EDA tool, flow and engine
development.
OpenROAD-Research and ORFS-Research provide new “contrib”-
style spaces to encourage global collaboration and accelerate in-
novation in physical design. Initial entries in OpenROAD-Research
include GPU-accelerated physical design engines (e.g., GPU-DPO)
and advanced engines for chiplet-based partitioning and packing
(ChipletPart). ORFS-Research provides a flexible sandbox to rapidly
prototype, integrate, and benchmark flow-level innovations. Initial
entries Multi-Plugin-Pin3D-Flow and ORFS-agent highlight the po-
tential for tracking of emerging challenges such as 3D integration
and AI-driven automation.
The vision of an ML EDA Commons has been strengthened
through advances in multiple components: datasets and benchmarks,
standard ML EDA data flows, agentic physical design flow, con-
tests and hackathons. New datasets such as interconnect buffering
benchmarks and the DALI-PD synthetic data generation framework
provide extensible foundations for ML training and evaluation. The
development of standards for ML EDA data formats and pipelines
reduces fragmentation seen across proprietary tools, and enables
consistent integration of ML models into physical design flows. For
LLM research in physical design, updates to the EDA Corpus dataset
and the development of OpenROAD-Agent are part of a broader
path toward interactive, context-aware coding agents for open-source
EDA toolchains. Finally, community contests and hackathons have
played an important role in shaping baselines. While these efforts lay
important building blocks for ML EDA Commons, gaps remain in
governance, incentives, and CI/CD pipelines. Addressing these gaps
will be essential for today’s fragmented efforts to coalesce into a true
Commons that accelerates progress and broadens participation in ML
for EDA.
Last, the IEEE CEDA DATC Roadmap aims to guide future
efforts that will strengthen open EDA infrastructure and community
collaboration. The roadmap emphasizes sustaining practices such as
continuous integration and the calibration and documentation of best-
ever baseline solutions. It also highlights both new and persistent
needs: advanced packaging support, open PDKs and foundation IPs,
industry-grade testcases, EDA ecosystem integration, and standard-
ized metadata reporting. To systematically fulfill these needs, DATC
will pursue coordinated community engagement, integration with
broader open-source initiatives, and the establishment of long-term
governance and incentives.
VII. ACKNOWLEDGMENTS
We would like to thank Andrew Johnson, Henry Chang, Sahrima
Jannat Oishwee and Simon Chang from Siemens EDA for their
collaboration and contribution to this publication. We thank Jiang
Hu, Sachin Sapatnekar, Siddharth Garg, Callie Hao and others for
discussions of “SLICE” and the framing of an ML EDA Commons.
This work is supported in part by the IEEE Council on Electronic
Design Automation.
REFERENCES
[1] T. Ajayi et al., “Toward an Open-Source Digital Flow: First Learnings
from the OpenROAD Project”, Proc. DAC, 2019, pp. 76:1-4.
[2] J. Chen et al., “DATC RDF-2019: Towards a Complete Academic
Reference Design Flow”, Proc. ICCAD, 2019.
[3] J. Chen et al., “DATC RDF-2020: Strengthening the Foundation for
Academic Research in IC Physical Design”, Proc. ICCAD, 2020.
[4] J. Chen et al., “DATC RDF-2021: Design Flow and Beyond”, Proc.
ICCAD, 2021.
[5] V. A. Chhabria et al., “Strengthening the Foundations of IC Physical
Design and ML EDA Research”, Proc. ICCAD, 2024.
[6] V. A. Chhabria, J. Hu, A. B. Kahng and S. S. Sapatnekar, “Invited:
Toward an ML EDA Commons: Establishing Standards, Accessibility,
and Reproducibility in ML-driven EDA Research”, Proc. ISPD, 2025.
[7] V. A. Chhabria et al., “OpenROAD and CircuitOps: Infrastructure for
ML EDA Research and Education”, Proc. VTS, 2024.
[8] A. Ghose, A. B. Kahng, S. Kundu and Z. Wang, “ORFS-agent: Tool-
Using Agents for Chip Design Optimization”, Proc. MLCAD, 2025.
[9] J. Jung et al., “DATC RDF: An Academic Flow from Logic Synthesis
to Detailed Routing”, Proc. ICCAD, 2018.
[10] J. Jung, I. H.-R. Jiang, G.-J. Nam, V. N. Kravets, L. Behjat and Y.-L. Li,
“OpenDesign Flow Database: The Infrastructure for VLSI Design and
Design Automation Research”, Proc. ICCAD, 2016, pp. 42:1-6.
[11] J. Jung et al., “METRICS2.1 and Flow Tuning in the IEEE CEDA Robust
Design Flow and OpenROAD”, Proc. ICCAD, 2021.
[12] J. Jung et al., “IEEE CEDA DATC: Expanding Research Foundations
for IC Physical Design and ML-Enabled EDA”, Proc. ICCAD, 2022.
8
[13] J. Jung et al., “IEEE CEDA DATC Emerging Foundations in IC Physical
Design and MLCAD Research”, Proc. ICCAD, 2023.
[14] J. Jung et al., “DATC RDF: Robust Design Flow Database”, Proc.
ICCAD, 2017, pp. 872-873.
[15] D. Junkin, “Supporting the Scientific Method for the Next Generation
of Innovators”, DAC-2022 BoF Open-Source EDA and Benchmarking
Summit. https://open-source-eda-birds-of-a-feather.github.io/doc/slides/
BOAF-Junkin-DAC-Presentation.pdf
[16] A. B. Kahng, “Looking Into the Mirror of Open Source”, Proc. ICCAD,
2019.
[17] A. B. Kahng, Y. Liu and Z. Wang, “Recursive Learning-Based Virtual
Buffering for Analytical Global Placement”, Proc. MLCAD, 2025.
[18] R. Liang et al., “Invited Paper: CircuitOps: An ML Infrastructure
Enabling Generative AI for VLSI Circuit Optimization”, Proc. ICCAD,
2023.
[19] R. Liang et al., “BufFormer: A Generative ML Framework for Scalable
Buffering”, Proc. ASP-DAC, 2023, pp. 264-270.
[20] Y. Lu et al., “AutoEDA: Enabling EDA Flow Automation through
Microservice-Based LLM Agents”, arXiv:2508.01012, 2025. https://
arxiv.org/pdf/2508.01012
[21] S. S. Kiran Pentapati et al., “Pin-3D: A Physical Synthesis and Post-
Layout Optimization Flow for Heterogeneous Monolithic 3D ICs”, Proc.
ICCAD, 2020.
[22] Y. Shi et al., “Open3DBench: Open-Source Benchmark for 3D-IC
Backend Implementation and PPA Evaluation”, arXiv:2503.12946, 2025.
https://arxiv.org/abs/2503.12946.
[23] U. Sharma et al., “OpenROAD-Assistant: An Open-Source Large Lan-
guage Model for Physical Design Tasks”, Proc. MLCAD, 2024.
[24] B.-Y. Wu et al., “2024 ICCAD CAD Contest Problem C: Scalable
Logic Gate Sizing Using ML Techniques and GPU Acceleration”, Proc.
ICCAD, 2024.
[25] B.-Y. Wu et al., “EDA Corpus: A Large Language Model Dataset for
Enhanced Interaction with OpenROAD”, Proc. LAD, 2024.
[26] B.-Y. Wu et al., “OpenROAD Agent: An Intelligent Self-Correcting
Script Generator for OpenROAD”, Proc. ICLAD, 2025, pp. 16-22.
[27] B.-Y. Wu and V. A. Chhabria, “DALI-PD: Diffusion-based Syn-
thetic Layout Heatmap Generation for ML in Physical Design”,
arXiv:2507.10606, 2025. https://arxiv.org/abs/2507.10606
[28] D. Kim et al., “Machine Learning Framework for Early Routability
Prediction with Artificial Netlist Generator”, Proc. DATE, 2021.
[29] V. A. Chhabria et al., “BeGAN: Power Grid Benchmark Generation
Using a Process-portable GAN-based Methodology”, Proc. ICCAD,
2021.
[30] P. Shreshta et al., “EDA-schema: A Graph Datamodel Schema and Open
Dataset for Digital Design Automation”, Proc. GLSVLSI, 2024.
[31] Si2 LLM Benchmarking Coalition Kicks off.
https://si2.org/si2-llm-benchmarking-coalition-kicks-off/
[32] Chip Design Hub: Open, Accessible and Scalable Infrastructure for
Research and Education. https://www.nsf.gov/awardsearch/showAward?
AWD ID=2427391&HistoricalAwards=false
[33] POSE: Phase II: Growing a Collaborative Ecosystem for Open-Source
Chip Design Using OpenROAD. https://www.nsf.gov/awardsearch/
showAward?AWD ID=2449356&HistoricalAwards=false
[34] Z. Guo et al., “A Timing Engine Inspired Graph Neural Network Model
for Pre-routing Slack Prediction”, Proc. DAC, 2022.
[35] Q2 2024 CEO Message. https://si2.org/q2-si2-newsletter/
[36] K. Xu et al., “Automated C/C++ Program Repair for High-Level
Synthesis via Large Language Models”, Proc. MLCAD, 2024.
[37] N. Wang et al., “VeriDebug: A Unified LLM for Verilog Debugging via
Contrastive Embedding and Guided Correction”, Proc. ICLAD, 2025.
[38] J. Tang et al., “HiVeGen – Hierarchical LLM-based Verilog Generation
for Scalable Chip Design”, Proc. ICLAD, 2025, pp. 30-36.
[39] Y. Bai, G. B. Hamad, S. Suhaib and H. Ren, “AssertionForge: Enhancing
Formal Verification Assertion Generation with Structured Representation
of Specifications and RTL”, Proc. ICLAD, 2025, pp. 85-92.
[40] H. Wu et al., “ChatEDA: A Large Language Model Powered Au-
tonomous Agent for EDA”, IEEE TCAD, 43:10 (2024), pp. 3184-3197.
[41] J. Xun et al., “CircuitNet 2.0: An Advanced Dataset for Promoting
Machine Learning Innovations in Realistic Chip Design Environment”,
Proc. ICLR, 2026.
[42] ACM Artifact Review and Badging. https://www.acm.org/publications/
policies/artifact-review-and-badging-current
[43] Artifact evaluation. https://github.com/ctuning/artifact-evaluation/blob/
master/docs/reviewing.md
[44] First-Commercial-Benchmarking-SiemensEDA Repo. https://github.
com/ieee-ceda-datc/First-Commercial-Benchmarking-SiemensEDA
[45] FreePDK45. https://github.com/The-OpenROAD-Project/
OpenROAD-flow-scripts/tree/master/flow/platforms/nangate45
[46] ICLAD GenAI Chip Hackathon @ DAC 2025.
https://github.com/ICLAD-Hackathon/ICLAD-Hackathon-2025
[47] V. A. Chhabria, “Standardized ML EDA Data Pipelines with Ontology-
driven Data Mapping”,
https://github.com/open-source-eda-birds-of-a-feather/
open-source-eda-birds-of-a-feather.github.io/blob/main/doc/slides
2025/ASU-Drexel-Si2-ML-EDA-data-pipeline.pdf
[48] IEEE CEDA DATC Robust Design Flow.
https://github.com/ieee-ceda-datc/Robust-Design-Flow
[49] IEEE CEDA DATC Robust Design Flow Calibration.
https://github.com/ieee-ceda-datc/datc-rdf-calibrations
[50] IEEE CEDA Design Automation Technical Committee.
https://ieee-ceda.org/node/2591
[51] MLCAD2024 Artifact Evaluation.
https://github.com/ml-eda/artifact-evaluation
[52] NanGate45-Synopsys-Enablement. https://github.com/ABKGroup/
NanGate45-Synopsys-Enablement
[53] NSF Workshop on Shared Infrastructure for Machine Learning EDA,
March 2023. https://sites.google.com/view/ml4eda/home
[54] OpenCores. https://www.opencores.org/
[55] OpenROAD-Flow-Scripts.
https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts
[56] ORFS-agent GitHub. https://github.com/ABKGroup/ORFS-Agent
[57] OpenROAD-Assistant. https://github.com/OpenROAD-Assistant/
OpenROAD-Assistant
[58] OpenROAD-Agent. https://github.com/OpenROAD-Assistant/
OpenROAD-Agent
[59] OpenRCX. https://github.com/The-OpenROAD-Project/OpenRCX
[60] OpenSTA. https://github.com/The-OpenROAD-Project/OpenSTA
[61] P. Haspel and A. Hwang, personal communication, December 2022.
[62] The OpenROAD Project (GitHub). https://theopenroadproject.org and
https://github.com/The-OpenROAD-Project/OpenROAD
[63] TILOS-AI-Institute/MacroPlacement.
https://github.com/TILOS-AI-Institute/MacroPlacement
[64] IWLS 2005 Benchmarks. https://iwls.org/iwls2005/benchmarks.html
[65] MLCAD 2025 Contest on ReSynthAI: Physical-aware Logic
Resynthesis using AI. https://github.com/ASU-VDA-Lab/
MLCAD25-Contest-Scripts-Benchmarks
[66] “National Science Foundation Workshop: “ImageNets” for EDA”, ac-
cessed: 2025-01-18. [Online]. https://wp.nyu.edu/imagenets eda/.
[67] “Pathways to enable open-source ecosystems (POSE)”, accessed:
2025-01-18. [Online]. https://www.nsf.gov/funding/opportunities/
pose-pathways-enable-open-source-ecosystems.
[68] “Google AI-driven Chip Design”
https://rsvp.withgoogle.com/events/chip-design-workshop
[69] “SLICE: A Shared Machine Learning Infrastructure for the EDA Com-
munity”. https://slice-ml-eda.github.io/
[70] The MLBuf repository. https://github.com/ABKGroup/MLBuf MLCAD
[71] OpenROAD gate resizer (rsz). https://github.com/
The-OpenROAD-Project/OpenROAD/tree/master/src/rsz.
[72] OpenROAD-Research.
https://github.com/ieee-ceda-datc/OpenROAD-Research
[73] ORFS-Research. https://github.com/ieee-ceda-datc/ORFS-Research
[74] Buffering Benchmarks.
https://github.com/ieee-ceda-datc/Buffering-Benchmarks
9
