[oharboe]

Before: the flow wrote GDS with the KLayout application, and make drc/make lvs ran Ruby rule decks that need the application.
Now: KLayout's Python module, pip install klayout, writes the GDS and runs every DRC and LVS deck ORFS uses (DRC: asap7, nangate45, sky130hd, ihp-sg13g2; LVS: sky130hd, ihp-sg13g2), rewritten in Python; Ruby decks are deprecated, and the installer installs the module only, not the KLayout application.

This continues and reframes the earlier version of this pull request, which dropped the KLayout application from the installer and wrote that DRC/LVS needed the application down as a permanent state. That gap is closed here instead: DRC and LVS run on the Python module, so the application is needed only for a deprecated Ruby deck, and whoever uses one installs it. (#4797, which removed the application install on its own, is folded in as the last commit.)

DRC and LVS decks in Python

KLayout ships no Ruby in the Python module (KLayout/klayout#1772); its DRC language is a thin layer over klayout.db's Region, Edges and EdgePairs (KLayout/klayout#1980). flow/util/klayout_drc.py is that layer for the operations ORFS's decks use, with the DRC language's arguments and defaults (_drc_layer.rb), and flow/util/klayout_lvs.py adds what the LVS language adds (_lvs_netter.rb). Each deck is the Ruby deck translated line by line, one platform per commit, and the Ruby deck is deleted in the same commit. make drc/make lvs run a deck ending in .py with PYTHON_EXE. Outputs keep their names: 6_drc.lyrdb, 6_drc_count.rpt, 6_lvs.lvsdb.

Each Python deck is checked, on the klayout module at 0.30.12 (the version the lock pins) and at 0.30.13 with identical results, against the Ruby deck run by the KLayout 0.30.0 application on the same GDS from ORFS's gcd on that platform, clean, and with shapes added outside the design that break a sample of rules. DRC: violations per category and the markers themselves; LVS: the match verdict and the cross-reference counts in the .lvsdb.

platform	deck	clean GDS, Ruby / Python	seeded GDS, Ruby / Python	seeded rules	runtime, Ruby / Python
asap7	DRC	42 / 42 in 9 categories, same markers	64 / 64 in 17 categories, same markers	width, spacing, via enclosure, gate width (universal drc), select	73 s / 55 s
nangate45	DRC, with antenna	0 / 0	8 / 8 in 8 categories, same markers	width, spacing, via enclosure, poly, metal1 antenna	27 s / 2.6 s
sky130hd	DRC	0 / 0	6 / 6 in 6 categories, same markers; FEOL rules on in both: 6 / 6	width, spacing, via without metal	4.2 s / 2.7 s
sky130hd	LVS	match / match; 496 devices, 1119 nets, 451 subcircuits matched in both	short (a met1 bar across the core): no match / no match; 10 nets and 28 subcircuits mismatched in both	connectivity	2.6 s / 0.8 s
ihp-sg13g2	DRC (sg13g2_minimal), with density	8 / 8 in 8 categories (global and 800 x 800 um density), same markers	24 / 24 in 20 categories, same markers	width, spacing with a corner touch, via and contact size, pin outside metal, density	4.3 s / 2.6 s
ihp-sg13g2	LVS	match / match; 36 circuits, 232 devices, 837 nets, 239 pins, 1764 subcircuits matched in both	short (a Metal3 bar between req_msg[12] and req_msg[9]): no match / no match; the same 2 nets and 1 subcircuit mismatched, the merged net named req_msg[12],req_msg[9]	connectivity, devices	7.3 s / 3.9 s

Also in these commits:

• nangate45 no longer sets KLAYOUT_LVS_FILE: it named lvs/FreePDK45.lylvs, which does not exist, so make lvs now says LVS is not supported instead of failing on a missing file.
• RBA::CellView::active, which only the application has, is gone with the Ruby decks: the asap7 and sky130hd DRC decks used it when no report file was given, the sky130hd LVS deck to place its extracted netlist (the .lvsdb holds that netlist), the ihp deck for its file dialog.
• In the sky130hd DRC deck, if backend_flow = CU assigns rather than compares, so its copper-only rules never ran; the Python deck keeps that (CU = False).
• The sky130hd LVS .lvsdb from Python lists the same device abstracts as the Ruby one, in a different order.
• ihp-sg13g2's Ruby LVS deck never ran in ORFS: KLAYOUT_LVS_FILE was commented out and named a file that does not exist, the deck read -rd input=/schematic=/topcell=/report= where make lvs passes in_gds=/cdl_file=/top_cell=/report_file=, and run by hand it said "no match" on gcd because the CDL from cdl.tcl leaves out the decap cells, which have transistors (1231 instances). The Python deck takes make lvs's arguments, cdl.tcl now writes the CDL with write_cdl -include_fillers, and ihp-sg13g2 sets KLAYOUT_LVS_FILE. With that CDL both decks match; sky130hd LVS still matches. The -include_fillers change reaches every platform's CDL.
• The ihp-sg13g2 Ruby LVS runset is deleted with its replacement: sg13g2.lvs, the 39 rule_decks/*.lvs files and run_lvs.py, which only drove it. IHP's vendoring script (sg13g2_update.py) never fetched them.
• flow/test/test_klayout_drc.py checks width, space, enclosure, a universal drc check, area filters and deep against flat reporting on a generated layout; it is skipped without the klayout module.

Ruby decks: deprecated

A .lydrc/.lylvs deck, on a platform outside this repository for one, still runs through the KLayout application, and make drc/make lvs warn:

WARNING: <deck> is a Ruby KLayout deck; Ruby decks are deprecated and need a KLayout application you install yourself, see docs/user/KLayoutPythonDecks.md

There is no schedule for removing Ruby support; that is up to the maintainers. docs/user/KLayoutPythonDecks.md says how to convert a deck, with ORFS's decks as worked examples. flow/util/klayout_compare_decks.py runs a Ruby deck and its translation on one GDS file and compares the violations per category, count and markers, as ORFS's decks were checked; on asap7 gcd it reports the Ruby and Python decks the same.

GDS via the Python module

def2stream.py merges the GDS file with the module, run by PYTHON_EXE; it already used only klayout.db calls, and gets a command line. The module is a prebuilt wheel, with no Qt and nothing to compile, for Python 3.10 and up on Linux (x86_64 and aarch64, glibc 2.27 and up) and macOS, added to etc/requirements-common.in and pinned at 0.30.12 in the lock, the version the installer installs. Without the module the merge stops, exit status 1, no file written:

ERROR: the klayout Python module is not installed, pip install klayout (etc/requirements-common_lock.txt)

sky130hd lb_32x128, make do-gds	KLayout Python module 0.30.12	KLayout application 0.30.0
layout	identical (LayoutDiff, 12 cells)	identical
bytes that differ	26, the GDS timestamps
wall time, peak memory (one run)	0.34 s, 101 MB	1.36 s, 403 MB

Installer: no KLayout application

etc/DependencyInstaller.sh loses its KLayout install for every OS; the module comes in with the other Python packages. Deleted:

• klayoutVersion and the version-check-and-reinstall logic, written three times (CentOS 7, CentOS 8, Rocky Linux 9) around klayout.org RPMs.
• On Ubuntu x86_64: the klayout.org .deb download, its md5 table per release, and the "Unsupported Ubuntu version" exit, so KLayout's packaging no longer limits which Ubuntu releases the installer supports.
• On Ubuntu aarch64: the build of KLayout from source, with its Qt, Ruby and libgit2 build dependencies, the slowest step of a fresh aarch64 install.
• klayout from apt on rodete, and the Homebrew cask on macOS.
• env.sh: the KLayout.app PATH entry on macOS.
• flow/scripts/variables.mk: the lookup of a KLayout in tools/install/klayout, which nothing installs. KLAYOUT_CMD is the klayout on PATH unless set, looked up once (command -v klayout runs 21 times for make -n clean_all on asap7/gcd, as on master).
• docs/user/BuildWithPrebuilt.md: the KLayout version note and the LD_LIBRARY_PATH line for a KLayout built from source.

A deprecated Ruby deck, the gallery and the viewers still need the KLayout application, installed by whoever uses them; without it they stop at check-klayout, as on master.

Dogs left lying

• flow/scripts/klayout/src and test (14 Ruby files): a bring-up tool that generates KLayout tech and layer files from a Cadence Virtuoso tech file. Nothing in the repository runs or references it; it is left as it is.
• ihp-sg13g2's full DRC deck, sg13g2_maximal.lydrc, which no flow uses, is deleted rather than converted: ORFS runs sg13g2_minimal, and converting IHP's full deck is IHP's to do in its own repository.

Commits

1. flow: write the GDS file with the klayout Python module
2. to 7. One deck per platform: asap7 DRC, nangate45 DRC, sky130hd DRC, sky130hd LVS, ihp-sg13g2 DRC, ihp-sg13g2 LVS.
3. ihp-sg13g2: delete the unused Ruby DRC deck sg13g2_maximal.lydrc
4. flow: deprecate Ruby KLayout decks
5. installer: no KLayout application

Tests

• flow/test/test_def2stream.py checks that the module gets the arguments, and that without it the merge exits with status 1, prints the error and writes no file. flow/test/test_klayout_sh.py checks that klayout.sh stops without the KLayout application and passes a call through unchanged with it. Both pass (25 tests).
• The deck equivalence table above; klayout_compare_decks.py on asap7 gcd: same.
• make -n shows the deprecation warning for a .lydrc deck and none for a .py deck.
• black 26.10.1 (the CI version) clean on every commit.
• Not run: the wrapped-macro merge (WRAP_LEFS), which only gf12 designs use. It calls the same script with the same arguments as before.

🤖 Generated with Claude Code

https://claude.ai/code/session_018PFLaCzFtFbnWE4nPTDwpC

[gemini-code-assist]

Code Review

This pull request refactors the flow to make KLayout an optional dependency by utilizing the klayout Python module for GDS/OAS stream generation, falling back to mocking (writing an empty file with a warning) when KLayout is entirely missing. It updates dependency installers, Makefiles, and documentation to reflect this change, and adds corresponding unit tests. The review feedback correctly identifies a critical issue in flow/util/def2stream.py where a subprocess version check could cause an unnecessary hard failure, and points out that the custom environment dictionary is not being forwarded to the spawned subprocesses.

[oharboe]

@maliberty @eder-matheus @vvbandeira TL;DR klayout has been a thorny dependency and it confuses users

This is intended to prune as much as possible from ORFS install scripts, etc. while giving each use-case the least chafing experience.

We try PyPi klayout first, then local and finally we write an empty .gds file and a warning.

The full klayout install is still needed for make lvs/drc and gallery, but I think those are out of the way for most users and PyPi klayout doesn't have ruby, so there's nothing for it, full klayout install is needed. This would be solved by documentation, this is an out of the way use-case you have to install klayout yourself.

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit 161cd23 · Jenkins build #17 · Baseline: build · View build on dashboard

62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.

[maliberty]

This is arguably a gap that should be fixed rather than a status we should enshrine. I like the simplification but not at the expense of having the possibility of DRC/LVS in the future.

[oharboe]

Reopened to close the gap rather than document it: the Ruby DRC/LVS decks get rewritten in Python on the PyPI klayout module (klayout.db Region checks, TilingProcessor for density, LayoutVsSchematic for LVS), one platform per commit. Each Python deck is checked against the Ruby deck's violations on the same GDS. Upstream KLayout ships no Ruby in the PyPI module (KLayout/klayout#1772) and points to plain Python over Region for this (KLayout/klayout#1980). Draft until the decks are in.

[oharboe]

@maliberty Rewrote ruby to python, klayout only needed for those designs(confidential/users) that still use Ruby. My thinking is they can install klayout themselves and ORFS can drop klayout install. I don't have any opinion on the deprecation period.