. This is very handy to split up larger files as well as avoid duplication of data that is needed in multiple places.
Most of the fields in this file are optional, only name is a required one. The XSD: xPDK_Base.xsd.
<?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>
nameThe 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.
providerThe provider field can be used for a full name of the design kit provider, so a full company name for example.
versionThe version field defines the version of the design kit and is expected in
licenseThe licensse states the basic conditions of using the file and typically refers to legal documents (NDA).
docThe 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.
globalsUse 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.
globalInsicde the globals you can define global variables with an expression, type and unit.
extendAllows 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.