xPDK_applayer

Virtual / application layer definitons including some user interface related properties. There are a series of common DRC rules available also.

It is often handy for more complex (boolean) operations to have some "gds" layers that are not actually written to GDS files, but are just used by the application to save repeated work. Allowing the use of such interim layers simplifies the layer operation definitions also as they do not need to be recursive and repeated.
In addition to their use in boolean operations, the same aspects often holds for more complex geometrical design rule checks.
Skip to XML structure
The fields for an applayer are almost the same as for a layer (see GDS Layer), but it does not have the gds_number, gds_datatype, polarity and masksupplier as the output should not go to file.
The documentation on the other fields is the same and is not repeated here.

Simple example

The following example shows a very minimal set, which is ok, but lacks the information like purpose or doc to be easy to maintain in the longer run.

full file


 <!-- some output layers for interim results -->
<applayer name="layerA0"/>
<applayer name="layerA1"/>
<applayer name="layerA2"/>

This example shows it very shortly, but it is recommended to document the purpose of the interim layer for future understanding / new colleques. This is done in the next example with the layerAnyData where both the purpose and doc are used (see GDS layer for details).

More realistic example

An example that uses the layerOr to merge data for a possible “data in cell area” test can be written this way. It uses the SingleLayerOps field layerOr (see single layer operations) instead of a series of the multi-layer versions.

full file


 <!-- some real layers for interim results -->
<layer name="layer0">
 <gds_number>0</gds_number> <gds_datatype>0</gds_datatype>
</layer>

<layer name="layer1">
 <gds_number>1</gds_number> <gds_datatype>0</gds_datatype>
</layer>

<layer name="layer2">
 <gds_number>2</gds_number> <gds_datatype>0</gds_datatype>
</layer>


<applayer name="layerAnyData">
 <purpose>Join of data layers</purpose>
 <doc>This join is intended for a "data inside chip area" design
      rule test.
 </doc>
  <SingleLayerOps>
   <layerOr>
     <layer>layer0</layer>
     <layer>layer1</layer>
     <layer>layer2</layer>
   </layerOr>
  </SingleLayerOps>
</applayer>

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_applayer  name="..." ... > ...
  <SingleLayerOps> ... </SingleLayerOps>    optional
  <color> ... </color>    optional
  <doc> ... </doc>    optional
  <fillstyle> ... </fillstyle>    optional
  <linestyle> ... </linestyle>    optional
  <purpose> ... </purpose>    optional
  <tex> ... </tex>    optional
  <visible> ... </visible>    optional
</xPDK_applayer>

XSD

The schema file can be downloaded or viewed at xPDK_Layout.

Details

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>

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

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

name

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

purpose

Define the purpose of the layer
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.