RV64 support + baremetal binaries

[jerryz123]

Chipyard now supports simulating two different vector units:

• Saturn (https://github.com/ucb-bar/saturn-vectors) supports full 1.0 RVV, with virtual memory, precise traps, and Zvfh/Zvbb

• Ara (https://github.com/pulp-platform/ara) supports most of 1.0 RVV

  We'd like to use this project to evaluate these vector units, and perhaps, use the vector units to assist in kernel development. I think there's two key capabilities that would make this much easier.

  • Support RV64 targets, it seems like currently it only supports rv32 (I might be wrong here)
  • Support compilation for bare-metal targets. We generally like to avoid running code with pk

  I'm happy to help make these changes happen, if the developers of this project agree.

[PhilippvK]

Hi,

the library itself is not limited to XLEN=64. What needs some work is the CMake config and the Scripts in the repository.

There are already some WIP branches which implement support for 64bit targets in some degree

• ara-support: Might be a bit outdated
• rv64bench: Hardcoded everything to use 64 instead of 32 bits. Also includes changes to scripts used in CI/Benchmarking.

I am currently working on toolchain refactorings to support RV64/RV32 on the same branch in a generic fashion. This will make the two mentioned branches obsolete.

Regarding the baremetal targets it should be feasible, but for spike I have no experience regarding how the target would report benchmark results or test failures (I expect we would need to use tohost? Are there other baremetal targets you have in mind?

We also have a project going on to bring muRISCV-NN to real RVV 1.0 hardware such as the CanMV K230 using an RTOS or Linux.

I hope this answers you questions!

[jerryz123]

Thanks Phillipp, I look forwards to support for selectable RV64/RV32.

Regarding baremetal targets, the main differences would be

• relying on tohost/fromhost (HTIF) for printf. A HTIF implementation of a minimal set of syscalls is provided in libgloss-htif (https://github.com/ucb-bar/libgloss-htif). With the right linker flags, it should be straightforwards to statically link libgloss
• avoiding I/O. Baremetal binaries cannot perform file I/O, so any test data must be baked into the binary. I'm not sure how much of a problem this will be.