Verilog-to-Routing

[umarcor]

This is work in progress for adding Verilog-to-Routing.

• [x] Should the image name be vtr or vpr?
• [x] ~It seems that PREFIX is not honored in the build scripts.~ Fixed by using cmake.
• [ ] Are there any runtime dependencies apart from libgtk-3-bin?

/cc @mithro

[mithro]

The image with vpr in it should just be called vpr. If the image has Odin-II, ABC and VPR in it, then it should be called vtr.

[umarcor]

The image with vpr in it should just be called vpr. If the image has Odin-II, ABC and VPR in it, then it should be called vtr.

Thanks! I'm not sure about what is the entrypoint of ABC, but these images do contain Odin-II (https://github.com/hdl/containers/runs/3100299682?check_suite_focus=true#step:5:62); hence, naming them vtr is ok.

[mithro]

It would probably be good to split the Odin-II and vpr into seperate containers?

[umarcor]

It would probably be good to split the Odin-II and vpr into seperate containers?

Might be. However, I'm not sure that use case is actually supported. There is no reference in VTR about how to build them separated:

• https://github.com/verilog-to-routing/vtr-verilog-to-routing#building
• https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/BUILDING.md

There are guidelines for building Odin-II alone (https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/doc/src/odin/quickstart.md), but no reference about building VPR with a pre-built Odin-II.

EDIT

Note that container vtr will always contain both VPR and Odin-II. Therefore, it is ok to publish this image, even if we later add vpr and odinii images, and then compose vtr with those. Final users of image vtr should not feel any difference (otherwise, we did something wrong).

[mithro]

@umarcor - Try taking a look at the conda packages?

[umarcor]

Try taking a look at the conda packages?

I did, however, there are 7 variants: https://github.com/hdl/conda-eda/tree/master/pnr. I'd rather focus on verilog-to-routing/vtr-verilog-to-routing#1756 as follow-up to this PR. Related to https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/dev/DOCKER_DEPLOY.md and verilog-to-routing/vtr-verilog-to-routing#1804, I want to move https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/.github/gha/install_dependencies.sh#L5-L51 into a set of build/vtr/{clang*,gcc*} images. That will allow VTR not to install all the dependencies in each CI run (90s x number_of_jobs are being spent on that), and it'll be easier to handle builds in this repo.

[mithro]

This pull request seems to have a bunch of renames which should probably be in a different pull request?

[umarcor]

This pull request seems to have a bunch of renames which should probably be in a different pull request?

That is the "TMP" commit (https://github.com/hdl/containers/pull/38/commits/e3722a4daea98bf1925c40d013fe1a00c4a4be92). It is for preventing workflows other than vtr from executing when this PR is updated. Before having it merged, I will remove that commit.

[vaughnbetz]

If you package up the whole of vtr, then I'd call it vtr. If you package up individual tools (vpr, odin, etc.) then I'd name it after those tools.

The vtr CI tests are run with all tools installed, so we don't really worry about packaging up individual tools. So it might be easier to get vtr itself packaged, rather than the sub-programs.