What is PVTM? Or why your Rockchip RK3588 CPU may not reach 2.4 GHz

While the Rockchip RK3588 processor is advertised as reaching 2.4 GHz, not all RK3588 chips may achieve this frequency. The keyword is PVTM (Process-Voltage-Temperature Monitor), and we’ll try to explain why it does, and why some of the RK3588 processors may only be clocked at about 2.3 GHz, while others will run fine at 2.4 GHz.

This all started with Rock 5B SBC debug party, where we noticed our boards did not reach the same frequency. Willy Tarreau noted the “pvtm” value was different between our boards:

  • Willy’s board: (Cortex-A76 cluster 1 @ 2,304 MHz, cluster 2 @ 2,352 MHz)
  • CNXSoft board (Cortex-A76 cluster 1 @ 2,304 MHz, cluster 2 @ 2,304 MHz) :
  • Thomas Kaiser (tkaiser) board: (Cortex-A76 cluster 1 @ 2,400 MHz, cluster 2 @ 2,400 MHz)

For reference, CPU 0 to 3 are Cortex-A55 cores, CPU 4-5 are two Cortex-A76 cores (cluster 1), and CPU 6-7 are two Cortex-A76 cores (cluster2). The frequencies reported above are Operating Performance Point (OPP) reported by the kernel, but the actual measured frequency in SBC-Bench.sh script may differ:

  • CNXSoft board:
  • Thomas board

What’s really odd is that we have different OPP frequencies. Thomas’ Cortex-A76 cores are set up to 2,400 MHz, but are only measured to 2,348 MHz. It’s still better than the 2304 and 2,298 MHz measured on my system.

We’ll see if we can find more details about pvtm in the Rockchip RK3588 TRM (and SDK). It can indeed be found in Chapter 17 entitled “Process-Voltage-Temperature Monitor (PVTM)” of TRM Part 2.

Rockchip PVTM
PVTM block diagram with apb_slv APB slave interface with 32-bit bus width, and PVTM engine

As described in the technical reference manual:

The Process-Voltage-Temperature Monitor (PVTM) is used to monitor the chip performance variance caused by chip process, voltage, and temperature.
PVTM supports the following features:

  • A clock oscillation ring is integrated and used to generate a clock like signal, the frequency of this clock is determined by the cell delay value of clock oscillation ring circuit.
  • A calculation logic is used to measure the frequency of the clock oscillation ring.
  • Follow PVTM blocks are supported:
    • BIGCORE0_PVTM, used near A76_0/1
    • BIGCORE1_PVTM, used near A76_2/3
    • LITCORE_PVTM, used near DSU and A55_0/1/2/3
    • NPU_PVTM, used near NPU
    • GPU_PVTM, used near GPU
    • PMU_PVTM, used near PMU

So that means not only the three CPU clusters (1x Cortex-A55 and 2x Cortex-A76) frequencies are impacted by the PVTM, but also the GPU and NPU frequencies, while for the PMU it appears to be used for low power modes as an alternative to a 32KHz clock source. The documentation further explains there are two methods of calculation (manual and auto):

A clock is generated by the oscillation ring and a frequency fixed clock clk_pvtm is used to calculate the cycles of the clock. Supposing the time period is 1s, then the clock period of oscillation ring clock is T= 1/clock_counter(s), the cell delay value is T/2.
For manual mode, user can only get one frequency result for a calculation.
For auto mode, user can set the calculation times, and get the maximum, minimum and average frequency during calculation. It also supports to generate an interrupt when the minimum or average frequency below a threshold. The threshold can be configured.

Every chip will be slightly different during manufacturing, and some may be able to reach 2.4 GHz while others not. The room temperature may also impact the performance. I’m based in the North of Thailand, and my room temperature is usually around 28°C, so it’s not impossible that my board can reach 2.4 GHz in winter (about 20°C in the morning), but is limited to about 2.3 GHz for the rest of the year…

The PVTM is probably used in conjunction with the PVTPLL (Chapter 18) which is “used to monitor the chip performance variance caused by chip process, voltage, and temperature, and generate a set of reference signals for adjusting the voltage of the chip.

I also wanted to check RK3588 Linux SDK on Gitlab as well, but I’ve just requested access from Rockchip, so we have to wait. Having said that the PVTM is not a new thing and I could find a patch submitted to mainline Linux in 2018 for the RK3288 processor, but I’ve just only noticed now. The Rockchip’s Linux CPUFreq driver documentation also mentions PVTM and how it assigns OPP values:

Rockchip’s CPUFreq driver attempts to read leakage value from eFuse and get frequency count from pvtm, then supplies the OPP framework with ‘prop’ information which is used to determine opp-microvolt-<name>property of OPPS when it is parsed by the OPP framework. This is based on operating-points-v2, but the driver can also create the “cpufreq-dt” platform_device to compatibility with operating-points.

Companies will sometimes create new part numbers for chips with the same functionality but different frequencies and Rockchip did that for RK3399K @ 2.0 GHz, RK3399 @ 1.8 GHz, and RK3399-T @ 1.5 GHz, but the small differences we’re seeing between Rockchip RK3588 processors probably did not warrant naming a new part, or it may come up later on.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

ROCK Pi 4C Plus
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
27 Comments
oldest
newest
Willy
Willy
22 days ago

Jean-Luc, not sure if you’re also reading the thread about the “debug party”, but I also shared my findings and analysis there: https://forum.radxa.com/t/rock-5b-debug-party-invitation/10483/141 In short, PVTM is an interesting way to estimate the silicon quality. It’s only a measure and not a limitation. The OPPs are conditioned on these values. It’s just that we’re missing extra OPPs in the DTS to compensate for the lower grade in our CPUs, but we could create new OPPs like we used to before. At least I think Radxa ought to do it to make sure that their customers do not face different frequencies,… Read more »

Xander
Xander
21 days ago

It’s a weird system. The PVTM is part of the silicon and therefore not in the ideal position to measure performance/quality, I don’t understand why they do not use binning.

Won’t be the first Chinese SoC with sensor defects either.

Willy
Willy
21 days ago

No, it’s the opposite. It’s part of the affected area and serves as a canary. From what I’ve read on the subject, some chips implement many PVTM clocks to try to cover the maximum possible area.

tkaiser
tkaiser
21 days ago

BTW: to get an idea about further PVTM variations in the wild I did some Geekbench data mining: https://github.com/ThomasKaiser/sbc-bench/blob/master/results/geekbench-rk3588/results.md

The ‘8 Cores @ 0.00 Hz’ entries can be skipped (no cpufreq support) and I would also skip everything prior to 2022 due to maybe other/static cpufreq OPP. Of course Geekbench’s way to ‘report’ clockspeeds is flawed but that’s all we have.

Theguyuk
Theguyuk
22 days ago

Do you still have your Mekotronics RK3588 and what speed does that give? Mekotronics have had their RK3588 available and in use for months so is it better, more mature development wise.

Theguyuk
Theguyuk
22 days ago

Have you run Linux on Mekotronics ?

I know the Mekotronics has a more stable Android with Google Play mostly working. Mind you these are designed as signage players, if I recall correctly.

Julius
Julius
22 days ago

I suspect that losing 0.1Ghz is unlikely to concern many.

In order to make comparison with a more mature release of the SOC, running the same tests on the Mekotronics would be logical.

It also has to be noted that this is a pre production board, handed out to a few in order to identify bugs and issues to be fixed.

Willy
Willy
22 days ago

It’s not a matter of “losing 0.1 GHz” but figuring why the advertised frequency may not necessarily be reached. It can translate to FPS in games or anything else, that is not trivial to explain by the casual user who may have a hard time guessing wrong that this or that distro doesn’t run at the same frequency, or that this or that perf test program could give different results between boots, especially if it may reach close to 10%. Admittedly once understood there’s nothing dramatic, but it just deserves an explanation. And this is perfectly within the type of… Read more »

Julius
Julius
21 days ago

If using FPS in games was to be used as comparison, 0.1Ghz as a percentage of the maximum 2.4Ghz is pretty much 5%. So in a game expected to run at 60FPS for optimal performance, using 5% as a broad expectation of potential loss, this would mean a game running at 59.5FPS, which nobody would ever notice, hence it not being a factor to be of any concern. Of course, with this being a pre production board, any anomalies are worth reporting such that final production can be as advertised. If it is seemed that 2.3 is the maximum then… Read more »

Theguyuk
Theguyuk
21 days ago

Gaming and emulation videos for the RK3588 have been on YouTube for months hence how it is known that RK3588 CPU, GPU is faster than a Nvidia shield Pro.

Willy
Willy
21 days ago

> So in a game expected to run at 60FPS for optimal performance, using 5% as a broad expectation of potential loss, this would mean a game running at 59.5FPS, which nobody would ever notice Your calculations look odd, 5% would give 57, and even if nobody would notice, they would notice the reported value that differs from their friends and would start looking in the wrong direction. In addition, 2208 is even 8% and it’s the highest frequency not affected by PVTM. That gives 55 FPS from 60 at 2400. Again, a reason for some people to question where… Read more »

tkaiser
tkaiser
21 days ago

> I suspect that losing 0.1Ghz is unlikely to concern many.

That’s not the point as already explained. It’s about understanding and documenting PVTM behaviour so all the crap reviews that will follow on YT get the idea.

Also it’s not ‘0.1Ghz’ but we’ve seen already just an 2256 MHz OPP (see Creepbench result for soon to be revealed Firefly Station N1) and as this blog post explained PVTM is not limited to CPU cores but also affects GPU and NPU clockspeeds and even the PMU domain and as such results with ‘gaming’ can differ even more.

tkaiser
tkaiser
21 days ago

> a more mature release of the SOC, running the same tests on the Mekotronics

Huh? Do you suffer from the same problem as TheLiarUK who can’t differentiate between boards and SoCs and hardware and software?

The ‘mother’ of all the current RK3588 thingies out there is called ‘Rockchip RK3588 EVB1 LP4 V10 Board’ since they’re all just variants of RK’s reference design. And said ‘EVB1 Board’ has been measured by sbc-bench already with just ~2320 MHz on the 3rd CPU cluster. PVTM is a design feature of recent Rockchip SoCs and not a matter of ‘maturity’.

TinLethax
21 days ago

(off topic a bit) Didn’t know you live in Thailand, me too (Thai) greeting from southern. Here in Trang always get chips hot easily (I have F1C100s running Buildroot Linux). Idle temp is 40 ish degree C. But since the CPU runs at 400 something MHz, It’ practically no different at all. I don’t have RK3588 board on hand so not quite sure how the PVTM would look like here in Trang. But I’m sure that it not gonna reach 2.4GHz

Salvador Liébana
Salvador Liébana
21 days ago

Very few games or emulators are cpu constrained but it would be interesting to know if we will be able to force at least one of the big core clusters beyond this limitation or not, since many emulators games that are cpu intensive require good single core performance for most parts. Also, while 5% may not be significant on cpu clocks for games, gpu clocks may be, and that would be difficult to measure. In fact, while we have a great tool for testing real cpu frequencies with tkaiser sbc bench (and willy) , we dont for gpu frequencies and… Read more »

tkaiser
tkaiser
21 days ago

> we dont for gpu frequencies and that’s a pain in the ass, benchmarking wise

Nope, since nobody cares. Those involved in ‘gaming’ and this other crap love to be served by numbers without meaning. It’s just like the average Android smartphone consumer: the more cores the better.

Once someone interested in this area starts to do some serious ACTIVE benchmarking that might change.

Salvador Liébana
Salvador Liébana
21 days ago

Haha dude, many do care about gaming on arm linux. And those hate android gaming for most parts. Especially with software like box64/box86/box32.
Anyway, to get any box to work with on this new platform, we need panfrost, so mainline… an year ahead to say at least.

back2future
back2future
17 days ago

Anyone ever seen statistics for pvtm values for several years?
(or dmesg logs for same SoC&pcb within years on ‘consumer level’ usage?)
thx

tkaiser
tkaiser
17 days ago

> Anyone ever seen statistics for pvtm values for several years?

Most probably Rockchip engineers. But outside RK? While PVTM is in use at least since RK3399 who took notice so far?

And how should dmesg output help if people are told to prefer mainline kernel where all the relevant BSP info is missing?

tkaiser
tkaiser
17 days ago
  • CPU: http://ix.io/456f (empty entries due to mainline kernel or only ‘Failed to get pvtm’ messages
  • Everything else: http://ix.io/456g (also lines with ‘pvtm list NULL’ filtered out)
back2future
back2future
17 days ago

thx, for the overview of pvtm values (sorted for 456f:rk3399/’diverse boards’/cpu_values and 456g:rk3399/’diverse boards’/mostly gpu values) for analyzing pvtm values alternation with surroundings/board temperatures, hw loading (cpu clusters,gpu,(npu),pmu,(memory controller?)), input voltage(s) one would need at least one single board for being on standardized/defined surroundings (at sustained, constant hw load) and fully documented, considering hw configuration (dts, bits from boot blobs, (image) maybe even a combined bootscript/bootloader/BSPkernel, so hw counter/rtc started before kernel was initialized?) the only other SBC supplier interested in such insights and providing results to consumers/customers would be Hardkernel. Maybe Rockchip engineers provide some numbers from years experience… Read more »

back2future
back2future
16 days ago

(not only rk3399 SoCs, but also a rk3328, some rk3568, rk3588 pvtm values)
dmesg clock times are low 1digit to low 10’s seconds numbers for logged pvtm values, makes assume that pvtm adjusts pvtm managed parts only on startup (no later pvtm values in dmesg, even with benchmarking loads)?

back2future
back2future
15 days ago

( just another try: cpu pvtm values http://ix.io/45mG, gpu/npu pvtm values http://ix.io/45mO )

Theguyuk
Theguyuk
17 days ago

PVTM is documented in TRM of many Rockchip SoC, from 2014- 2015 I have seen PVTM mentioned. So why the suddenly problems?

Advertisement