RSoft & Photonic Solutions Enewsletter

Quick Tip: Mask file handling in OptoDesigner

When creating photonic chip and mask layouts in OptoDesigner, you can use scripts to generate hierarchies of complex building blocks from PDK components. In addition to scripts, OptoDesigner has a number of other tools to help you build layouts, such as GDS files and internal mask representations. This article provides an overview of these tools.

OptoDesigner contains an in-memory representation of any number of masks, called the file cache. These masks may have been loaded from disk or generated by layout definitions. Each cache is referred to by a string, and may (like a GDS II file) contain not only polygon definitions and text, but also static cells (which in turn contain polygon, text and cell calls) and calls to those cells. Many operations can be performed on file cache items, such as Boolean operations and snapping.

Another tool to help build layouts is the gdsfile script class, which is a wrapper around a file cache that provides a simple interface to frequently used functions.

Gdsfile Class

The easiest way to deal with mask files is the gdsfile script class. It is loaded with the command #include @mask/file.

The gdsfile class has the following capabilities:

  • Load a GDS II file into memory.
  • Place the GDS II file into your design. The ‘place’ function has a 'wher' port that corresponds with the origin of the mask file and can be placed anywhere. Note: Be careful with rotations; if you place a mask file at a non-cardinal angle, most internal vertices will no longer be on grid. Many foundry tool chains do not accept this placement, since it requires them to modify your design by snapping the vertices to the grid.
  • Query all used mask layers, or automatically create them. The ‘getLayers’ function returns the array of layers used by the mask file. The ‘loadLayers’ function creates the layer objects in OptoDesigner as though you have called a ‘mask::AddLayer’ function on each. Note: Only layers created with ‘loadLayers’ or ‘mask::AddLayer’ will be exported.
  • Switch layer numbers. If you have a design for one technology that is functionally equivalent to another but uses different layers, you can change the layer number of all objects in a layer to another layer number with the ‘switchLayer’ command.
  • Cell operations. A mask file can have multiple cell definitions. A number of functions exist to query and manipulate cell definitions:

o   topCell: Returns the most likely top cell. The top cell in a mask is the one that is not called by any other cells.

o   Query the list of available cells

o   Query the list of cells that are being called from anywhere in the mask

o   Cell rename and deletion functions

o   Cell addition functions

o   cellKeep: Delete all cell definitions that are not called by the cell or other cells in its call tree

  • Get or set the file cache instance name
  • Save to a GDS II or .cif file on disk

Direct File Cache Processing

If the gdsfile class does not fully support your needs, you can also perform direct processing on the file cache. The relevant commands can be found in the Mask File Cache dialog box (Mask menu).

A file cache can be created directly from a design with the ‘mask::exportFileCache’ function.

You can perform Boolean operations between mask layers, or apply operations such as Heal (i.e., remove overlapping areas and merge touching polygons) or Snap on one layer. The operations will create a new file cache containing the results. This means that when you have performed the operation, the original file cache is untouched. To replace the original file cache or to remove all layers included in the Boolean operation except the result:

1.       Manually remove the layers using ‘mask::cacheDeleteLayer’

2.       Merge the results back into the original file cashe using ‘mask::cacheAppend’

3.       Delete the result of the Boolean operation using ‘mask::clearFile’

Important: All single and multi-layer operations that produce a new file cache require you to name the new cache (the parameter ‘Alias’). For performance reasons, OptoDesigner assumes that if a cache with that name already exists, it has the correct data and will not be recalculated. Therefore, it is imperative to either delete intermediate results or to make sure that each one is unique – unless you know that the data will still be correct later in the script, ready for re-use.

Under 'Mask File Cache / Boolean mask operations,' you’ll find all single- and multi-layer layer processing functions. Each of these can take up to five input mask file caches (arguments ‘Mask’ and ‘Merge’), from each of which a subset of layers can be chosen, with one output layer (argument 'Layer').

All selected layers from all input file caches are merged together before the operation takes place. The multi-layer operations always need an output layer to which the results are written. The single-layer operations (heal, snap, fracture, etc), however, also have the option of not specifying the output layer. This will automatically perform the operation on the ensemble of layers, producing the output in all the same layers as were in the input. If you do specify an output layer, the functions first merge all polygons from all specified layers from all inputs together before performing the operation.

Some more generic tips and tricks:

  • You can place a generated file cache into your design using either ml::Maskfile_SingleLayer or by creating a gdsfile instance, setting its file cache to the created one, and calling ‘Place’
  • Some operations (e.g., ‘mask::LayerSnap’) require the input file cache to have undergone a previous Boolean operation, such as ‘mask::LayerHeal’, to function properly
  • To avoid stitching errors, always perform a ‘mask::LayerSnap’ operation on all layers of a design before export. This ensures that vertices on one layer that should be on a line of a polygon on another layer actually are (will add a vertex to the line). 

Feature Highlight: Launch Computed Mode of a Waveguide Structure

A common task when studying waveguide-based photonic devices is to launch a mode of the waveguide into the device to investigate how the mode will be propagated through the device. This can be tricky when you are studying a wavelength range where the mode changes with wavelength. The Computed Mode feature provides a convenient way to solve this issue. 

Computed Mode calculates the mode of the structure on the fly and then uses it as the launch field. As an example, we will use a variation of the feature that calculates the mode of a structure defined in a separate design (.ind file). We will simulate a Si Y-splitter, shown in Figure 1a (SiYSplitter.ind). Figure 1b shows the launch configuration where we have chosen a launch Type of Computed Mode and set the Comp Mode .ind File to SiWG.ind. SiWG.ind is another design file that represents a standard silicon waveguide and matches the input of the Y-Splitter.

Figure 1: a) Y-splitter structure

Figure 1: b) Launch dialog box setting for launch waveguide mode

Figure 2 shows the result of a beam propagation simulation of the Y-splitter using Synopsys’ BeamPROP BPM simulation tool. The result in Figure 2a shows the field along the device and the overlap power with launch mode. Figure 2b shows the output power at the end of Y-splitter vs. wavelength for two different Si waveguide widths. The launched modes are calculated using the .ind file specified in the launch dialog box for each wavelength/width and then used to make measurements during the simulation. 

Figure 2: a) Field within Y-Splitter at one representative wavelength/width

Figure 2: b) Output vs. wavelength for two different waveguide widths 

You can access the design files used in this Computed Mode example on the Customer Support Portal.

New Models Added to PDK AMF

This PDK is a plug-in library for OptoDesigner developed by AMF. In addition to the photonic elements from the standard generic design library, the PDK contains technology-specific information including mask layer names, design rules, validated building blocks, die sizes, and GDS file settings. The PDK has been updated since June 2019 with:

  • OptSim Circuit modeling part
  • Support for bidirectional interface

Calendar

For the latest event calendar, please go to our Events Page.