xPDK Header

The typical structure of the xPDK files is a header like below followed by the content. This common header allows to include documents via
xs:include
. This is very handy to split up larger files as well as avoid duplication of data that is needed in multiple places.
full file
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<xPDK_Header xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         xsi:noNamespaceSchemaLocation="xPDK_Base.xsd"
  name="DemoPDK">
 <provider>Stichting PDAFlow Foundation</provider>
 <version>1.0.0</version>
  <license>
  Stichting PDAFlow Foundation, document in progress.
  Demo Material
  </license>

 <doc>
  The xPDK is a very flexible setuip.
 </doc>

 <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>

 <!-- Include files to ensure correct references.
  <xi:include href="someOtherXml.xml" parse="xml" />
   -->

 <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>

</xPDK_Header>

Most of the fields in this file are optional, only name is a required one. The XSD: xPDK_Base.xsd.

name

The 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.

provider

The provider field can be used for a full name of the design kit provider, so a full company name for example.

version

The version field defines the version of the design kit and is expected in where a major number change indicates something big changed, while the minor is for more incremental changes. The patch indicates normally small data updates like new measurements.

license

The licensse states the basic conditions of using the file and typically refers to legal documents (NDA).

doc

The doc 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.

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.

global

Insicde the globals you can define global variables with an expression, type and unit.

extend

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.

More details on extensions naming & conventions.