VTR: an open CAD flow that takes a Verilog circuit and an FPGA architecture to place, route and time it

The four stages that make up the VTR design flow

The VTR design flow takes as input a Verilog description of a digital circuit and a description of the target FPGA architecture, and then it performs three groups of work.

The stages in order are Elaboration, Synthesis and Partial Mapping under the name PARMYS, then Logic Optimization and Technology Mapping under the name ABC, then Packing, Placement, Routing and Timing Analysis under the name VPR.

The output is FPGA speed and area results. The point of listing the stages in order is that each is a separate tool in the repository, and the repository tree shows it. There is a parmys directory, an abc directory, a vpr directory, an odin_ii directory, a verilog_preprocessor directory, a vtr_flow directory that drives the whole thing, plus ace2, blifexplorer, libs and utils.

PARMYS handles elaboration, synthesis and partial mapping, so it is the front end that turns Verilog into a gate level netlist. ABC then does logic optimization and technology mapping, which is where the netlist is rewritten into the primitives of the target architecture. VPR closes the loop with packing, placement, routing and timing analysis, so it is the component that produces the numbers you actually want, area and delay.

There is an interesting division of responsibility here. ABC is a well known external project that the VTR tree vendors, and VTR treats it as a component with its own licence. Odin II is another tool in the tree, sitting alongside the verilog_preprocessor.

VTR also includes a set of benchmark designs known to work with the design flow, which matters more than it sounds. Without a fixed set of designs that complete the flow, an architecture experiment cannot be compared against a previous result, because the comparison is only meaningful if the same circuit was placed and routed the same way.

From a Verilog file to a placement and routing report

The build is a plain make from the root VTR directory on unix-like systems, and there is a separate Dockerfile that sets up all the necessary packages.

make

For most users, rather than active developers, the README points to the latest official VTR release on the project download page, which has been fully regression tested. That distinction between users and developers is the first practical decision to make, and the README is explicit about it.

The repository also ships a set of platform specific dependency installers, install_apt_packages.sh for Debian and Ubuntu, install_dnf_packages.sh for Fedora style systems, and install_win_msys2_ucrt64_packages.sh for Windows under MSYS2 with the UCRT64 toolchain. The Dockerfile starts from ubuntu:24.04 and pulls its package list out of install_apt_packages.sh with a chain of sed expressions, so the container image and the native install path are kept from drifting apart.

The Python side of the flow needs a handful of packages, and the requirements file lists prettytable, lxml, psutil, pandas, numpy and scipy for the flow scripts themselves, orderedmultidict for Surelog, and the tooling group of click, black and pylint for linting and formatting. The Dockerfile installs these with pip install -r requirements.txt inside a virtual environment whose bin directory is put on PATH.

The container image is worth a note for CI purposes. It also installs verilator, which is a Verilog simulator, even though the flow is about synthesis and place and route, and it pulls in ninja-build as the build tool for the C++ components alongside the Makefile entry point.

What the project measures, and the pictures that show it

The README leads with four rendered views of a run, and they are worth reading as a description of the output because they tell you what the flow is expected to produce.

There is a placement view with carry chains highlighted, a critical path view, a logical connections view, and a routing utilisation view. So a VTR run gives you a picture of where the logic landed on the fabric, which path was critical, how the cells are connected, and how much of the routing resource the design consumed.

That last one matters more than it might appear. Routing utilisation is usually the first number to fall over when a design is placed on an architecture that is too small or too loosely connected, and a flow that reports it alongside area and delay lets an architecture researcher see that failure mode instead of only seeing a delay number.

The project is also positioned for output beyond simulation. VTR can produce FASM to program some commercial FPGAs, via the Symbiflow work at Chips Alliance. The word some is doing real work in that sentence, so this is a path for particular devices rather than a general bitstream path for arbitrary boards.

For citation, the README names a general paper, VTR 9: Open-Source CAD for Fabric and Beyond FPGA Architecture Exploration, published in ACM TRETS in 2025, and gives the bibtex entry with a long author list.

The bibtex entry the README supplies uses the key vtr9, the article title VTR 9: Open-Source CAD for Fabric and Beyond FPGA Architecture Exploration, the journal ACM Trans. Reconfigurable Technol. Syst. and the year 2025.

The full documentation site at docs.verilogtorouting.org includes tutorials, descriptions of the design flow and tool options, and there is a quickstart guide linked for new developers.

Trunk versus release, and the review culture around a research tool

The development section is unusually candid about what working on VTR is like. This is the development trunk for the project, and unlike the nicely packaged releases, you are working with code in a constant state of flux. The README says you should expect that the tools are not always stable and that more work is needed to get the flow to run.

That is a warning against using master as a user, and it is the single most important operational fact about the repository. The release tags are v9.0.0 from 2025-01-21, v8.0.0 from 2020-03-24 and an FCCM 2023 NoC Placement tag from 2023, so tagged releases are infrequent and long apart, while the last push was on 2026-10-14. Development is clearly more active than the tag cadence suggests.

The contribution model is a feature branch flow. You create a new branch for new code, test it, measure its Quality of Results, and eventually produce a pull request for review by other developers, and pull requests that meet all the quality and review criteria are merged into master by a developer with the authority to do so.

Quality of Results is the metric that keeps the flow honest, and the automation around it is extensive. QoR and functionality are measured automatically on pull requests, and there is periodic automated testing of master using BuildBot, with a Trunk Status waterfall and QoR tracking pages published. The README puts the rule bluntly: a broken build must be fixed at top priority, and you break the build if your commit breaks any of the automated regression tests.

For a research tool where a change in placement heuristic can silently make results worse, that regression infrastructure is arguably the most valuable part of the project.

Support comes from four mailing lists: VTR-Announce for release announcements with low traffic, VTR-Users for discussions about using VTR, VTR-Devel for development discussions, and VTR-Commits for revision control commits.

Licence structure, funding and where VTR is the wrong choice

The licensing is not uniform across the tree. Generally most code is under the MIT licence, with the exception of ABC, which is distributed under its own permissive terms, and the full licence text is in LICENSE.md. For a project that vendors a third-party synthesis tool, this is the normal arrangement, but it does mean the licence of the code you copy depends on which directory it came from. The repository licence metadata records a custom licence GitHub cannot classify, so read LICENSE.md rather than relying on the field.

Funding comes from NSERC and the Semiconductor Research Corporation, and the contributor list names academic participants, with professors including Kenneth Kent, Vaughn Betz, Jonathan Rose, Jason Anderson and Peter Jamieson, and company participation from Intel, Huawei, Lattice, Altera, Texas Instruments, Google and Antmicro.

Where VTR is the wrong tool is fairly clear. It is not a bitstream generator for your own commercial board, and even the FASM path covers only some FPGAs. It is not a fast turnaround synthesis tool either, since a full flow run with place and route over a benchmark set is a long job, and the flow is intended to be run repeatedly across architecture variants rather than once for a product.

It is also not a general logic synthesis tool. ABC does the synthesis, but ABC on its own is a separate project with its own documentation, and VTR exists to exercise ABC inside a complete architecture evaluation flow.

And it is not a stable, versioned API for scripting. The trunk warning applies to anything you automate against master, so pin to a release tarball if you need reproducibility, and use the two Python entry points, run_quick_test.py and run_reg_test.py, in the repository root as the supported ways to exercise a build.

Editorial conclusion

Adopt VTR if you are researching FPGA architectures and need a flow that reports area, delay and routing utilisation for the same design under different fabric assumptions, since the value is having synthesis, placement and routing all under your control. Do not adopt it to produce bits for your own board, because the flow targets research and the FASM path only covers some commercial FPGAs. Verify first that you download the regression tested release rather than the trunk, since the README warns the development branch is in a constant state of flux, and read LICENSE.md because ABC is distributed under its own terms rather than the project's MIT licence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. verilog-to-routing/vtr-verilog-to-routing on GitHub