Explore the PIE capabilities on the ESP32-P4 · Espressif Developer Portal

[giscus[bot]]

Explore the PIE capabilities on the ESP32-P4 · Espressif Developer Portal

The developer resources in just one place!

https://developer.espressif.com/blog/2024/12/pie-introduction/

[Emill]

Has the *.QUP variant for all the *.VMULAS.* instructions been removed in ESP32-P4 that was present in ESP32-S3? It was really useful...

[YanKE01]

The TRM for ESP32-P4 is not fully ready yet and will require some more time.

[razor7788]

The TRM for ESP32-P4 is not fully ready yet and will require some more time.

Is there any update news aboout TRM for ESP32-P4?

[YanKE01]

The TRM for the ESP32-P4 is still not publicly available. If you wish to obtain it, you may try contacting Espressif's technical support through official website.

[CraigHutchinson]

Any updates on this yet... its nearly been a year?

[BitsForPeople]

@CraigHutchinson Some more information I found: https://esp32.com/viewtopic.php?t=48015
Still nothing as to the actual specification of the instructions, but a good starting point for experimenting.

[BitsForPeople]

In the inline assembly example, the employed 'manual' way to allocate registers and save them on the stack should not be done. The way it is now, it's somewhat inefficient, and, more importantly, may result in corruption/incorrect operation, e.g. if the compiler decides to (inline the add_pie() function and) provide "y" in register x31 to the assembly fragment (i.e. %1 = x31).

The better approach is to let the compiler handle the allocation of the (non-Q) registers, like

void add_pie(int16_t *x, int16_t *y, int16_t *z, int n)
{
    int i = 0;
    asm volatile(
        "loop:\n"
        " beq %[i], %[n], exit \n"
        " esp.vld.128.ip q0, %[x], 16 \n"
        " esp.vld.128.ip q1, %[x], 16 \n"
        " esp.vld.128.ip q2, %[x], 16 \n"
        " esp.vld.128.ip q3, %[x], 16 \n"
		
        " esp.vld.128.ip q4, %[y], 16 \n"
        " esp.vld.128.ip q5, %[y], 16 \n"
        " esp.vld.128.ip q6, %[y], 16 \n"
        " esp.vld.128.ip q7, %[y], 16 \n"

        " esp.vadd.s16 q0, q0, q4 \n"
        " esp.vadd.s16 q1, q1, q5 \n"
        " esp.vadd.s16 q2, q2, q6 \n"
        " esp.vadd.s16 q3, q3, q7 \n"

        " esp.vst.128.ip q0, %[z], 16 \n"
        " esp.vst.128.ip q1, %[z], 16 \n"
        " esp.vst.128.ip q2, %[z], 16 \n"
        " esp.vst.128.ip q3, %[z], 16 \n"

        " addi %[i], %[i], 32 \n"
        " j loop \n"
        "exit:\n"
        : [x] "+&r" (x), [y] "+&r" (y) , [z] "+&r" (z), [i] "+&r" (i)
		: [n] "r" (n)    
    );
}

[ctag-fh-kiel]

How can I make use of the optimized memcpy on the p4, is that already part of newlib, or do I have to manually add this?

[BitsForPeople]

Performance

The SIMD-optimized implementation achieves 180MB/s for PSRAM→IRAM transfers using the extended instruction set.

The optimized memcpy is actually critical for the memory management layer - efficient data movement between memory hierarchies directly impacts inference latency.

Notice that the bottleneck here is the PSRAM, not the CPU. You'll likely get the same speed via standard memcpy() whenever PSRAM is involved.

Active cache management (prefetch,invalidate via semi-documented ROM functions or direct register access) can help hide PSRAM latencies.

[ctag-fh-kiel]

Some results with 128KB L2 cache size.

Copying a block of 256KiB of SRAM containing random numbers to PSRAM, filling 16MiB.
Without PIE optimizations:
I (12420) test_perf: memcpy SRAM->PSRAM: 16.00 MiB in 188547 us -> 84.86 MiB/s
I (12580) test_perf: memcpy PSRAM->SRAM: 16.00 MiB in 152169 us -> 105.15 MiB/s
With PIE optimizations:
I (34262) test_perf: memcpy SRAM->PSRAM: 16.00 MiB in 135228 us -> 118.32 MiB/s
I (34402) test_perf: memcpy PSRAM->SRAM: 16.00 MiB in 138072 us -> 115.88 MiB/s
So, for this test, there is a small benefit of PIE optimizations.

Results for memcpy 8MiB PSRAM -> PSRAM.
Without PIE optimizations:
I (140291) test_perf: memcpy PSRAM->PSRAM: 8.00 MiB in 156996 us -> 50.96 MiB/s
With PIE optimizations:
I (24361) test_perf: memcpy PSRAM->PSRAM: 8.00 MiB in 140098 us -> 57.10 MiB/s
Again a bit faster.

Results for memcpy 128KiB SRAM -> SRAM.
Without PIE optimizations:
I (7691) test_perf: memcpy SRAM->SRAM: 0.12 MiB in 355 us -> 352.11 MiB/s
With PIE optimizations:
I (23290) test_perf: memcpy SRAM->SRAM: 0.12 MiB in 231 us -> 541.13 MiB/s
So here the PIE-enabled memcpy is significantly faster.

I am wondering why https://github.com/espressif/esp-dl/blob/master/esp-dl/dl/tool/isa/esp32p4/dl_esp32p4_memcpy.S
is not the default memcpy in newlib for the P4, any ideas?

[BoumedineBillal]

Hi, Thanks for your comprehensive response! This is very interesting and a collaboration would be great! Let me know how to get in touch.

Hi,

Thanks for reaching out! Somehow I completely missed the GitHub notification, my bad.

I saw CTAG works on audio/music tech, which is actually pretty relevant. The compiler I'm building deals with the same kind of problems real-time inference, memory bottlenecks (IRAM/PSRAM mess), SIMD optimization, quantized models. ESP32-P4 is where I'm starting but the goal is making it work across different platforms.

On the side I've been using esp-dl for actual deployment to understand what works and what breaks. Recently wrapped up a vehicle detection project that helped me figure out the real constraints - got 87.8% accuracy at 118ms per frame, 2.6MB model size, basically no accuracy loss from quantization. Used MobileNetV2 with some aggressive optimizations (layerwise equalization, bias correction, then QAT fine-tuning). Made 3 different variants from 70ms to 459ms depending on what you need.

Project is here if you want to check it out: https://github.com/boumedinebillal/esp32-p4-vehicle-classifier
Demo video: https://www.youtube.com/watch?v=fISUXHYNV20

This hands-on work is feeding directly into the compiler design, you learn a lot about what the hardware can actually do vs what looks good on paper.

Curious what kind of audio ML stuff you're dealing with. I'm guessing the optimization challenges are similar but probably hit different bottlenecks?

Contact:

• boumedinebillal@gmail.com
• linkedin.com/in/boumedine-billal-a9a850239

Would be great to talk more about this.

[BoumedineBillal]

Some results with 128KB L2 cache size.

Copying a block of 256KiB of SRAM containing random numbers to PSRAM, filling 16MiB. Without PIE optimizations: I (12420) test_perf: memcpy SRAM->PSRAM: 16.00 MiB in 188547 us -> 84.86 MiB/s I (12580) test_perf: memcpy PSRAM->SRAM: 16.00 MiB in 152169 us -> 105.15 MiB/s With PIE optimizations: I (34262) test_perf: memcpy SRAM->PSRAM: 16.00 MiB in 135228 us -> 118.32 MiB/s I (34402) test_perf: memcpy PSRAM->SRAM: 16.00 MiB in 138072 us -> 115.88 MiB/s So, for this test, there is a small benefit of PIE optimizations.

Results for memcpy 8MiB PSRAM -> PSRAM. Without PIE optimizations: I (140291) test_perf: memcpy PSRAM->PSRAM: 8.00 MiB in 156996 us -> 50.96 MiB/s With PIE optimizations: I (24361) test_perf: memcpy PSRAM->PSRAM: 8.00 MiB in 140098 us -> 57.10 MiB/s Again a bit faster.

Results for memcpy 128KiB SRAM -> SRAM. Without PIE optimizations: I (7691) test_perf: memcpy PSRAM->SRAM: 0.12 MiB in 355 us -> 352.11 MiB/s With PIE optimizations: I (23290) test_perf: memcpy SRAM->SRAM: 0.12 MiB in 231 us -> 541.13 MiB/s So here the PIE-enabled memcpy is significantly faster.

I am wondering why https://github.com/espressif/esp-dl/blob/master/esp-dl/dl/tool/isa/esp32p4/dl_esp32p4_memcpy.S is not the default memcpy in newlib for the P4, any ideas?

Interesting benchmarks - the SRAM→SRAM improvement is pretty significant (352 → 541 MiB/s).

About why it's not the default: My guess is PIE acts kind of like a coprocessor on the P4 - it's disabled by default and needs manual activation. From the TRM (section 1.7.2.3, page 108):
https://documentation.espressif.com/esp32-p4-chip-revision-v1.3_technical_reference_manual_en.pdf

• PIE starts disabled, throws illegal instruction exceptions if you try using it without enabling
• Has to be explicitly enabled via mext_pie_status.STATE
• Requires state management during context switching (OFF/INITIAL/CLEAN/DIRTY states)
• If a context uses PIE and gets interrupted, the OS has to save/restore the entire PIE register file

So making it the default memcpy would force every application to pay the context switching overhead, even if they're not doing any ML inference or SIMD work. Plus you'd have the problem where some random library or function could disable PIE before your memcpy runs, and then boom - illegal instruction exception. The current approach lets you opt-in when you actually need it, makes sense for general-purpose code but yeah, annoying for ML workloads where you'd want it always on.

[BitsForPeople]

The performance figures seem really low for the P4. I expected much more. The S3 for reference achieves ~1.9GB/s: https://github.com/project-x51/esp32-s3-memorycopy

[BoumedineBillal]

ESP32-P4 PIE-Optimized memcpy Benchmark

Test Results

Just ran some tests on my board with 128KB L2 cache config. Got pretty similar results:

========================================
ESP32-P4 Optimized memcpy Test
========================================
Buffer size: 128 KB
Iterations: 10

TEST 1: PSRAM → SRAM
====================
Average time: 673.2 us
Bandwidth: 185.7 MB/s

TEST 2: SRAM → SRAM
====================
Average time: 161.3 us
Bandwidth: 775.0 MB/s

SUMMARY
=======
PSRAM → SRAM: 185.7 MB/s
SRAM → SRAM:  775.0 MB/s
Speedup: 4.17x

PSRAM theoretical max: ~200 MB/s
========================================

Analysis

The SRAM→SRAM is significantly faster, around 4-5x speedup compared to PSRAM access. My PSRAM numbers are slightly higher than the earlier benchmarks, probably because I'm running at 200MHz PSRAM speed.

The PSRAM→SRAM hitting ~185 MB/s makes sense - pretty close to the theoretical 200 MB/s limit. The bottleneck is definitely the PSRAM interface, not the CPU or cache.

Test Code

#include <stdio.h>
#include <stdint.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_heap_caps.h"
#include "esp_timer.h"
#include "rom/cache.h"

extern "C" {
void dl_esp32p4_memcpy(void *dst, const void *src, const size_t n);
}

#define BUFFER_SIZE (128 * 1024)
#define EVICT_SIZE (256 * 1024)
#define ALIGNMENT 128
#define NUM_ITERATIONS 10

static volatile uint64_t g_prevent_optimization = 0;

static void force_cache_eviction(volatile uint8_t *evict_buf)
{
    volatile uint64_t sum = 0;
    for (size_t i = 0; i < EVICT_SIZE; i += 64) {
        sum += evict_buf[i];
    }
    g_prevent_optimization += sum;
    asm volatile("fence" ::: "memory");
}

static void test_optimized_memcpy()
{
    printf("\n========================================\n");
    printf("ESP32-P4 Optimized memcpy Test\n");
    printf("========================================\n");
    printf("Buffer size: 128 KB\n");
    printf("Iterations: %d\n\n", NUM_ITERATIONS);

    volatile uint8_t *psram_src = (volatile uint8_t *)heap_caps_aligned_alloc(
        ALIGNMENT, BUFFER_SIZE, MALLOC_CAP_SPIRAM);
    uint8_t *sram_dst = (uint8_t *)heap_caps_aligned_alloc(
        ALIGNMENT, BUFFER_SIZE, MALLOC_CAP_INTERNAL);
    uint8_t *sram_src = (uint8_t *)heap_caps_aligned_alloc(
        ALIGNMENT, BUFFER_SIZE, MALLOC_CAP_INTERNAL);
    volatile uint8_t *evict_buf = (volatile uint8_t *)heap_caps_aligned_alloc(
        ALIGNMENT, EVICT_SIZE, MALLOC_CAP_SPIRAM);

    if (!psram_src || !sram_dst || !sram_src || !evict_buf) {
        printf("ERROR: Allocation failed\n");
        return;
    }

    for (size_t i = 0; i < BUFFER_SIZE; i++) {
        psram_src[i] = (uint8_t)(i & 0xFF);
        sram_src[i] = (uint8_t)((i + 128) & 0xFF);
    }
    for (size_t i = 0; i < EVICT_SIZE; i++) {
        evict_buf[i] = (uint8_t)(i & 0xFF);
    }

    printf("TEST 1: PSRAM → SRAM\n");
    printf("====================\n");

    uint64_t total_psram_us = 0;

    for (int i = 0; i < NUM_ITERATIONS; i++) {
        force_cache_eviction(evict_buf);
        Cache_Invalidate_Addr(CACHE_MAP_L2_CACHE, (uint32_t)psram_src, BUFFER_SIZE);
        vTaskDelay(pdMS_TO_TICKS(10));

        asm volatile("fence" ::: "memory");

        int64_t start = esp_timer_get_time();
        dl_esp32p4_memcpy(sram_dst, (const void *)psram_src, BUFFER_SIZE);
        asm volatile("fence" ::: "memory");

        int64_t end = esp_timer_get_time();

        volatile uint64_t check = 0;
        for (size_t j = 0; j < BUFFER_SIZE; j += 64) {
            check += sram_dst[j];
        }
        g_prevent_optimization += check;

        total_psram_us += (end - start);
    }

    float avg_psram_us = (float)total_psram_us / NUM_ITERATIONS;
    float psram_bw = (BUFFER_SIZE / (1024.0f * 1024.0f)) / (avg_psram_us / 1e6f);

    printf("Average time: %.1f us\n", avg_psram_us);
    printf("Bandwidth: %.1f MB/s\n\n", psram_bw);

    printf("TEST 2: SRAM → SRAM\n");
    printf("====================\n");

    uint64_t total_sram_us = 0;

    for (int i = 0; i < NUM_ITERATIONS; i++) {
        asm volatile("fence" ::: "memory");

        int64_t start = esp_timer_get_time();
        dl_esp32p4_memcpy(sram_dst, sram_src, BUFFER_SIZE);
        asm volatile("fence" ::: "memory");

        int64_t end = esp_timer_get_time();

        volatile uint64_t check = 0;
        for (size_t j = 0; j < BUFFER_SIZE; j += 64) {
            check += sram_dst[j];
        }
        g_prevent_optimization += check;

        total_sram_us += (end - start);
    }

    float avg_sram_us = (float)total_sram_us / NUM_ITERATIONS;
    float sram_bw = (BUFFER_SIZE / (1024.0f * 1024.0f)) / (avg_sram_us / 1e6f);

    printf("Average time: %.1f us\n", avg_sram_us);
    printf("Bandwidth: %.1f MB/s\n\n", sram_bw);

    printf("SUMMARY\n");
    printf("=======\n");
    printf("PSRAM → SRAM: %.1f MB/s\n", psram_bw);
    printf("SRAM → SRAM:  %.1f MB/s\n", sram_bw);
    printf("Speedup: %.2fx\n", sram_bw / psram_bw);
    printf("\nPSRAM theoretical max: ~200 MB/s\n");
    printf("Prevent optimization: %llu\n", g_prevent_optimization);
    printf("========================================\n\n");

    heap_caps_free((void *)psram_src);
    heap_caps_free(sram_dst);
    heap_caps_free(sram_src);
    heap_caps_free((void *)evict_buf);
}

extern "C" void app_main(void)
{
    vTaskDelay(pdMS_TO_TICKS(100));
    test_optimized_memcpy();
}

Configuration

# sdkconfig.defaults.esp32p4

CONFIG_IDF_TARGET="esp32p4"
CONFIG_ESPTOOLPY_FLASHMODE_QIO=y
CONFIG_ESPTOOLPY_FLASHSIZE_16MB=y
CONFIG_PARTITION_TABLE_CUSTOM=y
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions.csv"
CONFIG_SPIRAM=y
CONFIG_SPIRAM_SPEED_200M=y
CONFIG_CACHE_L2_CACHE_128KB=y
CONFIG_CACHE_L2_CACHE_LINE_128B=y
CONFIG_ESP_SYSTEM_ALLOW_RTC_FAST_MEM_AS_HEAP=n
CONFIG_ESP_INT_WDT=n
CONFIG_ESP_TASK_WDT_EN=n
CONFIG_IDF_EXPERIMENTAL_FEATURES=y

Key Configuration Parameters

• PSRAM Speed: 200 MHz (CONFIG_SPIRAM_SPEED_200M=y)
• L2 Cache Size: 128 KB (CONFIG_CACHE_L2_CACHE_128KB=y)
• Cache Line Size: 128 bytes (CONFIG_CACHE_L2_CACHE_LINE_128B=y)

Dependencies

This test requires the PIE-optimized memcpy from esp-dl:

Source: https://github.com/espressif/esp-dl/blob/master/esp-dl/dl/tool/isa/esp32p4/dl_esp32p4_memcpy.S

Build Instructions

[ctag-fh-kiel]

I can confirm your results, most speed improvement SRAM->SRAM:

TEST 1: PSRAM → SRAM

Optimized:
Average time: 679.3 us
Bandwidth: 184.0 MB/s
Non-optimized:
Average time: 801.0 us
Bandwidth: 156.1 MB/s

TEST 2: SRAM → SRAM

Optimized:
Average time: 160.8 us
Bandwidth: 777.4 MB/s
Non-optimized:
Average time: 350.7 us
Bandwidth: 356.4 MB/s

[BitsForPeople]

The esp-dl code seems to not make the most efficient use of the SIMD instructions.
I have made a P4 variant of memory copy code I originally wrote for the S3:

https://gist.github.com/BitsForPeople/b030f9b6417e4091b955c00fd55ddcc0

If you want, please give it a try and let us know the result.
I don't have a P4, so it's not actually tested, but its S3 sibling is; and the P4 version compiles. If the P4 PIE instructions work the same as the S3 ones with similar names, it should work.

[ctag-fh-kiel]

Seems that your version is the fastest :)
https://github.com/ctag-fh-kiel/-esp32p4_memcpy_pie_benchmark

On another note, I also tried to test the FPU:
https://github.com/ctag-fh-kiel/esp32p4_fpu_benchmark

Critical comments / remarks are welcome!

[BitsForPeople]

Yay! ;-)
Thanks for testing!

Still a little disappointed by the P4 SRAM's speed. The 'same' cpy_mem() on the S3 @ 240MHz is a lot faster:

I (880) Memory Copy: cpy_mem IRAM->IRAM took 12863 CPU cycles = 1822.09 MB/s
(copying 100KB from Internal RAM to Internal RAM, a.k.a. SRAM)

[bitbank2]

I wrote a blog post to help you transition from writing ESP32-S3 SIMD code to the ESP32-P4:
https://bitbanksoftware.blogspot.com/2026/04/esp32-p4-simd-explained.html

[cavac]

With the help of AI (claude) i wrote a SIMD test app (P4 on the Tanmatsu device) and document the SIMD instruction we could find:

https://github.com/nullislandspace/tanmatsu-simd-tests/blob/main/PIE_REFERENCE.md

Not sure how helpful this is to anyone, but at least its a start.

[BitsForPeople]

Thanks. However, there appear to be a lot of obvious errors in that document (and the corresponding test code), from "256-bit accumulator: QACC", to "Widening load: read 8 bytes", to "FFT twiddle broadcast: loads two consecutive 16-bit values", to "P4 does NOT apply >>4 shift (differs from ESP32-S3)", and many more.
Would you be willing to work those out?

[cavac]

I can take a look if i have some free time. But ultimately, it comes down to Espressif to create a complete and validated documentation. I'm just a random guys on the internet, trying to reverse engineer the command set as a side project...

[BitsForPeople]

I'm just a random guys on the internet, trying to reverse engineer the command set as a side project...

Sure. And as you've shown, AI is of absolutely no use for this.

[BitsForPeople]

Some more information (brief description of (many of?) the instructions) here:
https://github.com/espressif/esp-dl/blob/master/tools/agents/skills/esp32p4-pie-simd/references/instructions.md