PDK structure

An IPKISS Process Design Kit (PDK) consists of:

• A Technology File with technology settings (layers, routing, …)

• A Cell Library with:

  • Models (i3.CompactModel) to evaluate circuit behaviour using circuit simulation.

  • Cells representing predefined parametric as well as static components, with their Layout, Netlist, CircuitModel views,

  • Waveguide templates for waveguide routing,

  • Optionally, Device simulation recipes for custom device simulation and model creation.

• Optionally, documentation on how to use the PDK.

PDK Source and distributable PDK

When implementing a process design kit, we make a difference between the distributable PDK and the PDK source:

• The Distributable PDK is the end product of the PDK implementation. It is what you send to the end user who will use the PDK to create a design.

• The PDK source contain everything you need to implement, verify and distribute the PDK. It may contain more files than the end user of the PDK will see or be allowed to see.

You are free to directly distribute the PDK sources if your intellectual property (IP) boundary conditions permit that. Nevertheless, if you want to set up future-proof internal procedures we advise you to follow the methodology suggested here.

Link for Siemens EDA supports generating PDK Source and from a Distributable PDK:

• Automating the generation and verification of a Distibutable PDK from a PDK Source.

• Generation of interface files for 3rd party EDA tool integration such as OpenAccess databases.

Requirements for Link for Siemens EDA

While the IPKISS core imposes no restrictions on the PDK file or module structure, working with OpenAccess-enabled tools and Link for Siemens EDA requires the PDK maintainer to adhere to a number of requirements regarding the folder structure and the logical structure of Python objects.

The specifications are outline here.

PDK Source requirements

The PDK Source should adhere to the following structure in order to serve as a valid input to pdktools, for generation of a Distributable PDK.

pdkname
├── pdkname.cfg
└── ipkiss
    └── pdkname
        ├── technology
        ├── __init__.py
        └── all.py

In this file structure,

• pdkname is the name of the pdk, it can be chosen freely.

• The Config File pdkname.cfg must exist and adhere to the format specified further.

• The Luceda PDK module needs to be located inside an ipkiss folder. This name cannot be altered.

• The IPKISS pdkname module:

  • must have a Technology File. The name (technology) can be chosen and is configured in lib.yml.

  • must have a Contents File all.py. This name cannot be altered.

So, the name of the PDK (here pdkname) must be used and match exactly in the name of the top-level folder, the Config File and Python module.

Distributable PDK requirements

The following Distributable PDK structure should be adhered to in order to be a valid library which can be used within OpenAccess-enabled tools with Link for Siemens EDA.

pdkname
├── ipkiss
|   ├── lib.yml
|   └── pdkname
|       ├── technology
|       ├── __init__.py
|       └── all.py
├── openaccess
    └── pdkname

In this hierarchy, which is autogenerated when using Link for Siemens EDA,

• pdkname is the name of the pdk, it can be chosen freely.

• The Luceda PDK module needs to be located inside an ipkiss folder. This name cannot be altered.

• The OpenAccess PDK module is located inside a openaccess folder. This name cannot be altered. It is generated by Link for Siemens EDA.

• The ipkiss and openaccess subfolders must be at the same level.

• The ipkiss folder must have a lib.yml library specification file. This file is generated by Link for Siemens EDA.

• The name of the Luceda PDK module and the OpenAccess library must share the same pdkname name.

• The IPKISS pdkname module:

  • must have a Technology File. The name (technology) can be chosen and is configured in lib.yml.

  • must have a Contents File all.py. This name cannot be altered.

Config File (pdkname.cfg)

The Source PDK needs to contain a configuration file in YAML format. The config file has an extension .cfg. Its purpose is to define how the Distributable PDK is built from the PDK source. This file is not needed in the Distributable PDK, it is only relevant for the building phase of the PDK.

The specifications of the Config File are best illustrated with an example:

# config file for pdkname
---
PDK:
    name: pdkname
    description: |
        This is a multiline description of the PDK.
        It can give a bit more information.
    version: 1.0
    date: 18-June-2020
    license:
        title: title of the PDK license

Technology:
    location: pdkname/technology

Exports:
    gdsii:
    ipkiss:
    openaccess:
        with_display: Yes
    files:
        - src: docs/examples
          dst: examples
    tanner:

• The first line is a comment

• Under the PDK key is general information about the PDK: Its name, a multi-line description, a version number, a release date and a license text. You can choose the format and contents of these freely. For versioning, we suggest semantic versioning like many software packages use.

• The Technology key currently only has one subkey location which points to the technology file to read. This is relative to the ipkiss folder containing the PDK module pdkname. By default technology is used, but you can choose a different technology module.

• The Exports key defines hwo the PDK Source is built into a Distributable PDK:

  • Multiple exporters are available: ipkiss, openaccess, files, gdsii.

  • Only the exporters which are listed will be used. For example, only if you explicitly list openaccess, an OpenAccess library will be generated in the Distributable PDK.

  • The gdsii exporter exports a GDSII file for each static cell in the library.

  • The ipkiss exporter exports the IPKISS library to the Distributable PDK. This is basically a copy of the IPKISS library in the PDK Source but it generates the si_fab.yml file as well.

  • The openaccess exporters generates an OpenAccess library with a technology definition (layers and purposes), and cells as well as PCells. One option is available: when the with_display: Yes subkey/value is specified, a .drf display file will be generated and stored in the OpenAccess library: a Lisp file with display definitions which can be read by most EDA tools.

  • The files exporter can be used to specify which additional files to copy. This is specified as a list, with each entry consisting of a src key indicated which file in the PDK Source to copy and a dst key to indicate the destination in the Distributable PDK. The src is relative to the toplevel directory (pdkname). These can be files or folders. In the example above, the doc\examples folder in the PDK source will be copied to examples in the Distributable PDK.

  • The tanner exporter exports the autoload.tanner file, which loads the Link for Siemens EDA macros in L-Edit, to the openaccess library. If you wish to make a custom autoload.tanner file you must use the files exporter instead of the tanner exporter to copy that file to the right location (openacces/<pdkname>/autoload.tanner).

Contents File (all.py)

The contents file is a Python module that has to be named all.py and defines the unique table of contents of the PDK. It ‘exposes’ what is needed to use the PDK. It is required in both the PDK Source and the Distributable PDK. It is automatically copied to the Distributable PDK by Link for Siemens EDA during the automated build.

The requirements on this file are: * The file must export 2 symbols:

• templates: a list of i3.TraceTemplate class names, for waveguide routing purposes. Note: only templates are allowed in this list, no waveguide cells.

• ` __all__`: a list of ipkiss3.all.PCell class names. These is the explicit, restrictive list of PCells which are exported by the PDK.

• The file must import all symbols (PCells, TraceTemplates) which it exports in templates and __all__.

• It _can_ also export other symbols such as functions and the TECH object. But this is not required.

The structure of the file is clarified with an example:

# import technology
from .technology import TECH

# import cells/pcells
from .components.waveguides.wire.trace import SiWireWaveguideTemplate, SWG450
from .components.mmi.pcell.cell import MMI1x2
from picazzo3.traces.twoshape import CoreCladdingShapeWaveguide


# export all accessible components
__all__ = [
    'SiWireWaveguideTemplate',
    'SWG450'
    'MMI1x2',
    'CoreCladdingShapeWaveguide'
]

# export waveguide templates which can be used for routing
templates = ['SiWireWaveguideTemplate', 'SWG450']

• First, the technology is imported (relative to the location of the all.py file. This is not required but handy for the user: with one import statement both the Technology File and Component Library are thus imported.

• Secondly, all cells or functions which we want to expose are imported from their relative locations.

• Also, any IPKISS dependencies that are required, for instance predefined picazzo3 classes, need to be imported. This depends on the cells you have defined in the library.

• The __all__` is a list of all names of (parametric) cells to be exposed. This is a standard private Python variable, hence the double underscored name.

• The templates list contains templates to be exposed for routing. This is a limiting list of template names which can be used in waveguide routing requests.

In large PDKs, for ease of maintenance it can be useful to compose __all__ from a list of smaller lists, but that is not a requirement. For instance, one could define:

# import technology
from .technology import TECH

# import cells/pcells
from .components.waveguides.wire.trace import SiWireWaveguideTemplate, SWG450
from .components.mmi.pcell.cell import MMI1x2
from picazzo3.traces.twoshape import CoreCladdingShapeWaveguide


# export waveguide templates which can be used for routing
templates = ['SiWireWaveguideTemplate', 'SWG450']

# cells defined in this PDK
cells = ['MMI1x2']

# dependencies from IPKISS
ipkiss_cells = ['CoreCladdingShapeWaveguide']


# export all accessible components
__all__ = templates + cells + ipkiss_cells

Technology File (pdkname.technology)

The technology file (pdkname.technology located at pdkname\ipkiss\pdkname\technology in the above specification) is in almost all cases a set of files combined together in a Python package using an __init__.py file. However, this is not a strict requirement: the only requirement is that the technology package can be successfully imported and defines a valid IPKISS Technology tree.

The technology file should be set up in accordance with the instructions in Technology. The required technology keys are documented in Required Technology Keys: IPKISS.