xPDK Interim (application) layer
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.
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 likepurpose
or doc
to be easy to maintain in the longer run.
<!-- some output layers for interim results -->
<applayer name="layerA0"/>
<applayer name="layerA1"/>
<applayer name="layerA2"/>
purpose
and doc
are used (see GDS layer for details).More realistic example
An example that uses thelayerOr
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.
<!-- 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>
<layerOr>
<layer>layer0</layer>
<layer>layer1</layer>
<layer>layer2</layer>
</layerOr>
</applayer>