xPDK Basic setup

XSD’s can include other XSD’s and thus the content can be partitioned over different files, while still easily be made accessible in a single (bigger) file. The same holds for XML files themself - so you can structure the data within the limits of the XML standard.
Due to the conversions steps, IP control and so on, the resulting PDK is unlikely to allow designers to have the maximum capability of his/her selected tools. So the basic balance is between allowing enough content in the XML and have enough design capability and creating a very complex super-format that tries to capture “all aspects” but adds a major burden on the foundries to fill up the data correctly as well as the software parties to correctly use such information.

The use of vendor-specific extensions alleviates this somewhat as it allows fine-tuning some aspects for some software/foundry combinations, without impacting others.

Extensions

The extensions, via some vendor specific views, attributes etc can then be used for fine-tuning the convertor. Small things via attributes, big things in vendor extensions.

A simple example is a “layer sizing rule” that can be implemented in different ways - the rule can be common with something like:
<layerSize extentSize="2.0"><A>layer1</A>
   <msg>sizing</msg>
</layerSize>

That will be in the standard. But if for example Synopsys recommends for waveguides to use the “algorithm 1” and for metal “version 2”, a foundry can drastically improve its design kit performance using:
<layerSize extentSize="2.0" Synopsys="alg2" OtherSoftware="std"><A>metal</A>
   <msg>sizing</msg>
</layerSize>
<layerSize extentSize="2.0" Synopsys="alg1" OtherSoftware="rounding"><A>waveguide</A>
   <msg>sizing</msg>
</layerSize>

and so on. This removes the need for a lot of side-files by vendors that complicate design kit development and quality assurance/control. A user of the format is not required to use such extension attributes, they are optional - but not using them will give less optimal results for the designers. This can be in accuracy, memory use or speed for example.

Naming convention

As extensions can be defined by many partners in parallel, it is likely that they can clash after a while. To avoid this, we define a naming scheme for the extension fields and/or attributes.
The types / attributes can be defined in vendor namespaces and in many places attributes from other namespaces are allowed everywhere. An example is the xPDK_OptoDesigner.xsd schema, that defines a series of extensions for Synopsys's OptoDesigner software. It is used in the examples / code with the od: namespace.
For elements in the xPDK schema's we use the following:
When extensions move into the standard (so shared via the pdaflow.org website), they can maintain their name or may receive a new name, depending on the choices of the maintainers of the format and the originator of the extension.
Whether it is a standard extension or not yet so, other partners may use the data in such fields also, however if the field/attribute is not in the standard, the owner can change its use or definition.

Examples

In some of the XML examples we show extensions which are not actually used; as such they do not comply with the naming scheme here and are not extensions that are used at the moment. They are just there to showcase future extensions and/or highlight the purpose of possible extensions in that scope.

Validation

xPDK explicitly allows (vendor / foundry) extensions as long as they do not conflict with the reference reader (so no derivatives). To support this, the XSDs provide for adding new content in many places.

The reference is (for now):