Exporting your design

Photonic design rarely ends in a single tool. A finished layout has to reach a foundry as a mask, a circuit simulator for frequency-domain analysis, a time-domain solver for dynamics, and sometimes an electronics co-simulation flow. Qfactr keeps layout, routing, components, hierarchy, and simulation-aware context in one editable place, then exports that single model to each of these targets so you do not maintain a separate netlist, schematic, or geometry by hand.

Because routes are real S-bend and Manhattan geometry between real component pins, and components carry physical pin positions and S-matrix data from their PDK, the exported artifacts describe the device you actually drew — not an abstract approximation of it. You design once and hand off to the flow your team already uses.

One design, many targets

Export lets you take the same underlying model in different directions depending on what you need next. The four target families below cover the common photonic design-to-fabrication and design-to-simulation handoffs.

The split is deliberate: fabrication and simulation want fundamentally different descriptions of the same circuit. A foundry wants exact geometry on the correct layers; a circuit simulator wants the connectivity and S-parameter behavior of each component. Qfactr derives both from the model you already built.

Choosing a target

If you are taping out, you want the fabrication path: Nazca generates the layout and GDS is what the foundry ingests. If you are analyzing behavior before committing to silicon, choose a simulator by the kind of answer you need.

• Spectral / steady-state response — transmission, insertion loss, resonance, filter shape: export to a circuit simulator (SAX or Simphony). These work over the S-parameter network and are well suited to frequency-domain sweeps.
• Time-domain / dynamic behavior — transient response, modulation, pulse propagation: export to PhotonTorch, which runs in the time domain on the GPU.
• Mixed electronic–photonic systems — the photonic circuit interacts with drivers, control loops, or readout electronics: export to Verilog-A / SPICE for co-simulation.

The export workflow

The shape of the workflow is the same regardless of target: build and validate in Qfactr, export, then continue in the downstream tool. Because the model already carries physical coordinates, explicit routes, and PDK-backed component data, the export captures the real circuit rather than something you have to reconstruct.

1. 1
   Finish and check the designPlace your components, route the waveguides, and resolve connectivity — unconnected pins render red, connected pins green. Run Simulate to confirm loss is reasonable before you hand off.
2. 2
   Pick the right targetDecide where the design is going next: fabrication (Nazca + GDS), circuit simulation (SAX / Simphony), time-domain (PhotonTorch), or electronics co-simulation (Verilog-A / SPICE).
3. 3
   Export the modelExport produces the artifact for that target from the single underlying design — mask geometry for fabrication, or a connectivity-and-S-parameter description for the simulators.
4. 4
   Hand off to your existing flowDrop the exported artifact into the pipeline your team already runs. The GDS from a Nazca export is the universal handoff to an existing fab flow; simulator exports plug into the analysis tools you already use.

A Nazca export is illustrative Python that builds the mask layout — the kind of foundry-facing geometry script a photonic flow expects:

# Conceptual illustration only — not a real Qfactr API.
import nazca as nd

# The exported model places components at true micron
# coordinates and routes waveguides as real geometry,
# then streams the mask out as GDSII for the foundry.
with nd.Cell(name="my_circuit") as circuit:
    # ... components and routed waveguides ...
    pass

nd.export_gds(filename="my_circuit.gds")

For a per-format reference — what each format is and exactly what to use it for — see Export formats. Qfactr's exports build on the open Lunima engine, which provides the physical layout, PDK-aware components, explicit routing, and the handoffs described here.

Next steps