This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCU-PLUS-SDK-AM243X: IPC module related questions

Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: SYSCONFIG

Hi,

Currently, I have the AM243x EVM (TMDS243GPEVM) on which I am running some performance tests for IPC module. I had a few questions regarding this, since I might have missed it in the documentation:

1. I read in the documentation that the underlying HW Mailbox mechanism is safety certified (please correct me if I am wrong). May I know if the IPC SW module is also safety certified? Till what level are both the Mailbox and the IPC SW module safety certified (SIL 3 or some other level)?

Test Setup: I continuously sent 100 messages of different buffer sizes (10 bytes, 100 bytes, 200 bytes and so on - fully packed buffer) between different cores through IPC RP Message module (I configured it using SysConfig as appropriate). I recorded the time taken to send messages between different cores for comparison of performance (calculated the average time taken to send one message). 

2. I noticed that the time taken to send one message from R5F0-0 core to M4F0-0 (for example - 99.34 us for 300 bytes message buffer) is slower than the time taken to send one message from M4F0-0 to R5F0-0 (for example - 27.32 us for 300 bytes message buffer). I am trying to understand why there is such a big difference, and why R5 is taking more time to send a message than M4? Is it because R5 is on a higher frequency and sending more messages than M4 can read at a given point of time? Or is it something else?

3. I noticed that the time taken to send one message from R5F1-0 core to M4F0-0 is slightly slower than the time taken to send one message from R5F0-0 core to M4F0-0 (consistently lower for all buffer sizes tested). I am trying to understand what the reason could be for this result, since I was expecting the time taken to be the fairly same between R5F0-0 to M4F and R5F1-0 to M4F?


If you can kindly shed any light on these matters, it would help a lot for my team to make some critical decisions. 
Please let me know if there are any other details you require.

Thank you,

Himel

  • Hi Himel,

    I am looking into this query, however my first point would be that the architecture of the R5 and M4 cores being different, may be the M4 core's software and interrupt overhead is much smaller than that of the R5f core. However, I'll come back with a proper explanation for this.

    Thanks,
    G Kowshik

  • Hi Kowshik,
    Thank you. Looking forward to your reply. 
    Our team is also very interested in finding out if IPC SW module is safety certified and till what level, if so. Please let me know once you find out? 

    Regards,

    Himel

  • Hi Himel,

    I have found the reason for the increase in the time you're seeing, let me give you a overview of our IPC comm at mailbox level. 

    The R5 core frequency is 400Mhz 

    The M4 core frequency is 200Mhz

    So basically when R5 wants to send a message to HSM, it writes to the mailbox of HSM triggers an interrupt, then HSM comes up and it reads the mail box memory. Now, the bottle neck or the latency you're seeing is because the read operation done by the HSM is very slow due to slower operating clock. However, on the other hand, when HSM sends the message to R5,. the time is faster because R5's operating frequency is much higher. The same applies to the other R5 cores as well (you'd see slighter change in the timing). Hope this explains your query.

    Our team is also very interested in finding out if IPC SW module is safety certified and till what level, if so. Please let me know once you find out?

    Regarding this, currently our SDK's IPC communication is not safety certified, however there is a plan to make a safeIPC version of the IPC we have there by complying the safety. However, we don't have any timeline that we can propose at the moment as the internal timeline freeze hasn't happened yet and this is just in the pipeline. However, the migration to this safeIPC will be ensured to be smooth and no major hassle will be there for the customer as this is more of a design change.

    Thanks,
    G Kowshik

  • Hi Kowshik,

    Thank you for the prompt response. Yes, that clears up a lot of our doubts about IPC and the operating frequency. That is what we were suspecting as well but wanted to confirm. 
    Regarding the safety, is it possible to directly access the underlying HW Mailbox API, since that is safety certified? 
    And there is no estimation you can provide on when we can expect to see safeIPC, as that will also help us make some decisions?

    Thanks,

    Himel 

  • Hi Himel,

    Glad that it helped.

    Regarding the safety, is it possible to directly access the underlying HW Mailbox API, since that is safety certified? 

    Currently, none of our drivers are safety certified.

    And there is no estimation you can provide on when we can expect to see safeIPC, as that will also help us make some decisions?

    I will definitely check with the SW team tomorrow and let you know regarding the timeline.

    Thanks