Amaranth HDL: writing synchronous digital logic in Python and targeting FPGAs

Python syntax for synchronous hardware, not a simulation wrapper around Verilog

Verilog and VHDL were designed decades ago for hardware description, with their own syntax and type systems. Amaranth HDL takes a different path: designers write Python code that describes the hardware, Amaranth converts that description to RTLIL (the intermediate language Yosys processes), and Yosys produces behavioral Verilog-2001 for synthesis. What gets synthesized is determined by what you write in Python, not by a separate HDL file that lives outside the Python toolchain.

This is not cocotb or a testbench layer that runs Python tests against Verilog. Amaranth produces the RTL description itself. Python's abstractions are available during design: loops, classes, functions with parameters and standard library modules all apply to the hardware description itself, not just to test code.

Practically, a designer can write a Python function that generates a configurable FIFO, call it multiple times with different widths in the same top-level module, and Amaranth generates correctly distinct Verilog instances for each call. That kind of parameterized reuse, done without preprocessor macros or generate blocks, is what the README describes as simplifying the design of complex hardware with reusable components. Analog hardware design is outside the scope of what Amaranth generates: the toolchain targets synchronous digital logic, and its output is a Verilog netlist, not an analog model or a mixed-signal description.

Four components that cover a complete FPGA design cycle

Four distinct parts make up the Amaranth toolchain, each addressing a separate phase of hardware development.

At the core is the hardware definition language itself, where signals, modules, combinatorial logic and sequential registers live. A standard library sits alongside it, with a component metadata system registered as a project entry point under amaranth.lib.meta in pyproject.toml. Simulation is the third part: Amaranth designs run as Python programs for verification, writing VCD waveform files through the pyvcd dependency (>=0.2.2,<0.5 from pyproject.toml) for inspection in any waveform viewer. Build system automation rounds out the toolchain, calling synthesis and place-and-route tools in the right order for each supported platform.

Beyond those four, pyproject.toml registers an entry point named amaranth-rpc for a remote procedure call interface, with the Jinja2 library (Jinja2~=3.0) supporting the build system's template-based output generation. A smaller jschon dependency (~=0.11.1) serves the metadata subsystem in amaranth.lib.meta.

Installing from PyPI and what the optional extras unlock

Amaranth is published on PyPI under the name amaranth, and requires Python 3.9 or newer per the requires-python constraint in pyproject.toml. For installation steps, the README points to the documentation at amaranth-lang.org/docs/amaranth/latest/install.html, rather than giving a command directly, because a full setup also involves placing Yosys on the system path.

Two optional extras are defined in pyproject.toml:

[project.optional-dependencies]
builtin-yosys = ["amaranth-yosys>=0.40"]
remote-build  = ["paramiko~=2.7"]

Installing the builtin-yosys extra adds amaranth-yosys>=0.40, which is a packaged Yosys distribution that Amaranth can call directly. This removes the need to install Yosys separately when targeting families where Yosys+nextpnr is the synthesis path. The remote-build extra adds paramiko~=2.7 for SSH-based builds on a remote host. Neither extra is pulled in by a plain install; they are opt-in based on your workflow.

Extended FPGA support versus any target that accepts behavioral Verilog-2001

Platform support in Amaranth splits into two tiers. Any FPGA or ASIC process that accepts behavioral Verilog-2001 as input can technically serve as a target, with designers handling toolchain invocation on their own. Extended support adds toolchain integration, device-specific primitive abstractions, and additional helpers for specific families.

On the open-source toolchain side, the README marks supported combinations in bold. Lattice iCE40, MachXO2, MachXO3L, ECP5 and Nexus all use Yosys+nextpnr. Quicklogic EOS S3 uses Yosys+VPR. Proprietary toolchains covered include AMD Virtex and Spartan families from early generations through to Spartan 6 via ISE, AMD 7-series through both Vivado and ISE, AMD UltraScale and UltraScale+ through Vivado, and Altera families through Quartus.

An FPGA family not in that list falls into the first tier: Amaranth can target it through Verilog output, but the extended primitives and toolchain integration will not be present. Whether that matters depends on how much vendor-specific IP the design uses.

Integrating existing Verilog and VHDL code in either direction

Adopting a new HDL typically raises a question about the fate of existing IP. Amaranth addresses this with two explicitly stated claims about interoperability.

On one side, the README states that existing SystemVerilog or VHDL blocks can participate in an Amaranth design without being rewritten. A team migrating to Amaranth carries proven IP across without needing to touch it. Going the other direction, Amaranth-generated output can participate in an existing Verilog-based flow, which means introducing Amaranth into one module of an otherwise Verilog project is viable without replacing the whole toolchain.

How either path works at the file and instantiation level is not described in the README. Both directions point to the project's documentation for the specifics. Those details matter when estimating integration effort: the interface between Amaranth-generated output and a third-party synthesis flow determines the exact handoff point, and what each side assumes about port widths, clock domains and generate-level boundaries shapes the actual effort. Whether the integration handles multi-clock designs or asynchronous resets correctly at the seam is not addressed in the README.

What the simulator documents and what it leaves unspecified

Amaranth includes a simulator as a built-in part of the toolchain. Designs run as Python programs for verification, using Python code as testbenches rather than a separate verification language. Signal states are written to VCD files through amaranth.sim.pysim, the module connected to the pyvcd dependency, and those files open in any standard waveform viewer.

The VCD output path is the one capability pyproject.toml makes concrete, through the pyvcd version constraint. Beyond that, the README names the simulator as part of the toolchain without documenting its scope. Formal verification, co-simulation with external models, and timing-accurate gate-level simulation are not mentioned in the README or in the available repository files. Whether the simulator handles asynchronous clock-domain boundary checks or multi-clock designs is similarly left undocumented in the README. Designers who need formal methods or gate-level timing accuracy should check the documentation at amaranth-lang.org to confirm whether those capabilities exist before choosing Amaranth on that basis.

BSD-2-Clause licence, v0.5.10 on 2026-09-10, and the nMigen history

Amaranth carries the two-clause BSD license, with the full text in LICENSE.txt at the repository root. Proprietary use is explicitly permitted under the terms the README states, provided the copyright notice in LICENSE.txt is reproduced when redistributing. That permissive stance means commercial FPGA designs built on Amaranth are not subject to copyleft obligations, unlike tools released under GPL or LGPL.

Release v0.5.10 was published on 2026-09-10, preceded by v0.5.9 on 2026-07-16 and v0.5.8 on 2025-10-15. A near-year gap between v0.5.8 and v0.5.9 contrasts with the two-month cadence of the most recent pair. Repository activity remains ongoing: the last push was on 2026-09-18, and the repository is not archived. Upgrade cost between minor releases is not addressed in the README; the CHANGELOG in the repository is where breaking changes, if any, are documented.

Development has been supported by LambdaConcept, ChipEleven, and Chipflow, as the README names. Community discussion runs through #amaranth-lang at libera.chat, bridged to Matrix at #amaranth-lang:matrix.org, with both systems showing the same messages.

Before version history became Amaranth HDL, the project was named nMigen. Any search for nMigen documentation or community posts covers the same project at an earlier stage, so older tutorials and issue threads remain relevant for understanding how design patterns evolved.

Editorial conclusion

Use Amaranth if you are comfortable with Python and want to describe synchronous digital logic for Lattice or AMD FPGA targets where Yosys+nextpnr is already integrated. Skip it if your design has analog circuitry, uses a toolchain that does not accept behavioral Verilog-2001, or if your team's background is solidly in SystemVerilog and migration cost is not acceptable. Before committing, check the platform support table in the README against your specific FPGA family, since extended toolchain integration covers only the named families, and review the project's release history to understand what changed between v0.5.8 and v0.5.10.

Frequently asked questions

Official sources

1. amaranth-lang/amaranth on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases