xPDK_Layout
  Structure
  Details

---

TechADK=.. dmExampleGenerate=.. xPDK_Header:pdk_name=..
  <CellCountRule> ...  -tp->
  <CellLocationRule> ...  -tp->
  <CellNameRule> ...  -tp->
  <DesignRule> ...  -tp->
  <DieExtends> ...  -tp->
  <DieTemplate> ...  -tp->
  <Example> ...  -tp->
  <GDSCellPrefix> ...  -tp->
  <LayerRule> ...  -tp->
  <TechExport> ...  -tp->
  <TechFactory> ...  -tp->
  <TechFooter> ...  -tp->
  <TechGlobals> ...  -tp->
  <applayer> ...  -tp->
  <changelog> ...  -tp->
  <drcA_EnclosedBy_B> ...  -tp->
  <drcA_NoOverlap_B> ...  -tp->
  <drcMinDistanceA_to_B> ...  -tp->
  <drcMinExtensionOf_A_By_B> ...  -tp->
  <drcMinSpacingA_to_B> ...  -tp->
  <drcNoPartialOverlap> ...  -tp->
  <drcOverlapOf_A_by_B> ...  -tp->
  <drcOverlapOf_A_by_B_Exist> ...  -tp->
  <drcScript> ...  -tp->
  <gdsSettings> ...  -tp->
  <layer> ...  -tp->
  <local> ...  -tp->
  <module> ...  -tp->
  <sptFooter> ...  -tp->
  <sptHeader> ...  -tp->
  <techDefineCoating> ...  -tp->
  <techGenerateSptFile> ...  -tp->
  <techIncludeMaskFile> ...  -tp->
  <techIncludePathLength> ...  -tp->
  <ticket> ...  -tp->
  <xsection> ...  -tp->
  <xPDK_Header:attribute> ...  -tp->
  <xPDK_Header:doc> ...  -tp->
  <xPDK_Header:global> ...  -tp->
  <xPDK_Header:groupRef> ...  -tp->
  <xPDK_Header:license> ...  -tp->
  <xPDK_Header:mpw_run> ...  -tp->
  <xPDK_Header:provider> ...  -tp->
  <xPDK_Header:tex> ...  -tp->
  <xPDK_Header:version> ...  -tp->

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.

Layer operations

The definition order in the XML file does not define the order of the operations to go from a schematic design (circuit or layout style) to the final GDS polygons, cells and other data in the GDS file. This would complicate the definition; instead the order of operations is defined by the following steps. The software writing the GDS is responsible for the correct order.

• Xsection grid
  The grid mappings define how the waveguide shapes are widening or mapped to different layer and applayer polygon / ... shapes. The widening operation is defined somehwat simple as creating a comparable shape with a wider width; it is therefore not the same as a layerSize or layerGrow operation.
  In case the xsection is defined implicitly via the autoXsection=true, the 1:1 mapping to the gdslayer is expected. After this steps shapes should be considered as polygons, even if the software uses more advanced shapes internally.
• Derived layers
  For each layer the software should ensure that all layers that it derives from are fully known. So if layer A depends on layers B and C & C depends on B, first B should be calculated, then C and A as last. The software is responsible for resolving this correct order.
  Each layer can be the target of multiple layer output operations in addition to being the output of the xsection/grid mappings. The output of all layer operations should jointly be used ("layer or/joined") as the final output.
• Geometric design rule checks
  The design rule checks should operate on the final output per layer; this can be done as soon as a layer is ready or later. In case of multi-layer design rule checks, the software is responsible that all layers in such a check are final; the order of design rule definitions in the XML file related to (derived) layer operations is not relevant.

Derived layer operations

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 Design Rule Checking.

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 layer in which the operation was defined, this can be a gds layer or an applayer.

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.

Some "single layer derived" layers are shown here.
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

This section describes the geometric (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).

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. That extends these a bit with more layer references and some more values.

OptoDesigner export

The xPDK_toOptoDesigner02.xsl used 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  TechADK="..."  dmExampleGenerate="..."  xPDK_Header:pdk_name="..." ... > ...
  <CellCountRule> ... </CellCountRule>   list
  <CellLocationRule> ... </CellLocationRule>   list
  <CellNameRule> ... </CellNameRule>   list
  <DesignRule> ... </DesignRule>   list
  <DieExtends> ... </DieExtends>    optional
  <DieTemplate> ... </DieTemplate>   list   optional
  <Example> ... </Example>   list   optional
  <GDSCellPrefix> ... </GDSCellPrefix>    optional
  <LayerRule> ... </LayerRule>   list
  <TechExport> ... </TechExport>    optional
  <TechFactory> ... </TechFactory>    optional
  <TechFooter> ... </TechFooter>    optional
  <TechGlobals> ... </TechGlobals>    optional
  <applayer> ... </applayer>   list
  <changelog> ... </changelog>   list
  <drcA_EnclosedBy_B> ... </drcA_EnclosedBy_B>   list
  <drcA_NoOverlap_B> ... </drcA_NoOverlap_B>   list
  <drcMinDistanceA_to_B> ... </drcMinDistanceA_to_B>   list
  <drcMinExtensionOf_A_By_B> ... </drcMinExtensionOf_A_By_B>   list
  <drcMinSpacingA_to_B> ... </drcMinSpacingA_to_B>   list
  <drcNoPartialOverlap> ... </drcNoPartialOverlap>   list
  <drcOverlapOf_A_by_B> ... </drcOverlapOf_A_by_B>   list
  <drcOverlapOf_A_by_B_Exist> ... </drcOverlapOf_A_by_B_Exist>   list
  <drcScript> ... </drcScript>   list
  <gdsSettings> ... </gdsSettings>   list
  <layer> ... </layer>   list
  <local> ... </local>   list
  <module> ... </module>   list
  <sptFooter> ... </sptFooter>   list   optional
  <sptHeader> ... </sptHeader>   list   optional
  <techDefineCoating> ... </techDefineCoating>    optional
  <techGenerateSptFile> ... </techGenerateSptFile>    optional
  <techIncludeMaskFile> ... </techIncludeMaskFile>    optional
  <techIncludePathLength> ... </techIncludePathLength>    optional
  <ticket> ... </ticket>   list
  <xsection> ... </xsection>   list
  <xPDK_Header:attribute> ... </attribute>   list
  <xPDK_Header:doc> ... </doc>    optional
  <xPDK_Header:global> ... </global>   list
  <xPDK_Header:groupRef> ... </groupRef>   list
  <xPDK_Header:license> ... </license>    optional
  <xPDK_Header:mpw_run> ... </mpw_run>   list
  <xPDK_Header:provider> ... </provider>    optional
  <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

Most is optional and extension capability is the idea.

CellCountRule

Type pdaDrcCellCount documentation: Define a count rule for designer cell names
This can be used for example to ensure that a single cell name MAIN is in the design or some CELL_ID to mark chips.
The regex should be applied on all cells and the amount of matches should be compared against the count value. Define the oepration as <, <=, >, >=, == or != with the normal C++ convention.

CellLocationRule

Type pdaDrcCellLocation documentation: Define a location rule for main designer cell

CellNameRule

Type pdaDrcCellName documentation: Define naming rules for designer cell names
This can be used for example to ensure the designers do not use foundry prefixes.

DesignRule

Define a 'meta rule', so non-geometric. Type pdaDrcGeneralRule documentation: Define a design rule that is not layer or "polygon" / "geometric" based.
Design rules are available in different flavors, some of which can not be associated with layers; for example the name of the GDS cell that is required to be used for the design.
The rule is described in text and software may (or not) be able to implement them. Using the rule field gives designers an easy way to find more information on the DRC fail if it appears.

DieExtends

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

DieTemplate

Type DieTemplate documentation: 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 DieExtends section.

Example

Type Example documentation: This allows to define an example for the technology. You can use xslt to select one of them by using the example name and create a self contained spt example file.
This is handy to validate design rules or re-generate designer examples when new die-templates or additonal options are used.

GDSCellPrefix

Type GDSCellPrefix documentation:

LayerRule

Type pdaDrcNamingRule documentation: Define naming rules for designer cell names
This can be used for example to ensure the designers do not use foundry prefixes.

TechADK

Type TechADK documentation: The ADK-option for the PDK adds additional xsection / layers in to the design kit to work with typical ADKs.

TechExport

Type TechExport documentation: 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 TechGlobals section with pcellLibraries or other things you need in the export.

TechFactory

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

TechFooter

Type TechFooter documentation: 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

• mcs: Define the default mcs - so what gets mask::CSselect()ed at the end of the technology class.
• mcsDC: Define the default mcs for DC
• mcsRF: Define the default mcs for RF

TechGlobals

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

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 and used for interim derived layers.
For applayer the default of od:layerIgnoreAsData is assumed to be true, so it will not appear in ``data in die'' tests in case a layer/applayer is tagged with od:layerIsDieArea="true". 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: 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.

dmExampleGenerate

Type dmExampleGenerate documentation: Create the standard examples

drcA_EnclosedBy_B

Type pdaDRC_OPSdualArgument_direction documentation:

drcA_NoOverlap_B

Type pdaDRC_OPSdual documentation:

drcMinDistanceA_to_B

Type pdaDRC_OPSdualArgument documentation:

drcMinExtensionOf_A_By_B

Type pdaDRC_OPSdualArgument documentation:

drcMinSpacingA_to_B

Type pdaDRC_OPSdualArgument_direction documentation:

drcNoPartialOverlap

Type pdaDRC_OPSdual documentation:

drcOverlapOf_A_by_B

Type pdaDRC_OPSdualArgument documentation:

drcOverlapOf_A_by_B_Exist

Type pdaDRC_OPSdual documentation:

drcScript

Type pdaOPSinLayer documentation:

extend

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

gdsSettings

Configure GDS settings.
The original GDS standard is often more restrictive then needed and many extensions exist on top of it. This record allows to configure what the fab knows to work in their operation with the mask vendors. Type pdaLayoutGdsSettings documentation:

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.
For layer the default of od:layerIgnoreAsData is assumed to be false, so it will appear in ``data in die'' tests in case a layer/applayer is tagged with od:layerIsDieArea="true". 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.

local

Use of locals allows the definition of a list of variables that can be used in the layers, xsections, derived layers and design rule checks.
These values can be handy to indicate relations between properties, for example a widening of 2um with a DRC on 3um of something is less clear then:
wext=2 um widen(wext) drc(wext+1) Type pdaNamedValue documentation:

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.

sptFooter

Type sptFooter documentation: This section will be put at the end of a definition via XSLT.

Tech/02 definition

This section is copied into the '02' file just before the function export()
The typical use is for backward compatability (for example mapping older mcs names) or some custom tech functions that need access to most of the tech-file.
Using this element instead of the TechFooter is easier in case of enriching the design kit via the C++ or Python library.

pdaSingleLayerOPS

This section is copied into the '02' file below the (gds/mcs) layer definitions in the single-layer operation block. It is intended for more complex single/multi layer derived operations or DRC.

xsection

This section is copied into the '02' file below the mcs definition and is intended for more complex properties like waveguide models and so on.
It provides also for less common mcsSet*() functions or feeding them with values that xPDK does not support.

BB definition

This section is copied into the '04' file inside the layout definition and is intended for fine-tuning behavior, giving control over returned attributes and so on. In typical cases it is not needed.
Use this field in case the xPDK format does not have all the fields you need for your BB in OptoDesigner. For example this is possible for returning more layout attributes or supporting more complex design rule checking.

BB boundary

This section is copied into the '04' file into the layout itself and can be used to mark up complex boundaries. Also the use of multiple mcs/gds layers for DRC can be simpler this way.
Instead of using spt, you can also use the xsection for typical cases and reduce vendor dependence for this section.

sptHeader

Type sptHeader documentation: This section will be put at the start of a definition via XSLT.

Tech/02 definition

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.

pdaSingleLayerOPS

This section is copied into the '02' file below the (gds/mcs) layer definitions in the single-layer operation block. It is intended for more complex single/multi layer derived operations or DRC.

xsection

This section is copied into the '02' file below the mcs definition and is intended for more complex properties like waveguide models and so on.
It provides also for less common mcsSet*() functions or feeding them with values that xPDK does not support.

BB definition

This section is copied into the '04' file inside the layout definition and is intended for fine-tuning behavior, giving control over returned attributes and so on. In typical cases it is not needed.
Use this field in case the xPDK format does not have all the fields you need for your BB in OptoDesigner. For example this is possible for returning more layout attributes or supporting more complex design rule checking.

BB boundary

This section is copied into the '04' file into the layout itself and can be used to mark up complex boundaries. Also the use of multiple mcs/gds layers for DRC can be simpler this way.
Instead of using spt, you can also use the xsection for typical cases and reduce vendor dependence for this section.

techDefineCoating

Type techDefineCoating documentation: You can use this field to define the coating options.
For edge-coupled fibre/chips (typically with SSCs) you normally have different coating options provided by the foundry. In case you use InP or other active materials, you may also have special handling for laser facets.
If you use this field, then the OptoDesigner tech file will setup the coating options and write the designer spec in a side file. You can define which sides support coating; not setting the field will block coating for that edge.
For typical packaging rules (like defined by Europe's PIXAPP Pilot Line service) only West (typical photonics edge) and East (either photonics or RF) are the edges to use; with North and South for use by electrical (lower speed, few GHz) connections.
The values should be a list of names, seperated by a ,, so AR, NO,HR. The names are free, but preferred naming is:

• NA Not Applicable - the designer does not care
• NO No coating
• AR Anti-reflection coating
• HR High-reflection coating

techGenerateSptFile

Type techGenerateSptFile documentation: Specify that the pcellMaskEngineer_Library will be added to the OptoDesigner 02-file/
This pcell library will be used in the BBs to generate a spt-based side-file for mask assembly.

techIncludeMaskFile

Type techIncludeMaskFile documentation: Specify that the #include @mask/file will be added to the OptoDesigner 02-file/
This library suppport operations on mask files and is needed also for loading GDS-based BB/cell definitions from a design kit. If BBs have a boundary with a gds cell in them, you do not need to set this value to true - it will automatically add it.

techIncludePathLength

Type techIncludePathLength documentation: Specify that the path length library will be added to the OptoDesigner 02-file/
This pcell library will be used within the OptoCompiler fast server code. Select the GDS layer that is used for marking the electrical pin.

ticket

Type pdaTicket 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: properties.

Design layers which map via gridding onto GDS/Oasis/OpenAccess layers. xsection'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.

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

attribute

Type pdaAttributeType documentation: and views with information that is likely to be software specific. So it is more a 'flag' then a value. The value is just a string and not something with an expression in it.

doc

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

global

Type pdaNamedValue documentation:

groupRef

Type pdaIdentifier documentation:
Identifiers are used in the Python library for the getName() and setName() function and can thus be used to identify the different elements in list s.
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_])*

license

Type pdaLicense documentation:
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

other data file can be applied. Type pdaMPWrun documentation: library.

pdk_name

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: 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

Type pdaProvider documentation: provider, so a full company or institute name for example, instead of the smaller pdk_name.

tex

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

version numbers helps to keep track of which files to use. Type pdaVersion documentation: