7 ms·
Ariane RISC-V CPU
- rwmj 9y agoThe lack of floating point and atomics is an "interesting" choice for a Linux-capable chip. It might run Fedora[1], but would likely require kernel support for emulating floats (as the distro is compiled assuming hard floats) and of course without atomics would only be single core. The README says they plan to add atomics. At least it supports compressed instructions. There are some actual chips about to be released without the C (compressed) extension, but Fedora and Debian are compiling everything assuming the C extension. In Fedora news, just today we've got a bootable (but very minimal) RISC-V disk image[2] that you can run in qemu. [1] https://fedoraproject.org/wiki/Architectures/RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V [2] https://fedorapeople.org/groups/risc-v/disk-images/ https://fedorapeople.org/groups/risc-v/disk-images/
- baobrien 9y agoThe SiFive chips (the microcontroller grade FE310 and closer to SoC FU540) both implement the C extension. The FE310 is RV32IMAC and the FU540 is RV64GC. Of course, you can't really hook external ram up to the FE310, and it doesn't have a TLB anyway, so no practical Linux there.
- rwmj 9y agoThe SiFive FU540 is what Fedora is targeting initially. They have actual ASICs: https://rwmj.wordpress.com/2018/02/03/sifive-unleashed-board/ https://rwmj.wordpress.com/2018/02/03/sifive-unleashed-board...
- phkahler 9y agoSo when will Fedora be doing RISC-V builds on real RISC-V hardware? That will be an interesting milestone.
- rwmj 9y agoIn about 6-8 weeks from now, when we receive the first batch of hardware.
- justinclift 9y agoAny idea which FMC standard is used on the board? Haven't found any docs/info about it so far. :( Looking at the photo's on the announcement, your blog (etc), it doesn't look like the HPC nor Vita57 pin-out versions, so guessing it's an LPC version?
- rwmj 9y agoHi Justin, long time no see. I don't know the answer. But please ask either DJ Delorie or better still the SiFive team. It's definitely only a very narrow selection of boards, and very likely $random_board you buy will not work.
- justinclift 9y agoThank Rich. Good point, will do. :)
- justinclift 9y agoFollowing up on this. I emailed the info@sifive.com address, but haven't received any kind of response. In the mean time, this forum answer of a similar question answers the FMC port type: https://forums.sifive.com/t/questions-about-hifive-unleashed/1010 https://forums.sifive.com/t/questions-about-hifive-unleashed... > HiFive Unleashed is an FMC mezzanine card with a male High Pin Count FMC connector
- baobrien 9y agoLike rwmj says, ask somebody at SiFive -- but if I had to guess, I'd say it only breaks out some low speed IO/GPIO lines and a few chiplink lanes. That is to say if you want anything high speed, you're going to have to go through an FPGA board.
- eeZah7Ux 9y agoDebian already supports ARM with and without hard float. Supporting a soft-float RISC is not different.
- rwmj 9y agoThat's a proof that something is possible. Actually doing it is a huge amount of work. ARM and RISC-V both have different ABIs for hard/soft float and once you support multiple ABIs you end up compiling everything twice and multiarching everything. Also that's ARMv7 (32 bit). This is a 64 bit chip and I'm not aware of any ARM 64 bit chip that lacks an FPU. In any case I was thinking about kernel or M-layer emulation of floats which is different, requires a bunch of code to be written once, but doesn't require software gymnastics from the distro.
- deleted 9y ago[deleted]
- nickik 9y agoThis is not the first time the PULP project has released a chip without a FPU. In the other case they have latter added a version with one. The atomics they seem to want to support but arn't quite done.
- cturner 9y agoNot to disagree with you, you highlighted intended use for linux. It touches on something i have wondered about. How far you could get in creating a general purpose computing platform with no floating point support at all, including no soft float. If you could avoid float, you could save on implementation costs, and round out a source of bugs downstream. Are there traditions that takes this path?
- rwmj 9y agoSome applications use different/narrower definitions of float. For example GPUs have 16 bit floats and TPUs (ie. AI co-processors) also use narrower floats which are specialized for neural networks. But for a general purpose application/server chip firstly the FPU doesn't really take up much space and secondly if you ship without an FPU then you can never enter certain important markets (eg. HPC).
- amelius 9y agoNote that you can also code the floating point instructions in microcode (a kind of firmware of the CPU).
- deleted 9y ago[deleted]
- amelius 9y agoNot sure why downvoted, but this basically allows you to redefine (within limits) the behavior of opcodes after you have shipped the CPU. I thought that was relevant. https://en.m.wikipedia.org/wiki/Microcode https://en.m.wikipedia.org/wiki/Microcode
- _chris_ 9y agoAnd RISC-V has a "machine mode" which the OS doesn't know about, which is effectively a place to do microcode.
- madez 9y agoThat is a very interesting question. Sometimes a solution to a problem using IEEE-754-arithmetic can be rewritten to use integer arithmetic. Now, what are the problems where IEEE-754-arithmetic is used now, and in what cases it cannot be rewritten? I wouldn't be surprised if music decoding could be done without IEEE-754-arithmetic. Maybe, a specialized codec would have to be used, but I still consider that doable.
- azernik 9y agoLack of floating point is not so out there - I've worked on several embedded Linux systems that shipped without hardware floating point support, and they didn't suffer much for it. Userspace code got to use floating point with software emulation, and kernel code avoids floating point (especially in contexts where interrupts are blocked) for precisely this use case. On atomics, see this section of the readme: > While developing Ariane it has become evident that, in order to support Linux, the atomic extension is going to be mandatory. While the core is currently booting Linux by emulating Atomics in BBL (in a single core environment this is trivially met by disabling interrupts) this is not the behavior which is intended. For that reason we are going to fully support all atomic extensions in the very near future.
- mtgx 9y agoAll RISC-V CPUs seem to be in-order right now, but I assume their ISA supports speculative execution for out-of-order CPUs. So are they going to redesign that part of the ISA in a future update, before companies start coming out with out-of-order RISC-V CPUs with speculative execution? I assume some of them were already mid-design of their out-of-order chips, so this could delay their launches quite a bit. But it would be for the best long-term.
- huntie 9y agoNot sure if they've done a production run, but BOOM[1] has existed for a while. I'm not sure if it supporst speculative execution yet. [1] https://github.com/ucb-bar/riscv-boom https://github.com/ucb-bar/riscv-boom
- _chris_ 9y agoIt's been taped out as a research chip, but no production runs. Naturally, like any OOO-issue processor, it supports speculative issuance of load operations to the memory system (or it wouldn't be worth the effort of OOO-issue).
- rwmj 9y agoWhat needs to be redesigned? All OOO cores should behave as if they are executing in order when viewed by the programmer.
- poizan42 9y agoI assume the parent is referring to Spectre.
- nickik 9y agoSeems very unlikely that ISAs will have to change, the problem needs to be fixed in micro Architecture. Its unlikely that there are many mass production RISC-V CPU currently in design. A couple are known but they are more advanced research projects. The BOOM core will be used by Esperanto and I'm sure they will evaluate what to do about the security issues. The guy who made BOOM written about this problems, check on Twitter.
- nickik 9y agoThis effort is part of the PULP Platform [1]. They have a number of cool chips and projects. Its a pretty large effort and they are releasing more and more of their work into open source. Here [2] you can see what they have already released and their plans going foreward. Project like LowRisc Open-SoC [3] using some of the smaller PULP cores as minion chips for things like IO offloading, security and so on. They can also reuse a lot of the work done for PULP. [1] https://www.pulp-platform.org/ https://www.pulp-platform.org/ [2] https://www.pulp-platform.org/release-plan/ https://www.pulp-platform.org/release-plan/ [3] http://www.lowrisc.org/ http://www.lowrisc.org/
- oneplane 9y agoThis this also allow for compiling into something QEMU can use? Or does it not need anything like this to emulate RISC-V.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- bogomipz 9y agoFrom the Readme: "While developing Ariane it has become evident that, in order to support Linux, the atomic extension is going to be mandatory. While the core is currently booting Linux by emulating Atomics in BBL (in a single core environment this is trivially met by disabling interrupts) this is not the behavior which is intended. For that reason we are going to fully support all atomic extensions in the very near future." Is the atomic extension mentioned here something like the LOCK prefix in x86, i.e it just lock the bus for the instructions that follow? I'm guessing this is non-trivial to implement?
- _chris_ 9y agoLoad-reserve, store-conditional, and atomic memory operations (e.g., AMO-ADD).
- bogomipz 9y agoThanks, I had to look up the AMOADD instruction. For anyone else who's interested, this is nice RISC-V reference card: https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/RISCVGreenCardv8-20151013.pdf https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/...
- pooya13 9y agoHey guys. What is your favourite resource for learning how to implement a complete RISC-V processor? I have taken a course in computer architecture so I have an idea about the theory but I really want to try and actually implement and simulate one from scratch and maybe even synthesize it if the FPGA board is less than 200$.
- _chris_ 9y agoI learned from MIT's 6.004. They provide infrastructure for you to build a simple core from gates for a RISC ISA in their own test environment. Their materials should be online (or available via OCW).(E.g., https://www.youtube.com/watch?v=CvfifZsmpQ4 https://www.youtube.com/watch?v=CvfifZsmpQ4). Once you understand how to build a core, frankly the more daunting part is how to interface with the core. How do you load a program into its memory? How do you see what it is doing? How do you know if it finished running or if it crashed? You may find luck following along with FPGA tutorials (maybe take a look at the Pynq board?) that teach you how to implement a design, put it on the board, and talk to it. Once you understand how to use your FPGA and how to interface with your designs, changing the design to a simple RISC-V core will be more tractable. You could try and check out picorv32 or riscv-sodor to see two examples of "simple" RISC-V cores that you can build, simulate on your computer, and watch them execute programs you wrote. But man the "magic" behind the test harnesses can be super opaque.