nextpnr: portable FPGA placement and routing with Yosys

Where nextpnr fits in an open FPGA flow

nextpnr addresses the physical implementation stage of an FPGA design: placing logic into device resources and routing the resulting connections. The project describes itself as a vendor-neutral, timing-driven, free and open source place and route tool. That makes it relevant to engineers who synthesize RTL with Yosys but need a separate stage that converts the synthesized netlist into a device-specific placed and routed design.

The repository is not a complete programming environment by itself. A typical iCE40 example uses Yosys to create a JSON netlist, nextpnr to produce an ASCII bitstream, icepack to create the binary file, and iceprog to upload it to an iCEstick. Constraints come from a PCF file, while the target device is selected with a command-line option. This separation is important for adoption decisions. nextpnr owns placement and routing, but the surrounding flow can still require synthesis software, board constraint files, device-support repositories and vendor toolchain utilities.

The intended users are FPGA engineers working with the listed Lattice, Gowin, NanoXplore or Cologne Chip families, as well as developers extending or evaluating open source implementation tooling. nextpnr is less suitable for someone expecting a single universal package that turns an RTL design into a programmable board image.

Device backends and their external dependencies

Support is organized around architecture-specific backends rather than one device-independent implementation. The README lists iCE40, ECP5, Nexus, Gowin LittleBee and Aurora V, NanoXplore NG-Ultra and Cologne Chip GateMate devices as supported. It also identifies Cyclone V, MachXO2, Xilinx 7-series and a generic user-defined architecture as experimental.

Each supported family has an associated project that supplies device information or related integration. iCE40 support uses Project IceStorm, ECP5 uses Project Trellis, and Nexus uses Project Oxide. Gowin, NanoXplore and GateMate support points to Project Apicula, Project Beyond and Project Peppercorn respectively. These relationships mean that selecting a nextpnr backend is not enough by itself. The README's build examples pass installation prefixes or source roots for several of these dependencies into CMake.

Architecture support should not be read as a uniform maturity claim. The README explicitly labels Cyclone V experimental with limited testing and says that its API, build requirements and integration points may change. It similarly marks MachXO2, Xilinx 7-series and the generic backend as experimental. The generic backend is aimed at user-defined architectures, but the README does not document the complete adaptation process.

Yosys synthesis through placement, routing and bitstream output

The clearest documented data flow is the iCEstick example. Yosys first synthesizes `blinky.v` for iCE40 and writes `blinky.json`. nextpnr reads that JSON netlist, the selected target type and the `blinky.pcf` constraints, then writes `blinky.asc`. A separate `icepack` invocation converts the ASCII output into `blinky.bin`, which `iceprog` uploads to the board.

This sequence exposes nextpnr's actual boundary in the toolchain. It consumes a structured netlist and device constraints, performs placement and routing, and emits an intermediate device-specific result. It does not synthesize the original Verilog and does not itself perform the final upload. For other architectures, equivalent utilities are likely part of their integration flows, but this README excerpt only supplies the complete command sequence for iCE40, so those steps should be taken from each architecture's own documentation.

nextpnr also has GUI support. The README states that `--gui` exposes toolbar actions and a Python command console for operations such as packing, placing, routing and writing output files. That is useful for inspection and manual intervention, although the documented quick-start flow is command based.

Installation tutorial for the nextpnr-ice40 tool

Building requires CMake 3.25 or later, a modern C++17 compiler, Python 3.5 or later with development libraries, Boost and Eigen3. Yosys is required to synthesize the demo design. The repository also needs its Git submodules initialized before configuration.

Install Project IceStorm under `/usr/local`, or choose another location and pass it through `ICESTORM_INSTALL_PREFIX`. The following commands initialize the repository, configure the iCE40 target, build it and install the resulting executables. Installing with `sudo` grants the system-wide permission needed by that command; a managed environment may use a different installation prefix instead.

git submodule update --init --recursive

After that command completes without an error, create the build directory and invoke CMake with `ARCH=ice40`.

mkdir -p build && cd build
cmake .. -DARCH=ice40
make -j$(nproc)
sudo make install

The reader should end this stage with a built and installed `nextpnr-ice40`. The executable names are backend-specific, so an ECP5 or Nexus build produces its own `nextpnr-ecp5` or `nextpnr-nexus` target rather than one interchangeable command.

First iCEstick design and GUI inspection

The repository includes a small iCEstick design under `ice40/examples/blinky/blinky.*`. Starting from that directory, the first command synthesizes the design and produces a JSON netlist.

yosys -p 'synth_ice40 -top blinky -json blinky.json' blinky.v

Yosys should create `blinky.json` if synthesis completes. nextpnr then selects the `--hx1k` device, loads the JSON and PCF files, performs placement and routing, and writes `blinky.asc`.

nextpnr-ice40 --hx1k --json blinky.json --pcf blinky.pcf --asc blinky.asc

The remaining documented tools convert that output and upload it to an iCEstick.

icepack blinky.asc blinky.bin
iceprog blinky.bin

For inspection rather than a non-interactive run, add `--gui`.

nextpnr-ice40 --json blinky.json --pcf blinky.pcf --asc blinky.asc --gui

The README says that the toolbar or Python command console can run pack, place, route and output-writing actions. Hardware connectivity and the device's actual behavior are outside what this command sequence can confirm.

Configuration choices for ECP5, Nexus and Windows

The build system selects an architecture through the `ARCH` CMake value, while dependency locations use backend-specific variables. ECP5 expects Project Trellis, and the documented example configures it with `TRELLIS_INSTALL_PREFIX`. Nexus expects Project Oxide and uses `OXIDE_INSTALL_PREFIX`. Cyclone V uses `MISTRAL_ROOT` to locate the Mistral source tree.

cmake .. -DARCH=ecp5 -DTRELLIS_INSTALL_PREFIX=/usr/local

This command is shown after entering a separate `build` directory, as in the iCE40 instructions. A Nexus configuration follows the same build-directory model but names the Oxide executable and prefix.

cmake .. -DARCH=nexus -DOXIDE_INSTALL_PREFIX=$HOME/.cargo

Windows support introduces more variables because the example fixes paths for Project IceStorm, vcpkg, Visual Studio and Python. It also documents `BUILD_STATIC=ON` with a static target triplet. Those settings are tied to the supplied Visual Studio 15 example and should not be copied as generic defaults for every Windows environment.

The prerequisite versions and package sets differ across targets. In particular, `nextpnr-himbaechel` requires Python 3.9 or later, while the general build prerequisite is Python 3.5 or later. This is another reason to check the selected backend before installing dependencies.

Limits, maintenance and the cost of changing backends

The largest practical limitation is that architectural coverage does not imply equal feature or testing maturity. The README calls several backends experimental and gives Cyclone V a specific warning about limited testing and API refactoring. A design that depends on timing closure must therefore be judged using the exact device and backend rather than by the breadth of the support list.

The project is not archived. Its last push was on 2026-10-13. Recent releases include nextpnr 0.11.1 on 2026-08-11 and nextpnr 0.10 on 2026-03-12. Those repository and release records show recent project activity, but they do not remove the compatibility cost imposed by backend changes. Upgrading may require checking architecture support, external device databases, API expectations and board-specific examples.

The repository uses the ISC license. That permissive licensing is favorable for inspecting and integrating the code, while embedded notices and dependencies must still be checked separately. The README does not document rollback procedures or a stable support window for experimental backends. It also does not provide timing-quality guarantees, so the produced placement and routing output remains the evidence to inspect for a particular design.

nextpnr compared with a device vendor flow

A vendor flow typically keeps synthesis, device implementation, bitstream generation and programming within a product-specific tool suite. nextpnr instead exposes an open source implementation stage across multiple device families, but the comparison is not one tool against one tool. In the documented iCE40 path, the same design also depends on Yosys, IceStorm, icepack and iceprog.

nextpnr's main distinction is architectural portability. The same core project provides separate backends for several supported families and an experimental interface for user-defined architectures. The trade-off is that users must assemble the correct dependencies and follow family-specific conventions. The README points ECP5 and Nexus users to external example collections rather than presenting one universal board tutorial.

A vendor-neutral workflow is therefore most relevant when open source synthesis and device support are already requirements. nextpnr is the wrong fit as a drop-in replacement for an entire programmable-device environment because the documented flow still spans several programs and repositories.

Editorial conclusion

Engineers working with a supported FPGA family and willing to assemble the matching device database, synthesis and bitstream tools should evaluate nextpnr against the documented board flow. Projects needing only stable support for one mature backend should verify that family first, while experimental backend users must account for changing APIs and limited testing. Before adoption, check whether the exact device, board constraints, timing results, external toolchain and licensing fit the required FPGA workflow.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. YosysHQ/nextpnr on GitHub