3 ms·

> I see why semi manufacturers like to use it for deeply embedded cores that replace M0. It's not just a matter of not having to pay for a C-M0 license. - min

> I see why semi manufacturers like to use it for deeply embedded cores that replace M0. It's not just a matter of not having to pay for a C-M0 license. - minimal RV32E cores (16 registers) are significantly smaller than an M0, but not slower - if you want 32 registers (RV32I) you can have it. Arm makes you go to full on Aarch64, with MMU, FPU, NEON etc etc - if you want no multiplier, you can have it - if you want multiply AND divide (C-M0 has no divide), you can have that - if you want CLZ or Popcount or anything like that, you can have it (Zbb standard extension). Arm makes you go to M3 for `clz` or Aarch64 for `cnt` - if you want a 64 bit C-M0 equiv you can have it. Arm, obviously, makes you go to full on Aarch64 with MMU, FPU, NEON etc for that In short, the huge advantage of RISC-V is flexibility. Arm tries to fit your needs into one of a very small number of buckets that are seldom Goldilocks for you.

demondemidi 2y ago
Everything you said are facts. In (my) reality, the level of detail you describe in the configuration is based on reading a spec, and not based on a design. Caveat: this is my experience evaluating RV v. Arm. In other words: no one is picking apart the requirements to that level. In fact, they are just shoveling NEW options into the ISA: look at T-Head, they've added like two dozen esoteric configs. That's a really outsized (and strange) influence IMHO. I think the issues with RV adoption aren't the ISA, it's everything else a semi needs to build a product, specifically debug, validation, integration, and ecosystem : the standards are still in their infancy (go read the debug standard, it is severely underbaked), and I don't think there are any IP vendors selling RV IP, are there? Just those two vectors alone are a big deal. The ecosystem is growing, its just not there yet. And I think Arm is aware that it IS only a matter of time. It is inevitable that the ecosystem vendors for RV will mature over time. I worry it is being polluted by special interest, because RV is too scared to say "no" right now. RV looks leaderless right now. And that is by design. And I think that is bad news.

demondemidi 2y ago

Everything you said are facts. In (my) reality, the level of detail you describe in the configuration is based on reading a spec, and not based on a design. Caveat: this is my experience evaluating RV v. Arm. In other words: no one is picking apart the requirements to that level. In fact, they are just shoveling NEW options into the ISA: look at T-Head, they've added like two dozen esoteric configs. That's a really outsized (and strange) influence IMHO. I think the issues with RV adoption aren't the ISA, it's everything else a semi needs to build a product, specifically debug, validation, integration, and ecosystem : the standards are still in their infancy (go read the debug standard, it is severely underbaked), and I don't think there are any IP vendors selling RV IP, are there? Just those two vectors alone are a big deal. The ecosystem is growing, its just not there yet. And I think Arm is aware that it IS only a matter of time. It is inevitable that the ecosystem vendors for RV will mature over time. I worry it is being polluted by special interest, because RV is too scared to say "no" right now. RV looks leaderless right now. And that is by design. And I think that is bad news.