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'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.
Take a look at 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.
Open source as defined by the OSI describes something identical to free software as described by the FSF.
* "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.
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?
For the initial iteration of minion cores, think of them as being an openly documented boot core and a way of implementing low-speed I/O in software (with some extra hardware support for things that would be dumb to do in software, e.g. shifting out a register). The initial target is SPI, I2C, I2S etc. Over the longer term, we are interested in using modified RISC-V cores for high-speed I/O and in general increasing the flexibility of a typical SoC design.
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 GPL family of licenses are complex legal instruments which really don't apply in a sensible way to chip designs. LGPL has previously been used in the OpenRISC community, but the 'library' boundary isn't really clear when it comes to hardware. I think there's definitely space for a hardware copyleft license that clearly defines the boundary (e.g. an IP block), but it doesn't exist currently. Strong copyleft like GPL just isn't going to work for ASICs without carefully chosen exceptions, given the need to work with proprietary process design kits. 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.
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.
> The GPL family of licenses are complex legal instruments which really don't apply in a sensible way to chip designs.
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.
That article mentions FPGAs, but doesn't discuss any of the issues with taping out an ASIC design. Specifically, the use of a proprietary and highly commercially sensitive process design kit, and the likely need for other IP to make a realistic chip (e.g. PLLs). I'm not at all against copyleft, but for lowRISC we felt that traversing uncharted territory in licensing would just be too ambitious. Additionally, one of the key components our design is derived from (Rocket) was already under a permissive BSD license.
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.
I'd like to highlight the fact that copyleft licensing also creates license incompatibility issues that prevent its use in many open source projects, and the same would apply to open hardware projects in the future. There are those (particularly certain systems-oriented luminaries) who have taken to referring to copyleft licenses as "anti-collaboration" licenses for this reason, and while I try to avoid adopting such snarky terms for my own use, it's worth noting the strength of opinion and specific problems relating to copyleft licenses.
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.
>> 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 ?
I think we need to do more work to demonstrate the advantages of tagged memory to potential adopters. I hope that the cost/benefit ratio will be such that others will adopt it.
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.
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.
The advantage of the Arduino is that it's a standard that "just works" with absolutely minimal time investment of getting started. You can have an Arduino up and running with a flashing LED before you've even assembled the breadboard and installed the toolchain for another solution.
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.
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.
The same reason you would use C when assembly could yield a much smaller and more efficient binary. Ease of use. And through having more things done for you less chance of error.
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.
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).
Everything is up at 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).
I've added a link on the 'about' page, in addition to the link that was already there on 'community'. A future restructuring will make it more prominent in the top-level navigation.
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.
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).