
LowRISC – An open-source, Linux-capable System-on-a-Chip - hkt
http://www.lowrisc.org/
======
asb
I'm one of the founders of lowRISC, a not-for-profit effort to produce a
completely open source, Linux capable, multi-core SoC. Fundamentally, we
believe that the benefits of open source we enjoy in the software world can be
applied to the hardware world will have a huge positive effect on the hardware
industry, academia, and wider society. Much like with Raspberry Pi, our
approach is to lead by _doing_ which is why we're working to create our own
SoC platform and low-cost development boards.

I should point out the title has been editorialised slightly inaccurately. Rob
Mullins is a fellow co-founder of lowRISC and was also a Raspberry Pi founder,
and I took a leading role in Raspberry Pi software work for a number of years,
but it's not really accurate to say lowRISC is backed by "the makers of
Raspberry Pi".

If you have any questions, I'll do my best to answer (I'm on a short holiday
right now, so have slightly intermittent internet access).

~~~
lgeek
> we believe that the benefits of open source we enjoy in the software world
> can be applied to the hardware world

In my opinion open source hardware IP has at least two major limitations
compared to software, which make it significantly less useful or important to
end users. I guess your preference for open source rather than copyleft
already hinted that the benefits are mostly for the ecosystem rather than the
users. The first one is that even though you can modify the design, you have
no practical way of using your modified design (at least in this context,
because FPGAs are slow and expensive and high performance SoCs don't fit
anyway).

The second limitation is that it is impractical to audit the hardware to
determine whether you have actually received the unmodified open source
design. For software this can be achieved using reproducible builds or just by
compiling it for yourself.

Open source hardware boards (as opposed to IP) have some of these limitations
as well, however both can be overcome by a hobbyist with a modest budget.

~~~
cryptarch
> The second limitation is that it is impractical to audit the hardware to
> determine whether you have actually received the unmodified open source
> design. For software this can be achieved using reproducible builds or just
> by compiling it for yourself.

Mostly too expensive AFAIK. I'm fuzzy on the details, but it should be
possible to create high-resolution (e.g. X-ray) scans of the chips (as is done
by chip design pirates) and compare them to known-good implementations, or
images generated based off the chip's open-source design.

I'm looking forward to a future where PC auditing shops are a thing. Take in
your machine, and let them verify the contents of every chip and storage unit
on your device.

~~~
jl6
Is there really an imaging technology that is high enough resolution to
capture the detail of a modern CPU?

And if so, would that be sufficient for an audit? Aren't CPUs dependent not
just on the layout of circuits but also on the material properties of the
components, which might not be apparent just from images?

~~~
pjc50
Worse, there isn't currently any _nondestructive_ chip imaging technology!

~~~
halomru
That just increases the verification costs: order ten chips, verify five
randomly chosen ones. If all five are clean, the other five are probably also
clean. Modify numbers for the desired cost/risk trade-off.

------
cryptarch
I'll take a fully open-source computing device with Core2Duo-like performance
any day, especially if the CPU is open source too. I'm just hoping it won't
have any firmware blobs.

Would this being built on RISC-V help with getting a formal CPU spec?

~~~
asb
RISC-V is an open specification that can be implemented by proprietary and
open source efforts alike. This means there's nothing stopping someone else
doing a RISC-V SoC that, like most current commercial cores, has documentation
"protected" by an NDA and inaccessible to most users.

As a fully open source effort, we of course want every aspect of the chip to
be fully documented and auditable. It's useful to have something like a
dedicated core to handle initial boot, but it's not useful to keep that core
completely undocumented (e.g. the Intel Management Engine). Our answer there
is what we term 'minion cores' ([http://www.lowrisc.org/downloads/lowRISC-
memo-2014-001.pdf](http://www.lowrisc.org/downloads/lowRISC-
memo-2014-001.pdf)), microcontroller-class cores to handle these sort of
tasks. These are fully documented, open source, and implement the RISC-V ISA.

As for formal specifications, there has been some work on specifying the
RISC-V ISA using L3 [https://github.com/SRI-
CSL/l3riscv](https://github.com/SRI-CSL/l3riscv). MIT have been working on a
specifying using their 'Kami' tool as well.

~~~
jeena
> someone else doing a RISC-V SoC that, ... , has documentation "protected" by
> an NDA and inaccessible to most users.

This is, as far as I understand, at least in software, the main difference
between Free- and Open Source-software.

I wonder if there is some movement like the Free Software movement but Free
Hardware instead.

~~~
asb
Take a look at [http://fossi-foundation.org/](http://fossi-foundation.org/).
Whatever terminology you're using, I think it's right to say lowRISC and FOSSi
have a shared vision for free and open source designs that respect user
freedom.

------
BuuQu9hu
An interesting talk from the RISC-V folks:

[https://youtu.be/QTYiH1Y5UV0](https://youtu.be/QTYiH1Y5UV0)

------
Lio
It would be interesting to get RMS' thoughts on this project.

Finally the prospect of fully Free mainstream computers looks like it's
becoming a reality.

~~~
asb
I hope we'll be 'Respect Your Freedom' compliant
[https://www.fsf.org/resources/hw/endorsement/respects-
your-f...](https://www.fsf.org/resources/hw/endorsement/respects-your-
freedom). This is of course trivial for our core SoC, where we have no
intention of relying on binary blobs. It just may affect our selection of
external parts, e.g. WiFi chips.

I often relate the way we're going about this to the early days of the GNU
project. Our ultimate aim is an SoC where all of the RTL for every component
is open source, though it may be that just like GNU which iteratively replaced
proprietary components of Unix we may need to have some intermediate stepping
stones. e.g. an SoC with a proprietary USB controller, until an appropriate
open replacement can be written and verified.

~~~
kamd
The LowRISC FAQ says that the project will use a permissive open-source
licence. Why are you choosing that over the GNU-style copyleft approach?

~~~
asb
I've tried to answer that question here
[https://news.ycombinator.com/item?id=13130195](https://news.ycombinator.com/item?id=13130195)

------
Zekio
I can't wait for these System on a Chips to be used on a Single Board
Computer, which is priced around the same as a Raspberry Pi

~~~
asb
We are working towards producing a lowRISC SoC design along with low-cost
development boards. I will say that hitting the Raspberry Pi pricepoint is
challenging. It's a hard price to hit even when using off-the-shelf silicon
that's already produced in huge volume. Our lower volume will mean our cost-
per-chip is somewhat higher.

Ultimately, our hope is that the lowRISC SoC can act something like the "Linux
of the hardware world" \- that others can take it as a base for their own SoC
designs (startups, academics, larger companies). The most likely route to an
ultra low cost design is likely one of the large semiconductor vendors
producing and selling a derivative design.

~~~
krylon
I would like a RISC-V based, completely open device comparable to the Pi very
much!

As long as it is not outrageously expensive, I could live with a higher price
(say, about €100).

~~~
amexrap
+1

------
tyingq
I understand it would be highly speculative, but is there any research out
there on the predicted performance of the first run of production ready RISC-V
processors?

(Especially as compared to popular ARM or Intel processors)

~~~
_chris_
Performance solely depends on the design team and their market targets, not
the ISA
([https://arxiv.org/abs/1607.02318](https://arxiv.org/abs/1607.02318)).

~~~
tyingq
Right. I assume there's a specific design team that's likely to produce "the
first run of production ready RISC-V processors". I'm curious what their
general performance target is, relative to existing ARM and/or Intel
processors.

------
optforfon
I'm not really fully involved in the ecosystem too much, but has open source
hardware really paid off? Like I see that you can get cheap knockoff Arduinos
- but that's not really moving things forward. Are people forking board
designs and selling their own twists? (honest question..)

~~~
juliendorra
In the Arduino case, open design of the board is a major factor in the
ecosystem success: Arduino itself is a derivative from the Wiring board. Board
like the lilypad were invented and derived and opened new avenues to Arduino-
based projects (wearable in the case of the Lilypad). There are many
specialized arduino-derived boards, and of course the shield ecosystem. Having
a common, simple IDE is also a big part of the success, and was helped by open
design and specs. For better or worse Arduino and friends are the go-to boards
for prototyping, from humble beginnings as artist workshop helpers in northern
Italy more than a decade ago.

For a more recent interesting example, Josef Prusa built and gave away its
design for its 3D printers, they were cloned by dozens and sold everywhere in
the world. When he launched his company, he had instant recognition and
thousands of customers ready to buy. (The reprap community is a fascinating
example of real open innovation, advancing very differently than labs or
startups or big companies would)

~~~
garaetjjte
I don't get Arduino phenomenon. AVR devices can be simply wired on breadboard.
Also usually there is more suited device for project than throwing 328P
everywhere.

And arduino uses UART bootloader, which uses up UART port and doesn't offer
debugging. They have addational chip on board for usb<>uart, so why not
instead use uC which can act as programmer and debugger using normal
interface?

Atmel(Microchip now?) also have some nice XMEGA uCs with much more
perpipherals that ATmega series, but are pretty expensive.

~~~
IshKebab
Arduino is popular because you can download a single program, buy a fairly
cheap board, plug it into USB and program it easily. Also it was the very
first system to make microcontroller programming vaguely affordable, so it has
kept a lot of mindshare due to that.

There's literally no other systems that are as simple as Arduino for newbies
to use. The only one I know that is vaguely close is mBed, but that uses an
online compiler (gross), or a relatively complex and not that great CLI
interface. Arduino's IDE may be shit but at least it is simple and easy to
install.

Almost everything else involves complex JTAG/SWD programmers and weird OpenOCD
command lines and frankly that is just shit. Even as an experienced embedded
developer the state of the tools is embarrassing.

~~~
ZenoArrow
>"Also it was the very first system to make microcontroller programming
vaguely affordable"

I'd suggest that the BASIC Stamp got there before the Wiring/Arduino:

[https://en.m.wikipedia.org/wiki/BASIC_Stamp](https://en.m.wikipedia.org/wiki/BASIC_Stamp)

------
cmrdporcupine
I'm eagerly awaiting this project, I can't wait to get my little consumer
hands on a RISC-V board to play with. They're doing great work, but is it a
bit delayed? I read about this project some time ago and thought they were
further along.

~~~
asb
Yes, we're behind where we initially thought we could be. When we first
started, we hoped we might produce a test chip in 2016. This hasn't happened.
One major factor is it's been difficult to grow our team. Finding people with
the right experience is really hard, and finding people with the freedom and
desire to trade-off lower pay for greater flexibility working in a University
environment makes it more difficult.

------
cyphar
Can anyone find a link to the actual HDL files? I couldn't find a single link
on the website to where the source code for the SoC is (and they are very
vague about what license the HDL is under).

~~~
asb
Everything is up at [https://github.com/lowrisc](https://github.com/lowrisc).
We recently had a website redesign which is 'soft launched' (in that there are
a number of regressions like this I need to sort out). Amongst other pieces of
IP, we build upon the Rocket implementation from UC Berkeley, which has a BSD
license, as well as the PULPino implementation from ETH Zurich (which has an
Apache-style license).

~~~
kinghajj
So is BOOM officially not going to be the core for the first run, then? If so,
are there plans for later generations to switch to it?

~~~
asb
Assuming sufficient die area on a 28nm test chip, we would like to have a
heterogeneous cluster with something like 2xBOOM and 2xRocket.

------
saycheese
What, if any, hardware or code will not be open source on the build you plan
to offer that is required to run it?

------
_vkcd
1) How does your feature set compare to SiFive's?

2) Where will your funding come from? Corporate or academic? Will it be enough
to scale compared to SiFive?

~~~
asb
SiFive haven't completed development of their Linux-capable platform (and we
haven't completed ours). We both make use of the Rocket codebase. Key
differences include our support for tagged memory and minion cores.

Funding so far has been via private donation and a grant from Google. I expect
we will be funded by a mix of corporate and academic funding going forwards. I
believe we are in a position to secure enough funding to produce our open
source SoC and low-cost development board. Our goals are completely different
to SiFive so it doesn't really make sense to compare 'ability to scale'. Our
targets are much more modest - we don't need to generate huge returns for a
VC. The investment that SiFive and others are making into the RISC-V ecosystem
is fantastic. The great thing about open source is obviously that we all make
and benefit from a shared investment.

