1

OpenROAD: Toward a Self-Driving, Open-SourceDigital Layout Implementation Tool ChainTutu Ajayi5, David Blaauw5, Tuck-Boon Chan2, Chung-Kuan Cheng1, Vidya. A. Chhabria6,

Kyojin Choo5, Matteo Coltella3, Sorin Dobre2, Ronald Dreslinski5, Mateus Fogaca1, Soheil Hashemi4,Abdelrahman Hosny4, Andrew B. Kahng1, Minsoo Kim1, Jiajia Li2, Zhaoxin Liang6, Uday Mallappa1,

Paul Penzes2, Geraldo Pradipta6, Sherief Reda4, Austin Rovinski5, Kambiz Samadi2,Sachin S. Sapatnekar6, Lawrence Saul1, Carl Sechen7, Vaishnav Srinivas2, William Swartz7,

Dennis Sylvester5, David Urquhart3, Lutong Wang1, Mingyu Woo1 and Bangqi Xu11UC San Diego, 2Qualcomm, 3Arm, 4Brown University, 5U. Michigan, 6U. Minnesota, 7U. Texas-Dallas

Abstract—We describe the scope and initial efforts of Open-ROAD, a project in the DARPA IDEA program that pursuesopen-source tools for 24-hour, “no human in the loop” digitallayout generation across integrated circuit, package and boarddomains. If successful, OpenROAD will help realize the IDEAgoal of “democratization of hardware design”, by reducingcost, expertise, schedule and risk barriers that confront systemdesigners today. Several novel technical directions follow directlyfrom the IDEA program’s 24-hour, no-humans goals. Theseinclude (i) enablement of pervasive machine learning in andaround design tools and flows, (ii) parallel search and optimiza-tion to exploit available cloud resources, (iii) partitioning andproblem decomposition to reduce solution latency, and (iv) layoutgeneration methodologies that provide “freedoms from choice”without undue loss of design quality. Further, the development ofopen-source, self-driving design tools is in and of itself a “moonshot” with numerous technical and cultural challenges.

I. INTRODUCTION

Even as hardware design tools and methodologies haveadvanced over the past decades, the semiconductor industryhas failed to control product design costs, as depicted inFigure 1. Today, barriers of cost, expertise and unpredictability(risk) block designers’ access to hardware implementation inadvanced technologies. Put another way: hardware systeminnovation is stuck in a local minimum of (i) complex andexpensive tools, (ii) a shortage of expert users capable of usingthese tools in advanced technologies, and (iii) enormous costand risk barriers to even attempting hardware design.

Particularly in the digital integrated-circuit (IC) domain,layout automation has been integral to the design of huge,extremely complex products in advanced technology nodes.However, a shortfall of design capability – i.e., the ability toscale product quality concomitant with the scaling of underly-ing device and patterning technologies – has been apparent forover a decade in even the most advanced companies [2]. Thus,to meet product and schedule requirements, today’s leading-edge system-on-chip (SoC) product companies must leveragespecialization and divide-and-conquer across large teams ofdesigners: each individual block of the design is handled by a

DISTRIBUTION STATEMENT A. Approved for public release: distribu-tion is unlimited.

Fig. 1. Design technology crisis.

separate subteam, and each designer has expertise in a specificfacet of the design flow. DoD researchers and developmentteams do not have resources to execute such a strategy, andhence see typical hardware design cycles of 12-36 months.

A. IDEA and the OpenROAD Project

To overcome the above limitations and keep pace withthe exponential increases in SoC complexity associated withMoore’s Law, the DARPA IDEA program aims to developa fully automated “no human in the loop” circuit layoutgenerator that enables users with no electronic design ex-pertise to complete physical design of electronic hardware.The OpenROAD (“Foundations and Realization of Open,Accessible Design”) project [17] was launched in June 2018 aspart of the DARPA IDEA program. OpenROAD’s overarchinggoal is to bring down the barriers of cost, expertise andunpredictability that currently block system creators’ accessto hardware implementation in advanced technologies. Witha team of performers that includes Qualcomm, Arm, andmultiple universities led by UC San Diego, OpenROAD seeksto develop a fully autonomous, open-source tool chain fordigital layout generation across die, package and board, withinitial focus on the RTL-to-GDSII phase of system-on-chipdesign. More specifically, we aim to deliver tapeout-capabletools in source code form, with permissive licensing, so asto seed a future “Linux of EDA” (i.e., electronic designautomation).

1105

Fig. 2. Design complexity.

Three innovative base technologies underlie the OpenROADteam’s strategy to achieve no-human-in-loop (NHIL), 24-hour turnaround time (TAT). First, machine learning basedmodeling and prediction of tool and flow outcomes will enablethe tool auto-tuning and design-adaptivity required for NHIL,new optimization cost functions in EDA tools, and new toolknobs that tools may expose to users. Second, extreme parti-tioning strategies for decomposition will enable thousands oftool copies running on cloud resources to maximize successwithin human, CPU, schedule bounds. Quality loss fromdecomposition is recovered with improved predictability offlow steps, along with stronger optimizations. Third, paral-lel/distributed search and optimization will leverage availablecompute resources (e.g., cloud) to maximize design outcomeswithin resource limits, and in the face of noise and chaosin the behavior of complex metaheuristics. A complementaryprecept is to reduce design and tool complexities through“freedoms from choice” in layout generation; this can increasepredictability and avoid iterations in the design process. Thesynergy of base technologies and restrictions of the layoutsolution space is illustrated in Figure 2.

B. A New Paradigm

The contributions and approach of OpenROAD seek toestablish a new paradigm for EDA tools, academic-industrycollaboration, and academic research itself. OpenROAD aimsto finally surmount ingrained, “cultural” and “critical mass /critical quality” barriers to establishing an open-source ethosin the EDA field. To start the project, we bring (i) signifi-cant initial software IP including donated source code bases,and a commercial static timing analysis tool; (ii) a signifi-cant set of academic software IP and skillsets; (iii) leadingSoC and IP know-how and guidance from industry partnersQualcomm and Arm; (iv) an in-built Internal Design team(U. Michigan) to provide de facto product engineering andalpha customer functions; and (v) a broad agenda of industryand academic outreach. Furthermore, OpenROAD derives its“Base Technologies” efforts directly from the IDEA programrequirements (no-humans, 24-hours, no loss of PPA quality).We view the cohesive integration of machine learning, problempartitioning and decomposition, and parallel/distributed searchand optimization as essential to reaching the IDEA target.This paper. The remainder of this paper will outline thecurrent status of OpenROAD’s GitHub-deployed tools and

Fig. 3. The OpenROAD flow.

flow. Early proof points and calibrations in the realm of digitalIC layout generation (“RTL-to-GDSII”) have been obtained inmultiple foundry design enablements including 16nm FinFETtechnology.

II. CURRENT STATUS: LAYOUT TOOL CHAIN

OpenROAD’s layout generation tool chain consists of a setof open-source tools that takes RTL Verilog, constraints (.sdc),liberty (.lib) and technology (.lef) files as input, and aims togenerate tapeout-ready GDSII file. Figure 3 illustrates the flowof tools corresponding to individual OpenROAD tasks. Theseinclude logic synthesis (LS), floorplan (FP) and power deliverynetwork (PDN) generation, placement, clock tree synthesis(CTS), routing and layout finishing.

A. Logic Synthesis

The major gap in open-source LS is timing awareness andoptimization. OpenROAD has explored two avenues towardenablement of timing-driven synthesis. First, we use machine

1106

learning techniques to enable autonomous design space ex-plorations for timing-driven logic optimization. It is oftenthe case that synthesis scripts contain tens of commands inorder to make a design meet its timing and area goals. Thesescripts are crafted by human experts. To produce best synthesisscripts that are tuned to individual circuits, we design machinelearning agents that automatically generate step-by-step syn-thesis scripts to meet target timing and delay goals. Second,we enable physical-aware logic synthesis by integrating theRePlAce [20] placement tool into the logic synthesis flow,whereby global placement-based wire capacitance estimatesare used within logic synthesis to improve timing results.Existing academic tools are oblivious to the outcomes ofsubsequent steps in the design flow, and our ultimate goal isto feed back wiring estimates as they are refined in physicaldesign steps (e.g., standard-cell placement and global routing)to improve synthesis results.

B. Floorplan and PDNFloorplanning and power delivery network synthesis are per-

formed by TritonFPlan, which has two major components. Thefirst component is integer programming-based macro blockpacking that is aware of macro-level connectivity and is seededby a mixed-size (blocks and standard cells) global placement.The second component is Tcl-based power delivery network(PDN) generation following a safe-by-construction approach.TritonFPlan requires the user to specify several config files,e.g., IP global.cfg and IP local.cfg capture macro packingrules, and PDN.cfg captures safe-by-construction metal andvia geometry information. These config files are necessitatedby the inability of academic open-source tool developers (or,their tools) to see complete unencrypted design enablementsfrom the foundry. We discuss this below in Section IV. TheTritonFPlan tool uses mixed-size placer (RePlAce) for itsinitial global placement. The generated macro global locationsprovide a starting point from which multiple floorplan solu-tions are created. For each of the generated floorplan solutionswith fixed macros and PDN, we use our placer (RePlAce)again, to determine the best floorplan according to an estimatedtotal wirelength criterion. Limitations include support of onlyrectangular floorplans, and macro counts less than 100.

C. PlacementRePlAce [3, 20] is a BSD-licensed open-source analytical

placer based on the electrostatics analogy. In OpenROAD,RePlAce is used for mixed-size (macros and cells) placementduring floorplanning, for standard-cell placement within agiven floorplan, and during clock tree synthesis (CTS) [18] forclock buffer legalization. Timing-driven placement is achievedwith integration of FLUTE [5] and OpenSTA [16], along witha signal net reweighting iteration [6]. The timing-driven TD-RePlAce tool takes input in standard LEF/DEF, Verilog, SDCand Liberty formats, and incorporates a fast RC estimator forparasitics extraction. Ongoing efforts aim to enable routability-driven mode using commercial format (LEF/DEF/Verilog).Figure 4 shows the RePlAce placement of a small RISC-V based block (foundry 16nm technology) produced by theUniversity of Michigan internal design advisors subteam.

Fig. 4. Foundry 16nm RISC-V based design block from the University ofMichigan, after RePlAce mixed-size placement. Red color indicates macrosand blue color indicates standard cells.

D. Clock Tree Synthesis

TritonCTS [7, 18] performs clock tree synthesis (CTS) forlow-power, low-skew and low-latency clock distribution, basedon the GH-Tree (generalized H-Tree) paradigm of [7]. Adynamic programming algorithm finds a clock tree topologywith minimum estimated power, consistent with given latencyand skew targets. Linear programming is used to perform sinkclustering and clock buffer placement. Leaf-level routing maybe performed using either the single-trunk Steiner tree or thePrim-Dijkstra [1] algorithm.

In the layout generation flow, TritonCTS has interfaceswith the placer (RePlAce) and the router (TritonRoute [9]).The placer is used for legalization of inserted clock buffers.The router maps sink pins to GCELLs that should be usedfor clock tree routing. TritonCTS inputs are LEF, placedDEF, placed gate-level Verilog, a configuration file and librarycharacterization files. (For each foundry enablement, a one-time library characterization is needed. Currently, this librarycharacterization is expected to be performed by some outsideentity (foundry or tool user) using commercial EDA tools.)TritonCTS outputs are “buffered” placed DEF, “buffered”gate-level Verilog, and clock tree global routing in ISPD18route guides format [14]. TritonCTS is publicly available onGitHub [18]. Early validations have been made using 16nmand 28nm foundry enablements. Improvements to handle mul-tiple clock sources, non-default routing rules, etc. are ongoing.

E. Routing

TritonRoute [9] consumes LEF and placed DEF, then per-forms detailed routing for both signal nets and clock nets givena global routing solution in route guide format [14]. Priorto the detailed routing, TritonRoute preprocesses the globalrouting solution using a fast approximation algorithm [10]to ensure a Steiner tree structure for each net. Thus, con-gestion and wirelength are minimized while net connectivityis preserved in detailed routing stage. The detailed routingproblem is then iteratively solved on a layer-by-layer basis,and each layer is partitioned into disjoint routing panels.The panel routing is formulated as a maximum weightedindependent set (MWIS) problem and solved in parallel usinga mixed integer linear programming (MILP)-based approach.The MWIS formulation optimally assigns tracks considering

1107

Fig. 5. Comparison between OpenSTA and a leading signoff timer (Signoff)for a small 28nm testcase. (a) Endpoint slacks of OpenSTA vs. Signoff timer.(b) Histogram of endpoint slack differences between OpenSTA and Signofftimer.

(i) intra- and inter-layer connectivity, (ii) wirelength and viaminimization, and (iii) various design rules. By an alternatingpanel routing strategy with multiple iterations, inter-panel andinter-layer design rules are properly handled and track assign-ments are maximized. To date, TritonRoute supports majorTSMC16 metal and cut spacing rules, i.e., LEF58 SPACING,LEF58 SPACINGTABLE and LEF58 CUTCLASS. An earlyevaluation shows approximately 10× reduction of spacingrule violations in a TSMC16 design block. Detailed routingflow with integration and optimization of local net routing isthe next step towards a 100%-completion, DRC-clean layoutcapability.

III. CURRENT STATUS: OTHER ELEMENTS

Other elements of the OpenROAD project under develop-ment include the above-mentioned “base technologies” (ma-chine learning, partitioning, parallel optimization), a designperformance analysis backplane (parasitic extraction, statictiming analysis, and power/signal integrity), cloud infras-tructure for tool/flow deployment and machine learning, the“internal design advisors” task, and corresponding self-drivinglayout generation capability in the package and PCB domains.This section outlines the status of several of these projectelements.

A. Static Timing Analysis

OpenSTA [16] is a GPL3 open-sourced version of thecommercial Parallax timer. The Parallax timing engine hasbeen offered commercially for nearly two decades, and hasbeen incorporated into over a dozen EDA and IC compa-nies’ timing analysis tools. OpenSTA is publicly availableon GitHub [16] since September 2018. The developer, JamesCherry, has added Arnoldi delay calculation, power reportingand other enhancements since the original release. OpenSTAhas been confirmed to support multiple advanced foundrynodes, and it supports standard timing report styles. To date,the OpenSTA timer has been integrated into TD-RePlAce(timing-driven enhancement of RePlAce), physical-aware syn-thesis (Yosys [11]) and a gate-sizing tool (TritonSizer [19]).Figure 5(a) shows a comparison of endpoint timing slacksfrom OpenSTA and a commercial signoff timer. Figure 5(b)shows the distribution of endpoint slack differences betweenOpenSTA and the commercial signoff timer.

(a) (b)

Fig. 6. (a) Example PDN templates; and (b) validation of the regressionmodel for R, C in PEX.

B. Parasitic Extraction

In OpenROAD’s approach, the parasitic extraction (PEX)tool processes a foundry process design kit (PDK) to buildlinear regression models for wire resistance, ground capaci-tance, and coupling capacitances to wires on the same layer,or in the adjacent layers above and below. A basic use case isfor another tool in the flow (e.g., CTS, global routing, timinganalysis) to call PEX, providing an input DEF file that consistsof the wire of interest and its neighbors. The output is providedas a SPEF file that contains the extracted parasitics. Figure 6(b)compares the actual and predicted values of the resistance andcapacitance obtained from test nets to validate the regressionmodel, and shows a good fit. Anticipated evolutions includeinterfacing the PEX functions to a possible future IDEA-wide physical design database, and extending the model-fittingapproach to achieve low-overhead parasitic estimators for usein timing-driven placement, crosstalk estimation during globalrouting, etc.

C. Power Integrity

A key goal of our power integrity analysis effort is to enablesingle-pass, correct-and-safe-by-construction specification ofthe power delivery network (PDN) layout strategy acrossthe SoC. Our power delivery network (PDN) synthesis tooltiles the chip area into regions, and selects one of a set ofavailable PDN wiring templates (cf. the “config” files notedin the Floorplanning discussion, above) in each region. Thesetemplates are stitchable so that they obey all design rules whenabutted. The PDN tool takes in a set of predefined templates(Figure 6(a)), an early (floorplanning-stage) placed DEF fora design, and available power analysis information (e.g., ourOpenSTA tool can provide instance-based power reporting).A trained ML model then determines a safe template in eachregion. An early prototype shows that the ML-based approachcan successfully deliver a PDN to satisfy a given (e.g., 1mVstatic) IR drop specification.

1108

D. Cloud Infrastructure

For users to take advantage of OpenROAD tools as well astools developed by other collaborators, a cloud infrastructureeffort aims to provide an end-to-end seamless user experience.In our cloud deployment, users subscribe their Git repo to ourcloud system. Once a design change is pushed to the Git repo,the design is automatically compiled by the OpenROAD flowand the user receives a notification by email when the flowis complete. The user can then download the outcome filesthrough a web browser. If needed, the user can also monitorthe progress of the flow on our web-based front end. Our clouddeployment is elastic as it leverages more computing resourceswhen more users log into the service, or when a user requestsparallel processing capabilities. For instance, the service canelastically deploy multiple machines in order to run a tool(e.g., placer) with multiple random seeds to obtain a betterresult within a given wall time budget. Or, in conjunction withglobal design partitioning, the cloud deployment can run eachdesign partition in parallel on a cloud instance, to maximizeparallel speedup and minimize design turnaround time.

E. METRICS 2.0

To enable large-scale applications of machine learning (ML)and ultimately a self-driving OpenROAD flow, we are develop-ing METRICS 2.0 [8], which can serve as a unified, compre-hensive design data collection and storage infrastructure (see[13]). A METRICS 2.0 dictionary provides a standardized listof metrics suitable for collection during tool/flow execution,to capture key design parameters as well as outcomes fromvarious tools in the design flow. We also propose a systemarchitecture based on JavaScript Object Notation (JSON) fordata logging, and MongoDB database [4] for data storage andretrieval of the metrics. Figure 7 illustrates the METRICS 2.0system architecture. The proposed architecture eliminates theneed to create database schemas and enables seamless datacollection. METRICS 2.0 is tightly coupled with machine-learning frameworks such as TensorFlow, which provides easyinterfaces to read and write into MongoDB, and enables fastdeployment of machine learning algorithms.

F. Early SoC Planning

In light of NHIL and 24-hour turnaround time requirements,it is important to initiate the OpenROAD tool chain with withreliable tentative floorplans as flow starting points, to minimizethe likelihood of run failures. This is a key link between the“system-level design” (IDEA TA-2) and “layout generation”(IDEA TA-1, which we address in OpenROAD). Early floor-plan estimates for the SoC can be enhanced by embeddingphysical implementation information in each IP (e.g., us-ing the vendor extension mechanism within industry-standardIP-XACT descriptions), and by making use of technology-and tool chain- specific parameters and statistical models.Combining and elaborating such information enables earlyarea and performance estimates that can indicate doomed-to-fail floorplan candidates or suggest design implementationfine-tuning (hard-macro placement, grouping, register sliceinsertions, etc.) in viable floorplans.

METRICS 2.0 Feature Extraction METRICS 2.0 Storage Machine-Learning

Design Instance

Tool B

…

Tool N

Final Output

Tool AParameters

Parameters

Parameters

Parameters

JSO

N F

orm

atte

d M

ETR

ICS

Models

Predictions

Tuned Tool Parameters

Fig. 7. Overall METRICS 2.0 system architecture.

G. Integration and Testing

The individual tools described above comprise a tool chainthat produces an implemented design ready for final verifi-cation and fabrication. Initial platform support is targeted forCentOS 6, with tool- and flow-specific support maintained at[17]. To evaluate the flow, non-tool developer entities in ourteam (i.e., U. Michigan, Qualcomm and Arm) perform fine-grained analyses on our tool outputs and provide target calibra-tion metrics for tool developers. Here, we leverage a testcasesuite based around existing designs that have previously beentaped out; these designs range across complexity (from smallblocks to whole chips) and process (e.g., 16nm and 65nm).Our suite of testcases also includes cutting-edge complex SoCsthat are currently in development. A continuous integration testsuite validates the tools individually during development andtracks regression metrics and feature impact.

IV. LOOKING FORWARD

Our near-term efforts will continue development of the toolsand flow described above. More broadly, we will also seek toaddress various technical, structural and cultural challengesthat have become apparent even at project outset.

One key technical challenge is to develop design automationtechnologies as well as layout generation flows that can co-optimize across the SoC, package (PKG) and PCB domains.Today, SoC, PKG and PCB tools and flows are largely disjoint;weeks if not months are required to converge across the threedesigns with manual iterations. To deliver NHIL, 24-hourturnaround time in the PKG and PCB domains, a UnifiedPlanning Tool that seamlessly coordinates among the threedatabases and enables quick iterations is essential. Figure 8illustrates our envisioned Unified Planning Tool. The UnifiedPlanning Tool would also include optimization engines, usinganalytical and ML approaches to evaluate the complex trade-offs across the three design spaces.

Some other technical challenges include the following. (1)The “small and expensive” nature of design process datain IC design – where obtaining a single data point might

1109

Fig. 8. Illustration of Unified Planning Tool.

require three weeks to run through a tool flow – challengesmachine learning and development of “intelligent” tools andflows. (2) The need for new, common standards for measuringand modeling of hardware designs and design tools must becompatible with the IP stances of foundries and commercialEDA; this may shape the future opening of a “Linux ofEDA” to broad participation. And, (3) it will be difficult toilluminate the critical junctures where “human intelligence” isnow required, yet must be replaced by “machine intelligence”,in the hardware design process.

Several structural challenges stem from our status as aca-demic tool developers of a tool chain that must producetapeout-ready GDSII. (1) OpenROAD tools will likely not befoundry-qualified, which implies that OpenROAD tools andtool developers will not be able to read encrypted advanced-node PDKs. To achieve safety and correctness by constructionof the tapeout database, OpenROAD tools require configfiles and one-time generation of “OpenROAD kit” elements,for each foundry enablement. (2) OpenROAD’s analyses andestimators for timing, parasitics and power/signal integrity arenot “signoff” verifiers. Thus, additional performance guard-bands are required throughout the layout generation flow.And, post-OpenROAD verifications may be performed by de-signers and/or foundries. (3) OpenROAD tools are developedand released by non-commercial entities. Commercial EDAvendors receive bug/enhancement requests accompanied by atestcase that exhibits the bug or behavior at issue. By contrast,bug reports that we receive are unlikely to be accompaniedby testcases due to blocking NDA / IP restrictions. Thiscomplicates the bug-fixing and enhancement process.

Finally, our outreach efforts seek culture change and en-gagement across the community of potential developers andtool users. For example, in the academic research world, alab’s code is its competitive advantage (or, potential startup),and liberal open-sourcing is still rare (cf. [12]). We hope thatOpenROAD and the IDEA/POSH programs help drive culturechange in this regard. With regard to tool users, we observethat commercial EDA tools are invariably driven to production-worthiness by “power users” – i.e., paying customers whohave deep vested interests in the capability and maturation ofa given tool. Traditionally, power users expose a new tool toleading-edge challenges and actively drive tool improvement.For OpenROAD, finding our “power users” is a critical need,especially since they would be able to improve tools and flowsat the source-code level.

V. CONCLUSION

In this paper, we have reviewed the scope and status ofOpenROAD, a DARPA IDEA project that aims to developa self-driving, open-source digital layout implementation toolchain. The above is only a snapshot, taken six months intoa four-year project. We welcome feedback, participation andcontributions.

ACKNOWLEDGMENTS

We thank Payal Agarwal, Chia-Tung Ho, Hsin-Yu Liu andSiddharth Singh for their contributions to the OpenROADproject. Mateus Fogaca (permanent affiliation: UFRGS, PortoAlegre, Brazil) developed TritonCTS as a visiting Ph.D.student at UCSD. The OpenROAD project is supported byDARPA (HR0011-18-2-0032).

REFERENCES

[1] C. J. Alpert, W.-K. Chow, K. Han, A. B. Kahng, Z. Li, D. Liu, S.Venkatesh, “Prim-Dijkstra Revisited: Achieving Superior Timing-drivenRouting Trees”, Proc. ACM/IEEE Intl. Symp. on Physical Design, 2018,pp. 10-17.

[2] W.-T. J. Chan, A. B. Kahng, S. Nath and I. Yamamoto, “The ITRSMPU and SOC System Drivers: Calibration and Implications for Design-Based Equivalent Scaling in the Roadmap”, Proc. IEEE Intl. Conf. onComputer Design, 2014, pp. 153-160.

[3] C.-K. Cheng, A. B. Kahng, I. Kang and L. Wang, “RePlAce: AdvancingSolution Quality and Routability Validation in Global Placement”, IEEETrans. on CAD (2018), to appear. DOI: 10.1109/TCAD.2018.2859220

[4] K. Chodorow, MongoDB: The Definitive Guide: Powerful and ScalableData Storage, O’Reilly Media, Inc., 2013.

[5] C. Chu and Y.-C. Wong, “FLUTE: Fast Lookup Table Based RectilinearSteiner Minimal Tree Algorithm for VLSI Design”, IEEE Trans. on CAD27(1) (2008), pp. 70-83.

[6] M. Fogaca, G. Flach, J. Monteiro, M. Johann and R. Reis, “QuadraticTiming Objectives for Incremental Timing-Driven Placement Optimiza-tion”, Proc. ICECS, 2016, pp. 620-623.

[7] K. Han, A. B. Kahng and J. Li, “Optimal Generalized H-Tree Topologyand Buffering for High-Performance and Low-Power Clock Distribu-tion”, IEEE Trans. on CAD (2018), to appear.

[8] S. Hashemi, C.-T. Ho, A. B. Kahng, H.-Y. Liu and S. Reda, “METRICS2.0: A Machine-Learning Based Optimization System for IC Design”,Workshop on Open-Source EDA Technology, 2018, pp. 21:1-21:4.

[9] A. B. Kahng, L. Wang and B. Xu, “TritonRoute: An Initial DetailedRouter for Advanced VLSI Technologies”, Proc. ACM/IEEE Intl. Conf.on Computer-Aided Design, 2018, pp. 81:1-81:8.

[10] L. Kou, G. Markowsky and L. Berman, “A Fast Algorithm for SteinerTrees”, Acta Informatica 15(2) (1981), pp. 141-145.

[11] C. Wolf, J. Glaser and J. Kepler, “Yosys – A Free Verilog SynthesisSuite”, Proc. Austrian Workshop on Microelectronics, 2013.

[12] VLSI CAD Bookshelf 2, MARCO/DARPA Gigascale Silicon ResearchCenter, http://vlsicad.eecs.umich.edu/BK/

[13] The METRICS Initiative, MARCO/DARPA Gigascale Silicon ResearchCenter, https://vlsicad.ucsd.edu/GSRC/metrics/

[14] ISPD-2018 Initial Detailed Routing Contest, http://www.ispd.cc/contests/18/index.html

[15] LEF/DEF reference 5.8, http://www.si2.org/openeda.si2.org/projects/lefdefnew

[16] OpenSTA, https://github.com/abk-openroad/OpenSTA[17] The OpenROAD Project, https://theopenroadproject.org[18] TritonCTS, https://github.com/abk-openroad/TritonCTS[19] TritonSizer, https://github.com/abk-openroad/TritonSizer[20] RePlAce, https://github.com/abk-openroad/RePlAce

1110