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

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.)

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.

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

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).

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?