6 ms·

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 t

by asb 10y ago

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).

comboy 10y ago
Do you plan to release any official dev board(s)?
- asb 10y ago
  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.
- deleted 10y ago
  [deleted]
airbear 10y ago
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). I'd love to help with this!
- asb 10y ago
  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.
- pjc50 10y ago
  I think you'd probably have to offer to fund it yourself. Why would the aerospace industry prefer this to its various existing solutions?
  - airbear 10y ago
    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.
throwaway41597 10y ago
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.
- asb 10y ago
  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.
- warkdarrior 10y ago
  Is there anything inherent in RISC-V that makes the platform unbloated?
  - BuuQu9hu 10y ago
    Some points about that in this talk: https://youtu.be/QTYiH1Y5UV0 https://youtu.be/QTYiH1Y5UV0
  - throwaway41597 10y ago
    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.
lgeek 10y ago
> 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 10y ago
  > 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 10y ago
    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?
    - 10y ago
tomjen3 10y ago
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?
- erichocean 10y ago
  +1 I'd really like to at least have Bluetooth LE available.
- thrilleratplay 10y ago
  or cellular? I have been waiting for a modern fully open source mobile device for years.
- asb 10y ago
  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-workshop 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.
phire 10y ago
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?
- asb 10y ago
  I'd recommend looking at Nyuzi https://github.com/jbush001/NyuziProcessor https://github.com/jbush001/NyuziProcessor. A GPU is an obvious future step, but there's a lot to be done before that.

by asb 10y ago

comboy 10y ago

Do you plan to release any official dev board(s)?

asb 10y ago
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.
deleted 10y ago
[deleted]

airbear 10y ago

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). I'd love to help with this!

asb 10y ago
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.
pjc50 10y ago
I think you'd probably have to offer to fund it yourself. Why would the aerospace industry prefer this to its various existing solutions?
- airbear 10y ago
  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.

throwaway41597 10y ago

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.

asb 10y ago
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.
warkdarrior 10y ago
Is there anything inherent in RISC-V that makes the platform unbloated?
- BuuQu9hu 10y ago
  Some points about that in this talk: https://youtu.be/QTYiH1Y5UV0 https://youtu.be/QTYiH1Y5UV0
- throwaway41597 10y ago
  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.

lgeek 10y ago

> 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 10y ago
> 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 10y ago
  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?
  - 10y ago

tomjen3 10y ago

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?

erichocean 10y ago
+1 I'd really like to at least have Bluetooth LE available.
thrilleratplay 10y ago
or cellular? I have been waiting for a modern fully open source mobile device for years.
asb 10y ago
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-workshop 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.

phire 10y ago

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?

asb 10y ago
I'd recommend looking at Nyuzi https://github.com/jbush001/NyuziProcessor https://github.com/jbush001/NyuziProcessor. A GPU is an obvious future step, but there's a lot to be done before that.