pdaMultiLayerOPS

Define multi-layer Derived & Design Rule Checking multi layer operations.
The layers should be defined prior to use.

Multi-layer derived

Derived layer operations are common in chip design to simplify work for designers and make their work more efficient and less error-prone. This holds for both single-layer and multi-layer operations.

The implementations of these operations vary strongly per software so efficiency (cpu, runtime, memory) will be different per software. In general a tool-specific set of operations can be much (> 10x) faster then a generic / converted deck and (optimal) runtime may easily be hours of wallclock-time, see also DRC.

Multi-layer derived layers look like the single-layer operations, they mainly differ in the amount of layers that are used.
For the input of the operations there are two flavors - the named layers A, B and sometimes C. And the layer list via a list of layer fields. The first option is used if order of layers is relevant, for example in a layerAnotB. Changing the A & B layers will lead to very different results.

The layer-list is suitable in case many layers can be used and ordering is not important. This option like in layerIsCoveredBy do use a list of layers like in the Cover and In fields, which combine like an "or".

The output of the operation is (for derived layers) stored in the Tgt layer, which can be a gds layer or an applayer.

full file


<!-- some base layser -->
<layer name="layer1">
 <gds_number>0</gds_number> <gds_datatype>0</gds_datatype>
</layer>

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

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

<layer name="layer4">
 <gds_number>4</gds_number> <gds_datatype>0</gds_datatype>
</layer>

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

<layer name="layerA1">
 <gds_number>0</gds_number> <gds_datatype>4</gds_datatype>
</layer>

<!-- multi-layer ops -->
<MultiLayerOps>
  <layerAnotB Tgt="layer4" A="layer1" B="layer3"/>

  <layerOr Tgt="layer4" A="layer1" B="layer3"/>

  <layerAnd Tgt="layer4" A="layer1" B="layer3"/>

  <layerXor Tgt="layer4" A="layer1" B="layer3"/>

  <layerOffset Tgt="layerA1">
   <doc>Some combined output</doc>
   <In>
     <layer>layer1</layer> <layer>layer2</layer> <layer>layerA0</layer>
   </In>
   <dist>2.0</dist>
  </layerOffset>

  <layerIsCoveredBy Tgt="layerA1">
   <doc>Some combined output</doc>
   <Cover>
     <layer>layer1</layer> <layer>layer2</layer>
   </Cover>
   <In>
     <layer>layer1</layer> <layer>layer2</layer> <layer>layerA0</layer>
   </In>
   <how>partly_including</how>
  </layerIsCoveredBy>
</MultiLayerOps>

Derived layers (single & multiple) are often needed to be able do define DRC rules more precisely as they tend to have clauses like "if this & that, then the rule is so&so". This this&that and so&so are both often derived layers.

Multi-layer DRC

That extends these a bit with more layer references and some more values.

full file


<!-- some base layser -->
<layer name="layer1">
 <gds_number>0</gds_number> <gds_datatype>0</gds_datatype>
</layer>

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

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

<!-- multi-layer ops -->
<MultiLayerOps>
  <!-- Define multi-layer operations -->
  <drcNoOverlapA_Exclude_B A="layer1" B="layer3">
   <msg>Just a msg</msg>
  </drcNoOverlapA_Exclude_B>
  <drcA_NoOverlap_B_Exclude_C A="layer1" B="layer3" C="layer2">
  <doc>Do something more exclusive here?</doc>
   <msg>triple</msg>
  </drcA_NoOverlap_B_Exclude_C>

  <drcMinSpacingA_to_B A="layer1" B="layer3">
   <value>5</value><msg>Keep some distance</msg>
  </drcMinSpacingA_to_B>

  <drcOverlapOf_A_by_B A="layer1" B="layer2">
   <value unit="um">5</value><msg>Need some overlap</msg>
  </drcOverlapOf_A_by_B>
</MultiLayerOps>

Design rule checking

This section describes the multi-layer design rule checking options that operate on geometric data. Often you need to assemble a chain of derived layer operations to get the required rule check.
A simple example is a minimum width check - you can implement this by a "shrink, followed by a grow" and then do a layer overlap with the original to see if there is a difference (note: this is not a fast way and not recommended!).

The operation chain is often using intermediate layers that are not needed in the output files - hence the use of applayer to store such interim layers. Sometimes the operations are just needed on the input data - so it can be a puzzle to write a test down in geometric correct specifications.
A second complication is that different software implements the tests and boolean operations differently; so an optimal result (in cpu / runtime / memory) on one software may not be so on another one. It is therefore recommended to validate with software vendors to see that the layer-operation chain and design rule check is well defined.
In general the best option is to use as few layer operations as possible with as little layers as possible in the rule check, but there are clear and common exceptions to this.

To validate the rule is correctly implemented, it is recommended to make a test design per rule; such a design should contain one or more of the failing designs, a few just-passing designs and some designs with a clear pass. The amount of pass/fail tests depends on the complexity of the rule.
With OptoDesigner you can then validate the operations to get the correct amount of fails. Setting up the regressionstesting with autoxml then allows you to automate the testing during new releases, so you reduce much effort in maintenance on existing rules, while not risking operations in the layer-operation chain failing due to extending the DRC deck.

The (clock) runtime of larger DRC decks can be considerable, even for photonics designs which are mostly empty space on the chip compared to electronic designs. The difference between a well-written / tool-specific DRC deck and a xPDK_Layout converted version is likely to be very relevant to designers. First of all because the tool-specific deck can use more / faster operations then xPDK_Layout supports. And secondary because the optimal layer operation chain + rule validation is different per tool.
You may need to make the choice therefore between cost for designers versus cost for the foundry (DRC deck user versus provider).

Structure

This element does not have attributes. The 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.

XSD

The schema file can be downloaded or viewed at xPDK_Layout.

Details

drcA_EnclosedBy_B

Test for enclose of A by B.
The Value-attribute is the enclosure distance. Type pdaDRC_OPSdualArgument documentation:

drcA_EnclosedBy_B_WhenAOverlapB

Test for enclose of A by B.
This is a restriction to areas where A is overlapped by B.
Value is the enclosure distance. Type pdaDRC_OPSdualArgument documentation:

drcA_NoOverlap_B

Test to make sure there is no overlap of A and B.
This is a very common operation which is often used for waveguide/black box boundary checks or waveguide/metal crossings. Type pdaDRC_OPSdual documentation:

drcA_NoOverlap_B_Exclude_C

Test to make sure there is no overlap of A and B in regions that are not overlapped by C.
It is an extension to drcA_NoOverlap_B to allow overlaps under the condition that C is there also. A simple example is a waveguide/black box boundary test where the ports are inside the building block rather then on the outside of it. Such additional context can be placed in C. Type pdaDRC_OPStriple documentation:

drcMinDistanceA_to_B

Value is the distance between A and B. Type pdaDRC_OPSdualArgument documentation:

drcMinExtensionOf_A_By_B

Validate an extension size.
The extension of (A,B) is the distance between the internal boundary of A and the external boundary of B.
Value is the extension. Type pdaDRC_OPSdualArgument documentation:

drcMinSpacingA_to_B

Validate that the minimum distance between A and B is value.
Value is the distance between A and B. Type pdaDRC_OPSdualArgument documentation:

drcNoOverlapA_Exclude_B

No self overlap in A excluding areas covered by B.
This is an extension of the single layer test drcNoOverlapA. Type pdaDRC_OPSdual documentation:

drcNoPartialOverlap

Test for no partial overlap of A and B.
This allows A and B to be either fully overlapping or not at all. Type pdaDRC_OPSdual documentation:

drcOverlapOf_A_by_B

Test for the overal of A by B to be at least value.
The overlap distance between the internal boundary of A and the internal boundary of B Check if layer A has any overlap with layer B Type pdaDRC_OPSdualArgument documentation:

drcOverlapOf_A_by_B_Exist

Test if layer A has any overlap with layer B
Type pdaDRC_OPSdual documentation:

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.