Consider collaborating (or joining forces with) the https://github.com/hdl organization?
mithro opened this issue · comments
Hi!
As @edbordin mentioned when I logged a bunch of issues around adding things like support for Xilinx and QuickLogic toolchains, it is a lot of work to keep things building and moving forward. To help reduce burden on a single maintainer (and thus things like burnout) a bunch of people from the GHDL / V-Unit community created the HDL github organization and are trying to build a critical mass around providing open source EDA tooling (like the open source FPGA tooling) in a number of different ways like static binaries, conda, docker and including "native" solutions like homebrew.
The idea is that bringing these different styles of packaging together under one GitHub organization makes it easier to do things like; sharing tips around how to get things auto-building on CI, workarounds for common issues, how to test the tools are working, etc. There is quite a long document covering a lot of aspects of this topic. We plan to move the conda packaging currently found on LiteX-Hub / SymbiFlow / TimVideos organizations to this location and have already been working on doing a bunch of bazel related build rules (which are probably not that interesting to you but shows there is a bit of momentum behind the effort). Having everything under one organization also makes it easier for people like my employer to donate things like build resources to speed up CI and support on hardware testing.
I think you should consider collaborating with this group, joining the organization and potentially even going as far as moving your repositories over. Given the strong set of VHDL enthusiasts, I'm sure if you moved the repository over there would be a strong incentive to add things like GHDL and demonstrate things like mixed-synthesis support (The community did that recently for the Fomu workshop, see https://workshop.fomu.im/en/latest/vhdl.html and https://workshop.fomu.im/en/latest/mixed-hdl.html).
Understand if you want to maintain to stay separate but highly recommend considering this. If you are actively involved in the HDL organization you can also make sure things like the needs for the icebreaker and your FPGA workshops are first class citizens in not only when using static binaries but also in other packaging schemes like Docker / conda / etc.
Keep up the awesome work!
Tim @mithro Ansell
Sorry I never replied Tim. I think there were various discussions between different groups of people around this time earlier in the year. At some point it became clear to me that the static linking approach was causing limitations (notably, not being able to deliver iverilog never quite sat right with me) so this project has sort of lived on in spirit through oss-cad-suite.
I got the sense that a lot of hardware-oriented people aren't quite as comfortable with tools like containers and conda, or find them difficult in airgapped corporate environments. I'm mostly speculating here but it wouldn't surprise me if that translated into some of the customer requirements for Tabby CAD. I have a software background like yourself so I regularly use conda and containers. Next time I dive back into some fpga tinkering I definitely plan to take a look at what the hdl org has come up with!