Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Scope of the project #1

Open
umarcor opened this issue Mar 24, 2021 · 3 comments
Open

Scope of the project #1

umarcor opened this issue Mar 24, 2021 · 3 comments

Comments

@umarcor
Copy link

umarcor commented Mar 24, 2021

By looking at the sources of this repo, it seems that the project is to generate artifacts for a wide range of platforms (both OSs and architectures). That's nice! However, I'm lacking some explanation in the README for understanding how does this fit with other similar projects in the ecosystem. I'd like to gather some information for listing it in hdl/packages and forwarding people for which this is the best solution.

Precisely, YosysHQ/fpga-toolchain is based on prior work by Miodrag, who did also contribute to apio. See https://github.com/YosysHQ/fpga-toolchain#credits and https://github.com/FPGAwars/toolchain-ecp5. Moreover, builds in fpga-toolchain are nightly/daily too. The main feature of fpga-toolchain is that tools are built statically.

In this repo:

  • Python is used for the plumbing, instead of bash.
  • The tools are cross-compiled on containers, instead of using the CI environments (typically Ubuntu).
  • At the same time, there is a Windows job in CI, which builds tools on MSYS2 "natively".

On the one hand, I'm not sure about the motivation for having a container for Windows cross-compilation and an MSYS2 CI job at the same time. I would expect one or the other to be used.

On the other hand, it seems that most of the tools are still built statically. Hence, is this a drop-in replacement for fpga-toolchain (with a different codebase and build environments)?

Furthermore, are you expecting to provide containers to end users? Or are those only for using a custom and portable build environment?

With regard to MSYS2, similarly to fpga-toolchain, you seem to have a significant number of tweaks for trying to use the same plumbing as for other platforms. However, IMHO, building a distribution of tools for/through MSYS2 is better done using the built-in package manager (pacman), PKGBUILD recipes and makepkg-mingw. In fact, the following works already:

# Extract https://github.com/msys2/msys2-installer/releases/download/2021-02-28/msys2-base-x86_64-20210228.tar.xz and open a MINGW64 shell
# NOTE: https://github.com/msys2/setup-msys2/blob/master/main.js#L12

# pacman -Syu
...

# pacman -S mingw-w64-x86_64-eda
:: There are 21 members in group mingw-w64-x86_64-eda:
:: Repository mingw64
   1) mingw-w64-x86_64-dfu-util
   2) mingw-w64-x86_64-ecpprog
   3) mingw-w64-x86_64-fritzing
   4) mingw-w64-x86_64-ghdl-llvm
   5) mingw-w64-x86_64-gtkwave
   6) mingw-w64-x86_64-icesprog
   7) mingw-w64-x86_64-icestorm
   8) mingw-w64-x86_64-iverilog
   9) mingw-w64-x86_64-kicad
   10) mingw-w64-x86_64-kicad-footprints
   11) mingw-w64-x86_64-kicad-meta
   12) mingw-w64-x86_64-kicad-packages3D
   13) mingw-w64-x86_64-kicad-symbols
   14) mingw-w64-x86_64-kicad-templates
   15) mingw-w64-x86_64-nextpnr
   16) mingw-w64-x86_64-ngspice
   17) mingw-w64-x86_64-openFPGALoader
   18) mingw-w64-x86_64-prjtrellis
   19) mingw-w64-x86_64-serial-studio
   20) mingw-w64-x86_64-verilator
   21) mingw-w64-x86_64-yosys

Enter a selection (default=all):

Find links to each of the recipes in https://hdl.github.io/MINGW-packages/#_packagestools and https://packages.msys2.org/group/mingw-w64-x86_64-eda. Recipes are located in https://github.com/msys2/MINGW-packages/.

The official recipes use fixed commits/tags. There are two workflows in hdl/MINGW-packages for keeping track of breaking changes and/or outdated packages:

On the one hand, you might use those workflows as a reference for working around the timeout issues you have in CI. On the other hand, you might want to customise those recipes for building main/master/head of the projects, instead of fixed versions. That would make your build procedure on/for Windows different from others. Yet, supporting cross-compilation for arm, arm64, riscv64 and amd64 is a huge task already. Hence, reducing the complexity of the Windows infrastructure would allow you to focus on the foreign linux builds.

Personally, I like contributing workflows for building main/master/head to the projects, instead of doing it in orgs MSYS2 or HDL. See: iverilog, verilator, gtkwave, GHDL, Serial-Studio, etc. There is a reference workflow in https://hdl.github.io/MINGW-packages/#_testing_pkgbuild_recipes_downstream, together with some brief guidelines.

Note that MSYS2 packages are tarballs. Therefore, YosysHQ could potentially have a mirror/repository with custom builds/versions, should you want to. Alternatively, you can publish assets in a 'nightly' release:

A similar strategy is used in MSYS2 for staging packages: https://github.com/msys2/msys2-autobuild/releases. See also https://packages.msys2.org/queue.

Nevertheless, MSYS2 maintainers are really fast. For instance: msys2/MINGW-packages#8180. Therefore, I don't think it's worth maintaining an independent set of nightly packages, unless you want to have very specific build options and/or combine tools with non-free software. Typically, any update will be available for everyone in 1-3 days after opening a PR.

No matter which strategy you follow, let me know if you need any hint about MSYS2/MINGW packages (hdl/MINGW-packages), QEMU and Docker (dbhi/qus) and/or MSYS2 on GitHub Actions (msys2/setup-msys2). I'm not an expert in either of them, but I do have experience with all and I'd be glad to help you make the best of your time.

Cheers
@mmicko
Copy link
Member

mmicko commented Mar 24, 2021 via email

@umarcor
Copy link
Author

umarcor commented Mar 24, 2021

Anyway this project started as my effort of making a build system for our commercial package, but in mind of greater OS support.

Is "your commercial package" Tabby CAD? Is there any non-open tool in the bundle apart from Verific's parser/frontend? I only found lists of the open source tools included.

we have a lot of people interested in using open source stack but have problems setting all solvers and can't keep up with updating all tools they need to update.

I would very strongly suggest you to distribute one container, at least, even if temporarily. In general, I don't like large monolithic containers, because of technical and conceptual reasons. However, that is the fastest solution for making any custom set of tools available to any user. That is because you need to care about a single Linux environment (pick the base image that you wish). The same image can then be used in CI, on Linux, Windows or MacOS. Once you have that first problem solved, you can focus on more granular build and distribution solutions. In a sense, I'm proposing you to focus on a subset of what you already have, since all the tools are already built/tested on some Debian/Ubuntu, you avoid all that custom copying of shared libs.

For formal verification, @tmeissner contributed multiple solvers to https://hdl.github.io/containers/#_tools_and_images. Precisely, image formal contains boolector, cvc4, superprove, yices2 and z3, apart from GHDL, Yosys and SymbiYosys. You can use it as a base and add the Verific frontend as a plugin on top of it. Also, whichever additional solvers you provide in Tabby CAD. Alternatively, you can clone/fork the repo and customise the dockerfiles to your needs; or you can have a look at it and use it for inspiration. If you want to share some effort, I'd be glad to discuss how can I/we reshape hdl/containers for making it more appealing to your needs.

NOTE: unlike MINGW-packages, in the containers ghdl-yosys-plugin is a library. Therefore, there should be no conflict for your clients to have both GHDL and Verific in the same environment.

for Windows I rely on setting PATH for now for DLL loading, but looking into better solution

I don't know whether any better solution exists. The canonical approach on MSYS2 is to install all DLLs to /bin, precisely for having all of them automatically available in the PATH without dealing with additional locations.

Note that static build is easier to make portable, but this is not possible for GUI tools, those that integrate python or others that rely on dynamic loading of plugins.

Indeed... Yet, my very personal opinion is that maintaining a custom build procedure needs to pay off due to some specific feature or use case which is not supported by upstream solutions. In the case of fpga-toolchain or apio, that added value was/is the portability and ease of installation, at the cost of certain features. At the same time, when those projects were created, many EDA tools were not upstreamed to official repositories yet.

Conversely, nowadays most of the tools are already packaged as DEB, RPM and/or PKGBUILD recipes. Therefore, I think that salsa, copr, aur, homebrew, nixos, etc. are a better fit for maintaining a complex multi-arch set of tools. In fact, this is not just a comment. I expect to replace the build procedures in hdl/containers with proper DEB and/or RPM recipes. That's because the added value of containers is the containerization itself. The recipes can and should be shared with "native" users.

IMVHO, your strong point is that you are the developers or relevant contributors of most of the tools in Tabby CAD. Therefore, you have very first hand information about upcoming challenges and potentially conflicting changes. You can foresee the work that packagers will need to do in the following update. You are also in a unique position for adding the features that your clients need, and having them published ASAP. Hence, I would like to very politely ask you to reconsider whether supporting recipes, CI and distribution of 12+ tools on 4+ archs is something that 1-2 people can develop and maintain on their own. It is my very honest believe that you would be more valuable for the open source EDA community if you balanced towards focusing on communication skills; on closing any existing gap between the development of that tools and the packagers in the major distributions. I'm pretty sure you'd get good help if you asked the community "we want help for having nightly DEBs and RPMs of all YosysHQ projects". Then, you could maintain this repository (the Python part) as a wrapper around those DEB, RPM, PKGBUILD and brew recipes. You would focus on your expertise: the integration of the tools in a bundle (not actually building and cross-compiling). At the same time, contributors would not need to learn your custom plumbing, but they'd contribute with their specific knowledge.

Please, note that I'm suggesting this because I know the effort it takes to maintain all these tools on two different environments for amd64 only (and very few multiarch). That is less than half of the work you explained in your scope! In those cases, allowing contributors not to understand the plumbing and allowing myself not to know the usage details of each tool did help all of us move forward. Of course, you might have additional constraints, demands and requirements which I'm not aware of. Hence, please, accept my apologies, should you consider it intrusive.

I have added Windows support for msys2 since that seems natural, but makes things complicated for CI and testing (if you have linux based machines only) so I made docker based one, but still have some limitations there (missing ADA compiler, so no GHDL build possible for now).

Honestly, I'm not sure that will work. Naturally, I suggest you to confirm with some expert (https://gitter.im/msys2/msys2), but my understanding is that MSYS2 cannot be used on Linux. Some users have tried using Wine, but I don't think it works. This is because the MSYS2 project itself would greatly benefit from building all their packages on Linux machines, but they don't/can't. On Linux you get mingw, not MSYS2. Both projects are similar, but not the same since long time ago. You might still be able to build all the tools using mingw/linux, but I would be careful about naming them MSYS2 or mixing them with actual MSYS2 packages.

Will see to improve preview of build status of packages per platform, so it is known what users can expect to have in the final build ( there are certain solvers that are linux only, or just can work on windows for example).

When the different packaging solutions are slightly more mature (in a few months), I'd like to make a table similar to https://hdl.github.io/MINGW-packages/#_packagestools in hdl/packages, showing the tools and versions available in each packaging solution. That will hopefully allow users to pick the one that fits their needs: FPGA/EDA, Verilog/VHDL/SV, sim/synth/formal, CI/embedded/workstation, etc. For a reference, in MSYS2 they compare themselves to Arch and Cygwin: https://packages.msys2.org/outofdate.

In time I also plan to upstream some of the changes to projects used to make scripts easier to maintain but also those projects more compatible with certain OS-es.

That is really nice to hear. In fact, most (if not all) YosysHQ projects do support MSYS2 already, which really helps maintenance of packages. Must be grateful to the people that did it.

@mmicko
Copy link
Member

mmicko commented Mar 24, 2021 via email

@umarcor umarcor mentioned this issue Mar 28, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mmicko @umarcor