bbWrapper

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.

Structure

This element does not have elements. The attributes are shown below, in a sorted per type fashion.

<bbWrapper  bb="..."  instargs="..."  layoutargs="..."  ports="..."  scope="..."  setLayoutPort="..."  sptFooter="..."  sptHeader="..." ... > ... </bbWrapper>

XSD

The schema file can be downloaded or viewed at xPDK_OptoDesigner.

Details

bb

Name of the BB that will be wrapped. Type bb documentation:

instargs

Arguments used in the call to the new BB

layoutargs

The arguments of the old BB definition, so used in the layout header.

ports

The ports used for connecting the new and old element. this is the old element.

scope

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. Type scope documentation:

setLayoutPort

If not in0/out0, set as string "dc0","dc1" or something like that.

sptFooter

Code after Type sptFooter documentation: This section will be put at the end of a definition via XSLT.

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.

Download the xsl/xml/xsd's and run the (bash) command line below to convert the XML to a SPT example in OptoDesigner (see short docu):

xsltproc --xinclude -stringparam standalone true -stringparam example drc0 xPDK_toOptoDesigner02.xsl layer_singleSpt.xml
full file
  <layer name="layer1">
    <gds_number>1</gds_number>
    <gds_datatype>0</gds_datatype>
    <grid>0.001</grid>
    <purpose>Waveguide layer</purpose>
    <color R="100" G="200" B="255"/>
    <visible>true</visible>
    <fillstyle>open</fillstyle>
    <linestyle>fill</linestyle>
  </layer>
  <layer name="layer2">
    <gds_number>2</gds_number>
    <gds_datatype>0</gds_datatype>
    <grid>0.001</grid>
    <purpose>Waveguide layer</purpose>
    <color R="255" G="20" B="20"/>
    <visible>true</visible>
    <fillstyle>open</fillstyle>
    <linestyle>fill</linestyle>
    <SingleLayerOps>
      <od_sptFooter>
      // println("hi");
    </od_sptFooter>
    </SingleLayerOps>
  </layer>
Spt:

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.
full file

 <xsection name="WG">
  <od_sptHeader>// This section does some special OptoDesigner things.
   mcsSetCurveCheck();
   mcsSetAltWG("WGhigh","WGlow");
  </od_sptHeader>
 </xsection>

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.

full file
<bb name="myBB">
 <port label="in0">
  <position>
     <x>0</x>
  </position>
 </port>
 <od_sptFooter>
  ml::Straight(cin-> this@in0:wfix(1),20) elm;
  this{"elm"}=elm;
  this{"L"}=20;
 </od_sptFooter>
</bb>

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.
full file

<bb name="myBB">
 <port label="in0">
  <position>
     <x>0</x>
   </position>
 </port>
 <boundary>
  <od_sptHeader>
   ml::Straight(cin-> this@in0 : wopar(1,3),20);
  </od_sptHeader>
 </boundary>
</bb>

sptHeader

Code before Type sptHeader documentation: