PRU-ICSS switch vs. CPSW on-board MAC

For example, does the PRU-ICSS switch support dual mac mode?

Hello fyang,

The MII-RT inside the PRU-ICSS is a completely different IP block from the CPSW. Each PRU core controls one MII port (whereas the A8 core controls both ports in the CPSW), and I do not believe that the ports are tied together in a similar switch configuration as is the CPSW.

What exactly are you trying to get the PRU/MII-RT to do that the A8/CPSW cannot? I would like to understand the bigger picture.

Hello Tim,

Thanks for your response. I understand that the PRU-ICSS switch block is different from the CPSW. I was trying to get  more information about how they compare against each other. I was hoping that if the PRU-ICSS switch capabilities were close enough to that of the CPSW, I wouldn't even need to use the CPSW in my hardware design. Unfortunately, this isn't the case.

Would you mind elaborating as to why you do not wish to use the CPSW?

Hello Tim,

I'm trying to create one hardware design that will be able to satisfy any of my application requirements. Depending on the application, I will have to select between the PRU-ICSS and the CPSW. If the PRU-ICSS is as capable of the CPSW, I would only have one hardware design that uses the PRU-ICSS.

Tim,

I think there's some confusion here. The new SDK V1.1.0.1 allows programming the PRU-ICSS as a cut-through switch. I have confirmed this on the ICE rev1 board. Can you confirm whether or not the PRU-ICSS supports dual mac mode?

What do you mean by "dual mac mode?" Are you asking if each MII port can be configured to function independently (/on a different network)?

The CPSW can be set to dual mac mode. My understanding is that each mac would be independent and each mac would have a unique mac address. Does the PRU-ICSS cut-through switch have the ability to be set into this "dual mac" mode to function on different networks?

I should add the follow on question: if CPSW and PRU are two different components and if CPSW and ICSS cohabitate on the SoC, and if CPSW is a 3 port switch, with one internal port, is that internal port available to both PRU's? how is contention and routing handled? Or does CPSW just function in a pass through mode, where each PHY is routed to one of the PRU's?

thanks,

Hi Jim,

CPSW and ICSS are two different IP's. CPSW and ICSS are not mutually exclusive IP's, for example in AM335x they co-exist together and they are separate hardware blocks. CPSW implementation is not based on PRU's.

ICSS (Industrial communication sub system) is designed for industrial communication. ICSS on AM335x has two PRU cores in it and various peripherals which help in implementing real-time industrial communication protocols. Main advantages of ICSS are that we can offload the host processor (ARM) of real-time processing requirements and can implement various protocols using ICSS as PRU's are programmable. Please go through following white paper which discusses the benefits of ICSS and what functionalities we have implemented on two PRU's in ICSS in PROFINET context. Please let us know if you have more questions.

http://www.ti.com/lit/wp/spry252b/spry252b.pdf

Regards,

Robin Singh

Hi Jim,

Yes, Figure 11 shows an identical list of activities because Firmware is symmetrical on both the PRU's. It has to be because PLC can be connected to any of two Ethernet ports. As shown in figure PRU0 receives frames from Port1 and Transmits on Port2 and vice-versa for PRU1.  

Both PRU's can handle the RT Communication and receive & transmit  the TCP/IP traffic. Both PRU's can cut-through the frames in the opposite directions. So, no one PRU is reserved for just handling RT Communication or NRT (Non Real Time) traffic.  Firmware for both PRU's is symmetrical but yes you will see few differences in the firmware binary for two because some code is specific to a PRU but that is largely internal event handling or bookkeeping code. Functionality is same for both the PRU's. There is NO CPSW involvement here. Both PRU's directly receive frames from their Ethernet Ports. PROFINET implementation is completely based on ICSS and it has nothing to do with CPSW.

In our solution there are three layers Stack, Driver and PRU Firmware. PRU Firmware executes on two PRU's in ICSS and implements the Data Link layer. Driver API's are used by stack to configure/interact with the PRU Firmware. 

We have Four receive queues for the host port and both PRU's put the received frames in these four queues as per quality of service rules. PROFINET Stack picks up the frames from top two priority queues whereas NDK (TCP/IP stack) picks up the frames from lower two priority queues. If you are sending a UDP frame then you have to open a socket on top of NDK to receive it.  If you want to see the received frame at driver level then you can put a break point in "RxPktGet' API in "icss_iSwitchDrv.c" file in "os_drivers/src/ICSS" folder or in receive ISR "RxInterruptHandler".

 Regards,

Robin Singh

hi Robin -

thanks.i can see where the packets come in now. prior to this, I was only able to trace to the boundary of the Molex stack and therefore missed where the UDP packets came in. I had gotten as far as iccs_swtichdrv.c but it wasn't clear what/how was driving RxTask (ie where the packets were coming from.) I've traced the init code. where does EMAC Init get called from? is that part of the interface into the NDK?

If I interpret your comments correctly, the PRU code transparently operates on incoming packets, regardless of PHY source. The ISR linkage to notify RxTask semaphore can be posted from either PRU and RxPktGet sorts out where they go and posts to the appropriate queue.

Since the next step in my activity will be to implement support for EthernetIP, does the PRU code that gets downloaded as part of the iPNDrv.c preclude running the EIP protocol? My very casual first look at the PRU download for the EIP suggests that it is a different size.

Thanks.

Jim

Robin,

I'm sure this isn't my last question, but my level of understanding has increased tremendously - thanks to your effort. anyway, do I need to be concerned which PRU runs the cyclic data transfer? I assume that reading and writing the relevant application data happens in the PRU shared RAM? is memory locking handled by the PRU for the cyclic data?

Jim

Hi Robin,

thanks. I've been reading your document a little more closely, so I'm sorry to have not caught some of this earlier. But at least a couple more questions: your document on page 11 refers to the TI Profinet API in the context of cyclic data transfer (CPM/PPM processing). is this what is captured in the iRtcDrv.c file? it appears to show up in the Molex demo code. Your document also makes the distinctions among CC-A, B and C. I'm familiar with how they're supposed to work, but my casual look over the Drv file doesn't seem to indicate how I would or would not specify Conformance Class C. I actually don't want C, we want to be at B but I don't want the synchronization clock overhead being part of the network traffic when we don't need it. And of course is there any documentation on how to set it up?

if we are at CC-B, we have to implement the SNMP connection. We have the Interniche source code but I haven't had time to go through it yet. It would be helpful to know if your SDK Profinet demo actually tied into the MIB database. For that matter, the documentation that came with 1.0.0.6 said that the Profinet demo was incomplete. it would save me some time if I knew ahead of time what was not connected.

I will need to know what degree of compatibility there is between the PRU firmware for Profinet and the PRU firmware for Ethernet IP.

I'm also curious as to how the ICSS PRU bypasses the CPSW. I assume the CPSW is a cell on the SoC to which are wired the PHY connections. I'm not the hardware guy, but is the bypass achieved in the Pin Muxing of the port pins?

thanks again.

Jim

Hi Jim,

Yes TI Profinet API's are in iRtcDrv.c and iPNDrv.c files.  

In SDK 1.1.0.6 there is only CC-A,B. We have not released yet the CC-C solution. So, you don't need to anything to configure it is CC-B, it is by default set for CC-B class.

Whatever we have not tied, there will be comment saying /*TODO ....*/ in the mib_impl.c file. Mostly we have tied the values to 0 there.

From application perspective the firmware for PROFINET and EthernetIP are different binary files. But yes firmware for both have a common base and then we build the protocol specific functionality's on top of it. IF you are running PROFINET then boot the board with PROFINET app and if you are using then boot the board with EthernetIP app. 

PINMUXING at  SoC boundary allows either ICSS or CPSW to interface with the PHY's on AM335x. We choose a pin muxing configuration which connects ICSS to PHY's. So, CPSW doesn't come into picture at all.

Regards,

Robin Singh  

Hi -

in the for it's worth category (and part of my initial confusion that led to the whole exercise of figuring out how the PRU's work), I can't find anywhere in the Profinet slave example where EMAC _Init is called. what I have figured out is that the Interniche code for the SNMP contains their own TCP/IP stack, which I'm sure is there to access their MIB files using their own UDP:port connection. it turns out that this stack is incompatible with running the NDK stack. It looks to me that you can't have both InitSNMP and EMAC_Init in the same application without modifying initSMNP().

I've done all I want with the PN slave app and I'm moving on to my real code. I still need the document on the decision tables.

thanks.

Jim