OpenFPGA now embrace latest Verilog-to-Routing (VtR)

[tangxifan]

🚀 What does this mean?

OpenFPGA was based on a hard forked version of Versatile Placement and Routing (VPR), which allows maintainers to develop useful technical features in a fast way.
However, this brings a lot of barriers to keep our VPR up-to-date from the upstream, since there have been many exciting features happened there.
After two-year of co-development with Verilog-to-Routing (VtR) team, we have managed to contributed many technical features back to upstream VTR, including

• Modularized routing resource graph data structure. Dashboard for RRGraph API refactoring status verilog-to-routing/vtr-verilog-to-routing#1868
• Tileable routing resource graph builder. [WIP] Tileable Routing Resource Graph Builder verilog-to-routing/vtr-verilog-to-routing#2135
• Post-routing synchronization with clustering results. Post routing cluster block pin fix-up verilog-to-routing/vtr-verilog-to-routing#1355
• Disable packing for specific modes in pb_type. Packable mode support  verilog-to-routing/vtr-verilog-to-routing#1309
• Set a constant name for VPR;s delayless switches. Reserve VPR delayless switch name verilog-to-routing/vtr-verilog-to-routing#1305

Along with the strengthen collaboration with VtR team, we have resolved major conflicts between the hard-forked VPR and upstream, especially in the code modularization, APIs, etc.
We are confident to use VtR as a submodule in OpenFPGA. As such, we can setup dependabot to received latest VtR upgrades regularly. The OpenFPGA community can benefit from latest upgrades in VtR shortly, and use them in prototyping FPGA devices.

Through this effort, we sincerely believe that this will help both OpenFPGA and VtR communities to grow faster than before, and open more opportunities in FPGA researches and products!

🔎 How to find the updated version

The code changes have been merged into the master branch through PR #747
You can start playing with the new version today!

⚠️ What I should know before starting

The critical updates on OpenFPGA has introduced some changes which may impact user interface and back-compatibility.

• Now Verilog-to-Routing is a submodule under the root, being similar to yosys and yosys-plugin.

We use a feature branch openfpga under the Verilog-to-Routing official repository. https://github.com/verilog-to-routing/vtr-verilog-to-routing/tree/openfpga. We will merge this feature branch to the master branch of VTR, which may take a few months to complete.

• Now libopenfpga is renamed to libs
• Golden netlists outputted by FPGA-Verilog should remain the same.
• Added gcc-10, gcc-11 build compatibility (deployed to CI)
• Removed the support on gcc-5 and gcc-6 due to that VTR only supports gcc-7, 8, 9, 10, 11, clang-6, clang-7, clang-10
• Now all the executables are located under the build directory. 🎺 No more executables in source code directories!!!
• Users can use option BUILD_TYPE in the Makefile to select build type: release or debug.
• The (VPR) architecture files used with v1.1.x (Hard forked VPR) may not be compatible with v1.2.x (with upstream VtR). You can upgrade your architecture files with script

python3 openfpga_flow/scripts/arch_file_updater.py \
    --input_file ${v1.1_arch_file} \
    --output_file ${v1.2_compatible_arch_file}

✔️ All the existing features of OpenFPGA has been tested and ensure non of them are dropped during this upgrade

⛔ However, any new features in the VtR other than the previous hard forked version (back to VtR 2019.11) have not been tested!!! We are actively working towards this target!

🕐 What if I do not want to try the new version now

If you want to stay with v1.1.x, the final build was (tag: _OpenFPGA:v1.1.541)

https://github.com/lnis-uofu/OpenFPGA/tree/v1.1.541

or you can download the docker image

docker pull ghcr.io/lnis-uofu/openfpga-master:v1.1.541