
Ariane RISC-V CPU - nickik
https://github.com/pulp-platform/ariane
======
nickik
This 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/)

------
rwmj
The 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/)

~~~
cturner
Not 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?

~~~
amelius
Note that you can also code the floating point instructions in microcode (a
kind of firmware of the CPU).

~~~
amelius
Not 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_
And RISC-V has a "machine mode" which the OS doesn't know about, which is
effectively a place to do microcode.

------
bogomipz
From 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_
Load-reserve, store-conditional, and atomic memory operations (e.g., AMO-ADD).

~~~
bogomipz
Thanks, 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/...](https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/RISCVGreenCardv8-20151013.pdf)

------
pooya13
Hey 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_
I 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.

------
mtgx
All 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.

~~~
nickik
Seems 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.

~~~
_chris_
Spectre can be completely mitigated, it's just another headache to deal with.
=(

Essentially, you just have to buffer up more stuff and clear the misspeculated
entries so nothing is left lying around that could leak information. Comes
with a cost, but chip companies don't have to give up on OOO/speculation
entirely.

~~~
CodesInChaos
Sounds tricky. For example if your CPU has hyperthreading, cache misses in
speculative execution could leak to the other thread running on the same core,
because they share computational resources and the utilization of those is
affected by cache misses in speculative execution.

~~~
_chris_
You tag things and prevent bypassing uncommitted data from one thread to
another.

For example, it's a mistake (that's been made by other ISAs!) to allow two
hardware threads to bypass store data out of the uncommitted StoreQueue from
one thread to another. Your memory consistency model violates single-copy
atomicity and now the programmer's life is much harder.

~~~
CodesInChaos
I'm talking about the shared computation resources (e.g. ALU), not about
shared caches. Cache hits and cache misses affect how much and when one thread
utilizes the ALU, which means the other thread sharing it won't be able to use
the same resources for computation. Since speculative execution also uses
these shared resources, it leaks information about its cache misses to the
other thread, even if a rolled-back speculative execution doesn't modify any
caches.

------
oneplane
This this also allow for compiling into something QEMU can use? Or does it not
need anything like this to emulate RISC-V.

