LowRISC – An open-source, Linux-capable System-on-a-Chip
lowrisc.org
lowrisc.org
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).
I'd love to help with this!
We'll do whatever EMC testing is necessary to comply with legislation for sale in the UK/Europe/USA/elsewhere. Beyond that, it would depend on demand from potential adopters and understanding their use case. e.g. there's no point in spending lots of money on tests on the bare board if it turned people like yourself would be putting it in a case.
I'd be really interested in finding out more about your requirements and potential use cases. To an extent, our main focus is on getting something out of the door. However we're very aware that there are a number of applications, like aerospace, where the open source (and hence auditable) nature may be particularly interesting, where we may be able to make collaborate and make small modifications at the design stage to better support a target application, and where typical unit costs are much higher than e.g. mass-market mobile phone SoCs.
I'd love to take you up on your offer of advice on this. You don't have contact info in your profile, so please drop me a line at asb@lowrisc.org.
For spacecraft we are typically building avionics in very low volume - most of the time we're making 5-10 boards, or 10-100 if for whatever reason it's some sort of constellation - I haven't personally worked on a constellation, so they might be buying more for spares or further qualification testing, but the overall point being it's not in the 1000's (or higher). So that in and of itself limits electronics designs to (board) components that are "off-the-shelf".
Typically spacecraft are doing something "non-standard" in the electronics: it's the premise of many space missions, to do something worth doing in space. Most of the time the electronics development done on the spacecraft side (where I've had most of my experience) is to support some instrument or some "payload" that's one of a kind - lots of times those one of a kind instruments have supporting electronics. And lots of times those electronics can be communicated with via standard electrical interface types (for example: EIA485/RS485, LVDS, LVCMOS). However, very rarely is the data protocol, or the temporal functionality standardized. Couple this with significant performance requirements to support the operation of said instruments/payloads (amount of data that they produce, relative timing of several spacecraft components to autonomously control spacecraft attitude, etc..) and a single chip that can both support software for higher level directives (a processor) and programmable logic for lower level and non-standard electronics interfacing (an fpga) seems like a very logical choice.
So long story short: lots of times spacecraft require non-standard data protocols and timing, and due to the typical production volumes and time horizons, doing this development with an fpga/processor combination is very advantageous.
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.
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.
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?
http://engineering.nyu.edu/press-releases/2016/08/23/cyberse...
As to your second point, I agree - open source hardware is no silver bullet for unearthing malicious backdoors. Being able to audit for unintentional issues is useful, but yes - you need to secure or trust your supply chain to know that the chip you have in your hands matches the open RTL.
You can test your improved design against the old design on an FPGA, and if the test results look good, the maintainers of the mass-produced version might merge your change request and incorporate it in their next generation.
Of course, that won't help you if your optimization only helps niche applications, but then again, if it's that niche, you weren't going to get a mass-produced SoC in the first place.
This is one of the things I'm hoping to study further during my PhD. I have a lot of reading to do before that, though :P
I'd really like to at least have Bluetooth LE available.
I have been waiting for a modern fully open source mobile device for years.
That's not to say we should write-off the posibility of open analogue components. This is an area that Onchip UIS are actively working. They are crowdfunding an open microcontroller design and write about this a little bit in their latest update https://www.crowdsupply.com/onchip/open-v/updates/5th-risc-v... (see 'no one else is doing analog').
For the board itself, we'd definitely like a WiFi/Bluetooth chip, it just won't be open.
I'm wondering if you have any solid plans for how to go about adding a GPU. Will you create a GPU from scratch, or is there an open source GPU hdl that you have your eyes on?
A GPU is an obvious future step, but there's a lot to be done before that.
Would this being built on RISC-V help with getting a formal CPU spec?
Some of the RISC-V ISA details are final and some are not. Check their website for the specs.
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), 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. MIT have been working on a specifying using their 'Kami' tool as well.
On the minion cores: that sounds quite interesting and I'm reading the paper now. Are they very different from e.g. the USB and network chips on the RPi, aside from having open firmware?
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.
* "Free software" and "open source software" are two terms for the same thing: software released under licenses that guarantee a certain, specific set of freedoms.
https://opensource.org/faq#free-software
What you're describing may be what's sometimes called "shared source".
- AESNI - fine grained sleep states
so you expect someone brand new to start at iphone 6 level of performance? ....
See page 43 - https://riscv.org/wp-content/uploads/2016/01/Wed1345-RISCV-W...
Finally the prospect of fully Free mainstream computers looks like it's becoming a reality.
It will be a while before RISC-V is supported by Free Software distributions and a while before hardware will be available to buy.
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.
https://www.crowdsupply.com/onchip/open-v https://www.crowdsupply.com/sifive/hifive1
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.
As long as it is not outrageously expensive, I could live with a higher price (say, about €100).
Why a permissive licence then? Doesn't that make it too easy for 3rd parties to take your design and slap on some vendor lock-in (e.g. via "secure boot")? Neither does it protect against EEE.
This piece from Andrew Katz is a good read http://www.ifosslr.org/ifosslr/article/view/69/131 or else the (length and inconclusive) discussion about GPLed HDL designs at last year's ORCONF https://www.youtube.com/watch?v=JgRBDuZQsFg https://www.youtube.com/watch?v=UOZkiOtmHEQ
Secure boot is a useful feature, but definitely one that can be abused to limit a user's freedom. I think a copyright license is far too blunt an instrument here - instead certification schemes (e.g. FSF's Respect Your Freedom) make more sense.
GPLv3 was designed with chip designs in mind, and the FSF has an article about it[1]. I'm not a lawyer (though I do cosplay as one on the internet), but I would assume that the FSF's intentions would've resulted in a license that was applicable to chip designs.
> Secure boot is a useful feature, but definitely one that can be abused to limit a user's freedom.
GPLv3 doesn't stop secure boot from being implemented, it just stops it from being used to take away users' freedom ("Restricted Boot" like Windows 8 ARM laptops that don't allow you to install anything other than Windows).
> I think projects like LLVM and FreeBSD show that a copyleft license isn't a pre-requisite for building a strong community of contributors, including from industry.
I don't think people are worried about community formation. The main concern is that someone forks RISC-V to create a proprietary chip design and then fools users into thinking that it's a free hardware design. Or they steal the market share that RISC-V would've had.
[1]: https://www.gnu.org/philosophy/free-hardware-designs.en.html
I understand how GPLv3 and secure boot works with software, I was unclear as to how those clauses might apply to a hardware design. I fully agree that 'restricted boot' is a terrible situation for consumers.
As for me personally . . . I'm an open source developer and advocate with a history of writing very pro-open-source articles for a (somewhat?) major online tech publication, and I am one of quite a few people I know who refuse to throw any significant code into the legal compatibility black hole of copyleft licensed projects. I would, therefore, be considerably less likely to show interest in RISC-V if it was copyleft.
I've also noted that in recent years new copyleft projects (except in particular niche areas where people apparently haven't heard of non-copyleft open source licenses) tend to suffer problems with rate of popular uptake. I'd hate to see that happen to such an obviously excellence-aimed open hardware project as RISC-V.
This is probably also a requirement for competitiveness on size/power/etc - because of the manufacturing and other advantages the big guys have.
So for the medium term, this means you need to find a different niche, and possibly a niche that the big guys don't want to copy, or can't copy.
So replacing peripherials with minion cores is a smart move. Same with customization for medium volume customers. Both goes against the business models of semi companies - extracting a price on every different feature.
But your other big innovation ,tagged memory, do you think it will get copied ?
Also what kind of imrpovements would you like to see contributed by the open-source community ?
As for other improvements, it's difficult to pick out specific projects. Off the top of my head, the work on an efficient out-of-order RISC-V core BOOM (https://github.com/ucb-bar/riscv-boom/) is exciting, peripherals such as USB or memory controllers are valuable, and there's a lot to be done in terms of benchmarking and performance analysis.
(Especially as compared to popular ARM or Intel processors)
I do understand that's just one specific implementation (RISCV BOOM), but it does give a little clarity on what level of performance that team is targeting.
Edit: Regarding the range of microcontroller to fast 64 bit...that's exactly what I'm trying to understand, mapping what's possible to what's actually being worked on. Roughly, when a production ready RISC-V 64 bit implementation might happen, and how it would compare to ARM/Intel. It's somewhat difficult to tell if the first in the "fast 64 bit" would be more comparable to a Raspberry PI in performance, or more comparable to a very low end Intel x86 processor.
So, yes, I get that the ISA doesn't dictate that, but the current groups working on RISC-V implementation does...and it's not clear to me who they all are, what their performance target is, and when they might produce something.
I believe open source silicon design has much more to offer than just lowering unit costs and increasing profit margins for the existing dominant players. This is why we are established as an independent not-for-profit - we want open source hardware to benefit everyone, and its design to be a truly collaborative process. We have a long way to go, but that's the direction we want to help move things in.
We are set up as a UK Community Interest Company, which that means we define a particular community we hope to benefit. For us that is anybody who may either adopt or benefit from open source hardware - whether they're a hobbyist, academic, small startup, established company, and whether they're currently sponsoring our efforts or not.
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)
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.
As a standard, users benefit from being able to share instructions that have a high chance of working on someone else's system.
Obviously these are most relevant for beginners or those with a short time to invest. But that's the market that Arduino practically created. It simplifies the decision making process: if you're a beginner, start with Arduino. Once you've used it for a bit, you'll be aware of the limitations and have an opinion on which alternative to switch to.
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.
I'd suggest that the BASIC Stamp got there before the Wiring/Arduino:
2) Where will your funding come from? Corporate or academic? Will it be enough to scale compared to SiFive?
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.