Use conda + Update initial setup docs + Bump FSim

[abejgonzalez]

This PR removes the *-req.sh scripts in favor of using Conda (same system that FireSim uses to manage system packages). The machine-launch-script.sh is basically the same as FireSim's version but doesn't include the python specific additions. I've also changed the documentation to be a bit clearer on how to run things in a AWS EC2 context and in the normal scenario. This change basically enables build-toolchains.sh to always work when building in a conda environment (I tested this on both the normal and esp-tools toolchains)! This doesn't affect the rest of the flows (running the toolchain out of $RISCV, etc.)

We should discuss how to deal with conda activate chipyard, when to do it, how does it operate w/ FireSim. Etc.

• [ ] Does a VCS simulation work?
• [ ] Verify the entire flow (SBT launch -> RTL created -> VCS/Verilator)
• [ ] Fix CI (either have new conda environments spawned for each CI run or have the environment setup offline on each CI instance)
• [ ] Fix esp-tools running under conda

Related PRs / Issues:

Type of change:

• [ ] Bug fix
• [x] New feature
• [x] Other enhancement

Impact:

• [ ] RTL change
• [ ] Software change (RISC-V software)
• [x] Build system change
• [x] Other

Contributor Checklist:

• [x] Did you set main as the base branch?
• [x] Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
• [x] Did you state the type-of-change/impact?
• [x] Did you delete any extraneous prints/debugging code?
• [x] Did you mark the PR with a changelog: label?
• [x] (If applicable) Did you add documentation for the feature?
• [x] (If applicable) Did you add a test demonstrating the PR?

• [x] (If applicable) Did you mark the PR as Please Backport?

[abejgonzalez]

I've sketched out where the conda activate calls should go. Once that is settled I'll update the docs to reflect that.

[abejgonzalez]

Cancelling CI since there needs to be more work done to make that work.

[vighneshiyer]

What would the flow look like if I wanted to use a custom version of riscv-isa-sim? If I were to clone it somewhere and compile it, how can I make sure it would override the riscv-isa-sim files included in the riscv-tools conda package when running RTL simulations (i.e. using the custom fesvr.so / spike)?

I think it would be better to have separate conda packages for riscv-gcc, libgloss, riscv-isa-sim, riscv-pk, and riscv-isa-tests. That way it is easy to uninstall one of them from your conda environment and replace it with a custom version. It also makes the dependency tree clearer (e.g. riscv-isa-sim doesn't depend on any of the other packages). In the interim, it is probably ok to leave everything but riscv-gcc as a source dependency in chipyard, considering they are fast to compile.

[abejgonzalez]

What would the flow look like if I wanted to use a custom version of riscv-isa-sim? If I were to clone it somewhere and compile it, how can I make sure it would override the riscv-isa-sim files included in the riscv-tools conda package when running RTL simulations (i.e. using the custom fesvr.so / spike)?

~~You would still build your version of Spike and put it on the PATH (I'm not sure if you need to modify the LD_LIBRARY_PATH for custom Spikes). If you really wanted to be absolutely sure there is no pollution of the normal tools with the custom Spike you could deactivate the normal tools by running source $CONDA_PREFIX/etc/conda/deactivate.d/deactivate...riscv-tools.sh.~~

I think it would be better to have separate conda packages for riscv-gcc, libgloss, riscv-isa-sim, riscv-pk, and riscv-isa-tests. That way it is easy to uninstall one of them from your conda environment and replace it with a custom version. It also makes the dependency tree clearer (e.g. riscv-isa-sim doesn't depend on any of the other packages). In the interim, it is probably ok to leave everything but riscv-gcc as a source dependency in chipyard, considering they are fast to compile.

~~That is definitely what we plan on getting towards, this PR is an intermediate PR where we can 1st have everything bundled together. I think the final split of items will be Spike + PK in one package, and everything else in a separate package (i.e. everything that depends on the toolchain) until we split up the toolchain even more according to how conda normally packages toolchains. If people really care about having Spike + PK built separately, I can add that in this PR.~~

[abejgonzalez]

Ok right now I have the following setup:

1. Install the RISC-V compiler with the conda package conda install -c ucb-bar {riscv-tools/esp-tools} (sets $RISCV/$PATH/$LD_LIB_PATH
2. Run ./scripts/build-toolchains-extra.sh {riscv-tools/esp-tools} to build/install Spike/PK/tests in the $RISCV area made/set by the conda package (libgloss also installed to compiler area).

I.e. everything is installed in $RISCV path like the following:

conda-dir/
  bin/
  riscv-tools/
    # compiler - installed by conda
    # everything else

I wonder if this is better/would be better for people.

1. Install the RISC-V compiler with the conda package outside of $RISCV env (in normal $CONDA_PREFIX/bin) (also point $LD_LIBRARY_PATH to $CONDA_PREFIX/lib)
2. Install Spike/PK/tests to a local RISCV folder (like the current toolchain folder - i.e. $CY/riscv-tools-install). Env. variables would point to this area like before (users would have to source the same file as now - source env-riscv-tools.sh). libgloss would still have to be installed directly to where the compiler is located.

conda-dir/
  bin/
    # compiler - installed by conda
    # libgloss - installed from src
    
chipyard/
  riscv-tools-install/ # or where the user wants
    # everything else

This setup would minimize the items needed to be built and installed in the conda managed area and would make it clearer what is managed by CY. I'm just not sure how much things would break with the compiler not present in the $RISCV path.

[abejgonzalez]

@sagark @a0u @jerryz123 This is now ready for round 2 of review (CI is failing due to elfutils repo cloning failing randomly - most likely will 100% pass CI if I run those tests again)

[abejgonzalez]

Unfortunately, something in Linux boot is breaking :/ causing a kernel panic. I'll have to look into if this is a QEMU issue, or more likely an issue with the buildroot build with the current dependencies

[a0u]

Unfortunately, something in Linux boot is breaking :/ causing a kernel panic. I'll have to look into if this is a QEMU issue, or more likely an issue with the buildroot build with the current dependencies

Check that the dynamic linker ld.so does not have rpath set. Perhaps the Conda environment is interfering with the cross-compilation of riscv-glibc?

[abejgonzalez]

@mergifyio rebase

[mergify[bot]]

rebase

❌ Base branch update has failed

Git reported the following error:

Rebasing (1/11)
error: could not apply 1de35a6... Use conda + Update initial setup docs
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 1de35a6... Use conda + Update initial setup docs
Removing toolchains/riscv-tools/riscv-tests
Removing toolchains/riscv-tools/riscv-pk
Removing toolchains/riscv-tools/riscv-openocd
Removing toolchains/riscv-tools/riscv-isa-sim
Removing toolchains/riscv-tools/riscv-gnu-toolchain-prebuilt
Removing toolchains/riscv-tools/riscv-gnu-toolchain
Removing toolchains/qemu
Removing toolchains/libgloss
Removing toolchains/esp-tools/riscv-tests
Removing toolchains/esp-tools/riscv-pk
Removing toolchains/esp-tools/riscv-isa-sim
Removing toolchains/esp-tools/riscv-gnu-toolchain
Removing scripts/ubuntu-req.sh
Removing scripts/centos-req.sh
Removing scripts/build-toolchains.sh
Removing docs/requirements.txt
Auto-merging .gitmodules
CONFLICT (content): Merge conflict in .gitmodules
Removing .github/scripts/remote-install-verilator.sh
Removing .github/scripts/create-hash.sh
Auto-merging .github/scripts/check-commit.sh
Removing .github/scripts/build-toolchains.sh
Removing .github/actions/toolchain-build/action.yml

err-code: 99C76

[abejgonzalez]

Unfortunately, something in Linux boot is breaking :/ causing a kernel panic. I'll have to look into if this is a QEMU issue, or more likely an issue with the buildroot build with the current dependencies

Ok. I believe I resolved the issue. I tested the most recent bumped versions of the compilers (+ sysroot) with buildroot and fedora booting.

[jerryz123]

This should be good to merge. I removed the CircleCI webhook from this repo settings, since we've moved away from that service.

[abejgonzalez]

Waiting on a review from @sagark and @a0u before merging in.

[abejgonzalez]

This PR is good to merge. The errors for SPI flash/read are because we need to bump Verilator to 4.226 and the CVA6 error is because there is a segfault when CVA6 is used with DRAMSim2 in the new verilator (this is solved if you use magic memory)

[jerryz123]

CVA6 with VCS + DRAMSIM is still fine?

[abejgonzalez]

CVA6 with VCS + DRAMSIM is still fine?

I haven't had the chance to verify this on this PR but pre-Conda I do remember this working. I can confirm that VCS + CVA6 + DRAMSim2 works

[abejgonzalez]

CVA6 with VCS + DRAMSIM is still fine?

I haven't had the chance to verify this on this PR but pre-Conda I do remember this working. I can confirm that VCS + CVA6 + DRAMSim2 works

I've gone ahead and fixed this by removing a getenv call in DRAMSim2 (which I don't think is used often)(the getenv is causing a segfault presumably due to multi-thread race condition).