bbVariablePorts

Define an expression for a port prefix.
Use this field to define that some port names are dynamic, the working of which is not yet settled within the standard, so its availability is software dependent.
The properties will be used for all the ports apart from the label field, which should be the prefix per port and have a sequence 0..n, with n=count-1 being appended.
refIn and refOut shoud be used on the 0 ports only.

Structure

The attributes and elements are shown below, in a sorted per type fashion.
In case a list is printed after an element, it indicates that you can have many, otherwise it should be a single element. With a optional it tells the element is not required.

<bbVariablePorts  label="..."  org="..."  portCheck="..."  portMapToName="..."  refIn="..."  refOut="..."  refport="..." ... > ...
  <count> ... </count>
  <direction> ... </direction>    optional
  <doc> ... </doc>    optional
  <domain> ... </domain>    optional
  <drcAngles> ... </drcAngles>    optional
  <drcMaximumX> ... </drcMaximumX>    optional
  <drcMaximumY> ... </drcMaximumY>    optional
  <drcMinimumX> ... </drcMinimumX>    optional
  <drcMinimumY> ... </drcMinimumY>    optional
  <position> ... </position>    optional
  <radius> ... </radius>    optional
  <software> ... </software>    optional
  <tex> ... </tex>    optional
  <width> ... </width>    optional
  <xsection> ... </xsection>    optional
</bbVariablePorts>

XSD

The schema file can be downloaded or viewed at xPDK_BB.

Details

count

Type pdaExpression documentation:
Expression need to be commonly evaluated by many software, so having a restricted set of math / types and so on is key. In PDAFlow lib2/expr there is a yacc/lex parser available with some unit support as well as double / complex expressions. An alternative is tinyexpr, but this is more restrictive, so may be very unhandy for things like waveguide model expressions.

direction

Type pdaPortDirection documentation:
For photonics ports the signals are bi-directional - also the output of a laser acts as input in the sense that if you send in optical power there, you modify the laser performance. However for a designer it is a logical output.
The same holds for a 1:2 splitter - it has a single logical input and two logical outputs, otherwise you would call it a 2:1 combiner. The geometry can be the same in optics!
Allowed values: In, Out and InOut.

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.

domain

Type pdaDomain documentation: match for both building blocks.

Supported values:

Optical: optical signal, light is bi-directional for modelling.
RF: different styles exist like s / gsg / gssg and so on. For > few GHz.
DC: assuming for low(er) rate signals so including AC; so typical speeds to < 1 GHz
Signal
This value defines that any domain is acceptable, which is suitable for things like straight waveguides that are allowed in multiple xsection's and therefore can span multiple domains.
Geometric
This defines that the domain is just geometric, so no electrical or optical signal will go through it. Its purpose is thus for layout oriented software, but can also be used as port to connect a boundary to and thus simplify long equations you may otherwise need. See at the boundary, the portref/align documentation.

drcAngles

Type pdaDoubleList documentation: text (attribute or element).

drcMaximumX

drcMaximumY

drcMinimumX

drcMinimumY

label

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_])*

org

portCheck

Type portCheck documentation: This field can be used for the validation of re-parameterizing any → xPDK data flows. It is used by the pdk_reparam.xsl to fill the cmpPort() call, so typically have a ops_makePoint(..) or local variable reference in it.

portMapToName

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

position

Type pdaPosition3D documentation: in 3D, but as chip design needs only x & y and less angles only the x is required. The x, y and z are in micron, while the angles angle, pitch and roll are in degrees.

The x & y locations are for 2D / chip design.
The z coordinate is mostly oriented at Assembly Design Kits (ADK) but if different layer stacks are used on chip (regrowth, etching) it provides for vertical in-chip coupling.
The angle is the rotation in x/y plane and often used in all-angle photonics chip design.
The pitch is the angle off-chip and for chip design mostly for vertical fiber/chip coupling.
The roll is oriented at Assembly Design Kits (ADK) and not needed in chip design kits (PDK).

radius

Type pdaValue documentation: none, and value is the expression in the content. The difference with attributes is that they are more like annotation; basically key/value string to add more information in a software specified way.

refIn

refOut

refport

Type pdaPortReference documentation:

software

Type software documentation: Define the software versions to use with this PDK.
This information is used in the design manual creation but can be embedded in the software specific design kit also

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.

width

xsection

Type pdaXsectionReference documentation: