
Open source RISC-V implemented from scratch in one night - guigg
https://github.com/darklife/darkriscv
======
earenndil
This is good news for risc-v! The fact that it can be implemented so easily by
hobbyists furthers the cause of trusted hardware. Sure, it won't be
implementable by hobbyists at the speeds necessary for modern desktop
computing, but a trusted security core (something like a yubikey) could be
implemented on completely from-scratch hardware, but then still use existing
trusted/vetted software (openssl), just a cross-compile away.

~~~
inetknght
"Modern" desktop computing is perhaps less resource hungry than you think when
you cut away so much graft of telemetry.

None or barely few games, of course. But word processing, email, and pure HTML
browsing without javascript? Maybe not HTML5's fancy features, but general
rich text?

I think it's very achievable.

~~~
simias
My software "stack" hasn't changed in maybe 15 years now. It's emacs + firefox
+ terminal and a couple utilities here and there. It ran fine on my first
computer with a single core ~1GHz CPU and 128MB of RAM (although multi-core
architectures and more RAM did make it a lot easier to multi-task later). The
only reason I upgrade my computer these days is to run modern games, for
everything else except compilation I could probably use a computer from 10
years ago and not feel the difference.

I'd gladly switch to a completely open source hardware architecture even if it
meant losing a significant amount of raw performance provided that the
hardware and OS are stable and it's not prohibitively expensive.

~~~
kilburn
I don't know what "prohibitvely expensive" is in your case, but there's a
possibility today:

Grab one HiFive Unleashed for $999 [1]:

\- 4 cores up to 1.5Ghz

\- 8Gb DDR4 ECC Ram

\- 1Gbps ethernet

Then grab one HiFive Unleashed Expansion Board for $1,999 [2]:

\- SSD M.2 Connector

\- SATA3 Connector

\- x16 PCIE Connector (4 lanes of pcie2)

\- A bunch of other cool stuff you wouldn't probably use (SPI, FPGA, etc.)

Finally grab some M.2 Drive and a graphics card ($500 maybe?).

This would set you back a grand total of $3500, which is definitely way more
expensive than the current mainstream but may fit within "non-prohibitively
expensive" for some. The whole platform should be open source [3].

[1] [https://www.crowdsupply.com/sifive/hifive-
unleashed](https://www.crowdsupply.com/sifive/hifive-unleashed) [2]
[https://www.crowdsupply.com/microsemi/hifive-unleashed-
expan...](https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-
board) [3] [https://www.sifive.com/products/hifive-
unleashed/](https://www.sifive.com/products/hifive-unleashed/)

~~~
dtx1
While the hifive is an awesome proof of concept 3,5 k$ for essentially
something performing roughly as well as a raspberry pi seems prohibitively
expensive for now.

~~~
acct1771
Seems worth it.

My issue would be paying all that, and then strapping closed source hardware
to it.

------
akuma73
Sorry to burst any bubbles here, but this is s very incomplete implementation.

You couldn’t run anything but small toy programs on this machine. This is more
like what a student would build in an undergraduate course in computer
architecture.

For example, there is no MMU, no debug support, no traps, no interrupts, no
exception handling, no OS privledge levels, no FP, no memory controller etc.

Of course, one wouldn’t implement all of these in a few hours.

The fact that this is RISCV is somewhat of a red herring as you could do a
similar thing with a restricted subset of MIPS or ARM or even x86 as they do
in UT Austin’s comp arch class.

~~~
samsoniuk
I fully agree with you about the missing features! However, as long my
objective is replace some legacy 680x0/683xx/coldfire processors running small
toy programs, I see no need for that complex features. Please keep in mind
that although 25% of RV32I instruction set is missing in my implementation,
there is no side effect, since that instructions are not relevant for this
specific environment (fencex, exxx and csrxxx), since the gcc generates by
default exactly the implemented subset and nothing more. I think this is a
very important advantage in the RISCV architecture when compared with others
and I dont think the gcc will have the same benevolent behaviour in the case
of ARM or x86. Maybe for MIPS is possible, but I am not sure about it. Anyway,
why not use RISC-V? :)

~~~
jonjacky
Yes. Part of the motivation for RISC-V was to enable designers to do one-off
experiments like this or small production runs with custom ISAs based on
RISC-V, without having to worry about licenses or intellectual property
issues. RISC-V even leaves some op codes uncommitted so designers can add
their own custom instructions. Dave Patterson (RISC-V designer and Turing
award winner) explained this at a talk I attended a few years ago.

------
eight_ender
I love reading about stuff like this. There's something magical about having
an inspiration fire so hot you can't put it out without 6 hours of hard coding
at an ungodly hour.

------
exikyut
I wonder how easy it would be to port
[https://github.com/xoreaxeaxeax/sandsifter](https://github.com/xoreaxeaxeax/sandsifter)
to the RISC-V instruction set.

Would probably be a decent step in the right direction for
validating/verifying the future of trusted computing.

Although... this gives rise to a 2nd thought. If it was _this easy_ to build a
RISC-V implementation, is it all that special, technically speaking? I ask as
someone naive about processor design. Is implementation relatively
straightforward, but design hard?

~~~
leibwiht
My understanding of sandsifter is that it works by executing an instruction
next to a page boundary, which gives either a page fault error (the
instruction executed correctly and then execution passed over to the next page
which is presumably non-executable) or an error indicating the instruction was
malformed. So, for it to work on RISC-V you need paging, and also interrupt
vectors to work. The MMU was only recently standardized so I'm not sure if
it's actually implemented in any hardware or software yet, but once you have
those two things it should be fairly straightforward.

~~~
_chris_
Sandsifter is dealing with the problem of "how do I find valid instructions in
any 1-15 byte sequence, which yields 2^120 combinations?"

In RISC-V there are currently only 2 byte and 4 byte instructions, which you
can brute force your way through. The specification does technically allow for
longer sequences, in which case sandsifter will work just fine. [And the
RISC-v privileged specification has existed for years].

~~~
leibwiht
>And the RISC-v privileged specification has existed for years

It is a draft which has not been finalized and contains a disclaimer that it
might be modified in a non-backwards compatible way prior to final release.

------
kbumsik
I don't know anything about RISC-V ISA yet, but I am wondering if its ISR is
great for learning computer architecture in shcools compared to MIPS, the
dominant ISR at colleges for introductory computer architecture classes?

The HDL (Verilog) code looks quite short and simple. If the partial
implementation of the ISR implementation is like that it shouldn't be so bad
for learning...

~~~
xmo
Yes. Berkeley started using it to teach introductory computer architecture:
[http://www-inst.eecs.berkeley.edu/~cs61c/sp18/](http://www-
inst.eecs.berkeley.edu/~cs61c/sp18/)

A major project of the course is to build RISVC emulator and implement 2-stage
pipeline in logisim.

~~~
henrikeh
The technical university of Denmark also transistioned to teaching computer
arch using RISC-V. Some of the most popular textbooks are also being converted
to RISC-V editions.

------
lisk1
As the possibilities for smaller transistor get narrower companies will get
more open towards smaller clients with small budgets, so taping out homebrew
CPUs or SOCs or integrated circuits will be possible.

~~~
trumped
so far, the opposite is happening in the "cellphone"/pocket pc space... it is
getting hard to get a phone that you can root without having to resort to
"holes" that can get patched at any time...

~~~
yipbub
Can you elaborate please?

~~~
trumped
Well, most people aren't going to make their own chips any time soon... so you
have to buy what is available and cellphones are getting more
restricted/locked down everyday in the name of security (they are getting
closer to what they used to be before Android came out)... not sure if that
answers your question though.

------
bem94
Whoa. This is very impressive!

It does seem to hilight an increasing unease I have with riscv.
Implementations are many and cheap, but reusable verification is rare and
people don't use what is out there. They have maybe the riscv-tests set
working. But that's not enough to call your new CPU usable for anything other
than a hobby project.

Fwiw, the riscv-formal package from Clifford wolf is the closest thing to a
turn key solution to verifying a riscv core, even if people must remember it
doesn't cover everything.

~~~
samsoniuk
hmmm... I promise investigate this topic in the future!

------
deeesa1
Impressive, I like this! I'm curious more in general how widely risc-v is
being used in the industry today already (they mentioned a steep adoption from
academia to industry). Looking at the foundation members, there are quite a
big number; given they range for risc-v is from small devices to super
computers, are there any examples where it's used today and showed benefits
over other archs?

~~~
rwmj
There'll be a few RV32 (RISC-V 32 bit) cores in every WD hard drive starting
next year.

------
adiusmus
Could be fun in near future. Plenty of room for improvement so it’s a good
base for exploration of Fpgas.

And with this [https://bellard.org/riscvemu/](https://bellard.org/riscvemu/)
and similar projects already spun up in other ways, risc-v is becoming more
interesting as time goes by.

------
wyldfire
> and the best feature: BSD license

IIRC this isn't the first open source RISC-V core but it's great to see
another implementation.

~~~
samsoniuk
It is not even the first RISC-V with BSD license, but I love make some GPL
friends cry! ;D

------
amelius
> works up to 75MHz

How much would this increase if it used an ASIC instead of FPGA? And how much
would it cost for different batch-sizes?

~~~
wyldfire
IIUC it's critically dependent on the manufacturing process used.

> how much would it cost

A CPU IC isn't very interesting until it has some I/O, so it's much more
meaningful to talk about an SoC with one or more of these darkriscv cores.

Sorry, I don't have an answer other than to say "this isn't quite complete
enough for it to be useful for most tasks." That said, there's probably tons
of open source implementations of DDR/SPI/PCI/USB interfaces (on
opencores.org, e.g.). So it's "only" a matter of integrating these.

~~~
abfan1127
fastest speeds depend on two things. First the manufacturing technology used
(smaller is faster because parasitic capacitance is smaller, although finfet
is getting to have large parasitic resistance). The 2nd factor is the datapath
between flip flops. Some architectures handle very fast clock rates because
the data path is simple (or pipelined). Others are quite slow. I've seen some
architectures top out at 500MHz when another architecture is running over 1
GHZ in the same chip.

------
samsoniuk
wow! I didn't expect to get so many comments and questions about my weird
project! thank you all! :)

------
sergioisidoro
/rant

"after one week of exciting sleepless nights of work (which explains the lots
of typos you will found ahead), the darkriscv reached a very good quality
result"

Not commenting on the actual quality of the code, but I wonder how can one
make typos due to sleep deprivation, and yet produce "good quality results" in
software.

I wonder when will we, as a community, stop praising all nighters and rushed
work.

~~~
tomhoward
There's a big difference between doing short bursts of work with little sleep
- particularly when you're young - vs doing it constantly for months/years.

In this case it just seems to indicate enthusiasm for the project rather than
dangerous overwork.

~~~
samsoniuk
in fact: 50% enthusiasm for the project, 50% dangerous overwork! hehehe

------
mtgx
I wish open source projects would stop being hosted on the Microsoft-owned
GitHub.

~~~
Annatar
If wishes were horses, beggars would ride.

------
Annatar
"The main motivation for the darkriscv is create a migration path for some
projects around the 680x0/coldfire family."

On the Amiga we don't need a replacement for MC680## processors because we
have the Vampire 2+ accelerator, which gives us a superscalar, 64-bit MC68080
with AMMX extensions.

Coming to ATARI ST and Amiga 1200 near you if the Apollo team keeps this
momentum.

~~~
samsoniuk
Yeah, I know about it! But unfortunately the 68080 is too large for my FPGA
applications, which are cost driven. Other open source 680x0 projects does not
work too, by the same reason. For some years, I wondering how create a compact
implementation of the 680x0 in the FPGA, but with no success. At some moment I
started work in a subset of the 680x0, something like a RISC version of 68000,
with a minimal instruction set and a very optimized pipeline, but in this case
the problem moved to the toolchain and make the gcc work well is not so
easy... Defeated by all that problems and limitations, I started test lots of
new architectures and found the RISC-V.

~~~
Annatar
What about OpenSPARC, since it has low power consumption and can be cut down
to less cores and threads?

~~~
samsoniuk
The available implementation of the OpenSPARC is too complex: a single core
with 4 threads requires 59350 LUTs and runs at 62.5MHz in a Virtex FPGA
(according to [1], slide 21). Although is possible remove some features, I
don't think is possible reduce the logic without impact the compatibility. I
think the Leon3 [2] is a far better option for FPGAs, since requires only
around 3500 LUTs and runs at 125MHz in a Virtex FPGA. In a low-cost FPGA, the
performance of Leon3 is around 66MHz, which is enough to replace the 680x0 and
coldfire v2 processors. The requirement for 3500LUTs is not so bad, as long
the TG68 (an open source 68000 replacement in VHDL) has similar requirements.
However, the typical RISC-V implementation uses less than 1/3 of the logic
when compared with Leon3 and TG68. Also, although the RISC-V provides almost
the same performance as the Leon3, the extra logic can be used for more
parallel RISC-V cores, resulting in a increase of 2 or 3x in the total
performance. Finally, there is an additional problem with OpenSPARC, Leon3 and
TG68: the GPL license. In another hand, most RISC-V implementations use the
BSD license, as long the RISC-V instruction set itself uses the BSD license.
Of course, the OpenSPARC, Leon3 and TG68 are implemented that way. There is no
obstacle, other than the technical complexity, to prevent develop a new
OpenSPARC, Leon3 or TG68 from scratch, with a more firendly license, better
performance or better use of the logic. In this case, the question is: how
many time you need to implement a minimal viable core with one of that
architectures? In the case of RISC-V is perfectly possible implement a small
core in a FPGA with the RV32I instruction set in few hours, because the RV32I
set of instructions is really very poor and primitive, which make it specially
friendly to the hardware and explain why is so compact.

[1]
[http://ramp.eecs.berkeley.edu/Publications/OpenSPARC%20T1%20...](http://ramp.eecs.berkeley.edu/Publications/OpenSPARC%20T1%20on%20Xilinx%20FPGAs%20-%20Updates%20\(Slides,%208-20-2008\).pdf)
[2]
[http://ramp.eecs.berkeley.edu/Publications/LEON3%20SPARC%20P...](http://ramp.eecs.berkeley.edu/Publications/LEON3%20SPARC%20Processor,%20The%20Past%20Present%20and%20Future.pdf)

------
josemanuel
Writing RTL takes one night but, how long will the verification take? How much
will it take to tapeout? Who will pay for it?

~~~
PhilWright
Your only comments on HN seem to be to criticize RISC-V.

The posters intention is not to start producing hardware, at no point does his
project mention taping it out and manufacturing. Obviously it is just a fun
side project to implement the RISC-V core ISA in an FGA. It was then made
open-source on GitHub so anyone else interested can look at it. Chill out
mate.

