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.
> 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.
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.
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'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?
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), 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.
Sure, I just meant that RISC-V being permissively licensed with in-depth documentation available will ease formally verifying implementations of it, and also encourage open-source implementations.
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?
RISC-V is no guarantee that the CPU is open source. RISC-V is only an open source ISA. Implementations of it could be proprietary or open source. Some could have firmware blobs.
Some of the RISC-V ISA details are final and some are not. Check their website for the specs.
There is the Berkley Out of Order Machine BOOM https://github.com/ucb-bar/riscv-boom, its performance approaches those of modern intel processors in core mark, I think it would probably be possible to eventually match them.
Thanks for the plug, but just to clarify, while BOOM approaches the cycles/instruction of Intel's server cores, it does not approach their clock frequencies! Still, I'd say its competitive with the current mobile processor segment. =)
Check out the BOOM RISC-V core. It's a superscalar out of order core from the UCB-BAR that claims similar coremark/Mhz to Arm Cortex-A15 in about half the area.
I hope we'll be 'Respect Your Freedom' compliant https://www.fsf.org/resources/hw/endorsement/respects-your-f.... 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.
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.
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.
>> The most likely route to an ultra low cost design is likely one of the large semiconductor vendors producing and selling a derivative design.
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 ?
Note that the HiFive is a microcontroller-class RISC-V implementation. (Low pin count, 16 KB SRAM, no external memory interface.) This isn't meant to insult it; it's just in a different space from the LowRISC project.
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)
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.
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'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..)
I think that's a really good question. How many people make derivative designs from the Arduino is hard to say. It seems more common to prototype with an Arduino, and then when moving to a product to do a custom board design (as lets face it, integrating an AVR or M0 microcontroller isn't particularly challenging). I think the community of people producing 3d printer motor control PCBs etc is a great example of a successful open hardware effort.
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.
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)
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.
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.
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.
Readit News
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).
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.
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.
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.
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 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.
Deleted Comment
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 have been waiting for a modern fully open source mobile device for years.
I'd really like to at least have Bluetooth LE available.
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?
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.
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.
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?
Some of the RISC-V ISA details are final and some are not. Check their website for the specs.
Deleted Comment
- 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...
Dead Comment
https://youtu.be/QTYiH1Y5UV0
Finally the prospect of fully Free mainstream computers looks like it's becoming a reality.
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.
It will be a while before RISC-V is supported by Free Software distributions and a while before hardware will be available to buy.
https://rwmj.wordpress.com/2016/10/15/fedorarisc-v-is-finish...
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 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 ?
https://www.crowdsupply.com/onchip/open-vhttps://www.crowdsupply.com/sifive/hifive1
(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.