Export formats
A reference for the downstream formats Qfactr exports to, and how to choose between them.
Qfactr keeps your design as one editable, physically grounded model: components at real micron coordinates, explicit waveguide routes between real pins, hierarchy, and the S-matrix data behind each part. When you are ready to hand off, that single model exports into the formats your downstream tools already expect, so you can fabricate, simulate, or co-simulate without rebuilding the circuit by hand.
This page is a reference for each supported format and what it is for. For the end-to-end workflow of getting a design out of the workspace, see Exporting your design.
Supported formats
Each format below targets a different stage of the photonic design flow: mask layout for fabrication, frequency-domain circuit simulation, time-domain simulation, and co-simulation with electronics.
| Format | What it is | Use it for |
|---|---|---|
Nazca (Python) | A Python-based photonic layout framework. Export produces a Nazca script that builds your circuit as physical geometry. | Generating mask layout programmatically and dropping into an existing Nazca-based fabrication flow. |
GDS (GDSII) | The standard binary stream format for IC mask layout — polygons on named layers. The universal handoff to a foundry. | Sending the final mask to fabrication, or importing into any layout/DRC tool that reads GDS. |
SAX | A frequency-domain, S-parameter circuit simulator. Composes the S-matrices of your components and routes into a circuit response. | Fast linear circuit simulation — transmission spectra, filter responses, and power budgets. |
Simphony | Another frequency-domain photonic circuit simulator built around S-parameter (compact) models. | S-parameter circuit simulation when your models or workflow are built around Simphony. |
PhotonTorch | A time-domain photonic circuit simulator with GPU support. | Time-domain behaviour and dynamic effects, and larger sweeps that benefit from GPU acceleration. |
Verilog-A | A behavioural hardware description language used in analog/mixed-signal EDA. | Co-simulating your photonic circuit alongside electronics in a standard EDA simulator. |
SPICE | The canonical analog circuit simulation format and engine. | Electro-optic co-simulation — driving and reading your photonics from electronic circuitry. |
Notes on choosing a target
The formats split into a few clear roles. Knowing which question you are asking points you at the right one.
Fabrication: Nazca and GDS
GDS is the universal mask handoff — almost every foundry and layout tool reads it, and it is what ultimately gets fabricated. Nazca sits one level up: it is the Python layout framework that generates that geometry, so exporting Nazca keeps the layout scriptable and parametric on the way to a GDS mask. Because Qfactr already works in real micrometers with PDK-aware parts, the exported geometry reflects exactly what you placed and routed. See Process design kits (PDKs) for why designing against a foundry-validated kit is what keeps that geometry manufacturable.
Circuit simulation: frequency- vs time-domain
For circuit-level analysis, choose by the kind of answer you need. SAX and Simphony are frequency-domain, S-parameter simulators: they cascade the S-matrices of your components and routes to give transmission spectra and power budgets quickly, which suits linear, steady-state questions like filter shape or insertion loss across wavelength. PhotonTorch is time-domain and GPU-capable, which suits dynamic behaviour and larger sweeps. The S-matrix data that makes these exports meaningful is the same data your components carry inside the workspace — see Components & building blocks.
Co-simulation with electronics: Verilog-A and SPICE
When a photonic circuit is driven or read by electronics — modulators, photodetectors, thermo-optic phase-shifter control — you often need to simulate both domains together. Verilog-A and SPICE exports let your photonic design participate in a standard analog/mixed-signal EDA simulation alongside the electronic circuitry.
One model, many outputs
The point of a single physically grounded representation is that these exports are different views of the same design, not separate re-entries of it. You lay out and route once; fabrication geometry, circuit-simulation netlists, and co-simulation models all derive from that one model. That is what lets a team iterate in days, not weeks: a change to a route or a component propagates to every downstream target on the next export rather than forcing a manual rebuild in each tool.