# FINN: a dataflow compiler that turns quantized neural networks into FPGA accelerators

> FINN is an experimental framework from AMD Research that generates dataflow-style FPGA architectures customized to each quantized network, and the README is blunt about the cost of that: only Docker based execution of the compiler is supported. Pre-built network examples live in a separate finn-examples repository.

**Xilinx/finn** — Dataflow compiler for QNN inference on FPGAs

- Repository: https://github.com/Xilinx/finn
- Website: https://xilinx.github.io/finn
- Stars: 1,085 · Forks: 309
- Language: Python
- License: BSD-3-Clause
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/xilinx-finn

## What FINN generates, and for whom

FINN is described as an experimental framework from the Integrated Communications and AI Lab of AMD Research and Advanced Development, and its stated purpose is to explore deep neural network inference on FPGAs.

The specific target is quantized neural networks, with emphasis on generating dataflow-style architectures customized for each network. The result is described as FPGA accelerators that are highly efficient and can yield high throughput and low latency.

Customization per network is the core idea and the main constraint. A dataflow architecture in FINN is not a generic accelerator that runs any model, it is a hardware design shaped around one network's layers, its quantization scheme and its data widths. That is where the efficiency claim comes from and also where the scope ends.

The framework is fully open-source, and the README says this is deliberate, in order to give a higher degree of flexibility, and that the intent is to enable neural network research spanning several layers of the software and hardware abstraction stack. That layering is the point of the project, since it lets a researcher move from a trained network down to a bitstream-level design without leaving one toolchain.

The project name and its history both come from the research literature. The current implementation is based on two publications, FINN-R: An end-to-end deep-learning framework for fast exploration of quantized neural networks in ACM TRETS, and the earlier FPGA 2017 paper FINN: A Framework for Fast, Scalable Binarized Neural Network Inference, both of which the README asks you to cite.

## Docker only, and what the repository layout implies

The most consequential line in the README is about execution. Due to the complex nature of the dependencies of the project, only Docker-based execution of the FINN compiler is supported at this time. The Getting Started page covers requirements, installation and how to run FINN in different modes, and the tutorials are Jupyter notebooks that the README recommends running from inside Docker for a better experience.

That is a hard constraint rather than a preference, and the repository is arranged around it. There is a docker/ directory, a run-docker.sh script at the root, and a setup-local.sh script that sits next to it, which suggests the local path exists but is not the supported one. A fetch-repos.sh script also suggests the build pulls in other repositories, which is exactly the kind of thing a container image can pin and a local checkout cannot.

The rest of the tree shows the multi-layer scope. There is custom_hls/ for the HLS source generation layer, finn-rtllib/ for the runtime library, finn_xsi/ for the Xilinx interface layer, src/ for the compiler itself, notebooks/ and tutorials/ for documentation, tests/, ci/, docs/, and scripts/. Two style guides are committed, HDL_STYLE_GUIDE.md and PYTHON_STYLE_GUIDE.md, which tells you the project produces HDL as well as Python.

The Python side is managed with PyScaffold, since setup.py says the file was generated with PyScaffold 3.2.1 and directs you to setup.cfg for configuration, and there is a .pre-commit-config.yaml plus .ruff.toml and .isort.cfg for linting. The requirements.txt pins the toolchain, with onnx 1.17.0, onnxruntime 1.18.1, onnxscript 0.6.2, numpy 1.24.1, scipy 1.10.1, protobuf 5.29.6, pybind11 2.10.0 and sphinx 5.0.2, among others.

## Pre-built examples live in a separate repository

The README points out that there is a separate repository, finn-examples, that houses pre-built examples for several neural networks. For more general information about FINN, there is the project page at xilinx.github.io/finn and a publications listing.

This split is worth pausing on, because it changes what you have to build. The main repository is the compiler, and the examples repository is a set of prepared flows. If a network you care about is already there, your job is to run and adapt it. If it is not, you are building the flow yourself, which means driving the frontend, the transformation passes and the HLS generation, and that is where the learning curve lives.

The documentation structure follows the same separation. The Read the Docs site carries the framework documentation, and the tutorials are Jupyter notebooks in the repository, which means the intended workflow is a notebook you can read as a narrative and then run, rather than a command reference.

For research use, the notebooks are the more valuable artefact. A compiler that transforms a network into hardware has a large implicit API, and the notebooks are the written record of how that API is meant to be driven, including the parts a reader would otherwise have to infer from the source.

## Community channels, and what happened to the old Gitter room

The support model is stated in a way that saves people from filing the wrong kind of issue. There are GitHub discussions where you can ask questions, and the README asks you to use the GitHub issue tracker to report bugs, but not to file issues to ask questions, since that is better handled in discussions.

Contributions are welcome, with a pointer to the contribution guidelines in CONTRIBUTING.md and to the list of open issues, and the README says not to hesitate to get in touch over GitHub discussions to discuss ideas.

There is also a note about a channel that no longer exists. The project previously had a Gitter channel, and the README says to be aware that it is no longer maintained by them but can still be used to search for questions previous users had. That is a small courtesy with a practical use, since an archived chat log is often where the answer to an old question lives, and the alternative is that the question gets asked again on Discussions for the first time in years.

Announcements are handled separately, under the Announcements category of the GitHub discussions, which is where the README says to find all news about what is changing in FINN.

## The v1.0 alpha, the deprecated v0.1, and where FINN is the wrong tool

The version picture has two interesting edges.

The recent releases are v1.0.0-alpha from 2026-09-06, then v0.10.1 from 2024-07-08 and v0.10 from 2024-04-02. So the project spent roughly two years between 0.10.1 and a 1.0 alpha, and the alpha label is still on it. The last push was on 2026-10-15 and the repository is not archived.

The other edge is the old v0.1 branch, which the README describes as an early-stage prototype of a toolflow that took in Caffe-HWGQ binarized network descriptions and produced dataflow architectures. The warning is emphatic: that version is deprecated and unsupported, and the main branch does not share history with it, so it should be treated as a separate repository for all purposes. Anyone arriving at a v0.1 era tutorial will find that the code paths described there do not exist in main, and the branch gap is the reason.

Where FINN is the wrong tool: it is not a general purpose inference engine, since the accelerator is customized per network and is not a runtime that loads arbitrary models. It is not a training framework, since it targets the deployment side of quantized networks rather than producing them. And it is not a comfortable choice if you cannot run containers, because the compiler has no supported non-Docker path, which is a real blocker for some regulated or locked down environments.

On licensing, the repository is BSD-3-Clause, and the setup.py header carries the standard three clause text with the Xilinx copyright. The conditions are the usual ones, so redistribution in source and binary form is allowed provided the copyright notice and conditions are retained, and neither the name of FINN nor the names of its contributors may be used to endorse or promote products derived from the software without prior written permission. That last clause is the one to note, since it puts a limit on how you describe a product built on top of FINN. This is a description of the licence terms, not legal advice.

## Conclusion

Adopt FINN if you are a hardware or ML researcher who needs a custom FPGA accelerator for a specific quantized network and can accept a Docker-based toolchain with its complex dependency stack. Do not adopt it as a general inference runtime or a production deployment path, because the README calls it experimental, supports Docker only for the compiler, and warns that the resulting accelerators are generated per network. Verify first which pre-built examples exist in the separate finn-examples repository, since those save you building a flow from scratch, and note that the v0.1 branch is deprecated and unsupported and shares no history with main.

## FAQ

### How do I run the FINN compiler?

The README states that due to the complex nature of the dependencies, only Docker-based execution of the FINN compiler is supported at this time. The tutorials are Jupyter notebooks and the README recommends running them from inside Docker as well.

### What kind of hardware does FINN generate?

FINN targets quantized neural networks and generates dataflow-style architectures customized for each network, producing FPGA accelerators designed for high throughput and low latency. The architecture is shaped around one network rather than being a generic accelerator.

### Where can I find pre-built FINN examples?

They are in a separate repository, finn-examples, which houses pre-built examples for several neural networks. The main repository holds the compiler, its notebooks and tutorials, and the finn-rtllib and finn_xsi runtime and interface layers.

### Can I still use the old v0.1 branch of FINN?

The README says that version is deprecated and unsupported, and that the main branch does not share history with it, so it should be treated as a separate repository for all purposes. It was an early-stage prototype that took Caffe-HWGQ binarized network descriptions.

## Sources

- [License: BSD-3-Clause](https://github.com/Xilinx/finn/blob/main/LICENSE)
- [Project website](https://xilinx.github.io/finn)
- [README](https://github.com/Xilinx/finn/blob/main/README.md)
- [Releases](https://github.com/Xilinx/finn/releases)
- [Xilinx/finn on GitHub](https://github.com/Xilinx/finn)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xilinx-finn