For a SoC (or bigger uC) include both ARM & RISC-V cores. They can work side by side, be used as development platform for either, share memory or peripherals included in the SoC (or perhaps share different but overlapping subsets of those resources). Or a Big.Little style setup where the "Big" and "Little" are different ISA.
Where utilising chip resources 100% is not too important (like, in most applications), designers could simply work with the ISA cores they're comfortable with. Switch use to the other cores, use the same peripherals.
Would this be difficult to work with? Unlikely. Software support for such setups exists, suitable defaults / boot settings & go.
At the very least this would get ARM foot in the door if it turns out RISC-V eating ARMs market share (which is already happening, be it limited scale so far). Or collect the 'ARM tax' for SoCs whose designers wanted RISC-V but don't mind including ARM as well.
For a SoC (or bigger uC) include both ARM & RISC-V cores. They can work side by side, be used as development platform for either, share memory or peripherals included in the SoC (or perhaps share different but overlapping subsets of those resources). Or a Big.Little style setup where the "Big" and "Little" are different ISA.
Where utilising chip resources 100% is not too important (like, in most applications), designers could simply work with the ISA cores they're comfortable with. Switch use to the other cores, use the same peripherals.
Would this be difficult to work with? Unlikely. Software support for such setups exists, suitable defaults / boot settings & go.
At the very least this would get ARM foot in the door if it turns out RISC-V eating ARMs market share (which is already happening, be it limited scale so far). Or collect the 'ARM tax' for SoCs whose designers wanted RISC-V but don't mind including ARM as well.