I got almost all of my wishes granted with RP2350

You can pick either ARM cores or RISC-V cores on the same die? Never saw design like this before. Will this impact price and power consumption?

"The Hazard3 cores are optional: Users can at boot time select a pair of included Arm Cortex-M33 cores to run, or the pair of Hazard3 cores. Both options run at 150 MHz. The more bold could try running one RV and one Arm core together rather than two RV or two Arm.

Hazard3 is an open source design, and all the materials for it are here. It's a lightweight three-stage in-order RV32IMACZb* machine, which means it supports the base 32-bit RISC-V ISA with support for multiplication and division in hardware, atomic instructions, bit manipulation, and more."

This "switchable cores" thing has been appearing in some products for a few years now, for example Sipeed SG2002 (LicheeRV). The area occupied by the actual instruction core is usually pretty small compared to peripherals and internal memories.

Apparently (this is news to me), you can also choose to run 1+1 Arm/RISC-V, you don't have to switch both cores either/or.

Eben Upton: "They're selectable at boot time: Each port into the bus fabric can be connected either to an M33 or a Hazard3 via a mux. You can even, if you're feeling obtuse, run with one of each."

Source: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/

The MilkV Duo also has this feature I believe... https://milkv.io/duo

This seems like a great way to test the waters before a potential full-on transition to RISC-V. It allows to validate both technically and market reception, for a much lower cost than taping out a additional chip.

Fun for benchmarking too.

You’re limited to those two exact kinds of cores, but you know every other thing on the entire computer is 100% identical.

It’s not SBC 1 vs SBC 2, but they have different RAM chips and this one has a better cooler but that one better WiFi.

But not 2+2? That seems too bad to have each architecture run code based on their strengths for quad core workloads.

Yea, i was hoping for 2+2 myself but I suspect it's because the setup doesn't have the ability to mediate peripherals between the cores in a way that'd let that work. I.e. trying to turn on both Risc-v and arm #1 cores means that there'd be bus conflicts. It'd be cool if you could disable the io on the risc-v cores and do all hardware io through arm (or vice versa) so you can use the unconnected ones for just pure compute tasks (say run ws2812b led strips with the arm cores but run python/javascript/lua on the risc-v cores to generate frames to display without interrupting the hardware io).

Why not both: power distribution and cooling? Having to route twice as many wide buses, and put in twice as much of L0 caches?

My thoughts exactly - a risc-free (hurhur) way to get RISC-V in the hands of many, many devs.

It's the same SoC as the LicheeRV (SG2002)

I do wonder if the unavailability of some of the security features and -- possibly a big deal for some applications -- the accelerated floating point on the RISC-V cores would skew that experiment, though.

Would've been cool for safety applications if the second core could be run in lockstep mode.

afaik that is a whole different rodeo on the silicon level

We did look at this, but the AHB A-phase cost of putting a true arbiter (rather than a static mux) on each fabric port was excessive. Also, there's a surprising amount of impact elsewhere in the system design (esp debug).

I really hope people don't do this. Or at least not try to sell it as ARM vs RISC-V tests.

Because what you are really testing is the Cortex-M33 vs the Hazard 3, and they aren't equivalent.

They might both be 3 stage in-order RISC pipelines, but Cortex-M33 is technically superscalar, as it can dual-issue two 16bit instructions in certain situations. Also, the Cortex-M33 has a faster divider, 11 cycles with early termination vs 18 or 19 cycles on the Hazard 3.

Hazard3 pointer https://github.com/Wren6991/Hazard3

I think it's cool as a cucumber that we can choose fully open-source RISC-V if we want. My guess is the RV cores are slower clock-per-clock than the M33 cores; that is benchmark scores for M33's will be better, as Hazard3 is only 3-stage pipeline - but so is M33. Can't wait for the benchmarks.

It'd help to know how much area each core takes within the die.

I would expect the ARM cores to be much larger, as well as use much more power.

Indeed, though I'm curious about the rationale behind it. It is a 'plan B' in case their relationship with ARM sours? It is aiming for cost-cutting in the future (I can't imagine the ARM licences are costing them much given the price of the RP2040, but maybe they're absorbing it to get marketshare)

Embracing RISC-V, the high-quality open-source ISA that is rapidly growing the strongest ecosystem, does make a lot of sense.

Hard to tell.

If you ignore the FPU (I think it can be power gated off) the two cores should be roughly the same size and power consumption.

Dual issue sounds like it would add a bunch of complexity, but ARM describe it as "limited" (and that's about all I can say, I couldn't find any documentation). The impression I get is that it's really simple.

Something along the line of "if two 16 bit instructions are 32bit aligned, and they go down different pipelines, and they aren't dependant on each other" then execute both. It might be limitations that the second instruction can't access registers at all (for example, a branch instruction) or that it must only access registers from seperate register file bank, meaning you don't even have to add extra read/write ports to the register file.

If the feature is limited enough, you could get it down to just a few hundred gates in the instruction decode stage, taking advantage of resources in later stages that would have otherwise been idle.

According to ARM's specs, the Cortex-M33 takes the exact same area as the Cortex-M4 (the rough older equivalent without dual-issue, and arguably equal to the Hazard3), uses 2.5% less power and gets 17% more performance in the CoreMark benchmark.

That is exactly what the "limited dual issue" is - two non-conflicting pre-decoded instructions (either 16b+16b or if a stall has occurred) can be sent down the execution pipe at the same time. I believe that must be a memory op and an ALU op.

yeah lockstep requires a whole bunch of things to verify and break deadlocks. I suspect you need three processors to do that as well (so you know which one has fucked up.)

The ARM cores are probably much larger, but I don't think that translates into better power efficiency _automatically_.

It is not necessary that there is triple modular redundancy with lockstep, I know of microcontrollers with two processors, who throw an error when the results from instructions don't match.

yes - two votes allows you to detect a disagreement, three votes allows two votes to win.