iEDA and the open source EDA stack from netlist to GDS

Two things in one repository: tools and an SDK

iEDA is described as an open source EDA infrastructure and tools from netlist to GDS for ASIC design, and the project overview splits the work into two levels. Level 1 is open-source EDA, RTL and PDK supporting chip design. Level 2 is open-source infrastructure that supports EDA development and research. The headline figure given is 1 EDA infrastructure, 11 EDA tools and 4 times tape-out design by iEDA.

That framing is the key to understanding the project, and it distinguishes iEDA from a collection of standalone utilities. The infrastructure layer exists so that tools can be written against a common set of abstractions rather than each one reimplementing file handling, database access and process management. The README names the four components: Database, Manager, Operator and Interface, and describes the reason for the whole thing as needing a software development kit to fast develop high-quality EDA tools.

So there are two audiences. One is a chip designer who wants to take an RTL netlist through to GDS using the tools. The other is an EDA researcher or tool developer who wants the infrastructure as a starting point for a new algorithm or a new tool. The project is explicit that iEDA can be used to support developing EDA tool or algorithm.

The tape-out record is what separates the project from a paper exercise. Four tape-outs is a claim about silicon rather than about screenshots, and the papers list backs it up: iRT on net resource allocation at DAC 2024, iCTS on controllable hierarchical clock tree synthesis at DAC 2024, AiEDA on an open-source AI-native EDA library at ISEDA 2024, iEDA itself as an invited open source infrastructure paper at ASPDAC 2024, iPD as an open-source intelligent physical design tool chain at ASPDAC 2024, AiMap on learning to improve technology mapping at ICCD 2023, iPL-3D on a bilevel programming model for die-to-die placement at ICCAD 2023, and an open source intelligent physical implementation toolkit at ISEDA 2023.

The project is hosted under the OSCC-Project organisation, with a homepage at ieda.oscc.cc, and the licence is Mulan PSL2 according to the badge in the header, which the repository metadata classifies as a custom licence GitHub cannot classify. The primary language is C++, and the last push was on 2026-07-09.

The build: a mirror container or a fetched dependency set

The user guide says that before designing a chip with iEDA you need to obtain the execution binary of iEDA, and that if you need to modify iEDA through source code construction you should read the linked user guide. It also notes that you can use the latest release Docker and skip the source construction step entirely.

Two source construction methods are given, and the first is the recommended one.

Method 1 uses a mirror image from Dockerhub, iedaopensource/base, which includes the latest master branch code and the dependencies, both build tools and dependency libraries. The build only uses the compile tools and dependency libraries provided by the mirror. The commands are:

# ieda opensource/base:(latest, ubuntu, debian)
docker run -it --rm iedaopensource/base:latest bash 
# enter docker and run build.sh to build
bash build.sh
# if output "Hello iEDA!", then compile successfully
./bin/iEDA -script scripts/hello.tcl

The Hello iEDA! output is the smoke test. If the script runs and prints that, the compile succeeded, and you have a working binary at ./bin/iEDA. The image tags cover ubuntu and debian, and the readme names Ubuntu 20.04 and Debian 11 specifically.

Method 2 is the from-scratch route on Ubuntu 20.04, and it fetches the source from a Gitee mirror rather than GitHub:

# download iEDA repo
git clone --recursive https://gitee.com/oscc-project/iEDA.git iEDA && cd iEDA
# compile dependencies with an apt installation requires root permission
sudo bash build.sh -i apt
# comple iEDA
bash build.sh
# if output "Hello iEDA!", then compile successfully
./bin/iEDA -script scripts/hello.tcl

The --recursive flag matters, because the repository carries .gitmodules and the dependencies are submodules. The build.sh script takes flags: -i selects the dependency installation method, apt here, and the Dockerfile uses -i mirror, so the dependency set is fetched from a mirror service rather than from apt, which is how the container build avoids depending on the network state of a package repository.

The practical difference between the two methods is where the dependencies come from, and that is the thing to decide before you start. Method 1 gives you a fixed environment that the project maintains. Method 2 gives you a local build on your own machine, with apt as the source of system packages.

Running a design: the release container and the sky130 example

Once you have a binary, the readme gives two ways to run a design.

Method 1 is the release or demo mirror, also the recommended one. If you need to use custom processes and designs, you mount the associated files into the Docker container to run:

docker run -it -v ${file directory of pdk and design}:${file directory in docker} --rm iedaopensource/release:latest

The mount is the whole interface. The host directory holding the PDK and the design appears at the same path inside the container, and the release image already has the toolchain set up, so there is nothing else to configure.

Method 2 is running a binary you compiled yourself. The file directory in scripts/sky130 is the reference, and asks you to add the path of the iEDA execution binary into the system path variable $PATH, then run sh run_iEDA.sh and see the result in result. The directory listing is the map of the whole flow:

iEDA/scripts/sky130
├── iEDA_config   # iEDA parameters configuration files
├── lef           # lef files
├── lib           # lib files
├── result        # iEDA result output files
├── script        # Tcl script files
├── sdc           # sdc files
├── run_iEDA.py   # Python3 script for running iEDA
└── run_iEDA.sh   # POSIX shell script for running iEDA

Every directory in that listing is a standard physical design flow input or output. The lef and lib files are the layout and library views of the process, the sdc files are the timing constraints, the script directory holds the Tcl that drives the tool, and result holds the output. The two runner scripts at the bottom, one Python and one POSIX shell, exist because the flow is scripted rather than interactive, and having a shell entry point means the run can be dropped into a CI pipeline without Python on the path.

For how to drive the tools themselves, the Tcl command manual is the reference and to the readme.md in src/operation, and for the design structure and configuration files to the demo in scripts/sky130.

The repository layout and the Tcl scripting model

The top-level entries describe a project that is more than a set of tools.

There is src/ for the tool and infrastructure code, cmake/ for the build configuration, a CMakeLists.txt at the root, build.sh as the entry point for the whole build, a Dockerfile, scripts/ for the example flows including sky130, and docs/ for the documentation and the images the readme embeds. There is a .clang-format file at the root, which tells you the code style is enforced, and a .gitee/ directory rather than a .github/ one, matching the Gitee-hosted development flow the clone command uses. There are also a README-CN.md alongside the English README, and the readme itself has a language switch at the top.

The most important structural fact is the Tcl scripting model, and it is visible in the commands rather than stated in prose. The binary is invoked as iEDA -script scripts/hello.tcl, and the hello.tcl file is the smoke test that prints Hello iEDA!. Every operation in the project is driven by a Tcl script rather than by a command line of tool switches.

That is a deliberate design and it has a clear consequence for anyone planning to use iEDA. The binary is a Tcl interpreter with EDA commands loaded into it, and a design run is a Tcl program. The scripts/sky130 example is therefore a real, readable flow you can copy and modify: the lef, lib, sdc and script directories are what a design run actually consumes, and the result directory is what it produces.

For a team writing their own flow, the readme directs you to the Tcl command manual and to the tool instruction docs in src/operation. For a team building a new tool, the infrastructure layer, with its Database, Manager, Operator and Interface components, is the part the SDK exists to provide, and the papers are the better description of what that layer buys you.

The Docker image follows the same model. Its CMD runs iEDA -script scripts/hello.tcl, so the container's default action is the smoke test, and the release image you mount a design into behaves the same way.

What the project is not, and the boundaries of the offer

Two boundaries are worth stating plainly.

The first is that this is an ASIC flow, not an FPGA flow. The readme says netlist to GDS for ASIC design, and the demo is sky130, an open source process, with a PDK mounted alongside the design. A team looking for an open source FPGA toolchain is looking in the wrong place, and the 11 tools are all part of the same ASIC physical design and implementation flow rather than a general synthesis and place-and-route suite.

The second is the licensing. The badge says Mulan PSL2, which is a Chinese open source licence modelled on Apache 2.0 with an explicit patent grant and a reciprocity requirement, and the repository metadata classifies the licence as one GitHub cannot classify with a pointer to the LICENSE file. For a company shipping a chip, the patent and reciprocity terms are the parts to read carefully before you build on it, and the licence file rather than the badge is what you should read.

There is also a build dependency worth planning around. Method 2 of the source build fetches dependencies over the network, and the container route depends on a maintained image being available for your platform. Neither is unusual for an EDA project, but both mean the build is not something you can run in an air-gapped environment without a local dependency set.

The project version badge reads 1.0.0, the node version badge asks for 23.12.01 or newer, and the last push was on 2026-07-09. There are no GitHub releases. A news page and a papers page are linked, and the project says contributions go through a fork and a pull request on Gitee, following the coding style document.

Editorial conclusion

iEDA is a good fit for a team doing ASIC design research or building new EDA tooling on top of an existing infrastructure, because the Database, Manager, Operator and Interface layers are there to be reused, and the project has a real tape-out record rather than only demos. It is a poor fit if you want a drop-in production flow, since the build depends on fetching a dependency set from the network or using a maintained container image, and the version line has moved only to 1.0.0 with the last push on 2026-07-09. Before adopting, read the iEDA user guide linked from the README and try the hello.tcl script in the container first, because the binary is a Tcl interpreter and the scripts directory, not the C++ source, is where you will spend your time.

Frequently asked questions

Official sources

1. Issues
2. OSCC-Project/iEDA on GitHub
3. README