5 ms·

RISC-V: An Open Standard for SoCs

52 points by apw 12y ago

microcolonel 12y ago
RISC-V is looking very hopeful, I hope I can get in on some chips soon.
wmf 12y ago
Related recent discussion about an in-progress implementation: https://news.ycombinator.com/item?id=8137521 https://news.ycombinator.com/item?id=8137521
filereaper 12y ago
I can understand RISC-V's use in academic settings or if you truly want open hardware. But what's the commercial benefit? Its an open core, its lacking patents because the performance critical aspects have been patented by others in their designs, so how does this stack up in terms of performance? Can you make a processor design as fast as proprietary ones like the Linux effort? Second comes the issue of fabrication, is there somebody ready to fab this? Or are you just going to throw this on a large FPGA? If you're throwing it on a FPGA, then why take jabs at the other ISA's when you'll be running this on non-open proprietary sillicon anyways. Lastly, who cares? I'm guessing embedded is out as they care out the cost of each chip, the cheaper and more performant the better. Perhaps you're running something mission critical or are totally tied to a architecture, but then you're a dinosaur, the industry's trending towards abstracting the hardware away anyways. Do you really care which piece of sillicon your app runs on? All of the above's probably really biased, misguided and wrong, but I'd like to hear what other HN'ers have to say.
- indeyets 12y ago
  their F.A.Q. states that they expect performance not worse than ARM, which sounds like a dealbreaker (there wasn't anything similar in OpenCore movement like… ever!). Fabrication: these guys do it http://www.lowrisc.org/ http://www.lowrisc.org/ and don't forget about chinese production companies who use custom MIPS now — this is a great altarnative for them. Actually, this applies to any government which needs verifiable hardware non-tampered by NATO
- mpoloton 12y ago
  I think Open ISAs such as SPARC, OpenRISC and RISCV and their related ecosystems and tools provide the following opportunities: -Educational: Engaging more people in hardware design and creating a much bigger community who can understand and design complex systems without the need to start from scratch. Moreover, a larger community leads to the improvements and maturity quicker than propriety solutions. -Commercial: I agree that they may not be able to compete with proprietary solutions in few applications in near future. However, in many applications the combination of open ISAs and proprietary solution enable faster customization and development time. A good example is NavSpark/Venus (http://navspark.mybigcommerce.com/ http://navspark.mybigcommerce.com/), a GNSS solution based on Leon3 with an attractive price and competitive features comparable to the state of the art. -Security: As mentioned by others
modeless 12y ago
Looks cool! Disappointed that there's no option to trap on integer overflow. Languages don't support it because processors don't support it, and processors don't support it because languages don't require it; a vicious cycle that someone needs to break.
- thesz 12y ago
  Most of the time you don't need integer overflow. When you need it, you can insert a check. I consider integer addition commands in MIPS a mistake. They take up CPU real estate, they slow down design and in the end they are not even used! The handling of division overflow in MIPS is more fair. If you can have a division that may iverflow, compiler inserts a check. Resources are wasted only here, not everywhere.
  - modeless 12y ago
    I'm going to assume you meant "most of the time you don't need integer overflow checks", because that makes more sense with the rest of your comment. I couldn't disagree more. If you look at real programs, overflow would be a bug for the vast majority of the integer arithmetic instructions. Therefore overflow checking should be the default. Wraparound overflow is sometimes useful and should be available but it should not be the default. For example, http://www.cs.utah.edu/~regehr/papers/overflow12.pdf http://www.cs.utah.edu/~regehr/papers/overflow12.pdf finds that there are ~200 instances of overflowing integer arithmetic instructions in all of SPEC CINT2000 (many of which are bugs). Every other integer arithmetic instruction in SPEC CINT2000 (orders of magnitude more than 200, of course) should never overflow; overflow would definitely be a bug and overflow checks would be useful in catching such bugs. See http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154 for a more complete argument. I really hope that if an ISA really does become "the standard ISA for all computing devices" as RISC-V aspires to, that it supports integer overflow traps.
userbinator 12y ago
The widening gap between memory and core speeds suggests to me that traditional RISC philosophy is not the way forward for performance and efficiency; fixed-length instructions, load-store restrictions, and delay slots may make implementation easier and faster at a time when memory could keep up with the CPU and instruction decoding was the bottleneck, but now that memory is often the bottleneck, it makes sense to have more complex, dense instruction encoding and the other features that are usually left out of RISCs, but improve code density. Variable-length instructions are especially beneficial to code density, since often-used instructions can be encoded in fewer bytes, leaving rarer ones to longer sequences. It also allows for easy extension. Relaxing the restriction on only load/store instructions being able to access memory can reduce code size by eliminating many instructions whose sole purpose is to move data between memory and registers; this also leads to requiring fewer explicitly named registers (since instructions reading memory will implicitly name an internal temporary register(s) the CPU can use), reducing the number of bits needed to specify registers. Other considerations like number of operands and how many of them can be memory references also contribute to code density - 0- and 1-operand ISAs require far more instructions for data movement, while 3-operand ISAs may waste encoding space if much of the time, one source operand does not need to be preserved. 2 operands is a natural compromise, and this is what e.g. ARM Thumb does. This is why I find the description of "compressed RISC-V" linked in the article ( http://www.eecs.berkeley.edu/~waterman/papers/ms-thesis.pdf http://www.eecs.berkeley.edu/~waterman/papers/ms-thesis.pdf ) interesting - benchmark analysis shows that 8 registers are used 60% of the time, and 2-operand instructions are encountered 36/31% statically/dynamically. These characteristics are not so far from those of an ISA that has remained one of the most performant for over 2 decades: x86. It's a denser ISA than regular RISCs, and requires more complex decoding, but not as complex as e.g. VAX. I think the decision to have 8 architectural registers and a 2-operand/1-memory format put x86 in an interesting middle-ground where it wasn't too CISC to implement efficiently, but also wasn't RISC enough to suffer its drawbacks. I'd certainly like to see how an open-source x86 implementation could perform in comparison.
- comex 12y ago
  > Variable-length instructions are especially beneficial to code density, since often-used instructions can be encoded in fewer bytes, Speaking of this, I find it interesting that ARM went back to a fixed 32-bit instruction width for ARMv8 (from 16/32 in Thumb-2). Any idea why they chose to do this?
bsder 12y ago
The dirty secret is: nobody cares because the ISA doesn't matter. When programming a modern microcontroller, I regularly think: "Gee, I wish I had more pins." "Gee, I wish I had documentation on that peripheral." "Gee, I wish I had better tool support." or "Gee, I wish I had more RAM/Flash/MHz." I never think "Gee, I wish I had a better ISA". I applaud the effort to make an open microprocessor especially in light of the increasing efforts to put trusted module crap in our computers. However, this has no commercial advantage in any way other than that.
- krasin 12y ago
  In this case, an open ISA would allow more stability over time. More over, once we have an open and widely adopted ISA, one can build an open microcontroller. After that, embedded developers will stop getting bad surprises when some specific microcontroller is being deprecated / out of stock and the whole board (and likely large parts of the firmware) has to be redesigned. And you're right: an ISA don't matter. It could be ARM, AVR or OpenRISC / RISC-V, but it's very desirable to be stable and embeddable into a SoC without purchasing additional licenses.
- gioele 12y ago
  > I never think "Gee, I wish I had a better ISA". After programming with AltiVec, going back to MMX/SSE made me wish I had a better ISA.
- renox 12y ago
  > The dirty secret is: nobody cares because the ISA doesn't matter. I disagree!! While normal operations don't matter, think about features like 'trap on integer overflow', if it was widespread in the popular ISAs we would have language which would use this semantic and as a result less bugs. Another interesting feature could be Azul's Vega realtime GC support but I don't know if this requires a change of the ISA, or if it's just a MMU feature.. Hardware capabilities/segmentation would also require support in the ISA. That said I agree with you that the RISC-V is just 'yet another ISA' which doesn't have interesting technical features, it's main feature is that it is open and you can implement it without paying someone for the privilege.
jaekwon 12y ago
If there were a fully open hardware/software machine, I would give it all of my money.* *Of budget allocated for purchasing computing devices.

52 points by apw 12y ago

RISC-V is looking very hopeful, I hope I can get in on some chips soon.

wmf 12y ago

Related recent discussion about an in-progress implementation: https://news.ycombinator.com/item?id=8137521 https://news.ycombinator.com/item?id=8137521

filereaper 12y ago

I can understand RISC-V's use in academic settings or if you truly want open hardware. But what's the commercial benefit? Its an open core, its lacking patents because the performance critical aspects have been patented by others in their designs, so how does this stack up in terms of performance? Can you make a processor design as fast as proprietary ones like the Linux effort? Second comes the issue of fabrication, is there somebody ready to fab this? Or are you just going to throw this on a large FPGA? If you're throwing it on a FPGA, then why take jabs at the other ISA's when you'll be running this on non-open proprietary sillicon anyways. Lastly, who cares? I'm guessing embedded is out as they care out the cost of each chip, the cheaper and more performant the better. Perhaps you're running something mission critical or are totally tied to a architecture, but then you're a dinosaur, the industry's trending towards abstracting the hardware away anyways. Do you really care which piece of sillicon your app runs on? All of the above's probably really biased, misguided and wrong, but I'd like to hear what other HN'ers have to say.

indeyets 12y ago
their F.A.Q. states that they expect performance not worse than ARM, which sounds like a dealbreaker (there wasn't anything similar in OpenCore movement like… ever!). Fabrication: these guys do it http://www.lowrisc.org/ http://www.lowrisc.org/ and don't forget about chinese production companies who use custom MIPS now — this is a great altarnative for them. Actually, this applies to any government which needs verifiable hardware non-tampered by NATO
mpoloton 12y ago
I think Open ISAs such as SPARC, OpenRISC and RISCV and their related ecosystems and tools provide the following opportunities: -Educational: Engaging more people in hardware design and creating a much bigger community who can understand and design complex systems without the need to start from scratch. Moreover, a larger community leads to the improvements and maturity quicker than propriety solutions. -Commercial: I agree that they may not be able to compete with proprietary solutions in few applications in near future. However, in many applications the combination of open ISAs and proprietary solution enable faster customization and development time. A good example is NavSpark/Venus (http://navspark.mybigcommerce.com/ http://navspark.mybigcommerce.com/), a GNSS solution based on Leon3 with an attractive price and competitive features comparable to the state of the art. -Security: As mentioned by others

modeless 12y ago

Looks cool! Disappointed that there's no option to trap on integer overflow. Languages don't support it because processors don't support it, and processors don't support it because languages don't require it; a vicious cycle that someone needs to break.

thesz 12y ago
Most of the time you don't need integer overflow. When you need it, you can insert a check. I consider integer addition commands in MIPS a mistake. They take up CPU real estate, they slow down design and in the end they are not even used! The handling of division overflow in MIPS is more fair. If you can have a division that may iverflow, compiler inserts a check. Resources are wasted only here, not everywhere.
- modeless 12y ago
  I'm going to assume you meant "most of the time you don't need integer overflow checks", because that makes more sense with the rest of your comment. I couldn't disagree more. If you look at real programs, overflow would be a bug for the vast majority of the integer arithmetic instructions. Therefore overflow checking should be the default. Wraparound overflow is sometimes useful and should be available but it should not be the default. For example, http://www.cs.utah.edu/~regehr/papers/overflow12.pdf http://www.cs.utah.edu/~regehr/papers/overflow12.pdf finds that there are ~200 instances of overflowing integer arithmetic instructions in all of SPEC CINT2000 (many of which are bugs). Every other integer arithmetic instruction in SPEC CINT2000 (orders of magnitude more than 200, of course) should never overflow; overflow would definitely be a bug and overflow checks would be useful in catching such bugs. See http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154 for a more complete argument. I really hope that if an ISA really does become "the standard ISA for all computing devices" as RISC-V aspires to, that it supports integer overflow traps.

userbinator 12y ago

The widening gap between memory and core speeds suggests to me that traditional RISC philosophy is not the way forward for performance and efficiency; fixed-length instructions, load-store restrictions, and delay slots may make implementation easier and faster at a time when memory could keep up with the CPU and instruction decoding was the bottleneck, but now that memory is often the bottleneck, it makes sense to have more complex, dense instruction encoding and the other features that are usually left out of RISCs, but improve code density. Variable-length instructions are especially beneficial to code density, since often-used instructions can be encoded in fewer bytes, leaving rarer ones to longer sequences. It also allows for easy extension. Relaxing the restriction on only load/store instructions being able to access memory can reduce code size by eliminating many instructions whose sole purpose is to move data between memory and registers; this also leads to requiring fewer explicitly named registers (since instructions reading memory will implicitly name an internal temporary register(s) the CPU can use), reducing the number of bits needed to specify registers. Other considerations like number of operands and how many of them can be memory references also contribute to code density - 0- and 1-operand ISAs require far more instructions for data movement, while 3-operand ISAs may waste encoding space if much of the time, one source operand does not need to be preserved. 2 operands is a natural compromise, and this is what e.g. ARM Thumb does. This is why I find the description of "compressed RISC-V" linked in the article ( http://www.eecs.berkeley.edu/~waterman/papers/ms-thesis.pdf http://www.eecs.berkeley.edu/~waterman/papers/ms-thesis.pdf ) interesting - benchmark analysis shows that 8 registers are used 60% of the time, and 2-operand instructions are encountered 36/31% statically/dynamically. These characteristics are not so far from those of an ISA that has remained one of the most performant for over 2 decades: x86. It's a denser ISA than regular RISCs, and requires more complex decoding, but not as complex as e.g. VAX. I think the decision to have 8 architectural registers and a 2-operand/1-memory format put x86 in an interesting middle-ground where it wasn't too CISC to implement efficiently, but also wasn't RISC enough to suffer its drawbacks. I'd certainly like to see how an open-source x86 implementation could perform in comparison.

comex 12y ago
> Variable-length instructions are especially beneficial to code density, since often-used instructions can be encoded in fewer bytes, Speaking of this, I find it interesting that ARM went back to a fixed 32-bit instruction width for ARMv8 (from 16/32 in Thumb-2). Any idea why they chose to do this?

bsder 12y ago

The dirty secret is: nobody cares because the ISA doesn't matter. When programming a modern microcontroller, I regularly think: "Gee, I wish I had more pins." "Gee, I wish I had documentation on that peripheral." "Gee, I wish I had better tool support." or "Gee, I wish I had more RAM/Flash/MHz." I never think "Gee, I wish I had a better ISA". I applaud the effort to make an open microprocessor especially in light of the increasing efforts to put trusted module crap in our computers. However, this has no commercial advantage in any way other than that.

krasin 12y ago
In this case, an open ISA would allow more stability over time. More over, once we have an open and widely adopted ISA, one can build an open microcontroller. After that, embedded developers will stop getting bad surprises when some specific microcontroller is being deprecated / out of stock and the whole board (and likely large parts of the firmware) has to be redesigned. And you're right: an ISA don't matter. It could be ARM, AVR or OpenRISC / RISC-V, but it's very desirable to be stable and embeddable into a SoC without purchasing additional licenses.
gioele 12y ago
> I never think "Gee, I wish I had a better ISA". After programming with AltiVec, going back to MMX/SSE made me wish I had a better ISA.
renox 12y ago
> The dirty secret is: nobody cares because the ISA doesn't matter. I disagree!! While normal operations don't matter, think about features like 'trap on integer overflow', if it was widespread in the popular ISAs we would have language which would use this semantic and as a result less bugs. Another interesting feature could be Azul's Vega realtime GC support but I don't know if this requires a change of the ISA, or if it's just a MMU feature.. Hardware capabilities/segmentation would also require support in the ISA. That said I agree with you that the RISC-V is just 'yet another ISA' which doesn't have interesting technical features, it's main feature is that it is open and you can implement it without paying someone for the privilege.

jaekwon 12y ago

If there were a fully open hardware/software machine, I would give it all of my money.* *Of budget allocated for purchasing computing devices.