Anaconda dependency breaks non-x86 targets

[tommythorn]

Expected Behavior

make pdk working

Actual Behavior

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-riscv64.sh -O /home/tommy/asic/skywater-pdk/env/downloads/Miniconda3-latest-Linux-riscv64.sh 2>&1 | cat
--2021-01-25 17:02:27--  https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-riscv64.sh
Resolving repo.anaconda.com (repo.anaconda.com)... 104.16.130.3, 104.16.131.3, 2606:4700::6810:8203, ...
Connecting to repo.anaconda.com (repo.anaconda.com)|104.16.130.3|:443... connected.
HTTP request sent, awaiting response... 404 Not Found

I went down the rathole of installing it from source, but despite claiming to be "open source" it seems very completely undocumented how to do this and I gave up after an hour. (Unfortunately pip install conda is not the solution).

Steps to Reproduce the Problem

1. Follow the Quick Setup steps from openlane

Specifications

• Version: skywater-pdk @ 3d7617a1acb92ea883539bcf22a632d6361a5de4
• Platform: RISC-V RV64GC

[tommythorn]

To preempt calls for filing this with Anaconda: it's clear that anaconda isn't actually a portable solution. It doesn't even support Arm.

[mithro]

@tommythorn - You can use the PDK without Conda if you are willing to provide all the require tools on your system manually.

[mithro]

FYI - The Conda-Forge version of Conda also seems to support a wider range of architectures (like POWER and ARM) -- unsure if it has a RISC-V version yet.

[mithro]

Nobody has written such instructions however...

[mithro]

make-env is the tool being used to set up the environment using conda. The goal is for make-env to eventually support environments provided by your system, conda or containers (like docker).

This is likely to be pair with the work @umarcor is doing at https://github.com/hdl and documented in this Google doc.

[umarcor]

Given how new RISC-V silicon is, I would not expect a fully packaged solution to be available in the short-mid term. It is possible to run docker on RISCV since 1.5y ago: https://github.com/carlosedp/riscv-bringup. However, there are no official images yet: https://github.com/docker-library/official-images#architectures-other-than-amd64. Other than that, I believe that most of the tools are not tested on anything other than x86_64/amd64.

Therefore, I guess that the first step would be trying to build all of them from sources on RISC-V hosts, and upstreaming patches. Trying to go for OpenLANE will be tricky, because instructions are based on building and using a container.

[tommythorn]

Two points you must have missed:

1. In order to get to this point I obviously had Docker working
2. Even Arm isn't supported by conda.

There may be other things that isn't supported outside of x86, but I haven't found them yet.

EDIT: I apologize if I sound annoyed, but I found Anaconda's "open source" claim somewhat of a misrepresentation.

[mithro]

https://github.com/conda-forge/miniforge

[mithro]

https://docs.conda.io/en/latest/miniconda.html

[umarcor]

1. In order to get to this point I obviously had Docker working

I was referring to supporting containers for RISC-V hosts in repo hdl/containers. That's why I linked https://github.com/docker-library/official-images#architectures-other-than-amd64.

If you can provide a riscv64/debian:buster-slim image, we can try providing multiarch images supporting RISC-V hosts. In dbhi/docker, Docker and QEMU are used on GitHub Actions for generating container images for arm and arm64 hosts (see dbhi/qus). The same strategy might be applied. However, as far as I am aware, there is no official Debian container image for RISC-V hosts, which we can use as the base: https://github.com/hdl/containers/blob/main/base.dockerfile#L20.

2. Even Arm isn't supported by conda.

There may be other things that isn't supported outside of x86, but I haven't found them yet.

EDIT: I apologize if I sound annoyed, but I found Anaconda's "open source" claim somewhat of a misrepresentation.

You are shooting at the wrong place. The issue is unrelated to Conda/Anaconda. Those are, mainly, distribution mechanisms. If no build recipes exist, there are no binaries/executables, and there is nothing to be distributed. That's the issue. I believe that none of these tools is built for RISC-V on a regular basis. No matter which packaging mechanism you use, you won't find them. Therefore, you can complain about conda, apt, dnf, pacman... But you should not let your feelings blur your view of the technical matter.

I am neither fond of Conda, but it is a misunderstanding to claim something is not open source because it does not work on certain CPU architecture or because you cannot find documentation. It is open source and, because it is, you can look at the sources and contribute the patches for it work on whichever architecture you wish, or you can fund someone with the expertise to do so. It does not imply much more on top of explicitly allowing you to do so.

However, you don't need to contribute to having Conda supported on RISC-V if you don't want too. There are a dozen different packaging strategies: hdl/packages. Contributing to any of them would be helpful for the community. Using Conda is one approach that several people found suitable for their use cases and they decided to contribute that support. That's also what allows the toolchain to be usable, at least on x86_64/amd64. I'm not aware of any other packaging solution which supports that yet. Hence, as little as we might like Conda, there is value in that solution being available and it does not conflict with whichever contributions you might want to help with in other packaging strategies.