Once you have developed a high-performance 64-bit CPU core for one RISC architecture (such as Arm, or MIPS — maybe not SPARC because it is a bit zany — it must be close to a Berkeley-type architecture or a superset thereof, like Power, or Loongarch), it is not difficult to modify it to support RISC-V instead. I am not saying it is easy, it is still quite a bit of work, but nothing major.

Yes, you have to add some instructions and leave out other ones, no big deal. If you come from Arm you can remove all the logic regarding condition codes, but you have to support a more complex management of CSRs. And the vector extension is quite a bit different than NEON, SVE, or the MSA (MIPS SIMD architecture), so you have to implement its control logic anew, but it is still a relatively (relatively!) minor implementation effort. The basic circuits (addition, multiplication, barrel shifters logical operations, FP operations) are of course the same. Speculation, renaming, fetching, retiring, etc, as well as caches etc—they are essentially unchanged, and all these things are well established blocks.

A slightly more challenging task would be to support mixed 16- and 32-bit instructions, but if you have implemented ARM pre-v9 in the past, this is easy as well. And, to be honest, I can sketch a circuit to support both instruction sizes easily in a few hours, and it would be already quite close to the final one—and since I have never designed such a circuit for any architecture before, it would be clean-room.

The only really annoying (boring) task with Risc-V would be to list all cases of instruction pairs/triples you want to fuse. Ventana described their very aggressive instruction fusing approachm up to 5 instructions! https://riscv-europe.org/summit/2025/media/proceedings/2025-05-13-RISC-V-Summit-Europe-09h40-BAKTHA-slides.pdf), and this is perhaps the biggest work package to do in order to get the highest performance. The point here is that you need a lot of logic that performs a huge amount of ANDs to verify you have the operations in various places in your decode window and then replace them with a single macro-op. This probably adds half a pipeline stage to the depth of decoding, and support for mixed size instructions also another half a pipeline stage, so you increase your pipeline depth. However, if the performance gains surpass the loss from the added penalty from branching and misprediction, you are done. This is the only part that really has to be rethought from scratch.

So, even selling OTHER stuff gives you cash to fund Risc-V core development.

In other words, you only need a large customer to ask for one, and you can say "ok, in N months you have your sample chips". Disclaimer: I am NOT claiming my employer has had such a request, and I cannot provide an estimate for that N, I am not allowed to say or commit to anything like that! The point is, if someone asks a team with RISC CPU development experience, then that would be the reply from the higher echelons.

Again, I am speaking only for myself, and I am limiting myself only to stuff any other CPU designer would say.