pdaBBProperty

Properties are ''return values'' of a BB based on its parameters. A typical property is a (geometric) path length, which can not be found for a black/grey box based on some polygon. But is key for optical modelling or path length matching.
Properties can be BB-scope or per port-pair. For a path-length property you can specify that the straight and/or arc waveguide models can be used for converting the geometrical path length into an optical one (useWGmodel=true).

Structure

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


<property  portFrom="..."  portTo="..."  useWGmodel="..."  pdaNamedValue:name="..."  pdaNamedValue:source="..."  pdaNamedValue:xsSpec="..."  pdaValue:allowedValues="..."  pdaValue:type="..."  pdaValue:unit="..."  pdaValueDouble:bbTestMax="..."  pdaValueDouble:bbTestMin="..."  pdaValueDouble:cpptype="..."  pdaValueDouble:doc="..."  pdaValueDouble:max="..."  pdaValueDouble:min="..."  pdaValueDouble:noParameterRangeTest="..."  pdaValueDouble:not0="..."  pdaValueDouble:nullable="..."  pdaValueDouble:pytype="..."  pdaValueDouble:spttype="..."  pdaValueDouble:test_accuracy="..."  pdaValueDouble:tex="..." ... > ... </property>

XSD

The schema file can be downloaded or viewed at xPDK_BB.

Details

Type pdaNamedValue

Type pdaValue

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.

Type pdaValueDouble

degrees for angles. The expression is in the content.

Type pdaExpression


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.

portFrom

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

portTo

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

useWGmodel

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

source

This information is relevant only in some specific cases so the recommendation is to avoid using it explictly in your definitions. It is primarily added to support the parameter to local conversion for BBs that have many parameters in the original definition but should have less in the design kit.
A typical example is thus the ipkiss to xPDK or spt to xPDK conversion where the full (whitebox) definition has many parameters of which only a few should be used by designers. The PDABBDEFINITION function param_to_local() can be used to mark this up, typically via the enrich.py. Type pdaValueSource documentation: The data in a final blueprint.xml can have multiple conversion / enrichment steps and in some cases it is
  • CheckUsage.
    A dialog should appear when using this BB in a design during 'export'; yes/no type of question. Only if 'yes' is selected should the export continue.
    'Export' can be a GDS tape-out or exchange of a design with others for example. The purpose is to avoid using the BB without some notification.
  • xsSpec

    The function part that you define as xsSpec is the part behind a (software specific) prefix. So values like Width, Radius or Length which map for OptoDesigner onto the mcsGetWidth() functions, see xPDK_toOptoDesigner_BBtest.xsl.

    allowedValues

    Type pdaStringList documentation: text (attribute or element).

    type

    Type pdaValueType documentation: expression is an extension to what the 'simple code' can do, but runs partly in xPDK:expr spt.
    The int, unsigned, double, point and complex are supported by the xPDK:expr supported.

    unit

    Type pdaUnit documentation:
    The use of units is strongly recommended to ensure that values are consistent between provider and user of data. The XSD schema allows a series of "basic units" with a * and / them. A basic unit uses the standard prefixes qryzafpnumckMGTPEZYRQ followed by its type and an optional ^. So a unit can be something like 1/cm*3kV/m^3/degree*dB
    A few additional names are added. You can use them with the common prefixes.

    bbTestMax

    the BB test files to make the design more clear, so not having bends with 359deg which are then shown as "racetrack". 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.

    bbTestMin

    the BB test files to make the design more clear, so not having bends with -359deg which are then shown as "racetrack". 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.

    cpptype

    Type epCppType documentation: In some cases we need more specific types in the expressions, mostly the ops_* things. This is the type for C++ in those cases.

    doc

    max

    rule checking or user interface aspects. 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.

    min

    rule checking or user interface aspects. 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.

    noParameterRangeTest

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

    not0

    within the optional range [min,max]. Give the exclusion range [-v,v] for the test. 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.

    nullable

    Type nullable documentation: This aspect is key in the epLayoutInterface.

    pytype

    Type epSptType documentation: In some cases we need more specific types in the expressions, mostly the ops_* things. This is the type for spt in those cases.

    spttype

    Type epSptType documentation: In some cases we need more specific types in the expressions, mostly the ops_* things. This is the type for spt in those cases.

    test_accuracy

    so if the parameter value needs more digits, set this to a lower value like 0.0001. 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.

    tex