xPDK_layer
GDS/Oasis/OpenAccess layer definitons including some user interface related properties. There are a series of common DRC rules available also.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.
<xPDK_layer autoXsection="..." gdsAnnotateBoundary="..." isKeyLayer="..." layerIgnoreAsData="..." layerIsDieArea="..." maskNumber="..." mcsAnnotateBoundary="..." mcsAnnotateCellName="..." mcsAnnotateParameter="..." mcsAnnotatePinDC="..." mcsAnnotatePinInfo="..." mcsAnnotatePinOptical="..." mcsAnnotatePinRF="..." mcsAnnotatePinSize="..." mcsAnnotateText="..." mcsAnnotateWaveguide="..." mcsMigrate="..." pdkSelect="..." techIncludeElectricalTag="..." techLayerFunction="..." techLayerID="..." techLayerRouting="..." techPurpose="..." pdaGDSlayer:name="..." ... > ...
<DesignRule> ... </DesignRule> list
<MRL> ... </MRL> list
<TRL> ... </TRL> list
<WaiveReport> ... </WaiveReport> list
<color> ... </color> list
<doc> ... </doc> list
<drcAngleCheck> ... </drcAngleCheck> list
<drcConvex> ... </drcConvex> list
<drcFixedRadius> ... </drcFixedRadius> list
<drcFixedWidth> ... </drcFixedWidth> list
<drcGlobalDensity> ... </drcGlobalDensity> list
<drcLocalDensity> ... </drcLocalDensity> list
<drcMaxArea> ... </drcMaxArea> list
<drcMaxLength> ... </drcMaxLength> list
<drcMaxRadius> ... </drcMaxRadius> list
<drcMaxSpace> ... </drcMaxSpace> list
<drcMaxVertices> ... </drcMaxVertices> list
<drcMaxWidth> ... </drcMaxWidth> list
<drcMinArea> ... </drcMinArea> list
<drcMinCornerSpacing> ... </drcMinCornerSpacing> list
<drcMinCornerWidth> ... </drcMinCornerWidth> list
<drcMinLength> ... </drcMinLength> list
<drcMinNotch> ... </drcMinNotch> list
<drcMinRadius> ... </drcMinRadius> list
<drcMinSpace> ... </drcMinSpace> list
<drcMinVertices> ... </drcMinVertices> list
<drcMinWidth> ... </drcMinWidth> list
<drcNoOverlap> ... </drcNoOverlap> list
<drcShortEdgeCheck> ... </drcShortEdgeCheck> list
<drcSingularPoint> ... </drcSingularPoint> list
<fillstyle> ... </fillstyle> list optional
<groupRef> ... </groupRef> list
<layerAnd> ... </layerAnd> list
<layerAnotB> ... </layerAnotB> list
<layerAnotBnotC> ... </layerAnotBnotC> list
<layerCount> ... </layerCount> list
<layerGrow> ... </layerGrow> list
<layerHeal> ... </layerHeal> list
<layerIsCoveredBy> ... </layerIsCoveredBy> list
<layerNot> ... </layerNot> list
<layerOffset> ... </layerOffset> list
<layerOr> ... </layerOr> list
<layerScript> ... </layerScript> list
<layerSelect> ... </layerSelect> list
<layerShrink> ... </layerShrink> list
<layerSize> ... </layerSize> list
<layerSnap> ... </layerSnap> list
<layerTrench> ... </layerTrench> list
<layerXor> ... </layerXor> list
<linestyle> ... </linestyle> list optional
<masksupplier> ... </masksupplier> list
<module> ... </module> list
<polarity> ... </polarity> list
<purpose> ... </purpose> list
<sptFooter> ... </sptFooter> list
<sptHeader> ... </sptHeader> list
<techLayerConnection> ... </techLayerConnection> list
<tex> ... </tex> list
<ticket> ... </ticket> list
<visible> ... </visible> list optional
<pdaGDSlayer:gds_datatype> ... </gds_datatype>
<pdaGDSlayer:gds_number> ... </gds_number>
<pdaGDSlayer:grid> ... </grid> optional
</xPDK_layer>
XSD The schema file can be downloaded or viewed at xPDK_Layout.
Details
Type pdaGDSlayer
etc. In addition to the basic layer info, there is typical design rule definitions (min/max width, space etc) and derived layers (grow, size, not, xor, ...).For creating design kits the user interface aspects are mostly optional so you you should think about suitable defaults for colors, visibility and display styles in case the preferred values are not set by the foundry. In such cases you can probably edit the respective file(s) and extend the design kit with those values in alignment with the foundry. This will enrich the design kit while making it more likely to display consistently in different software.
- color is a RGB value
- visibility is a boolean - visible or not
- line style
- fill style
Basic definition
<layer name="layer1">
<gds_number>1</gds_number>
<gds_datatype>0</gds_datatype>
<grid>0.001</grid>
<purpose>Waveguide layer</purpose>
<color R="10" G="20" B="30"/>
<visible>true</visible>
<fillstyle>open</fillstyle>
<linestyle>fill</linestyle>
<extend>
<!-- Show extension -->
<myprop>1</myprop>
</extend>
</layer>
DesignRule
Define a 'meta rule', so non-geometric. 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.
MRL
Type pdaMRL documentation: Manufacturing Readiness Level (MRL) as defined by the EU.TRL
Type pdaTRL documentation: Technology Readiness Level (TRL) as defined by the EU.WaiveReport
Type WaiveReport documentation: Waive an issue in the Report.htmlautoXsection
Define this GDS layer as xsection automatically also, set this to false if you do not want this.If true then this GDS layer can be used as xsection directly also, with a 1:1 grid and little information attached to it. Default is true and you need not specify this.
This flag is used in xPDK_toOptoDesigner02.xsl to disable some GDS layers to be mapped onto mcs's.
Note The XSD schema 1.0 can not handle this attribute selection in the xsection/layer search; it is therefore not validated that layers with autoXsection=false are not used in xsection-references.
color
Use a RGB color for the default settings in software; this is intended to have more consistent look over different software. Type pdaColor documentation: Each of R, G and B is required and be between 0 and 256.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.drcAngleCheck
Type pdaDrcAngleCheck documentation: Define angular DRC check.drcConvex
Type pdaDrcLayerNoArgument documentation: Define a single layer DRC test without argument.drcFixedRadius
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcFixedWidth
Type pdaDrcLayerArgumentDirection documentation:drcGlobalDensity
Type pdaDrcGlobalDensity documentation: Single layer DRC check on global density.drcLocalDensity
Type pdaDrcLocalDensity documentation: Single layer DRC check on local density.drcMaxArea
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMaxLength
Type pdaDrcLayerArgumentDirection documentation:drcMaxRadius
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMaxSpace
Type drcMaxSpaceType documentation: Validate the space between the center of (healed) polygons.drcMaxVertices
Type pdaDrcLayerUnsignedArguement documentation: Define a single layer DRC test with unsigned-int as argument.drcMaxWidth
Type pdaDrcLayerArgumentDirection documentation:drcMinArea
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMinCornerSpacing
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMinCornerWidth
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMinLength
Type pdaDrcLayerArgumentDirection documentation:drcMinNotch
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMinRadius
Type pdaDrcLayerArgument documentation: Define a single layer DRC test with argument.drcMinSpace
Type drcMinSpaceType documentation: Validate the space between the center of (healed) polygons.Value is the minimum space (um) between the centers.
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_drcMinSpace.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>
<SingleLayerOps>
<drcMinSpace value="2">DRC</drcMinSpace>
</SingleLayerOps>
</layer>
Spt:
drcMinVertices
Type pdaDrcLayerUnsignedArguement documentation: Define a single layer DRC test with unsigned-int as argument.drcMinWidth
Type pdaDrcLayerArgumentDirection documentation:drcNoOverlap
Type pdaDrcLayerNoArgument documentation: Define a single layer DRC test without argument.drcShortEdgeCheck
Type pdaDrcShortEdgeCheck documentation: Define short-edge DRC check.drcSingularPoint
Type pdaDrcLayerNoArgument documentation: Define a single layer DRC test without argument.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.
fillstyle
Set fillstyle (polygon area) default settings in software; this is intended to have more consistent look over different software.Fillstyle is default unfilled. Type pdaFillStyle documentation:
FILL
filled - used in OptoDesignerNOFILL
not filled - used in OptoDesignerSOLID
Solid style.DOT
Dotted style.LONG_DASH
Long dashed style.SHORT_DASH
Short dashed style.DOT_DASH
Dot and dash style.TRANSPARENT
not filled - used in OptoDesigner.STIPPLE
Use the stipple style.BDIAGONAL_HATCH
Backward diagonal hatch.CROSSDIAG_HATCH
Cross-diagonal hatch.FDIAGONAL_HATCH
Forward diagonal hatch.CROSS_HATCH
Cross hatch.HORIZONTAL_HATCH
Horizontal hatch.VERTICAL_HATCH
Vertical hatch.
gdsAnnotateBoundary
Type gdsAnnotateBoundary documentation: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_])*
isKeyLayer
Type isKeyLayer documentation: Specify that this layer should go to the DM 4.1 table.layerAnd
Type pdaOPSdual documentation: A base class for multi-layer operations with target layer.You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Attributes:
- A: source layer
- B: source layer
layerAnotB
Type pdaOPSdual documentation: A base class for multi-layer operations with target layer.You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Attributes:
- A: source layer
- B: source layer
layerAnotBnotC
Type pdaOPStriple documentation: A base class for multi-layer operations.You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Attributes:
- A: source layer
- B: source layer
- C: source layer
layerCount
Type pdaOPSlayerCount documentation: Count amount of polygons in layer.layerGrow
Type pdaOPSlayerGrow documentation: Single layer GROW operation.layerHeal
layerIgnoreAsData
Type layerIgnoreAsData documentation: OptoDesigner extension, mark this layer as 'non data' for a "data inside die/design area" test.layerIsCoveredBy
Type pdaOPSisCoveredByLayer documentation: Store partly/not/fully/partly_including/partly_excluding part of object layer definition.This is a complex operation that stores the covered objects contour for the list of In layers.
You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Sub elements:
In is the list of input layers.
Cover is the list of cover layers.
how defines the style (partly/not/fully/partly_including/partly_excluding); default is partly.
healOutput defines whether a heal operation should be done or not to keep the individual pieces.
layerIsDieArea
Type layerIsDieArea documentation: OptoDesigner extension, mark this layer as "die/design area".layerNot
Type pdaOPSLayerNot documentation: Single layer NOT operation.layerOffset
Type pdaOPSoffsetLayer documentation: Offset layer.This is a complex operation that creates an offset contour for the list of In layers. Different grow shapes can be used, detault is ellipse.
You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Sub elements:
In is the list of input layers.
dist is the distance for the offset (in um), default 0.1.
how defines the style (ellipse, miter, rectangle).
layerOr
Type pdaGDSlayerReferenceList documentation:layerScript
Type pdaOPSinLayer documentation:layerSelect
Type pdaOPSselectLayer documentation: Store part of object layer definition.This is a complex operation that stores the covered objects contour for the list of In layers.
You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Sub elements:
In is the list of input layers.
Compare is the list of cover layers.
how defines the style (covering | in | inside | interacting | not_covering | not_in | not_inside | not_interacting | not_outside | not_overlapping | outside | overlapping); default is covering.
healOutput defines whether a heal operation should be done or not to keep the individual pieces.
layerShrink
Type pdaOPSlayerShrink documentation: Single layer SHRINK operation.layerSize
Type pdaOPSlayerSize documentation: Single layer SIZE operation.layerSnap
Type pdaOPSlayerSnap documentation: Single layer SNPA operation.layerTrench
Type pdaOPSlayerTrench documentation: Tgt=Trench | (Clad & ! Core)Define a trench operation; Tgt=Trench | (Clad - Core).
The operation is called "trench" as it is often used for waveguide trench definitions, where you draw the "core" but need to get the "trench" in GDS output. Widening the "core" to "clad" and invert will give you the "trench". This is simple to do with the xsection definition and using multiple maps. The boolean operation that combines the output is then this trenching operation.
<xsection name="wg">
<grid>
<map>core</map>
<mag widen="5">clad</map>
</grid>
</xsection>
You can use it for other operations where you need a: "direct write" or (A - B).You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Attributes:
- Core: source layer
- Clad: source layer
- Trench: source layer
layerXor
Type pdaOPSdual documentation: A base class for multi-layer operations with target layer.You can use the elements doc and tex to document the operation. This is often useful for later changes as the logic behind complex chains of operations is often not easy to follow by colleques and/or partners.
Attributes:
- A: source layer
- B: source layer
linestyle
Set linestyle (polygon contour) default settings in software; this is intended to have more consistent look over different software.Linestyle is default filled. 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_])*
maskNumber
Type maskNumber documentation: Define tech maskNumber.This number somewhat reflects the layerstack and is used in LVS. The lower numbers should be the lower layers in the chip. The range does not need to be continous.
masksupplier
Define the (list of) suppliers for this mask and/or other ordering information like mask-grade, style (laser beam or ebeam) and so on.This field can be any string, for example a reference to the (foundry) internal supplier database. It allows the xPDK layout file to contain all mask related information the foundry needs.
This field is not used by OptoDesigner.
mcsAnnotateBoundary
Type mcsAnnotateBoundary documentation: OptoDesigner extension, use this xsection/mcs for the BB/pcell name in xpdkAnnotator().mcsAnnotateCellName
Type mcsAnnotateCellName documentation: OptoDesigner extension, use this MCS for the BB/pcell name in xpdkAnnotator().mcsAnnotateParameter
Type mcsAnnotateParameter documentation: OptoDesigner extension, use this MCS for BB/pcell parameters in xpdkAnnotator().mcsAnnotatePinDC
Type mcsAnnotatePinDC documentation: Tag DC port in this layer via rectangle.mcsAnnotatePinInfo
Type mcsAnnotatePinInfo documentation: OptoDesigner extension, use this MCS for BB/pcell ports in xpdkAnnotator(). This layer is used for the port name and properties.mcsAnnotatePinOptical
Type mcsAnnotatePinOptical documentation: Tag optical port in this layer via rectangle.mcsAnnotatePinRF
Type mcsAnnotatePinRF documentation: Tag RF port in this layer via rectangle.mcsAnnotatePinSize
Type mcsAnnotatePinSize documentation: 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.mcsAnnotateText
Type mcsAnnotateText documentation: Extension, use this MCS for plain text.mcsAnnotateWaveguide
Type mcsAnnotateWaveguide documentation: This information is intended for Layout-vs-Schematic (LVS) with ICvalidator in OptoCompiler.mcsMigrate
Type mcsMigrate documentation: and thus to slowly be dropped from the design kit.module
Specify which proces module adds this layer. 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_])*
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.polarity
Define the polarity of the mask.This field is only allowed once and should be one of DF, LF, DarkField, LightField. Type pdaMaskPolarity documentation: Type of mask plate.
purpose
Thepurpose
is a (short, single line) text describing the purpose of the layer in the foundry.Expected is a single liner.
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.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.
<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.
<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.
<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
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.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.
<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.
<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.
<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>
techIncludeElectricalTag
Type techIncludeElectricalTag documentation: Specify that the electrical tag 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.
techLayerConnection
Type techLayerConnection documentation: Define OA-Tech layer connection.This field can be used to link layers and/or xsections; this tells that routing-wise ('design intent') they are directly connecting, possibly with a byLayer value.
You can define the connection in either layer/xsection, no need to define it twice.
For layer/xsection's that connect to more than one, define them from one layer, otherwise multiple lines will be written in the tech file.
Only use this for layers that have at least one of techLayerRouting='true' or techIncludeElectricalTag='true'.
techLayerFunction
Type techLayerFunction documentation: Define the function value in OptoCompiler tech file, section 'function'techLayerID
Type techLayerID documentation: Define OA-Tech ID.The OA Tech file needs to have unique numbers that are PDK version constant for design migration. The default behavior is use to use for layer definitions 65536*gds_number+gds_datatype and for the xsection the value 10000+N with N being the index in the xsection list.
Those values are very likely to be unique per PDK, but the xsection numbers are unlikely to be PDK version constant (adding or removing xsection's will fail this).
You can overrule the Tech ID with this field; the range is 256-10000 to avoid overlapping the default range. The number is free within this range, but as guideline:
- 1000 - 1999 use this range for optical layers
- 2000 - 2999 use this range for electrical layers
- 3000 - 3999 use this range for mask annotations
- 4000 - 4999 use this range for LVS recognition
techLayerRouting
Type techLayerRouting documentation: Mark for routing in in OptoCompiler tech file, section 'constraintGroups'techPurpose
Type techPurpose documentation: Define the 'OpenAccess' purpose for a layer.This will be used in writing to the tech-file and if a layer does not have it specified, it will be used as drawing.
You can add your own values in addition to the standard provided names:
- redundant
- gapFill
- annotation
- OPCAntiSerif
- OPCSerif
- slot
- fill
- drawing
- fatal
- critical
- soCritical
- soError
- ackWarn
- info
- track
- blockage
- warning
- tool1
- tool0
- label
- flight
- error
- annotate
- drawing1
- drawing2
- drawing3
- drawing4
- drawing5
- drawing6
- drawing7
- drawing8
- drawing9
- boundary
- pin
- net
- cell
- all
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:visible
Set visibility default settings in software; this is intended to have more consistent look over different software.gds_datatype
specify the gds details. The combination should be unique per technology file.The
gds_datatype
is often zero in foundries for actual data, while annotations have a
non-zero number, but this is not a requirement.Datatype is default 0, the official GDS reference states numbers to 64. A lot of software supports 256, but this is often extended to 65536, which is what xPDK supports.
Note: as some software is more GDS compliant then others, you risk data loss if you use values above 256. Therefore you need to know what the acceptance limit is of the software in the broker / foundry / mask supplier chain. Type pdaGDSinteger documentation:
gds_number
specify the gds details. The combination should be unique per technology file.The official GDS reference states numbers to 64. A lot of software supports 256, but this is often extended to 65536, which is what xPDK supports.
Note: as some software is more GDS compliant then others, you risk data loss if you use values above 256. Therefore you need to know what the acceptance limit is of the software in the broker / foundry / mask supplier chain. Type pdaGDSinteger documentation:
grid
layer in nm. A typical value is 1.0.This grid value is used for defining how ports should be treated; not per-se the data (polygons) in this layer; you can use the layerSnap for that.
name
"identifier".Type pdaIdentifier documentation: