MCU-PLUS-SDK-AM243X: PRU_ICSSG

and also what is the difference between CPSW peripheral and PRU_ICSSG accelerator as I see both of them do the same thing, if there a major difference please let me know

Hi Hussein,

You can read about the Networking capabilities of AM243x here: mcu_plus_sdk_api_guide_am243x_09_02_00_50_Networking

Networking is supported using the two hardware Peripherals:

• Common Port SWitch (CPSW): It provides IEEE 802.3 standard Ethernet gigabit speed packet communication for the device and can also be configured as an Ethernet switch. CPSW supports RGMII and RMII Interfaces. CPSW implementation is not based on PRUs.
• Programmable Real-Time Unit and Industrial Communication Subsystem - Gigabit (PRU-ICSSG) : PRU-ICSSG is firmware programmable and can take on various personalities like Industrial Communication Protocol Switch (for protocols like EtherCAT, Profinet, EtherNet/IP), Ethernet Switch, Ethernet MAC, Industrial Drives, etc. PRU-ICSSG supports RGMII and MII modes.

PRU cores are primarily used for industrial communication, and can also be used for other applications such as motor control and custom interfaces. The PRU-ICSSG frees up the main ARM cores in the device for other functions, such as control and data processing.

Main advantages of ICSSG are that we can offload the main ARM core of real-time processing requirements and can implement various protocols using ICSS as PRUs are programmable.

You can find a list of CPSW and ICSSG examples available with MCU+SDK to achieve different Ethernet and Networking requirements- mcu_plus_sdk_api_guide_am243x_09_02_00_50_Examples_Networking

Also, you can learn more about the RTOS and no-RTOS based Industrial Communication, Fieldbus and networking applications on PRU-ICSS from the Industrial Communications SDK: ind_comms_sdk_api_guide_am243x_09_02_00_08

Do let me know if you have any more questions.

Regards,

Nitika

I already read all the data and links required but if the PRU free up main ARM cores, why did the examples uses R5F0-0 to run the PRU? and I tried both examples for CPSW and PRU_ICSSG and they both do the same thing and use the ARM processor to handle the data flow and initialization, I do not get a real difference between them.

I know that the accelerator is designed to handle operations without the contribution of the main core but as I see in example that is not our case, my main question is, Can I configure and program PRU-core to handle Ethernet frames without using ARM cores?

I measured the CPU load for both peripherals, CPSW and PRU_ICSSG and I found that they are almost the same, as I understand the accelerator should accelerate the operation, how can I make sure that I am using the accelerator in the right way?

Hi Hussein,

PRU-ICSSG works at the Data link layer with low latency deterministic operations and post processing is handles by the ARM core. PRU is optimized for low latency and no jitter in the real-time execution and is able to process the MAC layer functionality of Industrial Ethernet standards.

The purpose of using PRU is to fulfil the need of predictability, determinism and low-latency responsiveness that real-time processing can deliver. Teaming the PRU with high-performance ARM cores in processors provides the best of both worlds by optimizing a system for cost and power consumption, yet flexible for feature upgrades through efficient reprogramming.

Hussein Hafez said:

Can I configure and program PRU-core to handle Ethernet frames without using ARM cores?

You can do that by writing the assembly code to control the PRU depending upon your use case, although it is recommended to utilise the high performance of ARM core in components where real-time processing is not a priority.

Regards,

Nitika

I was working with CPSW for months and I decided to switch to PRU_ICSSG to be more optimized but after calculating the CPU load in both examples I found that they are the same, I can not decide which is more useful in this case.

CPSW also works on data-link layer and handle Layer 2 functionality and I can not differ between them in the performance, if there is benchmark for the usage of CPSW and PRU_ICSSG please send me the data.

Thank you.

Hi Hussein,

When you say more optimized, what parameters are you looking at? Is it just the ARM core CPU load that you want to reduce or are you looking for higher throughput or any other metric as well with ICSSG?

Also, what examples did you compare for CPU load?

Regards,

Nitika

I am looking for less usage of ARM CPU and try to maximize the usage of other hardware.

I sent from Colasoft to the ECU with its maximum speed and calculated the CPU load every second and I found that they are the same, that means that both of hardware consume the CPU as the same.

What is the major difference between CPSW and ICSSG for the contribution of ARM CPU to handle the process of sending and receiving Ethernet frames?

Hi Hussein,

Understood, let me look for the performance benchmark and get dev team's input on this as well.

Allow me some time to get back to you with the relevant information.

Regards,

Nitika

Few more question,

- What are your expectations with ICSSG, how much optimization are you looking at? 

- There are software level implementations that can be made to optimize performance, so can you brief me about your usecase, what are you trying to achieve with CPSW and what made you want to switch to ICSSG?

- What kind of traffic will you be dealing with in your system? Are there any throughput requirements as well?

Regards,

Nitika

- I want to minimize the usage of ARM core to reduce CPU load because my case is handling much frames and gatewaying , ALE in CPSW handle routing and firewall without the contribution of the ARM CPU and correct me if I am wrong, I found that ICSSG handle operations without CPU contribution as the same as CPSW.

- I need to differentiate between the hardware component without the contribution of the software because any software will be process by the ARM CORE, if there is a software that could be implemented on PRU to handle the frames without the ARM CPU please guide me.

-The software is handling much frames Ethernet, CAN and LIN with high traffic so maximizing the used hardware will be efficient in my case.

Hi Hussein,

I understand, please allow me some time to get back to you on this. I will involve the dev team as well in the discussion about your use case.

Regards,

Nitika

HI Hussein,

Can you tell me more about the Ethernet traffic in your system -

- Are you using any stack like lwip? Or any Industrial protocol? What kind of Ethernet frames are you handling?

- What post-processing do you want to perform on the frames?

- You mentioned earlier that you will be using 2 ethernet ports, can you share a system diagram or information to understand what the flow of data looks like in your system and what the two ports are used for?

Regards,

Nitika

Hi Hussein,

I would like to share an update from the dev team, firstly your current assessment of ICSSG and CPSW is correct and as I mentioned above you can write/modify the firmware code controlling PRU to handle more functionality than what is already present with it. 

As of now, we do not support customizing the MAC firmware but if you are interested to do some offloading of your own, we can share PRU firmware sources and functionalities such as custom packet filters etc can be implemented with ICSSG to offload ARM CPU.

Regards,

Nitika

if the usage of that firmware will reduce the usage of ARM core than the CPSW will do please share it with me.

In my case I am using the 2 Ethernet ports to route high traffic of data and in some cases it could be routed to CAN or LIN not only the ethernet, minimizing the usage of ARM core will be efficient in that case.

I do not use any light-weight stack or any other interfaces I am just handling the Ethernet packets with MAC addresses and VLAN, I used CPSW to handle it with ALE and I switched to PRU_ICSSG to accelerate the operation.

so if the available example does not use the PRU_ICSSG efficiently then please guide me to a source to maximize the usage of that accelerator

Thank you very much.