Maybe consider donating to the github.com/HDL organization?

[mithro]

The HDL GitHub organization is 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 bringing these different styles of packaging together under one GitHub organization so people can share 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 put together by the GHDL / V-Unit community about the various asks of things here.

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

[ktemkin]

I'm definitely open to this. Would more immediately be involved beyond a change in namespace?

[umarcor]

Hi @ktemkin! No more involvement neither now nor in the foreseeable future.

As @mithro said, the main target is to bring people from several camps of the open source hardware community into a meeting point. The idea is that watching what others are doing can help reduce the fragmentation and/or to explain to newcomers where is the fragmentation and why.

The first point to start with is ensuring that all users can get the tools. Since these are all very rapidly moving targets, system package managers on most distros are too slow, so the community has proposed several solutions which are apparently conflicting. However, some are focused on Verilog, others on VHDL, some are for synthesis, some for simulation... There are very few projects which cover an "acceptable" spectrum of tools because typically each of us is focused on our area of expertise. We hope that we can achieve a wider knowledge and coordination.

Yet, none of the projects in the HDL organisation is the main project of any of the contributors. Therefore, no need to rush. The idea is, before you do something, think whether it fits in one of the existing repos, or whether creating a repo in that organisation makes sense. Then, go ahead with the agenda you had. Do not force yourself to make more than you had planned to, but neither constraint the descriptions to what you will implement yourself only.

See, for instance, https://hdl.github.io/MINGW-packages/#_packagestools. Some of those tools were packaged by others (unrelated to HDL org), some of them were packaged by me (with feedback/help from project maintainers) and some are not going to be packaged in the near future, but they are on the radar.

There are also containers (https://hdl.github.io/containers/) and Bazel rules (https://github.com/hdl/bazel_rules_hdl) in the org. Moreover, there are sibling projects which are maintained independently, but which are tightly related (https://github.com/hdl/smoke-tests/blob/main/CONTEXT.md). There is communication and collaboration with open-tool-forge/fpga-toolchain and also with the Conda/Python work being done in Antmicro/SymbiFlow.

NOTE: https://github.com/hdl/packages was created a few days ago, so we will probably move CONTEXT.md from smoke-tests into there, and use it as the index for referencing other repos (in or out of the org). Probably include a table showing which tools are available in each environment.

smoke-tests itself is an attempt at gathering minimal and atomic tests for the most common tools. Regardless of the procedure used for building and installing the tools, if a bash shell is available, those tests should pass. That provides a minimal reference about where each packaging approach is.

There are repos not specifically related to packaging because the HDL org is not constrained to that (it's just the first step in the way).

constraints gathers board, device and memory constraints which are required in any FPGA design. Again, that information exists in many places using different file types and syntaxes. However, data is the same. We started with gathering constraint files as used by tools, but there is interest in closing the gap with litex-boards and similar proposals.

awesome was the original reason for creating the organisation. It is an awesome list on steroids, where each tool is defined in a different markdown file with a frontmatter. In all my packaging repos, I ref the tools to their awesome page. That allows to use a single URL in docs of packaging repos, but have several references (repo, website, docs, youtube, twitter, etc.) in the corresponding awesome page. Most awesome pages are placeholders yet, tho, since I prioritised containers and MSYS2 packaging.