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.

<layer  autoXsection="..."  layerIgnoreAsData="..."  layerIsDieArea="..."  pdaGDSlayer:name="..." ... > ...
  <SingleLayerOps> ... </SingleLayerOps>   list
  <color> ... </color>   list
  <doc> ... </doc>   list
  <fillstyle> ... </fillstyle>   list   optional
  <linestyle> ... </linestyle>   list   optional
  <masksupplier> ... </masksupplier>   list
  <module> ... </module>   list
  <polarity> ... </polarity>   list
  <purpose> ... </purpose>   list
  <tex> ... </tex>   list
  <visible> ... </visible>   list   optional
  <pdaGDSlayer:gds_datatype> ... </gds_datatype>
  <pdaGDSlayer:gds_number> ... </gds_number>
  <pdaGDSlayer:grid> ... </grid>    optional
</layer>

XSD

The schema file can be downloaded or viewed at xPDK_Layout.

Details

Type pdaGDSlayer

The typical GDS type of thing, but including some coloring 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, ...).

Basic definition

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="10" G="20" B="30"/>
   <visible>true</visible>
   <fillstyle>open</fillstyle>
   <linestyle>fill</linestyle>
   <extend>
    <!-- Show extension -->
    <myprop>1</myprop>
   </extend>
</layer>

SingleLayerOps

This section describes single layer operations, see xPDK GDS Layer - single layer operations
Type pdaSingleLayerOPS documentation: Define single layer operations.

Single layer operations are grouped in design rule checking (DRC) and derived layer operations.

Single layer "derived"

For general comments - please refer to multi layer operations.
Some "single layer derived" layers are shown here.

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="10" G="20" B="30"/>
   <visible>true</visible>
   <fillstyle>open</fillstyle>
   <linestyle>fill</linestyle>
</layer>

<layer name="layer2">
  <gds_number>3</gds_number>
  <gds_datatype>8</gds_datatype>
  <grid>0.01</grid>
  <purpose>Deeper and deeper</purpose>
  <SingleLayerOps>
   <!-- not making sense, just to show the setuip  -->
    <layerSize extentSize="2.0" A="layer1">
     <msg>sizing</msg>
    </layerSize>
    <layerGrow growSize="2.0" A="layer1">
     <msg>grow</msg>
    </layerGrow>
    <layerShrink shrinkSize="2.0" A="layer1">
     <msg>shrinking</msg>
    </layerShrink>
  </SingleLayerOps>
</layer>

Here the layerGrow, layerSize and layerShrink fill up content in this layer from another one. The A-reference should be to a GDS layer.

Design rule checking

For general comments - please refer to Multi layer DRC.
In short - be careful with the layer operations to make sure your DRC deck runs fast enough. And talk with your software partners to implement rules.

A simple exapmle is shown here.

full file


<layer name="layer1">
   <gds_number>1</gds_number>
   <gds_datatype>0</gds_datatype>
   <purpose>Waveguide layer</purpose>
   <!-- DRC -->
   <SingleLayerOps>
     <drcConvex/>
     <drcMinSpace value="0.2">Min dist between gides</drcMinSpace>
   </SingleLayerOps>
</layer>

autoXsection

Define this GDS layer as xsection automatically also, set 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.

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: Define a RGB color using the attributes R, G and B.
Each of R, G and B is required and be between 0 and 256.

doc

Type pdaDocumentation documentation: Document anything relevant for the topic you want to define.

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.

extend

Type AllowExtend documentation: This section allows to add your own field or attributes.

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 pdaIdentifier documentation: Defines a valid name for an identifier.

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

layerIgnoreAsData

OptoDesigner extension, mark this layer as 'non data' for a "data inside die/design area" test.

layerIsDieArea

OptoDesigner extension, mark this layer as "die/design area".

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: Defines a valid name for an identifier.

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

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.

module

Specify which proces module adds this layer. Type pdaIdentifier documentation: Defines a valid name for an identifier.

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

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

The purpose is a (short, single line) text describing the purpose of the layer in the foundry.
Expected is a single liner.

tex

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

visible

Set visibility default settings in software; this is intended to have more consistent look over different software.

gds_datatype

The gds_number and 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: The value is an integer between 0 and 65535.

gds_number

The gds_number and gds_datatype 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: The value is an integer between 0 and 65535.

grid

This defines (GDS) database grid / accuracy for this layer in nm. A typical value is 1.0.

name

The name must be defined, be unique and be "identifier".
Type pdaIdentifier documentation: