bbModulator
  Structure
  Details

---

  <pdaBBdefinition:DesignRule> ...  -tp->
  <pdaBBdefinition:GuiView> ...  -tp->
  <pdaBBdefinition:MRL> ...  -tp->
  <pdaBBdefinition:SpecView> ...  -tp->
  <pdaBBdefinition:TRL> ...  -tp->
  <pdaBBdefinition:WaiveReport> ...  -tp->
  <pdaBBdefinition:align> ...  -tp->
  <pdaBBdefinition:attribute> ...  -tp->
  <pdaBBdefinition:bbAnnotateFontSize> ...  -tp->
  <pdaBBdefinition:bbAnnotateName> ...  -tp->
  <pdaBBdefinition:bbDesignRule> ...  -tp->
  <pdaBBdefinition:bbFlexWrapper> ...  -tp->
  <pdaBBdefinition:bbWrapper> ...  -tp->
  <pdaBBdefinition:bbtype> ...  -tp->
  <pdaBBdefinition:boundary> ...  -tp->
  <pdaBBdefinition:changelog> ...  -tp->
  <pdaBBdefinition:doc> ...  -tp->
  <pdaBBdefinition:groupRef> ...  -tp->
  <pdaBBdefinition:icon> ...  -tp->
  <pdaBBdefinition:lastChangedDate> ...  -tp->
  <pdaBBdefinition:library> ...  -tp->
  <pdaBBdefinition:license> ...  -tp->
  <pdaBBdefinition:local> ...  -tp->
  <pdaBBdefinition:parameter> ...  -tp->
  <pdaBBdefinition:port> ...  -tp->
  <pdaBBdefinition:pxFactory> ...  -tp->
  <pdaBBdefinition:sptFooter> ...  -tp->
  <pdaBBdefinition:sptHeader> ...  -tp->
  <pdaBBdefinition:tex> ...  -tp->
  <pdaBBdefinition:ticket> ...  -tp->
  <pdaBBdefinition:version> ...  -tp->
  <pdaBBdefinition:view> ...  -tp->
  <pdaBBdefinition:xsection> ...  -tp->

bbModulator

Electro/thermo optical component (or other domain that modifies optical properties like chemical sensors or mechanical switches).
This group defines the BBs that have some non-optical influence that impacts the optical performance of the underlying m * n port component. Typical BBs are electro optic and thermo optic modulators which add to the 2 optical ports the 2 electrical ports. For the amount of electrical ports the speed is sometimes relevant too - for high speed (RF) often balanced or g/s/g ports are configured.

Structure

This element is simple - it does not have attributes or elements. The text that fills up the ... is value used.

---

<bbModulator  pdaBBdefinition:LayoutInterfaceArguments="..."  pdaBBdefinition:LayoutInterfaceBB="..."  pdaBBdefinition:LayoutInterfaceCondition="..."  pdaBBdefinition:LayoutInterfacePriority="..."  pdaBBdefinition:bbStyle="..."  pdaBBdefinition:bbox2path="..."  pdaBBdefinition:busConfigArguments="..."  pdaBBdefinition:busConfigElement="..."  pdaBBdefinition:dmPictSize="..."  pdaBBdefinition:exportclass="..."  pdaBBdefinition:mcsWrapper="..."  pdaBBdefinition:name="..."  pdaBBdefinition:noParameterRangeTest="..."  pdaBBdefinition:pcellFail="..."  pdaBBdefinition:pdkSelect="..."  pdaBBdefinition:portMapDC="..."  pdaBBdefinition:portMapDCi="..."  pdaBBdefinition:portMapDCo="..."  pdaBBdefinition:portMapIn="..."  pdaBBdefinition:portMapOut="..."  pdaBBdefinition:portMapRF="..."  pdaBBdefinition:portMapRFi="..."  pdaBBdefinition:portMapRFo="..."  pdaBBdefinition:symbolLibName="..."  pdaBBdefinition:symbolView="..."  pdaBBdefinition:symbolViewReorderPorts="..."  pdaBBdefinition:symbolViewTemplate="..."> ...   <pdaBBdefinition:DesignRule> ... </DesignRule>   list
  <pdaBBdefinition:GuiView> ... </GuiView>   list
  <pdaBBdefinition:MRL> ... </MRL>    optional
  <pdaBBdefinition:SpecView> ... </SpecView>   list
  <pdaBBdefinition:TRL> ... </TRL>    optional
  <pdaBBdefinition:WaiveReport> ... </WaiveReport>   list   optional
  <pdaBBdefinition:align> ... </align>    optional
  <pdaBBdefinition:attribute> ... </attribute>   list
  <pdaBBdefinition:bbAnnotateFontSize> ... </bbAnnotateFontSize>    optional
  <pdaBBdefinition:bbAnnotateName> ... </bbAnnotateName>    optional
  <pdaBBdefinition:bbDesignRule> ... </bbDesignRule>   list
  <pdaBBdefinition:bbFlexWrapper> ... </bbFlexWrapper>   list   optional
  <pdaBBdefinition:bbWrapper> ... </bbWrapper>   list   optional
  <pdaBBdefinition:bbtype> ... </bbtype>    optional
  <pdaBBdefinition:boundary> ... </boundary>   list
  <pdaBBdefinition:changelog> ... </changelog>   list
  <pdaBBdefinition:doc> ... </doc>   list
  <pdaBBdefinition:groupRef> ... </groupRef>   list
  <pdaBBdefinition:icon> ... </icon>    optional
  <pdaBBdefinition:lastChangedDate> ... </lastChangedDate>    optional
  <pdaBBdefinition:library> ... </library>    optional
  <pdaBBdefinition:license> ... </license>    optional
  <pdaBBdefinition:local> ... </local>   list
  <pdaBBdefinition:parameter> ... </parameter>   list
  <pdaBBdefinition:port> ... </port>   list
  <pdaBBdefinition:pxFactory> ... </pxFactory>   list   optional
  <pdaBBdefinition:sptFooter> ... </sptFooter>    optional
  <pdaBBdefinition:sptHeader> ... </sptHeader>    optional
  <pdaBBdefinition:tex> ... </tex>   list
  <pdaBBdefinition:ticket> ... </ticket>   list
  <pdaBBdefinition:version> ... </version>    optional
  <pdaBBdefinition:view> ... </view>   list
  <pdaBBdefinition:xsection> ... </xsection>   list
</bbModulator>

---

XSD

The schema file can be downloaded or viewed at xPDK_BB.

Details

Type bbPassive

This group is for passive component - until we have a better name.
This includes couplers, splitters, mode filters and so on. So any m * n port BB that has no driving / steering conditions (apart from maybe some thermal tuning for stability).

Type pdaBBdefinition

BB definitions including ports, parameters, attributes and views.

Basic fields

The following example shows the basic information that is expected (but not required). With this content you can start using it in different software. It does not define parameters, so it is a fixed design.
Normally BB's have more ports as well as parameters, so a "real" BB will be longer.

Documentation

Adding documentation is easy also, the doc is used by more software then the tex. tex is for long pieces of text like full help pages.

Alignment

A building block can be validated on angle - this is using the "org" port as coordinate reference.
You can select one of the following options: Manhattan, Xaligned, Yaligned, Angles as a series of values
Note that the global position of this is relevant; if you use the BB in your library and thus create a design hierarchy, the (relative) location inside the library netlist/component is not relevant.

Check definition

The xPDK format allows many aspects to be defined. To check that you defined it correctly, you can use the xsl files that convert the definition to the software of your choice.
A basic option is to use the gdspy project. The xsl/xPDK_toPython.xsl can use this library to generate the basic curves / black box designs. You can convert the BB.xml (as that includes the Layout.xml) in a simple script to generate a pdk.py.

xmllint --xinclude BB.xml | xmlstarlet tr $XPDK/xsl/xPDK_toPython.xsl -s pdkiteration=0 -s whitebox='nocell' > export/pdk.py

This (large) python file uses the xPDK Geometry.py and gdspy code jointly to allow the different boundary views, port locations and so on to be written to a GDS file or shown on screen.
Suppose you want to test the definition of a BB called myBB that has a paramter Length. Create a test.py with the following content:

from Geometry import Design
from pdk import *

myDesign=Design('/tmp/myBB.gds')
t=myBB()
t.Length=10
e0=t.place(myDesign,"element0",org=[0])
#e0.print_boundary()
t.Length=20
e1=t.place(dp,bir=e0.bol)
#e1.print_boundary()
#myDesign.draw_gdspy() # Just generate GDS
myDesign.draw_gdspy(show=True) # Show on screen
myDesign.write()

This should place two myBB's on the design, one with Length=10 and one with Length=20. The GDS file will depend on the type of BB (whitebox or not) and the -s whitebox='nocell' command line option. For black-box and grey-box BBs you should see two GDS cells, one per parameter setting.

DesignRule

Define a BB meta rule, so something that may not be auto-checkable. Type pdaDrcGeneralRule documentation: Define a design rule that is not layer or "polygon" / "geometric" based.
Design rules are available in different flavors, some of which can not be associated with layers; for example the name of the GDS cell that is required to be used for the design.
The rule is described in text and software may (or not) be able to implement them. Using the rule field gives designers an easy way to find more information on the DRC fail if it appears.

GuiView

Type pdaGuiView documentation: be have some additional remarks / special conditions. This field allows to define this.

LayoutInterfaceArguments

Type LayoutInterfaceArguments documentation: See also od:busConfigArguments for context; the epLayoutInterface resembles the od:BusConfig but is defined for Python.

LayoutInterfaceBB

Type LayoutInterfaceBB documentation: Define the BB mappings in the wxcfg class. It is ok to have multiple PDK elements map to the same wpcfg instance, for example depending on the wavelength band which is selected. The LayoutInterfaceCondition can then be used to select which version to pick, where the first is selected. Order is determined by LayoutInterfacePriority, highest is last.

LayoutInterfaceCondition

Type LayoutInterfaceCondition documentation: Set the selection mechanism for a multi-BB mapping. This can be as function call etc but then it should be somewhat language independent, so do not use self.X() but X() in python. The xsl code can prefix it with a class/instance scope.
You can use a reference to the technology definition, as tech.X(), for example for band-selection or enabled processes.

LayoutInterfacePriority

Type LayoutInterfacePriority documentation: Set the selection priority for a multi-BB mapping, lowest value is first.

MRL

Type pdaMRL documentation: Manufacturing Readiness Level (MRL) as defined by the EU.

SpecView

Type pdaSpecView documentation: for example a modulation depth or maximum modulation speed of a modulator. These are just for quick information for users. Typical values are insertion loss, modulation speed and so on.

TRL

Type pdaTRL documentation: Technology Readiness Level (TRL) as defined by the EU.

WaiveReport

Type WaiveReport documentation: Waive an issue in the Report.html

align

Building block placement validation.

This group is oriented at crystal / wafer alignment as for some BBs (like SOA and EAM) performance depends on crystalline alignment. Type pdaBBplacement documentation: Space seperated list of allowed global angles (in degrees) for the complete BB.

attribute

Type pdaAttributeType documentation: and views with information that is likely to be software specific. So it is more a 'flag' then a value. The value is just a string and not something with an expression in it.

bbAnnotateFontSize

Type bbAnnotateFontSize documentation:

bbAnnotateName

Type bbAnnotateName documentation:

bbDesignRule

Define a BB rule which can checked with some scripting language. Type pdaBBDrcScript documentation:

bbFlexWrapper

Type bbFlexWrapper 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).

bbStyle

This attribute can be used to mark a BB as whitebox; if not set to that value, a graybox (or blackbox) style should be used by the software.

• whitebox
  Write the BB in GDS as polygons and other shapes; the data will not be replaced / modified by the foundry. The data can be written with other whitebox and routing to a single GDS cell or spread over multiple GDS cells. It is also ok to write to a GDS cell and place instances based on the parameters.
• greybox
  The on-screen display represents the design to some extend, but the foundry will replace the cell. Therefore the software should write the content into a GDS cell.
  This mode is the normal style when using the boundaries to fill up some shapes. It provides for more options like automated design rule checking, visual validation and so on.
• blackbox
  Like a greybox, but with no shape information apart from the (outer) boundary.
• connector
  The data is for waveguide or electrical routing; the parameters of the cell are not describing the full shape as the start- and end-points (locations) are a key part of its definition. Connectors should not be put in GDS as cell's with multiple references to them based on having the parameters the same.

Type pdaBoxStyle documentation:

bbWrapper

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

bbox2path

Type bbox2path documentation: Specify that the shapes in the black-boxes BBs boundaries should be used to mark the 'path' property in OptoDesigner. This makes them suitable for the bus-routers.

bbtype

Optional type information that links to the compact model table. The type is an identifier to simplify cross-references.
This field defines applicable compact simulation models. This table is stored in a seperate XML file and/or can be included in the BB file itself. The value is a string that links to something like: which defines the compact models (CSM). This is likely to be defined between multiple foundry and software and thus not defined in the BB file itself, but xi:include in the BB file via:

<xi:include href="xPDK_CompactModel_List.xml" parse="xml" />

as shown.
Type pdaIdentifierExtended documentation:
Those names are mostly XML scope and thus for readability support more general naming then the pdaIdentifier.

boundary

The boundary field is for mask layout as well as on-screen display to avoid overlapping elements. Different shapes are available.
Type pdaBoundaryView documentation: aspect is the "geometric" boundary, but you can specify multiple regions with other aspects like "metal", "rf" or special optical exclusions and so on.
You can define as many boundaries as needed.

You can define a polygon (use point), a rectangle, circle or ellips now. Additional types will be added later.
Via the <spt> tag you can use OptoDesigner specific shapes also in case you want a white-box building block.

The "purpose" attribute set more details in case multiple boundaries are used. And the "xsection" can be used to use the xsection's to write to GDS, support DRC and so on.

busConfigArguments

Type busConfigArguments documentation: 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

busConfigElement

Type busConfigElement documentation:

changelog

Track changes to building blocks.
It is recommended for BB suppliers (foundry, design house, software, designer, ...) to track what changes over type in the definition. This helps in migrating designs to newer design kits, see what changed by designers and so on.
It is not required to do so.
Type xPDK_ChangeLog documentation: list, which can be empty. Software or design kit providers are not required to fill this data when changes are made, but it can help users to see what changed over time.

dmPictSize

Type dmPictSize documentation: Specify picture size (sml, mid, big) or use \sizepict{..} or something like that. It specifies the size of the BB picture in the design manual.

doc

Type pdaDocumentation documentation:
This field allows some (short, few lines) documentation to be written. It can be a long string, but the idea is not to replace a design manual.
This fields is like tex which allows documentation in LaTex format; doc is restricted to plain text.

exportclass

Export control & library

This element in the BB can be used for export control as some combinations need (legal) validation.
Without this attribute it is assumed to be a passive component. Type pdaDeviceType documentation: This information is intented for export control as some combinations of BBs need legal validation. Design software can validate the devicetype combinations that are used in the design and report on possible export regulations.

extend

Type AllowExtend documentation: Allows to extend with any (complex) data for enriching a design kit. The sub-data of an extend will normally be vendor or provider specific, but may span multiple software vendors or suppliers.

Provider extensions can be references to (or embedded) reporting scripts or their versions; source database references and so on. Such data is helpful in cross-referencing production issues or differences between export snapshots. Embedding such data in the XML rather then side-files enhances tracebility and reduces errors.

Using this section is not considered part of the xPDK format therefore, but as long as the files validate with the Stichting PDAFlow Foundation schema's, it is not considered a (not allowed) Derivative version.
For conventions, please check also Extensions.
See also xPDK License.

groupRef

Type pdaIdentifier documentation:
Identifiers are used in the Python library for the getName() and setName() function and can thus be used to identify the different elements in list s.
In text the specification is a letter, followed by letters, numbers, underscore. The XSD schema validation is a regular expression: [A-Za-z]([A-Za-z0-9_])*

icon

Icon’s can be fully embedded as base64 encoded data. This avoids the need for external file references.
Using files is possible also as shown with the filename statement. And calling some (software specific) functions can also be defined. The resolution of pictures should be high enough to allow good scaling in schematic designs. As such SVG is preferred.

Note: Pictures do not need to be square as for some BBs it is nicer using rectangular shapes.
Note: To keep the files “human editable” also, it is probably a good idea to have big pictures not embedded in the file, but referenced.
Type pdaPicture documentation: (use file) or file reference (so external file, use reffile) and for some software via function calls (use function).

lastChangedDate

This date allows a foundry to define the date that the BB really changed, so things like new layout, changes in layer stack and so on. Doing new measurements is not part of this.

The date is specified in the following form "YYYY-MM-DD" where:
YYYY indicates the year
MM indicates the month
DD indicates the day

library

The library defines a BB-grouping.

Defines the location in an library / element tree. In OptoDesigner it is used as dlgname and thus populates the Element dialog.

license

Specify license information if it differs from the PDK license scope.

This is typically not needed, but in some cases providers there may be IP restrictions from other parties involved or sub-licensing/restrictions for using this building block. Type pdaLicense documentation:
State the basic conditions of using the file and typically refer to legal documents.
License information should be compact enough to be clear as reference. The reference is expected to be to signed documents like Non Disclose Agreements (NDA) or service contracts and so on.

local

Type pdaNamedValue documentation:

mcsWrapper

Type mcsWrapper documentation: or something like that - it is a ml::setPort(this: label -> this@portMapToName );

name

Type pdaIdentifier documentation:
Identifiers are used in the Python library for the getName() and setName() function and can thus be used to identify the different elements in list s.
In text the specification is a letter, followed by letters, numbers, underscore. The XSD schema validation is a regular expression: [A-Za-z]([A-Za-z0-9_])*

noParameterRangeTest

Type noParameterRangeTest documentation:

• 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.

parameter

List of parameters (can be empty).

Parameters are named-values and can have an unit, type and value. The value is defined via an expression.
Parameters / globals and locals share the same style. A BB defining parameters with different constraints is shown here. It does not add the other information from the previous example to keep it focussed. Type pdaNamedValue documentation:

pcellFail

Type pcellFail documentation: This pcell fails in OptoCompiler PyCell; reason is listed in the string.
The BB definition needs to be fixed.

pdkSelect

Type pdkSelect documentation: Use in layout.xml's to have a single foundry database, where you select layer/xsection/.. sub-sets for a given PDK.

port

Ports define the connection points, see port definition. Type pdaPortDefinition documentation: Ports are the connection point for BBs and can be signal (schematic interfaces) and/or geometric-only (bounding box etc in OptoDesigner).
We want at least 1 port, otherwise we can not connect / place the instances. And as ports are key for connection, layout and simulation. Therefore a lot of information can be specified here.

Ports have a "per component" aspect (local coordinates) which typically depends on the parameters like widths and lengths of the BB. After placement on a chip/die these are then also associated with global coordinates. If the die is placed via Assembly Design Kit (ADK) suitable software like OptoDesigner these global coordinates are 6-axis values (x,y,z,y,yaw,pitch,roll) and thus incorporate both locations and angles in 3D.

Therefore the 'position' is supporting this capability also, with (for chip design) often unused "z" as well as the 3D angles pitch and roll.

Local port coordinates are assumed to be referenced to an implicitly defined "org" port, which is for Y-symmetrical devices (straight waveguide, simple MMIs, basic Yjunctions) often the "in0" port for easy calculation of output ports.
Use the org="true" attribute to specifiy a specific port is the [0,0,0,0,0,0] local position.

Use the refIn and refOut attributes to simplify element chain definitions; if they are not set, OptoDesigner will assume things instead, which is less robust. Per BB only a single port can be refIn or refOut, but the same port can be both.

Basic info

Values that are not specified are considered default; which is either “0” or specified in the xsd.

Design information

In addition to the locations & type, we need for photonics more things. Basic aspect is xsection which defined the design scope more precise, see the ​​ for the definition of these. Here they are references to this data.

Location design rule checks

For ports different logical rules may be needed to make sense on a layout. Typical info is either location or angle - for example an SSC in the middle of the design does not make sense.
It is also common to require crystal-axis alignment for active devices.

The min/max x/y are absolute coordinates for the chip design and have an origin that depends on the foundry - common values are to have the [0,0] at the lower-left of the design area or to have the [0,0] to be in the center of the design area. The former is most common, so the example below uses that.
As the foundry defines both the [0,0] and the coordinate checks, it is no problem to use a different setup - as long as they are consistent. An alternative for location based port checks it to annotate the Die-template with different zones like "SSC zone", "black box zone" and "die area zone" and use the enclosure test. This is a much more CPU-intensive test, but shrinks the amount of definitions per port or building block a lot.
Note: this is unlikely to be supported by schematic editors, who may support the port location test.

portMapDC

Type portMapDC documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapDCi

Type portMapDCi documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapDCo

Type portMapDCo documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapIn

Type portMapIn documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapOut

Type portMapOut documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapRF

Type portMapRF documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapRFi

Type portMapRFi documentation: Use the port label or label_rev to pick the direction; do not add numbers.

portMapRFo

Type portMapRFo documentation: Use the port label or label_rev to pick the direction; do not add numbers.

pxFactory

Type pxFactory documentation: Define a pxFactory map.
See OptoDesigner documentation.

sptFooter

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.

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

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.

sptHeader

Type sptHeader documentation: 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

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.

symbolLibName

Type symbolLibName documentation: Define the library to copy the symbol view from.
See symbolView.

symbolView

Type symbolView documentation: Define the symbol view to copy.
For pcells it is handy to start with an existing symbol view in the OA database. Using an existing view saves errors and makes life easier. The default library to search in is the photonicLib; you can use the symbolLibName to select another library. Another option is to use the symbolViewTemplate field to create a symbol view based on a template.

symbolViewReorderPorts

Type symbolViewReorderPorts documentation:

symbolViewTemplate

Type symbolViewTemplate documentation: Define the symbol view to use as basis.
When using this field, the OptoCompiler PDK will use this shape as template and generate the symbol based on the pre-defined template. This is an alternative of using the symbolView use.

tex

Type pdaTexDocumentation documentation: doc , but tex can be a long text in LaTex format to document the layer in more detail if needed.

You can document anything relevant for the topic you want to define.

Multiple paragraphs is fine. Format is Latex, so more complex content is possible.

ticket

Type pdaTicket documentation:

version

Optional version information.

To get an idea of the maturity of the BB design, you can add a lastChangedDate in the BB definition. It does not imply that it needs to have run on many wafers since that change. Another option to show this is the use of the version tag.
This tag defines the BB version, which can be different from the PDK version. If it is the same, best leave it out. Type pdaVersion documentation:
The version can be defined as:

• major.minor
  this is the short-hand version number. This can be a YYYY.MM (year.month) value also.
• major.minor.patch
  adds the patch to indicate small changes. This can be a YYYY.MM.DD (year.month.day) value also.
• major.minor.patch.iteration
  where the iteration is often relating to a (software) implementation and thus less typical in PDK or BB versions.
  It can be useful in the compact model files to indicate that the same measurements or simulations have received a new model instance.

A major number change indicates something big changed, while the minor is for more incremental changes. The patch indicates normally small data updates like new measurements.

view

General Views

Instead of defining a lot of somewhat hard-coded / fixed “views” on the “BB”, the PDAFlow concept of having BB's & View’s can be used also.

Note To keep the files “human editable” also, it is probably a good idea to have big simulation files not embedded in the file, but referenced, like xPDK Simulation

So allowing multiple “view”s - one that references side files and one that has it embedded can make life easier later on when the files are likely generated fully.

Having the option to add views is maybe not needed in combination with foundry / vendor extensions, but if we can use the same view by multiple parties, it saves effort and then makes sense to incorporate.
Type pdaView documentation: code this is handled with the object factories to automatically add them.

Views are defined in PDAFlow1 as C++ objects that can be created via an object factory. They can have arguments of any type, but not sub-views.
The idea of a view is to look at a building block / component in a flexible way, the view uses the information from the actual BB instance in a defined way; this can be things like layout, simulation as well as user interface aspects like icons, library references and so on.

xsection

Defines a valid xsection for the BB, you can define a series of them.

Some building blocks can be used in multiple xsections, typical examples are (straight) waveguides. Instead of defining many of these, one per xsection, it is easier to define one that allows to be defined in multiple xsections. List each of the allowed xsections in the BB section.
Consider for example an advanced SOI technology with 4 waveguide styles, 4 metal layers and 2 RF tracks - that would give 10 myStraight_<X>, which makes the library very big and unclear.

All port's of such a BB will be implicitly defined to be that xsection, unless defined in the port itself. Such an overrule is likely in things like TOPM's where the waveguide is for example DEEP/SHALLOW, but the electrical contact pads are allways DC.

BBs that support multiple xsections make life also much easier in more complex composites as you do not need to multiply your own library also. It may requires xsection dependent equations (things like phase, neff) which can be done easily via the xPDK expr library.

In case only a single xsection is allowed, typical for active elements like SOAs, then you should not use this field, but define all portbb_port's completely.
Type pdaXsectionReference documentation: