xPDK_BB

This section in a xPDK extends from
xPDK_Header.

This BB information contains the typical shared data between software: This information is needed in schematic design and circuit simulation as well as in layout.

This scope is therefore fairly broad and future extensions are likely to capture more information. The current common fields provide for a rich design kit already compared to other formats, while adressing different software.
Vendor extensions are supported in this section, so software specific details are possible therefore to tune behavior.

Extensive example

This example is part of the full file below. It is mostly listed here so you do not need to download it. It shows many fields and properties that can be defined and these are described in the child pages.
This file includes the technology file and adds the Met, Met1 and Met2 xsection's in the meta data to show both options work.

Use:
xmllint - -format - -xinclude - -schema xPDK_BB.xsd xPDK_BB.xml
to validate.
full file

 <globals>
  <global name="glbA" type="int"> 4 </global>
  <global name="glbB" type="double"> exp(glbA*3) </global>
  <!-- triggers "duplicate key-sequence" glbB
  <global name="glbB" type="double" >exp(glbA*3)</global>
  -->
 </globals>

 <extend>
   <!-- Series of supplier extensions for supplier side for trace-ability.
  -->
  <foundryDatabase app="SQL" version="2.0.0">See ISO forms - software release documents</foundryDatabase>
  <foundryDatabase app="GUI" version="1.0.42">See ISO forms - software release documents</foundryDatabase>
  <foundryReporter waveguide_module="2.0.1">Loss, neff, groupindex</foundryReporter>
  <foundryReporter active_module="1.2.9">groupindex</foundryReporter>
  <labRuns>march-june 2021, december 2021-april 2022.</labRuns>
 </extend>

 <!-- Include the technology file to ensure correct references.
   -->
  <xi:include href="xPDK_Layout.xml" parse="xml" />
  <!-- Include the compact model list to ensure correct references.
   -->
  <xi:include href="xPDK_CompactModel_List.xml" parse="xml" />


 <!-- Some xsection's for port's that are not defined in the basic technology
    - file. Such a list can include parts of the technology file instead of
    - the full include.
    - Note - adding xsection's here that include GDS layer mapportgs is ok for
    - the XML, but you risk that the software that only uses the technology
    - file does not use all data.
    -->
 <xsection name="Met" />
 <xsection name="Met1" /><xsection name="Met2" />


 <!-- very simple BB -->
 <bb name="myBB">
  <library>Basic components/demo</library>
  <version>1.0</version>
  <!-- implicit layout ports, here just for testing the portref. -->
  <port label="bil" /> <port label="bcl" /> <port label="bol" />
  <port label="bic" /> <port label="bcc" /> <port label="boc" />
  <port label="bir" /> <port label="bcr" /> <port label="bor" />
  <port label="org" />


  <port label="in0">
    <domain>Optical</domain>
    <position> <!-- units for x,y,z: um; for angle,pitch,roll: degree -->
      <x>0</x><y>0</y>
      <angle>10</angle>
    </position>
    <width unit="um" min="2" max="100000">5</width>
    <radius unit="um" min="5" max="100000">50</radius>
  </port>
  <boundary>
    <rectangle portref="org" width="10" length="20" x="0" y="0" />
  </boundary>
 </bb>

 <bb name="myDate">
  <lastChangedDate>2022-04-29</lastChangedDate>
 </bb>

 <bb name="mySOA">
   <bbtype>soa</bbtype>
 </bb>

 <bb name="myParam">
   <parameter name="MinL" type="int" min="1">5</parameter>
   <parameter name="MaxL" max="100"> 5.0 </parameter>
   <parameter name="RangeL" min="1" max="100"> 5.0 </parameter>
   <parameter name="IntSet" type="int" allowedValues="1 2 5 6 10">5</parameter>
   <parameter name="StringSet" type="string" allowedValues="a1 b2 c5 6 10">"c5"</parameter>
   <parameter name="noexpr" type="double" min="1" />
 </bb>

 <bb name="myDoc">
   <doc>This is the short one.

    Can still span lines though.</doc>
   <tex>And here I go for some Tex docu like $\rightarrow$ or even \input{sub.tex}.

    Can be manu lines too.</tex>
 </bb>



 <!-- simple BB with multiple port & parameters -->
 <bb name="myBB1">
  <version>2.0</version>
  <doc>I am a really nice BB with 2 parameters</doc>
  <align Manhattan="true"/>
  <!-- implicit layout ports, here just for testing the portref. -->
  <port label="orgx" />

   <parameter name="L"> 5.0 </parameter>
   <parameter name="IntSet" type="int" allowedValues="1 2 5 6 10">5</parameter>
   <parameter name="StringSet" type="string" allowedValues="a1 b2 c5 6 10">"c5"</parameter>

  <port label="in0">
    <domain>Optical</domain>
    <position> <!-- units for x,y,z: um; for angle,pitch,roll: degree -->
     <x doc="We are symmetric">0</x><y>0</y>
      <angle>10</angle>
    </position>
  </port>
  <port label="out0">
    <domain>Optical</domain>
    <position> <!-- units for x,y,z: um; for angle,pitch,roll: degree -->
      <x>L</x><y>0</y>
      <angle>0</angle>
    </position>
    <drcAngles>0 45 90 135 180</drcAngles>
  </port>
   <parameter name="Width" type="int" min="10" max="500"
          doc="The width is key for this BB">
    42
   </parameter>
   <parameter name="Length" min="0.5">
     3*Width+7.0
   </parameter>
 </bb>

 <bb name="myIcon1" exportclass="amplifier">
  <icon> <!-- this data is not actually a PNG ! -->
   <file format="png">4oVIUNDopNMHqhuzLaDOFXnzCT+cRkQM/NroSIdxnALeS1kYcYMKeRGrdRnc
yXtMtUAk6Xmnoje2X6EnYll/Zn0+GEfFl/6birD2W6ZVc3HhoRQ5Fnl8DObg
WhiGthy1dwNPhKULEzVoDEsffEilx1FfnRWaNSQr0sMfVPIUXH5Gpfb0+zvn
69+xutJmQa9cCrUgsNpYPQFZQLNj7B/gxzYywQHlNQPjO2OakXW7zruTfrgU
TYJlSTSmdJXwdBNN0Vbbn0giRM7RHDgJy/XA6Yvm2BIJci4K41fu+DEhtq+e
L8zzN6cDA6SzeOBcSDd4LWf6nvdmKdX9tIBw5zPlDO+kFSg/ldUPiSJG5udy
PnoaiBfw6faCyV3lTMD13w+HR0EUZCYWF+pu5swDlYstQidbSO59isRQsi7j
+VZb+D/l8SI0JpB2HCpw97gePmXuVKIKuXKmfpOqSWC9nSRlc1qm+++m270p
b2sdpETAstnriFLgcn98jrvKzbCQPRyLJteBzqBOyIaTe50zcDjwENSoVTzI
gwquDVYndjqZIR/ZrcCG7R3ic0LqFzuznQB0BIFN3sbBaVwquCS5Fd9vr0hp
96HXjpSz3NQouc5fMYPYcwK2QU1m+w5L/e5DFqLzbTpbWKO2MvGz5tlPuqoR
1hi7iZHduuKAwyba1acptLGw9zp6ZmtSFaqWKHHcQFV2Uu+vFnM24lunQHW/
VfpLIx5joVsncxfVDYbDcqlffKM3RmszKIt/NRVRbNwKTRteO3EhE4SrRKNi
FX19GlCWXz9vjqFDBvq4cRf+4XLG6IHk6lLxo6QY4zzRNo1p</file>
  </icon>
 </bb>

 <bb name="myIcon2" exportclass="amplifier">
  <icon>
   <!-- use fixed files -->
   <filename format="png">icon.png</filename>
   <filename format="svg">icon.svg</filename>
   <!-- call some drawing code, specific per software -->
   <function trigger="onChange">
      <software app="Software1" version="1.0.0" />
      <code>call_something_to_draw();</code>
   </function>
   <function trigger="onUpdate">
      <software app="Software2" version="1.0.0" />
      <code>
       n=Shape()
       n.draw_me()
      </code>
     </function>
  </icon>
 </bb>

 <!-- more content in BB -->
 <bb name="myBB2" exportclass="source">
  <library>Advanced components/Using parameters</library>
  <version>1.0.0</version>
  <icon>
   <!-- call some drawing code, specific per software -->
   <function trigger="onChange">
      <software app="Software1" version="1.0.0" />
      <code>call_something_to_draw();</code>
   </function>
   <function trigger="onUpdate">
      <software app="Software2" version="1.0.0" />
      <code>
       n=Shape()
       n.draw_me()
      </code>
     </function>
  </icon>
  <port label="out0">
    <domain>Optical</domain>
    <position>
      <x>0</x><y>0</y>
      <angle>10</angle>
    </position>
    <drcMinimumX>200</drcMinimumX>
    <drcMaximumY>400</drcMaximumY>
  </port>
  <port label="out1" refport="out0">
    <domain>Optical</domain>
    <position>
      <x>0</x><y>0</y>
      <angle>10</angle>
    </position>
    <drcMinimumX>200</drcMinimumX>
    <drcMaximumY>400</drcMaximumY>
  </port>
  <port label="rf0" >
    <domain>RF</domain>
    <position>
      <x>100</x><y>200+myLength/2</y>
      <angle>10+sqrt(myPos)</angle>
    </position>
  </port>
   <parameter name="myWidth" type="int" min="10" max="500"
          doc="The width is key for this BB">42
   </parameter>
   <parameter name="myLength" min="0.5"> 3*myWidth+7.0 </parameter>
   <parameter name="Length"   min="0.5"> 3*myWidth+7.0 </parameter>
   <parameter name="myPos" type="point" unit="um"
          doc="A location is a 2 value expression">
     [ 3*myWidth+7.0 , sqrt(myLength) ]
   </parameter>
   <locals>
   <attribute key="justStarted">InitialStage</attribute>
   <attribute key="pleaseDoSomeGUIplacement" />
  </locals>
  <!-- PDAFlow views. The code in PDAFlow allocates the views & sets parameters.
       Here just arbitrary names and values.
  -->
  <view name="pdaLayoutView">
     <parameter name="myWidth" type="int"> 42 </parameter>
  </view>
  <view name="pdaModelView">
    <parameter name="myNeff" type="double"> 1.0/myWidth </parameter>
  </view>
  <view name="pdaModelReference">
    <parameter name="ref" type="string"> "WaveguideModel" </parameter>
  </view>
  <!-- Some specialized views -->
  <SpecView name="loss">5 dB/cm</SpecView>
  <SpecView name="maturity">very high</SpecView>

  <boundary>
   <point x="0" y="-myWidth/2"/>
   <point x="myLength" y="-myWidth/2"/>
   <point x="myLength" y="myWidth/2"/>
   <point x="0" y="myWidth/2"/>
  </boundary>
 </bb>

 <bb name="myStraight" >
   <parameter name="Width" type="int" min="10" max="500"
          doc="The width is key for this BB"> 42 </parameter>
   <parameter name="Length" min="0.5"> 3*Width+7.0 </parameter>

     <xsection>WG</xsection>
     <xsection>Met</xsection>
  <port label="in0" org="true">
    <domain>Optical</domain>
  </port>
 </bb>

 <!-- simple BB with multiple port & parameters -->
 <bb name="myBB3">
  <version>2.0</version>
  <doc>I am a really nice BB with 2 parameters</doc>
  <align Manhattan="true" />
  <port label="in0">
    <domain>Optical</domain>
    <position>
      <x>0</x><y>0</y>
      <angle>10</angle>
    </position>
     <xsection>WG</xsection>
  </port>
  <port label="out0">
    <domain>Optical</domain>
    <position>
      <x>Length</x> <y>0</y>
      <angle>0</angle>
    </position>
    <drcAngles>0 45 90 135 180</drcAngles>
  </port>

   <port label="out1">
    <domain>Optical</domain>
    <position>
      <x>Length</x> <y>0</y>
      <angle>0</angle>
    </position>
    <drcAngles>0 45 90 135 180</drcAngles>
  </port>

   <parameter name="Width" type="int" min="10" max="500"
          doc="The width is key for this BB"> 42 </parameter>
   <parameter name="Length" min="0.5"> 3*Width+7.0 </parameter>
   <!-- gives Duplicate key-sequence ['Length'] - ->
   <parameter name="Length" min="0.5">3*W+7.0</parameter>-->
  <locals>
   <local name="xlW" type="int" min="10" max="500"
          doc="The width is key for this BB">42
   </local>
   <local name="xlL" min="0.5">3*Width+7.0</local>
   <!-- gives Duplicate key-sequence ['xlL'] - ->
   <local name="xlL" min="0.5">3*Width+7.0</local> -->
  </locals>
  <boundary >
    <rectangle portref="in0" width="10" length="20" />
  </boundary>
  <boundary purpose="metal">
    <rectangle portref="in0" width="4" length="2" />
  </boundary>
  <boundary purpose="metal">
    <rectangle portref="out0" align="boc" width="4" length="2" />
  </boundary>
  <boundary purpose="metal">
    <circle portref="out0" align="bcc" radius="42.24" y="10" />
     <xsection>Doc</xsection>
  </boundary>
  <boundary purpose="metal">
    <od_spt> ml::Straight(cin->[0] : );
    </od_spt>
  </boundary>
  <boundary purpose="waveguide">
    <circle portref="out0" align="bcc" radius="42.24" y="10" />
     <xsection>WG</xsection>
  </boundary>
 </bb>


  <!-- simple BB with multiple port & defaults xsection -->
 <bb name="myBB_manyport">
  <xsection>Met</xsection>
  <xsection>WG</xsection>
  <port label="in0" />
  <port label="out0" />
  <port label="rf0" />
  <port label="rf1" />
 </bb>

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_BB  xPDK_Header:pdk_name="..." ... > ...
  <bb> ... </bb>   list
  <changelog> ... </changelog>   list
  <xPDK_CompactModel_List> ... </xPDK_CompactModel_List>   list
  <xPDK_Layout> ... </xPDK_Layout>   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_BB>

XSD

The schema file can be downloaded or viewed at xPDK_BB.

Details

Type xPDK_Header

Header with some typical information for most xPDK files.

Most is optional and extension capability is the idea.

bb

Define a series of building blocks, sometimes called cell or pcell also (EDA terminology).
This section is used by both layout and schematic / circuit oriented software to allow designers to create their circuits. In general it does not make sense to have design kits without BBs in there. However it is not a required to have them - there are gds layer / process only design kits also.
full file
<bb name="myBB_0">
 <!-- put real definitions in here - see other sections. -->
</bb>

<bb name="myBB_1">
 <!-- put real definitions in here - see other sections. -->
</bb>
Type pdaBBdefinition documentation: BB definitions including ports, parameters, attributes and views.

Basic fields

The following example shows the basic information that is expected (but not required). With this content you can start using it in different software. It does not define parameters, so it is a fixed design.
Normally BB's have more ports as well as parameters, so a "real" BB will be longer.
full file

<bb name="myBB">
 <library>Basic components/demo</library>
 <license>Just the PDAFlow one</license>
 <version>1.0.0</version>

 <port label="in0">
   <domain>Optical</domain>
   <position> <!-- units for x,y,z: um; for angle,pitch,roll: degree -->
     <x>0</x><y>0</y>
     <angle>10</angle>
   </position>
   <width unit="um" min="2" max="100000">5</width>
   <radius unit="um" min="5" max="100000">50</radius>
 </port>
 <boundary>
   <rectangle portref="in0" width="10" length="20" x="0" y="0" />
 </boundary>
</bb>

Documentation

Adding documentation is easy also, the doc is used by more software then the tex. tex is for long pieces of text like full help pages.
full file

<bb name="myDoc">
   <doc>This is the short one.

    Can still span lines though.</doc>
   <tex>And here I go for some Tex docu like $\rightarrow$ or even \input{sub.tex}.

    Can be many lines too.</tex>
 </bb>

Alignment

A building block can be validated on angle - this is using the "org" port as coordinate reference.
You can select one of the following options: drcManhattan, drcXaligned, drcYaligned, drcAngles

full file
<bb name="myBB_0">
 <drcManhattan>true</drcManhattan>
</bb>

<bb name="myBB_1">
 <drcXaligned>true</drcXaligned>
</bb>

<bb name="myBB_2">
 <drcXaligned>true</drcXaligned>
</bb>

<bb name="myBB_3">
 <drcAngles>45.0 135.0 225.0 315.0</drcAngles>
</bb>

changelog

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.

xPDK_CompactModel_List

Include the defined compact models for easy checks and/or define them locally.
Using the <xi:include ... /> is the preferred route as it allows to share the definition between design kits.
See building block type for the more details on what this section defines. The preferred route is to include such files rather then embedding them.
full file
 <!-- Include compact model file -->
 <xi:include href="xPDK_CompactModel_List.xml" />
Type xPDK_CompactModel_List documentation: This section in a xPDK extends from xPDK_Header.

The Compact Model List file provides a table with building block types. Per building block type a list of models is defined that describes what type of (compact) model should be defined for a BB/Model definition file using the Circuit Simulation file.

xPDK_Layout

Include the technology file and/or define them locally.
Include a full technology file to avoid copy/paste errors and other data inconsistencies. See xPDK_Layout.xml for how to do this.

Define basic technology info.

The technology file contains the xsection information which is needed in the port to make sure the references are correct. To get this information, you can include a full technology file or just query the data using xsltproc and keep the (xs:include expanded) meta data file short.
full file
 <!-- Full tech file -->
 <xi:include href="xPDK_Layout.xml" />

Technology file → summary

You can run the following to summarize a technology file for the (embedded or xs:include'd) xsection list.
xsltproc - -xinclude xPDK_xsection_list.xsl xPDK_Layout.xml
This should give the following output:
full file
The XSLT file can be downloaded: xPDK_xsection_list.xsl.
Type xPDK_Layout documentation: 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.

xsection

Define local xsection's which can be added to a technology file or be just the a sub-set of the technology file to reduce file size and make the files stand-alone.

You can copy the output of the summary generation into the XML file and/or define additional xsection. As only the name is needed, the list is short.
full file
 <!-- Local tech file, eg. from summary -->
 <xsection name="Waveguide" />
 <xsection name="Metal1" />
 <xsection name="Metal2" />

Sometimes it is handy to add xsection's for port's that are not defined in the basic technology file. Such a list can include parts of the technology file instead of the full include.
Note - adding xsection's here that include GDS layer mapportgs is ok for the XML, but you risk that the software that only uses the technology file does not use all data.

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: