From RTL to Fabrication: Survey of Open-Source EDA Tools and PDKs

Abstract

This article aims to synthesize the current ecosystem of open-source tools for Integrated Circuit (IC) design, covering the entire digital design flow from Register-Transfer Level (RTL) description to fabricable layouts. The survey categorizes and analyzes tools across major stages of design, including code-generation tools, logic synthesis, simulation, and physical design flow. Special emphasis is given to the fabricable open-source Process Design Kit (PDK), which enables the physical realization of open-hardware projects. By examining interoperability, limitations, and maturity across this toolchain, the article provides a comprehensive overview of the Electronic Design Automation (EDA) landscape and identifies the research and educational opportunities that arise from democratizing silicon design through open and reproducible workflows.

1. Introduction

Electronic traces its origins to the fundamental discoveries in electricity and magnetism by pioneering scientists such as Coulomb, Ampère, Ohm, Gauss, Faraday, and Henry [1]. In 1865, James Clerk Maxwell unified these independent findings into a coherent theoretical framework known as Maxwell’s Equations, which established the foundation for modern electromagnetism and paved the way for the technological advancements that followed [2].

The Microelectronics era began in 1904 with John Ambrose Fleming’s invention of the vacuum diode, a device that permitted current to flow in only one direction [3]. Shortly thereafter, Lee De Forest introduced the triode by adding a control grid, enabling signal amplification and revolutionizing electronic communication [4]. These vacuum-tube technologies dominated early electronics, powering the first radios, amplifiers, and computers, until the invention of the bipolar junction transistor at Bell Laboratories in 1947 by John Bardeen, Walter Brattain, and William Shockley [5]. Although the Field-Effect Transistor (FET) had been conceptually proposed decades earlier [6], it was not successfully realized until 1959, when Mohamed Atalla and Dawon Kahng developed the Metal–Oxide–Semiconductor Field-Effect Transistor (MOSFET), a breakthrough that became the cornerstone of modern microelectronics and IC technology [7].

The advent of transistor-based integration led to the development of IC and, consequently, the need for systematic procedures to manage their increasing complexity. During the late 1970s, the Mead and Conway revolution fundamentally transformed the way digital systems were conceived and implemented by introducing a standardized, hierarchical methodology for Very-Large-Scale Integration (VLSI) design [8]. This approach established the basis of what is now known as the physical design flow, a structured process that translates high-level functional descriptions into manufacturable layouts through successive stages of logic synthesis, floorplanning, placement, routing, and signoff verification [9,10,11].

With the parallel growth of EDA tools during the 1980s and 1990s, these methodologies became increasingly automated, giving rise to commercial toolchains that enabled large-scale digital design and fabrication [12,13,14]. The physical design flow was gradually formalized and became a well-established process, typically divided into three main domains: the front-end, the back-end, and the foundry stage. The front-end stage encompasses high-level modeling, RTL design, functional verification, and logic synthesis. The back-end stage focuses on physical implementation, including floorplanning, placement, routing, and signoff verification steps such as Static Timing Analysis (STA), Design Rule Check (DRC), and Layout Versus Schematic (LVS). Finally, the foundry stage involves mask generation and fabrication using the corresponding PDK, completing the transition from logical design to silicon realization [15,16,17], as illustrated in Figure 1a.

Figure 1. (a) IC design flow illustrating the complete process from RTL specification through logic synthesis, physical design (floorplanning, placement, clock tree synthesis, routing), verification, and final GDSII generation for fabrication [17]. (b) FPGA design flow showing the progression from RTL description to synthesis, technology mapping, placement-and-routing on the target FPGA fabric, bitstream generation, and device configuration.

In contrast, Figure 1b depicts the FPGA-oriented design flow, where the process terminates after synthesis, technology mapping, and placement-and-routing on a predefined programmable fabric, followed by bitstream generation and device configuration, without requiring mask generation or fabrication. Together, these subfigures highlight the fundamental divergence between ASIC and FPGA workflows while emphasizing their shared front-end design stages and the common reliance on RTL-level abstraction as the entry point for both implementation paths [17].

The cost of designing an IC has increased exponentially as process nodes continue to scale down. Each new generation of semiconductor technology demands more complex design rules, advanced verification methodologies, and high-precision photolithography equipment, all of which contribute to escalating development costs. For instance, the design cost of building a high-performance Graphics Processing Unit (GPU), Central Processing Unit (CPU), or System-on-Chip (SoC) at 7 nm technology nodes has reached approximately $300 million, and projections indicate that the cost for 2 nm nodes could rise to around $752 million [18,19,20].

At advanced technology nodes, such as 2 nm, the non-recurring engineering (NRE) and design-related costs of an IC are distributed across several categories that reflect both software and hardware complexity. The largest portion corresponds to software-related expenses, which account for approximately 45% of the total, or around $326 million, encompassing EDA tool licenses, automation scripts, and simulation infrastructure. Verification represents about 18% ($130 million), covering functional, timing, and formal verification processes, while validation activities account for roughly 10% ($72 million) of the cost, focused on post-layout power and performance analysis. Prototyping and emulation represent 8% ($58 million), followed by physical design tasks, such as place-and-route and DRC/LVS, which contribute 7% ($51 million). System architecture definition and RTL design also comprise approximately 7% ($51 million), and finally, third-party IP qualification and integration make up the remaining 5% ($36 million) [18,19,20]. This distribution highlights how, at nanoscale nodes, the majority of expenses stem from software, verification, and design automation—underscoring the growing dependence of modern semiconductor development on computational resources and advanced design tools.

This increase, driven by higher mask set prices, longer verification cycles, and the need for specialized EDA tools, poses a serious barrier for smaller companies and academic institutions. Furthermore, the cost of commercial EDA licenses and restricted access to proprietary PDKs make it particularly difficult for most universities and research centers to engage in advanced IC design. These financial and logistical challenges significantly limit the ability of academic environments to train new semiconductor designers and to contribute actively to state-of-the-art research and innovation in IC development.

As design and fabrication costs continue to rise at advanced process nodes, programs such as the Defense Advanced Research Projects Agency (DARPA) Common Heterogeneous Integration and IP Reuse Strategies (CHIPS) initiative propose an alternative paradigm to mitigate these challenges [21]. The CHIPS vision aims to establish an ecosystem of modular, reusable Intellectual Property (IP) blocks that can be integrated using standardized electrical and physical interfaces. By promoting IP reuse and heterogeneous integration across different materials and technologies, this approach reduces non-recurring engineering costs and design time while improving flexibility for both defense and commercial applications.

In addition to economic barriers, the semiconductor industry faces a growing shortage of skilled professionals capable of managing complex design and verification flows [22,23,24]. This lack of trained engineers further amplifies the need for accessible design frameworks and educational resources. The modular and reusable design philosophy, together with the open-source EDA movement, directly addresses these issues by lowering entry barriers, fostering collaborative development, and accelerating workforce training in advanced microelectronics.

In this context, the purpose of this article is to synthesize the current open-source ecosystem that supports the complete digital design process of IC. The survey provides an overview of the most relevant tools and frameworks available for each stage of the digital design flow, emphasizing their interoperability, accessibility, and educational value. To facilitate navigation and reproducibility, Table A1 summarizes the surveyed tools according to their category, name, and direct access link, providing a centralized reference to the open-source resources discussed throughout the manuscript.

To facilitate readability and systematic navigation of the open-source EDA ecosystem, the surveyed tools are organized into a set of well-defined categories according to their functional role within the RTL-to-Graphic Design System II (GDSII) design flow. Section 2 (Code-Generation Tools) introduces classical open-source approaches that raise the level of abstraction above manual RTL coding, including High-Level Synthesis (HLS) frameworks, high-level or embedded Hardware Description Language (HDL)s, and RTL/Abstract Syntax Tree (AST)-level manipulation tools. Section 3 (LLM-Based Code Generation) is devoted to Artificial intelligence (AI)-driven methodologies, with particular emphasis on Large Language Model (LLM)-based approaches for automatic HDL generation, specification-to-RTL translation.

Subsequently, Section 4 (Synthesis Tools) focuses on logic synthesis engines that transform RTL descriptions into optimized gate-level netlists suitable for both Field-Programmable Gate Array (FPGA) and Application-Specific Integrated Circuit (ASIC) targets. Section 5 (Simulation and Verification Tools) reviews functional, timing, and verification frameworks that ensure design correctness across front-end, post-synthesis, and post-layout stages. Section 6 (Physical Design Flow Tools) details the back-end stages of layout generation and optimization, including floorplanning, placement, routing, and sign-off verification, which collectively enable the transition from logical representations to physical layouts. Finally, Section 7 (Fabricable PDKs) synthesizes the current landscape of open and manufacturable PDK that make the physical realization of open-source IC designs possible.

This structured organization consolidates the diverse open-source contributions across the IC design domain, highlighting their collective potential to democratize silicon innovation and education, while providing a coherent and accessible overview that lowers the barrier of entry for a broader semiconductor design community.

2. Code-Generation Tools

The progressive rise in abstraction levels within digital hardware design has become a defining strategy for reducing development time, improving productivity, and enabling rapid exploration of architectural alternatives [25,26]. Traditional RTL workflows require designers to manually specify control logic, datapaths, and structural details, a process which is both time-consuming and error-prone. By contrast, modern code-generation tools operate at higher levels of abstraction, ranging from behavioral descriptions to domain-specific languages and natural-language prompts, allowing engineers to express intended functionality rather than low-level implementation details. As a result, raising the abstraction level not only accelerates prototyping but also facilitates broader accessibility for software-oriented developers transitioning into hardware design. This shift aligns with industry trends toward agile hardware development and AI-assisted design methodologies, where expressiveness and automation are essential to managing design complexity.

Table 1 presents a comparative overview of prominent open-source code-generation tools, emphasizing the range of abstraction levels they support. These tools span from HLS environments, such as PandA Bambu and the Kiwi Compiler, to Python-embedded hardware description and modeling frameworks, including Amaranth HDL and PyMTL3, among others. As shown, each tool occupies a different point in the abstraction spectrum, offering unique advantages in terms of input language, output format, and design intent. HLS tools enable designers to begin from behavioral C/C++ descriptions, dramatically reducing the amount of time required to create hardware accelerators, while Python-based frameworks simplify parameterization, modularity, and verification.

Table 1. Comparison of Code Generation Tools.

Tool	Primary Purpose	Input Language	Output Format
PandA Bambu HLS [27]	HLS compiler translating C/C++ into RTL	C, C++	Verilog, VHDL
Kiwi Compiler [28]	HLS compiler translating C#/.NET into RTL	C#, .NET IL	Verilog
LegUp HLS [29]	LLVM-based HLS compiler for C programs	C, C++	Verilog
ROCCC [30]	Research HLS compiler for accelerator generation	C	Verilog
PyMTL3 [31]	Python-based hardware modeling and generation framework	Python	Verilog
Chisel [32]	Scala-based language for parameterized RTL generation	Scala	Verilog, C++
SpinalHDL [33]	Scala-based HDL for reusable RTL generators	Scala	Verilog, VHDL
Pyverilog [34]	Python framework for Verilog analysis and generation	Verilog, Python (API)	Verilog
Amaranth HDL [35]	Python-based HDL and RTL elaboration framework	Python	Verilog

Together, these tools illustrate how abstraction directly impacts design velocity and scalability. By minimizing manual RTL coding and enabling automated translation between conceptual descriptions and hardware implementations, abstraction-oriented methodologies reduce iteration time and support rapid design-space exploration.

To avoid ambiguity between fundamentally different design intents, this section organizes code-generation tools according to their modeling level and design abstraction rather than implementation language. Accordingly, existing open-source approaches are classified into three categories: (i) High-Level Synthesis (behavioral-to-RTL), (ii) High-Level/Embedded HDLs, and (iii) RTL/AST-level manipulation frameworks. This structure clarifies the abstraction level and design intent of each class of tools and prevents conflation between synthesis, high-level modeling, and RTL transformation approaches. AI-driven and LLM-based code-generation methods follow a distinct paradigm and are therefore discussed separately in Section 3.

2.1. High-Level Synthesis (Behavioral-to-RTL)

2.1.1. PandA Bambu HLS

PandA Bambu is an open-source HLS tool developed within the Politecnico di Milano’s PandA framework, designed to generate synthesizable hardware descriptions from C and C++ programs. Unlike traditional RTL design, in which designers explicitly describe hardware structures, Bambu allows algorithms to be expressed in a high-level programming language and then automatically translated into Verilog or Very High Speed Integrated Circuit Hardware Description Language (VHDL). This approach enables rapid design-space exploration and significantly shortens development cycles for complex hardware accelerators [27,36]. Bambu integrates several compiler technologies, including Low Level Virtual Machine (LLVM) and GNU Compiler Collection (GCC) front ends, to support a broad range of C/C++ constructs while optimizing memory access, control flow, and data dependencies during synthesis.

One of the defining features of Bambu is its modular optimization pipeline, which includes scheduling, allocation, binding, and control-path generation. The tool performs aggressive compiler-level optimizations such as loop unrolling, pipelining, array partitioning, and speculative execution when applicable. These features position Bambu as a powerful environment for researching HLS methodologies and for implementing hardware accelerators targeting FPGA or ASIC technologies. Furthermore, Bambu supports several back-end code generators, allowing users to produce RTL tailored for specific synthesis tools and target platforms. Its integration with widely used open-source toolchains, such as Yosys [37] for logic synthesis and Verilator [38] for simulation, makes it especially useful in fully open-source flows.

Bambu also stands out for its ability to evaluate different implementation strategies automatically. Through built-in design-space exploration, it can generate multiple hardware variants from a single C/C++ description, each with different latency, area, and throughput characteristics. Due to its open-source nature, PandA Bambu has become a valuable platform for academic research in high-level synthesis, hardware/software co-design, and digital architecture exploration [39,40]. For educational purposes, Bambu also provides an accessible environment for introducing students to high-level hardware design concepts without requiring deep RTL expertise. This balance of usability, transparency, and extensibility makes PandA Bambu one of the most prominent open-source HLS tools available today.

To illustrate this concept, the article [41] presents a complete open-source workflow that significantly increases the abstraction level of digital integrated circuit design by combining PandA Bambu HLS with the OpenLane RTL-to-GDSII flow. Instead of relying on manually written RTL descriptions, the methodology starts from algorithmic specifications written in C/C++, which are automatically translated into synthesizable Verilog using PandA Bambu HLS. This approach allows designers to concentrate on algorithmic functionality rather than low-level hardware implementation details, reducing development time and lowering the barrier for software-oriented designers. At the same time, the workflow remains fully open-source and compatible with manufacturable PDKs such as SKY130A and GF180MCUC, demonstrating that higher abstraction does not compromise silicon realizability.

Once the RTL is generated by PandA Bambu, it is directly integrated into the OpenLane flow, which automates logic synthesis, floorplanning, placement, clock tree synthesis, routing, and sign-off to generate a final GDSII layout. The article demonstrates that this tight coupling effectively bridges the gap between software-level descriptions and physical IC fabrication, enabling complex designs—such as matrix multipliers, cryptographic cores, and image-processing filters—to be implemented at the layout level. By leveraging OpenLane together with Caravel-based MPW integration, the proposed flow validates that HLS-generated RTL can be reliably transformed into manufacturable silicon, highlighting a scalable and practical path from C code to GDSII within a fully open-source EDA ecosystem.

2.1.2. Kiwi Compiler

The Kiwi Compiler is an open-source HLS tool that was originally developed at the University of Cambridge in collaboration with Microsoft Research. Its primary purpose is to translate programs written in C# or .NET intermediate language into synthesizable hardware descriptions, typically Verilog, enabling the implementation of high-level algorithms on FPGA devices. Unlike traditional HLS tools that restrict supported programming constructs, Kiwi supports a wide subset of C# features, including object-oriented structures, arrays, multithreading, and limited recursion [28,42]. This makes Kiwi particularly accessible for software developers seeking to transition into hardware design without writing low-level HDL code.

A distinguishing feature of Kiwi is its ability to allow programmers to express hardware parallelism using familiar software abstractions. The compiler automatically handles scheduling, resource allocation, and control-path generation, transforming sequential software semantics into hardware architectures that exploit concurrency. This capability greatly simplifies the creation of custom accelerators and hardware pipelines, making Kiwi an attractive platform for rapid prototyping in domains such as scientific computation, data processing, and machine learning. Furthermore, Kiwi includes a performance prediction mechanism that estimates hardware timing characteristics before full synthesis, helping developers optimize their designs iteratively.

The compiler is structured around a modular transformation flow that maps IL instructions to dataflow graphs, performs control-flow restructuring, and generates synthesizable RTL through a sequence of analysis and optimization passes. Its open-source distribution enables researchers to study and extend internal transformations, making it useful not only as an HLS tool but also as a research platform for experimenting with new compiler optimizations and hardware mapping strategies.

2.1.3. LegUp HLS

LegUp is an open-source HLS framework designed to translate standard C programs into synthesizable hardware descriptions targeting FPGA-based systems. Developed at the University of Toronto, LegUp enables software developers to exploit hardware acceleration without requiring manual RTL design, thereby reducing the complexity and entry barrier traditionally associated with hardware development [29].

Unlike conventional HLS tools that generate standalone hardware modules, LegUp targets a hybrid processor–accelerator architecture. In this model, a soft-core processor executes the software portions of an application, while computationally intensive functions are automatically synthesized into custom hardware accelerators that operate concurrently with the processor. Communication between the processor and accelerators is performed through a standard on-chip interconnect and shared memory, enabling efficient hardware/software co-design and flexible partitioning of applications between software and hardware execution [29].

LegUp is implemented as a set of backend passes within the LLVM compiler infrastructure. Source-level C code is first translated into LLVM’s intermediate representation, where conventional compiler optimizations are applied. Hardware synthesis is then performed directly on this representation through allocation, scheduling, and binding stages, resulting in a finite-state machine with datapath (FSMD) that is emitted as synthesizable Verilog RTL. This tight integration with LLVM allows LegUp to leverage mature compiler analyses, such as data dependence and alias analysis, while also facilitating experimentation with alternative scheduling and binding strategies.

A distinctive feature of LegUp is its emphasis on hardware/software codesign. Program execution can be profiled on the target processor to identify candidate functions for hardware acceleration, enabling systematic exploration of the design space between pure software and pure hardware implementations. By supporting a large subset of the C language—including arrays, structures, global variables, and pointer arithmetic—LegUp offers broader language coverage than many research-oriented HLS tools and is capable of compiling realistic applications rather than isolated kernels [29].

As a fully open-source framework, LegUp serves both as a practical HLS tool and as a research platform for studying high-level synthesis algorithms, hardware/software partitioning strategies, and accelerator-based system architectures. Its availability has contributed to reproducible research in HLS and has positioned LegUp as one of the most influential open-source HLS tools in the academic FPGA and EDA community.

2.1.4. ROCCC HLS

ROCCC (Riverside Optimizing Configurable Computing Compiler) is an academic HLS framework developed to translate C-based programs into synthesizable hardware accelerators. Unlike industrial HLS tools that aim for broad language support and tight integration with vendor flows, ROCCC was designed with a strong emphasis on compiler-driven optimizations, targeting loop-intensive kernels and data-parallel computations [30].

The ROCCC compiler focuses on aggressive loop transformations such as loop unrolling, software pipelining, and memory access optimization to expose instruction-level and data-level parallelism suitable for hardware implementation. Its compilation flow decomposes applications into computational kernels, which are then mapped into custom datapaths described in Verilog. This kernel-centric approach makes ROCCC especially well suited for accelerating compute-heavy sections of applications rather than full system synthesis.

Although ROCCC is no longer actively maintained and reflects the state of HLS research from the early 2010s, it remains an important reference point in the evolution of high-level synthesis. Many of the concepts explored in ROCCC—such as compiler-assisted hardware specialization and loop-based optimization strategies—have directly influenced later open-source and commercial HLS tools.

2.2. High-Level/Embedded HDLs

2.2.1. PyMTL3

PyMTL3 is an open-source hardware modeling, generation, simulation, and verification framework embedded in Python. It is designed to support a seamless and unified approach to hardware development across multiple abstraction levels, including functional-level, cycle-level, and RTL models. By embedding hardware description directly within Python, PyMTL3 enables designers to exploit the productivity, expressiveness, and extensive ecosystem of the Python language while constructing deeply parameterized and reusable hardware generators [31]. Its modeling workflow allows designers to refine a design progressively—from high-level behavioral descriptions to synthesizable RTL—using a consistent environment for elaboration, simulation, and testing. This unified approach eliminates the need to switch between different languages or toolchains and encourages agile hardware development practices.

Beyond modeling, PyMTL3 provides a modular software architecture that includes an in-memory intermediate representation and a system of analysis, instrumentation, and transformation passes. These passes can inspect, modify, or optimize hardware models, enabling advanced capabilities such as static elaboration, scheduling, translation to SystemVerilog, co-simulation with imported RTL, property-based testing, and integration with external tools like Verilator and FPGA/ASIC flows. The framework also supports black-box and white-box importing of Verilog and SystemC components, allowing seamless reuse of existing IP within Python-driven simulations. By combining flexible parametrization, multilevel modeling, powerful verification tools, and interoperability with the broader open-source hardware ecosystem, PyMTL3 serves as a comprehensive platform for research, education, and rapid prototyping in modern hardware design [31,43].

2.2.2. Chisel

Chisel (Constructing Hardware in a Scala Embedded Language) is a hardware construction language developed at the University of California, Berkeley, that embeds hardware description primitives within the Scala programming language. Unlike traditional HDLs such as Verilog or VHDL, which are primarily simulation-oriented, Chisel is designed to support highly parameterized hardware generators using modern software abstraction mechanisms, including object-oriented programming, functional constructs, and strong static typing. By leveraging Scala as a host language, Chisel raises the level of abstraction in hardware design while preserving precise control over RTL structure and timing [32].

A defining characteristic of Chisel is its generator-based design methodology. Hardware designs are expressed as parameterized programs that elaborate into concrete RTL implementations, enabling systematic design-space exploration and efficient reuse of microarchitectural patterns. Chisel provides hardware-specific data types for representing signals, registers, and structured interfaces, which are distinct from the host language types and explicitly model hardware semantics. These data types can be composed hierarchically to describe complex modules such as pipelines, caches, interconnects, and processors, addressing key scalability limitations of conventional HDLs [32].

From a backend perspective, Chisel can emit synthesizable Verilog suitable for standard FPGA and ASIC design flows and generates fast cycle-accurate C++ simulators to accelerate functional verification. Beyond its original role as a generator-oriented HDL, recent work demonstrates that Chisel is actively used in production-scale, physically aware design frameworks. For example, Chisel has been employed to implement a fully parameterized generator for standardized 3-D die-to-die interconnect physical layers, enabling automated logic generation, signal-to-bump mapping, and emission of physical design collateral such as floorplans and timing constraints in compliance with emerging standards like UCIe-3-D [32,44].

In this context, Chisel serves not only as a HDL but also as a unifying abstraction layer that co-locates hardware construction with design-space exploration algorithms, physical constraint generation, and protocol-aware configuration. Its strong typing, object-oriented structure, and functional programming support allow complex data structures—such as port lists, bump maps, and redundancy schemes—to be expressed and manipulated alongside hardware logic in a correct-by-construction manner. This capability enables end-to-end automation from high-level interface specifications to Verilog RTL and physical design inputs, addressing limitations of traditional, document-driven interconnect design methodologies [44].

2.2.3. SpinalHDL

SpinalHDL is an open-source HDL embedded in the Scala programming language, designed to improve designer productivity and code maintainability compared to traditional RTL languages such as Verilog and VHDL. By leveraging Scala’s object-oriented and functional programming features, SpinalHDL enables designers to describe hardware using parameterized components, reusable generators, and strongly typed interfaces. Rather than introducing a new simulation-driven language, SpinalHDL focuses on efficient hardware construction and elaboration, allowing complex digital systems to be expressed concisely while maintaining explicit control over register-transfer level semantics [33].

A central characteristic of SpinalHDL is its generator-based design methodology. Hardware descriptions are written as Scala programs that elaborate into concrete RTL implementations, enabling systematic reuse and scalable design-space exploration. SpinalHDL provides dedicated hardware data types, structured interfaces, and high-level constructs for describing pipelines, finite-state machines, buses, and clock-domain interactions. Strong typing and built-in consistency checks allow many design errors—such as invalid signal assignments or incomplete connections—to be detected at elaboration time rather than during simulation or synthesis, thereby reducing the debugging effort.

From a backend perspective, SpinalHDL generates synthesizable Verilog or VHDL that integrates seamlessly with standard FPGA and ASIC design flows and existing EDA tools. The generated RTL preserves hierarchy and naming, facilitating verification, debugging, and physical implementation. SpinalHDL also supports interoperability with legacy HDL designs through blackbox components, enabling incremental adoption in existing projects. Positioned between low-level RTL coding and behavioral synthesis, SpinalHDL occupies a distinct role as a high-level embedded HDL that enables explicit RTL construction through reusable, parameterized hardware generators while remaining compatible with industrial design workflows.

2.3. RTL/AST-Level Manipulation

2.3.1. Pyverilog

Pyverilog is an open-source, Python-based toolkit designed to analyze, transform, and generate Verilog HDL code. It provides a complete front-end flow that includes a parser for building an abstract syntax tree, a dataflow analyzer for extracting signal dependencies, a control-flow analyzer for modeling finite-state machine behavior, and a code generator capable of reconstructing synthesizable Verilog [34,45]. These components enable users to interpret hardware designs at both behavioral and structural levels, making Pyverilog well suited for developing custom EDA tools, RTL refactoring utilities, verification frameworks, and research prototypes. By offering a high-level Python interface, Pyverilog significantly lowers the barrier for performing complex RTL analysis without requiring specialized HDL-processing software.

In addition to analysis, Pyverilog supports transformation and extensibility through its modular architecture. The toolkit allows designers to traverse and modify AST nodes, rewrite signal expressions, optimize logic, or introduce new design constructs programmatically. It integrates seamlessly with standard Verilog preprocessing flows and leverages common software engineering patterns to facilitate rapid experimentation. The practicality of Pyverilog is demonstrated by its use in building hardware design automation frameworks that rely on automated dataflow extraction, Finite State Machine (FSM) analysis, and code synthesis. As a result, Pyverilog provides a powerful foundation for both academic research and practical tool development within the hardware design community.

2.3.2. Amaranth HDL

Amaranth is an open-source HDL and toolchain embedded in Python, designed for constructing synchronous digital systems at the RTL. Instead of introducing a new standalone HDL syntax, Amaranth leverages Python’s expressive programming constructs—such as classes, functions, loops, and conditionals—to define hardware structures and behavior. This approach enables designers to describe hardware in a more modular and parameterizable manner while retaining the precision required for synthesizable RTL [35]. Amaranth includes a standard library, an intermediate representation, and a build system that together provide a cohesive environment for developing digital designs.

One of the core strengths of Amaranth is its ability to generate synthesizable Verilog from Python descriptions. This makes Amaranth fully compatible with existing FPGA and ASIC toolchains, allowing easy integration with legacy Verilog or VHDL modules, vendor IP blocks, or full-chip flows based on commercial or open-source EDA tools. Furthermore, Amaranth provides abstractions for platform-specific primitives such as I/O buffers, memory blocks, Phase-Locked Loops (PLLs), and clock-domain controllers. These abstractions simplify the design of portable hardware components by hiding low-level device details while enabling fine control when required.

Amaranth also includes a built-in simulator, enabling functional verification directly within Python without relying on external simulation environments [46]. Designers can write testbenches using standard Python constructs, perform waveform inspection, and validate design behavior before synthesizing their circuits. This unification of design and verification within a single programming language accelerates prototyping and reduces development overhead. By combining the accessibility of Python with the rigor of RTL design, Amaranth provides a productive and flexible platform for education, research, FPGA prototyping, and early-stage ASIC exploration.

Amaranth has also been successfully combined with OpenLane to demonstrate how Python-based hardware description languages can be integrated into open-source RTL-to-GDSII flows. A representative example is the third-place winning project of the Efabless AI Design Contest, where Amaranth was used to implement a hardware-based pseudorandom number generator (RNG) [47]. In this work, the design was described in Python using Amaranth, automatically translated into Verilog, and subsequently processed by OpenLane for synthesis, placement, routing, and sign-off. The design flow was completed with integration into the Caravel harness, enabling fabrication through the ChipIgnite MPW program. Extensive validation, including simulation and Dieharder statistical testing, was performed prior to tape-out, illustrating that Amaranth-generated RTL can be reliably transformed into manufacturable silicon using OpenLane.

Beyond small accelerators and test circuits, Amaranth has also been applied to more complex system-level designs. The Misato RISC-V RV32I CPU is a notable example of a processor core written entirely in Amaranth HDL and implemented using OpenLane with both 65 nm and SKY130 nm PDKs [48]. The core supports the RV32I instruction set and has been formally verified to ensure correct instruction behavior, demonstrating that high-level, Python-based hardware descriptions can meet rigorous correctness requirements. Using OpenLane, the Amaranth-generated Verilog was synthesized and physically implemented, validating the compatibility of Amaranth with standard open-source ASIC flows. These examples collectively show that Amaranth, when paired with OpenLane, enables a productive and expressive design methodology that spans from high-level hardware modeling to silicon-proven implementations.

3. LLM-Based Code Generation

AI has profoundly transformed a wide range of scientific and engineering disciplines over the past decade, evolving from a set of specialized algorithms into a general-purpose technological paradigm. Advances in machine learning and deep neural networks have enabled systems capable of perception, decision-making, and pattern recognition at levels previously unattainable with classical algorithmic approaches. These capabilities have driven major breakthroughs in fields such as medical imaging, signal processing, control systems, and human–machine interaction, fundamentally changing how complex problems are approached and solved.

In the biomedical domain, AI techniques have demonstrated remarkable effectiveness in automating diagnostic and decision-support tasks. Deep learning models have been successfully applied to medical image analysis, enabling reliable classification and referral systems for diseases such as diabetic retinopathy, significantly improving screening accuracy and clinical efficiency [49,50].

Beyond healthcare, AI has also impacted areas involving real-time sensing, signal interpretation, and dynamic system modeling. Neural networks have been employed for gesture and sign language recognition using neuromorphic sensors [51], as well as for nonlinear system compensation in microwave power amplifiers through digital predistortion techniques [52,53]. Similarly, intelligent control strategies based on neural networks have been applied to robust control problems in automotive systems, addressing sensor delays and nonlinear dynamics [54,55]. Collectively, these applications highlight AI’s ability to model complex relationships that are difficult to capture using traditional analytical methods.

As AI methodologies mature, their influence is extending beyond application-level systems into the design of the underlying hardware itself. The same principles that enable learning-based perception, optimization, and control are now being leveraged to assist in electronic design tasks, including logic synthesis, verification, and architectural exploration. In this context, AI is no longer limited to accelerating end-user applications, but is increasingly reshaping the way digital circuits and systems-on-chip are specified, generated, and optimized, paving the way for intelligent, automation-driven design flows.

LLM-based HDL generation represents one of the most transformative frontiers in modern EDA. Recent research highlights that LLMs are evolving from general-purpose text generators into intelligent design assistants capable of interpreting natural-language specifications and producing synthesizable Verilog and VHDL code. Fine-tuned models demonstrate that compact LLMs can achieve high accuracy when trained on domain-specific datasets. These datasets often include multi-granularity Verilog corpora constructed using hierarchical summaries and Pyramid-of-Thought reasoning structures. Such advances bring HDL generation closer to a true “natural-language-to-hardware” workflow, reducing designer effort and lowering the barrier to entry for modern digital design methodologies [56,57].

Building on these advances, a growing body of work has explored different strategies to operationalize LLM-based HDL generation, ranging from direct natural-language-to-RTL translation to more sophisticated frameworks that incorporate data-centric training, self-reflection, and verification-driven refinement. Some approaches focus on fine-tuning domain-specific models to improve syntactic and functional correctness, while others leverage iterative feedback from compilers, simulators, or high-level synthesis tools to progressively refine generated designs. In parallel, large-scale foundation and commercial LLMs have emerged as flexible backbones that, although not hardware-specific by design, can be adapted to support HDL generation and reasoning tasks.

To contextualize these efforts, Table 2 provides a comparative overview of representative RTL code-generation tools and LLM-based approaches. The table highlights each method’s primary purpose and target language. This comparison helps clarify how different classes of models and tools contribute to the emerging natural-language-to-hardware paradigm and positions them within the broader landscape of AI-assisted digital design.

Table 2. Comparison of RTL code generation tools and LLM-based approaches.

Tool	Primary Purpose	Target Language
RTLCoder [58]	Automatic RTL generation from natural-language specifications	Verilog
Spec2RTL-Agent [59]	End-to-end translation of complex specifications into hardware implementations	Synthesizable RTL (via C++ and HLS)
OriGen [60]	Improving RTL generation quality through self-reflection and code augmentation	Verilog
AutoChip [61]	Iterative RTL generation with automatic compiler and simulator feedback	Verilog
CodeV [62]	Data-centric HDL generation via multi-level summarization and instruction tuning	Verilog
VeriCoder [63]	RTL generation via fine-tuning on functionally validated, test-driven datasets	Verilog
StarCoder [64]	Open-access foundation model for large-scale multi-language code generation	Multi-language code
CodeLlama [65]	Open-access code LLM commonly used as a base model for HDL fine-tuning	Multi-language code
DeepSeek-Coder [66]	Code-oriented LLM optimized for programming and synthesis-related tasks	Multi-language code
CodeQwen [67]	Large-scale code LLM with strong reasoning and long-context support	Multi-language code
Gemini [68]	Commercial multimodal LLM for specification-to-code and RTL reasoning	Multi-language code
GPT [69]	Commercial general-purpose LLM widely used for RTL generation and refinement	Multi-language code
ChatEDA [70]	Autonomous orchestration of EDA workflows using LLM agents	EDA scripts

3.1. RTLCoder

RTLCoder is a fully open-source framework for LLM-assisted RTL code generation, designed to translate natural-language hardware specifications directly into synthesizable Verilog. In contrast to prior approaches that rely on proprietary commercial LLMs, RTLCoder is built upon a customized open-source model with approximately 7 billion parameters, enabling local deployment and avoiding intellectual-property and data-privacy concerns. The framework targets a key limitation in existing AI-assisted hardware design flows by providing an end-to-end open solution tailored specifically for digital circuit description and generation [58].

A central contribution of RTLCoder is its automated dataset construction pipeline, which addresses the scarcity of high-quality, domain-specific training data for hardware-oriented LLMs. The authors propose a multi-stage process that generates diverse instruction–code pairs by combining domain keyword extraction, instruction synthesis, mutation-based augmentation, and syntax-validated Verilog generation. This process results in a large-scale dataset comprising tens of thousands of high-quality RTL samples, enabling effective fine-tuning of the model for hardware design tasks and improving generalization across representative RTL benchmarks.

Beyond data generation, RTLCoder introduces a training strategy that incorporates code-quality-aware feedback to enhance generation accuracy. Multiple candidate RTL implementations are produced for each instruction and evaluated using automated syntax and quality checks, allowing the model to preferentially learn from higher-quality outputs. Additionally, RTLCoder employs model quantization techniques to significantly reduce memory requirements, enabling efficient inference on resource-constrained platforms. These characteristics position RTLCoder as a practical and extensible foundation for future research on AI-driven RTL generation and integration within open-source RTL-to-GDSII design workflows.

3.2. Spec2RTL-Agent

Spec2RTL-Agent is an LLM-based multi-agent framework designed to automate the generation of RTL code directly from complex and unstructured hardware specification documents. Unlike other LLM-based approaches that rely on simplified prompts or require extensive human guidance, Spec2RTL-Agent targets realistic specification inputs that may span dozens of pages and include heterogeneous information such as tables, figures, equations, and informal textual descriptions. By explicitly modeling the stages of human-driven hardware development, the framework aims to bridge the gap between research prototypes and practical RTL implementation workflows [59].

A central contribution of Spec2RTL-Agent is its multi-agent collaboration architecture, which decomposes the RTL generation task into three coordinated stages: understanding, coding, and reflection. In the understanding stage, dedicated agents analyze and summarize the specification, extract constraints, and construct structured, step-by-step implementation plans. The coding stage then progressively refines the design by generating intermediate representations—including pseudocode, Python, and synthesizable C++—before converting them into RTL via high-level synthesis. This progressive refinement strategy improves correctness and synthesis compatibility compared to directly generating RTL in a single pass.

To further enhance robustness, Spec2RTL-Agent incorporates an adaptive reflection module that continuously verifies intermediate outputs and identifies the source of errors across the generation pipeline. When discrepancies are detected, the system can revise instructions, regenerate specific sub-functions, or backtrack to earlier design stages, closely mirroring how human designers debug complex RTL implementations. This reflective capability significantly reduces the need for manual intervention and enables the system to recover from both local coding errors and higher-level specification misunderstandings.

Experimental results reported in the original study demonstrate that Spec2RTL-Agent can generate correct RTL implementations from real-world specification documents with substantially fewer human interventions compared to baseline LLM-based approaches. These results position Spec2RTL-Agent as an end-to-end agent-based system for RTL generation from unstructured specifications, highlighting the potential of multi-agent LLM frameworks to play a transformative role in future AI-assisted VLSI design flows.

3.3. OriGen

OriGen is an open-source LLM-based tool designed to automatically generate synthesizable RTL code from natural-language hardware descriptions. The tool targets the reliability and openness limitations of some AI-assisted RTL generation approaches by providing a fully open workflow that does not depend on proprietary language models. OriGen focuses on producing correct and compilable Verilog code, making it suitable for integration into open-source digital design flows and for use in academic and research-oriented environments [60].

The OriGen model is trained using a data-centric approach that emphasizes code quality and structural consistency. Instead of relying solely on raw natural-language-to-RTL pairs, OriGen leverages a code-to-code generation strategy in which existing Verilog designs are first abstracted into high-level descriptions and then regenerated into refined RTL implementations. This process allows the model to learn consistent coding patterns, structural regularities, and common design constructs found in real-world RTL codebases.

In addition, OriGen incorporates an iterative self-reflection mechanism to improve robustness. When generated RTL code fails compilation, compiler error messages are used as feedback to guide corrective regeneration steps. This enables the model to iteratively refine its outputs and resolve syntactic or structural issues in a manner analogous to human RTL debugging. Through this combination of structured training data and feedback-driven refinement, OriGen achieves reliable RTL generation while maintaining full openness and reproducibility within the AI-assisted hardware design workflow.

3.4. AutoChip

AutoChip is an LLM-based framework for automated generation of synthesizable Verilog HDL that explicitly incorporates compilation and simulation feedback into the code-generation loop. Unlike others LLM approaches, AutoChip models RTL development as an iterative process in which generated designs are repeatedly analyzed, corrected, and refined until they compile and pass functional testbenches. The tool is designed to reduce manual debugging effort by automating the interaction between large language models and conventional hardware design tools [61].

The AutoChip workflow begins with a natural-language design specification, which is used to prompt an LLM to generate an initial Verilog module. This module is then compiled and simulated using standard open-source tools, and any compilation errors or simulation mismatches are captured. These tool-generated diagnostics are fed back into the LLM as structured prompts, enabling the model to iteratively correct syntactic errors, resolve functional mismatches, and refine the RTL implementation. The process repeats until the design satisfies all testbench requirements or a predefined iteration limit is reached.

To improve efficiency and scalability, AutoChip supports different feedback strategies, including retaining only the most recent error context to limit prompt size and token usage. The framework can also leverage ensembles of LLMs, combining smaller and larger models to balance cost and accuracy. By tightly integrating LLM-based generation with traditional HDL compilation and simulation, AutoChip demonstrates how feedback-driven AI workflows can significantly improve the correctness and practicality of automated RTL generation within open-source hardware design flows.

3.5. CodeV

CodeV is a framework designed to generate Verilog HDL code and Chisel—from natural-language specifications. The tool addresses a key limitation of prior LLM-based HDL generators: the scarcity of high-quality training data and the poor suitability of synthetic, LLM-generated code for fine-tuning. Instead of relying on direct description-to-code synthesis, CodeV leverages real-world, high-quality open-source HDL repositories as the foundation for training, enabling more accurate and practical RTL generation across multiple hardware design scenarios [62].

The core idea behind CodeV is that LLMs are more effective at summarizing HDL code than generating it from scratch. Based on this observation, CodeV introduces a multi-level code summarization pipeline in which existing Verilog and Chisel modules are first collected, filtered, and syntax-checked, and then summarized by an LLM into both detailed functional descriptions and higher-level design specifications. These summary–code pairs are used to construct a high-quality instruction-tuning dataset, allowing the model to learn realistic hardware semantics, coding patterns, and structural conventions directly from validated designs.

To support diverse generation tasks, CodeV employs a supervised fine-tuning strategy that integrates chat-style code generation and fill-in-the-middle completion within a unified training framework. Language-specific tags are used to explicitly distinguish between Verilog and Chisel, improving multi-language robustness when training data is limited. As a result, CodeV models can generate complete RTL modules from specifications, assist in partial code completion, and operate across multiple HDLs. This design positions CodeV as a general-purpose, open-source LLM-based backend for HDL generation, suitable for both research and practical integration into modern open-source EDA workflows.

3.6. VeriCoder

VeriCoder is an LLM framework specifically designed to improve the functional correctness of automatically generated RTL code. Unlike some RTL generation approaches that primarily emphasize syntactic validity, VeriCoder explicitly targets semantic correctness by incorporating simulation-based validation into the data curation and model training process. The core contribution of VeriCoder lies in its functionally validated fine-tuning dataset, where each training example consists of a natural-language specification, a corresponding Verilog implementation, and a self-checking unit test that passes simulation [63].

The VeriCoder training pipeline relies on a feedback-directed refinement strategy guided by a teacher LLM. Given an initial RTL design and its natural-language specification, the teacher model automatically generates unit tests and evaluates the design through compilation and simulation. If the design fails, diagnostic feedback from the simulator is used to iteratively refine either the RTL code, the testbench, or both. This loop continues until the design passes simulation or a predefined iteration limit is reached. As a result, the dataset used for fine-tuning contains only designs that have been empirically validated for functional behavior, addressing a key limitation of earlier datasets that relied solely on syntax checks.

By fine-tuning a lightweight open-source base model on this validated dataset, VeriCoder achieves significant improvements in functional correctness on established RTL generation benchmarks such as VerilogEval and RTLLM. Experimental results demonstrate that models trained with functionally validated data outperform those trained on syntactically filtered datasets, underscoring the importance of verification-aware data construction. Positioned within the broader landscape of AI-assisted hardware design, VeriCoder illustrates how integrating traditional simulation-based verification into LLM workflows can substantially enhance the reliability and practical usability of automated RTL code generation.

3.7. StarCoder

StarCoder is a large open-access, code-oriented language model developed by the BigCode community with the goal of advancing transparent and reproducible research in AI-assisted programming. Designed primarily for multi-language code generation, completion, and transformation, StarCoder supports more than eighty programming languages and is released together with detailed documentation of its training data, model architecture, and evaluation protocols. Its open and permissive distribution makes it particularly attractive for research domains such as EDA, where reproducibility, inspectability, and licensing constraints are critical [64].

From a technical standpoint, StarCoder is a decoder-only Transformer model with approximately 15.5 billion parameters and support for long-context inputs of up to 8 K tokens. The model incorporates a fill-in-the-middle training strategy, enabling it to generate or complete code within partially specified files rather than strictly in an autoregressive left-to-right manner. This capability is especially relevant for hardware design workflows, where designers frequently modify, extend, or refactor existing HDL modules rather than writing designs entirely from scratch.

A distinguishing feature of StarCoder is its training corpus, derived from “The Stack”, a large collection of permissively licensed source code extracted from public repositories. The dataset includes a wide range of programming paradigms and coding styles, allowing the model to learn realistic syntactic and semantic patterns. Importantly, the data-curation process incorporates governance mechanisms such as license filtering and opt-out support, addressing ethical and legal considerations that are increasingly important when deploying generative models in both software and hardware design contexts.

In the context of HDL development, StarCoder serves as a general-purpose foundation model that can be applied to tasks such as Verilog and VHDL code generation, RTL refactoring, testbench creation, and documentation assistance. While not specialized exclusively for hardware description languages, its strong code-understanding and generation capabilities enable effective adaptation to HDL-centric workflows, either through prompt engineering or domain-specific fine-tuning. As such, StarCoder provides a flexible and open baseline for exploring AI-assisted HDL generation and complements more specialized LLM-based tools targeting automation within the RTL-to-GDSII design flow.

3.8. CodeLlama

CodeLlama is a family of large language models optimized for code understanding and generation, derived from the LLaMA 2 foundation models and further specialized using large-scale code-centric datasets. Although originally developed for general-purpose programming languages, its architectural design and training strategy make it well suited for hardware description language (HDL) generation tasks, including Verilog and VHDL code synthesis, module completion, and RTL refinement. By learning the relationship between natural-language descriptions and structured programming constructs, CodeLlama can translate high-level hardware specifications into synthesizable RTL implementations [65].

CodeLlama is trained through a multi-stage specialization pipeline that includes extensive code pretraining, optional language-specific fine-tuning, and instruction tuning. A notable feature of the model is its support for fill-in-the-middle training, which allows it to generate missing code segments given both preceding and following context. This capability is particularly valuable in HDL workflows, where designers frequently modify or extend existing RTL modules by inserting logic, pipeline stages, or control structures without rewriting entire files. In addition, the model supports extended context lengths, enabling reasoning over large RTL codebases composed of multiple interacting modules.

Within digital hardware design flows, CodeLlama can be applied to a range of HDL-centric tasks such as generating RTL from textual specifications, completing partially written Verilog or VHDL modules, and refactoring existing code to improve clarity or enforce design constraints. Its strong code-structure awareness enables it to capture common HDL idioms, including synchronous and combinational processes, parameterized modules, and hierarchical design patterns. As a result, CodeLlama can serve as a practical backend for AI-assisted RTL development tools.

In the broader context of AI-assisted electronic design automation, CodeLlama functions as a general-purpose code intelligence engine that can be integrated with synthesis, simulation, and verification tools. When combined with domain-specific prompting or fine-tuning on HDL-focused datasets, the model can bridge the gap between informal design intent and formal RTL representations. This positions CodeLlama as a foundational model for emerging AI-driven EDA workflows aimed at accelerating and simplifying HDL-based hardware design.

3.9. DeepSeek-Coder

DeepSeek-Coder is LLM model specifically designed for code intelligence, covering tasks such as code generation, completion, infilling, and cross-file reasoning. Although originally evaluated on mainstream programming languages, its architecture and training strategy make it highly relevant for HDL generation workflows, including Verilog and VHDL. By learning syntax, structural patterns, and long-range dependencies in source code, DeepSeek-Coder can assist designers in translating high-level specifications into synthesizable HDL modules, scaffolding RTL templates, and refining control and datapath logic.

A key feature of DeepSeek-Coder is its repository-level pretraining strategy, where code is organized and learned at the project scale rather than as isolated files. This capability is particularly valuable for hardware design, where HDL projects often span multiple files with shared parameters, packages, and hierarchical module dependencies. The model learns to reason across files and maintain consistency between module interfaces, parameter definitions, and signal naming, which is essential when generating or modifying complex RTL designs.

DeepSeek-Coder also incorporates a fill-in-the-middle training objective, enabling it to generate missing code segments given both prefix and suffix context. This aligns naturally with common HDL development tasks, such as completing partially written always blocks, inserting pipeline stages, or modifying existing RTL while preserving surrounding logic. For HDL designers, this makes DeepSeek-Coder suitable for iterative RTL refinement, incremental design changes, and assistive editing within established codebases.

From a practical perspective, the permissive open-source license and availability of multiple model sizes make DeepSeek-Coder attractive for integration into open-source EDA flows and research prototypes. When combined with synthesis and verification tools, it can serve as an intelligent front-end for HDL generation, rapid prototyping, and design-space exploration. These characteristics position DeepSeek-Coder as a strong foundation for AI-assisted RTL generation and verification workflows in modern digital and VLSI design environments [66].

3.10. CodeQwen

Qwen is a family of LLMs developed by the Alibaba Group, designed as a general-purpose foundation model series with strong capabilities in reasoning, code generation, and tool use. The Qwen architecture follows a Transformer-based design and is pretrained on trillions of tokens covering natural language and source code, which provides a robust basis for understanding structured programming constructs and formal syntax. In the context of hardware design, these characteristics make Qwen particularly suitable for assisting with HDL generation tasks, where strict syntax, hierarchical structure, and logical consistency are required [67].

Beyond the base language models, the Qwen ecosystem includes specialized variants such as Code-Qwen and Code-Qwen-Chat, which are explicitly trained and fine-tuned on large-scale code corpora. These models demonstrate enhanced performance in code understanding, generation, and debugging tasks. Although originally evaluated on general-purpose programming benchmarks, the same capabilities naturally extend to hardware description languages such as Verilog and VHDL, enabling automated generation of RTL modules, interface definitions, and parameterized hardware blocks from textual specifications.

From an HDL generation perspective, Qwen-based models are particularly effective at capturing repetitive design patterns, enforcing syntactic correctness, and producing structured RTL code that aligns with common design idioms (e.g., finite state machines, datapath-controller separation, and parameterized modules). Their long-context support also enables the generation and refinement of larger HDL designs, including multi-module systems and testbench scaffolding, which are essential for realistic RTL-to-GDSII workflows.

Finally, the chat-aligned versions of Qwen enhance usability in interactive design settings, where iterative refinement of HDL code is required. Designers can prompt the model to explain generated RTL, modify existing modules, or adapt designs to new constraints (e.g., clocking schemes or interface protocols). As a result, Qwen and its coding-specialized variants represent a flexible open-source foundation for integrating LLM-assisted HDL generation into modern open-source EDA flows, complementing traditional synthesis, simulation, and formal verification tools.

3.11. Gemini

Gemini is a family of large multimodal language models developed by Google, designed to support advanced reasoning across text, code, images, and structured data. Unlike many open-source language models, Gemini is a proprietary and closed-source system, with model weights and training data not publicly released. Despite this, Gemini’s strong code-generation and reasoning capabilities make it relevant for EDA tasks, including HDL generation and verification assistance. By leveraging large-scale pretraining on diverse code and technical corpora, Gemini can interpret high-level hardware specifications and assist in translating design intent into structured RTL representations.

From an HDL generation perspective, Gemini can be applied to tasks such as Verilog and VHDL code synthesis from natural-language descriptions, completion of partially written RTL modules, and refactoring or documentation of existing designs. Its advanced reasoning abilities enable it to capture common hardware design patterns, including synchronous logic, finite state machines, parameterized modules, and hierarchical system organization. These capabilities allow Gemini to function as an intelligent design assistant, particularly in early-stage RTL development and rapid prototyping, albeit within the constraints of a closed-source deployment model.

A distinguishing aspect of Gemini is its multimodal capability, which enables the model to reason not only over textual specifications but also over diagrams, tables, and design documentation commonly found in hardware specifications. This feature is especially relevant for complex SoC and VLSI projects, where design intent is often distributed across multiple representation forms. By integrating information from different modalities, Gemini can provide more coherent and context-aware HDL generation and design explanations, even though its internal model mechanisms remain inaccessible for inspection or modification.

Within AI-assisted EDA workflows, Gemini is typically used in an interactive, human-in-the-loop manner, complementing traditional synthesis and verification tools rather than replacing them. Due to its proprietary nature, Gemini is generally accessed through cloud-based APIs, which may raise considerations related to data privacy, reproducibility, and long-term availability. Nevertheless, it serves as a representative example of how commercial, closed-source foundation models can augment HDL-centric design processes and influence emerging AI-assisted RTL-to-GDSII workflows.

3.12. GPT

GPT is a family of large language models developed by OpenAI and widely adopted as general-purpose foundation models for natural language understanding, reasoning, and code generation. GPT models are proprietary and closed-source, with model weights and training datasets not publicly released, and are typically accessed through cloud-based APIs. Despite this closed nature, GPT has had a significant impact on AI-assisted EDA research, particularly in the emerging area of HDL generation and verification assistance.

In the context of HDL-centric workflows, GPT models have demonstrated strong capabilities in generating Verilog and VHDL code from natural-language specifications, completing partially written RTL modules, and refactoring or documenting existing designs. Their instruction-following behavior and conversational interface make them especially effective for interactive, human-in-the-loop design scenarios, where designers iteratively refine RTL code based on synthesis or simulation feedback. GPT models are also capable of capturing common hardware design idioms, such as synchronous processes, finite state machines, and parameterized modules, enabling rapid prototyping at the RTL level.

GPT has also been used as a backend in several recent research tools that integrate large language models with traditional EDA workflows. These approaches typically combine GPT-based code generation with compilation, simulation, or formal verification feedback to improve correctness and robustness. In such settings, GPT acts as a reasoning and code-synthesis engine, while conventional EDA tools provide objective validation signals, illustrating how AI-driven generation can be tightly coupled with established verification methodologies.

From a methodological perspective, the widespread use of GPT in HDL generation research highlights both the potential and the limitations of proprietary foundation models in hardware design. While GPT offers strong performance and ease of use, its closed-source nature raises concerns related to reproducibility, data privacy, and long-term accessibility, particularly for academic and open-source communities. As a result, GPT is often used as a performance baseline or reference point against which emerging open-source, HDL-specialized language models are evaluated in the broader landscape of AI-assisted RTL-to-GDSII design flows.

Recent work has demonstrated the feasibility of using LLMs, specifically GPT-based systems, to generate hardware designs that are not only synthesizable but also fully manufacturable. In [71], GPT-4 was employed as the central design agent to create a complete Convolutional Neural Network (CNN) IC, following an “AI-by-AI” paradigm in which artificial intelligence is used to design another AI system. The process began with natural-language specifications provided to GPT-4, which generated a CNN model initially expressed in TensorFlow for training and validation on the MNIST dataset. Through iterative conversational refinement, the model was progressively downscaled from Python to C/C++, enabling subsequent translation into hardware using High-Level Synthesis (HLS). This workflow highlights GPT’s role as an intelligent assistant capable of bridging the gap between algorithmic machine-learning models and hardware-oriented descriptions.

The manufacturability of the GPT-generated CNN was validated by integrating the resulting hardware description into a complete open-source ASIC flow. After HLS conversion, the generated Verilog was physically implemented using the OpenLane RTL-to-GDSII flow and the open-source SKY130A PDK, producing a DRC- and LVS-clean layout. The CNN accelerator was then integrated into the Caravel SoC harness, enabling control and communication through an embedded RISC-V processor and allowing fabrication via an Efabless multi-project wafer shuttle. Post-layout results, including area, power consumption, and operating frequency, confirmed that the AI-generated design met realistic silicon constraints, ultimately demonstrating that GPT can contribute not only to HDL generation but also to the end-to-end realization of manufacturable CNN hardware using open-source tools [71].

3.13. ChatEDA

ChatEDA is an AI-assisted electronic design automation framework that leverages large language models to support multiple stages of the digital hardware design flow through a conversational interface. Rather than focusing on a single task such as RTL generation or verification, ChatEDA is designed as a general-purpose assistant capable of interpreting natural-language design intent and translating it into actionable EDA-related artifacts, including RTL code snippets, testbench components, constraint definitions, and verification queries. This interaction paradigm lowers the barrier to entry for hardware design and enables rapid prototyping and design-space exploration, particularly in early-stage development and educational settings [70].

From a methodological standpoint, ChatEDA combines a pretrained large language model with domain-specific prompt engineering and interfaces tailored to hardware design workflows. User inputs expressed in natural language are mapped to structured representations that guide the model toward generating syntactically correct and semantically meaningful HDL code or EDA commands. Typical use cases include assisting with Verilog or SystemVerilog module generation, explaining synthesis or timing analysis reports, supporting simulation setup, and helping formulate formal verification properties. The conversational nature of the system allows for iterative refinement, enabling designers to progressively constrain or adapt designs through dialogue.

Conceptually, ChatEDA positions large language models as intelligent front-end assistants rather than replacements for traditional EDA tools. The outputs generated by ChatEDA are intended to be processed by established simulation, synthesis, and verification engines, preserving compatibility with conventional RTL-to-GDSII flows. By bridging informal, natural-language specifications and formal hardware descriptions, ChatEDA demonstrates how conversational AI can enhance productivity, improve design comprehension, and support exploratory design activities while relying on deterministic EDA tools to ensure correctness and sign-off.

4. Synthesis Tools

Synthesis in electronic EDA is the automated process of converting high-level hardware descriptions into implementable circuitry. In practice, it transforms RTL code typically written in Verilog or VHDL into a gate-level netlist that defines the actual logic gates and interconnections to be fabricated on silicon. Synthesis can be divided into two main types RTL synthesis and logic synthesis: [72,73].

• RTL synthesis translates a high-level hardware description into a structural representation composed of registers, multiplexers, arithmetic units, comparators, and finite-state machines. At this stage, the tool infers the necessary hardware and performs technology-independent optimizations, such as constant propagation, operator sharing, and basic restructuring.
• Logic synthesis, in contrast, takes this structural representation and converts it into an optimized gate-level netlist using actual standard cells from a specific technology library. This involves Boolean minimization, structural rewriting, technology mapping, and timing-driven optimizations like gate sizing and buffer insertion.

In practice, synthesis is performed for both FPGAs and ASICs, but the goals and underlying technologies differ significantly. FPGA synthesis maps the RTL design onto a predefined and highly regular fabric composed of Lookup Tables (LUTs), Configurable Logic Blocks (CLBs), Flip-Flops (FFs), Digital Signal Processing (DSP) slices, and Block Random-Access Memorys (BRAMs). Because the FPGA architecture is fixed, optimization focuses on LUT packing, resource utilization, and routing congestion [74]. In contrast, ASIC synthesis maps the design directly into a custom set of standard cells from a chosen technology node, providing much finer control over performance, area, and power. ASIC synthesis is typically more timing-driven and involves complex optimizations such as gate sizing, buffer insertion, and retiming to meet aggressive frequency requirements.

It is also important to note that not all synthesis tools support both FPGA and ASIC implementations; many are specialized for one domain. FPGA-oriented tools must understand the specific architecture of each vendor’s device family (e.g., Xilinx, Altera, Lattice), while ASIC synthesis tools rely on the characteristics of the PDK and the associated standard-cell library. As a result, the synthesis flow depends heavily on the target FPGA architecture or ASIC technology node, making FPGA and ASIC synthesis similar in concept but fundamentally different in capabilities, constraints, and tooling support.

In the following subsection, we present an overview of the most widely used open-source synthesis tools in modern digital design workflows. Table 3 summarizes their key capabilities, including language support and compatibility with RTL-to-netlist, FPGA, and ASIC implementation flows.

Table 3. Summary of the main open-source synthesis tools.

Tool	Language Support	RTL-Netlist	FPGA Impl.	ASIC Impl.
Yosys [37]	Verilog (limited SV), RTLIL	Yes	Yes	Yes
ABC (Berkeley) [75]	BLIF, AIG, limited Verilog	Yes	Partial	Yes
ODIN II (VTR) [76]	Verilog	Yes	Yes	No
GHDL-Yosys Plugin [77,78]	VHDL	Yes	Yes	Yes
Synlig [79,80]	SystemVerilog	Yes	Yes	Yes
Mockturtle (EPFL) [81]	AIG, MIG, XAG, Boolean networks	Indirect	No	No

These tools form the foundation of RTL-to-netlist conversion for both FPGA and ASIC implementations, enabling designers to elaborate, optimize, and map hardware descriptions using fully transparent and customizable toolchains. By summarizing their capabilities, languages supported, and implementation targets, the subsection provides a clear reference for selecting the appropriate synthesis solution depending on design requirements, target technology, and workflow integration.

4.1. Yosys Open Synthesis Suite

Yosys is a widely adopted open-source framework for the synthesis of digital hardware described in Verilog. It supports most synthesizable Verilog-2005 constructs and provides a modular, pass-based architecture that allows designers to tailor synthesis flows using built-in transformations or custom extensions. Yosys performs a full suite of tasks including parsing, elaboration, RTL optimization, technology-independent synthesis, and technology mapping, and it integrates seamlessly with the ABC logic-optimization engine for advanced Boolean rewriting and cell mapping [37]. Its ecosystem extends into formal verification by exporting intermediate representations compatible with tools such as SMT solvers or equivalence-checking engines [82]. Combined with nextpnr, Yosys forms a fully open-source end-to-end toolchain capable of targeting modern commercial FPGAs, enabling Verilog-to-bitstream compilation across a range of architectures and device families [74].

Although Yosys has become the leading open-source synthesis framework, it also presents several limitations. Its SystemVerilog support, while rapidly improving through the Surelog Universal Hardware Data Model (UHDM) front-end, is still less complete and less mature compared to commercial EDA tools, particularly for advanced verification-oriented constructs and complex interfaces [83]. Yosys also lacks native support for VHDL, relying instead on external front-ends such as GHDL, which can introduce compatibility gaps or additional integration effort [84]. Furthermore, Yosys does not include a built-in timing-driven optimization engine comparable to those found in industrial ASIC synthesis tools, limiting its ability to perform aggressive gate sizing, path balancing, or automated constraint-driven closure.

Finally, because it is designed as a research-friendly and modular framework, achieving production-grade QoR (power, performance, area) often requires expert tuning and complementary tools like ABC or LSOracle [85,86,87]. Despite these disadvantages, Yosys remains the cornerstone of open-source synthesis flows due to its flexibility, transparency, and broad community support.

4.2. ABC (Berkeley)

ABC is a powerful open-source framework developed at UC Berkeley for logic synthesis, optimization, and formal verification, with a strong emphasis on sequential circuits. It operates primarily on And-Inverter Graphs (AIGs), an efficient and compact data structure used to represent Boolean networks. ABC provides an extensive collection of algorithms for logic rewriting, refactoring, decomposition, and Boolean Satisfiability (SAT)-based optimization, enabling advanced transformations for both combinational and sequential logic [75].

Its technology-mapping capabilities support LUT-based mapping for FPGA architectures as well as standard-cell mapping for ASIC flows. Because of its strong optimization engines and script-driven flexibility, ABC is widely used as the logic synthesis backend for tools such as Yosys and OpenLane, often delivering significant improvements in area and timing compared to simpler synthesis approaches [88].

In addition to synthesis, ABC integrates robust formal verification features, including SAT solvers, equivalence checking, property checking, and algorithms for model checking and sequential verification. These capabilities allow designers to validate circuit correctness, ensure equivalence between RTL and optimized netlists, detect unreachable states, and construct proofs using techniques such as induction, interpolation, and abstraction refinement [75].

4.3. ODIN II Verilog-to-Routing

ODIN II is the Verilog front-end of the open-source Verilog-to-Routing (VTR) toolflow, responsible for parsing synthesizable Verilog, performing elaboration, and generating a technology-independent netlist suitable for FPGA architecture exploration. It infers arithmetic units, multiplexers, registers, and hard blocks defined in the target architecture, producing a BLIF representation that is later optimized, packed, placed, and routed by downstream VTR tools.

As part of the VTR 9.0 release, ODIN II continues to support academic and experimental FPGA research by enabling logic decomposition and architecture-aware mapping driven entirely by user-defined FPGA architectural descriptions [76].

Beyond VTR itself, ODIN II also plays an important role in the OpenFPGA framework [89,90], where it serves as the initial synthesis and elaboration engine for custom FPGA fabrics. Because both VTR and OpenFPGA rely on architecture description files to define logic blocks, routing resources, and hard macro capabilities, ODIN II can seamlessly translate Verilog RTL into structures tailored to arbitrary FPGA architectures. This makes the combination of ODIN II, VTR, and OpenFPGA a powerful open-source flow for rapid prototyping, EDA research, and the development of novel reconfigurable architectures.

4.4. GHDL-Yosys Plugin

The GHD–Yosys plugin is an open-source integration layer that enables the use of GHDL as a VHDL front-end for the Yosys synthesis framework [77,78]. Its primary function is to translate fully elaborated VHDL designs produced by GHDL into Yosys’s internal RTLIL, thereby allowing VHDL-based designs to benefit from Yosys’s synthesis, optimization, and technology mapping capabilities.

Unlike traditional synthesis flows that rely on proprietary VHDL compilers, the GHDL–Yosys plugin provides a fully open and reproducible path from VHDL source code to synthesized netlists. The plugin leverages GHDL’s mature VHDL front-end to handle language parsing, elaboration, and semantic analysis, while delegating optimization and backend processing to Yosys. This separation of concerns improves robustness and maintainability, and aligns with the modular architecture increasingly adopted in open-source EDA toolchains.

By converting VHDL designs into RTLIL, the plugin enables seamless interoperability with Yosys-based FPGA and ASIC flows. The resulting RTLIL representation can be optimized and mapped to FPGA fabrics using tools such as VTR and nextpnr, or passed to ASIC-oriented physical design frameworks including OpenLane and OpenROAD [76,88,91]. This capability effectively extends Yosys beyond its native Verilog focus, making it a language-agnostic synthesis engine within the open-source ecosystem.

The GHDL–Yosys plugin bridges VHDL design methodologies with modern open-source synthesis and physical design flows.. It enables designers, researchers, and educators to develop end-to-end RTL-to-GDSII pipelines using VHDL without dependence on proprietary EDA tools, thereby supporting transparency, reproducibility, and accessibility in digital hardware design.

4.5. Synlig

Synlig is an open-source SystemVerilog front-end for synthesis that builds upon the Surelog parser and the UHDM to provide comprehensive support for the IEEE 1800 SystemVerilog standard [79,80,83]. In this architecture, Surelog is responsible for accurate parsing and elaboration of SystemVerilog designs, including advanced language constructs such as interfaces, packages, assertions, covergroups, classes, and deeply nested generate blocks, while UHDM serves as a standardized, tool-independent intermediate representation.

By leveraging UHDM, Synlig decouples language front-end processing from synthesis back-end implementation, enabling a clean and modular design flow. Synlig uses the UHDM representation and translates it into Yosys’s internal RTLIL format, allowing the design to undergo logic synthesis, optimization, and technology mapping using the Yosys framework.

A key contribution of Synlig is its integration with the Yosys interface [92], which enables fully open-source synthesis of modern SystemVerilog RTL targeting both FPGA and ASIC platforms. This capability bridges a long-standing gap in open-source digital design flows, where incomplete SystemVerilog support previously limited the adoption of advanced RTL coding styles. Through this integration, designs written in SystemVerilog can seamlessly flow from high-level RTL descriptions through Yosys-based synthesis and into physical design frameworks such as OpenLane and OpenROAD.

Synlig plays a central role in enabling end-to-end, reproducible RTL-to-GDSII flows using open-source tools. By combining industrial-grade SystemVerilog parsing, a standardized intermediate representation, and tight integration with synthesis and physical design frameworks, Synlig significantly narrows the feature gap between proprietary EDA solutions and open-source design infrastructures, making it particularly valuable for research, education, and emerging ASIC design methodologies.

4.6. Mockturtle

Mockturtle is an open-source logic network library designed to support research and development in logic synthesis, optimization, and technology mapping. Rather than operating directly on HDL descriptions, Mockturtle provides a unified and extensible framework for constructing and manipulating Boolean logic networks that serve as technology-independent, netlist-like representations of digital circuits. Supported network models include And-Inverter Graphs (AIGs), Majority-Inverter Graphs (MIGs), XOR-And Graphs (XAGs), and general Boolean networks [81].

A key strength of Mockturtle lies in its focus on advanced logic optimization algorithms that operate at the structural and Boolean levels of these logic networks. Through techniques such as rewriting, refactoring, resubstitution, and logic decomposition, Mockturtle incrementally transforms Boolean networks into optimized forms while preserving functional equivalence. The resulting networks can be interpreted as partial netlists, capturing the connectivity and logic structure of a design without binding it to a specific target technology or standard-cell library.

Mockturtle is commonly used as a backend logic optimization engine in both academic and open-source EDA flows. It has been integrated with synthesis frameworks such as Yosys, where logic networks generated or refined by Mockturtle are subsequently translated into synthesis-ready internal representations and further processed for technology mapping and physical implementation.

5. Simulation and Verification Tools

Simulation is a critical component of the digital design flow, serving as a primary mechanism for validating functional correctness before a design undergoes synthesis and physical implementation. At the front-end stage, simulation allows designers to evaluate the behavior of RTL descriptions, verify logical operations, and ensure compliance with architectural requirements well before committing to more expensive downstream processes [93,94]. By providing a controlled environment in which test stimuli can be applied and design responses observed, simulation enables early detection of functional errors, reducing the risk of design rework and minimizing the likelihood of costly failures later in the RTL-to-GDSII process.

Beyond simulation, verification encompasses a broader set of methodologies aimed at establishing design correctness with higher confidence. While simulation is inherently scenario-based and dependent on the quality of test stimuli, verification techniques—including assertion-based verification and formal methods—seek to systematically validate design properties across a much wider state space. In this context, simulation and formal verification are complementary: simulation is effective for debugging and performance evaluation, whereas formal verification can exhaustively prove correctness properties, detect corner-case failures, and ensure consistency across abstraction boundaries, such as between RTL descriptions and synthesized netlists [94].

Simulation also supports iterative refinement throughout the design cycle by enabling verification of module interactions, protocol compliance, pipeline behavior, and system-level integration. As modern systems increasingly incorporate heterogeneous components and third-party intellectual property, simulation-based verification becomes essential for ensuring interoperability and functional consistency across subsystems [17,93,94]. Complementary verification techniques, such as logic equivalence checking and property checking, further strengthen confidence in correctness by validating that optimizations and synthesis transformations preserve functional intent.

In addition to functional validation, simulations provide a foundation for advanced verification methodologies, including constrained-random testing, assertion-based verification, regression automation, and coverage-driven validation [95,96,97]. When combined with formal verification tools, these approaches enable more robust verification strategies that reduce verification gaps and increase confidence in safety, reliability, and performance guarantees.

From an educational and accessibility perspective, open-source simulation and verification frameworks play a vital role in democratizing digital design workflows. Tools such as Verilator [38], Icarus Verilog [98], cocotb [99], OpenSTA [100], and GTKWave [101], among others, provide high-quality capabilities spanning RTL simulation, co-simulation, waveform analysis, timing verification, and formal backends without the financial barriers imposed by commercial licenses. As summarized in Table 4, these open-source tools collectively support a comprehensive spectrum of simulation and verification methodologies, forming an accessible and reproducible foundation for education, research, and innovation in modern EDA practices.

Table 4. Summary of the main open-source simulation, verification, and timing-analysis tools.

Tool/Framework	Language Support	Simulation/Analysis Type	Verification Methodology
Verilator [38]	Verilog, SystemVerilog (subset)	Cycle-accurate compiled simulation	C++/SystemC TBs, cocotb
Icarus Verilog [98]	Verilog-2005	Event-driven RTL simulation	Verilog TBs, cocotb
cocotb [99]	Via simulators	Python-driven co-simulation	Python verification (drivers, monitors, scoreboards)
GTKWave [101]	VCD/FST/LXT	Waveform visualization	Visual debugging
Yosys-SMTBMC [102]	Verilog, SystemVerilog (subset)	Formal model checking (SMT/SAT)	Property checking, BMC, k-induction
EQY [103]	Verilog, SystemVerilog (subset)	Formal equivalence checking	Gold-vs-gate equivalence, SMT/SAT-based model checking
CoSA [104]	CoreIR, Verilog (via CoreIR)	SMT-based symbolic model checking	Safety/liveness checking, equivalence checking
OpenSTA [100]	Gate-level Verilog + .lib	Static timing analysis	SDC timing verification
OpenTimer [105]	Gate-level Verilog + .lib	Parallel static timing analysis	Critical-path timing verification
Tatum (VTR) [106]	FPGA netlists	FPGA timing analysis	Architecture-level timing verification

5.1. Verilator

Verilator is an open-source hardware simulation tool that compiles RTL written in Verilog or a subset of SystemVerilog into cycle-accurate, high-performance C++ or SystemC models rather than interpreting them as in traditional event-driven simulators [38,107]. It performs linting and static checks on the source HDL, then generates .cpp and .h files representing the design, which are compiled with a standard C++ compiler to produce an executable model.

The resulting simulation is cycle-accurate and significantly faster than interpreted HDL simulators, often by one or more orders of magnitude, because the synthesized C++ model benefits from compiler optimizations, modern CPU microarchitectures, and multithreading support. As an open-source project released under the LGPL and Artistic 2.0 licenses, Verilator is widely supported by the community and by organizations such as the CHIPS Alliance [108], making it a cornerstone tool in open-source EDA flows for both FPGA and ASIC development.

Thanks to its speed, openness, and broad compatibility, Verilator is highly effective for simulating large designs such as processors and SoC, executing long verification test suites, and supporting automated regression testing. Its ability to generate optimized C++ or SystemC models enables fast, cycle-accurate simulation, making it suitable for software–hardware co-simulation, continuous integration pipelines, and formal verification environments.

Recent studies further demonstrate Verilator’s suitability for high-performance system-level simulation. The work in [109] shows that compiling RTL into C++ models enables a high-speed SoC simulation environment that significantly outperforms traditional RTL simulation while preserving cycle accuracy, allowing rapid validation, benchmarking, and firmware testing. Likewise, the workflow presented in [110] integrates Verilator-generated SystemC models into an automotive SoC platform, enabling realistic and efficient processor benchmarking with real workloads and peripherals. Together, these studies highlight Verilator’s maturity as an open-source engine capable of supporting advanced system-level verification and early software–hardware co-validation.

5.2. Icarus Verilog

Icarus Verilog is an open-source HDL simulation and synthesis tool that implements the IEEE Verilog-2005 standard. It is widely used in education, research, and small-to-medium hardware design projects due to its accessibility, cross-platform compatibility, and strong support for both structural and behavioral Verilog constructs [98]. As an event-driven simulator, Icarus Verilog handles timing controls, delays, and scheduling semantics defined by the Verilog language, making it suitable for functional RTL validation and early prototyping.

The Icarus Verilog workflow operates in two stages. In the compilation stage, the iverilog compiler parses the Verilog sources, elaborates module hierarchies, resolves procedural and structural elements, and generates an intermediate simulation file in the Verilog Virtual Processor (VVP) format. During simulation, the vvp runtime executes this intermediate representation by performing event scheduling, evaluating delta cycles, propagating signal changes, and interpreting Verilog timing constructs. When waveform dumping commands are included in the testbench, Icarus Verilog produces trace files such as Value Change Dump (VCD) that can be inspected using visualization tools.

Although it is not optimized for very large or performance-intensive designs, Icarus Verilog remains a key component of the open-source EDA ecosystem. Its simplicity, compatibility with Python-based verification frameworks such as cocotb [99], and integration with tools like Yosys [37] and GTKWave [101] make it ideal for academic laboratories, verification tutorials, and rapid functional testing. Moreover, its support for a wide range of behavioral constructs allows users to debug and validate RTL designs effectively before migrating to higher-performance tools like Verilator.

5.3. cocotb

cocotb is an open-source verification framework that enables designers to develop testbenches entirely in Python rather than using traditional HDL languages. By leveraging Python’s expressive syntax and extensive ecosystem of libraries, cocotb enhances productivity, readability, and maintainability in hardware verification [99]. Its coroutine-based architecture allows users to create complex temporal behaviors, implement reusable verification components, and construct drivers, monitors, and scoreboards with familiar high-level programming constructs [111,112].

Internally, cocotb operates by co-simulating with an external HDL simulator through a foreign function interface. It supports a wide range of simulators, including Verilator [38], Icarus Verilog [98], GHDL [78], and several commercial tools, enabling seamless integration into both open-source and industrial verification environments. cocotb registers callbacks with the underlying simulator, allowing Python routines to drive signal activity, synchronize with clock events, wait on triggers, generate stimulus, and perform automated checking. This architecture makes it possible to incorporate Python-based randomization, data analysis, and regression automation directly into the verification flow.

Thanks to its flexibility and strong alignment with modern software engineering practices, cocotb has gained substantial traction in contemporary verification workflows. Its ability to integrate seamlessly with scripting environments, regression frameworks, and pipelines makes it particularly suitable for large-scale, automated validation. By leveraging Python’s expressiveness and extensive library ecosystem, cocotb effectively bridges hardware and software verification paradigms, offering a highly productive and powerful framework for functional validation, design exploration, and rapid prototyping across a wide range of digital systems.

5.4. SymbiYosys and Yosys-SMTBMC

Formal verification has emerged as a fundamental complement to simulation in modern digital design flows, particularly for control-dominated hardware where corner cases and rare state interactions are difficult to expose through stimulus-driven testing. In the open-source ecosystem, this capability is primarily enabled through the combined use of SymbiYosys and the Yosys-SMTBMC verification engine.

SymbiYosys (SBY) is an open-source formal verification framework built around the Yosys synthesis infrastructure [37]. Rather than acting as a solver itself, SymbiYosys provides a structured orchestration layer that coordinates RTL elaboration, property extraction, solver invocation, and result reporting. Verification tasks are described using concise and human-readable .sby configuration files, which specify the verification mode, depth bounds, constraints, and engines to be employed [102]. This abstraction significantly lowers the entry barrier to formal verification by shielding designers from low-level solver details while still allowing fine-grained control when needed.

At the core of many SymbiYosys verification flows lies Yosys-SMTBMC, a bounded model checking engine that is tightly integrated with Yosys. After the RTL design is processed and lowered by Yosys, Yosys-SMTBMC translates the resulting transition system into SMT form and dispatches it to a backend SMT solver. Design intent is captured through SystemVerilog Assertions (SVA) or equivalent safety properties, enabling exhaustive reasoning over all reachable states within a given bound. This approach contrasts sharply with traditional simulation, which explores only a limited subset of behaviors defined by explicit test vectors [113,114].

Yosys-SMTBMC supports multiple verification strategies, including bounded model checking for counterexample discovery, k-induction for proving invariants, and unbounded proof techniques for establishing global correctness properties. When a property violation is detected, the tool produces a concrete counterexample trace that can be visualized as a waveform, allowing designers to debug failures using familiar simulation-style workflows. This tight feedback loop makes formal methods practical even for engineers without deep formal methods expertise.

Within an RTL-to-GDSII design methodology, the SymbiYosys and Yosys-SMTBMC combination plays a critical role in front-end verification. It is particularly effective for validating finite-state machines, arbitration logic, protocol compliance, and safety-critical properties such as mutual exclusion, liveness, and deadlock freedom. By integrating seamlessly with open-source synthesis and implementation flows, these tools enable rigorous correctness checking early in the design cycle, reducing the risk of costly functional errors propagating into synthesis and physical implementation stages.

5.5. Equivalence Checking with Yosys (EQY)

Equivalence Checking with Yosys (EQY) is an open-source formal verification framework purpose-built to determine whether two hardware designs exhibit identical functional behavior under all possible inputs and states. It is implemented as a front-end driver program that leverages the Yosys synthesis infrastructure to elaborate and transform each design into a canonical intermediate representation, thereby enabling formal equivalence reasoning across RTL, post-synthesis, or refactored implementations [103]. The primary use case of EQY is to verify that design transformations—such as optimizations, refactorings, or synthesis tool outputs—preserve functional correctness relative to a trusted “gold” design.

EQY uses simple, human-readable configuration files with the ‘.eqy’ extension that describe two designs: the gold design, representing the reference, and the gate design, representing the candidate to be checked for equivalence. Each section includes a sequence of Yosys commands to read, elaborate, and prepare the design for equivalence analysis. Intermediate verification properties are defined in terms of matched netlists and logic partitions that should be equivalent between the two designs. By identifying and grouping corresponding nets or modules, EQY reduces the global equivalence problem into smaller, tractable formal subproblems.

For formal checking, EQY invokes Yosys together with SMT/SAT-based engines such as smtbmc via SymbiYosys, applying bounded model checking strategies to prove that corresponding partitions produce identical outputs for all reachable states up to a specified bound. Verification failures generate counterexample traces, often in VCD form, which can be examined to pinpoint functional divergences between the designs. This workflow allows designers to rapidly diagnose and correct behavioral mismatches arising from microarchitecture changes, synthesis optimizations, or refactoring efforts [103].

By integrating with the Yosys ecosystem, EQY provides a practical and scalable approach to equivalence checking within open-source ASIC and FPGA toolchains. It complements other verification methodologies—such as simulation and property checking—by providing formal guarantees about the preservation of functional semantics across design transformations, thereby increasing confidence in the correctness of hardware implementations throughout the development lifecycle.

5.6. CoSA: CoreIR Symbolic Analyzer

CoSA is an open-source formal verification framework designed to perform symbolic model checking on hardware designs represented in the CoreIR intermediate representation. Unlike traditional hardware model checkers that primarily rely on propositional satisfiability (SAT), CoSA encodes verification problems into Satisfiability Modulo Theories (SMT), enabling native reasoning over bitvectors and arrays. This word-level modeling capability allows CoSA to more accurately capture the semantics of modern hardware designs, particularly those involving memories and parameterized structures, improving both expressiveness and scalability [104].

At its foundation, CoSA models hardware behavior using Symbolic Transition Systems (STSs), which formally describe the initial states, transition relations, and variable assignments of a design. Based on this representation, CoSA supports the verification of both safety properties—expressed as invariants that must hold in all reachable states—and liveness properties, which require that certain conditions occur infinitely often during execution. When properties are violated, CoSA produces counterexample traces that expose erroneous behaviors, enabling systematic debugging of complex control logic.

CoSA provides a broad set of formal analyses, including bounded model checking, k-induction, interpolation-based proofs, and equivalence checking. Equivalence verification is achieved by constructing synchronous products of transition systems, allowing CoSA to formally prove that two designs—such as pre- and post-optimization versions—exhibit identical observable behavior. A key innovation of CoSA is its ability to leverage CoreIR-generated metadata to automatically derive auxiliary lemmas, significantly improving verification performance for designs transformed by compiler optimization passes.

The framework is implemented in Python and built on top of PySMT, providing solver-agnostic access to modern SMT solvers such as Z3, CVC4, and MathSAT. Its modular architecture separates model encoding, analysis engines, and trace generation, enabling extensibility and support for multiple input formats, including CoreIR, symbolic transition systems, and BTOR2. Integrated within the Agile Hardware Project toolflow, CoSA demonstrates how SMT-based formal verification can be embedded directly into open-source hardware compilation and optimization pipelines, enabling rigorous correctness checking across multiple abstraction levels.

5.7. OpenSTA

OpenSTA is an open-source STA engine designed to evaluate and verify the timing behavior of digital circuits at the gate level. Using Liberty (.lib) timing models, gate-level Verilog netlists, and Synopsys Design Constraints (SDC), OpenSTA determines whether all timing paths satisfy setup, hold, and clocking requirements [100]. As static timing analysis is a fundamental step in the ASIC physical design flow, OpenSTA enables designers to perform timing checks at multiple stages, including post-synthesis, post-placement, and post-routing [17,94].

Designers interact with OpenSTA through a Tcl-based interface that allows expressive timing queries, custom reports, and integration into automated flows. Its native support for industry-standard timing formats allows OpenSTA to function as a drop-in replacement for commercial STA tools in academic, research, and open-source environments. Because it evaluates both early and late timing, OpenSTA provides accurate insight into timing margins and potential violations across different process and operating conditions.

As part of the OpenROAD toolchain [91], OpenSTA serves as the timing backbone of the fully automated RTL-to-GDSII flow. It provides real-time feedback to timing-driven optimization steps such as placement refinement, buffering, and gate resizing, enabling iterative timing closure without reliance on proprietary tools. By offering a transparent, accessible, and extensible timing engine, OpenSTA plays a critical role in democratizing physical design and enabling end-to-end open-source ASIC implementation workflows [115,116].

5.8. OpenTimer

OpenTimer is an open-source, high-performance STA engine designed to deliver fast and accurate timing evaluation for digital circuits at the gate level. Implemented in modern C++ with extensive use of parallel programming techniques, OpenTimer supports multi-threaded execution, allowing it to exploit multi-core architectures for substantial speedups over traditional single-threaded timing analyzers. Like commercial STA tools, OpenTimer uses .lib timing models, gate-level Verilog netlists, and SDC constraints to compute setup, hold, and clocking checks across sequential and combinational paths [105]. Its performance-oriented architecture makes it especially suitable for large ASIC designs and environments where rapid timing feedback is critical.

A key feature of OpenTimer is its support for incrementaltiming analysis, enabling selective recomputation of timing information when only portions of the design are modified. This capability significantly accelerates iterative optimization loops, such as buffering, logic restructuring, and timing-driven placement adjustments, since only the affected subgraphs of the timing graph require recomputation. OpenTimer also provides comprehensive reporting capabilities, including critical-path extraction, slack analysis, delay breakdowns, and multi-corner analysis. Its modular design and open-source availability make it a valuable platform for exploring new EDA algorithms, optimization heuristics, and machine learning-based timing prediction strategies [117,118].

OpenTimer is increasingly used in academic and open-source physical design flows due to its speed, extensibility, and compatibility with widely adopted EDA formats. Although not as deeply integrated into automated RTL-to-GDSII flows as OpenSTA, it is frequently employed in research prototypes and experimental toolchains that demand rapid timing evaluation across multiple iterations [119,120]. Its emphasis on performance, coupled with its flexible Application Programming Interface (API), makes OpenTimer particularly attractive for large-scale ASIC development, timing-closure research, and emerging methodologies in parallel and distributed timing analysis.

5.9. Tatum (VTR)

Tatum is the STA engine integrated into the VTR framework, a widely used open-source toolchain for FPGA architecture research and experimental EDA flows [76,106]. Designed specifically for timing analysis in reconfigurable fabrics, Tatum evaluates timing characteristics across LUTs, routing networks, CLBs, and architecture-specific primitives. By supporting flexible architecture descriptions and customizable timing models, Tatum enables researchers to analyze the performance implications of architectural modifications and routing strategies in academic or prototype FPGA environments.

A core strength of Tatum is its support for parallel and incremental timing analysis, which allows large FPGA designs to be evaluated efficiently across different routing iterations. During timing-driven optimization, Tatum computes setup and hold checks, critical-path delays, and slack metrics across the timing graph, guiding placement and routing algorithms toward timing-optimized solutions. Its architecture-agnostic approach enables the exploration of novel FPGA fabrics, heterogeneous logic blocks, and emerging routing paradigms, making it a powerful engine for academic research and open-source EDA experimentation [89].

5.10. GTKWave

GTKWave is an open-source waveform visualization tool widely used in digital design workflows to inspect and analyze simulation traces. Supporting formats such as VCD, Fast Signal Trace (FST), and LXT Waveform Format (LXT), GTKWave provides designers with an intuitive graphical interface for examining signal transitions, timing relationships, and functional behaviors across hierarchical RTL modules [101]. Its compatibility with virtually all open-source and commercial simulators makes it a standard component of verification environments, providing essential visibility into the internal activity of a design during simulation.

A key advantage of GTKWave is its flexibility and powerful signal navigation capabilities. Users can search for signals, group them hierarchically, add custom display markers, and annotate waveforms to facilitate debugging and documentation. The tool also supports advanced features such as zoom-based time exploration, color customization, value highlighting, and cursor-based measurement of timing intervals. These capabilities make GTKWave particularly valuable when diagnosing functional mismatches, verifying protocol behavior, or identifying the root causes of timing or synchronization issues.

GTKWave is deeply integrated into open-source simulation flows, forming a natural complement to tools such as Verilator [38], Icarus Verilog [98], GHDL [78], and SymbiYosys [102]. Because it accepts standard waveform formats, it is frequently used to inspect counterexamples generated by formal verification tools and to validate complex testbench interactions in Python-based verification environments like cocotb [99]. Its lightweight implementation, cross-platform support, and ease of use make GTKWave an indispensable tool for students, researchers, and professionals engaged in RTL debugging, regression analysis, and validation of digital designs.

6. Physical Design Flow Tools

The landscape of open-source EDA tools has evolved rapidly, driven by the increasing demand for accessible and transparent chip design methodologies. A wide range of open-source projects now support various stages of the ASIC development flow, including logic synthesis, simulation, verification, placement, routing, timing analysis, and physical verification, opening the door for universities, research groups, and independent designers to experiment with real silicon design flows.

Despite this growth, open-source EDA tools vary considerably in purpose, maturity, and integration. Some tools are highly specialized, addressing only isolated tasks such as layout viewing, DRC checking, or analog constraint processing. Others focus on research-oriented capabilities or require significant manual intervention to complete a design. To maintain coherence and emphasize practical usability, this article narrows its scope to the subset of open-source EDA tools capable of executing an automated RTL-to-GDSII flow. This includes tools and frameworks that integrate logic synthesis, floorplanning, placement, clock-tree synthesis, routing, signoff checks, and GDSII generation within a unified flow, as summarized in Table 5.

Table 5. Comparison of Open-Source Physical Design Flow Tools.

Tool	Integration	Fabricable Technologies	Limitations
OpenROAD [91]	Core backend engine used by OpenLane and SiliconCompiler	SKY130, GF180MCU, HPSG13G2 (early), ICsprout55 (early)	Backend only; requires orchestration for full flows
OpenLane [88]	Wrapper over OpenROAD, Yosys, Magic, KLayout, Netgen	SKY130, GF180MCU, ICsprout55 (early)	Limited analog support; heavy reliance on sub-tools
iEDA [121]	Standalone modular environment for algorithm development	SKY130, GF180MCU, ICsprout55, research nodes	Less mature; smaller user base; evolving documentation
SiliconComp. [122]	Integrates OpenROAD, Yosys, KLayout, Magic, Verilator	SKY130, GF180MCU	PDK/tool integrations still evolving

6.1. OpenROAD

OpenROAD is an open-source physical design toolchain that enables automated digital ASIC implementation from synthesized RTL down to a manufacturable GDSII layout. Developed under the goal of achieving a “no-human-in-the-loop, 24-h” design flow, OpenROAD integrates multiple backend engines within a unified, open framework. Unlike monolithic proprietary tools, OpenROAD is composed of modular components that operate on a shared in-memory database (OpenDB), allowing placement, routing, timing analysis, and optimization to interact seamlessly throughout the flow [91,123].

The design process in OpenROAD begins with standard Verilog input, Library Exchange Format (LEF)/Design Exchange Format (DEF) technology files, Liberty timing models, and SDC constraints. After synthesis (typically performed by Yosys), OpenROAD initiates the backend flow starting with floorplanning and macro placement. High-level modules such as RePlAce perform global placement using analytical optimization, while OpenDB handles detailed placement and legalization. Clock Tree Synthesis (CTS) is carried out by dedicated engines to generate a balanced and low-skew distribution network across the design.

Following placement and CTS, the tool performs routing through a combination of global and detailed routing engines. FastRoute manages global routing, while TritonRoute produces the final detailed routing that adheres to design rules and minimizes congestion. Once routing is complete, OpenROAD integrates with OpenSTA for static timing analysis and uses parasitic extraction to validate timing closure. The tool also supports automated engineering change orders to resolve timing violations and improve quality of results. At the end of the flow, the design can be exported to DEF or GDSII for manufacturing. The main stages of this backend flow are illustrated in Figure 2.

Figure 2. Main stages of the OpenROAD-flow-scripts, illustrating the automated digital backend flow from synthesis to GDSII. The workflow includes floorplanning, placement, clock-tree synthesis, routing, timing analysis, and final layout generation [91,123].

OpenROAD implements an automated RTL-to-GDSII backend flow by integrating a collection of open-source engines that operate on standard design inputs such as Verilog, Liberty, LEF/DEF, and SDC files. As described in the article, the flow begins with logic synthesis, followed by floorplanning and Power Distribution Network (PDN) generation, which are handled by TritonFPlan through a combination of integer-programming-based macro placement and safe-by-construction PDN rules [124]. Global and detailed placement are then performed using RePlAce, respectively, enabling timing-driven and routability-aware optimization across macros and standard cells [100,124,125,126]. After placement, TritonCTS constructs a low-skew and power-efficient clock tree using generalized H-tree topologies, dynamic programming, and linear programming for sink clustering [127,128].

Following clock tree synthesis, OpenROAD transitions into the routing stages, beginning with global routing and followed by detailed routing using TritonRoute. TritonRoute refines global routing guides into DRC-clean metal and via geometries by solving a sequence of panel-based mixed-integer linear programming formulations that account for connectivity, wirelength, via minimization, and advanced design rules [127,128]. Once routing is complete, OpenROAD performs layout finishing, parasitic extraction, and static timing analysis through integrated engines such as OpenSTA [100]. These steps enable the flow to iteratively correct timing violations and generate a manufacturable GDSII database suitable for tapeout. As illustrated in Figure 2, OpenROAD’s cohesive integration of placement, clocking, routing, parasitic extraction, and timing analysis provides a unified and automated physical design solution aligned with the DARPA IDEA program’s vision of a 24-h, no-human-in-the-loop digital layout generator.

Through its ability to automate complex physical design tasks and integrate with other open-source tools such as Yosys, Magic, and KLayout, OpenROAD has emerged as a cornerstone of the open hardware ecosystem. It provides the computational infrastructure necessary for reproducible, scalable, and fully open ASIC implementation, enabling a new generation of designers to experiment with chip fabrication at unprecedented levels of accessibility.

An illustrative example of OpenROAD applied at system level is the physical implementation of a Linux-capable RISC-V system-on-chip presented in the Basilisk project [129]. In this work, OpenROAD is employed as the core place-and-route engine to transform a large-scale, industry-grade RISC-V SoC design from a synthesized netlist into a manufacturable layout using an open 130 nm CMOS technology. The authors integrate OpenROAD within a fully open-source flow based on Yosys and open PDKs, demonstrating that complex system-level designs—including a 64-bit RISC-V core, memory controllers, and multiple I/O peripherals—can be physically implemented without relying on proprietary EDA tools. This case study highlights OpenROAD’s capability to support end-to-end open silicon development while maintaining transparency and reproducibility across the entire design flow [129].

Beyond basic physical implementation, the article shows how OpenROAD was systematically optimized to improve the quality of results for the Basilisk SoC. By redesigning the power distribution network and carefully tuning global placement and routing parameters, the authors achieved convergence to zero design rule check violations while simultaneously increasing core utilization and reducing die area. These physical-design optimizations enabled the SoC to reach a peak operating frequency of 77 MHz, demonstrating that OpenROAD can effectively handle timing closure, routability, and scalability challenges in non-trivial RISC-V systems. The Basilisk implementation therefore serves as strong evidence of OpenROAD’s maturity as a practical physical design platform for open-source, system-scale integrated circuits.

6.2. OpenLane

OpenLane is designed as an automated, open-source RTL-to-GDSII flow that integrates a suite of open-source EDA tools around the OpenROAD project. As described in [88], OpenLane does not just invoke OpenROAD; rather, it provides additional automation scripts, configuration layers, design-space exploration mechanisms, and a unified flow environment tailored for producing tapeout-quality layouts on the SKY130 and GF180MCU PDK. The flow begins with logic synthesis using Yosys and ABC, where OpenLane applies multiple synthesis strategies—including area-driven, delay-driven, and retiming-focused approaches—and automatically selects the best result through design-space exploration. These synthesis steps generate a technology-mapped netlist that serves as the foundation for backend physical design operations.

Following synthesis, OpenLane performs floorplanning by defining die dimensions, core regions, placement rows, and routing tracks, while inserting PDN, well taps, endcaps, and decoupling capacitors. OpenLane also manages I/O and padframe construction through integration with utilities such as the Padring generator, enabling full-chip layouts. Once the initial floorplan is established, the backend physical design stages—placement, clock-tree synthesis, routing, timing optimization, parasitic extraction, and layout finishing—are executed entirely by the OpenROAD toolchain [91]. OpenROAD performs these steps autonomously using its internal engines for placement, CTS, routing, and timing analysis, while OpenLane orchestrates the sequence of operations, applies configuration parameters, and manages iterative optimization to achieve timing closure and design-rule correctness.

After OpenROAD completes the core backend stages, OpenLane proceeds to the verification and finishing stages. Magic is used for full-chip DRC validation, density checks, and dummy metal fill insertion, while Netgen performs LVS comparison between the extracted layout and the synthesized netlist. OpenLane also executes antenna checks and applies a hybrid diode-insertion strategy to mitigate antenna violations efficiently. Once the design is verified through DRC, LVS, and timing closure with post-route parasitics using OpenSTA, Magic streams out the final GDSII file suitable for fabrication. The main stages of this flow are illustrated in Figure 3.

Figure 3. Workflow of the OpenLane RTL-to-GDSII design flow. The figure illustrates the major stages of synthesis, floorplanning, power network generation, placement, clock-tree synthesis, routing, physical verification, and GDSII export. OpenLane orchestrates these tasks while delegating backend physical design operations to the OpenROAD toolchain [88].

OpenLane has become the most widely used open-source physical design flow due to its ability to abstract the complexity of the RTL-to-GDSII process into a unified configuration interface. By allowing designers to control the entire backend flow through a single configuration file, OpenLane drastically simplifies ASIC implementation and lowers the barrier to entry for students, researchers, and small design teams. Its popularity has further accelerated through the numerous MPW shuttle programs sponsored by Google, which have enabled the fabrication of hundreds of open-source chips using the SKY130 and GF180MCU technologies. These shuttle opportunities, combined with OpenLane’s reproducibility and automation, have established it as the de facto standard for open-source digital ASIC physical design [130].

Several recent works demonstrate the practical use of OpenLane as a complete RTL-to-GDSII flow for non-trivial digital systems, validating its applicability beyond toy designs. In [90], OpenLane is employed as the core physical-design framework to implement a custom embedded FPGA architecture using the SKY130 PDK. The study details how OpenLane integrates synthesis, floorplanning, placement, clock tree synthesis, routing, and sign-off to generate a manufacturable GDSII layout from RTL descriptions produced by OpenFPGA. By documenting configuration parameters, macro hardening strategies, and chip-level integration, this work serves as a clear example of how OpenLane can be used to achieve reproducible, fabricable results in complex, hierarchical designs using fully open-source tools.

Similarly, OpenLane has been used to validate system-level accelerator architectures at the physical-design stage. In [131], a hardware-accelerated edge-detection architecture based on a 2D-mesh Network-on-Chip and systolic arrays was first validated on FPGA and subsequently implemented as an ASIC proof-of-concept using the OpenLane flow targeting the SkyWater 130 nm PDK. The successful generation of a DRC- and LVS-clean GDSII layout demonstrates that OpenLane can support timing closure, power analysis, and manufacturability for domain-specific architectures combining computation and communication fabrics. Together, these works highlight OpenLane as a mature and versatile open-source platform capable of bridging the gap between RTL design and silicon-proven implementations.

6.3. iEDA

The iEDA platform provides a complete netlist-to-GDSII physical design flow, enabling block-level and SoC-level implementation through a unified, modular backend infrastructure. As described in [121,132], iEDA organizes its workflow into functional tool modules—each responsible for a major physical design task—and connects them through a common data model and unified software architecture. The overall execution begins once the synthesized netlist is provided. Because iEDA focuses specifically on physical implementation, RTL synthesis is delegated to external tools such as Yosys [37] and ABC [75], which are integrated into the Python-based iFlow wrapper. After synthesis, iEDA takes control of the entire backend flow, beginning with floorplanning and PDN definition.

During floorplanning, iEDA’s iFP tool initializes the layout, pre-places essential cells, assigns I/O pin locations, and automatically places macros based on structural netlist information. iFP then constructs the power distribution network, ensuring a valid and routable physical foundation. Next, the flow transitions to placement through iPL, which executes global placement, legalization, detailed placement, filler-cell insertion, and congestion-aware refinement. The placement engine aims to simultaneously reduce wirelength, improve timing, and maintain routability. Timing closure is further refined in the iTO module, which provides interfaces and algorithms to fix setup and hold violations, resolve design rule timing constraints, and iteratively improve overall performance through resizing and buffering operations.

Clock tree synthesis is performed by the iCTS module, which constructs balanced and timing-optimized clock-distribution structures. iCTS uses integrated timing models to compute delays, slews, and capacitances, and supports hierarchical clock tree construction using multiple merging strategies. Following CTS, routing is executed by iRT, a modular routing engine composed of a topology generator, planar router, track assigner, guide processor, and space router. iRT transforms the netlist connections into DRC-clean geometries across multiple metal layers while considering performance, congestion, and design rules. Once routing is completed, iEDA performs static timing analysis through iSTA, which supports CCS-based delay calculations, incremental analysis, crosstalk estimation, on-chip variation modeling, and parallelized processing of Liberty files. Power estimation is additionally supported through the iPA module, enabling both vectorless and vector-based analysis using SAIF/VCD.

The full backend flow is orchestrated through iFlow, a Python implementation that sequences the execution of all iEDA modules, integrates external synthesis and verification tools, and produces a final GDSII layout. As illustrated in Figure 4, iFlow coordinates the complete set of physical design stages, floorplanning, placement, CTS, routing, timing closure, and layout finishing, into a unified RTL-to-GDSII pipeline. iEDA reports that iFlow has been used to implement and tape out multiple RISC-V designs, ranging from 700 k to 1.5 M gates, on 110 nm and 28 nm process nodes, demonstrating the flow’s correctness and manufacturability [132]. Through its unified data model, modular architecture, and extensible solver framework, iEDA provides a research-oriented yet tapeout-capable backend flow that supports algorithm development and enables academic–industrial collaboration in open-source chip design.

Figure 4. Chip design process and the iEDA tools used at each stage. The diagram highlights how iEDA decomposes the physical design flow into modular engines, including iFP for floorplanning, iPL for placement, iCTS for clock tree synthesis, iRT for routing, iTO for timing optimization, iSTA for timing analysis, and iPA for power analysis. Together, these tools enable a fully integrated and extensible RTL-to-GDSII implementation environment [132].

6.4. SiliconCompiler

SiliconCompiler provides a higher-level build and orchestration system that stands apart from traditional, monolithic digital design flows. Rather than acting as a single physical design engine, SiliconCompiler serves as a flexible, open-source flow manager capable of coordinating multiple EDA tools across synthesis, verification, place-and-route, and signoff [122,133]. Its architecture allows designers to construct reusable and highly configurable flows that adapt to different methodologies, technologies, and toolchains. While many example flows rely on open-source backends such as OpenROAD, similar to the OpenLane ecosystem, SiliconCompiler distinguishes itself through its ability to seamlessly integrate both open-source and commercial EDA tools, including industry-standard solutions from Cadence and Synopsys. This flexibility makes it suitable for mixed environments where academic exploration intersects with professional-grade tooling.

Working primarily through Python and JavaScript Object Notation (JSON), SiliconCompiler adopts a modern, declarative configuration model. Users describe the design, constraints, PDK information, and tool sequence in a structured format, allowing SiliconCompiler to automatically construct dependency graphs, manage intermediate files, and coordinate tool execution. This compiler-like approach enables reproducibility, portability, and fine-grained customization of every step in the design flow. However, this configurability is a double-edged sword: while it offers exceptional control to experienced engineers and researchers, it can present a steep learning curve for students or newcomers who may not fully understand the intricacies of physical design. Unlike flows tightly coupled to specific PDKs or MPW programs, SiliconCompiler is more general and consequently exhibits less silicon validation compared to platforms like OpenLane, which have been exercised extensively through hundreds of fabrication runs.

Despite this, SiliconCompiler fills an important niche in the open-source EDA ecosystem. As a build system rather than a fixed sequence of tools, it enables the creation of custom flows tailored to unique research objectives, emerging PDKs, or hybrid toolchains. This flexibility is particularly valuable in environments where iterative experimentation, multi-tool integration, or industrial tool compatibility are required. In this sense, SiliconCompiler complements existing flows by providing a unifying automation framework capable of bridging open-source and proprietary methodologies, supporting both pedagogical and professional use cases.

7. Fabricable PDKs

Fabricable open-source PDKs represent a transformative milestone in the semiconductor ecosystem, as they eliminate long-standing barriers traditionally associated with integrated circuit design and manufacturing. Historically, accessing a PDK required strict non-disclosure agreements, institutional partnerships, and costly licensing arrangements, which restricted chip design to a limited number of well-funded organizations. By contrast, fabricable open-source PDKs provide complete and openly accessible documentation of design rules, device models, parasitic extraction guidelines, and verification decks. This openness enables designers to take a system from RTL to GDSII and ultimately to manufactured silicon without relying on proprietary toolchains or confidential process information. As summarized in Table 6, these PDKs differ in technology node, device options, openness level, and best-suited applications, yet all contribute to the democratization of ASIC development in a manner analogous to how open-source software transformed computing.

Table 6. Comparison of Selected Open and Academic-Accessible PDKs.

Feature	SKY130 [134]	GF180MCU [135]	IHP SG13G2 [136]	ICsprout55 [137]
Technology Node	130 nm CMOS	180 nm CMOS	130 nm SiGe BiCMOS	55 nm CMOS
Openness Level	Fully open-source	Fully open-source	Academic license	Limited open access
Primary Focus	Digital, mixed-signal	Mixed-signal, HV analog	RF/mmWave, mixed-signal	Digital SoC education
Key Devices	CMOS, HV MOS, MiM, resistors	CMOS, HV-LDMOS, MiM, resistors	SiGe HBTs, CMOS, MiM	CMOS, SRAM, basic analog
RF Capability	Low–moderate	Moderate (GHz range)	Very high (300+ GHz $f_{\mathrm{T}}$)	Limited
Standard Cell Support	Open-source libs (HD/HS/LP/MS)	Growing open-source libs	Limited digital libs	Basic digital libs
Best Use Cases	Education, SoCs, AMS IP	Sensors, MCUs, PMICs	Radar, RF, mmWave SoCs	Advanced-node education, ML/DSP
EDA Compatibility	OpenLane/OpenROAD	OpenLane/OpenROAD	Partial open flow; proprietary tools	Educational flows; limited openness
MPW Availability	chipfoundry OpenMPW	wafer.space OpenMPW	Europractice, IHP MPW	N/A

From an educational standpoint, fabricable open-source PDKs are essential for training the next generation of semiconductor engineers. Universities can now incorporate complete ASIC workflows into their curricula, allowing students to work with industrial-grade methodologies and realistic manufacturing constraints. These PDKs integrate seamlessly with open-source EDA flows such as OpenLane [88] and OpenROAD [91]. This level of transparency not only enables hands-on learning but also supports reproducible research and the development of new methodologies for digital, analog, and mixed-signal design. In an industry facing a global shortage of skilled engineers, the availability of such training tools has significant long-term impact.

Fabricable open-source PDKs also accelerate research across multiple domains, including machine-learning accelerators, RISC-V processors, sensor interfaces, low-power mixed-signal systems, power management circuits, and novel analog architectures. Researchers are able to prototype new ideas, share design flows, compare implementations, and fabricate test chips at low cost through Multi-Project Wafer (MPW) programs [138,139,140,141,142]. This level of openness and affordability was previously unattainable, as fabrication access was confined to large industry players or heavily funded research labs. The resulting acceleration of experimentation and iteration supports scientific discovery and strengthens the global semiconductor research community.

7.1. SKY130

The SKY130 process design kit is the first manufacturable open-source PDK, jointly released by Google and SkyWater Technology Foundry [143]. Originating from a mature 180–130 nm hybrid CMOS technology initially developed by Cypress Semiconductor, the process was later transferred to SkyWater and made publicly accessible through Google’s open-source initiative. This collaboration transformed SKY130 into a widely available platform that provides a complete set of open design rules, SPICE models, device libraries, and digital standard-cell libraries, removing the traditional barriers of Non-Disclosure Agreement (NDA)s, licensing restrictions, and proprietary toolchains [134]. As a result, SKY130 has become a cornerstone of the open-source silicon movement, enabling universities and research groups to design and manufacture ASICs.

At the device level, SKY130 offers a rich and versatile technology stack suitable for digital and mixed-signal applications. The process supports 1.8 V core devices with 5 V I/Os (operable at 2.5 V), includes one level of local interconnect, and provides five levels of metal, as illustrated in Figure 5. It is inductor-capable, includes high-sheet-resistance polysilicon resistors, offers optional metal–insulator–metal capacitors, and integrates shrunken-cell non-volatile memory. Additionally, the technology provides high-voltage extended-drain NMOS and PMOS devices supporting regulated supplies up to 10 V. These features collectively enable robust analog, power-management, and mixed-signal SoC implementations.

From a digital-design perspective, SKY130 includes multiple standard-cell libraries (HD, HS, LP, MS) that allow designers to navigate trade-offs among area efficiency, leakage power, and operating frequency. These libraries are fully compatible with open-source EDA flows such as OpenLane, OpenROAD, Magic, and KLayout, enabling an end-to-end RTL-to-GDSII workflow without reliance on commercial tools. The availability of Verilog simulation models, Liberty timing files, LEF/DEF physical abstracts, and complete physical verification decks (DRC, LVS, antenna) provides an industrial level of realism for education and research in digital VLSI.

Another critical strength of the SKY130 ecosystem is its rapidly expanding community-driven infrastructure, including reusable open-source IP blocks, automated flows, and MPW programs. In particular, the ChipFoundry OpenMPW initiative has enabled hundreds of academic, commercial, and hobbyist tape-outs worldwide, democratizing access to silicon and accelerating the development of digital, analog, and mixed-signal SoCs [144]. This robust ecosystem supports reproducibility, experimentation, and hands-on learning at a scale previously impossible outside large semiconductor companies.

Figure 5. Overview of the SKY130 PDK layers, including diffusion, polysilicon, interconnect metals, vias, and backend passivation. Detailed descriptions of each layer are available in the official SkyWater GDS Layers Information page [145].

Figure 5. Overview of the SKY130 PDK layers, including diffusion, polysilicon, interconnect metals, vias, and backend passivation. Detailed descriptions of each layer are available in the official SkyWater GDS Layers Information page [145].

7.2. GF180MCU

The gf180mcu PDK, released by GlobalFoundries in collaboration with Google, represents the second fully open-source PDK available to the public and targets a 180 nm mixed-signal CMOS technology with high-voltage capabilities. Unlike advanced digital nodes, GF180MCU is specifically optimized for embedded analog systems, power management ICs, sensor front ends, RF circuits operating up to several GHz, and microcontroller-class SoCs [135]. The PDK provides a rich device portfolio, including NMOS and PMOS transistors with multiple threshold-voltage options, high-voltage LDMOS devices supporting up to 40 V operation, precision resistors, MiM capacitors, and thick-metal routing layers suitable for high-current and low-resistance interconnects.

A key element of the technology is its backend-of-line stack, which offers configurations with five or six metal layers depending on the selected top-metal module. Figure 6 illustrates the cross-sectional structure of the 1P6M, showing the arrangement of the polysilicon gate layer, six metal interconnect levels (M1–M6), via transitions, dielectric materials, and the 11KA thick top-metal layer used for power routing. This configuration excludes the MiM capacitor module, making it well suited for power drivers, automotive interfaces, and high-reliability analog applications.

The digital-design ecosystem for GF180MCU continues to expand with the availability of open-source standard-cell libraries, complete DRC/LVS verification decks, and integration support for open-source EDA flows such as OpenLane and OpenROAD. Although the digital density is lower than in SKY130, the process offers significant advantages for mixed-signal systems requiring precise analog behavior, integrated Analog-to-Digital Converter (ADC)/Digital-to-Analog Converter (DAC) blocks, sensor readout circuits, and robust high-voltage I/O interfaces. The combination of a mature 180 nm platform, multiple metal layers, HV device options, and analog-friendly characteristics enables designs that are not easily achievable in more digitally oriented open-source technologies.

GlobalFoundries’ open release has already enabled the fabrication of advanced educational chips, sensor ASICs, microcontrollers, and research-driven mixed-signal architectures. In addition, access to the process has been further expanded through publicly available MPW programs offered by wafer.space [146], enabling cost-effective fabrication for universities, startups, and independent researchers. The open nature of the PDK—combined with the stability, manufacturability, and wide-voltage operation of a well-established 180 nm process—creates a uniquely accessible platform for analog-heavy SoC development. As a result, GF180MCU is rapidly becoming the preferred open-source PDK for projects demanding analog precision, high-voltage interfaces, and mixed-signal integration.

Figure 6. Cross-sectional representation of the GF180MCU 1P6M process stack using the TM 11KA thick top-metal option. The diagram illustrates the arrangement of the single polysilicon layer, six metal interconnect layers (M1–M6), via structures, dielectric materials, and final passivation [147].

Figure 6. Cross-sectional representation of the GF180MCU 1P6M process stack using the TM 11KA thick top-metal option. The diagram illustrates the arrangement of the single polysilicon layer, six metal interconnect layers (M1–M6), via structures, dielectric materials, and final passivation [147].

7.3. IHP SG13G2

The IHP SG13G2 PDK is a 130 nm SiGe BiCMOS technology developed by Leibniz Institute for High Performance Microelectronics (IHP), renowned for its exceptional RF and millimeter-wave performance. Unlike standard CMOS PDKs, SG13G2 integrates high-speed SiGe heterojunction bipolar transistors with CMOS logic on the same wafer, enabling designs that require both digital control and high-frequency analog/RF capabilities. The f_T and f_max of the SiGe HBTs can exceed 300 GHz, making this technology suitable for automotive radar (77 GHz), 5G mmWave front ends, phased-array transceivers, and high-speed wireline communication circuits [136,148]. The overall device stack and interconnect hierarchy used in SG13G2 are illustrated in Figure 7, highlighting the integration of SiGe HBTs with CMOS devices within the same process.

Figure 7. Cross-section of the IHP SG13G2 SiGe BiCMOS technology, showing the device-level integration of SiGe HBTs and CMOS transistors along with the corresponding backend metal layers, vias, dielectric stack, and passivation. This structure enables the high-frequency performance characteristic of the SG13G2 platform [136].

In addition to its RF capabilities, SG13G2 includes precision analog components such as poly resistors, MiM capacitors, and low-noise devices optimized for high-frequency linearity. The CMOS portion of the process supports embedded digital controllers, calibration logic, and DSP blocks needed for complex Radio Frequency (RF) systems. The combination of BiCMOS devices allows system-on-chip implementations that merge microwave front ends with baseband processing, reducing bill-of-materials cost and improving reliability.

IHP provides academic-accessible PDKs under controlled licensing agreements, often through Europractice or MPW programs [149]. These programs enable universities and research institutions to design and fabricate mmWave experimental chips with realistic performance targets. SG13G2 is widely used in academic research for phased-array systems, novel RF topologies, software-defined radio experimentation, and low-noise sensor interfaces, positioning it as one of the most advanced research-friendly RF PDKs available.

7.4. ICsprout55

The ICsprout55 PDK is an open-source 55 nm CMOS PDK developed by ICsprout Integrated Circuit Co., Ltd. (Hangzhou, China) in collaboration with the ECOS Team of the Institute of Computing Technology at the Chinese Academy of Sciences [137]. The PDK represents one of the most advanced technology nodes ever made publicly accessible under an open-source model, exceeding previous open releases such as SKY130 and GF180MCU in both integration density and performance potential. The initiative was formally introduced to the community at the Free Silicon Conference (FSiC) 2025, where it was highlighted as a major step toward democratizing semiconductor design at more modern nodes [150].

Unlike earlier open-source PDKs limited to mature analog-oriented technologies, ICsprout55 provides a comprehensive toolkit suited for higher-performance digital SoCs, low-power IoT designs, and mixed-signal subsystems. A key objective of the ICsprout55 initiative is to lower the barriers associated with proprietary 55 nm design ecosystems, providing universities, research laboratories, and open-source communities with a practical pathway to fabricate medium-complexity integrated circuits. The PDK aims to support a complete “design-to-tapeout” methodology without restrictive NDAs or licensing constraints.

The project is currently released as a preview version, with the first engineering MPW shuttle expected in December 2025. As noted by the developers, the PDK has not yet undergone full silicon validation or industrial reliability qualification, and therefore is not recommended for mass-production use at this stage. Its intended purpose is prototyping, academic research, and community-driven design exploration, especially in cases where open accessibility is prioritized over commercial certification.

Despite these early-stage limitations, ICsprout55 marks a significant milestone for the open-source silicon ecosystem. By providing a publicly accessible 55 nm technology, the initiative enables higher integration densities, reduced power consumption, and more modern circuit architectures than those achievable with existing open PDKs. The combination of an open PDK, open IP libraries, and compatibility with open-source toolchains positions ICsprout55 as a foundational platform for the next generation of open semiconductor innovation.

8. Conclusions

This article has presented a survey of the open-source ecosystem supporting the complete digital IC design flow, from RTL description to fabricable GDSII layouts. By systematically categorizing tools for code generation, synthesis, simulation and verification, physical design, and open-source PDKs, this study demonstrates that fully open and reproducible RTL-to-fabrication workflows are now technically feasible and increasingly mature. Frameworks such as Yosys, OpenROAD, and OpenLane, combined with fabricable PDKs like SKY130 and GF180MCU, have proven capable of supporting real silicon implementations, significantly lowering the economic and technical barriers traditionally associated with ASIC design.

The survey highlights how raising the level of abstraction—through high-level synthesis, Python-based HDLs, and emerging LLM-driven HDL generation—can substantially reduce development time and broaden accessibility to hardware design. At the same time, open-source simulation, verification, and timing-analysis tools provide robust mechanisms to ensure functional correctness and timing closure without reliance on proprietary software. Although limitations remain in areas such as advanced SystemVerilog support, aggressive timing-driven optimization, and mixed-signal integration, the rapid evolution of these tools and the strength of their communities indicate a clear trajectory toward increased capability and industrial relevance.