5 ms·

Their business model was to be sold to NVIDIA, but that didn't work out. Anyway, that's all well good, but - does anyone end up making decent RISC-V processors

Their business model was to be sold to NVIDIA, but that didn't work out. Anyway, that's all well good, but - does anyone end up making decent RISC-V processors that could replace a desktop CPU, or a RPi CPU, or something weaker but not in a small niche? Or is this still a vision for the future?

snvzz 5y ago
>does anyone end up making decent RISC-V processors that could replace a desktop CPU As of November, a large number of extensions got ratified, including the vector extension, cryptography acceleration, hypervisor support and other important features. RISC-V is finally not missing any important feature ARM or amd64 have, and it does it with an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) and with significantly higher code density. However, test chips with the first designs implementing all of that will take time, even assuming they were tapped out right then, after confirming no last minute changes. High performance cores depend on these extensions, so we'll begin to see them soon. We know multiple such efforts exist. Tenstorrent has one such project, led by Jim Keller. >Their (ARM) business model was to be sold to NVIDIA, but that didn't work out. They intend to go public now. I recommend against buying those shares, as I do not expect ARM to turn around.
- thetallstick 5y ago
  > with significantly higher code density. This is not correct and is a known weakness of RISC-V at the moment. The ARM toolchains are really good and have decades of improvements in them. This is a big issue for those who need to buy ROM in volume. Better tools are coming online though. For example: https://blog.segger.com/code-size-closing-the-gap-between-risc-v-and-arm-for-embedded-applications/ https://blog.segger.com/code-size-closing-the-gap-between-ri... "One of the issues faced by RISC-V developers is that the code density of the RISC-V instruction set for deeply embedded processors does not match that of Cortex-M with existing tools."
- posterboy 5y ago
  What remedie do you recommend against buying those shares, though?
- saagarjha 5y ago
  > RISC-V is finally not missing any important feature ARM or amd64 have, and it does it with an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) and with significantly higher code density. This has historically been a problem with RISC-V and it’s not really something you’ve backed up as being improved.
- inkyoto 5y ago
  > […] an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) […] I am not sure how to parse the «simpler, i.e. better» part; simplicity vs betterness is orthogonal at best and is contradictory at worst. Very few people write meticulously handcrafted, highly optimised code for any ISA today, and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Simplicity of the ISA does not immediately translate into faster or more optimised code. Moreover, creating a highly efficient optimiser is no easy feat as it depends on a large variety of factors and the in-depth knowledge of a specific CPU incarnation: the knowledge of each instruction's timing, instruction interdependencies (i.e. the most optimal instruction sequence that does not stall the pipeline or maximises the ALU/whatever utilisation etc etc), L1 I and D cache line sizes, the knowledge of a particular CPU model / generation… – and that is just a beginning. There is a good reason why Intel, AMD, IBM, ARM et al publish hefty optimisation guidelines / documents for each generation of their CPU's with the compiler writers in mind: the same sequence of instructions issued for the CPU model 123 might be less (or more) efficient than in the next CPU model 456 and vice versa; moreover (e.g. specifically for Intel vs AMD), a sequence of instructions optimised for a particular Intel generation might underperform for an equivalent AMD model or vice versa. Same is likely to be true for different RISC-V core designs from different RISC-V vendors. This is the reason why -mcpu=XXX and -mtune=YYY exist in GCC and clang/LLVM: efficient low-level code optimisation is a tricky business and depends on a large number of compounding factors. It remains to be seen how the optimisation will be tackled in the RISC-V case with its potpourri of optional ISA extensions and also with the instruction fusion. Given that a random concrete RISC-V implementation can be a combination of the base ISA + a random permutation of any RISC-V extensions (in the worst case scenario), emitting the code that will run equally efficient across N different RISC-V core designs appears to be problematic. Instruction fusion can pose another challenge as a fused macro-instruction may or may not run as efficiently on a RISC-V instance that does not fuse them. There is no guarantee that the compiler generated / optimised code will be equally highly performant across different implementations even for the same set of ISA extensions.
  - snvzz 5y ago
    >and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Itanium aka the Itanic demonstrated this is not the case.
vbezhenar 5y ago
There are rumours of Apple being interested with RISC-V. May be MacBook 2030 will feature it.
- snvzz 5y ago
  Apple posted job advertisements looking for RISC-V technical roles. What they plan to do with them is unknown, but Apple has the cash flow to try a lot of things. I would expect them to quickly adopt it for embedded applications, and experiment with making their own high performance design, including porting MacOS and Rosetta Stone. They can afford to do this much, regardless of whether they end up moving their main CPUs to RISC-V or not.
  - unfocussed_mike 5y ago
    Yep. There's surely a bunch of uses of RISC-V that have little or nothing to do with the main CPU, even in a conventional machine. Trust modules, device controllers, smart adapter cables etc.
  - jhickok 5y ago
    For what it's worth, Apple always has people on hand monitoring innovations in technology and testing their stack on new hardware, most of which never sees the light of day.
    - Macha 5y ago
      See OS X on Intel being a thing inside Apple for years and years before they decided it should see the light of day.
      - throwawayboise 5y ago
        NEXTSTEP was multi-architecture even before Apple owned it.
  - m463 5y ago
    I would imagine apple actually ships hundreds of devices with processors - each dongle and peripheral has at least one.
PaulHoule 5y ago
My take is that RISC-V is not that great of an architecture and might never compete at the high end. (e.g displace ARM, Intel, POWER, etc.) On the other hand there is a vast market for low-end CPUs that have specializations to be disk controllers and things like that. If the ISA and all the IP required to make specialized devices is free and particularly if there is a culture in which it is easy to learn how to do that then RISC-V will have a special place. My next spatial computing project is going to be RP 2040 based mostly because I have the parts in stock (other projects are blocked because of supply chain issues) but I am really an AVR8 fanatic and the only path forward I see to higher performance AVR8 systems is a soft core running on an FPGA where very hard tasks (vision? comms?) get offloaded to the FPGA and that can be a very appealing architecture where somebody might prefer RISC-V particularly if the tooling and accelerator integration are there.)
- zozbot234 5y ago
  > might never compete at the high end. (e.g displace ARM, Intel, POWER, etc.) It might also be successful, even in that segment. The RISC-V ISA was specifically designed to scale up (e.g. to OOO and vector processors) while still being very simple, especially at the low-end - a basic RV32E is really comparable in complexity with many real-world 8- and 16-bit chips.
  - jabl 5y ago
    The pretty minimal RV32EC core Ibex is estimated 15k gates: https://github.com/lowRISC/ibex https://github.com/lowRISC/ibex But, the similarly minimal Arm Cortex M0 is, drumroll, 12k gates. Not saying this means Arm is better than RISC-V, such a small difference can probably be explained by some microarchitectural feature or lack of it. Just that you can scale down Arm as well. But yes, I can see tiny chips like these putting a squeeze on 8 and 16 bit microcontrollers.
- snvzz 5y ago
  >My take is that RISC-V is not that great of an architecture That's not the impression I got, when I studied the specification. Do you care to elaborate?
rjsw 5y ago
Making a RPi equivalent would require a GPU with Linux support, I don't see any sign that RISC-V chip vendors are able to do this. Building a desktop system with a PCIe graphics card would be easier.
- Narishma 5y ago
  Isn't Imgtec doing that?
  - rjsw 5y ago
    Where can I get the source code for PowerVR kernel drm code from?
    - snvzz 5y ago
      https://www.phoronix.com/scan.php?page=news_item&px=Open-Source-PowerVR-Vulkan https://www.phoronix.com/scan.php?page=news_item&px=Open-Sou...
    - Narishma 5y ago
      Nowhere because it's not available yet. They only made a few announcements.
      - snvzz 5y ago
        This has since changed. They've released a DRM/DRI driver.
- ColonelPhantom 5y ago
  There actually exists at least one GPL-licensed GPU core (GPLGPU), but it's based on a 90s PC 3D accelerator that's really just not that good. I believe the team behind LibreSOC is also working on a 3D processor, but I don't know how far along they are. However, if a vendor instead ships a decent framebuffer and high-performance vector unit, I think LLVMpipe would not be a problem for most RPi-equivalent use cases, either light desktop use or server use (especially the latter!)
hajile 5y ago
Jim Keller's team is creating a 6-wide issue RISC-V CPU. It should have similar IPC as ARM X1 or AMD Zen 3. https://youtu.be/KOHQQyAKY14?t=494 https://youtu.be/KOHQQyAKY14?t=494
- Taniwha 5y ago
  here's an 8-issue design: https://moonbaseotago.github.io/ https://moonbaseotago.github.io/

snvzz 5y ago

>does anyone end up making decent RISC-V processors that could replace a desktop CPU As of November, a large number of extensions got ratified, including the vector extension, cryptography acceleration, hypervisor support and other important features. RISC-V is finally not missing any important feature ARM or amd64 have, and it does it with an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) and with significantly higher code density. However, test chips with the first designs implementing all of that will take time, even assuming they were tapped out right then, after confirming no last minute changes. High performance cores depend on these extensions, so we'll begin to see them soon. We know multiple such efforts exist. Tenstorrent has one such project, led by Jim Keller. >Their (ARM) business model was to be sold to NVIDIA, but that didn't work out. They intend to go public now. I recommend against buying those shares, as I do not expect ARM to turn around.

thetallstick 5y ago
> with significantly higher code density. This is not correct and is a known weakness of RISC-V at the moment. The ARM toolchains are really good and have decades of improvements in them. This is a big issue for those who need to buy ROM in volume. Better tools are coming online though. For example: https://blog.segger.com/code-size-closing-the-gap-between-risc-v-and-arm-for-embedded-applications/ https://blog.segger.com/code-size-closing-the-gap-between-ri... "One of the issues faced by RISC-V developers is that the code density of the RISC-V instruction set for deeply embedded processors does not match that of Cortex-M with existing tools."
posterboy 5y ago
What remedie do you recommend against buying those shares, though?
saagarjha 5y ago
> RISC-V is finally not missing any important feature ARM or amd64 have, and it does it with an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) and with significantly higher code density. This has historically been a problem with RISC-V and it’s not really something you’ve backed up as being improved.
inkyoto 5y ago
> […] an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) […] I am not sure how to parse the «simpler, i.e. better» part; simplicity vs betterness is orthogonal at best and is contradictory at worst. Very few people write meticulously handcrafted, highly optimised code for any ISA today, and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Simplicity of the ISA does not immediately translate into faster or more optimised code. Moreover, creating a highly efficient optimiser is no easy feat as it depends on a large variety of factors and the in-depth knowledge of a specific CPU incarnation: the knowledge of each instruction's timing, instruction interdependencies (i.e. the most optimal instruction sequence that does not stall the pipeline or maximises the ALU/whatever utilisation etc etc), L1 I and D cache line sizes, the knowledge of a particular CPU model / generation… – and that is just a beginning. There is a good reason why Intel, AMD, IBM, ARM et al publish hefty optimisation guidelines / documents for each generation of their CPU's with the compiler writers in mind: the same sequence of instructions issued for the CPU model 123 might be less (or more) efficient than in the next CPU model 456 and vice versa; moreover (e.g. specifically for Intel vs AMD), a sequence of instructions optimised for a particular Intel generation might underperform for an equivalent AMD model or vice versa. Same is likely to be true for different RISC-V core designs from different RISC-V vendors. This is the reason why -mcpu=XXX and -mtune=YYY exist in GCC and clang/LLVM: efficient low-level code optimisation is a tricky business and depends on a large number of compounding factors. It remains to be seen how the optimisation will be tackled in the RISC-V case with its potpourri of optional ISA extensions and also with the instruction fusion. Given that a random concrete RISC-V implementation can be a combination of the base ISA + a random permutation of any RISC-V extensions (in the worst case scenario), emitting the code that will run equally efficient across N different RISC-V core designs appears to be problematic. Instruction fusion can pose another challenge as a fused macro-instruction may or may not run as efficiently on a RISC-V instance that does not fuse them. There is no guarantee that the compiler generated / optimised code will be equally highly performant across different implementations even for the same set of ISA extensions.
- snvzz 5y ago
  >and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Itanium aka the Itanic demonstrated this is not the case.

vbezhenar 5y ago

There are rumours of Apple being interested with RISC-V. May be MacBook 2030 will feature it.

snvzz 5y ago
Apple posted job advertisements looking for RISC-V technical roles. What they plan to do with them is unknown, but Apple has the cash flow to try a lot of things. I would expect them to quickly adopt it for embedded applications, and experiment with making their own high performance design, including porting MacOS and Rosetta Stone. They can afford to do this much, regardless of whether they end up moving their main CPUs to RISC-V or not.
- unfocussed_mike 5y ago
  Yep. There's surely a bunch of uses of RISC-V that have little or nothing to do with the main CPU, even in a conventional machine. Trust modules, device controllers, smart adapter cables etc.
- jhickok 5y ago
  For what it's worth, Apple always has people on hand monitoring innovations in technology and testing their stack on new hardware, most of which never sees the light of day.
  - Macha 5y ago
    See OS X on Intel being a thing inside Apple for years and years before they decided it should see the light of day.
    - throwawayboise 5y ago
      NEXTSTEP was multi-architecture even before Apple owned it.
- m463 5y ago
  I would imagine apple actually ships hundreds of devices with processors - each dongle and peripheral has at least one.

PaulHoule 5y ago

My take is that RISC-V is not that great of an architecture and might never compete at the high end. (e.g displace ARM, Intel, POWER, etc.) On the other hand there is a vast market for low-end CPUs that have specializations to be disk controllers and things like that. If the ISA and all the IP required to make specialized devices is free and particularly if there is a culture in which it is easy to learn how to do that then RISC-V will have a special place. My next spatial computing project is going to be RP 2040 based mostly because I have the parts in stock (other projects are blocked because of supply chain issues) but I am really an AVR8 fanatic and the only path forward I see to higher performance AVR8 systems is a soft core running on an FPGA where very hard tasks (vision? comms?) get offloaded to the FPGA and that can be a very appealing architecture where somebody might prefer RISC-V particularly if the tooling and accelerator integration are there.)

zozbot234 5y ago
> might never compete at the high end. (e.g displace ARM, Intel, POWER, etc.) It might also be successful, even in that segment. The RISC-V ISA was specifically designed to scale up (e.g. to OOO and vector processors) while still being very simple, especially at the low-end - a basic RV32E is really comparable in complexity with many real-world 8- and 16-bit chips.
- jabl 5y ago
  The pretty minimal RV32EC core Ibex is estimated 15k gates: https://github.com/lowRISC/ibex https://github.com/lowRISC/ibex But, the similarly minimal Arm Cortex M0 is, drumroll, 12k gates. Not saying this means Arm is better than RISC-V, such a small difference can probably be explained by some microarchitectural feature or lack of it. Just that you can scale down Arm as well. But yes, I can see tiny chips like these putting a squeeze on 8 and 16 bit microcontrollers.
snvzz 5y ago
>My take is that RISC-V is not that great of an architecture That's not the impression I got, when I studied the specification. Do you care to elaborate?

rjsw 5y ago

Making a RPi equivalent would require a GPU with Linux support, I don't see any sign that RISC-V chip vendors are able to do this. Building a desktop system with a PCIe graphics card would be easier.

Narishma 5y ago
Isn't Imgtec doing that?
- rjsw 5y ago
  Where can I get the source code for PowerVR kernel drm code from?
  - snvzz 5y ago
    https://www.phoronix.com/scan.php?page=news_item&px=Open-Source-PowerVR-Vulkan https://www.phoronix.com/scan.php?page=news_item&px=Open-Sou...
  - Narishma 5y ago
    Nowhere because it's not available yet. They only made a few announcements.
    - snvzz 5y ago
      This has since changed. They've released a DRM/DRI driver.
ColonelPhantom 5y ago
There actually exists at least one GPL-licensed GPU core (GPLGPU), but it's based on a 90s PC 3D accelerator that's really just not that good. I believe the team behind LibreSOC is also working on a 3D processor, but I don't know how far along they are. However, if a vendor instead ships a decent framebuffer and high-performance vector unit, I think LLVMpipe would not be a problem for most RPi-equivalent use cases, either light desktop use or server use (especially the latter!)

hajile 5y ago

Jim Keller's team is creating a 6-wide issue RISC-V CPU. It should have similar IPC as ARM X1 or AMD Zen 3. https://youtu.be/KOHQQyAKY14?t=494 https://youtu.be/KOHQQyAKY14?t=494

Taniwha 5y ago
here's an 8-issue design: https://moonbaseotago.github.io/ https://moonbaseotago.github.io/