Tools like Yosys and Vpr not in PATH on latest Quicklogic image

[carlosedp]

❯ docker run -it --rm -v $(PWD):/src -w /src gcr.io/hdl-containers/symbiflow/eos-s3 yosys
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "yosys": executable file not found in $PATH: unknown.

❯ docker run -it --rm -v $(PWD):/src -w /src gcr.io/hdl-containers/symbiflow/eos-s3 vpr
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "vpr": executable file not found in $PATH: unknown.

Had to manually add with ENV PATH=/usr/local/envs/eos-s3/bin/:$PATH

[umarcor]

You need to activate the conda environment after starting the container. See https://hdl.github.io/containers/ug/index.html#_symbiflow. However, that is tested for the xc7 images. As commented in the SymbiFlow channel on Slack, there might be issues in the eos-s3 image due to --strip-components: https://github.com/hdl/containers/tree/symbiflow-eos-s3.

[carlosedp]

Doesn't work either... the conda script is using python which is not installed. There is python3 instead.

Also:

❯ docker run -it --rm -v $(PWD):/src -w /src gcr.io/hdl-containers/symbiflow/eos-s3
root@cbfcaa780bca:/src# python3 /usr/local/condabin/conda activate eos-s3

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run

    $ conda init <SHELL_NAME>

Currently supported shells are:
  - bash
  - fish
  - tcsh
  - xonsh
  - zsh
  - powershell

See 'conda init --help' for more information and options.

IMPORTANT: You may need to close and restart your shell after running 'conda init'.

[umarcor]

I think I mistakenly kept the "old" URL (the one from June) when downloading the eos-s3 artifacts. I.e., I updated the xc7 URLs only: https://github.com/hdl/containers/commit/ee7ca86c7186761c7610e440065445283933d79b Hence, that might have been fixed upstream. I will look into it as well.

[umarcor]

It should be fixed now: https://github.com/hdl/containers/commit/9958d9372fb64ebf180971a5c6606669139d56f3. Note that you need to use a login (probably interactive) shell in order to have the profile.d scripts properly sourced. See https://github.com/umarcor/symbiflow-examples/commit/a16becb0186d98e0f3b33bd93788f02286222fc9 and https://github.com/umarcor/symbiflow-examples/actions/runs/1576528548.

[carlosedp]

I don't get why adding this complexity to it. I think this wouldn't work correctly with Edalize running thru the wrapper script as it calls each tool (symbiflow_synth, symbiflow_pack, etc) and the wrapper script assumes the tools are already in the path.

As we have different images for each FPGAZ toolchain, why not having the environment already activated.

[umarcor]

Images are now available in the */conda/* namespace, and the environments are activated through profile.d. See:

• https://github.com/hdl/packages/blob/main/.github/workflows/containers-conda-symbiflow.yml
• https://github.com/hdl/packages/actions/workflows/containers-conda-symbiflow.yml

[carlosedp]

Running Edalize thru this new wrapper works: https://gist.github.com/carlosedp/ac36e9052bfa23f84b2f42f1a05ee1bd

[umarcor]

@carlosedp, want to submit a PR? https://github.com/hdl/containers/blob/main/doc/ug/FineGrained.rst#edalizes-launcher

[carlosedp]

I'll probably submit a PR to el_docker script in Edalize and then I send there with the correct link :)