200Mhz clock speed update

[paulbuzzby]

I have seen that the RP2040 has some update that defaults the processor to run at 200mhz up from 133mhz (i think). Quite the speed increase.

One of the articles about it here

Does there need to be a new MicroPython firmware release in order to take advantage of this?

[robert-hh]

The default clock speed is 125 MHz. The linked article tells, that the device was certified fro 133MHz before. Now it's certified for 200Mhz. You can already since 2021 change the CPU frequency using machine.freq(new_value). The range is from 48 MHz up. Up to 250 MHz you get still REPL. Some people ran it up to 400MHz, but that requires additional precautions.

[paulbuzzby]

In the past I have played with the machine.freq(new_value) method but I stopped as I though I was starting to get funny issues with a timer I had setup to run 80 times a second. Not conclusive as I could have been breaking other stuff at the same time.

If it is that easy then that's great. Will have to do some testing on some simpler code to check but a good 40% speed increase will be brilliant for what I am doing.

[scruss]

This is kind of a “damned if we do, damned if we don't” situation:

• if the default is changed to 200 MHz, people will complain that the timing of their legacy scripts has changed. It may or may not break stuff.
• if the default is kept at 125/133 MHz, MicroPython will appear slower than it needs to be. Especially if CircuitPython picks up on the frequency bump ...

I've had

machine.freq(200000000)

in boot.py since mid-2023. I can't tell if it has caused problems.

[sosi-deadeye]

I would simply use the default standard and not deviate from it.
If someone has problems with their code because of this, there are ways to:

1. compile Micropython for RP Pico yourself, specifying the desired clock rate
2. machine.freq() in boot.py or main.py
3. Fix bugs in your own code.

[Josverl]

I propose to update the rp2 docs page to add the option to use a higher frequency by adding the below, in case speed is of the essence.
boot.py

import machine
machine.freq(200000000)

[peterhinch]

The impact of this announcement is on professional users designing hardware for production. Such engineers need a guarantee of reliability and never exceed manufacturers' specifications. They are now cleared to use 200MHz.

As an amateur I've been routinely using 250MHz on a number of boards without issue ever since the RP2 was released.

[rogernock]

With the device now certified for 200MHz operation. Will the firmware take into account that as well as the frequency change, VREG - VSEL will need setting to 1.15v instead of the default 1.1v ?

[robert-hh]

The expression vsel = 0.8 + ((mem32[0x40064000]>>4 & 0b1111) - 5) * 0.05 returns 1.1 on a freq built RP2040. I looked up the program flow for machine_freq() into the sdk. Just the PLL is changed, not the core voltage. So changing the core voltage should be added for faster clock frequencies.

[scruss]

... everything worked fine

Please note that this is for small values of everything. I haven't done any of the DVDD / VREG tweaks, and they're likely important for long-term stability. I am wary of the claims of overclockers, and would never want to be an authority

[MilhouseVH]

clk_sys (and clk_peri) have a maximum frequency of 133MHz across all process, voltage and temperature variations.
You can achieve 200MHz by running at an elevated core supply (DVDD) and setting VREG VSEL to 1.15V. For more
information, see Section 2.10.6.

Doesn't this suggest that if clk_peri can also achieve 200MHz, then the maximum SPI baudrate should now be 50Mbps (it's 31.25Mbps @ 125MHz)?

I've only ever seen the SPI baudrate go as high as 40Mbps @ 160MHz - any higher clk_peri seems to result in a lower baudrate (regardless of what baudrate is requested).

Testing with a W5500-EVB-PICO-POE, it would be nice if there's an SPI benefit to higher clk_sys. 🙂

[robert-hh]

Testing with a W5500-EVB-PICO-POE, it would be nice if there's an SPI benefit to higher clk_sys

That would not increase the ETH bandwidth substantially, since processing the data also takes it's time.

[MilhouseVH]

That would not increase the ETH bandwidth substantially, since processing the data also takes it's time.

A 40MHz SPI baudrate (with clk_sys/clk_peri at 160MHz) does result in a noticeable ETH improvement compared with stock maximum 31.25MHz SPI baudrate at 125MHz clk_sys/clk_peri.

I've not had any luck with upython 1.24.1 when using a 200MHz sys/peri clock and 50MHz baudrate as the network won't pull a DHCP address, but that might be the older SDK, or a limitation elsewhere in the WIZNET SPI networking.

Also, configuring a 40MHz baudrate at 200MHz clock selects only a 33.333MHz baudrate, so maybe there's some sort of override in the WIZNET library or SDK, although this 33.333MHz configuration does connect, and appears stable at 200MHz with 1.24.1.

The "speedtest" below is a very crude test I added in my project - it simply requests 10 Mbytes of data from a local socket server in 32KByte chunks and logs the elapsed time... kinda like iperf.

I'm seeing a 27.4% increase in network performance for a 28% increase in system/peripheral clock speed (125MHz > 160MHz) and 28% increase in baudrate (31.25MHz > 40.00MHz). This is with the interrupt pin enabled.

The results for 200MHz clock/33.333MHz baud (125>200 +60%; 31.25 > 33.333 +6.66%) are also shown - it's still a sizeable network performance gain of 34% for only a small increase in baudrate. I'm just not sure why it has chosen this particular SPI divisor, however.

I suppose the point is, that a 200MHz clock should have meant a 50MHz baudrate is now possible, and as this is a 60% increase for both, then in theory one might have expected the network performance to have increased by a similar amount.

Which would have been nice. 😄

clk_sys/clk_peri @ 125MHz, SPI baudrate 31.25MHz:

clk_sys/clk_peri @ 160MHz, SPI baudrate 40.00MHz:

clk_sys/clk_peri @ 200MHz, SPI baudrate 40.00MHz (requested) although 33.333MHz selected: