←back to thread

I got almost all of my wishes granted with RP2350

(dmitry.gr)
700 points elipsitz | 10 comments | 08 Aug 24 13:03 UTC | HN request time: 0s | source | bottom
Show context
synergy20 ◴[08 Aug 24 15:15 UTC] No.41192422[source]▶
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."

replies(4): >>41193048 #>>41193435 #>>41193928 #>>41197487 #
1. geerlingguy ◴[08 Aug 24 16:37 UTC] No.41193435[source]▶
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/

replies(2): >>41194218 #>>41196146 #
2. ravetcofx ◴[08 Aug 24 17:42 UTC] No.41194218[source]▶
But not 2+2? That seems too bad to have each architecture run code based on their strengths for quad core workloads.
replies(3): >>41194602 #>>41194644 #>>41196841 #
3. simcop2387 ◴[08 Aug 24 18:16 UTC] No.41194602[source]▶
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).
4. nine_k ◴[08 Aug 24 18:20 UTC] No.41194644[source]▶
Why not both: power distribution and cooling? Having to route twice as many wide buses, and put in twice as much of L0 caches?
5. jaeckel ◴[08 Aug 24 20:54 UTC] No.41196146[source]▶
Would've been cool for safety applications if the second core could be run in lockstep mode.
replies(1): >>41196673 #
6. 4gotunameagain ◴[08 Aug 24 21:47 UTC] No.41196673[source]▶
afaik that is a whole different rodeo on the silicon level
replies(1): >>41200232 #
7. ebenupton ◴[08 Aug 24 22:06 UTC] No.41196841[source]▶
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).
8. KaiserPro ◴[09 Aug 24 09:33 UTC] No.41200232{3}[source]▶
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.)
replies(1): >>41210330 #
9. 4gotunameagain ◴[10 Aug 24 15:54 UTC] No.41210330{4}[source]▶
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.
replies(1): >>41211470 #
10. soneil ◴[10 Aug 24 18:59 UTC] No.41211470{5}[source]▶
yes - two votes allows you to detect a disagreement, three votes allows two votes to win.