AM2434: EtherCAT PRU read/write time

The 150ns per byte latency is expected behavior for byte-by-byte R5F access to ICSSG SMEM through the interconnect. Here's the assessment and recommended path forward:

For your 19-byte process data, switching from byte copy to 32-bit word copy is the correct immediate optimization. This reduces the number of bus transactions from 19 to 5 (4 word reads + 1 byte for the remainder), bringing you to ~150ns per 32-bit word rather than per byte [1]. The ICSSG internal SMEM (64KB) has ~15ns access latency from PRU cores internally, but R5F access traverses the external interconnect, which adds the latency you're seeing

OK，so this works for all DPRAM read/write, SDO and PDO. Or ESC registers are also included?

Above explanation mainly apply to SDO, PDO and DPRAM read/write. Because ESC registers are also emulated via ICSS SMEM, this is technically applicable, but do you see frequent access path in stack to ESC registers cyclically which is done 8-bits at a time ?

Hi Pratheesh,

It seems that the start address of PDO is not 4-byte aligned. If I directly use 4-byte copy like below code, the drive would just go crash.

while (c>=4)
{
*(uint32_t*)d = *(uint32_t*)s;
d+=4;
s+=4;
c-=4;
}Code

I ploted the address of &pEsc[0x1100], supposed SM2 address is changing every cycle.

Then after I add 4-byte alignment at start, I cannot observe any improvement on running time.

When testing 19-byte RPDO, we do get around 500 ns improvement. The running time is reduced to around 5 us.

I wonder if any more improvement is possible. The current testing is replacing bsp_read with bsp_myread.

void bsp_myread(PRUICSS_Handle pruIcssHandle, uint8_t *pdata, uint16_t address,
              uint16_t len)
{
    uint8_t *pEsc = (uint8_t *)(((PRUICSS_HwAttrs *)(
                                     pruIcssHandle->hwAttrs))->baseAddr + PRUICSS_SHARED_RAM);
    uint8_t *d = pdata;
    const uint8_t *s = &pEsc[address];
    int c = len, remainder = 4 - ((long)s & 3);
    if (remainder != 0 && c >= remainder)
    {
        while (remainder)
        {
            *d = *s;
            d++;
            s++;
            remainder--;
        }
        c -= remainder;
    }
    while (c>=4)
    {
        *(uint32_t*)d = *(uint32_t*)s;
        d+=4;
        s+=4;
        c-=4;
    }
    while (c)
    {
        *d = *s;
        d++;
        s++;
        c--;
    }
}

Current function is attached.

mainly is ESC register 0x220 AL Event. It is handled in 1 ms, and it is OK if takes longer time.

PratheeshGangadhar said:

but do you see frequent access path in stack to ESC registers cyclically which is done 8-bits at a time ?

Jianyu Wang said:

When testing 19-byte RPDO, we do get around 500 ns improvement. The running time is reduced to around 5 us.

What optimization level is used? Can you look at disassembly level deltas

Jianyu Wang said:

I wonder if any more improvement is possible.

There some possibilities like adding PRU DMA to R5F TCM but this requires firmware modifications as well as potential stack interface changes (we have done similar thing on AM437x EtherCAT implementation via EDMA) but this is not a planned feature as of now on AM64/AM243/AM26x

https://dr-download.ti.com/software-development/driver-or-library/MD-JLNx46uE7Y/01.00.10.00/EtherCAT_Slave_Datasheet.pdf 

our optimization level is OIptimize most (o3), the assembly is as follows.

70122234 <bsp_myread>:
70122234: e52db004       str  r11, [sp, #-4]!
70122238: e28db000       add  r11, sp, #0
7012223c: e24dd02c       sub  sp, sp, #44
70122240: e50b0020       str  r0, [r11, #-32]
70122244: e50b1024       str  r1, [r11, #-36]
70122248: e1a01002       mov  r1, r2
7012224c: e1a02003       mov  r2, r3
70122250: e1a03001       mov  r3, r1
70122254: e14b32b6       strh  r3, [r11, #-38]
70122258: e1a03002       mov  r3, r2
7012225c: e14b32b8       strh  r3, [r11, #-40]
70122260: e51b3020       ldr  r3, [r11, #-32]
70122264: e5933004       ldr  r3, [r3, #4]
70122268: e5933004       ldr  r3, [r3, #4]
7012226c: e2833801       add  r3, r3, #65536
70122270: e50b3018       str  r3, [r11, #-24]
70122274: e51b3024       ldr  r3, [r11, #-36]
70122278: e50b3008       str  r3, [r11, #-8]
7012227c: e15b32b6       ldrh  r3, [r11, #-38]
70122280: e51b2018       ldr  r2, [r11, #-24]
70122284: e0823003       add  r3, r2, r3
70122288: e50b300c       str  r3, [r11, #-12]
7012228c: e15b32b8       ldrh  r3, [r11, #-40]
70122290: e50b3010       str  r3, [r11, #-16]
70122294: e51b300c       ldr  r3, [r11, #-12]
70122298: e2033003       and  r3, r3, #3
7012229c: e2633004       rsb  r3, r3, #4
701222a0: e50b3014       str  r3, [r11, #-20]
701222a4: e51b3014       ldr  r3, [r11, #-20]
701222a8: e3530000       cmp  r3, #0
701222ac: 0a000026       beq  0x7012234c <bsp_myread+0x118> @ imm = #152
701222b0: e51b2010       ldr  r2, [r11, #-16]
701222b4: e51b3014       ldr  r3, [r11, #-20]
701222b8: e1520003       cmp  r2, r3
701222bc: ba000022       blt  0x7012234c <bsp_myread+0x118> @ imm = #136
701222c0: ea00000c       b  0x701222f8 <bsp_myread+0xc4> @ imm = #48
701222c4: e51b300c       ldr  r3, [r11, #-12]
701222c8: e5d32000       ldrb  r2, [r3]
701222cc: e51b3008       ldr  r3, [r11, #-8]
701222d0: e5c32000       strb  r2, [r3]
701222d4: e51b3008       ldr  r3, [r11, #-8]
701222d8: e2833001       add  r3, r3, #1
701222dc: e50b3008       str  r3, [r11, #-8]
701222e0: e51b300c       ldr  r3, [r11, #-12]
701222e4: e2833001       add  r3, r3, #1
701222e8: e50b300c       str  r3, [r11, #-12]
701222ec: e51b3014       ldr  r3, [r11, #-20]
701222f0: e2433001       sub  r3, r3, #1
701222f4: e50b3014       str  r3, [r11, #-20]
701222f8: e51b3014       ldr  r3, [r11, #-20]
701222fc: e3530000       cmp  r3, #0
70122300: 1affffef       bne  0x701222c4 <bsp_myread+0x90> @ imm = #-68
70122304: e51b2010       ldr  r2, [r11, #-16]
70122308: e51b3014       ldr  r3, [r11, #-20]
7012230c: e0423003       sub  r3, r2, r3
70122310: e50b3010       str  r3, [r11, #-16]
70122314: ea00000c       b  0x7012234c <bsp_myread+0x118> @ imm = #48
70122318: e51b300c       ldr  r3, [r11, #-12]
7012231c: e5932000       ldr  r2, [r3]
70122320: e51b3008       ldr  r3, [r11, #-8]
70122324: e5832000       str  r2, [r3]
70122328: e51b3008       ldr  r3, [r11, #-8]
7012232c: e2833004       add  r3, r3, #4
70122330: e50b3008       str  r3, [r11, #-8]
70122334: e51b300c       ldr  r3, [r11, #-12]
70122338: e2833004       add  r3, r3, #4
7012233c: e50b300c       str  r3, [r11, #-12]
70122340: e51b3010       ldr  r3, [r11, #-16]
70122344: e2433004       sub  r3, r3, #4
70122348: e50b3010       str  r3, [r11, #-16]
7012234c: e51b3010       ldr  r3, [r11, #-16]
70122350: e3530003       cmp  r3, #3
70122354: caffffef       bgt  0x70122318 <bsp_myread+0xe4> @ imm = #-68
70122358: ea00000c       b  0x70122390 <bsp_myread+0x15c> @ imm = #48
7012235c: e51b300c       ldr  r3, [r11, #-12]
70122360: e5d32000       ldrb  r2, [r3]
70122364: e51b3008       ldr  r3, [r11, #-8]
70122368: e5c32000       strb  r2, [r3]
7012236c: e51b3008       ldr  r3, [r11, #-8]
70122370: e2833001       add  r3, r3, #1
70122374: e50b3008       str  r3, [r11, #-8]
70122378: e51b300c       ldr  r3, [r11, #-12]
7012237c: e2833001       add  r3, r3, #1
70122380: e50b300c       str  r3, [r11, #-12]
70122384: e51b3010       ldr  r3, [r11, #-16]
70122388: e2433001       sub  r3, r3, #1
7012238c: e50b3010       str  r3, [r11, #-16]
70122390: e51b3010       ldr  r3, [r11, #-16]
70122394: e3530000       cmp  r3, #0
70122398: 1affffef       bne  0x7012235c <bsp_myread+0x128> @ imm = #-68
7012239c: e320f000       nop
701223a0: e320f000       nop
701223a4: e28bd000       add  sp, r11, #0
701223a8: e49db004       ldr  r11, [sp], #4
701223ac: e12fff1e       bx  lr

Hi Pratheesh,

Since EDMA is not supported on AM24 so far, please help have a look if there is any further optimizations could be done on the assembly code (for function bsp_myread.c) customer provided above, thanks.

In the meanwhile, customer will analyze if the current configuration setup could meet their application level target or not. If it's not and no other optimizations could try then we may discuss the EDMA porting on AM24 in the future support later.

Thanks,

Kevin