7 ms·

Once it gets to the shelfes at reasonable price will be happy to work with/on it. Curious how IP pricing compares to ARM in this case and how much would I need

Once it gets to the shelfes at reasonable price will be happy to work with/on it. Curious how IP pricing compares to ARM in this case and how much would I need to put on top of it to tape out own batch of processors

snvzz 5y ago
The license to the ISA itself is free. There's several vendors besides RISC-V offering cores for licensing. There's even some OSHW cores that can be freely used. Even if we choose to ignore the technical prowess of being a true 5th generation RISC ISA built with hindsight no other ISA has, what's IMHO a big deal in RISC-V is the mere availability of this market of cores. It poses a threat to ARM's business model, where ARM licenses cores and ISA, but nobody else than ARM can license cores to others.
- fartcannon 5y ago
  So I guess we should expect to hear a lot of FUD about RISC-V over the coming years.
  - snvzz 5y ago
    This is a real possibility, albeit a sad one. No amount of FUD will save ARM. Only pivoting into a different business model could.
    - duskwuff 5y ago
      Honestly, ARM is fine. They're no longer the only game in town, but they've still got a huge head start.
      - snvzz 5y ago
        They'll be fine if they focus on their microarchitectures rather than the ISA (where IMHO they've already lost), and make the process for obtaining a license much more streamlined; I've heard it takes no less than 18 months of long negotiations to license anythin from ARM. That's not sustainable now that there's competition.
        duskwuff 5y ago
        That's already where their focus is. Most of ARM's customers are licensing specific cores from ARM, not the ISA as a whole.
        klelatti 5y ago
        > where IMHO they've already lost Given M1, Graviton etc etc that’s a bold statement.
        snvzz 5y ago
        High performance implementations are possible even with bad ISAs, given enough resources. x86-64 is much worse than ARM. It's a literal clusterfuck. And yet. A high performance implementation of ARM, which is a much better ISA than x86-64, was something expected to happen sooner or later. It did not surprise me.
        klelatti 5y ago
        Fair enough but I’m still not sure why you think the Arm ISA has ‘lost’?
  - marcodiego 5y ago
    No need to wait. Already happened in 2018: https://www.theregister.com/2018/07/10/arm_riscv_website/ https://www.theregister.com/2018/07/10/arm_riscv_website/ https://www.extremetech.com/wp-content/uploads/2018/07/arm-risc-v-5-things-to-consider.png https://www.extremetech.com/wp-content/uploads/2018/07/arm-r...
    - snvzz 5y ago
      And it is how many learned about RISC-V's existence. It will be a PR disaster long remembered. One for the textbooks.
    - fartcannon 5y ago
      Why do people fall for this shit? Blows my mind.
    - jhgb 5y ago
      I find it amusing that RISC-V allegedly creates "fragmentation risk" when platform fragmentation in the ARM ecosystem already exists and it's painful enough -- at least that's what I recall from some comparisons with the x86/PC platform with respect to Linux kernel development.
- dmitrygr 5y ago
  > built with hindsight no other ISA has Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft.
  - snvzz 5y ago
    >Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft. aarch64 seems poorly designed to me. ARMv7 had thumb, but for some reason ARMv8 did not incorporate any lessons from that. As a result, code density is bad; ARMv8 binaries are huge. ARMv9, to be available in chips next year, is just a higher profile of required extensions, and does nothing to fix that. Ever wonder why M1 needs such huge L1 cache? Well, now you know. Considering ARMv9 will be competing against RVA22, I don't have much hope for ARM.
    - dmitrygr 5y ago
      > for some reason ARMv8 did not incorporate any lessons from that. I used to think so too, until I asked some more knowledgeable people about it. Turns out the lesson IS that not having it is better. Fixed-sized instructions make a decoding significantly simpler, making it much easier to make very wide front ends
      - brucehoult 5y ago
        A little easier, not much easier. A number of organisations are making very wide RISC-V implementations, and one has already published how their decoder works. It's modular, with each block looking at 48 bits of code (the first 16 overlapping with the previous block) and decoding either two 16 bit instructions, or one aligned 32 bit instruction, or one misaligned 32 bit instruction with a following 16 bit instruction, or one misaligned 32 bit instruction followed by an ignored start of another misaligned 32 bit instruction. You can put as many of these modules side by side as you want. There is a serial dependency between them in that each block has to tell the next block whether its last 16 bits are the start of a misaligned 32 bit instruction or not. That could become an issue with really really wide but for something decoding e.g. 16 bytes at a time (4 to 8 instructions) it's not an issue. There is a trade-off between a little bit of decoder complexity and a lot of improved code density -- but nowhere near to the same extent as say x86.
- Teknoman117 5y ago
  As far as OSHW cores go, it's so very nice to be able to throw something together in verilog and be able to inherit a compiler and not be trampling on someone else's copyright...

snvzz 5y ago

The license to the ISA itself is free. There's several vendors besides RISC-V offering cores for licensing. There's even some OSHW cores that can be freely used. Even if we choose to ignore the technical prowess of being a true 5th generation RISC ISA built with hindsight no other ISA has, what's IMHO a big deal in RISC-V is the mere availability of this market of cores. It poses a threat to ARM's business model, where ARM licenses cores and ISA, but nobody else than ARM can license cores to others.

fartcannon 5y ago
So I guess we should expect to hear a lot of FUD about RISC-V over the coming years.
- snvzz 5y ago
  This is a real possibility, albeit a sad one. No amount of FUD will save ARM. Only pivoting into a different business model could.
  - duskwuff 5y ago
    Honestly, ARM is fine. They're no longer the only game in town, but they've still got a huge head start.
    - snvzz 5y ago
      They'll be fine if they focus on their microarchitectures rather than the ISA (where IMHO they've already lost), and make the process for obtaining a license much more streamlined; I've heard it takes no less than 18 months of long negotiations to license anythin from ARM. That's not sustainable now that there's competition.
      - duskwuff 5y ago
        That's already where their focus is. Most of ARM's customers are licensing specific cores from ARM, not the ISA as a whole.
      - klelatti 5y ago
        > where IMHO they've already lost Given M1, Graviton etc etc that’s a bold statement.
        snvzz 5y ago
        High performance implementations are possible even with bad ISAs, given enough resources. x86-64 is much worse than ARM. It's a literal clusterfuck. And yet. A high performance implementation of ARM, which is a much better ISA than x86-64, was something expected to happen sooner or later. It did not surprise me.
        klelatti 5y ago
        Fair enough but I’m still not sure why you think the Arm ISA has ‘lost’?
- marcodiego 5y ago
  No need to wait. Already happened in 2018: https://www.theregister.com/2018/07/10/arm_riscv_website/ https://www.theregister.com/2018/07/10/arm_riscv_website/ https://www.extremetech.com/wp-content/uploads/2018/07/arm-risc-v-5-things-to-consider.png https://www.extremetech.com/wp-content/uploads/2018/07/arm-r...
  - snvzz 5y ago
    And it is how many learned about RISC-V's existence. It will be a PR disaster long remembered. One for the textbooks.
  - fartcannon 5y ago
    Why do people fall for this shit? Blows my mind.
  - jhgb 5y ago
    I find it amusing that RISC-V allegedly creates "fragmentation risk" when platform fragmentation in the ARM ecosystem already exists and it's painful enough -- at least that's what I recall from some comparisons with the x86/PC platform with respect to Linux kernel development.
dmitrygr 5y ago
> built with hindsight no other ISA has Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft.
- snvzz 5y ago
  >Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft. aarch64 seems poorly designed to me. ARMv7 had thumb, but for some reason ARMv8 did not incorporate any lessons from that. As a result, code density is bad; ARMv8 binaries are huge. ARMv9, to be available in chips next year, is just a higher profile of required extensions, and does nothing to fix that. Ever wonder why M1 needs such huge L1 cache? Well, now you know. Considering ARMv9 will be competing against RVA22, I don't have much hope for ARM.
  - dmitrygr 5y ago
    > for some reason ARMv8 did not incorporate any lessons from that. I used to think so too, until I asked some more knowledgeable people about it. Turns out the lesson IS that not having it is better. Fixed-sized instructions make a decoding significantly simpler, making it much easier to make very wide front ends
    - brucehoult 5y ago
      A little easier, not much easier. A number of organisations are making very wide RISC-V implementations, and one has already published how their decoder works. It's modular, with each block looking at 48 bits of code (the first 16 overlapping with the previous block) and decoding either two 16 bit instructions, or one aligned 32 bit instruction, or one misaligned 32 bit instruction with a following 16 bit instruction, or one misaligned 32 bit instruction followed by an ignored start of another misaligned 32 bit instruction. You can put as many of these modules side by side as you want. There is a serial dependency between them in that each block has to tell the next block whether its last 16 bits are the start of a misaligned 32 bit instruction or not. That could become an issue with really really wide but for something decoding e.g. 16 bytes at a time (4 to 8 instructions) it's not an issue. There is a trade-off between a little bit of decoder complexity and a lot of improved code density -- but nowhere near to the same extent as say x86.
Teknoman117 5y ago
As far as OSHW cores go, it's so very nice to be able to throw something together in verilog and be able to inherit a compiler and not be trampling on someone else's copyright...