xPDK_NetlistDefines the xPDK Netlist.
This type defines the hierarchy of typical designs by defining a series of flat netlists that can reference each other by name.
StructureThe 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_Netlist netlist_version="..." ... > ...
<attribute> ... </attribute> list
<author> ... </author> optional
<changelog> ... </changelog> list
<doc> ... </doc> optional
<filedate> ... </filedate> optional
<global> ... </global> list
<license> ... </license> optional
<netlist> ... </netlist> list
<software> ... </software> optional
<tex> ... </tex> optional
<ticket> ... </ticket> list
<version> ... </version> optional
XSD The schema file can be downloaded or viewed at xPDK_Netlist.
DetailspdaAttributeType documentation: Attributes are key/value pairs to annotate building blocks 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. 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. 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
texwhich allows documentation in LaTex format;
docis restricted to plain text.
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
extendwill 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.
Format is of the form: 2020-03-27 13:22:05", assuming GMT (UTC+0) time zone. pdaNamedValue documentation: Create a named value with expression / type support. 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.
First entry is “main netlist”, the rest are user-defined CBB sub-netlists which may referenced by the main netlist Type pdaNetlist documentation: Define a flat netlist.
The flat netlist is a series of BBs or other netlist instances. Each of these can have its parameter values changed but it is not required to set all of them.
These instances are connected via the bb_connect's or to the external ports of the netlist via the extport. pdaVersion documentation: Version information.
The version can be defined as:
this is the short-hand version number. This can be a
YYYY.MM(year.month) value also.
adds the patch to indicate small changes. This can be a
YYYY.MM.DD(year.month.day) value also.
where the iteration is often relating to a (software) implementation and thus less typical in PDK or BB versions.
It can be useful in the compact model files to indicate that the same measurements or simulations have received a new model instance.
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. pdaTexDocumentation documentation: As
texcan 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. pdaTicket documentation: Specify something to look at / fix. PDAFlow netlist file format Type pdaVersion documentation: