xPDK schema format extensions for OptoDesigner This schema defines a few OptoDesigner extensions for different items.
The schema is located at: http://pdaflow.org/xsd/ per instance of the standard.

License for general users / automation / ...:
Use unmodified.
License for PDAFlow members:
Allow to extend / modify / update in alignment with the other PDAFlow members.

Vendor extension for OptoDesigner.
This section will be put at the start of a definition via XSLT.

Tech/02 definition

This section is copied into the '02' file at the start of the TechnologyPDKLIB class instance.
The typical use is waveguide mode models and other bigger spt sections that can then be used in the different sections.

pdaSingleLayerOPS

This section is copied into the '02' file below the (gds/mcs) layer definitions in the single-layer operation block. It is intended for more complex single/multi layer derived operations or DRC.

xsection

This section is copied into the '02' file below the mcs definition and is intended for more complex properties like waveguide models and so on.
It provides also for less common mcsSet*() functions or feeding them with values that xPDK does not support.

BB definition

This section is copied into the '04' file inside the layout definition and is intended for fine-tuning behavior, giving control over returned attributes and so on. In typical cases it is not needed.
Use this field in case the xPDK format does not have all the fields you need for your BB in OptoDesigner. For example this is possible for returning more layout attributes or supporting more complex design rule checking.

BB boundary

Tech/02 definition

This section is copied into the '02' file just before the function export()
The typical use is for backward compatability (for example mapping older mcs names) or some custom tech functions that need access to most of the tech-file.
Using this element instead of the TechFooter is easier in case of enriching the design kit via the C++ or Python library.

pdaSingleLayerOPS

This section is copied into the '02' file below the (gds/mcs) layer definitions in the single-layer operation block. It is intended for more complex single/multi layer derived operations or DRC.

xsection

BB definition

BB boundary

This section is copied into the '04' file into the layout itself and can be used to mark up complex boundaries. Also the use of multiple mcs/gds layers for DRC can be simpler this way.
Instead of using spt, you can also use the xsection for typical cases and reduce vendor dependence for this section.
Define an function for OptoDesigner.

This is vendor specific and can be defined as functor {functor #} or expression {a -> f(a)} style. These are used in the lengthening and widening of curves for example.
This section is copied into the '02' file just before the export() function and is intended for overriding functions of the base technology class.
The following attributes are possible

mcs: Define the default mcs - so what gets mask::CSselect()ed at the end of the technology class.
mcsDC: Define the default mcs for DC
mcsRF: Define the default mcs for RF

Define the default mcs - so what gets mask::CSselect()ed at the end of the technology class. Define the default mcs for DC; this is used for:

function getmcs_DC(){}.

Define the default mcs for RF; this is used for:

function getmcs_RF(){}.

This section is copied into the '02' file below the default header with the typical mask/die etc includes. The purpose of this is to define pcell libraries and other globals that are shared by 02 and 04 files, eg. for pdkexport() use. This section is copied into the '02' file as the design kit export function body, so you do not need the 'function export(..)'.
If this section is not in the PDK, it will add a default export function which you may need to modify if you use the TechGlobals section with pcellLibraries or other things you need in the export. This section is copied into the '02' file below the export() function and is intended to register the pxBB's mapping into the pxFactory.Register() tables to support foundry independent designs. This section contains the die-template definition which is put in the '04' file. The die-template should define form-factors, typical IO locations, dice line or cleave markers and so on.
When using the examples, this section will be placed before the DieExtends section. This section contains the die-template instance/use, which is copied into the code-snippets but will also used for the examples to define a basic die.
It is therefore good to pick defaults like die-sizes that support the examples directly. This allows to define an example for the technology. You can use xslt to select one of them by using the example name and create a self contained spt example file.
This is handy to validate design rules or re-generate designer examples when new die-templates or additonal options are used. Specify that the #include @mask/file will be added to the OptoDesigner 02-file/
This library suppport operations on mask files and is needed also for loading GDS-based BB/cell definitions from a design kit. If BBs have a boundary with a gds cell in them, you do not need to set this value to true - it will automatically add it. You can use this field to define the coating options.
For edge-coupled fibre/chips (typically with SSCs) you normally have different coating options provided by the foundry. In case you use InP or other active materials, you may also have special handling for laser facets.
If you use this field, then the OptoDesigner tech file will setup the coating options and write the designer spec in a side file. You can define which sides support coating; not setting the field will block coating for that edge.
For typical packaging rules (like defined by Europe's PIXAPP Pilot Line service) only West (typical photonics edge) and East (either photonics or RF) are the edges to use; with North and South for use by electrical (lower speed, few GHz) connections.
The values should be a list of names, seperated by a ,, so AR, NO,HR. The names are free, but preferred naming is:

NA Not Applicable - the designer does not care
NO No coating
AR Anti-reflection coating
HR High-reflection coating

Coating specification for West side Coating specification for East side Coating specification for North side Coating specification for South side Specify that the pcellMaskEngineer_Library will be added to the OptoDesigner 02-file/
This pcell library will be used in the BBs to generate a spt-based side-file for mask assembly. Specify that the path length library will be added to the OptoDesigner 02-file/
This pcell library will be used within the OptoCompiler fast server code. Select the GDS layer that is used for marking the electrical pin. Layer annotation used in XSL to generate an OptoDesigner Tech/02 file.
OptoDesigner extension, mark this layer as 'non data' for a "data inside die/design area" test. Layer annotation used in XSL to generate an OptoDesigner Tech/02 file.
OptoDesigner extension, mark this layer as "die/design area". gds annotation used in XSL where the mcsAnnotateBoundary can not be used for autoXsection=false setting. MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
OptoDesigner extension, use this xsection/mcs for the BB/pcell name in xpdkAnnotator(). MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
OptoDesigner extension, use this MCS for the BB/pcell name in xpdkAnnotator(). MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
OptoDesigner extension, use this MCS for BB/pcell parameters in xpdkAnnotator(). MCS annotation for text in BB/pcell/04 file.
Extension, use this MCS for plain text. MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
OptoDesigner extension, use this MCS for BB/pcell ports in xpdkAnnotator(). This layer is used for the port name and properties. MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
OptoDesigner extension, use this MCS for BB/pcell ports in xpdkAnnotator(). This layer is used for a rectangle that indicates the width of the port. MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
Tag optical port in this layer via rectangle. MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
Tag DC port in this layer via rectangle. MCS annotation used in XSL to generate an OptoDesigner BB/pcell/04 file.
Tag RF port in this layer via rectangle. BB annotation used in XSL to generate an OptoDesigner BB/pcell/04 file. Font size to use for masktext in um. Configure the arguments of a bus-routing component.
Obsolete, the LayoutInterfaceArguments is now used for both python and spt.
The OptoDesigner bus-router simplifies complex (delay based) routing. It needs a few different BBs to be setup per PDK, which can be generic waveguide curves also.
For the argument/order you can look in the /*default:*/ below, which shows the curve that is used if you do not overrule it. wwg is the configured waveguide width for the bus.

 // create straight in some way, must support a port/port spec via L=null
 abstract layout straight(double L nullable UnitInfo "micron") TexDoc "Create a straight waveguide";
    /*default:*/ ml::Straight( cin->this@in0,cout->this@out0 : wfix(wwg), L == null?null:max(0,L));

 // create taper in some way, L=null allows sub-class to spec it
 abstract layout taperToBus(double win UnitInfo "micron",double L nullable UnitInfo "micron") TexDoc "Width taper";
    /*default:*/ ml::Straight( cin->this@in0,cout->this@out0 : wlin(win,wwg), L);

 // create taper in some way, L=null allows sub-class to spec it
 abstract layout taperFromBus(double wto UnitInfo "micron",double L nullable UnitInfo "micron") TexDoc "Width taper";
    /*default:*/ ml::Straight( cin->this@in0,cout->this@out0 : wlin(wwg,wto), L);

 // create 90deg bend in some way
 abstract layout bend90(int up RangeSpec[-2,2]) TexDoc "Manhattan bend style";
    /*default:*/ ml::BendPolar( cin->this@in0,cout->this@out0 : wfix(wwg), wwr, up*90);

 // create 180deg bend in some way
 abstract layout bend180(int up RangeSpec[-2,2]) TexDoc "Manhattan bend style";
    /*default:*/ ml::BendPolar( cin->this@in0,cout->this@out0 : wfix(wwg), wwr, up*180);

 // create some bend
 abstract layout bend(double r UnitInfo "micron",double a UnitInfo "Degree") TexDoc "General bend";
    /*default:*/ ml::BendPolar( cin->this@in0,cout->this@out0 : wfix(wwg),r,a);

The string data is the argument for the PDK bb element based on the mapping from above. In addition to the (very few) arguments of the layout's above, you can use:

 final function getWidth()  TexDoc "Return width"

 final function getRadius() TexDoc "Return radius"

 final function getDistance() TexDoc "Return wg/wg distance"

 final function getDistanceCenterCenter() TexDoc "Center - center distance of 2 waveguides"

 final function getTaperAngle()  TexDoc "Return default angle for tapers"

For the busConfigElement arguments: L,win,wbus

straightL,wwg
taperToFromBusL,wext,wbus; use the argument order for the ``into'' the bus; the widths will be reversed for the out-going taper
bend90up,wwr,wwg
bendr,a,wwg

BB annotation used in XSL to generate an OptoDesigner BB/pcell/09 file.
This field is superseded by the epi:LayoutInterfaceBB, which extends this with more values. The busConfigArguments is used for the OptoDesigner spt, also for the epi:LayoutInterfaceBB. MCS annotation used in XSL to generate an OptoDesigner bus config 09 file.
This boolean can be set to true to set up a curve-based bus-config for this xsection in case no BBs are set up for bus-routing for this xsection.
Using this value is not needed if there is at least a single BB configured for being a busConfig-element for this xsection; in that case the other non-specified layout's are automatically configured using basic OptoDesigner curves. Use this at xPDK_BB or BB level to mark output ports to be mapped to in* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to out* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to dc* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to dc* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to dci* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to dco* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to rfi* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at xPDK_BB or BB level to mark output ports to be mapped to rfo* ports.
Use the port label or label_rev to pick the direction; do not add numbers. Use this at port level to map to a standard name. You can add a +[0,0,180] or something like that - it is a ml::setPort(this: label -> this@portMapToName ); Use this at port level to map to a standard name. You can add a +[0,0,180] or something like that - it is a ml::setPort(this: label -> this@portMapToName ); Specify an earlier name for this xsection; it is intended for backward compatability and thus to slowly be dropped from the design kit. Define that this BB replaces another one.
Due to PDK changes, older BBs may need migration to new ones. Using this field allows to define at the definition of the new BB the mapping from the old one. You can change parameters and ports.
Remove the old BB from the PDK, a new definition will be added which gives the replace by.. type of message on its use. This allows designers to quickly migrate their design.
You can use the optional (plain) text content for additional information. The arguments of the old BB definition, so used in the layout header. Arguments used in the call to the new BB If not in0/out0, set as string "dc0","dc1" or something like that. The ports used for connecting the new and old element. this is the old element. Name of the BB that will be wrapped. Define the scope of the wrapper; typically this is migrate, which gives a drc::Warn() and calls the new BB. After a longer while, it can be set to fail to indicate it will be removed from the design kit later on.
Use pass to avoid the warnings and simply call the new one behind the scenes.
pxfactory can be used to change / add arguments compared to the pxFactory definitions of elements. It acts as a pass flag, but is more specific in its purpose.
For 'pass', 'pxfactory' and 'migrate' the BB will appear in the element dialog under the foundry; for 'fail' it will be hidden. Code before Code after Use this at xPDK_Layout level to mark that this PDK is intended for use with ADKs.
The ADK-option for the PDK adds additional xsection / layers in to the design kit to work with typical ADKs. The black/grey-box cells will get this prefix. If not set, then the fabacronym in upper case is used. Define a pxFactory map.
See OptoDesigner documentation. Define Flex-wrapper.
The BB's flex-wrapper is used for standardizing the port names (mask::setLayoutPort()) so we can use them consistently in the bus-routers, back-annotation of layouts back into schematic (for pose-layout simulation).
Code before the layout_extends() Code after the layout_extends(), before mask::port2layout() If used, it will drop the equation below the layout_extends() and before the sptFooter() as a
this{"centerPathLength"}=..
Use if you want the in/out swapped BB also; this is typical for waveguide transitions. The building blocks will normally be tested with:

Default value for all parameters
Iterate through the parameters;
- if min or max value defined, then use those to place more instances

This provides for a convenient non-default value testing also, however it may be that those parameter combinations are not valid. Per parameter the min/max may work, but it can be that the minimum of one parameter requires a non-default value for another one.
Setting this property in the BB definition allows to define such a test pattern, for now this is not yet used, so any string is fine. Mark this parameter as allowed to be empty or null.
This aspect is key in the epLayoutInterface.