Testing the RP2350B

[SiliconWizard]

I started testing the RP2350B (48 GPIO version).

The obligatory primes benchmark:

Code: [Select]

// 206.142 sec RP2350B @ 250 MHz               ??? bytes  51.5 billion clocks
Yes it runs @ 250 MHz without a problem. The RP2040 did too. I didn't try higher yet.
The number of cycles is not too impressive, it's barely lower than a Cortex-M4 (not significantly) while I was expecting a bit better with a M33. I haven't tested on a STM32U5 (which is also a M33) to confirm if it's solely reflecting the "performance" of the M33 or if the Flash cache of the RP2350 is maybe a bit less efficient. Doubt it, but can't say for sure. This is of course only comparing the results of "primes", which only says what uh, it says.

Note for those who want to use the pico sdk without their Cmake-based build system: the SDK v2 has become even much more of a monster than v1 was, so you've been warned. You probably remember the gigantic hierarchy of directories; well, with the support of two families, it hasn't gotten any better. They have also dramatically increased the number of macros to define various parameters. Anddd... they don't just use Cmake and some Python now; they now also use Bazel, which I didn't even know the existence of a couple days ago: https://en.wikipedia.org/wiki/Bazel_(software) . Now I do, but it didn't entice me in the least.

I used openocd to flash it. You'll have to build the RPi fork for now, as the official openocd doesn't support the RP2350 yet: https://github.com/raspberrypi/openocd . (The official openocd does support the RP2040 so it's probably safe to assume that they will integrate the RPi changes at some point). You can of course go via UF2 otherwise (but that's not very practical for development purposes). But here again, if you don't intend to use their Cmake/Bazel build system, you'll be in for a rough ride as the old tool (elf2uf2) doesn't support the RP2350 and they have switched to a different tool now for UF2 instead of updating the old one. Of course. So you'll need to build (or download if available for your platform) their new 'picotool' executable, which does a bit of everything except coffee.

Oh and for those who are keen to go directly baremetal without going via the pico-sdk-with-your-own-build-system way first, you can get some (working but very, very crude) starting point here:
https://github.com/metebalci/rp2350-bare-metal-build

Its startup code is very basic, and in particular, it doesn't enable any of the coprocessors of the RP2350 ARM core(s), so if you want to be able to use them, you'll have to figure out how to (oh, and also it only copies the data section, but doesn't zero-out the bss section, so, yes, did I say crude?). Which you'll find in the crt0.S file in the pico-sdk, inside a mountain of conditional compilation and additional source code spread in the runtime.c and runtime_init.c source files. With a non-trivial (before you get to know it) call chain system. I know, because I did build my tests with the pico-sdk and my own makefile, and there were a lot of new things to care about compared to the older sdk with the RP2040, and my first attempts made the CPU hardfault. Finally tracked it down to a NOCP error. Which was because I was calling GPIO functions from the pico sdk, which uses the GPIO coprocessor on the RP2350 (which is nice, btw, doesn't go via a peripheral bus anymore), and this coprocessor was not enabled in the startup code... with the way I was building it.

Just to say that if you're going baremetal, keep this coprocessors thing in mind. The RP2350 -M33 has several of them, and they are nice.

That's all for now, but I'm curious to test PSRAM on it next. And the new PIO.

(Speaking of PSRAM, it doesn't seem to be directly supported by the pico-sdk yet, and there isn't any example in pico-examples either - that I could find - but here's a small project that shows how to configure the QSPI controller for PSRAM, that should be handy to spend less time figuring it all out: https://github.com/FreddyVRetro/pico_psram/tree/main )

[cfbsoftware]

Interesting...

Last October we reported a comparison of the code produced by our Oberon compilers for the RP2040 and the RP2350:

https://www.astrobe.com/forum/viewtopic.php?f=19&t=803

The test program that we ran was originally written in Modula-2 by Niklaus Wirth for his Lilith computer. It is documented in Appendix 2 of the *ETH Report Nr 40 - The Personal Computer Lilith* (The Yellow Report). Apr 1981. N. Wirth which you can download from:

https://www.astrobe.com/Modula2/

The results shown there indicate (taken with a huge grain of salt) that the Pi Pico is ~ 50x faster, and the Pi Pico 2 is ~ 100x faster than a Lilith.

The price comparison of the systems is even more impressive at ~ 5000x:

The Lilith cost ~ $US 8000 (~ $US 25,000 today) whereas you can get a Pi Pico 2 for $US 5

[SiliconWizard]

Ah, for sure. Yes there's about 2x more performance over the M0+ of the RP2040, although of course it's an average and will depend on what exactly is executed.

Having a FPU is nice, and they have added a double-precision coprocessor too, allowing to compute some double-precision operations (it's of course limited compared to a full double-precision FPU) very efficiently compared to resorting to soft FP for double precision. The GPIO coprocessor is also nice if GPIO latency is critical (although in this case, you'll be using the PIO, but I guess having efficient GPIO handling via the CPU itself can still be handy in some cases).

Compared to what was powerful 40 years ago... Yes this is insane. This for the price of a candy bar (the chip)

I'm sure a full Lilith workstation could be emulated on a RP2350 and possibly perform better (that has been done for 68k Macs). I mean emulation of the hardware, CPU included! Could be fun.

[brucehoult]

I started testing the RP2350B (48 GPIO version).

The obligatory primes benchmark:

Code: [Select]

// 206.142 sec RP2350B @ 250 MHz               ??? bytes  51.5 billion clocks

"obligatory" ... heh. Fame! Can fortune be far away?

I'm assuming it's probably the same 228 bytes as the BluePill & BlackPill (submitted), and Teensy (done by me) entries?

Want to try the Hazard3?

This is of course only comparing the results of "primes", which only says what uh, it says.

I think it's as good a test of a CPU core and L1 cache with a decent amount of load/store and branching as any. Or SRAM for microcontrollers.  And with a decent branch mispredict rate even on the top x86 and Apple cores, which isn't easy to do in a micro-benchmark (it's comparable to e.g. gcc)

[brucehoult]

The results shown there indicate (taken with a huge grain of salt) that the Pi Pico is ~ 50x faster, and the Pi Pico 2 is ~ 100x faster than a Lilith.

The price comparison of the systems is even more impressive at ~ 5000x:

The Lilith cost ~ $US 8000 (~ $US 25,000 today) whereas you can get a Pi Pico 2 for $US 5

For $5 you can also get the Milk-V Duo (I paid $3 for mine, but they seem to have gone up) which does the primes test in 43.048s at the default 850 MHz set by the standard buildroot image which is 4.8x faster than this Pi Pico 2 result -- at the 1 GHz they're advertised at (which I'm sure it will happily do I've just never bothered) it should be 5.6x faster.

That's a 64 bit CPU with full FPU, MMU, 64 MB in package RAM, and a 128 bit vector unit.  Plus a bonus 700 MHz 64 bit microcontroller core. And an 8051 :-)

[SiliconWizard]

That's a 64 bit CPU with full FPU, MMU, 64 MB in package RAM, and a 128 bit vector unit.  Plus a bonus 700 MHz 64 bit microcontroller core. And an 8051 :-)

Yes! Now it draws much more power than the RP2350, so the latter still has its place.
I have considered using the CV1800B or SG2002 for a product actually, but I'm still unsure about long-term availability. That's the main issue.

[SiliconWizard]

I started testing the RP2350B (48 GPIO version).

The obligatory primes benchmark:

Code: [Select]

// 206.142 sec RP2350B @ 250 MHz               ??? bytes  51.5 billion clocks

"obligatory" ... heh. Fame! Can fortune be far away?

Getting there!

I'm assuming it's probably the same 228 bytes as the BluePill & BlackPill (submitted), and Teensy (done by me) entries?

I don't know. Haven't checked the size nor the assembly.

Want to try the Hazard3?

I should. Seeing how primes does on RV compared to arm cortex-M, I'm almost certain it will do better. Even the CH32L103 and 32V307 do better for primes.

This is of course only comparing the results of "primes", which only says what uh, it says.

I think it's as good a test of a CPU core and L1 cache with a decent amount of load/store and branching as any. Or SRAM for microcontrollers.  And with a decent branch mispredict rate even on the top x86 and Apple cores, which isn't easy to do in a micro-benchmark (it's comparable to e.g. gcc)

Well, yes. But all I can say is that it tends to perform significantly better on RV32 than on cortex-M for some reason, even the M4/M33, at least for all RV32 cores I've tested it with. While other kinds of tasks will give an edge to the cortex-M. Comparing the assembly will probably explain the reason why. The M7 tends to be better OTOH. CoreMark seems to "favor" the cortex-M compared to your primes.

[brucehoult]

I'm still unsure about long-term availability. That's the main issue.

Sadly, geopolitics is probably a much bigger risk there than the usual question of how long the company will make them for.

Sophgo maybe slightly higher risk than WCH, Espressif, Gigadevice, Allwinner, Rockchip, Amlogic, Gowin, StarFive ... but I think not much more on these things made on older process nodes at domestic factories.

[brucehoult]

I think it's as good a test of a CPU core and L1 cache with a decent amount of load/store and branching as any. Or SRAM for microcontrollers.  And with a decent branch mispredict rate even on the top x86 and Apple cores, which isn't easy to do in a micro-benchmark (it's comparable to e.g. gcc)

Well, yes. But all I can say is that it tends to perform significantly better on RV32 than on cortex-M for some reason, even the M4/M33, at least for all RV32 cores I've tested it with. While other kinds of tasks will give an edge to the cortex-M. Comparing the assembly will probably explain the reason why. The M7 tends to be better OTOH. CoreMark seems to "favor" the cortex-M compared to your primes.

Is it time to again mention that I wrote primes at Samsung in 2016, to compare ARM SBCs such as Pi 3, Odroid XU4 and C2 with the CPUs in Google and Samsung phones and with x86? I hadn't heard of RISC-V at the time, and the HiFive1 wasn't yet announced. It was not biased towards RISC-V!

RISC-V benefits a lot on twisty code, especially on simple cores, from the integrated "compare and branch" instructions.

On the other hand Coremark is in my opinion overweighted on having a fast multiply (which primes does use too) and Arm often has 1-cycle multiply on their lower clock frequency cores, while I don't know of any RISC-V with multiply in less than 3-4 cycles (possibly with an early out if one of the operands is small).

Also there was a kerfuffle in the early days of RISC-V with Coremark. Coremark's code uses "unsigned int" for array indexes which, in my experience, goes against industry practice of using int, long, or size_t. This benefits ISAs that automatically zero-extend 32 bit values and penalises ISAs that automatically sign-extend 32 bit values, which then need extra instructions (two! in basic RV64GC) to zero-extend. RISC-V people put in a typedef for those variables, using "int" instead. The Coremark overlords noticed this and said "your results are illegal, you're not allowed to change the source code" and made everyone change., resulting in lower Coremark results being published from then on.

I think this was unfortunate. Any normal open source project would happily accept a patch typedefing something differently on different machines.

The Zba extension solved this problem with the sh1add, sh2add, sh3add instructions working with int, long, and unsigned long indexes and add.uw, sh1add.uw, sh2add.uw, sh3add.uw efficiently covering the unsigned int case by zero-extending rs1 before shifting and/or adding to the 64 bit rs2.

Of course none of this applies to 32 bit CPUs.

[SiliconWizard]

Yes, the type of your indices can make a significant difference - benchmarked that on RV64 too.

That can also happen on 32-bit CPUs when using a smaller-sized index (like uint16_t or uint8_t). But it also depends on *how* the indices are used. For instance, if simply incremented by 1, it doesn't make a difference. But if doing something different with the indices, then that becomes interesting. That's at least with gcc 14.2. To illustrate the point:

https://godbolt.org/z/rTc6hj5M7

[cfbsoftware]

I'm sure a full Lilith workstation could be emulated on a RP2350 and possibly perform better (that has been done for 68k Macs). I mean emulation of the hardware, CPU included! Could be fun.

That would be an interesting exercise. All the necessary source code of EmuLith, a full working Lilith workstation emulator, is available. The Lilith CPU design uses the AMD2901 bit-slice processor and the emulator emulates the execution of the microcode. However, it might be a bit slow on the RP2350:

The performance of Emulith on a 1 GHz machine is comparable with the real hardware, which used a 7 Mhz main clock. Any operation involving the disk is considerably faster on the emulator.

http://pascal.hansotten.com/niklaus-wirth/lilith/emulith/

[SiliconWizard]

Ok I tested PSRAM.
* Read: 37 MB/s
* Write: 12 MB/s
(Writing an alternate pattern and reading it back/checking, 4 MB data block.)

That's not fantastic. Not completely sure why the discrepancy with the write speed. I tried tweaking timings but I can't get better than this so far.
CPU running at 250 MHz, PSRAM clocked at 125 MHz.

And.... the RISC-V tests.

Interestingly, the read speed I get from PSRAM with the RISC-V core is a bit higher: 39 MB/s (consistently). The write speed is identical.

For primes:

Code: [Select]

// 178.424 sec RP2350B (RV32 Hazard3) @ 250 MHz ??? bytes  44.6 billion clocks
Better than the Cortex-M33. On par with the QingKeV4 cores (but the latter don't currently run at such high speeds on WCH products).

For the "fun" fact: once the RISC-V cores have started, one (possibly obvious, but annoying) consequence is that the chip becomes unaccessible via SWD. Since the ARM cores are off. I haven't dug into the docs deeply enough to figure out if the Hazard3 cores have some kind of SWD-like debug interface or how to access it, so until then, they can't be "debugged" and you can't even flash the chip again using OpenOCD unless you force to boot it in UF2 update mode (which appears to run on ARM cores, luckily enough). Maybe there's a way to deal with it and I haven't found it yet (didn't search yet). If not, that's quite, uh... funky.

[brucehoult]

And.... the RISC-V tests.

Very interesting. The two cores are very comparable, one better on some things e.g. M33 4.09/MHz on Coremark vs Hazard3 3.81 (7% difference), one better on others ... 15.5% to the Hazard3 on primes.

For primes:

Code: [Select]

// 178.424 sec RP2350B (RV32 Hazard3) @ 250 MHz ??? bytes  44.6 billion clocks

Added, thanks!

For the "fun" fact: once the RISC-V cores have started, one (possibly obvious, but annoying) consequence is that the chip becomes unaccessible via SWD. Since the ARM cores are off.

Oh, that's weird and unfortunate and unexpected.

[brucehoult]

I asked grok. YMMV. Information not verified.

[SiliconWizard]

I'll look into that and will report back.

Yes, it does work. You only need to use the rp2350-riscv.cfg config file instead of rp2350.cfg (which is for ARM cores).
https://github.com/raspberrypi/openocd/blob/sdk-2.0.0/tcl/target/rp2350-riscv.cfg
Again only available with the RaspberryPi fork of OpenOCD for now.

Seems to work fine, couldn't fault it so far.

[SiliconWizard]

And.... the RISC-V tests.

Very interesting. The two cores are very comparable, one better on some things e.g. M33 4.09/MHz on Coremark vs Hazard3 3.81 (7% difference), one better on others ... 15.5% to the Hazard3 on primes.

One nice thing with the RISC-V cores is the A extension, supported by most available RISC-V cores these days. Compare a simple atomic add on the Hazard3 and on the CM-33:

Code: [Select]

#include <stdatomic.h>

atomic_int Counter;

void Foo()
{
atomic_fetch_add_explicit(&Counter, 1, memory_order_relaxed);
}

CM-33:

Code: [Select]

Foo:
        ldr     r3, .L4
.L2:
        ldrex   r1, [r3]
        adds    r1, r1, #1
        strex   r2, r1, [r3]
        cmp     r2, #0
        bne     .L2
        bx      lr
.L4:
        .word   .LANCHOR0
        .set    .LANCHOR0,. + 0
Counter:
        .space  4

Hazard3:

Code: [Select]

Foo:
        lui     a5,%hi(Counter)
        li      a4,1
        addi    a5,a5,%lo(Counter)
        amoadd.w        zero,a4,0(a5)
        ret
Counter:
        .zero   4

 

[MK14]

There is an interesting article on overclocking the RP2350/Pico2:

https://learn.pimoroni.com/article/overclocking-the-pico-2

It seems, because the CPU voltage can be set to much higher values than the original RP2040/Pico, it is VERY overclockable, if you are willing to risk messing with the CPU voltage (not recommended for production or any serious use).

Edit: Previous post was too long and hard to understand, so rewritten.

[brucehoult]

Code: [Select]

.L2:
        ldrex   r1, [r3]
        adds    r1, r1, #1
        strex   r2, r1, [r3]
        cmp     r2, #0
        bne     .L2


RISC-V A extension does of course also have the LR/SC way to do it.

Atomic RMW is annoying to implement on a very small RISC core because it needs some kind of sequencing within an instruction, either a state machine or microcode -- and actually more complex than Arm's LDM/STM (which Hazard3 has too, in the form of the Zcmp extension).

One option is to let AMOADD etc trap and emulate it with LL/SC in M mode code: SBI on a bigger machine, a microcontroller could have the code in a little bit of mask ROM and a custom trap vector, maybe even not documented.

Big machines implement AMOADD in the last level cache controller, or even potentially on a completely different machine, on the other side of the room, where that bit of memory exists. If the dst register is Zero (x0), as here, then no reply is needed and on the bus it's just like a store with an extra 3 bit opcode (ADD, AND, OR, XOR, MAX, MAXU, MIN, MINU).

[SiliconWizard]

There is an interesting article on overclocking the RP2350/Pico2:

https://learn.pimoroni.com/article/overclocking-the-pico-2

It seems, because the CPU voltage can be set to much higher values than the original RP2040/Pico, it is VERY overclockable, if you are willing to risk messing with the CPU voltage (not recommended for production or any serious use).

Yes, although past 1.2V/1.3V, I think you're getting into dangerous territory, not just the temperature. I wonder what process node they use for this die?

I'm pretty happy with 300 MHz already. But yes, I've heard some people even considering replacing a STM32H7 with an overclocked RP2350, so... you could need the extra clock frequency. You'll have to set up the Flash wait state appropriately too.

[SiliconWizard]

As to PSRAM read/write speed, I've read about that in a couple threads on the RPi forums. Apparently, it could be due to the QMI cache, that works well for Flash but not so much for PSRAM and it appears that disabling it for PSRAM yields much higher throughput. I'll experiment with that.

Confirmed, when using uncached access:
* Read: 35 MB/s
* Write: 41 MB/s

Since I write and check an alternate pattern, I manually unrolled my loops a little and got this:
* Read: 38 MB/s
* Write: 53 MB/s

So, getting close to the maximum at all possible of ~60 MB/s (bus speed = 125 MHz - just making it clear that I'm talking about MiB/s here, but I refrained from using this not to offend some people), the difference for reads here being just because I check the pattern on the fly which adds a bit of overhead.

That makes sense when writing large contiguous blocks of data considering how the cache is flushed (which unfortunately creates a lot of short bursts on the QSPI bus), so uncached writes of large blocks are much faster. Uncached reads are slightly slower, expected as well. A bit unfortunate for writes, but I guess this cache was really optimized for flash reads anyway rather than writes.

OTOH, writing through the cache will be more efficient if you do a lot of writes in an area of a few KB.
Good thing is that you don't have to disable and re-enable the cache, as they have mapped uncached QSPI access at a different address. So you can combine cached and uncached accesses on the fly, where it makes the most sense.
(See section "4.4.1. XIP Cache")

[jnk0le]

You can also try the streamer interface to improve read speeds if the linear prefetching is lacking.

[SiliconWizard]

You can also try the streamer interface to improve read speeds if the linear prefetching is lacking.

I'll have to figure it out too. Read about it in the datasheet.

[neil555]

Here's some more information on overclocking ...

https://forums.raspberrypi.com/viewtopic.php?t=375975

I've been torture testing one of my boards for weeks now at 576Mhz (1.8v) with no issues, it barely even gets warm!

[Harjit]

How narrow a pulse can one generate on the RP2350B?

I'm curious if the RP2350B can be used to commutate several brushless motors. The STM32G4, some TI and Microchip parts can do single digit nanosecond wide pulses.

I've read the PIO document section but couldn't find a clock tree to work out the details. Thanks in advance.

[brucehoult]

How narrow a pulse can one generate on the RP2350B?

"HSTX Interface: For high-speed applications, the RP2350 includes a High-Speed Serial Transmit (HSTX) interface, which can drive up to 8 GPIOs (pins 12–19) at 150 MHz with double-data-rate (DDR) output, achieving up to 300 Mbps per pin (effectively 150 MHz per bit, as DDR doubles the data rate per clock cycle). This is significantly faster than standard GPIO toggling due to dedicated hardware."

You may not be able to get rail to rail at those speeds, or anywhere near close to it, due to capacitive loading on the output pin, drive strength (maximum 12 mA, default 4 mA), trace length, etc.