Open source EDA tools and open source PDKs for various technologies have recently matured a lot. Here’s a simple and quick way to set up the development environment for those and get started with development.
Tool Overview
Digital ASIC development requires various tools (synthesis, implementation, …) that are usually combined in a toolflow. For an overview of commercial and OSS tools, see for example Mohammed Zakir Hussain’s post here. Make sure to check the updated table in the comments, as the original one has some errors.
In addition, you need the PDK (Process Design Kit) for your target technology. PDKs are usually tool specific, so your PDK also needs explicit support for the OS tools. Right now, such PDKs are available for GlobalFoundries GF180MCU, SkyWater SKY130 and IHP SG13G2 BiCMOS SiGe technologies.
Setting up all tools and PDKs and updating them regularly is quite some effort. Furthermore, if you want to do analog or mixed signal development, even more tools are needed. The easiest way to install the tools is therefore using a prepared distribution.
A well-known, well-supported one is the IIC-OSIC-TOOLS container image. Whereas the original installation instructions are fine, the setup can be simplified a lot on a Linux host when using distrobox.
Distrobox Tool Installation
Setting up a distrobox container is quite simple:
distrobox create -i docker.io/hpretl/iic-osic-tools:2025.03 asic
distrobox enter asic
As the IIC-OSIC-TOOLS image does not officially support distrobox yet, we need to make some additional changes though:
# Use bash in the container, even if you use another shell in your host OS
chsh -s /bin/bash
# Automatically source the environment script when we enter the container
sudo ln -s /headless/.bashrc /etc/profile.d/z99_iic_osic_env.sh
sudo sh -c 'echo "source /headless/.bashrc" >> /etc/bash.bashrc'
Running Graphical Tools
The IIC-OSIC-TOOLS image ships various tools, including grpahical tools for analog design. As we’re using distrobox, we can just run these tools from the container. We don’t have to use VNC, X11 forwarding or any other complex setup that is described in the IIC-OSIC-TOOLS documentation.
To test whether the tools are working, we can just run klayout
once:
distrobox enter asic
# Use IHP PDK
iic-pdk ihp-sg13g2
# Try running klayout
klayout
Synthesize a Digital Example Design with ORFS
Using the tools in the container, we can also run RTL2GDS flows for digital design. Let’s synthesize some Verilog example code for the IHP PDK using OpenROAD Flow Scripts (ORFS).
Although IIC-OSIC-TOOLS ships OpenROAD tools and regularly tests ORFS, it does not ship ORFS as part of the container. This is reasonable, as ORFS sometimes needs to be adapted to your design. So you really want your own ORFS copy in a writable location.
First create a new project directory somewhere and clone ORFS:
distrobox enter asic
cd ~/Documents
git clone https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git orfs
cd orfs
It is important to use the ORFS commit matching the OpenROAD version shipped in the container.
If you use a newer version of ORFS, older OpenROAD tools in the container may just crash.
The $TOOLS/openroad-latest/ORFS_COMMIT
file contains the ORFS git commit that was tested when assembling the container.
Let’s check out the tested ORFS revision:
git checkout $(cat $TOOLS/openroad-latest/ORFS_COMMIT)
With ORFS ready, we can now run a simple first synthesis. According to the test script in the IIC-OSIC-TOOLS repository, we need to set some tool paths:
export YOSYS_EXE=$TOOLS/yosys/bin/yosys
export OPENROAD_EXE=$TOOLS/openroad-latest/bin/openroad
export OPENSTA_EXE=$TOOLS/openroad-latest/bin/sta
export FLOW_HOME
Then enter the flow directory, select an example to synthesize and run the flow:
cd flow
export DESIGN_CONFIG=./designs/ihp-sg13g2/spi/config.mk
make
We implicitly selected the PDK ihp-sg13g2
and the design spi
through the DESIGN_CONFIG
path.
For information on how to use this with your own designs, see the ORFS tutorial and reference documentation.
VS Code Integration
For more convenient development, you’ll probably want to use the container in VS Code as well.
This could mean running tools from the VS Code terminal or that your VS Code can use tools from the container.
For example, the TerosHDL extension needs a yosys
executable, which can be used directly from this container.
When attaching to a container, VS Code by default connects as root user. This will mess up file permissions: For distrobox containers, you should use the username matching your host OS. Follow this guide completely and configure VS Code properly, before attaching to the container.
Create the following configuration file at $HOME/.config/Code/User/globalStorage/ms-VS Code-remote.remote-containers/nameConfigs/asic.json
to match the distrobox container named asic
:
{
"remoteUser": "jpfau",
"workspaceFolder": "/home/jpfau/Dokumente/Projekte/FPGA/neosd",
"settings": {
"terminal.integrated.defaultProfile.linux": "bash"
}
}
remoteUser
must match the username on your host OS.
workspaceFolder
is optional and can be used to set a folder that will be opened by default.
As distrobox maps your home folder, you can choose any folder from your host OS as long as it’s in your $HOME
.
I’ll also set defaultProfile
to ensure that terminal windows use bash
by default, as the container only sets up the environment for that shell.
You should always start the container using distrobox enter
before connecting in VS Code.
Don’t let VS Code start the container.
You can now connect to the container in VS Code:
Press Ctrl+Shift+P
and type Dev Containers: Attach to running container
.
For some reason, graphical applications don’t seem to start from the VS Code terminal.