RocketChip standalone build support is deprecated upstream, requires use of SoC frameworks

[n-kremeris]

Please see the issue here that's raised on the rocketchip's github page: https://github.com/chipsalliance/rocket-chip/issues/3483

Current upstream RocketChip has moved to using Mill instead of SBT, and the support for building it standalone (like what Litex Rocket update.sh does) is now deprecated and removed due to lack of maintainers.

From one of the contributors: Unfortunately, the standalone rocket-chip build support has been deprecated and removed, due to lack of developer resources to maintain that feature. To build and test SoCs with rocket-chip, users should seek out SoC frameworks., notable options include Chipyard and Playground.

As a result, rebuilding rocket from latest scala sources using update.sh is not possible. I suggest a temporary solution would be to add a checkout for an older commit in update.sh for the time being, at least until some kind of migration path can be adopted.

[gsomlo]

This should be addressed by https://github.com/litex-hub/pythondata-cpu-rocket/commit/85e155f96d0b4a7c4098e1e5f6938eddff8105ec

I'm now going to start a low-key search for a 64-bit rv64gc, fpu, mmu, and s-mode capable RISC-V chip that can boot a real distro (e.g. Fedora) like Rocket chip could. Bonus points if it's written in Verilog, rather than some obscure "write-only" language :P

[mithro]

You probably want to add "maps efficiently to FPGAs" to your requirements.

[mithro]

@gsomlo - BTW BlackParrot might be a good candidate, the UWash team has previously been active with LiteX related stuff and they would probably respond positively to more users. I believe BlackParrot almost goes through Surelog->UDHM->Yosys correctly these days.

[gsomlo]

looks like we're waiting for rocket-chip upstream PRs https://github.com/chipsalliance/rocket-chip/pull/3493 and/or https://github.com/chipsalliance/rocket-chip/pull/3494 to land in master before being able to resume building litex variants with make verilog (but now with the requirement that the $MILL env.var. be set to something "sensible" before running make verilog).

I find that an acceptable compromise.

Though I am still interested in a [system]verilog (or migen) solution, for reasons of "source code understandability" (whatever software engineers call that property :) ) and the somewhat related/resulting "bus factor" -- thanks everyone for all the suggestions!

[gsomlo]

Closing, see https://github.com/litex-hub/pythondata-cpu-rocket/pull/6#issuecomment-1972206003 for the current resolution.

We can revisit this if/when upstream rocket (or yosys' ability to handle .sv files) changes.