EDA-Q tries to cover the whole quantum chip design flow, and the PDK layer is where it gets serious

A design tool that claims the whole flow, not one stage

EDA-Q is described as an advanced automated design tool for quantum chips, aimed at providing comprehensive support for the full design process, integrating quantum chip topology design, equivalent circuit computation, GDS layout and routing, and simulation.

The claim is significant, because the background section argues that existing quantum chip design tools tend to cover only part of the flow and lack automation, which becomes painful at the scale of large chips where the physical constraints, engineering limits and layout optimisation interact. The project's answer is an integrated platform where topology design leads to circuit computation, then to layout and routing, then to simulation and verification.

Architecture coverage is broader than the title suggests. The introduction says there is simultaneous support for superconducting, ion trap and photonic chip design, and it points readers to the READMEs of the ion_trap_chip and photonic_quantum_chip directories for those methods. That phrasing is a warning as much as a feature: the superconducting path is the integrated one, and the other two are separate subprojects you read separately.

The stated audience is researchers and engineers designing, simulating and optimising qubit chips. The licence is Apache-2.0, which matters for a tool that sits in the middle of a hardware design flow, since it lets a foundry or a research group embed it in their own pipeline without a licensing negotiation.

The primary language is listed as Jupyter Notebook, which tells you how the project is actually used: as a set of executable notebooks and helper modules that a researcher drives interactively rather than as a packaged library with a stable API.

Installation is a conda environment built from environment.yml

The installation is unusually well specified, and the reason is that the tool depends on a heavy scientific stack that is painful to reproduce by hand.

The project ships an installation free version in Releases that lets you run the UI launcher without any environment configuration. That is the fast path for looking at the tool. The documented code path is the environment route.

The method is to use a pre-configured environment.yml file that includes all the necessary dependencies and environment settings, so that you create a Python environment matching the development setup. The procedure has five steps.

Install Anaconda or Miniconda first, from the official sites. Then clone the repository locally:

   git clone https://github.com/Tianyan-QEDA/EDA-Q.git
   cd <EDA-Q Project directory>

Note the URL in that command. It points at Tianyan-QEDA/EDA-Q, while the repository this overview describes is hosted under Q-transmon-xmon. That is either a mirror arrangement or a stale instruction, and it is the first thing to verify before you clone anything, because cloning the wrong tree gives you a different project.

Create the environment from the file:

   conda env create -f environment.yml

Activate it:

   conda activate qeda_env

And then verify the installation, which is the step worth copying exactly, because it checks that the package imports:

   python -c "import api"

The repository also contains environment_linux.yaml alongside environment.yml, which suggests the environment definition is not identical across platforms, another reason to expect some setup friction on a machine that is not the one the maintainers use.

The PDK layer is the part built for real foundries

The most recent and most concrete piece of the project is the PDK framework, and it is the part that tells you what EDA-Q is actually for.

The repository includes a reusable PDK framework under ./pdk covering foundry process packaging, versioning and EDA-Q integration. There is a full guide at ./pdk/README.md, a packaged example under ./pdk/foundries/sc_flipchip/line1/1.0.0, and a recommended runtime for this workspace of pyoccenv.

That naming scheme is the interesting part. A process design kit for a flip chip superconducting process is packaged by foundry, by line, and by version, with a concrete example at 1.0.0. Versioning is therefore handled at the PDK level, not just at the tool level, which is the arrangement you want if a foundry revises a process and you need to know which version a given layout was drawn against.

Two example commands are given for this workspace:

conda run -n pyoccenv python pdk/tools/convert_line1_process_json.py
conda run -n pyoccenv python -m compileall api/design.py api/pdk.py pdk/core/*.py

The first converts the line 1 process definition, and the second byte compiles the design API, the PDK API and the PDK core modules. That second command is a hint about the architecture: api/design.py and api/pdk.py are the integration points between the design tools and the packaged process, and pdk/core/ holds the reusable machinery.

The pyoccenv runtime choice points at the geometry stack underneath, which is where GDS layout and routing work actually happens. For a user this is the difference between a drawing tool and a tool that can talk to a foundry process package.

The repository is a map of the design flow, not a library

The top level directory listing is the best description of the project available, and it reads like a table of contents for the whole design pipeline.

There is a 0_demo/ directory, which usually means runnable examples. GUI/ holds the interface, and the project overview includes a screenshot of an AI assistant panel, with two related directories, edaq-assistant-mvp/ and edaq-knowledge-assistant-mvp/, whose names suggest an assistant MVP and a knowledge assistant MVP, both still experimental by naming convention.

The engineering directories follow the flow. api/ is the integration surface, base/ holds shared code, components/ holds reusable parts, cmpnt_frame/ appears to be a component frame, library/ is a component library, and toolbox.py sits at the root as a helper. equ_circ/ and equ_circ_files/ hold the equivalent circuit computation, qasm_files/ and qasm_relevant_files/ hold QASM related inputs, routing/ holds routing, renderer/ holds rendering, gds_analysis/ and gdsocc/ hold GDS analysis and GDS output, simulation/ holds simulation, and sub_tag/ holds sub tagging.

Two directories sit alongside: ion_trap_chip/ and photonic_quantum_chip/, which matches the introduction's pointer to their own READMEs, confirming that those architectures are developed separately from the superconducting core. excel/ suggests spreadsheet exchange, Innovation_Archive/ suggests archived experiments, and picture/, svg/ and test/ hold assets and tests. tutorial.md is the guide, and there is a separate COPYRIGHT.md alongside the License file.

For a reader, the honest summary is that this is a working research platform with several half-finished corners, not a polished product with one entry point. The value is that the pieces that exist are connected.

Releases give you a launcher, notebooks give you the tool

There are two distinct ways to use EDA-Q, and the project is clear that they serve different needs.

The installation free version in Releases runs the UI launcher with no environment configuration. That path exists because the hardest part of running a scientific tool is often the environment, and for evaluating the interface or demoing the flow it is the obvious entry point. For anyone who needs to use code for their quantum chip design, the documentation points to the conda procedure instead.

The Releases page also has a meaningful version history: v3.1.0 from 2026-04-02, v3.0.0 from 2026-01-31 and v2.0.0 from 2025-12-01. So the project has already moved through two major version boundaries since December 2025, and the project overview is titled EDA-Q v3.0.0, which means the documentation header lags the newest tag.

The AI assistant is worth a note because it is presented as a first class part of the GUI rather than an afterthought, with its own screenshot and its own MVP directories. The overview does not describe what the assistant does, whether it calls a model API, or what data it can see, so anyone evaluating it should read the code in those directories rather than assume.

The contribution model is informal by design: the guide says to submit a pull request and that it will be reviewed. The contributors section lists many individual accounts and then institutional entries, including the Institute of Physics at the Chinese Academy of Sciences, CIQTEK, the Shenzhen International Quantum Institute, Zhejiang University, the National Supercomputing Center in Zhengzhou, Nanjing University, Zhengzhou University, Origin Quantum, and the China Academy of Electronics and Information Technology. That list explains the shape of the tool, which is a research platform built by a group rather than a product.

Apache-2.0 terms, a recent push and a codebase still in motion

The licence is Apache-2.0, which is a good fit for a tool in a hardware design flow: it is permissive, it includes an explicit patent grant, and it does not force a foundry or a chip company to open source the layouts they draw with it.

The repository is not archived and the last push was on 2026-09-20, about a month before the newest tag of v3.1.0 from 2026-04-02. That gap says the code is moving faster than the tagged releases, so if you depend on a specific release, pin the tag rather than tracking main.

Three gaps in the documentation are worth naming, since they are the practical friction points for an adopter.

First, the clone URL discrepancy already noted. Second, the split between the superconducting path and the ion trap and photonic subprojects, which means there is no single guide describing how to design a chip in each architecture. Third, the version drift between the overview header, the package tags and the PDK example version, which means the documentation and the code are not always describing the same release.

None of that is disqualifying for a research tool, and the Apache licence plus the packaged PDK structure are genuine strengths. But a team that needs a versioned, documented API with a support commitment should look elsewhere, and a team designing superconducting qubits with a foundry process in hand will get real value here.

The concrete next step for any of these readers is to create the environment, run the import api check, and open ./pdk/README.md against the packaged sc_flipchip example, which is where the project's current centre of gravity is.

Editorial conclusion

Use EDA-Q if you are designing superconducting qubits and want topology, equivalent circuit computation, GDS layout and routing, and simulation in one place, especially if your foundry process already has a packaged PDK under pdk/foundries. Do not expect a polished, documented API from a Jupyter notebook centred repository, because the module boundaries are uneven and the ion trap and photonic flows live in separate subprojects with their own READMEs. Before committing, create the conda environment from environment.yml, verify it with the import api check, and read ./pdk/README.md together with the packaged sc_flipchip example, then confirm the clone URL you intend to use, since the documented clone command points at a different GitHub organisation than the repository itself.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Q-transmon-xmon/EDA-Q on GitHub
4. README
5. Releases