The '/source/' directory in the Lumfoundry Template contains subfolders for each of the elements in a CML. Each subfolder has a name which matches an element, and contains multiple files that are necessary to compile that element. Each element's subfolder contains at least the following two files:
- The element source data file (.json) contains information which is used by the photonic model to compile the element. Ex: port names, parameter values, element description, notes for the end user, QA test settings and the source data for the model. Source data depends heavily on the photonic model being used.
- An element icon file (.svg) is a vector graphics file which is used as the icon of the compact model.
Some photonic models may require other files in the source directory, for example S-parameter data files.
Often it's more practical to copy and modify the existing templates within Lumfoundry Template to suit the model being created, instead of re-creating the source data from scratch. Creating data files from scratch is often quite technical, and requires advanced knowledge of the photonic model being used.
Template icons are available within the Lumfoundry Template directory of CML Compiler under the "icons" folder. These templates can be copied or modified to suit the element being created. Alternatively, element icons can be created from scratch, if desired.
Following you can find more details on the source data file and what type of information they contain.
Element Source Data Files
The element source data file is a JSON-formatted file that contains necessary information about an element and its compact model. The information provided within the data file is highly dependent on the photonic model being used, but they tend to follow a general structure, which will be outlined in this section.
Data files contain the following sections as a struct:
general
The model data file contains a “general” struct which includes the model description, prefix and notes. For example, this is the general section for the straight fixed waveguide template in Lumfoundry Template:
"general" :
{
"description" : "Foundry strip waveguide - C band",
"prefix" : "WG",
"notes" :
{
"_data" :
[
{
"property" : "wavelength_range",
"value" : "C-band (1530 - 1565 nm)"
},
{
"property" : "temperature_range",
"value" : "Best accuracy between 273 and 373 K"
}
],
"_type" : "cell"
}
},
The 'description' string contains a brief description of the element, and is displayed to the end user in the "Description" column of the Element Library.
The 'prefix' string contains a short (typically a few letters) prefix, which INTERCONNECT uses to name the element instance when the end user adds it to the layout view. This prefix is followed by an underscore, and then an integer which increments based on the number of elements added to the layout. In the example above, if we add two elements to the layout view, they will be named like so:
Finally, notes can be added to communicate with the end user. Each element in the notes cell array is a struct which contains the property and value fields. These fields store the name of the note along with the information that needs to be communicated to the end user, respectively. The contents of notes can range from allowed model property values, to descriptions of ports, to simulation tips for maximum accuracy.
ports
All element source data files contain a struct which defines the ports within the final model. For example, these are the port definitions for the straight fixed waveguide template in Lumfoundry Template:
"ports" :
{
"opt_1" :
{
"name" : "opt_1",
"dir" : "Bidirectional",
"loc" : 0.5,
"pos" : "Left",
"order":1
},
"opt_2" :
{
"name" : "opt_2",
"dir" : "Bidirectional",
"loc" : 0.5,
"pos" : "Right",
"order":2
}
},
All port definitions follow a similar syntax. Information about each port is stored as a struct within a "ports" struct. Each struct contains fields which describe the name, type, and position of the port on the final model.
- name stores the name of the port, as a string.
- dir stores the port's directionality - either "Input", "Output" or "Bidirectional".
- pos describes which side of the final model the port will be placed on - either "Left", "Top", "Right", or "Bottom".
- loc gives the placement of the port on whichever side it's on, as a value between 0 and 1.
- order gives the order at which each port is listed in a netlist.
parameters (if applicable)
Most photonic models support one or more parameters which are visible to and editable by the end user. A simple example can be seen within the straight fixed waveguide template, which (by default) allows the end user to modify the waveguide length:
"parameters" :
{
"wg_length":
{
"name" : "wg_length",
"min": 0,
"max": 1.0,
"unit" : "um",
"default":1e-5,
"visible_to_user" : 1,
"annotate":0
},
...
}
For the waveguide_simple photonic model, this parameter can be modified to control how the end user will interact with the waveguide's length property. Changing the “name” field will change the name of the parameter as it's seen in INTERCONNECT, and changing the wg_length unit (e.g., the “unit” field) will modify the default unit which is used by INTERCONNECT to describe the . For example, these values are changed to look like:
"parameters" :
{
"wg_length":
{
"name" : "length_of_waveguide",
"min": 0,
"max": 1.0,
"unit" : "mm",
"default":1e-5,
"visible_to_user" : 1,
"annotate":0
},
...
}
Note: The value as the “default” should always be provide in SI units. In the example above, this value is provided in meters although the preferred user-facing unit is millimeters.
Then the final compact model within INTERCONNECT will have a parameter named "length_of_waveguide", with default units of millimeters, like so:
The parameter can also be made invisible, which is desirable when a parameter should be fixed, and not editable by the end user. This can be done by setting “visible_to_user” field to false.
model_data
The “model_data” struct stores all the data used to model the optical and electrical behavior of the element. This data contains numeric information about the element's performance, and is very specific to the type of element which is being modeled. More information about the data for each model type can be found in the data descriptions listed for each Lumfoundry Template.
FOMs (if applicable)
"FOMs" contains data that is required by CML Compiler to run quality-assurance tests on the final model. It is also optionally used by CML Compiler to fine-tune the internal model to provide the expected behavior.
If the source physical data provided for the model in “model_data” section is not consistent with the figures of merit (FOMs) provided (meaning the actual FOM values resulting from physical parameters differ from provided FOM data), the model can tune the provided physical data to match the FOMs to the provided values. For more information, seeTuning Active Compact Models.
More information about the FOMs for each model type can be found in the data descriptions listed for each Lumfoundry Template.
QA (if applicable)
This section contains settings for QA tests automatically generated by CML Compiler. These settings vary across different photonics models. More information about the QA settings for each model type can be found in the data descriptions listed for each Lumfoundry Template.
Statistical (if applicable)
This section contains the data required by CML Compiler to generate a statistical model. This struct contains two structs, “parameters” which stores all the information on statistical parameters that the user wants to enable for the model, and the “QA” struct which includes the QA settings for the statistical QA automatically generated by CML Compiler. For more information on statistical compact models, please see Introduction to statistical compact models.
For more information on the data required to statistically enable each model, please visit the data descriptions listed for statistical templates in Lumfoundry Template.