google / google/CFU-Playground
Packaging discussion
- Dominant language
- Verilog
- Stars
- 565
- Forks
- 160
- PR merge metrics
- No merged PRs in 30d
Description
Currently there is initial support for getting some tools (yosys, nextpnr-nexus, prjoxide) via Conda. This is optional (you can opt to install the tools directly on your system), and only in addition to the base setup (./scripts/setup).
If we make the jump and *require* that the user use Conda, then we can simplify our setup, and also reduce what the user is required to install (specifically the GCC RISC-V toolchain, and also some "apt install ..." requirements).
Also, if we intend to make SymbiFlow default for XC7 devices (#9, https://github.com/SymbiFlow/symbiflow-examples/issues/204), that will require using Conda.
Here's a laundry list of things on my mind about making the jump:
* We can eliminate some of the dependencies that we currently clone from GitHub, e.g. meson.
* We still want to clone LiteX and Lite* repos since we often make local changes. We need to accommodate this in the Conda installation.
* We need to be careful that we don't mix using a system RISC-V toolchain and the Conda-provided toolchain. I ran into this frequently in my experiments. LiteX found a toolchain with one prefix, while our Makefiles used a different prefix.
* We have some local executable builds, e.g. flashrom. We'd need to see whether we can get these through Conda, and whether the Conda version is new enough.
Sometimes containers are suggested as an alternative. I'd consider it, but currently I don't know what the "user journey" using containers looks like.
Contributor guide
Assessment
This issue has not been assessed yet.