Can someone explain the benefit of having essentially 4 cores (2 ARM + 2 RISC-V) on the chip but only having 2 able to run simultaneously? Does this take significantly less die space than having all 4 available at all times?
I see a business decision here.
Arm cores have licensing fees attached to them.
Arm is becoming more restrictive with licensing and wants to capture more value [1]:
> The Financial Times has a report on Arm's "radical shake-up" of its business model. The new plan is to raise prices across the board and charge "several times more" than it currently does for chip licenses. According to the report, Arm wants to stop charging chip vendors to make Arm chips, and instead wants to charge device makers—especially smartphone manufacturers—a fee based on the overall price of the final product.
Even if the particular cores in the RP2350 aren't affected, the general trend is unfavorable to Arm licensees.
Raspberry Pi has come up with a clever design that allows it to start commoditizing its complement [2]:
make the cores a commodity that is open-source or available from any suitable RISC-V chip designer instead of something you must go to Arm for.
Raspberry Pi can get its users accustomed to using the RISC-V cores—for example, by eventually offering better specs and more features on RISC-V than Arm.
In the meantime, software that supports the Raspberry Pi Pico will be ported to RISC-V with no disruption.
If Arm acts up and RISC-V support is good enough or when it becomes clear users prefer RISC-V, Raspberry Pi can drop the Arm cores.
Coordinating access to the memory bus and peripherals is probably not easy to do when the cores weren’t ever designed to work together. Doing so could require a power/performance penalty at all times, even though most users are unlikely to want to deal with two completely different architectures across four cores on one microcontroller.
Having both architectures available is a cool touch. I believe I criticized the original RP2040 for not being bold enough to go RISC-V, but now they’re offering users the choice. I’ll be very curious to see how the two cores compare… I suspect the ARM cores will probably be noticeably better in this case.
They actually let you choose one Cortex-M33 and one RISC-V RV32 as an option (probably not going to be a very common use case) and support atomic instructions from both cores.
All of the public mentions of this feature that I've seen indicated it is an either/or scenario, except the datasheet confirms what you're saying:
> The ARCHSEL register has one bit for each processor socket, so it is possible to request mixed combinations of Arm and RISC-V processors: either Arm core 0 and RISC-V core 1, or RISC-V core 0 and Arm core 1. Practical applications for this are limited, since this requires two separate program images.
Beyond the technical reasons for the limit, it provides for a relatively painless way to begin to build out/for RISC-V[1] without an uncomfortable transition. For those who just want a better next iteration of the controller, they have it. For those who build tools, want to A/B test the architectures, or just do whatever with RISC-V, they have that too. All without necessarily setting the expectation that both will continue to coexist long term.
[1] While it's possible they are envisioning dual architecture indefinitely, it's hard to imagine why this would be desirable long term esp. when one architecture can be royalty free and the other not, power efficiency, paying for dark silicon etc.
cores are high bandwidth bus masters. Making a crossbar that supports 5 high bandwidth masters (4x core + dma) is likely harder, larger, and higher power than one that supports 3.
It's actually 10 masters (I+D for 4 cores + DMA read + DMA write) versus 6 masters. Or you could pre-arbitrate each pair of I and each pair of D ports. But even there the timing impact is unpalatable.
Each arm/riscv set likely share cache and register space (which takes most of the die space by far), resulting in being unable to use them both simultaneously.
Considering that these are off-the-shelf Cortex-M designs I doubt that Raspi was able or would be allowed to do that. I'd expect most of the die to be the 512K SRAM, some of the analog and power stuff and a lot of it just bond pads.
