The least resistance path to get ngspice working on macOS is brew install ngspice. However, the version shipped lags ngspice releases and lacks certain features such as OSDI support for Verilog-A models and OpenMP support for multi-threaded operation.

This article walks through the steps for compiling ngspice from source on Apple Silicon, the dependencies and the ./configure options worth knowing about. This has been tested with ngspice-46 on macOS Tahoe 26.5.1 on a MacBook Pro with the M4 Pro chip.

Prerequisites

The first prerequisite is that the Xcode command line tools are installed. This is where we get clang, make and header files. Make sure you have run xcode-select --install first if you haven’t already.

Next, Homebrew needs to be in place. We’re going to use it to get a bunch of libraries the ngspice build depends on. You can install it by using the bootstrap script /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)". The rest of the instructions here assume that Homebrew is installed under its default path for Apple Silicon of /opt/homebrew.

Installing build dependencies

brew install bison flex readline ncurses libomp
brew install --cask xquartz

flex/bison are the lexer/parser combination required for ngspice’s grammar engine. The libraries shipped by macOS are too old, and we get the new ones from homebrew. readline and ncurses are required to handle the interactive command line and terminal interactions. libomp is the OpenMP runtime, and is required for multi-core operation.

xquartz is the big one amongst these. It’s a pre-built cask, providing the X11 runtime and installs to /opt/X11. It’s required to build ngspice with the --with-x configuration that enables the internal waveform viewer. It’s entirely possible to skip this (and freetype which enables font rendering for X11) if you intend to use ngspice only in batch mode.

If you ever want to install directly from the git repository, you’ll also need the following additional packages.

brew install autoconf automake libtool

Getting the ngspice source

You can download ngspice from its SourceForge repository.

curl -L -o ngspice-46.tar.gz "https://sourceforge.net/projects/ngspice/files/ng-spice-rework/46/ngspice-46.tar.gz/download"
tar xzf ngspice-46.tar.gz && cd ngspice-46

Configuring the build

The first step in configuring is to set the environment variables for the compiler and linker flags so they refer to the dependencies we just installed. Homebrew packages aren’t on the default compiler search path, so CPPFLAGS/LDFLAGS point clang at them and PATH makes sure the right flex/bison executables run first.

export PATH="/opt/homebrew/opt/bison/bin:/opt/homebrew/opt/flex/bin:$PATH"
export CPPFLAGS="-I/opt/homebrew/opt/readline/include -I/opt/homebrew/opt/ncurses/include -I/opt/homebrew/opt/libomp/include -I/opt/X11/include/freetype2"
export LDFLAGS="-L/opt/homebrew/opt/libomp/lib -lomp -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/opt/ncurses/lib -L/opt/X11/lib"

The tarball used comes with a pre-made ./configure, so we do not need to use autogen.sh like we would if we were building directly from the repository. There are a few different options for the ngspice configuration:

• --with-x - builds the X11 waveform viewer. Good for observing simulation results directly from the interactive shell
• --enable-xspice - enables the XSPICE extension: event-driven/mixed-signal simulation and code-model plugin system
• --enable-cider - enables the CIDER extension: a coupled numerical device simulator, allowing the simulation of critical devices using physical/numerical models
• --enable-osdi - enables the OSDI loader, an interface to load in Verilog-A compiled models at runtime
• --enable-predictor - enables the predictor algorithm that estimates the next time-step’s solution to speed up transient simulation
• --enable-pss - enables periodic steady-state analysis
• --enable-openmp - enables OpenMP multi-threading for parallel matrix/device evaluation
• --with-readline=yes - uses GNU readline for command-line history and line editing in the interactive shell
• --disable-debug and CFLAGS="-O2" - drops debug symbols for a faster optimized build and sets the compiler optimization level to the standard -O2

./configure \
  --with-x \
  --enable-xspice \
  --enable-cider \
  --enable-osdi \
  --enable-predictor \
  --enable-pss \
  --with-readline=yes \
  --enable-openmp \
  --disable-debug \
  --prefix="/opt/ngspice" \
  CFLAGS="-O2"

If you’d like to install it under a different directory than the specified /opt/ngspice/ you can change the prefix option.

./configure \
  ...
  --prefix="$HOME/.local/ngspice" \
  ...

Compiling and installing

After configuring, you can compile ngspice (in parallel) by:

make -j$(sysctl -n hw.ncpu)

You can then install it into the prefix location by:

sudo make install

The sudo will only be required if you’re installing in a system area.

Make sure that the installation directory is in your path:

export PATH="$PATH:/opt/ngspice/bin"

Verifying the installation

Run ngspice --version and you should see:

➜  ~ ngspice --version
******
** ngspice-46 : Circuit level simulation program
** Compiled with KLU Direct Linear Solver
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2025, The ngspice team.
** Please get your ngspice manual from https://ngspice.sourceforge.io/docs.html
** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html
******

Better yet, you can launch ngspice and use the version -f command inside the ngspice shell to display the extensions:

ngspice 1 -> version -f
******
** ngspice-46 : Circuit level simulation program
** Compiled with KLU Direct Linear Solver
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2025, The ngspice team.
** Please get your ngspice manual from https://ngspice.sourceforge.io/docs.html
** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html
**
** CIDER 1.b1 (CODECS simulator) included
** XSPICE extensions included
** Relevant compilation options (refer to user's manual):
** OpenMP multithreading for BSIM3, BSIM4 enabled
** --enable-predictor
**
******

Wrapping up

With that, you have a feature-complete ngspice built from source — OSDI, OpenMP, XSPICE and the X11 viewer all compiled in, none of which Homebrew gives you. This is the engine the rest of the flow plugs into: OSDI lets you load Verilog-A compact models (compiled with OpenVAF), OpenMP puts the extra cores to work, and the interactive viewer gives you a quick look at results without leaving the shell. I’ll try to cover most of these in a follow-up post.

The Ubuntu version I was using (22.04) was getting too old for development work and I desperately needed an upgrade. It was a pleasant surprise to see that WSL now supported Fedora out of the box, which has been my go-to choice for a distro for a while. I like using the bleeding-edge versions of the development packages, and things breaking occasionally makes life interesting.

This tutorial will provide a guide to install and bring-up the basic toolkit. The installation paths will look like:

• ~/analog - root directory for all work
• ~/analog/tools - open source EDA software
  • ~/analog/tools/bin - binaries
  • ~/analog/tools/src - source files
• ~/analog/pdk - pdk installation
• ~/analog/wa - workarea directories for development

Installation

WSL

Installing Fedorra under WSL in Windows 11 is pretty straightforward.

wsl --install FedoraLinux-43

You can now use the newly installed WSL distribution by:

wsl ~

It’s a good idea to upgrade the packages before continuing any further.

sudo dnf upgrade

Tools

The toolset is the same as before.

• Schematic editor: xschem
• Simulator: ngspice
• VerilogA Model Interface: openvaf
• Layout: magic & klayout

Development Environment

sudo dnf install gcc g++ gdb make

xschem

Install prerequisites:

sudo dnf install flex bison
sudo dnf install libX11-devel libXrender-devel libXpm-devel
sudo dnf install tcl8-devel tk8-devel
sudo dnf install libjpeg-turbo-devel
sudo dnf install xterm # required for the simulate command

The tcl8-devel and tk8-devel packages are chosen for compatibilty with magic, the Tcl 9.0 versions of these packages (tcl-devel and tk-devel) seemed to have a lot of issues with magic scripts; altough both tools compile and run with the latest versions as well.

Build and install xschem from the GitHub repository:

mkdir -p ~/analog/tools/src/xschem; cd ~/analog/tools/src/xschem
git clone https://github.com/StefanSchippers/xschem.git ./
# build and install
./configure --prefix=$HOME/analog/tools
make -j 16
make install

ngspice

Install prerequisites:

sudo dnf install autoconf libtool automake
sudo dnf install libXaw-devel

Build and install ngspice from the SourceForge repository:

mkdir -p ~/analog/tools/src/ngspice; cd ~/analog/tools/src/ngspice
git clone https://git.code.sf.net/p/ngspice/ngspice ./
# build and install
./autogen.sh
mkdir release; cd release
../configure --prefix=$HOME/analog/tools --with-x --enable-cider --with-readline=yes --enable-predictor --enable-openmp --enable-osdi --enable-pss
make -j 16
make install

openvaf

OpenVAF is a Verilog-A compiler that compiles a restricted subset of the language into a OSDI (Open Source Device Interface) model; which can be loaded by the circuit simulators. The IHP SG13G2 PDK requires openvaf to compile the PSP 103 MOSFET, MOS varactor and 3-terminal resistor models.

Compiling OpenVAF is a challenge. Also, it’s development seems to have gone through a break and a revival, which makes compiling it from source a bit of a higher challenge.

For now, simply download the pre-compiled binary from here. I chose the latest 0.3 version ( openvaf-reloaded-osdi_0.3-31-gf47d557-linux_x64.tar.gz to be exact) and copied the binary to $HOME/analog/tools/bin.

magic

magic main branch does not compile successfully for Fedora 43. termio.h was removed from glibc 2.42 (April 2025) after ~37 years when it was deprecated by the standardization of termios.h in 1998. Thankfully, the replacements only constitute a small patch, which I hope will be merged to the main branch soon.

I have not detailed the changes here, as the developers seem to be aware fixes are under discussion here.

Install prerequisites:

sudo dnf install mesa-libGL-devel mesa-libGLU-devel

mkdir ~/analog/tools/src/magic; cd ~/analog/tools/src/magic
git clone https://github.com/RTimothyEdwards/magic ./

Patching for Fedora 43

Compiling directly seems to cause some issues with old-style function declarations, where their prototypes are declared without the arguments. You need to change the configure script to the following:

( CFLAGS=${CFLAGS:-"-g -std=gnu89"}; export CFLAGS; cd scripts ; ./configure "$@" )

Afterwards, you can build and install magic:

# build and install
./configure --prefix=$HOME/analog/tools
make -j 16
make install

klayout

Install prerequisites:

sudo dnf install qt6-qtbase-devel qt6-qt5compat-devel
sudo dnf install qt6-qtmultimedia-devel qt6-qtsvg-devel qt6-qttools-devel
sudo dnf install ruby-devel python-devel
sudo dnf install libgit2-devel

mkdir ~/analog/tools/klayout; cd ~/analog/tools/klayout
git clone https://github.com/KLayout/klayout ./
# build - this will take a while
./build.sh -option -j16

klayout places all its executables and libraries under a bin-release folder. Instead of copying these to ~/analog/tools/bin we’re going to directly refer to them by prepending these to PATH and LD_LIBRARY_PATH.

klayout also requires the gdsfactory python package to run the pcells defined in the pdk. Install these packages to the default python instance via:

pip install gdsfactory
pip install --upgrade attrs

PDK - IHP SG13G2

The IHP 130nm BiCMOS Open Source PDK is available at https://github.com/IHP-GmbH/IHP-Open-PDK. Unlike SKY130 in the open_pdks flow, the PDK does not need to be built and can be used directly after cloning the repository.

mkdir -p ~/analog/pdk/IHP-Open-PDK; cd ~/analog/pdk/IHP-Open-PDK
git clone https://github.com/IHP-GmbH/IHP-Open-PDK.git ./

After cloning, you also need to populate all the submodules the repository is referencing via:

git submodule update --init --recursive

Workarea Setup

Create a simple workarea:

mkdir -p ~/analog/wa/dev; cd ~/analog/wa/dev

Create a source.sh file in this workarea. Source this before running any of the tooling.

# add the tools to the path
export PATH=$HOME/analog/tools/bin:$PATH
export PATH=$HOME/analog/tools/src/klayout/bin-release:$PATH
export LD_LIBRARY_PATH=$HOME/analog/tools/src/klayout/bin-release:$LD_LIBRARY_PATH
# some useful environment variables
export PDK_ROOT=$HOME/analog/pdk/share/pdk
export PDK=ihp-sg13g2
export WA_ROOT=`pwd`

xschem

The PDK comes with an install script that does a couple of things: compile the Verilog-A model libraries and copy the required xschemrc to the current workarea, and the .spiceinit file to $HOME/.

$PDK_ROOT/$PDK/libs.tech/xschem/install.py

I’m not a big fan of cluttering my $HOME/ (unlike in real life), so another option is to place the .spiceinit file under $WA_ROOT/simulations/.spiceinit.

You can now start xschem and the example simulations should work.

klayout

You can launch klayout in editor mode by:

klayout -e

When launching klayout for the first time, you need to import the technology files. To do this:

1. Run Tools -> Manage Technologies
2. Right click on the technology list and choose Import technology
   1. Choose $PDK_ROOT/$PDK/libs.tech/klayout/tech/sg13g2.lyt
   2. “sg13g2 - IHP SiGe 130nm Technology” should appear in the technology list
3. Restart klayout. It should now come with the SG13G2 PDK menu loaded by default.

I had a few requirements for this storage solution:

• I wanted to use smaller drives in a RAID array instead of a single large-capacity one to safeguard against disk failures.
• I wanted to abstract away the hardware to easily extend the storage in the future.
• I wanted peak performance, rather than enterprise level flexibility.
• I wanted ease of access for the files on the system from various systems in my home.

In order to achieve these, I decided to build a Linux system that ran RAID, LVM, an XFS file system and a Samba file server. I had set up something very similar for a laboratory build years ago, so I thought it would be quite straightforward. It wasn’t. The setup procedure is documented in the rest of this article.

RAID Array

I wanted to go for a RAID solution to protect against hardware failures. The reasonable options were RAID1, RAID5 or RAID6 arrays. I found the best compromise between disk usage and safety to be the RAID5 array, which uses a single parity disk to safeguard against a single drive failure.

Before setting up RAID, we first need to create partitions in the drives that will be used to build the array.

➜  ~ fdisk /dev/sda

Inside fdisk, follow these steps:

1. Press g to create a new empty GPT partition table.
2. Press n to create a new partition. Press Enter through the prompts to accept the defaults, which will use the entire disk.
3. Press t to change the partition type.
4. Type raid (for “Linux RAID”) and press Enter.
5. Press w to write the changes to the disk and exit.

Repeat this for all disks you want in the array. In my case, I was building with three drives: /dev/sda, /dev/sdb and /dev/sdc. You should be able to verify that these partitions have been created by seeing the /dev/sd[abc]1 appear.

➜  ~ sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdc1

You can now see the RAID array status by:

➜  ~ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Sun Aug  3 15:04:36 2025
        Raid Level : raid5
        Array Size : 15627786240 (14.55 TiB 16.00 TB)
...
       Update Time : Mon Aug  4 00:04:07 2025
             State : clean, degraded, recovering
    Active Devices : 2
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 1
...
    Rebuild Status : 78% complete

              Name : fedora:0  (local to host fedora)
              UUID : c89b4882:2eb89e2e:b46483e8:52939c5c
            Events : 6190

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       49        2      spare rebuilding   /dev/sdc1

At this point the array is ready to use, but it’s in a clean, degraded, recovering state. This means that it will not perform until the rebuilding process is finished, and the data on it will not be safe, as a drive failure at this stage can cause a total loss.

The rebuilding process will take long: in my case, it was over 10 hours. During this time the disks will see heavy access and it is a good idea to ensure that they have good ventilation. Halfway through the process, I realized the temperature of my disks had climbed to 60°C because I had all the case fans disconnected.

There are a couple more steps to ensure that the RAID array goes online with the system. I am not sure how much of the following is required, as there are reports that Fedora actually is able to detect the array and bring it online without any intervention. However, running the below worked for me.

➜  ~ sudo mdadm --detail --scan | sudo tee /etc/mdadm.conf
➜  ~ sudo dracut -f

LVM

The next layer in the storage process is the Logical Volume Manager. LVM allows a flexible way to manage disk space, acting as a layer of abstraction between the physical disks and actual partitions the operating system uses. It has three components:

1. Physical Volumes: PVs are the actual disks or partitions, or in our case, the RAID array.
2. Volume Groups: VGs are the storage pools that combine one or more PVs into a large storage space.
3. Logical Volumes: LVs are the actual virtual partitions that get formatted with a file system and mounted to be used by the operating system.

The benefit of using LVM is the flexibility it provides beyond the physical constraints of the actual disks. In this case, we might want to a completely new RAID array and have LVs that span across both; or perhaps move an LV from one RAID array to another.

For the flexibility it provides, it is also extremely easy to set up. First label the disks to be used as PVs:

➜  ~ sudo pvcreate /dev/md0

Then, to create the VG, which will only contain /dev/md0 for now:

➜  ~ sudo vgcreate vg_storage /dev/md0

Finally, to create the LV that spans across the entire free space on /dev/md0:

➜  ~ sudo lvcreate -l 100%FREE -n lv_storage vg_storage

This should make the LV now available at /dev/vg_storage/lv_storage and /dev/mapper/vg-storage-lv_storage. At this point, this is a partition, very much like a /dev/sda1 that we can format and mount.

XFS File system

Finally, we get to format our virtual partition and mount it. An important choice here is the file system. The ext4 file system is a good choice, but xfs is reported to have a slight edge on performance in RAID arrays, due to its awareness of the underlying RAID geometry. The important parameters to know while creating an xfs file system are the Stripe Unit(su) and Stripe Width(sw). We use the information from the RAID array to get these:

➜  ~ sudo mdadm --detail /dev/md0

/dev/md0:
           Version : 1.2
     Creation Time : Sun Aug  3 15:04:36 2025
        Raid Level : raid5
...
        Chunk Size : 512K
...
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       3       8       49        2      active sync   /dev/sdc1

1. Stripe Unit(su) is the Chunk Size. In our case, this is 512K.
2. Stripe Width(sw) is a multiplier of su, and is the number of data disks in a RAID device. The data disks exclude the parity disks, which take up one disk in a RAID5 configuration. In our case, this is 2.

➜  ~ sudo mkfs.xfs -f -d su=512k,sw=2 /dev/vg_storage/lv_storage

Unfortunately, this selection of the RAID geometry is a one-time process during file system creation. Extending the RAID array with another disk will change the geometry (sw will increase to 3) and the underlying file system will not be optimally sized for it.

Mounting the File system

➜  ~ sudo blkid /dev/vg_storage/lv_storage
/dev/vg_storage/lv_storage: UUID="582846f1-c651-4794-a1d4-064ca3fc8550" BLOCK_SIZE="4096" TYPE="xfs"

Add this UUID as a mount point to /etc/fstab.

#
# /etc/fstab
# Created by anaconda on Sun Aug  3 00:57:19 2025
...
UUID=582846f1-c651-4794-a1d4-064ca3fc8550 /mnt/storage xfs defaults,noatime 0 2

The noatime is an parameter telling the system not to update the access time of the files stored. This offers a slight performance boost.

Finally, execute all the mounts in the /etc/fstab by running:

➜  ~ sudo mount -a

Samba Server

The last piece of the puzzle is the Samba server. With this, the Windows machines on the network can access the files hosted on the Linux NAS. I wanted to set up two types of shares, a public one anyone in my home network could access; and a private one that would require authentication.

Samba Installation

Setting up Samba is fairly forward. Install the packages, enable it through the firewall and we’re done.

First install Samba by:

➜  ~ sudo dnf install samba

Enable Samba through the firewall.

➜  ~ sudo firewall-cmd --get-active-zone
FedoraWorkstation (default)
  interfaces: eno1

➜  ~ sudo firewall-cmd --permanent --zone=FedoraWorkstation --add-service=samba
➜  ~ sudo firewall-cmd --reload

Public Share

I created the public share under /mnt/storage/public and created a new sharepub group, so that the members of this group will have access to the share under Linux as well.

➜  ~ sudo mdkir /mnt/share/public
➜  ~ sudo chown -R nobody:sharepub /mnt/share/public
➜  ~ sudo chmod -R 2775 /mnt/storage/public

The chmod sets the setgid flag for the directory, meaning that all files and directories created under it will inherit the group ownership rules.

Edit the Samba configuration file at /etc/samba/smb.conf.

...
[global]
        workgroup = SAMBA
        security = user
...
        map to guest = bad user
...
[public]
        comment = public
        path = /mnt/storage/public
        public = yes
        writable = yes
        browsable = yes
        guest ok = yes
        read only = no
        create mask = 0664
        directory mask = 0775
        force user = nobody
        force group = sharepub

Here we define the [public] share (which will be accessed from Windows clients at \\ip-address\public) at path = /mnt/storage/public in the Linux file system. The guest ok = yes statement tells Samba that we do not need an user to authenticate to be able to access the share. The rest are fairly self explanatory, allowing users to browse, read and write to the folder.

The create mask = 0664 and directory mask = 0775 ensures all users can read these files, but only members of the sharepub group are allowed to edit them. The force user = nobody and force group = sharepub statements sets the user and the group of newly created files;

The final step on the Linux side is to ensure that SELinux does not block the Samba daemon from accessing the shared folder. Run the following to tag the hierarchy with the samba_share_t:

➜  ~ sudo semanage fcontext -a -t samba_share_t "/mnt/storage/public(/.*)?"
➜  ~ sudo restorecon -Rv /mnt/storage/public

Restart the samba service:

➜  ~ sudo systemctl restart smb nmb

Finally, on the Windows side, there might be a Group Policy Setting that blocks users to access the public share without authentication. From gpedit.msc You need to go to Computer Configuration -> Administrative Templates -> Network -> Lanman Workstation and enable Enable insecure guest logons.

After following these steps, you should be able to navigate to ``\ip-adress\public` and access the drive, without being prompted for a username or password.

Private Share

I created the private share under /mnt/storage/private and created a new shareprv group.

➜  ~ sudo mdkir /mnt/share/private
➜  ~ sudo chown -R cgurleyuk:shareprv /mnt/share/private
➜  ~ sudo chmod -R 2770 /mnt/storage/private

The /etc/samba/smb.conf is modified to define the new private storage area:

[private]
        comment = private
        path = /mnt/storage/private
        read only = no
        browsable = yes
        writable = yes
        guest ok = no
        valid users = cgurleyuk @shareprv
        create mask = 0660
        directory mask = 0770

Here we define valid users = cgurleyuk @shareprv meaning that the user cgurleyuk and members of the group shareprv will be able to access the share. Compared to the public share, the create and directory masks have 0660 and 0770, disabling public access on the Linux side.

Finally, to remove SELinux restrictions the new hierarchy is tagged with samba_share_t:

➜  ~  sudo semanage fcontext -a -t samba_share_t "/mnt/storage/private(/.*)?"
➜  ~  sudo restorecon -Rv /mnt/storage/public

Restart the samba service:

➜  ~ sudo systemctl restart smb nmb

After following these steps, you should be able to navigate to ``\ip-adress\private` and access the drive after being prompted for a username and password.

Troubleshooting

There are a couple of issues I ran into while trying to access these shares from the Windows server. Firstly, make sure that the Credential Manager on Windows does not have a login stored. If you have a login stored already, you might run into the issue that Windows prompts for a password each time you try to access the public share as well.

Also, if you already log in as an anonymous user, and then try to access the private drive; you might run into authentication issues as well. Windows establishes a connection to the public share using the anonymous guest user; but since the private share is on the same server and you try to login with a different user account, Windows will reject opening the second connection. This especially is problematic if you map a network drive as the guest user, as there is no way to remove the connection other than simply removing the network drive.

In order to resolve this issue, you need to remove all network drive mappings; clear cached credentials and finally delete all active network connections by:

net use * /delete

After this, you need to login to the private share first, and give your username and password. With the above Samba setup; you should be able to access both the private and public shares with the authenticated user.

The SKY130A open-source analog flow, with ngspice and xschem, supports DC annotations. However, I’ve found that these are largely limited to node voltages, which can be somewhat limiting. A few additional steps are required to get complete information about the operating points of transistors and here I’ll try to explain how to complete the picture.

Saving MOS Transistor Operating Points

In the SKY130A PDK, MOS transistors are defined as macromodels: parametrizable subcircuits that instantiate the actual transistor device internally. This approach seems to have been chosen to enable automatic model selection via width/length and also to conduct parameter calculations (mainly related to mismatch). A typical model definition looks like the following:

*  Nmos Model
.subckt  sky130_fd_pr__nfet_01v8  d g s b  mult=1
.param  l = 1 w = 1 nf = 1 ad = 0 as = 0 ...
Msky130_fd_pr__nfet_01v8  d g s b nshort_model l = {l} w = {w} ad = {ad} as = {as} ...

.model nshort_model.1 nmos
+ level = 54 lmin = 8E-6 lmax = 2.02E-5 wmin = 7E-5
+ wmax = 1.01E-3 version = 4.5
...

.model nshort_model.2 nmos
+ level = 54 lmin = 4E-6 lmax = 8E-6 wmin = 7E-6
+ wmax = 1.01E-3 version = 4.5
...

.ends sky130_fd_pr__nfet_01v8

Here the line .subckt sky130_fd_pr__nfet_01v8 d g s b mult=1 ... defines the subcircuit for the transistor and the line Msky130_fd_pr__nfet_01v8 d g s b nshort_model l = {l} w = {w} ... defines the transistor instantiation itself. What follows are numbered model definitions starting with .model nshort_model.1 nmos and featuring the lmin, lmax, wmin, wmax parameters to define the geometry range the model is valid for.

When this device is netlisted through xschem, it will express that it is a subcircuit instantiation by prefixing it with an X. A typical device instantiation will look like:

XM3 von vip vtail vss sky130_fd_pr__nfet_01v8 L=0.5 W=10 nf=1 ...

ngspice does not save the evaluated operating point information for these models (such as id, gm, vdsat) by default. It has to be instructed to save these parameters if you want to annotate them. This is achieved by a save command in the netlist:

.save @m.XDUT.XM3.msky130_fd_pr__nfet_01v8[id]
.save @m.XDUT.XM3.msky130_fd_pr__nfet_01v8[gm]
...

The format of the save command generally follows: .save @m.{path}.msky130_fd_pr__{model}[{param}]. Here {path} refers to the full path to the device subcircuit. In the above example, the device is XM3 which is in an amplifier XDUT, so the full path is XDUT.XM3. The {model} refers to the actual model of the device, and in the example, it is nfet_01v8. Generally, the model name is printed on the symbol in xschem. Finally, {param} is the operating point information to be saved.

When the netlist is run with these save commands, running a print all command will reveal that the operating point information is saved for the device:

ngspice 533 -> print all
...
@m.xdut.xm3.msky130_fd_pr__nfet_01v8[id] = 9.579547e-6
@m.xdut.xm3.msky130_fd_pr__nfet_01v8[gm] = 2.409997e-4
...

Automating .save Commands

It can get quite unwieldy to write .save commands for a large number of devices. A simple Python script makes it easy to generate all the save commands for all transistors in a netlist. It reads in a .spice netlist file and generates a .save file that has all the save commands for all devices and the specified parameters.

block = 'amp'
testbench = 'dc'
subcircuit = 'xdut'
params = ['id', 'gm', 'gds', 'vdsat', 'vth']

fname_spice = f'{block}/simulation/tb_{block}_{testbench}.spice'
fname_save = f'{block}/simulation/tb_{block}_{testbench}.save'

with open(fname_spice, 'r') as f_spice:
    with open(fname_save, 'w') as f_save:
        lines = f_spice.readlines()

        for i, line in enumerate(lines):
            if line.startswith('XM'):
                tokens = line.split()
                name = tokens[0]
                model = tokens[5]

                for param in params:
                    f_save.write(f'.save @m.{subcircuit}.{name}'
                                 f'.m{model}[{param}]\n')

Unfortunately, this script is quite limited in scope. It only works for transistors instantiated within a single subcircuit (named via the subcircuit = 'xdut') line. A more generic version could traverse the entire SPICE netlist, build a tree out of all the subcircuit instantiations and populate the .save file.

Finally, this .save file can be included in your netlist via an .include tb_{block}_{testbench}.save command, keeping the actual netlist definition uncluttered.

DC Operating Point Annotation in xschem

Default symbols for SKY130A devices in xschem already come with text boxes that annotate some parameters like id, gm, vds and vgs. These are quite useful ss it is but an extension with some additional small-signal parameters gives more complete information about the device’s operating condition.

This can be achieved by editing the device symbol file through xschem (even though you’ll need write permissions to the pdk area) or directly editing the text file under $PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/{device}.sym. These symbols will already have some examples that can be extended, but the general format for the contents of a text box looks like this:

tcleval(vgs=[to_eng \{@#1:spice_get_voltage - @#2:spice_get_voltage \}]
vds=[to_eng \{@#0:spice_get_voltage - @#2:spice_get_voltage \}]
vdsat=[to_eng [ngspice::get_node v(\\@m.$\{path\}@spiceprefix@name\\.msky130_fd_pr__@model\\\\\\[vdsat\\\\])]] 
gds=[to_eng [ngspice::get_node \\@m.$\{path\}@spiceprefix@name\\.msky130_fd_pr__@model\\\\\\[gds\\\\]]] )

When the schematic is annotated, these boxes get evaluated and pull the operating point information saved in the raw file. This setup looks like this in xschem, and is what I currently use:

WSL

Use a Windows terminal to run:

wsl --install -d Ubuntu-24.04
wsl

This will drop you into the Linux terminal. You can now update the installed distribution by running:

sudo apt update
sudo apt upgrade

Tools

Currently the tools used are:

• Schematic editor: xschem
• Simulator: ngspice
• Layout: magic & klayout

Development Environment Installation

Since most of the tools are going to be built from source, we first need to install basic build tooling

sudo apt install gcc g++ gdb make

TODO: There might be missing items here.

xschem

mkdir ~/tools/xschem; cd ~/tools/xschem
git clone https://github.com/StefanSchippers/xschem.git ./
# install prerequisites
sudo apt install tcl-dev tk-dev libx11-dev 
sudo apt install libxrender-dev libx11-xcb-dev 
sudo apt install libcairo2-dev bison libxpm-dev libjpeg-dev
# build and install
./configure --prefix=$HOME/tools
make
make install

ngspice

mkdir ~/tools/ngspice; cd ~/tools/ngspice
git clone https://git.code.sf.net/p/ngspice/ngspice ./
# install prerequisites
sudo apt install autoconf libtool automake 
sudo apt install libxaw7-dev bison flex libreadline-dev
# build and install
./autoconf.sh
mkdir release; cd release
../configure --prefix=$HOME/tools --with-x --enable-cider --enable-predictor --enable-openmp --enable-osdi --enable-pss
make -j 16
make install

magic

mkdir ~/tools/magic; cd ~/tools/magic
git clone https://github.com/RTimothyEdwards/magic ./
# install prerequisites
sudo apt install m4 python3 libx11-dev tcl-dev tk-dev 
sudo apt install libcairo2-dev mesa-common-dev 
sudo apt install libgl-dev libglu1-mesa-dev zlib1g-dev
# build and install
./configure --prefix=$HOME/tools
make -j 16
make install

klayout

mkdir ~/tools/klayout; cd ~/tools/klayout
git clone https://github.com/KLayout/klayout ./
# install prerequisites
sudo apt install qt5-default qttools5-dev libqt5xmlpatterns5-dev
sudo apt install qtmultimedia5-dev libqt5multimediawidgets5 libqt5svg5-dev
sudo apt install ruby ruby-dev
sudo apt install python3 python3-dev
sudo apt install zlib1g-dev
sudo apt install libgit2-dev
# build - this will take a while
./build.sh

klayout places all its executables and libraries under a bin-release folder. Instead of copying these to ~/tools/bin we’re going to directly refer to them by adding the build artifacts to PATH and LD_LIBRARY_PATH.

klayout also requires the gdsfactory python package to run the pcells defined in the pdk. Install these packages to the default python instance via:

pip install gdsfactory
pip install --upgrade attrs

PDK

mdkir ~/pdk
mkidr ~/pdk/open_pdks; cd ~/pdk/open_pdks
git clone https://github.com/RTimothyEdwards/open_pdks ./
# build and install
./configure --prefix=$HOME/pdk --enable-sky130-pdk --with-sky130-variants=A
make -j 16
make install

Workarea Setup

MVP Experimentation Workarea

Create a simple workarea

mkdir -p ~/wa; cd ~/wa

Create a source.sh file in this workarea. We source this before running any of the tooling.

# add the tooling to the path
export PATH=$HOME/tools/bin:$PATH
export PATH=$HOME/tools/klayout/bin-release:$PATH
export LD_LIBRARY_PATH=$HOME/tools/klayout/bin-release:$LD_LIBRARY_PATH
# define some useful environment variables
export PDK_ROOT=$HOME/pdk/share/pdk
export PDK=sky130A
export WA_ROOT=`pwd`

xschem

Copy xschemrc into the local workarea and modify it to look for the correct location for the SKY130A libraries.

cp $HOME/pdk/share/pdk/sky130A/libs.tech/xschem/xschemrc ./
append XSCHEM_LIBRARY_PATH :${PDK_ROOT}/${PDK}/libs.tech/xschem

You can now start the schematic editor by:

xschem

magic

Copy the sky130A.magicrc file into the local workarea:

cp $PDK_ROOT/$PDK/libs.tech/magic/sky130A.magicrc ./.magicrc

You can now start the layout editor by:

magic

klayout

You can launch klayout in editor mode by:

klayout -e

When launching klayout for the first time, you need to import the technology files. To do this:

1. Run Tools -> Technology Manager
2. Right click on the technology list and choose Import technology
   1. Choose ~/pdk/share/pdk/sky130A/libs.tech/klayout/tech/sky130A.lyt
   2. sky130 - SkyWater 130nm technology should appear in the technology list
3. Change the paths to point to the correct locations
   1. Change Base path to ~/pdk/share/pdk/sky130A/libs.tech/klayout
   2. Change Layer properties to tech/sky130A.lyp
4. Restart klayout. It should now come with the Efabless sky130 menu loaded by default.

Methods to generate colored noise sources for time-domain simulations generally involve generating white noise and using a filter to produce the desired spectrum. Some of these time-domain filters can be trivial to build. A simple accumulator will be enough to approximate the \(1/f^2\) spectra. However, synthesizing time-domain filters that produce \(1/f\) spectra is much less trivial. Generally, filter stages show 20 dB/dec response, and it’s not clear how to combine these to build the 10 dB/dec spectra of pink noise.

This post presents a method that uses frequency-domain processing to generate colored noise sources to avoid this challenge altogether [1]. The idea is to manipulate the white noise signal to the desired shape in the frequency domain via a shaping function. The discrete Fourier transform (DFT) and its inverse are used to bring the signal back and forth, and all the processing is done in the frequency domain. The method presented is supposed to be a precursor to an post tackling the challenge of developing time-domain filters to generate \(1/f\) noise.

The Method

The algorithm for frequency domain filtering is quite straightforward. Take the DFT of a white noise signal to get its frequency domain representation, multiply it with the desired shaping function, and use the IDFT to return the signal to the time domain. Using Python and NumPy, it can be implemented as follows:

def generateColoredNoise(n_pts: int,
                         exp: float
                         ) -> NDArray[Shape['Any'], ComplexFloating]:
    # generate white noise with 0 mean
    x = np.random.randn(n_pts)
    x = x - np.mean(x)

    # generate the shaping function for the desired exponent
    f = generateShapingFunction(n_pts, exp)

    # frequency domain filtering
    x_f = np.fft.fft(x)
    y_f = x_f*f
    y = np.fft.ifft(y_f)
    return y

Running the above a few times and averaging the results shows the expected frequency-domain shape for different exponents. In the figure below, noise for each exponent was generated for 1000 runs and the magnitude of their outputs was averaged to show their spectra clearly. The signals have also been scaled to have the same approximate power, which makes them easy to compare in the time domain.

The figure below shows one of the runs in the time domain. Because of the scaling, the signals with the higher exponents tend to show much less high-frequency content and have approximately the same magnitude.

The only missing piece of the puzzle is generating the shaping function.

The Shaping Function

DFTs of real signals are symmetric around the Nyquist frequency. This property has to be maintained after shaping in the frequency domain to generate real, time-domain signals. The implication is that the shaping function must also be symmetric around \(f_s/2\). The function below generates these shaping functions for different powers of \(1/f\).

def generateShapingFunction(n_pts: int,
                            exp: float
                            ) -> NDArray[Shape['Any'], Float]:
    f = np.ones(n_pts)
    for i in range(1, int(n_pts/2)+1):
        f[i] = 1/i**(exp/2)
        f[n_pts-i] = f[i]

    return f

The figure below shows the gain of the generated functions in log-log space. The different slopes correspond to different exponents. The dashed line shows the Nyquist frequency, and the functions are symmetric with respect to it.

If this property were not satisfied, the resulting output of the IDFT would have significant imaginary content. Since the goal is to generate real-valued noise signals, this is undesirable. We can discard the imaginary component of the signal, but removing this data would make the magnitude response deviate from the desired shape. Even with the above implementation, there will still be some imaginary values after the IDFT, but their magnitude will be small enough to ignore and maintain the spectra. The imaginary output with symmetric shaping functions is attributed to the numerical resolution of the DFT/IDFT operations.

Comparison with Time-Domain Filtering

We can use the trivial case to compare the method to its time-domain equivalent. The time-domain filter for a \(1/f^2\) response can be implemented with a simple accumulator, implemented with one delay element and an adder.

The accumulator is driven with the same input signal used for the frequency-domain filter. The figure below compares the magnitude of their outputs’ PSD and their over-time behavior. The PSD magnitude shows a similar \(1/f^2\) response for both, whereas the time-domain signals look different. The two signals in the time domain have approximately the same amplitude, but the similarities end there.

The missing piece of information can explain these differences: the phase of the signals. Comparing the transfer functions of both filters in the frequency domain reveals the source of the difference. The transfer function of the frequency-domain filter is the shaping function itself. The transfer function of the accumulator in the z-domain is:

The magnitude of its transfer function in the frequency domain then can be written as:

The magnitude and phase responses for these transfer functions are plotted in the figure below. The accumulator shows a 90-degree phase shift at DC, which drops to 180 degrees at around \(f_s/2\). On the other hand, the frequency-domain filter shows a 0-degree phase shift across the entire band. Different frequency components are delayed differently for the accumulator, whereas the frequency-domain filter retains the phase of its input.

The second, and the less significant, difference originates from the time-domain accumulator’s behavior around frequencies close to \(f_s/2\). The accumulator does not maintain a \(1/f^2\) slope after its unity-gain frequency at \(f_s/6\), and the magnitude of its transfer function is 0.5 at \(f_s/2\).

Issues with Frequency-Domain Filtering

One might argue that frequency-domain filtering and time-domain filtering are equivalent. One could take the IDFT of the shaping function to get its impulse response and build a convolutional filter with it. Such an approach is entirely correct. The only difference between the two would be that the implementation is more efficient when utilizing the FFT.

The most prominent issue with this method is that it requires precomputing the entire noise signal. All samples that will be used must be computed before the start of the simulation and stored in memory. It is possible to quickly run into issues in long simulations requiring several such signals. A time-domain filter will generally require much less memory but might be computationally demanding during simulation.

A related problem is that simulation time must be known a priori to generate colored noise via frequency-domain filtering. The generated signals should be long enough to cover the entire length of the simulation. It is not trivial to stitch two signals generated via this method and achieve the same frequency-domain behavior due to windowing effects. The technique works well on noise signals that do not show specific features over time. However, utilizing it for generic filtering applications runs into windowing issues [2] that result in poor time domain responses.

The last one is not necessarily a unique problem to frequency-domain filtering. The simulation time must be estimated while synthesizing time-domain filters to find the number of stages that maintain the spectra to low frequencies. However, it’s much easier to overdesign since time-domain filters have significantly smaller memory requirements.

The Code

You can find the code used to generate the plots on GitHub.

References

[1] Algorithm for high quality 1/f noise? on Computational Science StackExchange

[2] Why is it a bad idea to filter by zeroing out FFT bins? on Signal Processing StackExchange

One example I came across is the simulation of an inductor for an LC oscillator in an electromagnetic simulator. Usually, the simulator exports single-ended Y-parameters for the two inductor terminals referenced to ground. However, what we care about is the behavior of differential inductance in the LC tank. So, the output needs to be transformed to mixed-mode to do any further analysis.

This article shows the derivation of mixed-mode Y/Z-parameters from their single-ended counterparts. It starts with a brief introduction to Y/Z-parameters followed by an analysis conducted via defining the differential and common-mode drive conditions for the two-port. At the end, a couple of example circuits demonstrate the expressions derived.

Single-Ended Y/Z-Parameters

Y/Z-parameters are used to define the behavior of linear electrical networks by specifying the relationship between the voltages and currents of its ports.

Y-parameters (also known as conductance parameters) relate the independent variables of port voltages to dependent variables of port currents. To derive the Y-parameters, we drive each port with a voltage source, while shorting all other ports and measure the currents into each port.

The Y-parameters 2-port are then defined using these measurements as the following.

These can be represented in matrix form as below.

Similarly, Z-parameters (impedance parameters) relate the independent variables of port currents to dependent variables of port voltages. This, in turn, means that we drive each port with an independent current source, while leaving open and measuring the voltage at every other port.

The Z-parameters for a 2-port can then be defined as the following.

These can be represented in matrix form as below.

Both sets of parameters completely describe the behavior of the linear circuit. They can also be converted from one to the other via matrix inversion.

Naturally, this requires the matrices to be invertible. There are some circuits for which the matrices will not be invertable, which implies that the other set of parameters tend to infinity.

Mixed-Mode Y/Z-Parameters

The label mixed-mode refers to the combination of and differential- and common-mode signaling over a pair of ports. A differential transmitter uses a balanced interface to send the singal and its inverse across a two-conductor channel, and a differential receiver responds to the voltage difference between the two conductors. In such a system, external interference appears in-phase on the two lines and the corruption of the differential-mode signal is avoided. As an additional benefit, the signal amplitude is doubled, which results in higher signal-to-noise ratio.

The differential- and common-mode voltages and currents in the case of a two-port driven with . The differential-mode is the out-of-phase (and generally the desirable) signal component, and the common-mode is the in-phase (and generally the parasitic) component.

The voltage and current expressions for the ports are as follows.

The expressions for the voltages are familiar, but the mixed-mode currents might be slightly confusing. The differential-mode current circulates into the first port and out of the second. The common-mode current is the total current going into both ports and coming out of the reference node.

Mixed-Mode Y-Parameters

Similar to their single-ended counterparts, mixed-mode Y-parameters relate these differential- and common-mode currents (dependent variables) to voltages (independent variables).

In matrix form, mixed-mode Y-paramaters are as below.

Converting Single-Ended to Mixed-Mode

Two conditions have to be considered to convert the single-ended Y-parameters to mixed-mode. In the first condition the ports are driven with oppsite polarity voltage sources. \( V_{CM} \) is set to zero, and the circuit is excited with \( V_{DM} \) only.

We can then derive \( I_1 \) and \( I_2 \) from the single ended Y-parameters.

Then, the differential and common-mode currents can be derived and \( V_{DM} \) can be substituted in for \( V \) to arrive at the final expressions.

In the second condition, the ports are driven with the same polarity voltage sources. \( V_{DM} \) is set to zero, and the circuit is excited with \( V_{CM} \) only.

Similarly, given the voltages at the ports under common-mode drive, we derive \( I_1 \) and \( I_2 \) from the single-ended Y-parameters.

Then, we derive the differential and common-mode currents under common-mode drive, and convert the variable V to the common-mode voltage \( V_{CM} \).

We can combine these expressions with their differential-mode drive counterparts in matrix form to arrive at the mixed-mode Y-parameters.

Mixed-Mode Z-parameters

Mixed-mode Z-parameters relate the differential and common-mode voltages (dependent variable) to currents (independent variable).

In matrix form, mixed-mode Z-paramaters are as below.

Converting Single-Ended to Mixed-Mode

Similar to the analysis for the Y-parameters, there are two conditions of consideration. In the first condition, the two-port terminals are driven with current sources with opposite polarity. This excites the circuit with \(I_{DM}\) while setting \(I_{CM}\) to zero.

In this case, the port currents are as below.

The port voltages, \(V_1\) and \(V_2\), then can be calculated from the single-ended parameters.

We can then derive the differential- and common-mode voltages for the ports.

For the scond condition, the two-port terminals are driven with current sources with the same polarity. This excites the circuit with \(I_{CM}\) while setting \(I_{DM}\) to zero.

The port voltages, \(V_1\) and \(V_2\), then can be calculated from the single-ended parameters.

We can then finally derive the remaining differential- and common-mode voltages for the ports.

We can combine these expressions with their differential-mode drive counterparts in matrix form to arrive at the mixed-mode Z-parameters.

Examples

Single-Ended Termination

The Z-parameters for the differential termination is as follows.

Using the expressions above, these can be converted to mixed-mode Z-parameters.

The differential impedance seen into the differential port is doubled and the common-mode impedance is halved. In single-ended systems that use 50Ω characteristic impedance, the differential impedance is (as expected) 100Ω, and the common-mode impedance is 25Ω.

Differential Termination

We could just as well terminate the system differentially, as follows:

The Y-parameters for the differential termination is below. Notice how similar this looks to the MNA stamp of a resistor.

The mixed-mode Y-parameters for the differential resistor is:

The common-mode input conductance of the two-port is zero, implying an infinite common-mode input impedance. For the same reason, the Y-parameters cannot be converted to Z-parameters with the above expression as the determinant of the Y-parameter matrix is zero.