13 ms·

There's been a fair bit of discussion about this over on reddit: https://www.reddit.com/r/linux/comments/3z9t7k/open_source_processor_core_gains_traction_googl

by asb 11y ago

There's been a fair bit of discussion about this over on reddit: https://www.reddit.com/r/linux/comments/3z9t7k/open_source_processor_core_gains_traction_google/ https://www.reddit.com/r/linux/comments/3z9t7k/open_source_p... https://www.reddit.com/r/opensource/comments/3z5ue8/open_source_processor_core_gains_traction_google/ https://www.reddit.com/r/opensource/comments/3z5ue8/open_sou... I'm a cofounder of lowRISC, a not-for-profit working to produce a fully open source SoC implementing the RISC-V ISA, in volume silicon. If you have questions then fire away.

ZenoArrow 11y ago
I remember hearing about lowRISC before, but haven't kept up with it. How have the last 12 months been for the project? Also, what process node are you currently targeting?
- asb 11y ago
  My response to a sibling question gives some details on recent developments. We're currently looking to target 28nm bulk CMOS.
0xcde4c3db 11y ago
Can you talk about how involved/committed chip vendors are in the lowRISC effort or RISC-V generally? I remember seeing mentions of STMicro in some of the Berkeley slides, but it wasn't clear to me whether they were just donating fab capacity/support or were in a more interested/collaborative role.
- asb 11y ago
  Some of the Berkeley test chips with RISC-V processors were done on ST's 28nm FD-SOI. There's not currently any larger role from ST or any other fab.
roymurdock 11y ago
> A permissive open-source license. What specific license will you be releasing under? Is that still TBD? Also, who is putting up the money for dev time and fabrication? Partners? Exciting stuff. Thanks for sharing!
- asb 11y ago
  Changes to existing projects (e.g. Berkeley's Rocket RISC-V design) is released under the upstream project's license. We're interested in using an Apache-derived license for new hardware codebases due to the additional patent clauses. We have received backing from a private individual which has got us going, and some additional donations from some of our project partners.
  - jacques_chester 11y ago
    Companies paying into Foundations which own the IP under an Apache license is becoming a relatively well-tested pattern these days. The Linux Foundation provides "Foundation as a Service" to several of these. I work for Pivotal, so I'm most familiar with the Cloud Foundry Foundation, which is administered by the Linux Foundation on behalf of members. From what I can see, it's a smooth way to offload the administrative stuff to specialists while retaining the core openness.
frik 11y ago
I haven't followed the progress the last few months, so sorry for my probably dumb questions: What's the current status? (I read http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-two http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-d... (June 30, 2015)) Your site mentions a lot of "FPGA", do you have some actual silicon prototypes? What's the current raw speed in MHz or FLOPS? I read about OpenRISC, OpenSPARC, RISC-V, Z-Scale, BOOM - which are furthest in testing phase? Can we buy some of them in 2017? Or will it take longer?
- zhemao 11y ago
  > OpenRISC, OpenSPARC Can't really comment, since these aren't our projects. I haven't really seen any developments on these fronts, though. > RISC-V, Z-Scale, BOOM RISC-V is the ISA. Rocket, Z-Scale, and BOOM are implementations of the ISA we've produced at Berkeley. Rocket is our reference implementation. It is a 64-bit in-order core. Z-scale is a small 32-bit core with no MMU intended for microcontrollers. BOOM is an out-of-order 64-bit core. They all share some common code, but BOOM is a bit behind the other two. We have taped out different Rocket and Z-scale chips. But these run as tethered systems and were only meant for our research. As a university research lab, we do not really have any intentions for mass manufacture. ASB can answer better about when lowRISC chips will be commercially available.
- asb 11y ago
  Our most recent update was releasing an untethered version of the Rocket core http://www.lowrisc.org/blog/2015/12/untethered-lowrisc-release/ http://www.lowrisc.org/blog/2015/12/untethered-lowrisc-relea.... Our next development goals are integrating the minion cores and integrating with third-party IP in order to produce the initial test chip, which we're intending to tape out later this year. We haven't yet produced a silicon prototype, but will be taping one out this year. The Berkelely Rocket implementation has been silicon-proven multiple times as has the ETH Zurich PULP core which we also hope to use. The aim of this test chip is to integrate an LPDDR3 memory controller+PHY, plus USB host controller+PHY. I don't have the link handy, but the Rocket implementation has clocked at 1.5GHz on a 45nm process. For the final question, perhaps it's useful to define some of these terms: * OpenRISC: an older 32-bit open ISA. * OpenSPARC: The open-sourced design from Oracle. GPL-licensed. I don't know of anyone planning to produce a commercially available ASIC using it. * Z-scale and BOOM are both RISC-V implementations from Berkeley. Z-Scale is a microcontroller-class RISC-V implementation and BOOM is an out-of-order implementation. Both make use of parts of the Rocket implementation (essentially using the codebase as a library). I believe only the base Rocket design has been produced in silicon so far. With lowRISC, we hope to discuss at the upcoming RISC-V workshop (this Tuesday and Wednesday) the status of BOOM, and whether it will make sense to use it as our application cores. I hope we'll see commercially available lowRISC chips towards the end of 2017, but we'll be able to make a better judgement about how realistic that is once we reach our first test chip.
modeless 11y ago
Not a question really, but a comment for anyone involved: please push to add integer overflow traps. No processor adds support because C doesn't require them, and as a result no language detects integer overflow by default because the processors make it slow. We need to break this cycle and it's not often that a new processor architecture comes around. http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154
- luu 11y ago
  There is no chicken and egg problem for most workloads. Processors are quite good at handling correctly predicted branches, and overflow checks will be correctly predicted for basically all reasonable code. In the case where the branch is incorrectly predicted (because of an overflow), you likely don't care about performance anyway. See http://danluu.com/integer-overflow/ http://danluu.com/integer-overflow/ for a quick and dirty benchmark (which shows a penalty of less than 1% for a randomly selected integer heavy workload, when using proper compiler support -- unfortunately, most people implement this incorrectly), or try it yourself. People often overestimate the cost of overflow checking by running a microbenchmark that consists of a loop over some additions. You'll see a noticeable slowdown in that case, but it turns out there aren't many real workloads that closely resemble doing nothing but looping over addition, and the workloads with similar characteristics are mostly in code where people don't care about security anyway.
  - modeless 11y ago
    People who are actually implementing new languages disagree. Look at the hoops Rust is jumping through (partially) because they don't feel comfortable with the performance penalty of default integer overflow checks: https://github.com/rust-lang/rfcs/pull/146 https://github.com/rust-lang/rfcs/pull/146
    - luu 11y ago
      If you read the thread, you'll see that the person who actually benchmarked things agrees: someone implemented integer overflow checks and found that the performance penalty was low, except for microbenchmarks. If you click through to the RISC-V mailing list linked to elsewhere in this discussion, you'll see that the C++17 standard library is planning on doing checked integer operations by default. If that's not a "performance focused language", I don't know what is.

by asb 11y ago

ZenoArrow 11y ago

I remember hearing about lowRISC before, but haven't kept up with it. How have the last 12 months been for the project? Also, what process node are you currently targeting?

asb 11y ago
My response to a sibling question gives some details on recent developments. We're currently looking to target 28nm bulk CMOS.

0xcde4c3db 11y ago

Can you talk about how involved/committed chip vendors are in the lowRISC effort or RISC-V generally? I remember seeing mentions of STMicro in some of the Berkeley slides, but it wasn't clear to me whether they were just donating fab capacity/support or were in a more interested/collaborative role.

asb 11y ago
Some of the Berkeley test chips with RISC-V processors were done on ST's 28nm FD-SOI. There's not currently any larger role from ST or any other fab.

roymurdock 11y ago

> A permissive open-source license. What specific license will you be releasing under? Is that still TBD? Also, who is putting up the money for dev time and fabrication? Partners? Exciting stuff. Thanks for sharing!

asb 11y ago
Changes to existing projects (e.g. Berkeley's Rocket RISC-V design) is released under the upstream project's license. We're interested in using an Apache-derived license for new hardware codebases due to the additional patent clauses. We have received backing from a private individual which has got us going, and some additional donations from some of our project partners.
- jacques_chester 11y ago
  Companies paying into Foundations which own the IP under an Apache license is becoming a relatively well-tested pattern these days. The Linux Foundation provides "Foundation as a Service" to several of these. I work for Pivotal, so I'm most familiar with the Cloud Foundry Foundation, which is administered by the Linux Foundation on behalf of members. From what I can see, it's a smooth way to offload the administrative stuff to specialists while retaining the core openness.

frik 11y ago

I haven't followed the progress the last few months, so sorry for my probably dumb questions: What's the current status? (I read http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-two http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-d... (June 30, 2015)) Your site mentions a lot of "FPGA", do you have some actual silicon prototypes? What's the current raw speed in MHz or FLOPS? I read about OpenRISC, OpenSPARC, RISC-V, Z-Scale, BOOM - which are furthest in testing phase? Can we buy some of them in 2017? Or will it take longer?

zhemao 11y ago
> OpenRISC, OpenSPARC Can't really comment, since these aren't our projects. I haven't really seen any developments on these fronts, though. > RISC-V, Z-Scale, BOOM RISC-V is the ISA. Rocket, Z-Scale, and BOOM are implementations of the ISA we've produced at Berkeley. Rocket is our reference implementation. It is a 64-bit in-order core. Z-scale is a small 32-bit core with no MMU intended for microcontrollers. BOOM is an out-of-order 64-bit core. They all share some common code, but BOOM is a bit behind the other two. We have taped out different Rocket and Z-scale chips. But these run as tethered systems and were only meant for our research. As a university research lab, we do not really have any intentions for mass manufacture. ASB can answer better about when lowRISC chips will be commercially available.
asb 11y ago
Our most recent update was releasing an untethered version of the Rocket core http://www.lowrisc.org/blog/2015/12/untethered-lowrisc-release/ http://www.lowrisc.org/blog/2015/12/untethered-lowrisc-relea.... Our next development goals are integrating the minion cores and integrating with third-party IP in order to produce the initial test chip, which we're intending to tape out later this year. We haven't yet produced a silicon prototype, but will be taping one out this year. The Berkelely Rocket implementation has been silicon-proven multiple times as has the ETH Zurich PULP core which we also hope to use. The aim of this test chip is to integrate an LPDDR3 memory controller+PHY, plus USB host controller+PHY. I don't have the link handy, but the Rocket implementation has clocked at 1.5GHz on a 45nm process. For the final question, perhaps it's useful to define some of these terms: * OpenRISC: an older 32-bit open ISA. * OpenSPARC: The open-sourced design from Oracle. GPL-licensed. I don't know of anyone planning to produce a commercially available ASIC using it. * Z-scale and BOOM are both RISC-V implementations from Berkeley. Z-Scale is a microcontroller-class RISC-V implementation and BOOM is an out-of-order implementation. Both make use of parts of the Rocket implementation (essentially using the codebase as a library). I believe only the base Rocket design has been produced in silicon so far. With lowRISC, we hope to discuss at the upcoming RISC-V workshop (this Tuesday and Wednesday) the status of BOOM, and whether it will make sense to use it as our application cores. I hope we'll see commercially available lowRISC chips towards the end of 2017, but we'll be able to make a better judgement about how realistic that is once we reach our first test chip.

modeless 11y ago

Not a question really, but a comment for anyone involved: please push to add integer overflow traps. No processor adds support because C doesn't require them, and as a result no language detects integer overflow by default because the processors make it slow. We need to break this cycle and it's not often that a new processor architecture comes around. http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154

luu 11y ago
There is no chicken and egg problem for most workloads. Processors are quite good at handling correctly predicted branches, and overflow checks will be correctly predicted for basically all reasonable code. In the case where the branch is incorrectly predicted (because of an overflow), you likely don't care about performance anyway. See http://danluu.com/integer-overflow/ http://danluu.com/integer-overflow/ for a quick and dirty benchmark (which shows a penalty of less than 1% for a randomly selected integer heavy workload, when using proper compiler support -- unfortunately, most people implement this incorrectly), or try it yourself. People often overestimate the cost of overflow checking by running a microbenchmark that consists of a loop over some additions. You'll see a noticeable slowdown in that case, but it turns out there aren't many real workloads that closely resemble doing nothing but looping over addition, and the workloads with similar characteristics are mostly in code where people don't care about security anyway.
- modeless 11y ago
  People who are actually implementing new languages disagree. Look at the hoops Rust is jumping through (partially) because they don't feel comfortable with the performance penalty of default integer overflow checks: https://github.com/rust-lang/rfcs/pull/146 https://github.com/rust-lang/rfcs/pull/146
  - luu 11y ago
    If you read the thread, you'll see that the person who actually benchmarked things agrees: someone implemented integer overflow checks and found that the performance penalty was low, except for microbenchmarks. If you click through to the RISC-V mailing list linked to elsewhere in this discussion, you'll see that the C++17 standard library is planning on doing checked integer operations by default. If that's not a "performance focused language", I don't know what is.