> It’s space-inefficient as half of the CPUs are shutdown
In practice is doesn't matter very much for a design like this. The size is already limited to a certain minimum to provide enough perimeter area to provide wire bonding area for all of the pins, so they can fill up the middle with whatever they want.
What difference would the extra 16KiB or whatever instead of the 2 RISC-V cores make? If 520KB is far too little for you, you're likely better off adding a 8 MiB PSRAM chip.
SRAM is big in gate count. typically 6 transistors per bit.
The i386, a 32 bit chip already dragging around a couple of generations of legacy architecture came in at 275,000. I would imagine the Hazard3 would be quite a bit more efficient in transistor usage due to architecture.
16K is 16384(bytes) *8(bits per byte) *6(transistors per bit) = 786, 432
The ESP32-S3 has 512 KB of SRAM, and the RP2350 has 520 KB of SRAM. The ESP32-S3-WROOM does indeed come in configurations with additional PSRAM, but that would be comparing apples and pears. The WROOM is an entire module complete with program flash, PSRAM, crystal oscillator etc. It comes in a much larger footprint than the actual ESP32-S3, and it is entirely conceivable that one could create a similar module with the same amount of PSRAM using the RP2350.
Furthermore, the added RAM in both cases is indeed PSRAM. That being said, the ESP32-S3 supports octal PSRAM, not just quad PSRAM, which does make a difference for the throughput.
And go cellphone style: Package-on-Package or Multi-Chip Module of some sort.
Wouldn't the massive increase in capabilities from adding 8MB-16MB of closely-integrated, fast RAM far outweigh the modest price increase for many applications that are currently memory-constrained on the Pico?
> But doesn't the ESP32-S3-WROOM have some large on-chip RAM?
They use the same PSRAM chips with relatively bad latency you complained about higher up in the thread. There are boards like those from Pimoroni that even have them on the PCB from the factory.
> For the Pico, say, something in the line of the approach taken by many smartphone SoCs that package memory and processor together.
What for? This only saves you PCB space, the latency is not going to be affected by this. There probably won't be enough people ordering those to justify the additional inventory overhead of (at least) 2 more skews.
Wouldn't the massive increase in capabilities from adding 8MB-16MB of closely-integrated, fast RAM far outweigh the modest price increase for many applications that are currently memory-constrained on the Pico?
Source for the RISC-V cores being essentially free (Luke Wren is the creator of the RISC-V core design used):
> The final die size would likely have been exactly the same with the Hazard3 removed, as std cell logic is compressible, and there is some rounding on the die dimensions due to constraints on the pad ring design.
Funny thing is that it cost them more than you might think. It was the ability to switch to the riscv which made it (much) easier to glitch. See the "Hazardous threes" exploit [1]
I wonder if they're using the same die for one or more microprocessor products that are RISC-V-only or ARM-only? They could be binning dies that fail testing on one or the other cores that way. Such a product might be getting sold under an entirely different brand name too.
They're not currently doing that but there is a documented way to permanently disable the ARM cores, so they could sell a cheaper RISC-V-only version of the same silicon if there's enough demand to justify another SKU.
That may be the plan for the future. Right now, this is a hedge / leverage against negotiations with ARM. For developers looking to test their code against a new architecture and compare it to known good code/behavior, it doesn’t get any easier than rebooting into the other core!
I find this whole concept remarkable, and somewhat puzzling.
Have seen the same (ARM + RISC-V cores) even at larger scales before (Milk-V Duo @1GHz-ish). But how is this economical? Is die space that cheap? Could you not market the same thing as quadcore with just minor design changes, or would that be too hard because of power budget/bus bandwidth reasons?
Thats also a good point. For the big Milk-V systems I mentioned they use external DRAM-- but cache might still be a die-space issue (I'd assume that it's always shared completely between ARM/RISC-V cores, and would need to be scaled up for true multicore operation).
But I'm still amazed that this is a thing, and you can apparently just throw a full core for a different architecture on a microcontroller at basically no cost :O
1) it needs a certain perimeter to allow all the pins to go from the silicon to the package, which mandates a certain sized square-ish die
2) only the cores are duplicated (and some switching thing is added)
so yes, there is enough space to just add another two cores without any worries, since they don't need more IO or pins or memory or anything.
It’s space-inefficient as half of the CPUs are shutdown, but architecturally it’s all on the same bus.