Changelog

What changed in each release of the laylight command line, newest first. Every release can be installed from the download site or from PyPI as laylight-cli. From 0.2.2 on, the Laylight Python library is released with it, at the same version, as laylight.

0.3.1 — 2026-10-15

Added

• GDS cell imports. import "library.gds" exposes cells with valid DSL names; import "library.gds" cell "MMI$1" as MMI selects any cell, including a nested cell, with a local alias. Used cells keep their hierarchy, layers, arrays and Laylight metadata, with coordinates converted to the design's DBU. The language server completes GDS paths and cell names, navigates to imports and renames aliases. The browser compiler and language client accept binary GDS files as Uint8Array, and the editor accepts them through binaryFiles. Unsupported geometry and instance transforms produce import errors; ordinary text labels are omitted with a warning. See Importing GDS Cells.
• Design rule checks. define drc <name> { ... } writes a process's rules in Laylight: width, space (one layer, or between two), enclosure a in b, overlap, area and radius, with limits that are ordinary expressions, severity / metric / message properties and optional names. laylight check runs every deck after evaluation, laylight drc runs them alone (--deck to select, --report out.json for every violation with coordinates, both edges, sources and timing), and the language server reports violations while you type. Each violation points at the shape ... as name statement that drew the shape and, between instances, at the place statements. Cells are checked once however many times they are placed; the interactions between instances are checked only where they come within a rule's limit, and identical pairs of array members once. The checks know the shapes' primitives: an isolated ring at the minimum width passes by its parameter, the radius rule reads the tightest radius of a bend from the curve, and the edges of discretized curves carry a 1 DBU tolerance, so no violation comes from discretization alone. inside a in b reports every part of a outside b, through the hierarchy. Decks can define derived layers (define clad = slab - si, grow / shrink, .holes / .hulls / .extents, selections such as .not_inside(b) and filters such as .with_area(min, max)) and report them with empty; notch, isolated, length, angle, corner, grid and density rules, area <=, the square metric, min_projection / max_projection and angle_limit cover the rest of KLayout's common checks (see docs/laylight-dsl/drc-gaps.md for what is left). laylight drc writes marker files (--lym out.lym, a compact indexed binary of every violation, read back by laylight lym), the layout with a marker layer per rule (--markers), checks GDS or IR files against the decks of a source file (--rules), and checks cells on all cores. On straight-line layouts the edge-pair results match KLayout's exactly; bench/drc/ scores Laylight, KLayout, gdsfactory and gdstk on speed, scaling, missed violations and false positives against planted violations.
• Blackboxes that survive other tools. A blackbox's record now also names the cell it was published as, its database unit, the signature scheme, what published it, and digests of each part of the interface and of each layer of the whitebox (record format 2; blackboxes published by 0.2.2 to 0.3.0 still read and verify). In GDS the record is kept in several places: the cell metadata, a record text on the blackbox layer whose string is the record (it survives tools that drop GDS properties), the outline code (the content signature drawn as squares in the arrow's shaft, which survives tools that drop texts), the pins, and properties on every reference to the blackbox. So a blackbox can still be unboxed after KLayout renames it to resolve a name clash, after its properties or texts are dropped, or after its marker layer is filtered out. unbox then checks it against the blackbox its whitebox makes and warns. See Blackboxes.
• Checks that say what differs. Verifying a blackbox (at import, in unbox and with the new laylight blackbox --verify <file>) names the parameter, attribute, marker, footprint or database unit that is not as published, shows outline and pin differences and where they are (comparing regions, so polygons that another tool re-cuts or reorders still match), and notes renames. Reading GDS reports blackboxes that were flattened into another cell, merged with or replaced by a cell of the same name, and copies of a record that disagree. A whitebox that does not match says on which layers its geometry differs.
• laylight unbox builds parametrized whiteboxes from source: each blackbox's source cell is built with the parameters the blackbox records, so the blackbox of Arm with length = 50um (Arm$…) is found in cell Arm(length = 20um).

Changed

• laylight blackbox refuses to publish a blackbox whose metadata would not survive GDS and IR exactly, and then writes no files. The checks cover values longer than GDS's 126 bytes, text that is not printable ASCII, values that do not read back the same (such as areas), and too many properties for one GDS element. Before writing, it also reads the blackboxes back from GDS and IR in memory. The GDS writer likewise refuses to drop any of a blackbox's metadata, where other cells only get a warning.
• laylight unbox fails when a blackbox is left without a whitebox. --partial keeps such blackboxes with a warning, for designs unboxed in steps. It also fails when a cell that is not a blackbox has shapes on the blackbox layer (a flattened blackbox). Blackbox outlines now carry the outline code, so newly published blackboxes look speckled inside the arrow's shaft.

0.3.0 — 2026-10-10

Added

• Anonymous usage statistics. After each command (when laylight lsp starts), laylight sends one small event to telemetry.photonstack.io: the command, the names of the options given, the kinds and sizes of its files, the run time and outcome, the version and the system. File names, contents, option values and identifiers are never sent, and the server keeps no IP address. The first run prints a notice and sends nothing, CI runs send nothing, and laylight telemetry disable, LAYLIGHT_TELEMETRY=0 or DO_NOT_TRACK=1 turn it off. LAYLIGHT_TELEMETRY_DEBUG=1 prints the event instead of sending it. See Telemetry.
• laylight lsp runs the language server on stdin and stdout, so every editor with LSP support gets diagnostics (evaluation errors included), completion, hover with evaluated values, go to definition, references, rename, formatting, an outline and semantic highlighting; see Editor support. It replaces the separate laylight-lsp executable.
• Completion by context. In with clauses and calls the parameters of the primitive, cell or cross-section that are not given yet; the values of string parameters (profile = "…", ends, join, a marker's kind and direction); import paths; units after a number; the clauses that can continue a place, shape or clone statement; statement keywords at the start of a line; nothing in comments or where a new name is written.
• The language server runs in the browser. Compiled to WebAssembly, it completes code as you type (or on Ctrl+Space) in the DSL playground and the Tour.
• laylight netlist and laylight lvs also read Laylight IR (.lyir) and GDSII, such as the IR the Python library writes: laylight lvs chip.lyir --netlist ref.json. Connections between coincident ports are found again on reading, since GDSII keeps no connections and IR from elsewhere may record only the declared ones.

0.2.2 — 2026-10-08

Added

• The Python library is released with the command line. pip install laylight==0.2.2 installs the library and the laylight-cli of the same version. Its devices and Placer now build Laylight IR in Python: one cell per parameter set, named as the DSL names cells, ports as input / output markers and port-to-port placements as connections. layout.write("out.gds") compiles the IR with laylight build, and laylight.read() reads GDSII or IR back. KLayout is no longer needed; it stays optional (laylight[klayout]) for PNG previews and PCells.
• Dummy fill. --dummy <layer>[:<options>] on laylight build, ir and unbox fills the free space of a layer with square tiles as the layout is written, without changing the language or the IR. Tiles lie on a grid anchored at the top cell's origin, keep keepout away from the layer's geometry, from exclude layers and from blackbox footprints, and stay inside the top cell's bounding box or the shapes of an area layer, less a margin. Options set the tile size and space, a datatype for the tiles and staggered rows. The tiles are written as arrays of one tile cell, so a million tiles take a few thousand array references.
• laylight build and laylight ir also read Laylight IR (.lyir) and GDSII, so an existing layout can be filled: laylight build chip.gds -o filled.gds --dummy si.

0.2.1 — 2026-10-07

Added

• Blackboxes. laylight blackbox publishes cells as blackboxes: the outline and ports of a cell without its geometry, as Laylight IR (-o cells.lyir) and GDSII (--gds). The outline is drawn on the blackbox layer (254/0 unless the layer table names one) with an up arrow etched out of it, footed to the left so that rotated and mirrored placements show; every port gets a pin on the marker layer as wide as the port. Parameters, attributes and markers are kept.
• laylight unbox puts the real cells (whiteboxes) back in place of the blackboxes of a design. The design and the whiteboxes can be Laylight source, IR or GDSII, so a design received as GDS can be completed. Whiteboxes that contain blackboxes are unboxed in turn.
• Signatures. Every blackbox records SHA-256 signatures of its whitebox's content and of its interface (name, parameters, attributes, markers, footprint). They are the same whether a cell comes from source, IR or GDS. unbox takes the whitebox whose content matches, reports whiteboxes that do not, and with --allow-revision accepts one whose geometry changed but whose interface did not. A blackbox edited after it was published is reported.
• IR imports. import "cells.lyir" reads Laylight IR, the output of laylight ir or laylight blackbox, and its top cells can be placed like cells defined in source, so other projects can reuse cells without their source. The language server completes their markers and goes to their definitions.

0.2.0 — 2026-10-06

Added

• Cross-sections (define xsection): the layers across a waveguide, drawn along the centerline of path, straight, arc, euler, sbend, bezier, ring, racetrack and taper. Tapers pair the sections of two cross-sections by layer, min_radius is checked on the exact curve, ports placed on waveguide ends carry their cross-section, and LVS reports connected ports whose cross-sections differ.
• The straight primitive.
• Statements in cell bodies. define, for, if, place and layer blocks can be written directly in a cell, and layer blocks inside for and if.
• PyPI. The command line is published as the laylight-cli package: pip install laylight-cli, uv tool install laylight-cli or pipx install laylight-cli.

0.1.0 — 2026-10-06

The first release of the laylight command line, for Linux (x86-64 and ARM64, glibc 2.17 or later), macOS on Apple silicon and Windows (x86-64), with install scripts for each.

• check, ir, build, decompile, netlist, lvs, fmt and parse: check, evaluate and compile Laylight files to GDSII, write and compare netlists, turn GDSII back into Laylight source, and format.
• Boolean and morphological operations that run on all cores for large inputs.