xPDK Format logic

XML is chosen for the data storage as “eXtensible Markup Language” already shows the basic idea - we have common parts, but not all is likely to fit in that. A layout tool does not need all the simulation model info and vice versa.

Keeping the format(s) compact and well defined simplifies their use. So the focus is on the common parts that are shared between at least a few software vendors to start the filling up the design kits and give the foundries a consistent design kit use over different software.

For these common parts it should be clear:

• What does something define.
• What is its purpose (if any) in each of the design software.

This avoids surprises in how xPDK data is converted to the final design kits, without the foundries having in-depth know-how on both the convertor and the design software.

For data that is not useful for multiple software (at the moment) the preference is to have vendor extensions instead of side-files as maintaining both xPDK files in conjunction with all kinds of per-software side files increases maintenance complexity. Using a super format to describe all content for all software vendors makes the content definitions very complex and adds significant cost on the conversions tools and is thus likely introduce errors in the foundry → PDK chain.