That is a good comment, and I agree things like CSR differences could be annoying, but compared to the engineering challenges of designing the Oryon cores from scratch… I still think the scope of work would be relatively small. I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.

> I just don’t think Qualcomm seriously wants to invest in RISC-V unless ARM forces them to.

That makes a lot of sense. RISC-V is really not at all close to being at parity with ARM. ARM has existed for a long time, and we are only now seeing it enter into the server space, and into the Microsoft ecosystem. These things take a lot of time.

> I still think the scope of work would be relatively small

I'm not so sure about this. Remember that an ISA is not just a set of instructions: it defines how virtual memory works, what the memory model is like, how security works, etc. Changes in those things percolate through the entire design.

Also, I'm going to go out on a limb and claim that verification of a very high-powered RISC-V core that is going to be manufactured in high-volume is probably much more expensive and time-consuming than the case for an ARM design.

edit: I also forgot about the case with Qualcomm's failed attempt to get code size extensions. Using RVC to approach parity on code density is expensive, and you're going to make the front-end of the machine more complicated. Going out on another limb: this is probably not unrelated to the reason why THUMB is missing from AArch64.

> verification of a very high-powered RISC-V core that is going to be manufactured in high-volume is probably much more expensive and time-consuming than the case for an ARM design.

Why do you say this?

Presumably, when you have a relationship with ARM, you have access to things that make it somewhat less painful:

- People who have been working with spec and technology for decades

- People who have implemented ARM machines in fancy modern CMOS processes

- Stable and well-defined specifications

- Well-understood models, tools, strategies, wisdom

I'm not sure how much of this exists for you in the RISC-V space: you're probably spending time and money building these things for yourself.

There is a market for RISC-V design verification.

And there is already some companies specializing on supplying this market. They do consistently present at RISC-V Summit.

The bigger question is how much of their existing cores utilize Arm IP… and how sure are they that they would find all of it?

> That doesn't mean you can just slap a RISC-V decoder on an ARM chip and it will magically work though.

Raspberry Pi RP2350 already ships with ARM and RISC-V cores. https://www.raspberrypi.com/products/rp2350/

It seems that the RISC-V cores don't take much space on the chip: https://news.ycombinator.com/item?id=41192341

Of course, microcontrollers are a different from mobile CPUs, but it's doable.

That's not really comparable. Raspberry Pi added entirely separate RISC-V cores to the chip, they didn't convert an ARM core design to run RISC-V instructions.

What is being discussed is taking an ARM design and modifying it to run RISC-V, which is not the same thing as what Raspberry Pi has done and is not as simple as people are implying here.

Nevertheless, several companies that originally had MIPS implementations did exactly this, to implement ARM processors.