SiliconCompiler: make for silicon, with the toolchain expressed as a schema

What it is: a build system whose unit of configuration is a schema

SiliconCompiler is a modular hardware build system, and the README calls it make for silicon. The project philosophy is quoted as making the complex possible while keeping the simple simple. The distinguishing mechanism is the data model. The project description calls it a compiler framework that automates translation from source code to silicon, and the Why section lists portability through a powerful dynamic JSON schema that supports ASIC and FPGA design and simulation, and provenance through compilation manifests created automatically during execution. So the design, the tool settings, the flow steps and the record of what was built are all held in one schema rather than in a Makefile, in a tool invocation log, and in a wiki page that nobody updates.

The tools it drives, and the two kinds of PDK

The supported technologies table is the real scope of the project. Design languages include C, Verilog, SystemVerilog, VHDL, Chisel, Migen and Amaranth, Bluespec and MLIR. Simulation tools cover Verilator, Icarus, GHDL and Xyce. Synthesis covers Yosys, Vivado, Synopsys and Cadence. ASIC place and route covers OpenROAD, Synopsys and Cadence, FPGA place and route covers VPR, nextpnr and Vivado, the layout viewer covers Klayout, OpenROAD, Cadence and Synopsys, and DRC and LVS cover Klayout, Magic, Synopsys and Siemens. The PDK row is the one to read twice. The open PDKs, sky130, ihp130, gf180, asap7, freepdk45, gt2n, icsprout55 and interposer, are all shipped by lambdapdk. The foundry PDKs, gf12lp, gf22fdx and intel16, require a foundry agreement, and you have to package them yourself following the external library guide.

Thirteen lines from RTL to GDS, and the metric names that tell you what failed

The getting started section claims that converting RTL into DRC clean GDS takes thirteen lines of simple Python code, and then shows them. You import the ASIC and Design classes, create a Design object, set the top module against the rtl fileset, add the source files, create the project, enable the filesets, load a pre-defined target such as skywater130_demo, set the scheduler to docker so the tools run in containers, and run. Then project.summary prints a summary and project.show displays the layout. The parenthetical about the metrics is the detail a practitioner wants, since it tells you how to read a failure. The asicflow reports geometric violations from detailed routing as the drcs metric, and electrical ones, slew, capacitance, fanout and antenna, as drvs. Signoff DRC and LVS run in a separate signoffflow, which is a meaningful split, because the signoff tools are the expensive ones and the ones that decide whether the tapeout is real.

from siliconcompiler import ASIC, Design               # import python package
from siliconcompiler.targets import skywater130_demo
design = Design("heartbeat")                           # create design object
design.set_topmodule("heartbeat", fileset="rtl")       # set top module
design.add_file("heartbeat.v", fileset="rtl")          # add input sources
design.add_file("heartbeat.sdc", fileset="sdc")        # add input sources
project = ASIC(design)                                 # create project
project.add_fileset(["rtl", "sdc"])                    # enable filesets
skywater130_demo(project)                              # load a pre-defined target
project.option.scheduler.set_name("docker")            # run the tools in containers
project.run()                                          # run compilation
project.summary()                                      # print summary
project.show()                                         # show layout

One Design, four project classes, and a lint path that needs no tools

The Not building an ASIC section makes the central design claim concrete. The same Design feeds every flow, and the project class is what decides what happens to it. A Lint class lints your RTL and needs no tools at all. A Sim class simulates or proves properties formally and needs Verilator, Icarus, GHDL or SymbiYosys. An FPGA class builds a bitstream and needs Yosys plus VPR or nextpnr. The ASIC class is the full flow. Linting is described as the quickest way to see SiliconCompiler work, and the reason it is quick is that the default linter ships as a Python package, so there is no EDA tool to install. That is a deliberate on-ramp, and for a complete FPGA build with no EDA tools installed locally, the demo runs in containers, with python3 -m siliconcompiler.demos.fpga_demo and the docker scheduler.

python3 -m siliconcompiler.demos.fpga_demo -scheduler docker

Install it with pip, and the Windows caveat

SiliconCompiler is available as wheel packages on PyPI for macOS, Windows and Linux, and for a working Python 3.10 to 3.14 environment the instruction is just to use pip, with pip install --upgrade siliconcompiler. The caveat is on the next line and it is about tooling rather than packaging, that on Windows you should use Docker or remote execution, since local tool flows are supported on Linux and macOS. The reason is straightforward once you look at the supported tool list, since the commercial tools in it, Vivado, Synopsys and Cadence, are installed in platform specific ways that a container image handles more predictably than a Python package. The dependency list in the packaging manifest includes the docker Python client, which is the scheduler interface, plus graphviz for the flowgraph visualisation, orjson, PyYAML, requests, Pillow, GitPython, distro and fasteners, and lambdapdk for the open PDKs.

pip install --upgrade siliconcompiler

The execution model: flowgraph, containers, remote processing, provenance

The Why section lists the properties that make it a build system rather than a script collection. Ease-of-use is a programmable Python API. Speed comes from a flowgraph execution model that enables cloud scale execution, since the steps of a hardware flow are a graph and the independent ones can run in parallel. Friction-less is containerized execution enabling zero install compilation, plus a remote execution model that offloads builds to a server you operate, and the project ships both Docker and remote processing documentation. Modularity is a tool abstraction layer that makes it easy to add or port new tools. Provenance is the compilation manifests created automatically during execution, and the documentation is described as an extensive set of auto-generated reference documents. The In-use claim is that it is actively used by Zero ASIC for commercial tapeouts at advanced process nodes, and the authors of the project are Zero ASIC.

The examples directory, and what it tells you about real use

The examples/ directory in the repository is the best evidence of what the framework is actually used for, and it is a list of hardware problems rather than of demos. There is an adder with cocotb and with a formal equivalence check, an AES example, a blinky, a fibone, a gcd, a ghdl to synopsys flow, the heartbeat example the README uses, a heartbeat written in Migen, an interposer, a macro reuse example, an mlir_hls directory for high level synthesis through MLIR, an oh_experiments directory, a padring, a parallel example, a pex_calibration example for parasitic extraction, picorv32, requirements files, a soda directory, an sva_sby example for static verification, and a uniquify example. Several of these are verification flows rather than implementation flows, which is a reminder that the framework is used across the whole space of hardware engineering work and not only for tapeout.

Upkeep, licence and the shape of the repository

The releases are v0.38.9 on 2026-09-21, v0.38.10 on 2026-10-06 and v0.38.11 on 2026-10-15, so the patch line moves every couple of weeks. The last push to the repository was on 2026-10-15, the repository is not archived, the primary language is Python, and the licence is Apache-2.0 with the text in the LICENSE file, which for an EDA framework is unusually permissive and lets a commercial team use it without a separate agreement. The repository layout shows a full Python project, with the siliconcompiler/ package, docs/, examples/, tests/, scripts/, setup/, a Changes directory, a .devcontainer/ directory for development environments, a .flake8 configuration, a MANIFEST.in and a pyproject.toml. The version is derived from setuptools_scm and written into siliconcompiler/_version.py, so a checkout reports the git tag it was built from, and the CI is split into separate workflows for the Python tests, the tools tests, a daily run, the wheel builds and linting.

Editorial conclusion

SiliconCompiler suits a hardware team that has outgrown a pile of makefiles, that wants the tool versions, the settings and the inputs of a build recorded rather than remembered, and that is prepared to express its flow in Python rather than in a shell script. It is the wrong choice for a single small FPGA bitstream, because the schema, the containers and the scheduler are a large amount of machinery for one flow, and a poor fit if you cannot run containers, since the containerized execution model is the recommended default. Before adopting it, read the supported technologies table, because the distinction between the open PDKs shipped by lambdapdk and the foundry PDKs that require an agreement is the difference between a working build today and a procurement conversation.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. siliconcompiler/siliconcompiler on GitHub