... And the Vega board https://open-isa.org/ with 4 cores
That's unusual, it has a NXP logo, and claims to have a foot in both camps, with ARM and RISC V cores. RF support and BGA with large memories (1.25MB Flash 384k RAM )
However, even with a Nov 2018 NXP data sheet download, a search on NXP.COM for RV32M1, finds nothing at all ?
That device makes huge sense. The core is only a few percent of the die on a chip like that. Adding a second core lets them dip a toe in the RISC-V waters cheaply, while having a ARM core that ensures market acceptance. Making a complex chip with only a core whose market acceptance is unproven is risky. Making a simple chip with the unproven core means it won't do enough to attract much of an audience.
These multi-core, multi instruction set franken-monstrosities don't appeal to me at all. TI has something like this in the AM574x sitara.
Which has, count em,
2 Arm Cortex A15, 2 C66x DSP, 2 cortex M4, 2 PRU's and a partridge in a pear tree! Just Crazy.
Each different ISA requiring a different compiler and tool chain. who needs that complexity headache.
I see at least 4 market segments where RISC-V has a unique value proposition.
1. Very low cost high volume commodity controllers where the ARM licence cost is a dead weight and every penny counts.
2. companies like Western Digital who have high volume internal needs and want to be free from ARM licencing control and cost.
3. commodity manufactures who want to be immune to capricious changes in export law/sanctions
4.High security PC applications and server market, those that want to be free from back-doors like Intel's management engine
I'd say you missed a few.
1. anything where a custom instruction tightly integrated into the processor (i.e. take one or two register values, compute something, write the result to a register, all in 1 clock cycle) can significantly improve performance and energy efficiency on some task. ARM won't allow you to do that at any price. A coprocessor or memory-mapped device are the best they'll allow. This is ARM policy rather than physics or mathematics, so they could choose to change this.
2. anything that wants a microcontroller level of area / performance / energy consumption but wants 64 bit addressing, for example because you're an I/O controller in the corner of a bigger chip. ARM doesn't offer small 64 bit cores comparable to Cortex M0 or even M3. Again, this is more policy than anything, though they'd also want to define a subset of Aarch64, which is not currently allowed. RV64I cores can be very small -- and there seems to be demand for RV64E (16 registers only) also.
3. anything that wants 64 bit with code density comparable to Thumb2. Aarch64 code is much bigger than Thumb2 (though smaller than original ARM). This is hard to fix. There is insufficient room in the A64 encoding to add on 16 bit opcodes so you'd need either an awkward mode change as with original Thumb, or else an entirely new instruction encoding. MIPS, incidentally, seem to have done a good job of this with NanoMIPS which has 2, 4, and 6 byte instructions and both 32 bit and 64 bit. It looks to be virtually stillborn though, with only a single 32 bit chip announced 15 months ago, and no inclusion in their Open Source offering.