Ara integration in Cheshire (2)

[mp-17]

This is the second PR for Ara's FPGA and OS support. See #112 for the bare-metal one.

• Add support for back-referencing FPGA flow (i.e., by driving the FPGA implementation from Ara's directory).
• Adapt Ara-CVA6 interface to support virtual memory.
• Bump Ara and CVA6.
• Update the CI to test RVV Linux, Cheshire + Ara on VCU128, and its Linux boot.

Before merging, Ara and CVA6 should be referenced with TAGs laying on the main branch.

[paulsc96]

This is very clean as far as the diff in this repository.

The back-referencing setup however, while an intriguing construction, seems unnecessary. We can further discuss this offline, but:

• To avoid the hardware back-reference (Bender script inject):
  • It is perfectly fine to unconditionally add Bender flags required by Ara to Cheshire; CVA6 does this too.
  • If you need these flags to be configurable (nr_lanes, vlen), it is best to introduce variables for them in the Cheshire make fragment (like those for the PLIC, CLINT etc.) and insert them in the build targets for the analyze scripts. This way, they can be overriden the same way as all other non-SV IP parameters.
  • If I missed something and you need to dynamically generate RTL (I don't think so), it would be great if you could follow the established method of creating an includable Make fragment in Ara to reconfigure its RTL from Cheshire as needed.
• For the device tree, each (FPGA) target may have multiple device trees; you can simply add one called cheshire.vcu128_ara.dts using riscv,isa = "rv64imafdcv" instead of patching cheshire.dtsi.
• For Linux, I don't necessarily mind if an Ara-ready image cannot (yet) be built directly from Cheshire. How we build and manage Linux is about to fundamentally change anyways, so adding a back-reference for this now is perhaps untimely. We can address this in a cleaner way in a later PR.

[paulsc96]

Having these as defines is fine, but perhaps they should be prefixed to clarify they affect Ara