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).
> 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.
I agree, open source hardware (and especially open source silicon, where there are such huge barriers of entry) is very much different to open source software. It's possible that a breakthrough in direct-write lithography or similar would help to reduce these barriers, but it's not something we're betting the project on. This is one reason why our hope isn't to produce just one iteration of the lowRISC SoC, but to have a regular tapeout schedule. This means if you make a contribution, you know you'll be able to see it on shipping silicon on a reasonable timeline. Another part of this story is, as with minion cores, in moving more aspects of the design from fixed hardware to being software configurable.
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.
> 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.
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?
This is true, imaging a die can help but it's not enough for full assurance. See e.g. this work on inserting hardware trojans through changing the dopant levels on transistors http://sharps.org/wp-content/uploads/BECKER-CHES.pdf
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.
> 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).
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.
> 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.
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'm in the aerospace industry and I know my company and others would be very much interested in this. As I'm sure you're aware aerospace requirements are primarily on the environmental envolope of the chip (temperature, vibration, mechanical shock, EMI, etc) - to that end, I know it's tangential to consumer electronics, but is it in the cards to do any sort of radiation testing on the first run? Similarly, do you have a notion yet what sort of EMC standards you'll want to comply to? (if any).
The short answer to this is that no, we're not at the stage where we've carefully considered these parameters. Most of our focus so far has been on the platform design+implementation and on ensuring there is at least one viable route to a tapeout, with necessary packaging design and access to the physical IP we need given the funding we have.
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.
I should preface this that I work in the astronautics industry, and I'm only loosely familiar with aeronautics.
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.
As an end user interested in RISC-V, I'd like to say thank you. You and other RISC-V contributors give me hope that we get a powerful, open, unbloated computing platform. And thank you for posting notes about the RISC-V Workshops.
You're very welcome! I'm hoping to increase activity on the blog over the coming weeks and months so hopefully I'll be doing a better job in the future of keeping you up to date on developments both with lowRISC itself and in the wider free and open source hardware community.
I particularly like the fact that the core spec is a hundred pages and they commit to keeping it small. The minimal architecture RVI32 is even much less than that and will probably still be useful in real life.
Absolutely. Our main focus right now is in completing the RTL design for our initial SoC platform, at which point we can perform a test run (multi-project wafer) and ultimately volume production.
Any plans for adding wifi or bluetooth capability? I admit I have little hardware knowledge, but would those normally be separate chips, or are they going to be part of the SOC?
On-chip, not in the near future. The main challenge is the analogue design and that's not the area where our expertise lies. The economics are also quite different for an open source effort (digital logic is portable across different process nodes, analogue designs aren't), plus it's very difficult to share designs due to the foundries' desire to protect trade secrets.
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.
In your FAQ, you say that "early versions of our SoC will not include a GPU".
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?
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).