
LowRISC: Open-source RISC-V SoC - br0ke
http://www.lowrisc.org/
======
ajross
Hm... the link only talks about the CPU, but calls itself a SoC. There's a lot
more than needs to go on any chip that calls itself a "SoC", and much of it is
very poorly served by existing "open source" solutions:

    
    
        + DRAM
        + I2C
        + GPIO (with stuff like 3.3v, tristate outputs, pull up/down, etc...)
        + USB2 host/device
        + SD/MMC
    

And that's just at the very basic level. Once you get into the consumer world
you need to start talking about video output, camera input, video decode and
encode acceleration, programmable GPUs,...

Really the CPU is, in some sense, the most solved problem from the perspective
of open source. The designs themselves may be closed IP, but the instruction
sets are meticulously documented and their behavior is very standard across
many vendors and ISAs.

~~~
kwantam
The peripherals you list span a _wide_ range of complexity.

GPIO, I2C, and SD interfaces (in approximately increasing order of complexity
from my point of view) are one-person jobs for the right person. I've been in
charge of all the GPIO for complex mixed-signal chips several times in the
past, and I could crank these out in no time. But someone who's never designed
for ESD and latchup, beyond-the-rail inputs, etc., would probably find these
pretty nasty.

Forget using fab-supplied GPIO; those designs are almost always much (3-5x or
more) larger than they need to be, and in advanced nodes, they tend to add
additional processing cost. Specifically, most fabs want to stick with per-pad
snapback clamps, which are (1) big and (2) require (in processes newer than
about 0.13u; you can get away without it in earlier nodes) an additional "ESD"
layer to fix doping gradients so that the devices don't destroy themselves as
soon as they snap back. A much better solution, for many reasons, is transient
rail clamps and steering diodes. First, because diodes can handle insane
amounts of current per micron of perimeter (think: easily 50 mA / um of
perimeter for a diode, vs single digit mA / um for snapback devices), their
layouts are more compact, and they don't require ballasting to prevent current
crowding. Second, and more importantly, clamps and diodes can be simulated
(and the simulations, if not correct, are at least predictable in the way they
fail depending on the models the fab gives you). Snapback is effectively
voodoo: design what looks like it should work, test it, and hope that some
circuit you accidentally put too close to the pad doesn't change the behavior
enough to cause failures.

DRAM controllers are another step up in complexity. Depending what standard
you're going after, this is going to take some reasonable work.

USB2 is, in a word, hideous. A team starting fresh is looking at several
person-years (or more) for a well-designed physical interface, control logic,
etc.

One wonders if they can convince someone to donate designs. Come to think of
it, I'd do their GPIO/ESD/latchup design for them just for the fun of it; my
current employer certainly wouldn't object.

~~~
ajross
USB2 has a fairly sane external PHY specification though with lots of parts in
the market. I was thinking about USB in the context of the data layer, which
(to my mostly-software eyes) seems comparatively straightforward and sane.

But absent some random hackery on opencores.org, no one seems to have really
put effort into doing it on an open part in a serious way.

------
userbinator
RISC-V looks like MIPS but with some of the more dubious design decisions of
the time (e.g. branch delay slots) fixed. The mix of 16-bit and 32-bit
instruction lengths is reminiscent of ARC.

In other words, the characteristics of SoCs using this core will likely be
_very_ similar to the many out there using MIPS: cheap and simple, with
performance that's acceptable for applications like routers and other embedded
devices.

~~~
hajile
That raises an interesting point -- the original MIPS ISA hasn't been patent
encumbered in quite a while (and even then, only two non-essential
instructions were patent protected). Why should a person is this unknown ISA
instead of MIPS?

~~~
userbinator
I think it may be to avoid any political/legal issues - despite the patents
having expired, MIPS still sells ISA licenses. On the other hand, RISC-V
basically _is_ most of MIPS (but most RISC ISAs are very similar anyway).

They also avoided the patented instruction issue completely by removing all
alignment restrictions from the regular load/store; probably a good idea, with
memory bandwidths being the bottleneck now and buses growing wider - the extra
hardware is also negligible, basically a barrel shifter and logic to do an
extra bus cycle if needed.

~~~
FullyFunctional
The specification ([http://riscv.org/riscv-
spec-v2.0.pdf](http://riscv.org/riscv-spec-v2.0.pdf)) clearly states the
reasons. It has nothing to do with political/legal issues. There are very good
technical reasons for designing a new ISA.

That RISC-V resembles MIPS is a testament to what was good about the MIPS
design, however if you look closely you will find the many ways in which
RISC-V is different.

Truly, the specification is highly readable and the footnotes enjoyable.
Having implemented multiple MIPS cores and so far one RISC-V core, I'm deeply
impressed with the care that went into the design.

------
cjdrake
That hardware implementation of RISC-V listed on their website is written in
Scala (using Chisel). That's very cool. I want to see synthesis results.

~~~
_chris_
Hi, are you talking about the Sodor cores? I wrote those and wouldn't mind
answering any questions about RISC-V or Chisel.

Regarding Sodor, they're designed to be instructional (we use them on our
undergrads at Berkeley) and open for anybody with a C++ compiler so they can
learn about Chisel and RISC-V. I pushed them through synthesis once just for
kicks, but I didn't work on making them FPGA-ready. Chisel will give you the
Verilog of the core, but you'd still need to write a test-harness that's
specific to your FPGA.

The RISC-V user manual lists some of our existing RISC-V silicon
implementations (8 so far, listed in Section 19.2), whose RTL aren't (yet)
open-source.

~~~
trsohmers
Hey, I've been interested in RISC-V and Chisel, and am a bay area local (Live
in Oakland)... what is the best way to get in contact with you and others at
UCB?

~~~
_chris_
Hmmm, I actually have no idea!

Chisel has a google group that you can post any comments or questions you have
(chisel.eecs.berkeley.edu). If you wait a week, we should have something
similar up at (riscv.org) too.

Chisel has an occasional "boot-camp" where you can come and learn how to use
it, and RISC-V will have something similar too I believe in January.

------
alain94040
_Volume silicon manufacture is planned_

I highly doubt it. But if it's true, that would be the missing link for all
open source hardware design.

It would also be nice if they gave some idea of the kind of performance or
implementation they are considering.

~~~
wmf
People are making volumes of Bitcoin ASICs for surprisingly small amounts of
money, so it is possible. The question in my mind is who's going to be buying
volume quantities of this chip and why.

~~~
higherpurpose
A company like Silent Circle/Blackphone could buy a million or two in the
future. Maybe some Raspberry Pi competitors, too.

~~~
jondtaylor
One of the team members was a co founder of the Raspberry pi.

------
cottonseed
I'm not familiar with the IP issues. Would it be possible to center open-
source processor development around the ARM instruction set?

It looks like the privileged part of the RISC-V ISA is not finished yet. This
is a great project, but it seems a long way off.

~~~
makomk
I'm surprised they don't just use OpenRISC, there's already hardware shipping
that uses ASIC implementations of that internally.

~~~
mjn
They discuss their reasoning briefly in the manual [1, p. 3]:

 _We are far from the fi rst to contemplate an open ISA design suitable for
hardware implementation. We also considered other existing open ISA designs,
of which the closest to our goals was the OpenRISC architecture. We decided
against adopting the OpenRISC ISA for several technical reasons:_

 _\-- OpenRISC has condition codes and branch delay slots, which complicate
higher performance implementations._

 _\-- OpenRISC uses a fixed 32-bit encoding and 16-bit immediates, which
precludes a denser instruction encoding and limits space for later expansion
of the ISA._

 _\-- OpenRISC does not support the 2008 revision to the IEEE 754 floating-
point standard._

 _\-- The OpenRISC 64-bit design had not been completed when we began._

[1]
[http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54...](http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.html)

------
FullyFunctional
(Disclaimer: I'm developing my own RV64 FPGA implementation.)

I wish the page was a little more clear on what the intentions are, etc, but
seeing RV64 in silicon would be immensely exciting. Producing a simple in-
order machine, even with usual set of peripherals isn't very hard at all and
nor that expensive on an older process node, but there's a world of difference
if we start talking superscalar out-of-order multi-core SMP. Seeing OpenRISC
on the Advisory Board I suspect it's more the former than the latter.

------
CHY872
I've spent some time with Robert Mullins and he is an absolutely stand-up guy.
It was a pleasure to be taught by him.

