xPDK_Layout

This section in a xPDK extends from
xPDK_Header.

The layout section contains information for mask layout purposes as well as performing derived layer operations and (geometrical) design rule checking. It is therefore the key information for getting correct GDS files to a foundry.

xPDK Layout - OptoDesigner vendor extension

The following extensions provide xPDK_toOptoDesigner02.xsl the information to convert a xPDK Layout file into a 02-file as part of the OptoDesigner design kit or a self contained example that can be used directly.
In the former case you should also convert a xPDK BB file into a 04-file and your layout-only design kit is ready (the xsl is not yet there).
For the latter case it provides an easy way to embed BB, DRC, ... test files and user examples inside the technology file so if the die-template, design rules, ... change you can easily re-generate an extensive set of test cases and user examples. Skip to XML structure
The basic setup is to use xsection's to draw your design in. This abstracts your design from the technology details and makes it much faster to design.

Full example

The following example is a big one.
xPDK_Layout.xml

Use:
xmllint --format -noout --schema xPDK_Layout.xsd xPDK_Layout.xml
to validate the file.

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_Layout  xPDK_Header:pdk_name="..." ... > ...
  <MultiLayerOps> ... </MultiLayerOps>   list
  <applayer> ... </applayer>   list
  <changelog> ... </changelog>   list
  <layer> ... </layer>   list
  <module> ... </module>   list
  <od_DieExtends> ... </od_DieExtends>   list
  <od_DieTemplate> ... </od_DieTemplate>   list
  <od_Example> ... </od_Example>   list
  <od_TechExport> ... </od_TechExport>   list
  <od_TechFactory> ... </od_TechFactory>   list
  <od_TechFooter> ... </od_TechFooter>   list
  <od_TechGlobals> ... </od_TechGlobals>   list
  <od_TechHeader> ... </od_TechHeader>   list
  <xsection> ... </xsection>   list
  <xPDK_Header:doc> ... </doc>    optional
  <xPDK_Header:globals> ... </globals>    optional
  <xPDK_Header:license> ... </license>    optional
  <xPDK_Header:mpw_run> ... </mpw_run>   list
  <xPDK_Header:provider> ... </provider>    optional
  <xPDK_Header:software> ... </software>   list
  <xPDK_Header:tex> ... </tex>    optional
  <xPDK_Header:version> ... </version>    optional
</xPDK_Layout>

XSD

The schema file can be downloaded or viewed at xPDK_Layout.

Details

Type xPDK_Header

Header with some typical information for most xPDK files.

Most is optional and extension capability is the idea.

MultiLayerOps

This section is for multi-layer (GDS or app) operations. See multi layer.
A basic design kit does not need this section, but when a series of (gds or app) layers exists, it is likely to be needed to describe more complex rules and define inter-layer aspects. Type pdaMultiLayerOPS documentation: 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).

applayer

This section allows to define a list of applayers. These will not be written to any output, but are typically needed for supporting DRC.
Per layer single-layer operations are available (DRC, derived), see single layer. Type xPDK_applayer documentation: 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.

changelog

Trace changes to the technology file. Type xPDK_ChangeLog documentation: Trace changes to the data.
This is time-stamped change list, which can be empty. Software or design kit providers are not required to fill this data when changes are made, but it can help users to see what changed over time.

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.

layer

This section allows to define a list of GDS layers. These will be written to GDS or Oasis file or OpenAccess database.
A layout oriented PDK should have one or more of these therefore.
Per layer single-layer operations are available (DRC, derived), see single layer. Type xPDK_layer documentation: GDS/Oasis/OpenAccess layer definitons including some user interface related properties. There are a series of common DRC rules available also.

module

Define a proces module.

Foundries can define multiple processes that can be used by designers. Such process modules will add specific layer/applayer/xsection for a designer to use. Process modules are often used in case basic circuit capability can be achieved with cheaper processes then more advanced capabilities; so it is mostly relevant for silicon photonics where a "passive", "modulator" and "active" process adds incremental cost.
Normally only a few modules are available. Type pdaLayoutProcessModule documentation: Define a process module.

A process module is provided by a foundry or assembly service provider as "add-on" option on a more basic platform. Such extensions typically take more time or are at different (higher) cost.

od_DieExtends

This section contains the die-template instance/use, which is copied into the code-snippets but will also used for the examples to define a basic die.
It is therefore good to pick defaults like die-sizes that support the examples directly. Type od_VendorExtension documentation:

od_DieTemplate

This section contains the die-template definition which is put in the '04' file. The die-template should define form-factors, typical IO locations, dice line or cleave markers and so on.
When using the examples, this section will be placed before the od_DieExtends section. Type od_VendorExtension documentation:

od_Example

Type od_Example documentation:

od_TechExport

This section is copied into the '02' file as the design kit export function body, so you do not need the 'function export(..)'.
If this section is not in the PDK, it will add a default export function which you may need to modify if you use the od_TechGlobals section with pcellLibraries or other things you need in the export. Type od_VendorExtension documentation:

od_TechFactory

This section is copied into the '02' file below the export() function and is intended to register the pxBB's mapping into the pxFactory.Register() tables to support foundry independent designs. Type od_VendorExtension documentation:

od_TechFooter

This section is copied into the '02' file just before the export() function and is intended for overriding functions of the base technology class.
The following attributes are possible Type od_TechFooter documentation:

od_TechGlobals

This section is copied into the '02' file below the default header with the typical mask/die etc includes. The purpose of this is to define pcell libraries and other globals that are shared by 02 and 04 files, eg. for pdkexport() use. Type od_VendorExtension documentation:

od_TechHeader

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

xsection

This defines a xsection which in EDA-design is often called a cad or design layer. In OptoDesigner this is a mcs.
A layout oriented PDK should have one or more of these therefore and they are key for schematic / circuit design also, as connecting ports in a schematic should have a matching xsection.
Type pdaXsection documentation: Define mcs/cad/design layers with optical related properties.

Design layers which map via gridding onto GDS/Oasis/OpenAccess layers. mcs's provide for "optical" logic like default width, bend radius, coupling length and so on.
Each design layer can map to multipe GDS layers, so you can define a layer stack relating to a waveguide in a single definition.
Take for example a typical core, cladding and trench or some under/over etch compensation. This approach is not only suitable for photonics, but is practical in many technologies. The picture below shows a cross-section of a (printed) transistor.



Instead of writing in many GDS layers, you can simply use the xsection which represents OptoDesigner's mcs concept which is shown in the picture.

xsection

This defines a xsection which in EDA-design is often called a cad or design layer. In OptoDesigner this is a mcs. The xsection's define what the port should refer to. A xsection is normally something like a waveguide or metal track and is often using multiple (gds) layers.

Very basic definition.

full file
 <xsection name="WGbase">
  <purpose>Base waveguide</purpose>
 </xsection>
This definition is good for marking things up, but elements placed in this design layer will not go to a mask file.

Including GDS mapping and some properties

full file
<!-- define GDS layers for the <map> sections -->
<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>

<!-- define MCS layers -->
<xsection name="WG" >
  <purpose type="active">Waveguide with grid</purpose>
  <grid>
   <map accuracy="0.1">layer1</map>
   <map widen="2">layer2</map>
  </grid>
  <mcsSetWidth useDrc="false">0.5</mcsSetWidth>
  <mcsSetRadius min="100">200</mcsSetRadius>
 </xsection>

 <xsection name="Doc" >
  <purpose type="doc">Metal highlighting</purpose>
  <grid>
   <map accuracy="0.1">layer2</map>
   <map widen="2">layer2</map>
  </grid>
  <mcsSetWidth useDrc="false">0.5</mcsSetWidth>
  <mcsSetRadius min="100">200</mcsSetRadius>
 </xsection>

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.

globals

Use of globals allows the definition of a list of variables that can be used throughout the file in expressions. Using globals is handy for things that are repeatedly used, so instead of copy/paste long expressions, you can just use the global variables.

Type pdaGlobals documentation: This field provides for optional global parameters and attributes. Inside the globals you can define global variables with an expression, type and unit.

license

Define the license condition for this file. Type pdaLicense documentation: Define license information.

State the basic conditions of using the file and typically refer to legal documents.
License information should be compact enough to be clear as reference. The reference is expected to be to signed documents like Non Disclose Agreements (NDA) or service contracts and so on.

mpw_run

Define a list of tape-outs for which a design kit or other data file can be applied. Type pdaMPWrun documentation: Multi-Project Wafer (MPW) run that will support the given PDK library.

pdk_name

Library / process name; a foundry can supply many PDKs under the same provider name.

The pdk_name at the start (just below the xsi:noNamespaceSchemaLocation defines the design kit name and is intended as a relatively short name. It should be unique enough to avoid confusion by designers. Type pdaPDKname documentation: Defines a valid name for a PDK - this is slightly more general then the pdaIdentifier.
In text this is a letter or number, followed by letters, numbers, underscore or dot or dash or dollar. The check is regular expression: [A-Za-z0-9]([A-Za-z0-9_\.\#$])*

provider

Define the provider of this document.
Type pdaProvider documentation: This field can be used for a full name of the design kit provider, so a full company or institute name for example, instead of the smaller pdk_name.

software

Define the list of supported software for this file. Type pdaSoftware documentation: Define the versions to use with this design kit.

The main idea is that the foundry identifies the 'agreed upon' or 'qualified with' status and that during export and/or pdk load we (can) check this.

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.

version

Define the version of the design kit / data.
Using version numbers helps to keep track of which files to use. Type pdaVersion documentation: