S32GのトピックRe: Question about the memcpy performance on the m7 core.

Question about the memcpy performance on the m7 core.

seungtake — Sun, 19 Oct 2025 23:45:09 GMT

I have a question about the memcpy speed on the M7 core.

For data sharing between the M7 and A53 cores, I implemented a simple example based on the IPCF demo. The code is straightforward: every second, the M7 copies about 3 MB of data into a non-cacheable memory region using memcpy, then triggers an MSI interrupt to let the Linux side (running on the A53) read the data. The data size is fixed, and there are no management structures like “managed/unmanaged” buffers — the M7 simply writes to a fixed memory address, and the A53 only reads after receiving the interrupt.

However, the memcpy operation on the M7 side seems significantly slower than expected. When measured with TRACE32, the memcpy function alone takes about 180 ms. I understand the measurement might include some debugger latency, but this still feels unusually long.

Is this memcpy speed to non-cacheable memory typical on the M7 core?
Currently, DMA is not used, and the addresses and data size are 8‑byte aligned.

I would appreciate any advice on how to improve the memcpy performance in this scenario.

Re: Question about the memcpy performance on the m7 core.

chenyin_h — Mon, 20 Oct 2025 03:32:40 GMT

Hello, @seungtake

Thanks for your post.

May I know if you are using S32G2 or G3? What is the frequency set on your M7?

Chenyin

Re: Question about the memcpy performance on the m7 core.

seungtake — Mon, 20 Oct 2025 05:58:56 GMT

Hi, Chenyin

I am currently using the S32G399ARDB3 reference board. I am using the device tree provided in BSP44.0 and starting the M7 core through startm7 in u-boot. Could you please advise how I can check the M7 clock frequency?

Thank you.

Re: Question about the memcpy performance on the m7 core.

chenyin_h — Mon, 20 Oct 2025 07:06:51 GMT

Hello, @seungtake

Thanks for your reply.

If you did not use the M core application to set the frequency, then it is usually 400M for your M7 core

Would you share more details of your test functions? it is a memcpy test from SRAM to SRAM, or SRAM to DRAM or else?

By checking the related documents, I do not find similar formal performance data that could be shared for reference.

Chenyin

Re: Question about the memcpy performance on the m7 core.

seungtake — Mon, 20 Oct 2025 07:48:56 GMT

Re: Question about the memcpy performance on the m7 core.

seungtake — Tue, 21 Oct 2025 05:56:03 GMT

Hi, @chenyin_h

Yes, I did not change the frequency on my m7 application.

My test code copies data chunks from SRAM to SRAM.

And my code as below

static int32_t priv_svc_lipcf_cqueue_enqueue(struct lipcf_shm_cqueue_t* cqueue, uint8_t* buf, uint32_t size)
{
int32_t ret = 0;

uint32_t queue_end = 0;
uint32_t first_chunk_size = 0;
uint32_t second_chunk_size = 0;

ret = priv_svc_lipcf_check_ptr(cqueue);

if (ret == 0) {
ret = priv_svc_lipcf_check_ptr(buf);
}

if (ret == 0) {
queue_end = cqueue->queue_base + cqueue->queue_size;
if ((cqueue->queue_head + size) <= queue_end) {
memcpy((void*)(cqueue->queue_head), (void*)(buf), size);
cqueue->queue_head += size;
if (cqueue->queue_head >= queue_end) {
cqueue->queue_head = cqueue->queue_base;
}
}
else {
first_chunk_size = (queue_end - cqueue->queue_head);
second_chunk_size = (size - first_chunk_size);
if (first_chunk_size > 0) {
memcpy((void*)(cqueue->queue_head), (void*)(buf), first_chunk_size);
}

if (second_chunk_size > 0) {
memcpy((void*)(cqueue->queue_base), (void*)(buf + first_chunk_size), second_chunk_size);
}
cqueue->queue_head = cqueue->queue_base + second_chunk_size;
}

if (cqueue->queue_head == cqueue->queue_tail) {
cqueue->queue_full = 1;
}

ret = size;
}

return ret;
}

Thank you.

Re: Question about the memcpy performance on the m7 core.

chenyin_h — Wed, 22 Oct 2025 11:08:11 GMT

Hello, @seungtake

Thanks for your reply

What is the implementation of your memcpy? using some kinds of lib or implemented yourself?

What is your optimization level used for building the libs and/or your test application?

Chenyin

Re: Question about the memcpy performance on the m7 core.

seungtake — Thu, 23 Oct 2025 21:47:05 GMT

Hi, @chenyin_h

I'm using the memcpy implementation from the GCC library. GCC version: gcc-10.2.0-Earmv7GCC-eabi (downloaded from the NXP site) Optimization level: -Os (optimize for code size)

Thank you.

Re: Question about the memcpy performance on the m7 core.

chenyin_h — Fri, 24 Oct 2025 03:48:30 GMT

Hello, @seungtake

Thanks for your information.

I will check if there are some additional benchmark could be or had done for this SRAM performance query, it may take some time and I will be back if any updates found.

Thanks for your understanding.

Chenyin

Re: Question about the memcpy performance on the m7 core.

chenyin_h — Tue, 28 Oct 2025 09:47:41 GMT

Hello, @seungtake

I understand that currently you measured the performance via the debugger, may I know if it is possible to measure it with the timer, in order for obtaining more accurate results?

Chenyin

Re: Question about the memcpy performance on the m7 core.

seungtake — Tue, 28 Oct 2025 22:38:58 GMT

Hi, @chenyin_h

Yes, I will test with the OS timer or hardware timer instead ofo the debugger and then let you know the result.

Thank you.

Re: Question about the memcpy performance on the m7 core.

seungtake — Tue, 04 Nov 2025 22:33:59 GMT

Hi, @chenyin_h

I measured the SRAM to SRAM copy time using the STM timer.

The measurement code is as follows, and the STM module clock was checked in Linux.

STM module clock = 132206143

<test code>

stm->CR = 0x00000D00; // Divider=13 for ~98ns resolution
stm->CNT = 0; // Init counter
stm->CR |= 0x00000001;

memcpy((void*)(0x35000000), (void*)(buf_ptr), total_send_size);

stm->CR &= ~(0x00000001); // stop timer
end_time = stm->CNT;
elapsed_ticks = end_time;
// STM Module Clock: 132,206,143Hz, Divider=13 → Timer freq = 10,169,703Hz
// Period = 1,000,000,000ns ÷ 10,169,703 = 98.33ns/tick
elapsed_time_ns = elapsed_ticks * 98;
elapsed_time_us = elapsed_time_ns / 1000;
elapsed_time_ms = elapsed_time_us / 1000;

elapsed_ticks = 1761109
elapsed_time_ms = 172

Although the calculation was approximate, the actual time taken is about 171 ms, which is only about 10 ms different from the measurement result using the debugger.
Will using eDMA make the speed faster? Basically, DMA increases the core’s utilization, so I’m not sure how much performance improvement there will be, but if eDMA transfers data in bursts, I am considering trying it.

Re: Question about the memcpy performance on the m7 core.

chenyin_h — Wed, 05 Nov 2025 02:46:28 GMT

Thanks for sharing more information. @seungtake

1. Yes, you may try it with DMA to see if there are any improvements.

2. Currently, from available performance data I had, I did not find similar formal benchmark data for your reference, but I have discussed it internally to search for further resources, if any feedback or valuable data would be shared, I will reply you

Thanks

Chenyin