14 ms·

Google, HP, Oracle Join RISC-V – Open-source processor core gains traction

260 points by mparramon 11y ago

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.
0xcde4c3db 11y ago
Microsemi (the names "Actel" and "ProASIC" might be better-known) and Lattice are also mentioned as sponsors in the article itself. These are FPGA vendors, which suggests that they might be interested in shipping RISC-V soft cores in their design tools or possibly even shipping chips with RISC-V hard cores (similar to the Xilinx Zynq and Altera SoC families). Notably, Lattice manufactures the only FPGA for which a full open source design flow currently exists (albeit unsupported by Lattice themselves) [1], and has its own set of open source soft processor cores [2] [3]. [1] http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ [2] http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/LatticeMico32.aspx http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I... [3] http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/Mico8.aspx http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I...
- petra 11y ago
  I think the main reason the fpga companies aren't offering a low-cost , hard core mcu+fpga chip is that they are afraid about competing against the mcu companies.They can certainly reach the prices (Lattice claims a 50 cents fpga).And it's very affordable to license from ARM. So i don't see this sector changing with an open-source core.
  - Sanddancer 11y ago
    Altera, and Xilinx both offer FPGAs that have ARM cores in them for when the need arises. However, the FPGA market has entrenched itself fairly well into the DSP realm, and as such, worrying about an mpu at all just means chip area that would likely go to waste anyways. Lattice on the other hand, is a more general purpose chip maker, so they may not want to bite the hand that feeds them. They've got a lot of products other than FPGAs, so keeping those lines working is probably more strategic than anything else.
  - sitkack 11y ago
    As sanddancer said, there are already high end parts from both of the top FPGA companies that include hard MCUs. Xilinx has been doing this for a really long time going back to embedded PPC. They wouldn't be competing against MCU companies, they are already competing against other programmable logic companies with the same features. The difficult part is the engineering and marketing in a way that doesn't cut into the profit margin of those low cost FPGAs. And RISCV provides a zero to low cost path to working netlists and toolchains. MCU+FPGA hybrids are absolutely the future in programmable logic it is only a matter of time before _all_ shipping fpgas have built in hard programmable control logic.
wstrange 11y ago
Can someone explain the advantage of RISC-V vs. other open source architectures (e.g. OpenSPARC?). Are there legal issues that make it more favourable?
- tw04 11y ago
  Well, I think the fact it's LGPL vs. GPLv2 is one point in favor of RISC-V. The other major factor I believe is that the RISC-V architecture is better suited for embedded type applications. I don't think you could (easily) scale down the OpenSPARC design enough to make it a suitable architecture.
  - zhemao 11y ago
    The RISC-V ISA and Berkeley's open source reference implementations are BSD-licensed, not LGPL. And yes, the RISC-V ISA is simpler than the SPARC ISA. We also have clearly separated the base integer ISA from the various extensions, such as floating-point, atomics, supervisor, etc.
    - tw04 11y ago
      Thank you for the correction, I was thinking OpenRISC (which is LGPL), vs. RISC-V (which is BSD).
- jkot 11y ago
  I believe OpenSPARC is a bit slow, this could be faster.
- FullyFunctional 11y ago
  Lots have been written about that, but this might be a good starting point: http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-14..., but read also the spec (http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62...) and pay attention to the footnotes. IMO, compared to OpenSPARC, this is a fresh design that leverages lessons learned from everything that proceeded it. There are many problems with SPARC that makes it hard & expensive to scale up and down.
zhemao 11y ago
Hi, I'm a Ph.D. student at UC Berkeley on the RISC-V team. Happy to answer any questions about the RISC-V ISA or Rocket, our open-source reference implementation. Since there's always confusion about it, I'll start off by clarifying the difference between the two. RISC-V is an open-source ISA standard. Rocket is an implementation of this ISA which also happens to be open source. We do not intend for the ISA to be tied to a single reference implementation. The intention for RISC-V is to enable many different implementations (whether open-source or proprietary). These different implementations can all run an open-source software ecosystem, which currently consists of a GNU toolchain, LLVM, and Linux kernel port.
- 1ris 11y ago
  Great! I heard somewhere here on HN that a modern x86 decoder is smaller than a modern arm decoder. Do you know if this is true? Also, how big is the decoder of risc-v and does it even matter? (I mean the size)
  - zhemao 11y ago
    > a modern x86 decoder is smaller than a modern arm decoder That's because the ARM ISA is not small either by any stretch of the imagination. On the other hand, the instruction listing of the base RISC-V ISA and the standard extensions can fit on a single powerpoint slide. http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2015.pdf http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2... I wasn't involved in any of the recent tape-outs, so I can't say exactly how big the decoder is. But it's quite small relative to the other chip components. Currently, the integer pipeline of the chip is roughly the same size as the FPU, and these two together are roughly the same size as the L1 cache. All of those components together are smaller than the L2 cache (depends on the size of the L2 cache, though). So decoder size doesn't really matter in the grand scheme of things. Decoder speed probably does matter, though. Currently, we can decode an instruction in a single cycle (1 ns). The x86 decoder, on the other hand, can take multiple cycles depending on instruction. But maybe this isn't a fair comparison since the instructions are decomposed into uops. I have no idea about the performance of ARM decoders.
mwcampbell 11y ago
I wonder what Google, HP, and Oracle are planning to do with RISC-V. Will RISC-V-based chips be able to compete with Intel in the server market? Incidentally, I think the first consumer devices to adopt RISC-V will be home wireless routers, because the stock firmwares for those are closed, so they'll just need to be recompiled with a new toolchain. And those devices don't need a GPU.
- zhemao 11y ago
  We do expect embedded systems to be the main use of RISC-V processors at the outset. In fact, I believe there is a consumer product out now - some kind of camera - which uses a RISC-V processor. I don't think we'll be able to compete with Intel's x86 chips for a while. Mostly because Intel's silicon processes are more advanced than those offered by other foundries.
  - aurhum 11y ago
    The AXIOM, a 4K camera uses a RISC-V http://riscv.org/workshop-jan2016.html http://riscv.org/workshop-jan2016.html
- asb 11y ago
  I agree that the easiest entry-point for RISC-V is in systems which run embedded firmware of some sort (even if it's a builroot Linux rootfs). Even before you get to that, there are loads of companies that still have their own home-grown instruction sets used for auxilliary functions on a larger core. Think peripherals on an SoC, SSD controllers and so on.
- mtgx 11y ago
  Well, it may be easier to offer an open source RISC-V processor in products, but it's certainly not necessary. From Wikipedia: > The RISC-V authors aim to provide several freely available CPU designs, under a BSD license. This license allows derivative works such as RISC-V chip designs to be either open and free like RISC-V itself, or closed and proprietary, (unlike the available OpenRISC cores, which under the GPL, requires that all derivative works also be open and free). https://en.wikipedia.org/wiki/RISC-V https://en.wikipedia.org/wiki/RISC-V So if it's not GPL, such as OpenRISC, then it's not guaranteed to be fully open source. You could still have 99% of the chip as open source and the other 1% as the proprietary backdoor.
bitwize 11y ago
I wonder what the copyright license terms on Oracle's proprietary ISA extensions will be...
Const-me 11y ago
I wonder how are they going to compete with Intel? I don’t see how they’re going to match raw performance against those 1tflops+ 20-cores xeons. I don’t see how they’re going to match performance/watt against 7w quad-core C2338. I don’t see how they’re going to match price against $20 x5-Z8300. If none of the above, then why should Google/HP/Oracle/anyone else buy that?
- mtgx 11y ago
  Maybe they think the more Intel conquers the markets it's in, the less competitive it will be performance/price-wise - like say how it replaced its $110 Core-based Celeron chips for Atom chips with half the performance and almost no extra "features" that also cost $110, because it knows people will keep buying "Intel" in the PC market and are not even giving AMD a second look now. It surely helped when Microsoft killed Windows RT and eliminated the ARM competition from the market for the foreseeable future. Maybe these RISC-V chips will never get out of the labs of Google, but they could still serve to force Intel to keep prices the same on its new generations in the future, unless they want Google to really get serious about making its own chips.
  - Const-me 11y ago
    “how it replaced its $110 Core-based Celeron chips for Atom chips” — they already reverted that decision. Latest Celerons 3855U, 3955U are Skylake i.e. 6th generation Core chips.
- jeffbush 11y ago
  I don't think they need to compete with Intel. The numbers I've seen suggests Intel ships around 300-400 Million processors per year[1]. In 2014, 12 Billon (with a B) devices with ARM cores shipped[2]. In 2011, around 500 Million MIPS based cores shipped[3]. These are obviously very different businesses. But it's clear there is an enormous market for licensable low-end IP cores that are used in everything from cars, cable boxes, TVs, cellphones (many phones have multiple cores internally to operate functions like the cellular baseband), etc. Most of the licensees are just gluing together licensed cores and contracting foundries like TSMC or Global Foundries to build them. The margins tend to be pretty thin (we're talking chips that are in the single digits for cost), so saving a little money on IP licensing is attractive. Since these are often custom applications, binary compatibility is less of an issue. That seems like a more interesting market for an open ISA and open core processors. [1] http://www.ft.com/cms/s/0/beff6e56-53ed-11e4-80db-00144feab7de.html#axzz3wFGbKjgu http://www.ft.com/cms/s/0/beff6e56-53ed-11e4-80db-00144feab7... [2] https://atlas.qz.com/charts/Ek18VmbP https://atlas.qz.com/charts/Ek18VmbP [3] http://www.forbes.com/forbes/2011/0509/technology-mips-sandeep-vij-dvd-micro-chips-less-more.html http://www.forbes.com/forbes/2011/0509/technology-mips-sande...
tbirdz 11y ago
How does RISC-V compare with the J2 core based on the SuperH architecture by the Open Processor Foundation[1]? 1: http://0pf.org/ http://0pf.org/
- asb 11y ago
  I answered a similar (but slightly different) question here: https://lobste.rs/s/jmgsyl/untethered_lowrisc_release/comments/ng761j#c_ng761j https://lobste.rs/s/jmgsyl/untethered_lowrisc_release/commen..., comparing lowRISC and the Open Processor Foundation.
thebeardisred 11y ago
Obligatory: ¨RISC architecture is going to change everything¨ - https://arikia.files.wordpress.com/2013/02/test2.gif?w=625 https://arikia.files.wordpress.com/2013/02/test2.gif?w=625
chei0aiV 11y ago
I wonder if HP are looking at RISC-V/lowRISC for their "The Machine" project.
deleted 11y ago
[deleted]
fmarch 11y ago
Has any one created a verification infrastructure with any of RISC-V implementations? The git repository does have a set of tests and benchmarks but could not find any thing more than that.
- gluggymug 11y ago
  Check out : https://github.com/ucb-bar/rocket-chip https://github.com/ucb-bar/rocket-chip Last time I complained here about the verification infrastructure of this project, someone gave that link. I didn't like much of what I could find there. What exactly are you trying to do?
  - fmarch 11y ago
    I want to at the minimum compare the architectural state of the implementation on every retire with the ISA simulator (Spike). In addition it would be good to have a set of assertions to maintain the sanity (read functional correctness) while experimenting with the design. How are these implementations verified right now ? All I see are few assertions in chisel and small set of tests.
    - _chris_ 11y ago
      You can get a commit log (PC, inst, write-back address, write-back data) from Rocket to compare against Spike's commit log. It's not documented because the verification story is still in flux, and the commit log is fairly manual (since there will be many false positives). Comparing a real CPU against an ISA simulator is VERY HARD. There's counter instructions, there's interrupts, timers will differ, multi-core will exhibit different (correct) answers, Rocket has out-of-order write-back+early commit, floating point registers are 65-bit recoded values, some (required) ambiguity in the spec that can't be reconciled easily (e.g., storing single-precision FP values using FSD puts undefined values in memory, the only requirement being that the value is properly restored by a corresponding FLD). We also use a torture tester that we'll open source Soon (tm).
      - 11y ago

260 points by mparramon 11y ago

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.

0xcde4c3db 11y ago

Microsemi (the names "Actel" and "ProASIC" might be better-known) and Lattice are also mentioned as sponsors in the article itself. These are FPGA vendors, which suggests that they might be interested in shipping RISC-V soft cores in their design tools or possibly even shipping chips with RISC-V hard cores (similar to the Xilinx Zynq and Altera SoC families). Notably, Lattice manufactures the only FPGA for which a full open source design flow currently exists (albeit unsupported by Lattice themselves) [1], and has its own set of open source soft processor cores [2] [3]. [1] http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/ [2] http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/LatticeMico32.aspx http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I... [3] http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores02/Mico8.aspx http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I...

petra 11y ago
I think the main reason the fpga companies aren't offering a low-cost , hard core mcu+fpga chip is that they are afraid about competing against the mcu companies.They can certainly reach the prices (Lattice claims a 50 cents fpga).And it's very affordable to license from ARM. So i don't see this sector changing with an open-source core.
- Sanddancer 11y ago
  Altera, and Xilinx both offer FPGAs that have ARM cores in them for when the need arises. However, the FPGA market has entrenched itself fairly well into the DSP realm, and as such, worrying about an mpu at all just means chip area that would likely go to waste anyways. Lattice on the other hand, is a more general purpose chip maker, so they may not want to bite the hand that feeds them. They've got a lot of products other than FPGAs, so keeping those lines working is probably more strategic than anything else.
- sitkack 11y ago
  As sanddancer said, there are already high end parts from both of the top FPGA companies that include hard MCUs. Xilinx has been doing this for a really long time going back to embedded PPC. They wouldn't be competing against MCU companies, they are already competing against other programmable logic companies with the same features. The difficult part is the engineering and marketing in a way that doesn't cut into the profit margin of those low cost FPGAs. And RISCV provides a zero to low cost path to working netlists and toolchains. MCU+FPGA hybrids are absolutely the future in programmable logic it is only a matter of time before _all_ shipping fpgas have built in hard programmable control logic.

wstrange 11y ago

Can someone explain the advantage of RISC-V vs. other open source architectures (e.g. OpenSPARC?). Are there legal issues that make it more favourable?

tw04 11y ago
Well, I think the fact it's LGPL vs. GPLv2 is one point in favor of RISC-V. The other major factor I believe is that the RISC-V architecture is better suited for embedded type applications. I don't think you could (easily) scale down the OpenSPARC design enough to make it a suitable architecture.
- zhemao 11y ago
  The RISC-V ISA and Berkeley's open source reference implementations are BSD-licensed, not LGPL. And yes, the RISC-V ISA is simpler than the SPARC ISA. We also have clearly separated the base integer ISA from the various extensions, such as floating-point, atomics, supervisor, etc.
  - tw04 11y ago
    Thank you for the correction, I was thinking OpenRISC (which is LGPL), vs. RISC-V (which is BSD).
jkot 11y ago
I believe OpenSPARC is a bit slow, this could be faster.
FullyFunctional 11y ago
Lots have been written about that, but this might be a good starting point: http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-14..., but read also the spec (http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62...) and pay attention to the footnotes. IMO, compared to OpenSPARC, this is a fresh design that leverages lessons learned from everything that proceeded it. There are many problems with SPARC that makes it hard & expensive to scale up and down.

zhemao 11y ago

Hi, I'm a Ph.D. student at UC Berkeley on the RISC-V team. Happy to answer any questions about the RISC-V ISA or Rocket, our open-source reference implementation. Since there's always confusion about it, I'll start off by clarifying the difference between the two. RISC-V is an open-source ISA standard. Rocket is an implementation of this ISA which also happens to be open source. We do not intend for the ISA to be tied to a single reference implementation. The intention for RISC-V is to enable many different implementations (whether open-source or proprietary). These different implementations can all run an open-source software ecosystem, which currently consists of a GNU toolchain, LLVM, and Linux kernel port.

1ris 11y ago
Great! I heard somewhere here on HN that a modern x86 decoder is smaller than a modern arm decoder. Do you know if this is true? Also, how big is the decoder of risc-v and does it even matter? (I mean the size)
- zhemao 11y ago
  > a modern x86 decoder is smaller than a modern arm decoder That's because the ARM ISA is not small either by any stretch of the imagination. On the other hand, the instruction listing of the base RISC-V ISA and the standard extensions can fit on a single powerpoint slide. http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2015.pdf http://riscv.org/workshop-jun2015/riscv-intro-workshop-june2... I wasn't involved in any of the recent tape-outs, so I can't say exactly how big the decoder is. But it's quite small relative to the other chip components. Currently, the integer pipeline of the chip is roughly the same size as the FPU, and these two together are roughly the same size as the L1 cache. All of those components together are smaller than the L2 cache (depends on the size of the L2 cache, though). So decoder size doesn't really matter in the grand scheme of things. Decoder speed probably does matter, though. Currently, we can decode an instruction in a single cycle (1 ns). The x86 decoder, on the other hand, can take multiple cycles depending on instruction. But maybe this isn't a fair comparison since the instructions are decomposed into uops. I have no idea about the performance of ARM decoders.

mwcampbell 11y ago

I wonder what Google, HP, and Oracle are planning to do with RISC-V. Will RISC-V-based chips be able to compete with Intel in the server market? Incidentally, I think the first consumer devices to adopt RISC-V will be home wireless routers, because the stock firmwares for those are closed, so they'll just need to be recompiled with a new toolchain. And those devices don't need a GPU.

zhemao 11y ago
We do expect embedded systems to be the main use of RISC-V processors at the outset. In fact, I believe there is a consumer product out now - some kind of camera - which uses a RISC-V processor. I don't think we'll be able to compete with Intel's x86 chips for a while. Mostly because Intel's silicon processes are more advanced than those offered by other foundries.
- aurhum 11y ago
  The AXIOM, a 4K camera uses a RISC-V http://riscv.org/workshop-jan2016.html http://riscv.org/workshop-jan2016.html
asb 11y ago
I agree that the easiest entry-point for RISC-V is in systems which run embedded firmware of some sort (even if it's a builroot Linux rootfs). Even before you get to that, there are loads of companies that still have their own home-grown instruction sets used for auxilliary functions on a larger core. Think peripherals on an SoC, SSD controllers and so on.
mtgx 11y ago
Well, it may be easier to offer an open source RISC-V processor in products, but it's certainly not necessary. From Wikipedia: > The RISC-V authors aim to provide several freely available CPU designs, under a BSD license. This license allows derivative works such as RISC-V chip designs to be either open and free like RISC-V itself, or closed and proprietary, (unlike the available OpenRISC cores, which under the GPL, requires that all derivative works also be open and free). https://en.wikipedia.org/wiki/RISC-V https://en.wikipedia.org/wiki/RISC-V So if it's not GPL, such as OpenRISC, then it's not guaranteed to be fully open source. You could still have 99% of the chip as open source and the other 1% as the proprietary backdoor.

bitwize 11y ago

I wonder what the copyright license terms on Oracle's proprietary ISA extensions will be...

Const-me 11y ago

I wonder how are they going to compete with Intel? I don’t see how they’re going to match raw performance against those 1tflops+ 20-cores xeons. I don’t see how they’re going to match performance/watt against 7w quad-core C2338. I don’t see how they’re going to match price against $20 x5-Z8300. If none of the above, then why should Google/HP/Oracle/anyone else buy that?

mtgx 11y ago
Maybe they think the more Intel conquers the markets it's in, the less competitive it will be performance/price-wise - like say how it replaced its $110 Core-based Celeron chips for Atom chips with half the performance and almost no extra "features" that also cost $110, because it knows people will keep buying "Intel" in the PC market and are not even giving AMD a second look now. It surely helped when Microsoft killed Windows RT and eliminated the ARM competition from the market for the foreseeable future. Maybe these RISC-V chips will never get out of the labs of Google, but they could still serve to force Intel to keep prices the same on its new generations in the future, unless they want Google to really get serious about making its own chips.
- Const-me 11y ago
  “how it replaced its $110 Core-based Celeron chips for Atom chips” — they already reverted that decision. Latest Celerons 3855U, 3955U are Skylake i.e. 6th generation Core chips.
jeffbush 11y ago
I don't think they need to compete with Intel. The numbers I've seen suggests Intel ships around 300-400 Million processors per year[1]. In 2014, 12 Billon (with a B) devices with ARM cores shipped[2]. In 2011, around 500 Million MIPS based cores shipped[3]. These are obviously very different businesses. But it's clear there is an enormous market for licensable low-end IP cores that are used in everything from cars, cable boxes, TVs, cellphones (many phones have multiple cores internally to operate functions like the cellular baseband), etc. Most of the licensees are just gluing together licensed cores and contracting foundries like TSMC or Global Foundries to build them. The margins tend to be pretty thin (we're talking chips that are in the single digits for cost), so saving a little money on IP licensing is attractive. Since these are often custom applications, binary compatibility is less of an issue. That seems like a more interesting market for an open ISA and open core processors. [1] http://www.ft.com/cms/s/0/beff6e56-53ed-11e4-80db-00144feab7de.html#axzz3wFGbKjgu http://www.ft.com/cms/s/0/beff6e56-53ed-11e4-80db-00144feab7... [2] https://atlas.qz.com/charts/Ek18VmbP https://atlas.qz.com/charts/Ek18VmbP [3] http://www.forbes.com/forbes/2011/0509/technology-mips-sandeep-vij-dvd-micro-chips-less-more.html http://www.forbes.com/forbes/2011/0509/technology-mips-sande...

tbirdz 11y ago

How does RISC-V compare with the J2 core based on the SuperH architecture by the Open Processor Foundation[1]? 1: http://0pf.org/ http://0pf.org/

asb 11y ago
I answered a similar (but slightly different) question here: https://lobste.rs/s/jmgsyl/untethered_lowrisc_release/comments/ng761j#c_ng761j https://lobste.rs/s/jmgsyl/untethered_lowrisc_release/commen..., comparing lowRISC and the Open Processor Foundation.

thebeardisred 11y ago

Obligatory: ¨RISC architecture is going to change everything¨ - https://arikia.files.wordpress.com/2013/02/test2.gif?w=625 https://arikia.files.wordpress.com/2013/02/test2.gif?w=625

chei0aiV 11y ago

I wonder if HP are looking at RISC-V/lowRISC for their "The Machine" project.

deleted 11y ago

[deleted]

fmarch 11y ago

Has any one created a verification infrastructure with any of RISC-V implementations? The git repository does have a set of tests and benchmarks but could not find any thing more than that.

gluggymug 11y ago
Check out : https://github.com/ucb-bar/rocket-chip https://github.com/ucb-bar/rocket-chip Last time I complained here about the verification infrastructure of this project, someone gave that link. I didn't like much of what I could find there. What exactly are you trying to do?
- fmarch 11y ago
  I want to at the minimum compare the architectural state of the implementation on every retire with the ISA simulator (Spike). In addition it would be good to have a set of assertions to maintain the sanity (read functional correctness) while experimenting with the design. How are these implementations verified right now ? All I see are few assertions in chisel and small set of tests.
  - _chris_ 11y ago
    You can get a commit log (PC, inst, write-back address, write-back data) from Rocket to compare against Spike's commit log. It's not documented because the verification story is still in flux, and the commit log is fairly manual (since there will be many false positives). Comparing a real CPU against an ISA simulator is VERY HARD. There's counter instructions, there's interrupts, timers will differ, multi-core will exhibit different (correct) answers, Rocket has out-of-order write-back+early commit, floating point registers are 65-bit recoded values, some (required) ambiguity in the spec that can't be reconciled easily (e.g., storing single-precision FP values using FSD puts undefined values in memory, the only requirement being that the value is properly restored by a corresponding FLD). We also use a torture tester that we'll open source Soon (tm).
    - 11y ago