Rust on the RP2350 (2024)
thejpster.org.uk
thejpster.org.uk
Ada works, too, though, or Forth. :P
It turned the usual multi-hour expedition of locating and configuring SDKs, toolchains, etc into 3 commands and 5 minutes of downloads and compilation. The resulting executable ran successfully at the first try. I was amazed.
Are there two actual CPUs on the same die? Is it one shared architecture with two different instruction decode stages, one for ARM and the other for RISC-V that can be toggled at boot time? I like the idea conceptually but I'm not sure how much of that is a hack and/or inefficient compared to a pure ARM or RISC-V core.
It’s space-inefficient as half of the CPUs are shutdown, but architecturally it’s all on the same bus.
> 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.
[1] https://www.raspberrypi.com/news/security-through-transparen...
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?
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.
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
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.
PSRAM has huge latency.
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
(this one, only 32bit internally)
…vertically stack a slab of SRAM above or beneath the CPU die, does come to mind ;)
For the Pico, say, something in the line of the approach taken by many smartphone SoCs that package memory and processor together.
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?
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.
(for various chemistry reasons, it's much more efficient to manufacture Flash, DRAM, and regular logic on separate wafers with different processing)
What I really want to know is why would anyone need or want dual architectures on one chip?
Tapeouts are expensive. It seems that they had spare area, so they decided to add RISC-V as a sort of feature test and market test; that lets them determine what the market preference is between the two and acquire geek coolness points (plus an additional point for using Rust) at relatively low cost, certainly lower cost than doing two tapeouts for two different SKUs.
Here at $MEDIUM_SIZED_CHIP_CO, we also have some products which have a custom DSP for realtime audio processing and an ARM for "other stuff". It's more common than you think. Even the very first Pi was effectively a video-oriented vector processor with a small ARM glued on the side.
As long as they make their core at least feature-equivalent by implementing FPU and the secure boot chain.
However, giving end users both in the same chip eliminates any risk because it allows the Risc-V tooling to develop at the same time. And if that development fails, oh well, the Arm cores will keep working and the next tapout might exclude the Risc-v cores. Life moves on.
RISC-V is rapidly growing the strongest ecosystem.
After some thought I understand the problem this setup tackles: Without dual architectures, there's a conundrum: how do you sell Risc-V if everyone is tooled for Arm?
So I get that offering both means they dont have to risk tapeout of a pure Risc-V die there's no immediate market for. The dual arch chip presents little to no risk while allowing the same chip to bootstrap a Risc-V tooling ecosystem. Once the end users have a mature Risc-V ecosystem the chip makers can begin to cut the Arm licensing strings they are entangled in.
> It's more common than you think.
You are describing co-processors or accelerators which fulfill a different role in the same system. It makes sense to have those. However, I was initially confused as to why a chip needs two architectures that fulfill the same role. That did not make sense at first glance from a technical standpoint but does from a business one.
In that respect it makes perfect sense to me.
⁰ https://datasheets.raspberrypi.com/picow/pico-2-w-schematic....
(BTW two of the variants are called RP2354 and not RP2350, the last digit means the amount of internal flash)
Ah, he wrote most of embedded-sdmmc-rs which I used quite a bit. Jonathan, if you see this, thanks!
Raspberry Pi Showcases Rust on the RP2350 Microcontroller (9 comments):
Would suggest people understand this before buying.