
Ariane RISC-V CPU – An open source CPU capable of booting Linux - grlass
https://github.com/openhwgroup/cva6
======
ansible
So I've had the itch to get a 64-bit RISC-V board of some sort. For reasons I
won't get into, I'm not so interested in the 32-bit version.

The prices for the Genesys 2 Kintex-7 are $1000 USD at Digikey, which is way
too much to spend on a hobby. I suppose I could try to port the FPGA code to a
cheaper platform, but I'm no expert on that sort of development.

Arguably, I'm not an expert on operating systems development either...

On the other end of the spectrum, There is this Canaan Kendryte K210 chip,
which is a dual-core 64-bit RISC-V SoC, but only has 8MiBytes of on-chip SRAM,
with no provision for SDRAM. An RTOS is of course the straight-forward choice
for that, though people are apparently able to run a very slim Linux kernel on
it as well. You can get various boards from Seeed Studio for $30 USD or less.

Is there something else that is a reasonable price? Less than $100 USD? Yes, I
know, qemu is free.

~~~
rjsw
There are pre-built images for cheaper FPGA boards. There is one for the
Parallella system.

A limiting factor on most FPGA dev boards is the amount of RAM if you want to
do any software development on the resulting RISC-V SoC.

------
j-pb
I love that the controller symbol is a toilet, because on a miss-predict it
does a "flush".

------
DC-3
Could someone break down the significance of this for those of us who are less
hardware-acquainted? Does this represent the cutting edge of RISC-V CPU
design? And how difficult would it to implement this design properly instead
of simply emulating it with an FPGA?

~~~
newhouseb
Emulation to me implies simulation, which isn't what an FPGA does.

A configured FPGA and an ASIC are both real electric circuits. In an FPGA the
building blocks are larger groups of transistors (typically forming "Look Up
Tables") that are connected together by a network of a bajillion electronic
switches (read: other transistors). In an ASIC the building block is generally
a transistor (although technically any structure you can "tape-out" with
lithography) and everything is wired up directly.

Porting this to an ASIC is more gated by access to proprietary tooling than
anything else. There's a number of open source efforts to replicate this
tooling on older process nodes (search for SkyWater PDK and OpenROAD).

As for how significant this particular RISC-V chip is, there are a bunch of
open source RISC-V chips cropping up. This one does seem to have more
extensions implemented than the typical RISC-V chip, which is notable.
Personally I'm more interested in RISC-V CPUs written in newer tooling (i.e.
nMigen or Chisel) rather than Verilog as I find Verilog a trusty but a bit
archaic (similar to how C is seen these days).

~~~
monocasa
Emulation just means running it on hardware it wasn't intended. That runs the
spectrum between ISA emulators like Dolphin, software RTL simulators like
verilator, and FPGAs can certainly be used for emulation if the design wasn't
really intended for them as the real end goal.

There's also an interesting point in that spectrum of the cadence/synopsys
hardware emulators. They run in a rack sized device composed of a bunch of
FPGAs and arrays of custom ascetic processor cores that can only do logic and
branch ops to run HDL for SoC sized designs at ~1-10MHz.

~~~
guepe
I know ZeBu very well and... "a bunch of FPGAs" is an understatement. It can
go all the way to 1500 FPGAs !

------
ncmncm
RISC-V could be a pretty good ISA, if only it came with a popcount
instruction. Given popcount, it is easy to compose a whole range of other
essential operations with just one or two more instructions. Without, you are
stuck running two dozen instructions just to get to the first step.

Is the RISC-V evolutionary process capable of processing small-sized,
incremental improvements? Or are only big "extension" instruction families
even possible?

~~~
Symmetry
The B extension is going to add that.

[https://github.com/riscv/riscv-bitmanip](https://github.com/riscv/riscv-
bitmanip)

Also conditional move which you really need for a lot of reasons but
especially to avoid timing attacks in cryptography.

~~~
ncmncm
The B extension spec seems to be stagnating. It will anyway be optional and
probably rarely implemented even if ever finished. If we have to wait on B, it
probably means not getting popcount.

Conditional move would be there implicitly if they had defined boolean "true"
to be ~0 in the ABI: just AND. Instead they made it 1, so you have to negate
it before you can use it for anything. This has been well understood in SIMD
circles for decades; it is a mystery how they could have missed it.

I am ready for a RISC-VI, RISC-W, or RISD-V "fixed version".

~~~
nickik
B extension was making good progress after it had slowed down for a while.
Seems like standardization has slowed because of COVID.

The argument that it will never be implemented seems kind of wrong, why not?
Multiple vendors and open source extensions already implemented the essential
functionality in non standard ways. In the next standard profile for Linux,
the V and B extensions will very likely be included.

ISA standardization never happens as fast as you hope it does.

~~~
ncmncm
Popcount is important even in minimal implementations, including "embedded".
Waiting for B is not a way to get popcount where it is needed. We need another
track.

------
Symmetry
Cool. No register renaming but scoreboared issue means it's still weakly out
of order. It seems to be grabbing the instruction stream in 32 bit chunks but
I wonder if it can decode two compressed instructions in a single clock cycle?

~~~
fwsgonzo
I doubt it because they can cross page-borders which is a seriously annoying
"feature" in the compressed extension. Also 32-bit instructions can cross the
page border too!

~~~
Symmetry
The 32-bit instruction sets I'm familiar with all tend to enforce alignment
which means page boundaries aren't a problem. Also, you get 2 extra bits of
jump distance for free by not having to specify the exact byte you're jumping
too but only the 32 bit word.

~~~
fwsgonzo
If you disable the compressed extension then you do get enforced alignment.
So, for example RV32I, RV64I both 32-bit alignment. I just ran a small linux
program I had for RV32GC and I found 2 places where an instruction crossed a
page border. I don't understand why they thought that was a good idea, and for
such a modern architecture too, but I guess on hardware it's fine?

~~~
monocasa
Well, there's a few places were it makes sense and doesn't. And it being an
optional extension means that it pretty much exists where it's benefits
outweigh it's costs.

The really tiny cores with RV-C don't even have page tables, so there's no
straddling to worry about. There it's very cheap, and has a lot of benefit, so
you see it in the same target (and same reasons) as CortexM cores being Thumb2
based.

One level of complexity up, a simple embedded core with a full MMU (taking the
place of what'd be a classic 5 stage RISC like in a home router or something)
is the least likely to want it, but in those cases you're normally doing
buildroot like software anyway, so it's not a big deal that you have to
compile everything with rv32g instead of rv32gc.

Larger more powerful cores have the gate count necessary to paper over the
complexity of straddling page boundaries. And that's why you see the binary
distros pretty much requiring RV-C. The increased gate count there is worth
the better utilization of the I$.

------
Koshkin
What’s so attractive in RISC-V compared to, say, ARM or MIPS? Is it just the
license?

~~~
monocasa
It's cleaner than ARM or MIPS. AArch32 has something like 1200 instructions
these days and a ton of cruft in there. AArch64 has good but not great
instruction density, having nothing like ARM Thumb or RV-C.

MIPS (or at least what most people mean when they say MIPS) has all sorts of
gross stuff like branch delay slots that are a pain in any non 5 stage in
order design.

------
searedsteak
Looks like it just shares a name with the spacecraft but isn't related?

~~~
Ndymium
I can't help but think of Ariane V and its famous launch failure due to a
programming error. I hope Ariane RISC-V fares better. ;) (Ok, the rocket
platform has been reliable since 2003, but that ruins the joke.)

~~~
MaxBarraclough
Was going to say the same. I learnt of the Ariane 5 explosion in a class on
critical-systems software development. The out-of-range error that cost
$0.5bn.

A summary of the failure: [https://www-
users.math.umn.edu/~arnold/disasters/ariane.html](https://www-
users.math.umn.edu/~arnold/disasters/ariane.html)

~~~
ncmncm
It wasn't even the out-of-range value that caused the failure--that would have
been fine. The failure was caused by trapping the error, and dumping debug
data onto the realtime control bus.

