OpenFPGA generates the FPGA architecture, not just the bitstream for a fixed chip

The unit of work is an architecture, not a design

The OpenFPGA framework is described as the first open-source FPGA IP generator with silicon proofs, supporting highly customisable FPGA architectures. The key phrase is IP generator. OpenFPGA does not merely take your Verilog and produce a bitstream for a device that already exists. It lets you describe the architecture of the FPGA itself, the array of logic elements, the routing, the embedded memory, the programmable interconnect, and then it generates the bitstream for the architecture you described and verifies it.

The stated scope is complete EDA support for customized FPGAs, including Verilog-to-bitstream generation and self-testing verification. The project presents this as opening the door to democratising FPGA technology and EDA techniques with agile prototyping approaches and evolving EDA tools for chip designers and researchers.

The silicon proofs are what separate it from a research prototype. A generated architecture that has been fabricated and measured is a different claim from a paper describing a hypothetical design flow, and that is the reason the project has an award and a journal paper behind it.

The audience follows from the scope. Chip designers prototyping an architecture, and researchers who want to study or extend the design flow, are the people who benefit. A developer with a Verilog file and an off the shelf board is not the target, and the documentation says as much by pointing first time users at an introduction video and a summary of the technical capabilities before they compile anything.

The flow is split into the framework, the flow scripts and the EDA backends

The repository layout describes the architecture of the tool itself, and it is the clearest statement of how the pieces fit.

There is an openfpga/ directory for the framework code, an openfpga_flow/ directory that holds the flow scripts, and a docs/ directory with the documentation source. Alongside those are the submodules the flow depends on: yosys, which is the synthesis side, and vtr-verilog-to-routing, the verification and timing side. There is a libs/ directory, a dev/ directory, a cmake/ directory, a Dockerfile and a vcpkg.json for the C++ dependencies.

The VTR and Yosys pieces are the reason the tool is called an EDA framework rather than a script. A self-testing verification flow means the generated architecture is simulated and checked, not just synthesised. The README also lists a set of tools elsewhere in the documentation, and the site carries a page that gives a quick overview of the OpenFPGA tools, so the flow is documented as a set of cooperating programs rather than one binary.

The scripts in openfpga_flow/ are what turn an architecture description into those tool invocations. That separation is the practical point for a user: the flow is data driven and the individual steps can be inspected, changed and rerun, which is what you need when the interesting work is in the architecture rather than in the RTL.

The build is CMake, with a Makefile wrapper and a long dependency list

Compilation is documented in the compilation guidelines on the site, with a tutorial video as well, and the README insists you read the required dependencies and make sure they are installed correctly before starting.

The top level Makefile is a wrapper around CMake with a small number of knobs. BUILD_TYPE picks release or debug and defaults to release, and the file errors out on anything else. CMAKE_FLAGS forces the flags handed to CMake. BUILD_INSTALLER and INSTALL_DOC toggle the installer and the documentation build, and both default to on. The generator choice is handled per platform: Ninja on MSVC and on macOS, Unix Makefiles elsewhere, with Unix Makefiles restored for MSYS2 with the UCRT64 environment.

The Python side is small and pinned.

envyaml==1.0.201125
humanize==3.1.0
coloredlogs==9.1
pyverilog

The same file also pins click at 8.0.2, with a comment explaining that the project's version of black needs an older click, black itself at 26.3.1 and pylint at 2.7.4, and it carries a note that this is the Python linter and formatter section. There is a separate msys2_requirements.txt for the Windows toolchain, which is the kind of file that tells you how much platform specific setup a Windows build involves.

The practical warning is in the documentation rather than the code. There is a page for the required dependencies, a tutorial video on how to compile, and a Docker image as part of the guidelines, and the README recommends checking the summary of technical capabilities before compiling, which is a reasonable way to find out whether the flow supports the architecture feature you need before you spend a day on the build.

The docker image is an editor on top of the toolchain

The Dockerfile in the repository is not a minimal build image. It starts from a published OpenFPGA master image, ghcr.io/lnis-uofu/openfpga-master, and then adds a full interactive development environment on top.

The additions are extensive. Node.js is installed, code-server is installed, and then a set of Visual Studio Code extensions are added for specific tasks: Python support, a rainbow CSV extension for aligning CSV files, a WAVEtrace extension for viewing VCD files, an XML linter, a git graph extension, and veriloghdl, the Verilog linter. Python packages are then installed for a notebook server: notebook, jupyterlab, jupyterhub, jupyter-server and jupyter-server-proxy, all with the --user flag into the home directory of a newly created user.

That tells you something about how the project expects to be used. A generated architecture involves reading a large amount of structured output, comparing runs, plotting waveforms and iterating on the architecture description, and this is a research and prototyping tool, so a browser based workbench with a Verilog linter and a VCD viewer is the environment it was designed around.

The repository also has a Binder badge, which runs the same environment in the browser with no local install at all, which is the fastest way to look at the flow before deciding to build it locally. The tradeoff is that a Binder environment is not a place to keep your work, so anyone actually running designs will still end up on a local or cluster install.

Tutorials and a backward compatibility guide are the way in

The documentation is unusually complete for a project of this kind, and the README points at it in several directions.

The full documentation includes tutorials, descriptions of the design flow, and tool options. There is a separate tutorials section, with which you get familiar with the tool and use OpenFPGA for various purposes. There is a technical capabilities summary, and a page listing the OpenFPGA tools as a quick overview.

For people who used an older version, there is a dedicated backward compatibility page in the developer manual, and the README asks you to check it if you are moving from an old version to the latest. That is a real signal about the shape of the project. The release history shows v0.3-alpha in November 2019, v1.1.0 in February 2022 and v1.1.541 in September 2022, and the version number is not a small integer, which is what a tool with hundreds of internal versions looks like as its users iterate on the flow.

The FAQ discussion thread is also linked, and the README asks you to check it before asking for help, which is the usual courtesy for a project where the answer is usually in the documentation.

If you are citing the work, the README gives a specific reference: the IEEE Micro paper, OpenFPGA: An Open-Source Framework for Agile Prototyping Customizable FPGAs, volume 40, number 4, pages 41 to 48, July and August 2020, with a Bibtex entry, plus a list of related publications in the appendix of the documentation.

MIT for the code, permissive terms for the submodules, and tags that trail the commits

The licence is stated with a carve-out that matters. All the code is under the MIT licence, with the exception of submodules, which the README names: VTR, Yosys and Yosys-plugin, distributed under their own permissive terms, and it points at their full licences for details.

That is the normal arrangement for a project that vendors a toolchain, and it is worth reading the submodule licences if you intend to ship the result, because the MIT grant on the framework does not cover the code inside the submodules.

The other thing to weigh is the gap between the commits and the releases. The last push was on 2026-10-19, and the project is not archived, so the code is being worked on. The listed releases are v1.1.541 from 2022-09-22, v1.1.0 from 2022-02-21 and v0.3-alpha from 2019-11-27. The README itself points you to VERSION.md for the version, which is the file to check when you build from source rather than from a tag.

The continuous integration picture is healthy on paper. There is a build workflow badge and a separate cell library tests workflow badge, the code style is enforced with black, the documentation status is tracked on readthedocs, and the top level repository holds a.clang-format file, a.clang-tidy configuration, a Makefile, a CMakeLists.txt, an openfpga.sh entry script and a vcpkg.json for the C++ dependency versions.

Taken together this is a project with an active repository and a mature public interface, where the practical question for a new user is not whether it is alive but which version of the flow they should pin, and that answer is in VERSION.md and the backward compatibility documentation rather than in the release list.

Editorial conclusion

OpenFPGA fits a chip designer or researcher who needs to prototype a custom FPGA architecture rather than target an existing device, and who can absorb a multi tool build. It is the wrong choice if you simply want to build a bitstream for a commercial FPGA, where a vendor toolchain is faster to get running. Verify first which version you are building against, since the version lives in VERSION.md and the newest release tag is from 2022, and read the backward compatibility guidelines before moving an existing flow to a newer release.

Frequently asked questions

Official sources

1. License: MIT
2. lnis-uofu/OpenFPGA on GitHub
3. Project website
4. README
5. Releases