xPDK BB - GUI fields

Standardizing look & feel (from a foundry / designer perspective) can be helpful too. This allows quicker understanding of what to find where in different software and facilitates communication between foundry and design teams as well as within design teams.

BB changes / version

To get an idea of the maturity of the BB design, you can add a lastChangedDate in the BB definition. It does not imply that it needs to have run on many wafers since that change. Another option to show this is the use of the version tag.
full file

<bb name="myDate">
    This date allows a foundry to define the date that the BB really changed, so things
    like new layout, changes in layer stack and so on. Doing new measurements is not part
    of this.

    The date is specified in the following form "YYYY-MM-DD" where:
    YYYY indicates the year
    MM indicates the month
    DD indicates the day
Version information.

The version can be defined as:
  • major.minor
    this is the short-hand version number. This can be a YYYY.MM (year.month) value also.
  • major.minor.patch
    adds the patch to indicate small changes. This can be a YYYY.MM.DD (year.month.day) value also.
  • major.minor.patch.iteration
    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.

Export control & library

The devicetype in the BB can be used for export control as some combinations need (legal) validation.
full file

<bb name="myBB2" devicetype="source">
  <library>Advanced components/Using parameters</library>
The library provides for grouping of comparable foundry BB, mostly handy in case there are many BBs.

  This information is intented for export control as some combinations of BBs need legal
  validation. Design software can validate the devicetype combinations that are used in the
  design and report on possible export regulations.
    Defines the location in an library / element tree. In OptoDesigner it is used as dlgname
    and thus populates the Element dialog.

Icon & drawing

Icon’s can be fully embedded as base64 encoded data. This avoids the need for external file references.
full file

<bb name="myIcon1" devicetype="amplifier">
  <icon> <!-- this data is not actually a PNG ! -->
   <file format="png">4oVIUNDopNMHqhuzLaDOFXnzCT+cRkQM/NroSIdxnALeS1kYcYMKeRGrdRnc
But using files is possible also as shown with the filename statement. And calling some (software specific) functions can also be defined.
full file

<bb name="myIcon2" devicetype="amplifier">
   <!-- use fixed files -->
   <filename format="png">icon.png</filename>
   <filename format="svg">icon.svg</filename>
   <!-- call some drawing code, specific per software -->
   <function software="Software1">call_something_to_draw();</function>
   <function software="Software2">draw_me();</function>
The resolution of pictures should be high enough to allow good scaling in schematic designs. As such SVG is preferred.
  Define a picture.

  The picture can be provided as embedded (use file) or file reference (so external file, use reffile) and
  for some software via function calls (use function).


Pictures do not need to be square as for some BBs it is nicer using rectangular shapes.


To keep the files “human editable” also, it is probably a good idea to have big pictures not embedded in the file, but referenced.