Required input data
Type | Template file | Description |
---|---|---|
Measurement data | Exp_data.csv | Comma-separated file containing experimentally measured data for some of the s-parameters |
Element configuration file | y_branch_strip_te_c_sparam.lsf | Lumerical script file with configuration settings for spar_fixed photonic model |
Process file | lumerical_foundry_process_file.lbr | Lumerical generic process file containing layer information to build 3D design geometry |
Design layout | y_500.gds | The layout of the design for which data collection is required |
Port specification in GDS file
In order to specify the location of ports for FDTD simulation within the design layout, you can simply draw a box or polygon object with 4 vertices perpendicular to the intended propagation direction in the waveguide as shown by the green box in the figure below. The center of the box along X/Y directions will be considered the center of the port and is recommended to be aligned with the center of the waveguide along its width. The X/Y span of the box doesn’t make any difference in the port setup as the port’s width is automatically set by the flow or can be overridden in collection settings.
The ports’ order and numbering will set automatically by the flow with port 1 being the most upper left port in the design and moving clockwise (left to right, top to bottom) to assign numbers to the rest of the ports.
The injection axis and direction of the port doesn’t need to be specified and will be set automatically by the flow. Rotation is not supported for the ports and only injection along the X or Y axis is supported.
A layer corresponding to the ports with an arbitrary layer number/data type should be added to the layout and all the boxes representing ports should be assigned to that layer.
Port information in process file
The process file should include a layer named “Ports” with an identical layer number/data type to the layer used for the ports in the GDS. This layer should be disabled in the process file so that it is not imported as a physical layer in the simulation and affect the imported geometry of the design. The start position and thickness should be the same as the waveguide layer (the layer including the pattern of your design). The process type should be set to “Grow”. Other settings of this layer do not matter and will not affect the operation of the flow.
The center of the ports in the Z direction will be aligned to the center of this layer (0.11um for the example above) and the thickness will determine the minimum Z span of the ports.
For more information about how to work with and edit a process file, see Layer Builder Simulation Object.
Element configuration
This file should contain all the necessary parameters and configurations needed by the spar_fixed photonic model of CML Compiler. For more information about all the required contents of the element config file, please visit spar_fixed - CML Compiler Model:
The same file can be provided to CML Compiler as a source in order to generate a fixed s-parameter compact model alongside the s-parameter data generated by the workflow.
It is important to make sure that the port and mode information is correct here as this data will be used by the flow to set up the simulation and configure the output data. For example, if you need a single-mode TE s-parameter data for a waveguide crossing with 4 ports, you need to make sure that the element config file contains port information for 4 ports and only mode data for a single mode.
Experimental data
Experimental data is supported through both .csv and .txt formats and the data should be arranged in a column-based format similar to the provided template. The following settings in the workflow driver file will help the flow to properly interpret the data you provided:
- config.external_spreadsheet.use determines whether or not external data should be loaded from a spreadsheet.
- config.external_spreadsheet.input_file is a string specifying the name of the input data spreadsheet to load from the input directory.
- config.external_spreadsheet.smooth_data determines whether or not the external data should be smoothed using a polynomial fit.
- config.external_spreadsheet.smoothing_fit_order determines the polynomial order to use for smoothing the external data.
- config.external_spreadsheet.columns is a cell array defining the contents of the spreadsheet columns, so it can be parsed by the flow. Each cell array should be a struct which contains the type field, and some other fields which depend on the type used.
- The type field can be set to “wavelength”, “frequency”, “power”, or “transmission”.
- If the ;type field is set to “wavelength” or “frequency”, then the cell entry should also contain the field unit, which contains the value of the provided unit in SI units. (1e-9 for nm, 1e12 for THz)
- If the type field is set to “power” or “transmission”, then the cell entry should also contain the fields input_port, output_port, mode_id_in, and mode_id_out, which each correspond to the input and output port and mode IDs.
Ensuring the final model is ‘physical’
The spar_fixed photonic model, for which this workflow is designed, is intended to model passive multi-port photonic devices. All such devices have transfer functions which are both reciprocal and passive. An S-parameter is passive if it’s spectral norm (or L2-norm) is less than or equal to one and doesn’t result in optical power gain. An S-parameter is reciprocal if the transfer between two ports is independent of direction. The s-parameter workflow is equipped with a module that can process the data to ensure that the final compact model always satisfies these conditions.
Passivity Enforcement
The s-parameter data collection workflow is capable of testing and enforcing passivity. The workflow provides many options for enforcing passivity in the final device:
- "ignore" will disable passivity enforcement, along with passivity checking. This option is not recommended.
- "test" will test to see if the s-parameter is passive by calculating it’s spectral norm, but won’t process the data at all.
- "enforce" and “enforce-sep” apply the scaling passivity algorithm.
- “enforce-sep” will apply the scaling passivity algorithm separately for each wavelength.
- “enforce” will apply the same scaling across the entire bandwidth, allowing preservation of the spectrum’s shape.
- "optimal" and “optimal-sep” apply the SVD passivity algorithm
- “enforce-sep” will apply the scaling passivity algorithm separately for each wavelength.
- “enforce” will apply the same transform across the entire bandwidth, allowing as much preservation of the spectrum’s shape as is possible.
Sometimes, enforcing a maximum L2norm of one will still cause a slight passivity violation in the final INTC model. Because of this, a margin can be applied to the passivity of the processed data using the config.enforcement.passivity_tolerance setting. If passivity is enforced with a nonzero value for this setting, the final model will have a spectral norm which is at least that far below unity.
The Scaling passivity Algorithm
One option for enforcing the passivity of the device is by scaling the s-parameter amplitudes down until the device is passive. This method preserves the phase of the s-parameter but may scale the amplitudes of the s-parameter quite significantly to achieve a spectral norm less than or equal to one. There are two options for applying this scaling.
One option (“enforce”) finds the scaling factor for the point of highest passivity violation and scales the entire s-parameter according to this factor. This option is most appropriate when preserving the overall shape of the s-parameter spectrum is important.
The other option (“enforce-sep”) finds and applies the scaling factor separately for each frequency point. This option is most appropriate when it’s more important to alter the s-parameter as little as possible for each frequency point, and altering the shape of the spectrum is acceptable.
The SVD passivity Algorithm
The “optimal” option for enforcing the passivity of the device uses a passivity algorithm that modifies both the amplitude and phase of the s-parameter. In general, this method will not preserve phase and will modify the transfer-function between each port pair differently.
This method works by taking the singular-value-decomposition (SVD) of the s-parameter and using it to construct a transformation that reduces the maximum eigenvalues to unity. This transformation has been proven to enforce passivity while altering the individual matrix elements as little as possible [1]. There are two options for calculating and applying this transformation.
One option (“optimal”) finds the transformation needed to passivate the s-parameter at the frequency of the highest passivity violation and then applies that transformation across the entire spectrum. This first option is the best choice if preserving the shape of the s-parameter spectrum is important.
The other method (“optimal-sep”) calculates and applies a separate transformation for each frequency point. The second option is the best choice if altering the individual matrix elements by the smallest amount at each frequency point is important.
Reciprocity Enforcement
Reciprocity can be enforced by setting config.enforcement.reciprocity to “enforce”. When this is set, the workflow will ensure that the final device is passive by taking the average between the s-parameter and its transpose at all frequency points.
Combining Simulated and Experimental Data
The s-parameter data collection workflow is intended to make it as easy as possible to generate and utilize simulated results to create accurate compact models of passive multi-port photonic components. Oftentimes, CML designers wish to use experimentally measured transmission values for their devices since they are more representative of actual device performance. However, it’s often hard to measure values for the phase-shift between ports, or values for reflection at a port. Therefore, the flow is designed in a way which allows you to apply their measured transmission amplitudes for model accuracy, while still including things like phase-shift and reflection from simulated results.
There are two methods for creating models that use a combination of simulated and experimental data using this workflow. One method allows you to use full-spectrum measurements for s-parameter entries, and the other method allows you to provide single values for s-parameter entries. The first method is performed using the "external_spreadsheet" module, whereas the second method is performed using the "external_singles" module.
External Spreadsheet
This method is used for when values of external data are available at multiple wavelength points across the spectrum. For details of the options available for this method, see "Experimental Data" section of this page.
External Singles
The external_singles module is used to apply externally provided single-values for transmission, phase, and group delay values. These single values are used to tune the final device spectrum to experimental results. This module applicable when simulation is the primary source of the device spectra since it allows tuning of the simulation data to match single external values (usually values at mid-band or operating wavelength).
- config.external_singles.use determines whether or not the workflow should load and apply single external values.
- config.external_singles.amplitude_type is a string containing the value “ignore”, “transmission”, or “power”. If “transmission” or “power” is selected, then the values within config.external_singles.amplitudes will be treated as either transmission amplitude or transmission power - respectively.
- config.external_singles.amplitude_method is a string that determines the method of tuning used to match final device spectra to the single-values provided. Options are “constant”, “mean”, or “mid_band”
- “constant” will set the final transmission spectrum to the values provided for each set of input/output ports/modes. This is most useful for setting reflection values of the final device without needing to run simulations.
- "mean" and “mid-band” will scale the simulated device spectrum so that it’s mean or mid-band value matches the value provided. This is most useful when a single approximate reflection value is known for the entire spectrum, but simulation results are desired to capture frequency dependence.
- config.external_singles.amplitudes is a cell array containing structs which are the single values used within the algorithm specified by config.external_singles.amplitude_method. Each cell should contain a struct with the fields value, input_port, output_port, mode_id_in, mode_id_out.
- config.external_singles.phase_type is a string containing one of the values “ignore”, “phase”, or “group_delay”. This tells the rest of the flow whether the externally provided phase values should be used and whether they are phase values (in radians), or group delay values.
- config.external_singles.phase_method is a string containing one of the values “constant” or “mid-band”, and is only used if phase_type is set to “phase”.
- “constant” will set the phase of the final device to the provided phase value across the entire spectrum. This should not typically be used since oftentimes the phase shift between ports is highly frequency dependent.
- “midband” will shift the simulated phase spectra to match the single value at the center of the band.
- config.external_singles.phases is a cell array containing structs which are the single values used within the algorithm specified by config.external_singles.phase_method. Each cell should contain a struct with the fields value, input_port, output_port, mode_id_in, mode_id_out.
Related Publications
[1] Doshi, K. et al. “Fast and Optimal Algorithms for Enforcing Reciprocity, Passivity and Causality in S-parameters.” (2012).