Solvers, Engines, Tools and Flows: The Next Wave for AI/ML in Physical Design

It has been six years since an ISPD-2018 invited talk on "Machine Learning Applications in Physical Design". Since then, despite considerable activity across both academia and industry, many R&D targets remain open. At the same time, there is now clearer understanding of where AI/ML can and cannot (yet) move the needle in physical design, as well as some of the difficult blockers and technical challenges that lie ahead. Some futures for AI/ML-boosted physical design are visible across solvers, engines, tools and flows - and in contexts that span generative AI, the modeling of "magic" handoffs at flow interstices, academic research infrastructure, and the culture of benchmarking and open-source EDA.


INTRODUCTION
The ISPD-2018 invited paper [25] is one in a trajectory of works proposing how AI/ML would change physical design. 1 Six years after [25], we see that (i) more than half of the research papers at leading EDA conferences now involve applications of machine learning; (ii) AI/ML pervades the product offerings of major EDA vendors; and (iii) the latest wave of large language models and generative AI is everywhere.With this backdrop, this paper gives some personal thoughts on near-term futures for AI/ML in physical design through the lens of "solvers, engines, tools and flows".In 2018, a future ecosystem (Figure 1) was envisioned wherein EDA suppliers would open up their tool knobs, thus enabling new AI/ML models for tools and designs, alongside discovery of new optimization objectives for core EDA engines.Designers would identify pain points and supply training and validation data to researchers, who would develop new design-adaptive tool and flow guidance, along with tool outcome predictors.Improved tools and private-label AI models would then increase the value of commercial design technology to users.Unfortunately, the envisioned ecosystem did not materialize, for reasons that include the lack of (i) accessible EDA tool knobs, and (ii) solutions to the data problem.Hence, many "target list" items from six years ago [24][25][26] are still open.
Figure 1: 2018 vision of a future Vendor-Designer-Researcher ecosystem for AI/ML in EDA.From [24].
Also in 2018, Figure 2 from [25] proposed four oncoming stages of ML insertion into PD tooling.ML developments since then reflect this path, and are typically grouped into three main categories: prediction, optimization and generation [52].Prediction applies supervised learning to predict design QoR metrics [32], with many endeavors spanning power prediction [49], timing prediction [16], congestion prediction [54], etc. Optimization applies Bayesian optimization (BO) or reinforcement learning (RL) to directly optimize EDA problems.AutoDMP [1] wraps BO around DREAMPlace [43] to achieve superior macro placement solutions.The earlier work [50] applies RL to macro placement.Generation applies generative models (GANs or transformers) to directly generate solutions to EDA problems, e.g., [57] uses GANs to synthesize realistic layout patterns, and [51] develops a transformer-based gate sizer that optimizes a given placed and unoptimized netlist.Generative approaches struggle with consistent delivery of well-formed solutions, hance are often used to obtain good initial (ballpark, or hint) solutions for traditional methods.At the same time, the rapid advance in areas such as Large Language Models (LLMs) bring hopes of widespread application in EDA and design [17].
Overall, the past six years have brought clearer understanding of where AI/ML can and cannot (yet) move the needle, and of nearterm challenges.Some takeaways: • Successes include black-box hyperparameter optimization (e.g., Cadence Cerebrus and Synopsys DSO.ai), i.e., a form of AI/ML "around" the tool.ML has also shown promise to speed up analyses that range from routability and congestion to EM/IR and temperature.• Disappointments include the increasing difficulty of extracting runtime data or applying ML inference results, in the regime of an industry duopoly and closed tool "silos".Prospects for companies sharing data, or public foundation models, are poor.Further, costs of machine learning have turned out to be significant.And, prediction is difficult.• Surprises include the rush to LLMs and generative AI, which aligns with reduced visibility of users into tools.
1.2 A Lens of Solvers, Engines, Tools and Flows.Figure 3 depicts a hierarchy of design technology elements, along with the applicability of various boosters such as cloud deployment or ML "inside".
• Solvers at the base of the hierarchy typically correspond to combinatorial methods (ILP, SAT, DP), often with performance bounds.An example application is clip-based, optimal place-and-route [8,20].Multithreading, GPU and cloud can slightly advance the size of solvable instances, but ML (e.g., RL or L2O) has not had impact in practice.[21,37]) that improve quality and stability of outcomes obtained within schedule limits.
• Flows such as SoC floorplanning invoke multiple tools, often with feedback loops, to achieve major design goals.Inherent complexity, long runtimes and chaotic behaviors make flows resistant to techniques such as reinforcement learning.On the other hand, improved results can be obtained via sampling and autotuning with cloud resources.
It is important to consider where ML can be applied -"inside" or "around" [27].Figure 3 indicates that ML "around" has applications across solvers through flows, e.g., by autotuning of hyperparameters, commands and options.ML "inside" has been less tractable, absent infrastructure that can save and leverage data from past design experiences or tool/flow runs.Such infrastructure has been suggested for decades [12,21,31], but is blocked by a missing consensus on open standards for data models, naming and APIs.
It is also crucial to comprehend the breadth of challenges and limits seen today for ML in PD: optimization quality of results; data; scalability; generalization; validations; and cost.Three of these stand out: (1) Optimization baselines are strong.ML has struggled to show benefit for problems that have well-studied formalisms and combinatorial methods.Metaheuristics such as annealing or genetic algorithms also give strong baselines.And, humans still come up with the most useful cost functions.(2) ML has not handled scale well.For example, RL and L2O have proved too data-heavy relative to design complexities and resource limits.This heightens interest in problem decomposition and discovery of useful hierarchy, especially at the front end of chip implementation.(3) Chaos is still with us.E.g., perturbing target clock period by 0.1ps may change post-P&R netlist area by 10%.Thus, sampling remains a workhorse for improved solution quality and stability, with little involvement of ML. (4) Accuracy bars are high for ML-boosted PD to have value in production.

PD CHALLENGES AND LEVERS
This section briefly reviews selected challenges and key levers for PD (see also [25,28]).

PD Challenges.
Floorplanning and placement have become severe pain points in PD, due to rapid growth of SoC design complexity in concert with the move to advanced nodes.Some emerging challenges are as follows. 2esign partitioning and block shaping.Growing design complexity has collided head-on with superlinear tool runtimes and tighter design schedules.Designers must partition huge designs into small (e.g., 1-2 million instances) blocks.The coevolution of a P&R tool with its typically small-sized R&D regression and customer benchmark testcases means that the tool ends up being highly tuned for small blocks.On the other hand, having more small blocks in the SoC floorplan creates an explosion of complex rectilinear block shaping, pin/port placement, macro placement (or partitioning), channel definition, and floorplan brittleness.In the end, whether to split a design into a smaller number of large blocks with long runtimes, or into a larger number of small blocks with short runtimes, depends on the P&R tool as well as the design.Corollary challenges include budgeting, assembly, signoff, and even the movement to 2.5D/3D.Placement-aware hierarchical floorplanning.Placement-aware (or macro placement-aware) hierarchical floorplanning must also make decisions based on some underlying model of the placement tool's behavior.The placer is exquisitely sensitive to macro locations, block shaping and boundary terminals, and floorplan constraints (fences, regions, guides, (hard/partial/FF) blockages, etc.).Applying the right floorplan constraints can condition the placement canvas and steer the tool toward dramatic improvements of solution quality metrics such as timing or congestion.However, robust methods to synthesize such "magic" floorplans and screens remain elusive [25].
Datapath-aware floorplanning.In many application markets, high-performance datapath modules are essential to competitive success, and layout solutions may be replicated thousands of times in tiled architectures.As had preceded a 1990s wave of datapathfocused EDA offerings [28], today's tools often produce unacceptable misalignment and tangling of datapaths in P&R.Datapathaware floorplanning entails intelligent pre-placement and fixing of PPA-critical flip-flops and standard cells -after synthesis and before placement -again, to properly condition the placement canvas and steer the tool to good results.How to select and place the fixed instances in the datapath-aware floorplan has also been elusive.
Drive for area reduction.With the slowdown of scaling and increasing wafer cost per transistor, die utilization is now a permanent first-class concern.Cost reductions are sought by squeezing whitespace out of the SoC floorplan, but this is challenging since (i) block shapes interact in the SoC floorplan, and (ii) chaos in the implementation flow generally worsens with more aggressive PPA targets (cf."Sampling for Stability" in the next subsection).Corollaries of area squeezing include adoption of hybrid cell row architectures at the foundry 3nm node [28,67] to enable flexible mixing of drive strengths (i.e., fin counts).Use of hybrid row heights (e.g., 117, 169, 286nm in a single P&R block) severely challenges the entire PD flow, from physical synthesis that must predict and manage density distributions of cell heights, to sizing and ECO optimizations whose cost landscapes become less smooth.

Levers to Advance PD.
Four high-impact levers to advance PD are (i) GPU-based speedups; (ii) use of cloud resources; (iii) use of sampling to gain stability; and (iv) a "multi-spectral" mindset to obtain more data for ML in a given time.
GPU-based speedups.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.Design schedule constraints therefore induce complex design partitioning and block shaping challenges.In this context, massively parallel modern GPUs provide a natural computational substrate for acceleration of physical design [19,42,56].Table 1 lists efforts in this direction that span much of the PD flow.
A key goal for GPU-based acceleration of optimization and ML is to shorten the time to useful PPA feedback, thus enabling faster and more accurate exploration of architecture and chip floorplan  Cloud.Another lever for PD is the mainstreaming of EDA in the cloud.Current tools and algorithms follow software patterns optimized for single-GPU engineering workstations, leaving huge opportunities to scale efficiency and capacity. Figure 5(a) shows how in OpenROAD, distributed incremental detailed routing is sped up by ∼ 100× in the cloud, using 20 16-core workers.Overheads of serialization and task distribution limit the achievable cloud-based speedup for this code, as shown in the figure.Figure 5(b) shows how pin access analysis, which is performed at the start of detailed routing, is sped up by 30× using cloud instances as opposed to a single machine.In general, having more machines available to AI orchestration will enable richer patterns of exploration and exploitation.Potentially, some optimization threads can explore the basic flow even as others explore floorplans, cell/corner options, and other high-impact decision points.
Sampling for Stability.Outcomes of physical design are chaotic, especially when tools and flows are driven to "try harder" (e.g., to achieve higher die utilization in costly advanced nodes).The chaotic behavior is due to the complex interactions of many internal metaheuristics [7,28].Figure 6(a) shows noise in the output  Effective Clock Period (ps) netlist metrics of 201 runs of a commercial logic synthesis tool, for the AES design in a GLOBALFOUNDRIES 12nm (triple-VT) enablement.Figure 6(b) shows results from 201 P&R runs for each of five input netlists (i.e., a total of 1005 P&R runs). 3Two box and whisker diagrams show area distributions for two additional sets of 1005 P&R runs; these sets respectively comprise 201 P&R runs starting from each of the five lowest-area (respectively, highestarea) post-synthesis netlists.This confirms large tool noise as well as relatively poor correlation between the synthesis and P&R flow steps.To mitigate this and improve stability of PD outcomes, cloud deployment of optimizers seems inevitable.
Multiple Views in Unit Time: Tomography.In a number of domains, terms such as "multi-spectral imaging" or "sensor fusion" refer to the use of multiple views of an object to enhance identification or analysis.An analogous term, tomography, involves creating multiple images to provide detailed insights into the human body or various solid objects.At UCSD, the idea of tomography in placeand-route has led to techniques that generate many views of a given design within the same walltime that is needed for one view -along with use of these many views to achieve better optimization or ML modeling.
A specific example of tomography in P&R uses the Cadence Innovus early global router (eGR) to generate congestion reports under various routing blockage conditions.eGR is much faster than traditional detailed routing (e.g., runtime of < 1 second, versus 1.5 hours), which enables generation of hundreds of congestion reports for different routing blockages near-instantaneously when run in parallel.Figure 7 shows seven congestion reports generated using eGR, each with a different partial density value for the routing blockage covering the design. 4The congestion report has closest alignment to actual DRC markers when the partial density value is 75.But, using all of the images in this placement tomography improves ML model accuracy in congestion or DRC hotspot prediction.

ELEMENTS OF A NEXT WAVE
This section gives several elements of a "next wave" for AI/ML in IC physical design.These include the onrush of generative AI, continuing to seek "magic" conditioning of problem instances at flow interstices, infrastructure for ML, and overdue culture changes. 5

Generative AI.
Across the technology world, generative AI has "taken all of the oxygen out of the room", and EDA and IC design are no exception.Generative AI does not afford solvers or optimizers in the usual sense: failure rates can be high, so answers require checking and correction.Nevertheless, GenAI has found use cases where guesses can be discarded (if wrong) or else improved.It is very likely generative AI methods -spanning from language to graphs -will soon be pervasive in PD.Applications include interactive tool help, design goal-specific tool and flow recipes, script and HDL code debugging (e.g., [53]) and copiloting, virtual teaching assistants, and more.( [17] provides a more far-ranging perspective than is possible here.) In the near term, EDA and IC design companies will leverage LLMs along three main vectors.(i) LLM-based design assistants will provide a chat interface to answer various types of designer queries about the tool, design, or technology.(ii) Prompt-based tool flows will provide live feedback between the tool and the user using prompts, leveraging a combination of LLMs and deep learning models (predictors of downstream flow outcomes, recommenders for flow recipes, etc.).(iii) Graph generative models will be the basis for fast, incremental physical synthesis, place-and-route and optimization that works on the cones of logic affected by incremental changes to RTL, netlist, constraints or floorplan contexts.The second and third vectors, if successful, can potentially revolutionize designer productivity -but perhaps not end quality of outcomesin physical design.
Broadly speaking, generative methods (and, AI in general) are likely to see adoption in contexts where humans are not in competition with the AI, and are happy to be relieved of mundane, tedious tasks.What humans dislike creating (e.g., documentation, verifications, and tests) will provide the initial applications for generative methods.ChipNeMo [46] applies domain adaptation methods to optimize LLMs for three such tasks -chatbot assistant, tool script generation, and bug summarization.
Whether GenAI can overcome well-recognized blockers remains to be seen.Data for model training must rely on a mix of real and synthetic data; it is unclear whether synthetic data that safeguards IP rights can be produced using real samples as seeds, and then released into the wild.Generalization will depend on data quality and whether general methods -as opposed to models specialized to a few canonical types of IC designs and design styles -are needed.Cost will presumably be attacked using pre-trained models plus fine-tuning, as well as model compression and sparsification.Debugging and diagnosing the inevitable incorrect predictions and hallucinations will require task-specific checkers and debuggers.Other application domains will also develop methods to detect and prevent hallucinations.
Notwithstanding the above, other factors may lead to less rosy futures for generative AI in PD and chip implementation.Three examples: (i) insufficient training data for the ML models that underlie EDA flow control; (ii) data poisoning and improper use of copyrighted materials that increase cost and risk of GenAI models; and (iii) LLM successes seen only in applications for which large amounts of public data are available for training (e.g., small PyTorch scripts, Copilot for Verilog coding).

ML at Interstices.
[25] and contemporaneous works set out a number of R&D targets for ML and physical design.In the arena of predictive modeling of tools and designs, these were often referred to as "magic" -netlists, floorplans, corners and constraints, etc.For example, it was observed that a single netlist is handed off from logic synthesis to place-and-route, and that a challenge for AI/ML was to generate "magic" recipes to produce a best-possible netlist at this handoff point.
The left side of Figure 8 lists a number of coevolutions and cooptimizations that correspond to interstices between flow steps.There is opportunity for "magic" at these interstices because the tools and corresponding flow steps are typically developed and executed "at arm's length".Recent years have made it clear that "prediction is difficult": the field has not achieved usable predictors of subflow outcomes, such as post-route design rule violations from a global placement, given the high cost of prediction errors.Work at UCSD instead seeks methods to condition the problem instance that is passed forward at a given interstice between flow steps.As noted in the discussion of placement-aware hierarchical floorplanning, a placement problem instance can be conditioned by adjusting target density and cell padding, and/or by adding placement and routing blockages.Relatively simple adjustments of target density at the start of placement can yield substantial improvements of post-route-opt wirelength, total power, WNS and TNS metrics.Or, for a fixed placement, proper conditioning of the routing problem with routing blockages (per-region and per-layer; recall Figure 7) can dramatically reduce post-route DRCs.We refer to such routing and placement blockages as "magic screens".An important goal is to develop ML-based generation of magic screens that will reduce design iterations while improving PPA.

Infrastructure for ML.
OpenROAD and CircuitOps.While ML -including various forms of generative AI -has been a rapidly growing field of EDA research, this area still lacks dedicated research infrastructure: (i) Python APIs in EDA tools for faster data generation, (ii) a standard format for data representation and data sharing, and (iii) a Python interface with EDA tools to enable a feedback path from ML algorithms back into the EDA platform.As shown in Figure 9 the OpenROAD project [2] and NVIDIA's CircuitOps [36,61] have recently made progress together in addressing these challenges. 6This has enabled a new, open-source "playground" for ML-EDA researchers.Specifically, (i) Python APIs in OpenROAD wrap the underlying C++ APIs of its EDA engines, which enables faster data generation compared to using commercial tools' TCL interfaces.(ii) NVIDIA's CircuitOps leverages OpenROAD to model chip data as labeled property graphs, and uses pandas data frames to store graph properties as features.(iii) CircuitOps further leverages recently-added Python APIs in OpenROAD as a feedback loop to interact with the ML algorithms.The recent ASP-DAC 2024 tutorial [59] demonstrates a reinforcement learning-based gate sizer which uses this feedback loop in OpenROAD to perform gate sizing.7   Efforts to develop open proxies (PDKs, design enablements, tools and designs) seek to remove this obstacle [22].
For example, when creating a proxy design enablement the design-and research-relevant characteristics of a source technology should match the corresponding characteristics of a target PDK.In Figure 10(a), source is the ASAP7 academic research PDK, while target is a commercial 7nm foundry technology.The plot shows the Power versus Effective Clock Period "hockey stick" for ten target clock periods.Simple scaling of ASAP7 delay and power can bound (red, purple) outcomes from the foundry 7nm enablement (green).Autotuning with Ray/Tune [37,65], using simple tuning parameters (delay, pin capacitance, internal/switching power, setup/hold times) and a loss function of Mean Absolute Percentage Error across the 10 target clock periods, yields the blue hockey stick with loss function value of 11%.Open design testcases, along with infrastructure for proxy cell library creation and design-technology co-optimization [11,64] and artificial-but-realistic netlist generation [33,58], are rapidly coming online.There is also opportunity for ML to take us deeper in the context of proxies and matching.For example, sufficient analysis data might enable deeper ML-based approximation of the design enablement -down to BSIM models, RC extraction techfiles, and even etch and CMP models.Indeed, this may be inevitable, as there is an "analog hole" for design analysis information, and because "it's just physics" after all.
Among the hallmarks of a mature technical field are that (i) reported results are reproducible, and (ii) progress can be clearly measured -because we "Measure, to Improve".To enable reproducibility of their reported results, PD researchers can now post Tcl scripts for research purposes, with proper acknowledgment of the interests of the tool suppliers.This has been an amazing breakthrough, and kudos are due to the EDA vendors for making this policy change [23].However, as a community, we do not yet require papers with code or award badges for excellent opensource collaterals.And, benchmarking of commercial EDA remains forbidden.
Can we accelerate culture changes that move the research leading edge toward benchmarking and open source?There is no question that benchmarking and benchmarks will accelerate the (transparent, reproducible) improvement of optimizers, baselines, and in-context assessments.Similarly, there is no question that open infrastructure, open proxies, and open-source EDA will accelerate data generation that feeds the learning of objectives and the discovery of more impactful AI/ML methods (cf. the "AI flywheel").This would be true for AI/ML both "inside" EDA and "around" EDA, with the A final, cautionary note: Transparency and reproducibility are not a substitute for research integrity, and can still be swamped by marketing hype and other "noise".Rigorous empirical evaluationusing public data -of claimed improvements to solvers, engines, tools and flows is increasingly important to preserve a healthy research ecosystem in PD and EDA [10].Fortunately, such empirical evaluation is embarrassingly parallel and amenable to automation.

CONCLUSIONS
Over the six years since ISPD-2018 and [25], researchers have incorporated AI/ML methods into nearly every core area of physical design.EDA vendors have achieved commercial successes, notably with hyperparameter optimization (autotuning) around SP&R, but also in verification, PCB and advanced packaging layout, and other areas as well.Interestingly, the "half a node's progress" [60] from wrapping an autotuner around digital SP&R lends support to longstanding claims that commercial EDA had left over a node of optimization QoR scaling on the table.AI/ML will play an important part in clawing back semiconductor value via "the last scaling levers" of quality, cost and schedule. 8One might ask: Will ISPD-2030 have a papers-with-code requirement, and award a prize for best-curated open-source repository?By 2030, will there be a journal of open-source design and design automation -or, of confirmation studies?And, will there be a neutral organization that measures and reports on the progress of EDA technology?
The adoption of AI/ML in PD has generally followed the taxonomy and sequencing proposed in [24][25][26] (Figures 1, 2).However, blockers have emerged from the closed nature of commercial tool silos, and from the lack of open infrastructure, data and sharing mechanisms that would enable an "AI flywheel" for the PD research community [62].For target list items proposed in 2018, comparatively more progress has been made on estimations of physics analyses (delay, crosstalk, power, IR, thermal), while less progress has been made on predictors of syntheses and optimizations (particularly, extremal criteria such as worst path timing or overcongestion in routing hotspots).Many of the target list items remain open today.
The context for research going forward includes basic realizations: (i) optimization baselines are hard to beat (and accuracy bars are high), so ML will take aim at new, less-formal and/or mechanical challenges; (ii) ML has not scaled well to large instances; and (iii) best-performing metaheuristics are chaotic at their QoR limits.Some challenges, such as predicting outcomes of long multi-stage subflows, or reusing training data and models across designs, tools and foundry nodes, will likely prove quite stubborn.Following are just a few out of many threads to watch for in the coming years.
• ML-boosted automations in production for lower-hanging fruits: floorplan squeezing, datapath-aware floorplanning, and smallscale end-case optimizations (e.g., detailed placement for routability, post-route-opt DRC fix, gate sizing).• Production-worthy ML methods to condition problem instances with "magic" screens, corners, and/or constraints at one or more interstices of the flow (Figure 8).• Critical mass, usability and sustaining mechanism for an open ML EDA infrastructure that provides researchers with a spinning AI flywheel (i.e., running "on the exhaust of data") and reference ops pipelines.
• Advancement of open-source EDA and proxy research enablements through efforts such as OpenROAD [2], iEDA [34], Cir-cuitOps [61] and the IEEE CEDA DATC [65].• Commercial success -based on dominating QoR, cost, and runtime -of generative AI methods for prompt-based flow control and for incremental PD optimizations.• Industry acknowledgment of the value of sampling and cloud scaling -and of the much greater resources that are needed to unlock AI/ML benefits with these levers.• Widespread adoption of generative AI-infused training modules across levels (high school through re-skilling and up-skilling) for IC physical design and design automation.• Advancement of culture in a healthy PD research community, to seek and reward transparency, reproducibility, and benchmarking to measure progress.

ACKNOWLEDGMENTS
Many thanks to Sayak Kundu, Bodhisatta Pramanik, Zhiang Wang and Dooseok Yoon for their help with the figures and text in this paper.Discussions with Siddhartha Nath, Igor Markov, Chuck Alpert and Ilgweon Kang are also gratefully acknowledged.Research at UCSD is partially supported by DARPA, Samsung, the C-DEN center, and gifts from Google, Intel and others.

Figure 4 :
Figure 4: Placements from (a) RePlAce, (b) Commercial placer, and (c) a new academic GPU-accelerated placer.options.At the same time, classical electrostatics-based global placement engines such as OpenROAD's RePlAce [9, 63] can miss designlevel perspective.Figures 4(a), (b), and (c) respectively show global placement results of RePlAce, a commercial placement tool, and a new GPU-accelerated academic tool for the MemPool Cluster RISC-V design [5], which has 9.5M instances and nearly 1300 macros in NanGate45 technology.The new placer substantially reduces runtime while maintaining solution quality in terms of post-placement half-perimeter wirelengths, along with early global route (eGR) wirelength and congestion metrics reported by Cadence Innovus 21.1.Advances in speed, quality and scalability from GPU-based acceleration can potentially revolutionize architecture, RTL and floorplan exploration -orthogonally to improvements in ML and search.Of course, development must focus on where slowdowns arise in real end-to-end flows, e.g., detailed route search and repair, DRC fixing, and MCMM design closure.

Figure 5 :
Figure 5: (a) Speedup of incremental detailed routing in Open-ROAD by 100× with 20 16-core workers.(b) Pin access analysis can be completed 30× faster using cloud instances as opposed to a single server [38].

Figure 6 :
Figure 6: (a) Variation of metrics across 201 output netlists from logic synthesis, with target clock periods evenly spaced in a 2ps interval.(b) Variation of metrics across 1005 final P&R results.Testcase: AES, GF12LP.

Figure 7 :
Figure 7: Congestion report for routing blockages with varying partial densities and post-route DRC markers.

Figure 8 :
Figure 8: Coevolution of optimizers and opportunities for "magic" at interstices.

Figure 9 :
Figure 9: OpenROAD as a new EDA playground for ML researchers.

Table 1 :
Examples of GPU-accelerated physical design.