PHIDL: Python CAD layout and geometry creation for

nanolithography
arXiv:2103.01152v1 [cond-mat.supr-con] 1 Mar 2021

A. N. McCaughan1 , A. M. Tait1 , S. M. Buckley1 ,

D. M. Oh2 , J. T. Chiles1 , J. M. Shainline1 & S. W. Nam1
1 National Institute of Standards and Technology, Boulder, CO 80305
2 University of Colorado, Boulder, CO 80305

Introduction
Computer-aided design (CAD) has become a critical element in the creation of nanopatterned
structures and devices. In particular, with the increased adoption of easy-to-learn program-
ming languages like Python there has been a significant rise in the amount of lithographic
geometries generated through scripting and programming. However, there are currently un-
addressed gaps in usability for open-source CAD tools – especially those in the GDSII design
space – that prevent wider adoption by scientists and students who might otherwise benefit
from scripted design. For example, constructing relations between adjacent geometries is
often much more difficult than necessary – spacing a resonator structure a few micrometers
from a readout structure often requires manually-coding the placement arithmetic. While
inconveniences like this can be overcome by writing custom functions, they are often sig-
nificant barriers to entry for new users or those less familiar with programming. To help
streamline the design process and reduce barrier to entry for scripting designs, we have de-
veloped PHIDL† , an open-source GDSII-based CAD tool for Python 2 and 3 based on gdspy1
and numpy.2
In PHIDL, we have placed an high priority on usability, clarity, and consistency: the
package is purpose-built so that a brand-new user can learn the conceptual underpinnings
and begin designing useful geometries in just a few minutes. In its development, we sought
to emulate the ease of vector-editing software like Inkscape and Adobe Illustrator as these
programs and their interfaces have been developed for decades and are highly intuitive even
to new users.
At present, several other geometry creation CAD tools do exist, with varying levels of
scripting interfaces.3–6 Generally, the software built for scripting GDS geometries follow the
GDS specification closely, including polygons, cells, references, and arrays. However, PHIDL
also provides functionality for the user well beyond just the GDS specification.
The basic premise of PHIDL is that polygons are created by the user and grouped into
one or more “Device” objects. (For those familiar with GDS design, a Device is just a “cell”
†
https://github.com/amccaugh/PHIDL

1
 a

Figure 1: Creating complex geometries by connecting shapes together. (a) Three arcs are
generated, and each arc has a “port” on either end. (b) The shapes are snapped together like
building blocks using the connect() function, which automatically performs the calculations
needed to mate the ports together.

with a few special features). Within the Devices, a user can also define “ports” which offer a
convenient way of connecting one Device to another–ports are typically placed at the input
and outputs of a Device. For example, when building a smooth path with contacts at either
end, a user would likely put ports on the path outputs and, separately, also put ports on
the contacts. After a few Devices are constructed by the user, they can be trivially snapped
together like building blocks using the connect() function.
In this way, very complex geometries can be assembled one piece at a time without
requiring the user to manually compute placement locations. We note that this kind of shape-
to-shape snapping is ubiquitous in vector-editing and other design software (e.g. Adobe
Illustrator™, Inkscape, and even Microsoft PowerPoint™) due to its convenience and utility.
The Device also makes a convenient abstraction for working with complex polygons, as the
user does not need typically to concern themselves with the details of the polygons inside
the Device–only use the ports to quickly connect it to other Devices. Shown in Fig. 2 are
photonic and superconducting layouts made in PHIDL which were successfully fabricated in
a cleanroom.
To make PHIDL as convenient as possible, there is an included geometry library
phidl.geometry (known as pg hereafter) which contains a large number of easy-to-use func-
tions which can produce basic shapes (ellipses, rectangles, arcs, etc), advanced shapes (text,
contact pads, etc), boolean functions (boolean, union, offset, etc), lithographic test structures
(resolution tests, calipers, etc) and application-specific shapes such as photonic waveguides
structures and superconducting nanowire single photon detectors. One particularly useful
feature is the packer() function, which takes a list of shapes or Device objects and packs
them together into as small an area as possible. Shown in Fig. 3 is the usage of this function
to automatically pack all of the built-in geometry library shapes into a single area.
This package also includes a variety of other useful features, such as (1) the quickplot()

2
 a b e

50 um

c d

10 um

Figure 2: Example layouts and fabricated die made with PHIDL (a) Layout of a
superconducting-nanowire electronic circuit based on thermal switches7 with 7 independent
layers, and (b) resulting microscope image of fabricated device. (c) Layout of a multilayer
superconducting single photon detector device and (d) scanning electron micrograph of the
fabricated device. (e) Photonic integrated circuit layout made in PHIDL with over 95,000
polygons and 6.8 million points.

Figure 3: Examples of the built-in geometry library functions.These include basic shapes,
text, layer-alignment calipers, resolution tests, boolean operations, and grow/shrink opera-
tions. These shapes were automatically placed within the rectangular area using PHIDL’s
built-in packing algorithm packer().

function which can quickly generate a plot of any shape or device using matplotlib,8 (2)
the ability to easily to record custom metadata for every Device and export it for later
reference, and (3) the ability to export designs directly to the SVG format for use in figures
and scientific posters.

Design concept overview

This software package is aimed at scientists and students who need to manipulate geometry
and produce GDS files and want to do that a minimal amount of time spent learning pro-
grammatic structure. Below, we enumerate the principles according that this package strives
towards, listed in order of importance.

3
Usability
The goal in designing PHIDL was to ensure that anyone who has used common drawing
software can start designing useful structures with as little start-up time as possible. We
found that many of the current GDS scripting methods encourage users to position geometry
according a “rubber stamp” approach that consists of: (1) selecting a geometry function (e.g.
a ring or a transistor), (2) choosing the exact coordinates for its location, then (3) creating
an instance of the geometry at that position. Much like a mark made by a rubber stamp, if
the position of the geometry is found to be incorrect later it is not easy to move it after the
fact; the user must trace back through the code, modify the position of the geometry at its
instantiation, and update any follow-on calculations which depend on that positioning. For
PHIDL, we opted to take the “building block” approach used by many types of graphical-
editing software, where the user is encouraged to gather structures together first and then
assemble them afterwards. In PHIDL, this translates to (1) creating instances needed ge-
ometry immediately, not worrying about positioning, then (2) manipulating the geometries
together with move(), rotate(), reflect(), and connect() until everything is positioned
as as desired. We note that at very large scales there are useful optimizations possible with
the “rubber stamp” approach–however the optimizations are not large compared against the
overhead of Python itself, and we believe the usability and intuitiveness of our approach
make for much larger time savings overall.
An important aspect to making the “building block” approach usable was to guarantee
that any PHIDL object can be manipulated/transformed using the same key words (e.g.
move() or rotate())–whether it be the geometry-containing Device itself, a reference to
that Device, a polygon, or a port. This consistency reduces the amount of memorization
required by the user and follows the principle of least astonishment, which states that “...a
component of a system should behave in a way that most users will expect it to behave;
the behavior should not astonish or surprise users.” Aiming for a high level of usability
also meant we put a priority on having many examples. Documentation always useful, but
our experience has been that examples are the quickest way to start using scripted software,
with documentation acting as a canonical resource for deeper understanding of the functions.
To this end, we have created a wealth of examples available as tutorials and in the online
documentation.

Flexibility
Similar to usability, PHIDL is also designed to be flexible in the ways that the user can
interact with and manipulate its objects. This means that PHIDL was designed with the
software principle of “do what I mean” which states that the user “...should not be stopped
and forced to correct themselves or give additional information in situations where the cor-
rection or information is obvious.” An example of following this principle is that polygons
can be created by entering the data either as a list of x/y pairs [(x1,y1),(x2,y2),(x3,y3),...] or
as a pair of ordered lists [(x1,x2,x3,...),(y1,y2,y3,...)]. PHIDL will deduce which format the
user’s data is being entered in and make the necessary conversions without user intervention.
(Since any non-trivial 2D polygon must have at least 3 points there can be no ambiguous
cases.) Another example of flexibility is how PHIDL allows the user to position geometry

4
in multiple ways. As a first option, the user can manually move an object such as a De-
vice or a polygon with its move() command and the related fixed-axis commands movex()
and movey(). As a second option, the user can use relational properties of the geometry
to move objects around. For instance, to separate two circles in the x-direction by exactly
5 units one can use the command circle1.xmin = circle2.xmax + 5. This will position
circle1 such that its minimum x value is 5 units to the right of the maximum x value of
circle2. As a third option, the connect() command can be used to snap together Devices
like building blocks using their ports. The connect() command even includes an optional
overlap argument which can be used force overlap between geometries. This overlap is often
useful in multi-layer cleanroom fabrication when perfect alignment between layers cannot be
guaranteed.
Also useful is the flexibility in layer specification. To comply with GDS standards every
polygon must have a layer and datatype – PHIDL follows this convention, but allows
more flexible entry in specifying the layer. For example, making cross shape on layer 7
with datatype 0 can be accomplished either by explicity writing pg.cross(layer = (7,0))
or using the shorthand pg.cross(layer = 7). When creating geometry, multiple layers
can also be specified easily using the built-in Python set object. For example using the
argument layer = {7, 8, (9,25)} will put copies of the geometry on layers (7,0), (8,0)
and (9,25). Alternatively, there is a more advanced PHIDL LayerSet object which can be
used to group several layers together. There is also an ’alias’ functionality within phidl. To
work with an object, it can either be stored into its own variable or it can be assigned to the
Device which owns it with an ’alias’. For instance, if we want to add a reference of a circle
to a Device D using the add_ref() function, we can either hang on to the reference by (1)
assigning it to a temporary variable like myrect = D.add_ref(E) or by (2) assigning it an
alias within D like D[‘myrect’] = D.add_ref(E). Storing objects as aliases can also help
reduce ambiguity when sharing code because it becomes obvious to which Device the object
belongs.

Minimal structure
When designing PHIDL, we tried to create as simple a software structure as was feasible
while still prioritizing usability. We have observed that scientists and graduate students are
often part-time designers, using design tools heavily for a few days or weeks then leaving
the tools for a period of time to implement the designs. As a result, we tried to keep the
structure of PHIDL minimal so that both a first-time user or a returning user has a minimal
amount of architectural information they have to keep memorized. One example of keeping
structure to a minimum is that all functions in the phidl.geometry library operate the same
way: they create new geometry and return a single Device. Similarly, all functions within
a Device object (for instance, align() or flatten()) only modify the existing geometry
within the Device.
We also attempted to provide sane defaults for any function that has potentially ambigu-
ous arguments. These defaults give the user a starting point, and by viewing the resulting
geometry with the quickplot() function the user can learn-by-inspection. This process
can occur without ever leaving the Python terminal, needing to read the function code, or
looking up the the online documentation. PHIDL also offers convenience functions wherever

5
 Table 1: Naming conventions of geometry-editing software
Reflection Translation Rotation Offset
PHIDL mirror move rotate offset
gdspy1 mirror translate rotate offset
IPKISS6 mirror move rotate offset/grow
nazca9 flip move rotate buffer
gdshelpers3 transform translate rotate buffer
KLayout5 mirror move rotate size
LayoutEditor10 mirror move rotate sizeadjust
L-edit mirror move rotate grow
Illustrator reflect move rotate offset
Inkscape flip move rotate offset
Powerpoint flip move rotate N/A

possible. For example, while it is possible to align several polygons horizontally along the
y-axis using the move() command and a for loop, we have also included a convenience
function in the Device class called align() because it is such a common action in geometry
design.
Without enumerating them all, other convenience functions include the distribute()
function (distributes a list of geometries so they have fixed spacing between them),
movement-related command related to the bounding box mentioned earlier (xmin/y-
max/etc), and the packer() function shown in Fig. 3 (packs geometries into the smallest area
possible). These single-line convenience functions increase the readability of the code and
are so useful they are implemented in virtually all vector-editing software. Lastly, PHIDL at-
tempts to use pre-existing conventions from related software where possible. Table 1 shows
the variations of nomenclature used in related geometry-editing software (including GDS
editing software and vector-editing software). For the sake of user ease, PHIDL attempts to
follow the most widely-used conventions.

Key elements of geometry library

Here we list a few of the pre-made geometries available in the built-in phidl.geometry. A
more complete list can be seen in the online documentation† .

Basic shapes
These are shapes which were included due to their widespread utility. They include functions
such as rectangle(), arc(), circle(), ellipse(), ring(), and more. We note that
although a circle is a subset of an ellipse, it is also one of the most commonly used shapes,
so to match user expectations circle() is provided as shortcut to the ellipse() function.
Similarly there are rectangle variants such as bbox() that can be used to easily draw a
bounding box around an object, and compass() which is a rectangle with ports placed
on each edge. We note that geometry-creating functions in PHIDL don’t have arguments
to specify the position–this is done to avoid “rubber-stamp” style design. Additionally,
†
https://phidl.readthedocs.io/

6
these arguments are often ambiguous – for example, if a rectangle-generation function has a
position argument, it will be unclear whether that position refers to the rectangle center or
one of its corners. To facilitate code clarity, PHIDL encourages users to perform operations
like centering after creation of the geometry (e.g. my_rectangle.center = (10,5)) The
text() function is another basic one which can print multiline text with left, right, or center
justification. In addition to having full unicode font support, it also includes the DEPLOF
font, which was specially designed for photolithography and electron-beam lithography to
avoid islands/delamination of resist.

Paths / waveguides
The package also includes a highly efficient module for creating smooth curves, particularly
useful for creating waveguide structures such as those used in photonics. The process is
designed to be intuitive and powerful, by conceptually separating the specification of the
path from the specification of the cross-section. The path can be constructed piece by piece
using the append() functionality and several convenient built-in component functions (such
as the arc() section, the straight() section, or the straight-to-bend euler() curve section,
also known as a track transition or clothoid). Separately, the cross-section can be defined in
a similar manner. By combining the 1D path and the 1D cross-section, the final 2D polygons
can be easily output as shown in Fig. 4. PHIDL also includes a fast implementation of the
Ramer-Douglas–Peucker algorithm11 for polygon simplification, as one of the chief concerns
of generating smooth curves is that too many points are generated, inflating file sizes and
making boolean operations computationally expensive. The path module also comes with a
built-in transition() function that allows simple transitioning between two cross-sections
along an arbitrary Path.

Figure 4: Path / waveguide module in phidl. (a) Construction of a path from circular arc()
sections, straight() sections, and straight-to-bend euler() sections. (b) Combining the
1D path with a 1D cross-section to create a set of 2D polygons.

7
Boolean / offset
The boolean() function can perform the standard suite of AND (intersection), OR (union),
NOT (subtraction), and XOR (exclusive disjunction) operations, and the offset() function
provides grow/shrink operations for polygons. The codebase for this is provided by the Clip-
per library12 by way of gdspy. Performing boolean and offset operations on 2D geometry can
be computationally intensive, so we have added functionality to optimize those operations.
By setting the num_divisions argument in boolean() and offset(), the user can choose
to slice the geometry into multiple subsections before performing the operation. Since the
boolean and offsetting operations are generally more complex than O(N ) for N points, di-
viding the geometry into multiple sections can speed up the operation significantly, as shown
in Fig. 5. This process enables significant speedup, but since the the subdivision process
adds computational overhead, too-small or too-large n can result in increased computation
time.

102 3.0 million points

Computation time (s)

1.5 million points

0.3 million points

101

100
1 2 4 6 8 10 12 14 16 18
Number of divisions

Figure 5: Speedup of boolean operations by subdivision. Shown is the effect of varying the
num_divisions parameter when performing the boolean() on a large number of random
shapes. When n is greater than 1, the geometry is partitioned into n×n equal-sized rectangles
and the boolean operation is applied to each subdivision sequentially, enabling significant
speedup of the operation.

Lithographic test structures

Although lithographic tests used in cleanroom fabrication are often application-specific, we
found that easy access to a few of the most common structures has been critical to encour-
age users to include lithographic tests in their designs. Among these test structures include
litho_steps() (tests linewidth and resolution), litho_star() (tests linewidth and alias-
ing), and litho_calipers() (checks alignment accuracy between two layers). We have also
implemented a filling function fill_rectangle(), which can be used to populate empty
areas of a wafer with configurable-density rectangles for more uniform photoresist develop-
ment.

8
Application-specific geometries
There are several geometries in PHIDL which are meant for superconducting and photonic ge-
ometry creation. Included are functions like snspd(), for creating superconducting nanowire
single-photon detectors using optimized curves which reduce the problem of superconducting
“current crowding”. There are also test structures such as test_ic() For photonic creation,
the phidl.path functions allows users to create complex paths and waveguides by speci-
fying (1) a path of points that the path should follow and (2) the 1D cross-section of the
path. There are also functions meant for automatic routing between paths. For example,
route_basic() can connect the ports of two paths together using a smooth sine curve. For
more advanced routing, route_manhattan() will smoothly connect paths together along a
manhattan grid.

User-defined geometries
Of course, the user can always create their own geometry functions within phidl. In this
process, users are encouraged to make use of the same style as the phidl.geometry library:
(1) the function should return only a single Device (2) metadata about the geometry should
be saved in the Device’s .info variable, which is a Python dictionary meant for saving
(and later retrieving) information about the geometrical object. If the user finds them-
selves designing geometries which take a large amount of time to compute, they can use the
@device_lru_cache decorator, which allows caching of geometries so they only have to be
calculated once per set of arguments.

Conclusion
In summary, PHIDL is geometry manipulation tool aimed at scientists, graduate students,
and anyone trying to script the creation of 2D geometries. Like Python itself, it aims to be
readable, and intuitive. To this end, the software design focuses on usability, flexibility, and
simplicity. The goal has been to develop a GDSII-creation tool which can be picked up by
new or returning users in a few minutes, allowing users to get to desiging as quickly as possible
while maintaining an architecture robust enough to build extremely complex geometries. It
comes with a large library of premade geometry functions and many convenience functions
for the creation, manipulation, and debugging of large scripted geometries. There are also
opportunities to further optimize PHIDL, for instance using a compiled backend (such as
KLayout5 ) as a faster geometry database, or using just-in-time compilation packages such
as numba13 for computationally-expensive operations.
The U.S. Government is authorized to reproduce and distribute reprints for governmental
purposes notwithstanding any copyright annotation thereon. Certain software and commer-
cial materials are identified in this paper to foster understanding. Such identification does
not imply recommendation or endorsement by the National Institute of Standards and Tech-
nology, nor does it imply that the materials or equipment identified are necessarily the best
available for the purpose.

9
References
1
Lucas H. Gabrielli. gdspy.
2
Stéfan van der Walt, S Chris Colbert, and Gaël Varoquaux. The NumPy Array: A
Structure for Efficient Numerical Computation. Computing in Science & Engineering,
13(2):22–30, mar 2011.
3
Helge Gehring, Matthias Blaicher, Wladick Hartmann, and Wolfram H. P. Pernice. Python
based open source design framework for integrated nanophotonic and superconducting
circuitry with 2D-3D-hybrid integration. OSA Continuum, 2(11):3091, 2019.
4
K. C. Balram, D. A. Westly, M. Davanco, K. E. Grutter, Q. Li, T. Michels, C. H. Ray,
L. Yu, R. J. Kasica, C. B. Wallin, I. J. Gilbert, Brian A. Bryce, G. Simelgor, J. Topolancik,
N. Lobontiu, Y. Liu, P. Neuzil, V. Svatos, K. A. Dill, N. A. Bertrand, M. Metzler, G. Lopez,
D. A. Czaplewski, L. Ocola, K. A. Srinivasan, S. M. Stavis, V. A. Aksyuk, J. A. Liddle,
S. Krylov, and B. R. Ilic. Nanolithography Toolbox: Device design at the nanoscale. In
Conference on Lasers and Electro-Optics, page ATh3B.6, Washington, D.C., 2017. OSA.
5
Matthias Köfferlein. KLayout.
6
Wim Bogaerts, Pieter Dumon, Emmanuel Lambert, Martin Fiers, Shibnath Pathak, and
Antonio Ribeiro. IPKISS: A parametric design and simulation framework for silicon pho-
tonics. In The 9th International Conference on Group IV Photonics (GFP), pages 30–32.
IEEE, aug 2012.
7
A. N. McCaughan, V. B. Verma, S. M. Buckley, J. P. Allmaras, A. G. Kozorezov, A. N.
Tait, S. W. Nam, and J. M. Shainline. A superconducting thermal switch with ultra-
high impedance for interfacing superconductors to semiconductors. Nature Electronics,
2(10):451–456, oct 2019.
8
John D. Hunter. Matplotlib: A 2D Graphics Environment. Computing in Science &
Engineering, 9(3):90–95, 2007.
9
Ronald; Broeke and Xaveer Leijtens. Nazca design photonic IC design framework.
10
Jürgen Thies. LayoutEditor.
11
David H Douglas and Thomas K Peucker. Algorithms for the reduction of the number
of poitns required to represent a digitized line or its caricature. Cartographica: The In-
ternational Journal for Geographic Information and Geovisualization, 10(2):112–122, dec
1973.
12
Angus Johnson. Clipper - an open source freeware library for clipping and offsetting lines
and polygons.
13
Siu Kwan Lam, Antoine Pitrou, and Stanley Seibert. Numba. In Proceedings of the
Second Workshop on the LLVM Compiler Infrastructure in HPC - LLVM ’15, pages 1–6,
New York, New York, USA, 2015. ACM Press.

10