This is the most galaxy brained solution to windows package distribution I've seen yet, I'm impressed and horrified @Amyayash
What is YoWASP?
Why use WebAssembly?
A batch compiler, such as an FPGA toolchain, transforms input files to output files without using any OS services beyond basic bookkeeping. Is it really necessary to build something so fundamentally simple for a large matrix of every OS × every CPU? With WebAssembly and WASI, it is now possible to build a single universal binary that runs on many OSes and CPUs.
Do I need a browser?
Despite the name, WebAssembly is not tied to browsers; it is a kind of machine code that can be easily translated into x86, ARM, or other machine code that your CPU runs directly. The YoWASP project currently does not provide tools that can run in a browser.
Why use language package managers?
Many new hardware definition languages are embedded in another host language, which comes with its own package manager and repository. For example, Amaranth HDL is embedded in Python, which uses pip and PyPI. There are several benefits in distributing FPGA tools via language package managers:
- Designers working in such HDLs are already familiar with the package manager of the host language, making it is a convenient distribution mechanism;
- Synthesis and PnR tools can be added as ordinary dependencies to the project, and their versions can be frozen for reproducibility;
- “Turnkey” toolchain installation enables new applications that generate FPGA bitstreams just-in-time, or use synthesis tools to transform netlists.
Which tools are provided?
This project provides packages for:
Which platforms are supported?
YoWASP relies on a WebAssembly engine to run the WASM code, and inherits both its advantages and its limitations.
YoWASP is an early technology preview. At the moment, it uses the Wasmtime engine, which supports the following platforms:
- Linux (x86_64 and AArch64),
- macOS (x86_64),
- Windows (x86_64).
This list is unfortunately short. The maintainer of YoWASP is working together with the maintainers of several WebAssembly engines to expand it.
Are there other packages?
YoWASP isn’t the only project that packages the open-source FPGA toolchain, and it has some limitations. One of the following projects may suit your workflow better:
- YosysHQ FPGA toolchain is a native build (x86_64 Linux and macOS only) that includes GHDL and programming tools (
How do I use the tools…
… with Python?
To use Yosys, install the
yowasp-yosys package using pip or add it as a dependency. It provides the
To use nextpnr-ice40, install the
yowasp-nextpnr-ice40 package using pip or add it as a dependency. This package contains support for every device, and provides the
To use nextpnr-ecp5, install the
yowasp-nextpnr-ecp5 package using pip or add it as a dependency. This package contains support for every device, and provides the
To use nextpnr-nexus, install the
yowasp-nextpnr-nexus package using pip or add it as a dependency. This package contains support for every device, and provides the
To use nextpnr-gowin, install the
yowasp-nextpnr-gowin package using pip or add it as a dependency. This package contains support for every device, and provides the
yowasp-nextpnr-gowin executable. It also depends on a compatible version of the
Apicula package, which provides the
Try running e.g.
yowasp-yosys --version to see if everything works! When the tools are run for the first time, it will take a few seconds for them to be compiled to machine code.
If the packages are installed in a virtualenv, they will only be available in that virtual environment. Otherwise, they will be available system-wide or user-wide, similar to any other Python scripts installed via pip.
… with other languages?
At the moment, only PyPI packages are provided. Open an issue if you’d like YoWASP packages to be built for another ecosystem.
Are the tools slower?
Yosys built for WebAssembly is about half the speed of a native build. Nextpnr built for WebAssembly runs about as fast as a native build.
How are the packages released?
Every day, latest upstream changes are automatically pulled in, packaged, and uploaded to Test PyPI. Every week, after manual review, latest upstream changes are packaged, uploaded to PyPI, and become available to downstream users.