GDSFactory makes chip layout a Python script, and the PDK you activate decides what your code means

The core loop is a component, a reference and an x coordinate

GDSFactory is a Python library for designing chips, PCBs and 3D printable objects, and the quick start example is short enough to read in one pass.

import gdsfactory as gf

# Activate the built-in generic process design kit
gf.gpdk.PDK.activate()

# Create a new component
c = gf.Component()

# Add a rectangle
r = gf.components.rectangle(size=(10, 10), layer=(1, 0))
rect = c.add_ref(r)

# Add text elements
t1 = gf.components.text("Hello", size=10, layer=(2, 0))
t2 = gf.components.text("world", size=10, layer=(2, 0))

text1 = c.add_ref(t1)
text2 = c.add_ref(t2)

# Position elements
text1.xmin = rect.xmax + 5
text2.xmin = text1.xmax + 2
text2.rotate(30)

# Show the result
c.show()

The model is a hierarchy of components. A component is a cell, references place one component inside another, and positioning is done by assigning to the `xmin` attribute and letting the geometry resolve the rest. That is the whole idea, and it is what makes the layouts reviewable as code.

The first line is the one with the most leverage. `gf.gpdk.PDK.activate()` selects the generic process design kit, which is a stand-in with sensible defaults, and the layer numbers in the example are only meaningful relative to whichever PDK is active. Change the PDK and the same script means a different physical structure, because layer (1, 0) means something specific in that process.

The output formats are equally direct. You write Python or YAML, and you get GDSII, OASIS, STL or GERBER files for fabrication, plus component settings and netlists in YAML.

The PDK decides the physics, and some of them are gated

GDSFactory is useless without a process design kit, and the README is unusually clear about which PDKs are open and which are not.

The open list, described as requiring no NDA, covers photonics with the Cornerstone PDK, the SiEPIC Ebeam UBC PDK, the VTT PDK and the Luxtelligence GF PDK. It covers quantum with the Quantum RF PDK. And it covers RF, AMS, digital and analog with IHP, the GlobalFoundries 180nm MCU CMOS process and the SkyWater 130nm CMOS process. Each has a public repository and public documentation.

Foundry PDKs under NDA require a GDSFactory+ subscription, and the sign up page is at gdsfactory.com, with the list of available PDKs published there. The GDSFactory+ product is described as offering a graphical user interface for chip design built on top of GDSFactory and VSCode, providing foundry PDK access, schematic capture, device and circuit simulations, design verification with DRC and LVS, and data analytics.

That split is the commercial structure of the project and it deserves to be stated plainly rather than discovered later. The library is MIT licensed, so the code is free and permissively licensed, but the process data that makes a design manufacturable is the part under NDA, and access to it is a subscription.

The README headline figures cite 42+ PDKs overall, while the named open list is much shorter. For an engineer, the practical question is not whether GDSFactory supports your process but whether you can get the PDK for it, and the open list is the fastest way to answer that.

Cornerstone, the SiEPIC and IHP kits are the ones a new user is most likely to start with, because the photonics PDKs come with public documentation.

Design, verify and validate are one flow, and simulation reads the layout

The README describes an end-to-end flow in three stages, and the middle one is where GDSFactory differs most from a plain layout tool.

Design covers layout, simulation and optimization, where you define parametric cell functions in Python to generate components, test component settings, ports and geometry to avoid unwanted regressions, and capture design intent in a schematic.

Verify covers DRC, DFM and LVS, and the sentence that matters is that you can run simulations directly from the layout using the simulation interfaces, removing the need to redraw your components in simulation tools. That is a real reduction in work, because a redrawn component is a second source of truth that can drift from the layout. Conduct component and circuit simulations, study the design for manufacturability, and confirm that complex layouts match their design intent through Layout Versus Schematic verification and are DRC clean.

Validate covers defining layout and test protocols simultaneously for automated chip analysis after fabrication, extracting component parameters and building data pipelines from raw data to structured data so chip performance can be monitored.

The simulation integrations are listed by name: Ansys, Lumerical, Tidy3d, MEEP, DEVSIM, SAX, MEOW and SPICE. In the package metadata those arrive through the `full` extra, which pulls in `gplugins` with the devsim, femwell, meow, sax, schematic and tidy3d backends, along with scikit-rf. Installing the full set of simulation plugins is a heavier step than the base install, which is why the base dependency list is kept to geometry and plotting libraries.

The base dependencies describe the core accurately: numpy, scipy, shapely and rectpack for geometry, pandas for data, pydantic and pydantic-settings for parameter validation, jinja2 for templating, typer and rich for the command line, loguru for logging, matplotlib for plotting, and `kfactory[ipy]` at version 3.2.1 or newer as the core geometry kernel.

Regression testing is done by diffing generated geometry

The test setup is the part of this repository that tells you what kind of project it is, and it is unusual.

The Makefile has a `test-data` target that checks out a submodule named `test-data-gds` at its pinned commit, and a `test` target that runs pytest in parallel with `-n logical`. There is a `test-force` target that runs with `--force-regen` and, crucially, serially, and the comment in the Makefile explains why: so that GDS difftest can prompt before replacing a reference file. That names the mechanism. The test suite compares generated GDS output against reference files and prompts when a difference is found, so a change in the library that shifts a coordinate by a nanometre shows up as a diff to be reviewed rather than as a silently updated file.

The regression tools in the dev dependencies support the same approach: `pytest-regressions` for snapshot comparison, `pytest-xdist` and `pytest-randomly` for parallel and randomised ordering, `hypothesis` for property based testing, and `jsondiff` and `jsonschema` for structural comparison. The `benchmarks/` directory in the repository and the `bench` extra with an `asv.conf.json` at the root cover performance measurement, so speed changes are tracked rather than noticed.

There is also a dedicated target for the samples, `test-samples` running `tests/test_samples.py`, which checks that the example scripts still run without error. And `dev` sets up the development environment with `uv`, installs the pre-commit hooks, and runs `gf install-klayout-genericpdk` and `gf install-git-diff` to set up the layout viewer and a diff helper.

The `uv.lock` file and the `Makefile` bootstrapping `uv` itself when it is missing are the details of a project that expects its contributors to have a reproducible environment rather than a curated one.

Version 10, Python 3.12 to 3.14, and what the release candidate implies

The current version is 10.0.0rc0, a release candidate published on 2026-09-16, after v9.51.0 on 2026-09-14 and v9.50.0 on 2026-09-10. The last push to the repository was on 2026-10-15 and it is not archived.

Three releases in six days, with a major version bump in the middle, is the pattern of a project that has settled into a fast release train. A major version number in a library like this usually means breaking changes in the component or port model, and the release candidate is the point where the maintainers ask users to shake out incompatibilities before the final.

The Python floor is worth noting because it is tight. The package requires Python 3.12 or newer and below 3.15, and the classifiers list 3.12, 3.13 and 3.14. The development target is pinned in the Makefile, which creates the environment with `uv venv -p 3.12`, and the build backend is flit_core with a `>=3.2,<5` requirement.

The build and release plumbing is conventional and well organised. The Makefile has targets for publishing to devpi and to twine, building and running a Docker image, generating the docs, and running the notebooks. A `benchmarks/` directory, an `asv.conf.json` and the `bench` extra form a proper performance harness. There is a `CHANGELOG.md`, a `SECURITY.md`, a `.pre-commit-config.yaml` and a `.devcontainer/` for a reproducible Codespace, and the `full` extra is what a user installs to get the simulation plugins.

The licence is MIT, which is why a commercial foundry can build a business on top of the library while keeping the process data behind a subscription. The repository README reports 4 million or more downloads, more than 116 contributors and 42 or more PDKs, and the documentation site, the Binder sandbox, the Codespaces badge, the video tutorials and the online course on silicon photonics design at UBC all point to a project that has built a teaching path as well as a library.

Editorial conclusion

Adopt GDSFactory if you design photonics or analog chips in Python already, if you want version control over your layouts, and if you can work with a PDK that is either open or covered by a subscription. Do not adopt it as a way to avoid a foundry PDK, because the open PDK list is limited to specific processes and everything under NDA sits behind a GDSFactory+ subscription. Verify first that the process you need has a PDK you can actually obtain, that your simulation tool has an interface in the gplugins set, and that the Python version you run matches the 3.12 to 3.14 range the package declares.

Frequently asked questions

Official sources

1. gdsfactory/gdsfactory on GitHub
2. License: MIT
3. Project website
4. README
5. Releases