vtr-verilog-to-routing
vtr-verilog-to-routing copied to clipboard
Support SystemVerilog using Surelog parser
We should be able to handle SystemVerilog input using the Surelog front-end for yosys.
- Add a simple regression test to check end-to-end flow.
- Update documentation to explain how to run with SystemVerilog.
@benbroce
FYI - @acomodi / @kgugala
FYI - @hzeller
It seems some repositories, like googletest, are recursively used with various versions in the Yosys UHDM Plugins Integration. For instance, we got googletest @ 8d51dc5
inside Surelog/third_party and googletest @ e2239ee
inside Surelog/third_party/UHDM/third_party. VTR uses subtrees instead of submodules, so it seems we need to add each version of these repositories separately as a subtree to the VTR repository. There is also capnproto @ 14f24a4
inside Surelog/third_party/UHDM/third_party, while VTR already has a version of this library. Considering the fact that we do not modify subtrees' source code, we need to add another version of this repository to the VTR repository as well. It would be helpful to know anyone else's thoughts on this.
@vaughnbetz Is there a reason VTR decided to use subtree instead of submodule?
All of the google/f4pga repos seems to use submodules (that I'm aware of), and it seems like the better candidate for this case, where we have different dependency repos using different version of the same tool. This is easy to manage with submodules, although I'm really not familiar with subtrees, so maybe it's easy to mange with those as well...
I'm far from an expert on this, but it seems like git subtree's are generally recommended over submodules (at least the top few articles I see on them recommend subtrees). See https://www.atlassian.com/git/tutorials/git-subtree
This is likely a good thing to discuss in the VTR meeting today if you can make it.
Closing this issue as the support is added in PR #2068, and documentation will be updated in PR #2139