Extracting a schematic from a GDS-II layout is a solved problem in CMOS EDA. The extraction algorithm reads polygon shapes, identifies transistors from their layer combinations — gate oxide over active, contacted by poly, with diffusion on both sides — reconstructs the connectivity from metal and via layers, and outputs a SPICE netlist. The algorithm works because the physics of MOSFET operation maps cleanly to polygon geometry: a gate is a gate is a gate, identifiable by the same layer stack everywhere in the design.
In silicon photonics, extraction is fundamentally harder. The "components" are optical functions — waveguides, couplers, resonators, interferometers — whose identity depends not just on layer combinations but on geometric relationships, aspect ratios, and spatial context. Extracting a photonic netlist from GDS-II means recognizing optical components from their geometry, which is a substantially more difficult recognition problem.
The Core Challenge: Optical Components Are Geometry-Defined
Consider how you identify a directional coupler in a GDS-II file. It's not a single polygon with a characteristic layer stack. It's two waveguide polygons — typically on the same layer — running parallel to each other with a specific gap and length. There's no distinct "coupler" layer. The coupler exists as a geometric relationship between two waveguide segments. To extract it as a component in the netlist, the extraction algorithm must: detect two adjacent waveguide polygons, determine that they run parallel within a specified proximity threshold, measure the gap between them, measure the coupling length, and classify the structure as a directional coupler with those parameters.
Now extend this to a ring resonator. It's a closed waveguide loop (the ring) near a straight waveguide bus (the coupling section). Recognition requires: identifying the closed loop topology in the waveguide polygon graph, detecting a straight segment in proximity to a curved ring segment, measuring the coupling gap, and extracting the ring radius and bus waveguide width as parameters of the extracted component instance.
Neither of these recognition tasks is simple polygon-to-component lookup. They require geometric reasoning over the full layout context.
Hierarchy-Based Extraction vs. Flat Geometry Recognition
There are two fundamentally different approaches to photonic GDS-II extraction, and understanding the difference is important for evaluating any extraction tool.
Hierarchy-based extraction (top-down)
In this approach, the extraction tool reads the GDS-II cell hierarchy and matches cell names or cell signatures against a PDK component library. If a cell with the name dc_coupler_10um_200nm appears in the library with a defined port map and parameter set, then any instance of that cell in the layout is extracted as a directional coupler with those parameters. The extraction algorithm works top-down: it reads instances, looks them up in the library, assigns port connections.
This approach is fast and reliable when designs are built entirely from PDK cells. It's the approach used by most commercial PIC design environments, and it works well for production flows where designers select components from a fixed library. Its limitation is that it fails silently for non-library components: any geometry that isn't a recognized PDK cell instance doesn't appear in the extracted netlist. Custom structures, hand-drawn features, and cells from an external library are invisible.
Flat geometry recognition (bottom-up)
The flat approach reads all polygons in the GDS-II, ignoring cell hierarchy, and attempts to recognize optical components from their geometric signatures. This is more general — it can, in principle, identify a directional coupler drawn by hand, not as a library cell — but substantially more complex. It requires robust algorithms for waveguide polygon tracing, junction detection, ring closure identification, and coupling region classification. The recognition logic is process-specific: what counts as a waveguide, what constitutes a valid ring, what gap range indicates intended coupling versus routing proximity.
In practice, most photonic extraction tools use a combination: hierarchy-based extraction for PDK cell instances (which covers the majority of the layout), with flat geometry passes for connectivity reconstruction and for detecting non-library structures that may indicate problems.
The Connectivity Graph Problem
After component instances are identified, extraction must reconstruct the optical connectivity: which ports connect to which. In CMOS, connectivity comes from metal layers — you trace metal wires from component terminals through vias to find connections. In photonics, connectivity is established by direct waveguide routing: a waveguide polygon that physically connects two port coordinates in the GDS-II means those ports are connected.
This sounds simple, but the implementation has several complications.
Port coordinate matching: Two ports are considered connected if their GDS-II coordinates match. But "match" requires a tolerance: floating-point geometry in GDS, small grid snapping errors, or deliberate snapping offsets in the design tool can place port coordinates 1–5 nm apart in the file, even though the designer intended them to be connected. The extraction algorithm must handle this with a configurable tolerance, typically set at half the GDS grid resolution.
Through-routing vs. termination: A waveguide may pass through a region where another cell's port is located, without connecting to it. The extraction must distinguish between a waveguide endpoint (a termination, or a connection to a port) and a waveguide that happens to pass geometrically close to a port without connecting. This distinction is critical for avoiding spurious connections in the extracted netlist.
Net naming for verification: In a SPICE netlist, every node has a name. In optical extraction, the "net" connecting two ports is the waveguide segment between them. For verification purposes, nets need labels that reference both their endpoints and the physical waveguide path, so that a violation can be reported with a meaningful location: not just "port A connects to port B" but "waveguide net WG_023 at coordinates (X, Y) in cell RING_01".
Extraction Failures and Their Consequences for Verification
An incorrect extraction directly corrupts any subsequent verification. If a component is misidentified during extraction — a ring resonator recognized as a straight waveguide because its radius was slightly outside the recognition threshold — the verification run will not check coupling gap compliance for that structure. If a connection is missed — two ports that should be connected but whose coordinates are 6 nm apart — the LVS comparison will flag a false connectivity mismatch that requires manual investigation.
The most dangerous extraction failure mode is silent: the tool extracts something, reports no error, but the extracted netlist doesn't accurately reflect the drawn layout. This can happen when a custom cell is silently ignored (hierarchy-based extraction), when a waveguide route has an unintended gap at a port that the tolerance-matching bridges incorrectly, or when a cell with a name collision resolves to the wrong library entry.
We're not saying that extraction errors are unavoidable — a well-designed extraction engine with careful tolerance management and explicit coverage reporting can achieve high reliability for well-structured PDK-based designs. The key word is "explicit": the extraction report should state what it successfully recognized, what it couldn't recognize, and what coverage gaps exist, rather than silently skipping unrecognized structures.
GDS-II Format Limitations Relevant to Photonic Extraction
GDS-II is a polygon-based format designed in the 1970s for CMOS layout. Several of its limitations create specific challenges for photonic extraction:
- No semantic layer information: GDS layer/datatype numbers are arbitrary integers. The meaning of layer 1 is defined by the PDK layer map, not the file format. Extraction tools must apply the PDK layer map before any component recognition makes sense.
- Curved geometry approximated by polygons: GDS-II has no native arc or circle primitive. Curved waveguides — bends, rings — are approximated by multi-vertex polygons. Extraction must reconstruct the intended circular or spline geometry from these polygon approximations, which introduces reconstruction error in radius and coupling gap measurements.
- Hierarchy is design-tool-specific: Different layout tools generate different hierarchical structures for equivalent designs. A flat GDS export (single cell, all polygons expanded) is valid GDS-II, but it destroys the cell instance information that hierarchy-based extraction depends on. Tools that produce or consume flat GDS exports are not extraction-friendly.
- No port attributes in the file format: GDS-II has no native concept of a component port. Port locations and attributes are conventions defined by PDK documentation and tool-specific annotations (often using text labels on specific layers). Extraction must parse these conventions correctly to locate ports.
OASIS as an Alternative
The OASIS format (SEMI P39) addresses some GDS-II limitations for advanced-node photonics: it supports curved geometry primitives natively, has better compression for repetitive structures, and includes a richer metadata layer system. Some advanced photonic PDKs now ship OASIS-format layout files. For extraction tools, OASIS support means cleaner curve geometry (actual arc radius rather than a polygon approximation) and potentially richer port annotation data.
However, GDS-II remains the dominant interchange format at most silicon photonics foundries, and extraction tools must treat it as the primary input for the foreseeable future. OASIS support is an incremental improvement, not a fundamental change in the extraction challenge.
Extraction as a Foundation, Not an Afterthought
The fidelity of photonic GDS-II extraction determines the ceiling on verification coverage. Every optical verification check — mode mismatch, coupling gap, routing proximity, polarization path consistency — operates on the extracted representation of the layout. If the extraction is incomplete, those checks have blind spots. If the extraction is incorrect, those checks produce false positives and negatives that erode trust in the verification system.
For teams building or integrating photonic verification into their tape-out flow, evaluating extraction quality is a necessary first step. The right questions: Does the extraction engine report explicit coverage (what was recognized versus unrecognized)? Does it handle the specific PDK cell hierarchy used by the design? Does it correctly handle curved geometry in the process's waveguide layers? Does its port-matching tolerance match the GDS grid resolution of the design tool? A verification flow built on a well-characterized extraction foundation can be trusted; one with uncharacterized extraction gaps cannot.