10 ms·

Does anybody have informed opinions about the future of RISC-V? The pace of development in the space seems frantic (though early) and the IP situation seems lik

by bane 5y ago

Does anybody have informed opinions about the future of RISC-V? The pace of development in the space seems frantic (though early) and the IP situation seems like it's ripe to eventually become a major force in processor ISAs.

mhh__ 5y ago
I'm optimistic but not particularly bothered as long as X86 goes the way of the dodo i.e. people have argued that ARM could be the better ISA for the processor in your laptop. One thing that we will have to see about is whether the extension model they have now actually holds in the future e.g. will we see a high performance fork of RISCV in the future, or simply (say) a chinese-only company who don't particularly care using parts of the instruction encoding space for their own purposes.
- cable2600 5y ago
  It is the Post-X86 era now. That doesn't mean that X86 is gone, it means that alternatives to it exist and are on the rise.
  - pjmlp 5y ago
    Alternatives always existed, and if AMD did not had a license to produce X86 clones, they would have been gone already.
    - ngcc_hk 5y ago
      Such a surprise but so true as well.
- FullyFunctional 5y ago
  High performance RISC-V is orthogonal to those extensions. There is nothing stopping an M1-class implementation with the existing ISA.
  - nine_k 5y ago
    Does e.g. the memory model allow for a highly parallel architecture, with a ton of execution units and possible OoO execution? If it does, would it be a pain to program for (see Cell)?
    - FullyFunctional 5y ago
      Yes. By design (1), RISC-V removes much of what makes OoO harder. Most instructions have very regular and clean semantics, communicating only through registers, with a straight forward [up to] two register operands, at-most one destination. The memory model by default is the same as Arms, a fairly weak model. Basically code that works on Arm will port over trivially (vector and special functions excluded). (1) Unfortunately compressed instructions were included in the Unix profile which causes a lot of pain and makes it mostly impossible to do any partial predecode at I$ fill time. Ironically Arm64 wised up and removed the Thumb variants. (Preempting the code density crowd: there are other ways to deal with this). EDIT: Pain includes dealing with instructions that crosses cacheline or even page boundaries (hello double fault), but worse, not being able to tell what might be an instruction in the I$. It was a sad day when RISC-V with essentially no input from the higher-end concerns decided to force it on us.
      - brucehoult 5y ago
        That only applies if you want to run binary distros and applications such as Fedora or Ubuntu. If you're running a supercomputer and don't want to implement the C extension then you can build your own kernel and programs. If you do that then anything from RV32IA and up can be used. You can also use a QEMU or Valgrind-like thing to JIT the C away. Or you can do what modern x86 does and annotate your cache lines the first time they are actually decoded instead of at cache fill time. That's just a little slower for cold code but the same for hot code. Having the C extension keeps 40% more of your code hot for any given cache size. There might be some implementation point at which Aarch64 wins by having bigger but fixed length code, but it's not at the low end and I don't think it's at the very high end either.
  - mhh__ 5y ago
cable2600 5y ago
Main challengers is the ARM CPU line. I can see China making RISC-V chips for Microwaves and TV sets and mobile devices.
pjmlp 5y ago
I think people are too optimistic, even if it ever manages ARM adoption scale, nothing prevents OEMs to ship their RISC-V implementation with proprietary extensions. Dreamers gotta dream I suppose.
- rwmj 5y ago
  It's already happened unfortunately - looking at you Kendryte.
- avianes 5y ago
  But that's not a problem at all. It still guarantees that a program compiled for RISC-V will run on this CPU. Moreover, they have no motivation to introduce too many non standard/proprietary extensions as it would require them to add support for these new instructions in mainstream compilers, while they could - with standard extensions - take advantage of the work already done for standard extensions. Today, a major difficulty a newcomer to the industry faces is that they have 2 options: 1 - Taking an existing ISA and paying a license fee, but benefiting from the work already done on the compiler side. or 2 - Building their own new ISA for free, but having to do all the work on the compiler side by themselves from scratch. With RISC-V this problem does not exist anymore which opens the door to newcomers.
  - pjmlp 5y ago
    Like UNIX workstation wars won by NeXTSTEP in the end, come for POSIX (RISC-V in this case) compatibility, stay for the extensions.
    - avianes 5y ago
      Hardware and Software have very different dynamics, therefore the comparison with POSIX is very weak. There is no way today to build competitive opensource hardware, and RISC-V is not about providing opensource hardware. With RISC-V (or any other ISA) we remain mainly dependent on the manufacturer who implement whatever they want within your processor. I think you are expecting too much from RISC-V, it's not about winning a war against manufacturers, it's about providing a royalty-free high-performance standard ISA which makes it easier for newcomers to enter the market. RISC-V is built around the idea that manufacturers can make their own non-standard extensions and benefit from existing work.
audunw 5y ago
What I’ve seen is that a product is being designed with both ARM and RISC-V cores. The RISC-V cores outperformes the equivalent ARM cores and have no licensing costs. It’s used if it’s a management core not usually programmed by the customer or specialized low power and/or low latency processing. The ARM cores are used for TrustZone, FPU and DSP functionality and for the extensive IDE, debugging and trace support. I can see RISC-V gradually taking over, since it now has a foot in the door. But it’ll take a long time and depends on third party development.
ksec 5y ago
> eventually become a major force in processor ISAs. In what market segment? Will RISC-V win a substantial market shares in embedded / micro- controller usage? Very likely. It is sort of started happening already. Will RISC-V wins over a substantial market in current x86-64 and ARMv8 segment. Highly Unlikely. I have seen zero argument or proposition that even make sense for this to happen. Other than people want it or certain country want it for whatever ideology reason.
- nine_k 5y ago
  I suspect that building a CPU from scratch, without a ton of legacy, may allow for greater efficiency, both per watt and in absolute speed. This is how RISC-V designs can percolate from embedded world to laptop and even datacenter world, much like ARM did before it.
  - ksec 5y ago
    >I suspect that building a CPU from scratch Or you mean designing an ISA from scratch? Which is precisely what ARM have done to ARMv8. And further refined in ARMv9.
    - brucehoult 5y ago
      Except it's not really from scratch. While we are starting to see A64-only cores, A64 was obviously designed to run on the same cores that also run A32/T32 code. There are A32 features that A64 carries over which no one else in the 35 years of RISC ISA design since 1985 has seen fit to copy -- the optional shift/rotate of one ALU operand being the obvious one. Would they really have done that if it was a clean sheet design? If it's so great, why hasn't anyone else done it? Also no other clean sheet ISA designed for high performance since 1990 (it's a short list: DEC Alpha, Intel Itanium, RISC-V) has included condition codes. Even POWER acknowledges that a single condition code register is a bad idea and has eight of them instead (the others just use integer registers to hold long-lived conditions).
ansible 5y ago
In general it has a bright future. It is not nearly as revolutionary as, for example, the Mill CPU by Out Of the Box Computing, but it does have some refinements from all the lessons learned over the decades of ISA design. As more designs get produced, there will be more and more pressure on the chip designers to stick to the published specifications, instead of going their own way. Why? Because everyone will want to just use the existing toolchains (GCC, LLVM, etc.) and not have to support proprietary extensions. It helps that the specs themselves are easily available. The implementations that exist now are not at the leading edge of performance, but they are more than good enough for many applications. This will improve over time. One of the best features of the ISA is the design for extensions... meaning that extensions were planned from the very beginning. Unlike other architectures, where often the ISA is designed to be "complete", and adding extensions inevitably becomes difficult, expensive (cost or run-time performance, or both), or complex (which slows adoption).
geeB 5y ago
My opinion is not informed, but from my point of view the opposite is true. It's been 10 years since the first specs and silicon, according to https://riscv.org/about/history/ https://riscv.org/about/history/. And it seems that one has to go way out of their way to find RISC-V systems in the wild.
- brucehoult 5y ago
  It's ten years since the idea occurred to start a new design. The first silicon with the final ISA design (or at least RV32IMAC) was the FE310 which shipped on the HiFive1 in December 2016, less than five years ago. It takes up to two years to go from RTL working in verilator or on an FPGA to manufactured chips on boards in shops. RISC-V is all over the place in deep embedded. Samsung announced that their 2020 high end phones have RISC-V cores controlling the camera and also the 5G radio. Qualcomm is using RISC-V in their 5G. The very popular ESP32 series of WIFI/BT chips is switching to RISC-V, with the last three (?) models being either partially or fully RISC-V instead of Xtensa. The last several months have seen announcements of startups who have chip designers from Intel, AMD, and Apple's M1 team and who are now working on *lake/Zen/M1-class RISC-V designs. Those will of course take maybe three or four years to appear on the market, but there is zero reason to think they won't be technically successful.

by bane 5y ago

mhh__ 5y ago

I'm optimistic but not particularly bothered as long as X86 goes the way of the dodo i.e. people have argued that ARM could be the better ISA for the processor in your laptop. One thing that we will have to see about is whether the extension model they have now actually holds in the future e.g. will we see a high performance fork of RISCV in the future, or simply (say) a chinese-only company who don't particularly care using parts of the instruction encoding space for their own purposes.

cable2600 5y ago
It is the Post-X86 era now. That doesn't mean that X86 is gone, it means that alternatives to it exist and are on the rise.
- pjmlp 5y ago
  Alternatives always existed, and if AMD did not had a license to produce X86 clones, they would have been gone already.
  - ngcc_hk 5y ago
    Such a surprise but so true as well.
FullyFunctional 5y ago
High performance RISC-V is orthogonal to those extensions. There is nothing stopping an M1-class implementation with the existing ISA.
- nine_k 5y ago
  Does e.g. the memory model allow for a highly parallel architecture, with a ton of execution units and possible OoO execution? If it does, would it be a pain to program for (see Cell)?
  - FullyFunctional 5y ago
    Yes. By design (1), RISC-V removes much of what makes OoO harder. Most instructions have very regular and clean semantics, communicating only through registers, with a straight forward [up to] two register operands, at-most one destination. The memory model by default is the same as Arms, a fairly weak model. Basically code that works on Arm will port over trivially (vector and special functions excluded). (1) Unfortunately compressed instructions were included in the Unix profile which causes a lot of pain and makes it mostly impossible to do any partial predecode at I$ fill time. Ironically Arm64 wised up and removed the Thumb variants. (Preempting the code density crowd: there are other ways to deal with this). EDIT: Pain includes dealing with instructions that crosses cacheline or even page boundaries (hello double fault), but worse, not being able to tell what might be an instruction in the I$. It was a sad day when RISC-V with essentially no input from the higher-end concerns decided to force it on us.
    - brucehoult 5y ago
      That only applies if you want to run binary distros and applications such as Fedora or Ubuntu. If you're running a supercomputer and don't want to implement the C extension then you can build your own kernel and programs. If you do that then anything from RV32IA and up can be used. You can also use a QEMU or Valgrind-like thing to JIT the C away. Or you can do what modern x86 does and annotate your cache lines the first time they are actually decoded instead of at cache fill time. That's just a little slower for cold code but the same for hot code. Having the C extension keeps 40% more of your code hot for any given cache size. There might be some implementation point at which Aarch64 wins by having bigger but fixed length code, but it's not at the low end and I don't think it's at the very high end either.
- mhh__ 5y ago

cable2600 5y ago

Main challengers is the ARM CPU line. I can see China making RISC-V chips for Microwaves and TV sets and mobile devices.

pjmlp 5y ago

I think people are too optimistic, even if it ever manages ARM adoption scale, nothing prevents OEMs to ship their RISC-V implementation with proprietary extensions. Dreamers gotta dream I suppose.

rwmj 5y ago
It's already happened unfortunately - looking at you Kendryte.
avianes 5y ago
But that's not a problem at all. It still guarantees that a program compiled for RISC-V will run on this CPU. Moreover, they have no motivation to introduce too many non standard/proprietary extensions as it would require them to add support for these new instructions in mainstream compilers, while they could - with standard extensions - take advantage of the work already done for standard extensions. Today, a major difficulty a newcomer to the industry faces is that they have 2 options: 1 - Taking an existing ISA and paying a license fee, but benefiting from the work already done on the compiler side. or 2 - Building their own new ISA for free, but having to do all the work on the compiler side by themselves from scratch. With RISC-V this problem does not exist anymore which opens the door to newcomers.
- pjmlp 5y ago
  Like UNIX workstation wars won by NeXTSTEP in the end, come for POSIX (RISC-V in this case) compatibility, stay for the extensions.
  - avianes 5y ago
    Hardware and Software have very different dynamics, therefore the comparison with POSIX is very weak. There is no way today to build competitive opensource hardware, and RISC-V is not about providing opensource hardware. With RISC-V (or any other ISA) we remain mainly dependent on the manufacturer who implement whatever they want within your processor. I think you are expecting too much from RISC-V, it's not about winning a war against manufacturers, it's about providing a royalty-free high-performance standard ISA which makes it easier for newcomers to enter the market. RISC-V is built around the idea that manufacturers can make their own non-standard extensions and benefit from existing work.

audunw 5y ago

What I’ve seen is that a product is being designed with both ARM and RISC-V cores. The RISC-V cores outperformes the equivalent ARM cores and have no licensing costs. It’s used if it’s a management core not usually programmed by the customer or specialized low power and/or low latency processing. The ARM cores are used for TrustZone, FPU and DSP functionality and for the extensive IDE, debugging and trace support. I can see RISC-V gradually taking over, since it now has a foot in the door. But it’ll take a long time and depends on third party development.

ksec 5y ago

> eventually become a major force in processor ISAs. In what market segment? Will RISC-V win a substantial market shares in embedded / micro- controller usage? Very likely. It is sort of started happening already. Will RISC-V wins over a substantial market in current x86-64 and ARMv8 segment. Highly Unlikely. I have seen zero argument or proposition that even make sense for this to happen. Other than people want it or certain country want it for whatever ideology reason.

nine_k 5y ago
I suspect that building a CPU from scratch, without a ton of legacy, may allow for greater efficiency, both per watt and in absolute speed. This is how RISC-V designs can percolate from embedded world to laptop and even datacenter world, much like ARM did before it.
- ksec 5y ago
  >I suspect that building a CPU from scratch Or you mean designing an ISA from scratch? Which is precisely what ARM have done to ARMv8. And further refined in ARMv9.
  - brucehoult 5y ago
    Except it's not really from scratch. While we are starting to see A64-only cores, A64 was obviously designed to run on the same cores that also run A32/T32 code. There are A32 features that A64 carries over which no one else in the 35 years of RISC ISA design since 1985 has seen fit to copy -- the optional shift/rotate of one ALU operand being the obvious one. Would they really have done that if it was a clean sheet design? If it's so great, why hasn't anyone else done it? Also no other clean sheet ISA designed for high performance since 1990 (it's a short list: DEC Alpha, Intel Itanium, RISC-V) has included condition codes. Even POWER acknowledges that a single condition code register is a bad idea and has eight of them instead (the others just use integer registers to hold long-lived conditions).

ansible 5y ago

In general it has a bright future. It is not nearly as revolutionary as, for example, the Mill CPU by Out Of the Box Computing, but it does have some refinements from all the lessons learned over the decades of ISA design. As more designs get produced, there will be more and more pressure on the chip designers to stick to the published specifications, instead of going their own way. Why? Because everyone will want to just use the existing toolchains (GCC, LLVM, etc.) and not have to support proprietary extensions. It helps that the specs themselves are easily available. The implementations that exist now are not at the leading edge of performance, but they are more than good enough for many applications. This will improve over time. One of the best features of the ISA is the design for extensions... meaning that extensions were planned from the very beginning. Unlike other architectures, where often the ISA is designed to be "complete", and adding extensions inevitably becomes difficult, expensive (cost or run-time performance, or both), or complex (which slows adoption).

geeB 5y ago

My opinion is not informed, but from my point of view the opposite is true. It's been 10 years since the first specs and silicon, according to https://riscv.org/about/history/ https://riscv.org/about/history/. And it seems that one has to go way out of their way to find RISC-V systems in the wild.

brucehoult 5y ago
It's ten years since the idea occurred to start a new design. The first silicon with the final ISA design (or at least RV32IMAC) was the FE310 which shipped on the HiFive1 in December 2016, less than five years ago. It takes up to two years to go from RTL working in verilator or on an FPGA to manufactured chips on boards in shops. RISC-V is all over the place in deep embedded. Samsung announced that their 2020 high end phones have RISC-V cores controlling the camera and also the 5G radio. Qualcomm is using RISC-V in their 5G. The very popular ESP32 series of WIFI/BT chips is switching to RISC-V, with the last three (?) models being either partially or fully RISC-V instead of Xtensa. The last several months have seen announcements of startups who have chip designers from Intel, AMD, and Apple's M1 team and who are now working on *lake/Zen/M1-class RISC-V designs. Those will of course take maybe three or four years to appear on the market, but there is zero reason to think they won't be technically successful.