TMDS64EVM: CPSW Cut-through using MCU+ SDK

Hi Jonas Olsson,

Thanks for your query.

I will check on this and get back to you.

Regards

Ashwani

Thanks for having patience.

I stuck in something else. Now, working on this. will provide some result in next week.

Regards

Ashwani

Hi Jonas,

Can you please help me with some information about your setup:

1. What SDK version are you using?

2. Are you building your project in Debug mode or Release mode? If you are using Debug mode. then I would suggest you to switch to Release mode for profiling.

3. Can you confirm that you are following the steps and limitations of cut-through feature mentioned in the SDK documentation: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/09_01_00_41/exports/docs/api_guide_am64x/EXAMPLES_ENET_LAYER2_CPSW_SWITCH-Cut-Through-feature

Regards,

Nitika

Hi Nitika,

1. I'm using  mcu_plus_sdk_am64x_09_01_00_41

2. Tried Release mode, same result

3. The ENET_LAYER2_CPSW_SWITCH example is used as is. Forwarding is done between external ports using full duplex 1Gb. The steps to enable Cut-thru switching are undocumented. I have verified that the example code do call the EnetApp_setCutThruParams function.

A complete example with a sender and receiver enabling cut-thru would be really helpful.

Regards,

Jonas

If your priority goal is measuring the CPSW3G cut-through latency on AM64x family of devices it is about 1.5us. The Linux side switch drivers have supported cut-through for a while see https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW3g.html?highlight=cut%20through#enabling-cut-through-forwarding-ctf for how.

MCU+ driver support and testing might be limited. On AM64x I'd recommend using Linux to manage CPSW3G.

  Pekka

The thing is that we need the same support for the AM243x series and there we will have to rely on the MCU+ driver support.

Is there any better support for cut-through in the AM243x MCU+ SDK? I thought they are mostly the same?

This functionality is strictly necessary in our design and the announced support is one of the main reasons we started to investigate the AM64x/AM243x series from the beginning.

When can we expect any support of this functionality in the MCU+ SDK?

Regards,

Jonas

Ok, so you are not just looking for a DUT to configure as either cut-through or store and forward. I would still recommend trying this as a reference with Linux as the switch configuration with the default SDK SD card image is quite quick.

As you have noticed the MCU+ has the API in brief documentation on how to configure cut-through. But what seems to be your observation the frames are not cut-through even though you configured so. Can you take a look at the statistics counters the CPSW3G maintains. High level description and Linux ethtool interface is in the Linux SDK https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW3g.html?highlight=cut%20through#enabling-cut-through-forwarding-ctf , copied here for convenience:

ethtool -S eth1 | grep col
  tx_collision_frames: 1796093
  tx_single_coll_frames: 0
  tx_mult_coll_frames: 3
  tx_excessive_collisions: 0
  tx_late_collisions: 0
root@evm:~# ethtool -S eth0 | grep col
  tx_collision_frames: 3
  tx_single_coll_frames: 0
  tx_mult_coll_frames: 2002396
  tx_excessive_collisions: 52
  tx_late_collisions: 23

tx_collision_frames:      Enet_Pn_TxCut Enet Port n Cut Thru with and without delay (full-duplex)
tx_single_coll_frames:    Enet_pn_TxCut_SAF Enet Port n Tx Store and Forward (full-duplex)
tx_mult_coll_frames:      Enet_Pn_RxCut_NoDelay Enet Port n Rx Cut Thru with no delay (full-duplex)
tx_excessive_collisions:  Enet_Pn_RxCut_Delay Enet Port n Rx Cut Thru with delay (full-duplex)
tx_late_collisions:       Enet_Pn_RxCut_SAF Enet Port n Rx Store and Forward (full-duplex)

So in RTOS environment can you look at the statistics counter CPSW_STATN_TXCOLLISIONFRAMES which in full duplex case is used for normal frames that are cut through. Old name for this register is for half-duplex, where cut-through is not possible. It looks to me this is at address 0803 A248h for one port and at 0803 A448h. TRM section 12.2.1.6.8.19 .

This statistics register is the basic check we use in Linux.

  Pekka

Just to clarify, what knowledge can be gained from this test that is not already available from the information in my first post?

> The measured delays are about 13 us for 1500 bytes or 2 us for 64 bytes, which means that cut-through is not activated.

If the cut-through was enabled, wouldn't the 1500 bytes package have the same delay as the 64 byte package?

Kind regards

Jonas

Jonas Olsson said:

If the cut-through was enabled, wouldn't the 1500 bytes package have the same delay as the 64 byte package?

Yes for the start of frame.

Jonas Olsson said:

Just to clarify, what knowledge can be gained from this test that is not already available from the information in my first post?

This is a ask to read the counters which describe what the CPSW thinks it is doing, so not a new test. So can you read the addresses for register name is CPSW_STATN_TXCOLLISIONFRAMES incrementing. So is counter at 803 A248h for one port and at 0803 A448h for the other incrementing when traffic you expect to be cut through is being sent.

Using Linux on the middle CPSW would be the reference test for cut through.

  Pekka