GDSII Export Automation

The GDSII file format is commonly used to store layout data. Various Lumerical script commands allow users to export and import structures to GDSII; however, the basic GDSII export script commands require significant effort to automate the export process. This article outlines a flexible scripted solution (attached) to export device layouts from Lumerical geometry. For context, we introduce some alternative options and advanced functionalities to help ensure you are using the best approach for your application.
[[Note:]] A previous version of GDSII export automation was made obsolete with an update to Klayout in (2021). For reference, we have attached the older files in the attached archive folder.

See also

• Importing and exporting GDSII files
• Layer builder - Simulation object

Overview

This article outlines how to automatically export your structures from the Lumerical Objects Tree to GDSII. There are essentially three steps.

1. Download the gds_export package attached this article and unzip the file.
2. Define the layers you want to extract in a LSF file following the attached examples.
3. Run the LSF script with your FSP file and specify the output filename.
4. Inspect the output GDSII file.

From the FSP we will preserve the tree hierarchy (as cells and sub cells in GDSII), allowing you to organize your geometry according to your preferences. We will provide more details and look at a few of the attached examples after discussing some other approaches.

GDSII Import\Export Options

Export Options

Download the associated files, gds_automation_script.zip , unzip the folder and put all the files in the same directory.

The approach given here should work for the vast majority of export uses cases; however, there are known limitations and workflows that require slightly different approaches.

• Finite element IDE (CHARGE,FEEM, DGTD,HEAT), one can use the workflow.
• Topology optimized devices another approach is required. In this case the workflow uses an (n,k)-import objects, and so we employ the getcontours algorithm – see known limitations.
• Very large devices like metalenses that consist of billions of elements. In this case a more efficient, but less flexible approach is used.

Import Options

For GDSII import it is typically straightforward to use the GDSII import feature[] or script commands[]. This will require modifying the materials and thickness after import [ ]. The Layer Builder utility is an advanced tool to make this process easy and repeatable by using a process file for the layer structure and process information. The GDSII files are simply used as the pattern properties.

Layout and Schematic Driven Flows

This article is focused on getting device geometries from Lumerical MODE and FDTD; however, the GDSII format’s primary utility is in defining the layout of the entire photonic integrated circuit when fabricating lithography masks. Photonic circuit analysis is the domain of Lumerical INTERCONNECT where typical workflows involving generating reduced order compact models of each device through Lumerical’s physics solvers, and then analyzing their collective performance using these blocks. Defining the PIC layout would follow an analogous progression, where individual device geometries are exported using this flow, but would then need to be placed within the entire circuit with waveguide routing between them.

There are several commercial and open-source options that can be used for PIC layout. The options are two numerous to iterate here; although, it is worth mentioning that two common paradigms are used. Layout-driven design involves direct geometric layout, with tool that help waveguide routing. Schematic-driven design approaches the problem from a topological perspective, where the connections between devices are determined first and algorithms are used to automatically create the layout.

GDS Export Automation

Known Limitations

• Groups need Unique Names
• Polygons with very dense points can be problematic
• Complex mesh order does have some issues
• Unsupported Types
  • Surface Objects
  • (n,k) import
  • Assembly Group
  • 2D Objects

To export your to GDSII you need two things, your Lumerical geometry should be defined in an FSP, or LMS file and a user defined layer definition. The attached program will map the object tree hierarchy to GDSII format and loop over your layers, extracting the polygon vertices of the various materials and planer slices. The geometry needs to be be oriented with layers stacked in the global Z-direction.

Step 1:

Download the associated files, [[gds_automation_script.zip]], unzip the folder. This program is defined through a set of dependent recursive functions defined in the [[GDSexport_core.lsfx]], and a wrapper function defined in [[GDS_auto_export.lsf]]. The user needs to call GDS_AUTOEXPORT_MAIN to extract the geometry.

To have the required functions imported use feval in the script to run these two files. It is simplest to put the FSP, and these files together in the same folder; however, you can specify the path explicitly. In this package we have put the test cases in a set of subfolders, and prerun these files in the parent directory using “..”. Remove these if these script files are in the same folder as the FSP.

feval("../GDSexport_core.lsfx");
feval("../GDS_auto_export.lsf");

The lsfx is in an encrypted format to prevent modification. One can inspect the GDS_AUTOEXPORT_MAIN in the GDS_auto_export file, but this is not necessary.

Step 2:

Define the layers for extraction in Lumerical and the labels for these layers in GDSII. To do this we define each layer as a struct. This means you have a struct -datatype- with the following format.

• layer.z [float]: the z value to used when extracting the device profile
• layer.material [string]: This cane be the material name in the material database, or an a number for the index of the object defined dielectric.
• layer.layer [string or integer] : This the label identifier

layer_1 = struct;
layer_1.z =0.0e-6; 
layer_1.material = "Au (Gold) - CRC";
layer_1.layer = "1:0";

After defining each layer, you can package the results together into a cell of all layers, which can be passed to the GDS_AUTOEXPORT_MAIN

layer_def = cell(3);
layer_def{1} = layer_1;
layer_def{2} = layer_2;
layer_def{3} = layer_3;

Step 3:

After you have defined the inputs, you can pass the arguments to the GDS_AUTOEXPORT_MAIN as the a struct. It requires the following fields to be defined.

• layer_def
• gds_filename
• verbose

The gds_filename arguments is set to use the name of the current fsp. Verbose is a Boolean value used to print additional logging information, like timing and plotting the found polygons.

Step 4:

The script can take some time to run, typically a few 1-5 minutes. Check the generated GDSII file using your layout tools (e.g., KLayout). If the export process fails in the middle of the export process the gds file will not close properly and the file can no longer be modified. To avoid future errors, you can restart the GUI. Alternatively write to a new gds file, and delete the failed gds file, after closing FDTD.

Examples

We have included three test cases in the GDS export package. In the test cases folder open the respective FSP file and then run the lsf of the same name.

3Layer

This file consists of 3 different materials. The script will export each layer as a separate material, even though the z-position is set 0.0, for all layers.

Grating Coupler

This example is a more realistic grating coupler device. The attached script will export the silicon device layer and the etch layer.

Metalens

This example demonstrates a larger model, and will require longer to run. We can see the layout reconstructed with high fidelity below.