5 ms·
Is having physical RISC-V hardware required, or would using an fpga-based risc-v cpu or a risc-v emulator be acceptable?
by tbirdz 10y ago
Is having physical RISC-V hardware required, or would using an fpga-based risc-v cpu or a risc-v emulator be acceptable?
- mynameislegion 10y agoThe qemu support for RISC-V is being upstreamed right now and there is also the Spike RISC-V simulator that you can use. There are various soft CPUs that can be run in FPGAs too.
- tbirdz 10y agoThanks for giving some specific examples of risc-v emulators. I was curious if using an fpga or emulator based solution (assuming it could fit in a rack enclosure) would be acceptable for the Fedora team, or if they wanted actual bare-metal risc-v hardware.
- asb 10y agoQEMU on modern x86 is going to give _much_ better performance than an FPGA.
- bonzini 10y agoOnly linux-user is going to be accepted upstream until the privileged spec is finalized.
- hedora 10y agoI'm looking for a performant way to run RISC-V code in the next year or so. Any idea how sophisticated the QEMU emualtor is? For instance, is it JITing to X86, or interpreting? Is there low hanging fruit there on the CPU performance side? On a related note, is throwing money at the FPGA vendors going to change the tradeoff, or is QEMU already winning against top-end hardware?
- pm215 10y agoQEMU always JITs to the host, regardless of target.
- rwmj 10y agoQEMU JITs the code and is very performant, much faster than any FPGAs. The two lowest hanging fruit now are: - Multithreaded TCG would let us use multiple host cores (eg allowing parallel builds). MT-TCG is a very new feature even in QEMU. - Adding virtio 1.0 support would allow us to use much more efficient block devices. qemu-user exists already and avoids both these issues, however we cannot use it for final builds because of concerns over incorrect building when the kernel isn't a RISC-V kernel. For preliminary test-building it is fine, and very fast on Intel Xeon host hardware.
- rwmj 10y agoThe FPGA based RISC-V hardware that I already have is much slower, has much less RAM and is in other ways more limited than QEMU. OTOH what's missing from QEMU is virtio support. However none of this is relevant for Fedora builders, which must be 19" rackable server hardware. This is a non-negotiable condition from the Fedora project itself, and also quite understandable because they don't want to be managing flaky dev boards. (For those interested, we solved this for armv7 initially using Calxeda hardware, and later using aarch64 hardware running in 32 bit mode).
- mynameislegion 10y agoIs there a reason you cant use cross-builds? or qemu once it has virtio?
- rwmj 10y agoCross builds aren't really a supported way to build RPMs. No other architecture supported by Fedora uses cross-compilation, so it would just be an endless stream of problems and forks. The current autobuilder is using QEMU (without virtio, but it'd be a lot easier and faster with) running on a 16 core Xeon. https://github.com/rwmjones/fedora-riscv-autobuild https://github.com/rwmjones/fedora-riscv-autobuild But for the Fedora official builders, it's 19" rackable RISC-V real server hardware, and that's the non-negotiable condition we've been given, which I support and understand. It'll be a few years, but it doesn't stop people using Fedora on RISC-V right now, they just have to grab the packages from a slightly different URL: https://fedorapeople.org/groups/risc-v/ https://fedorapeople.org/groups/risc-v/
- microcolonel 10y agoI think it might go a bit the other way around. The Government of India/IIT Madras is building their SHAKTI family RISC-V SoCs. One or two of these SoCs will be server-type hardware, and I suspect they'll want to run RHEL or similar on them once they're taped out. Of course it'll be a while before they're actually deploying them en masse. Given that it takes a while for things to get from Fedora to RHEL, starting now seems wise.